CN115001639B - Method for avoiding HFN desynchronization in uplink through WLAN in LTE-WLAN aggregation - Google Patents

Abstract

The present disclosure relates to a method of avoiding HFN desynchronization in the uplink through a WLAN in LTE-WLAN aggregation. Various techniques for mitigating or eliminating Hyper Frame Number (HFN) desynchronization for uplink LWA are described herein. In one embodiment, a separate PDCP discard timer is maintained for packets sent over the WLAN and LTE links. The discard timer may be set independently for WLAN and LTE links. In a second embodiment, status reports indicating Acknowledgements (ACKs) and/or Negative Acknowledgements (NACKs) for 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 transmitted once over the WLAN link may be disabled.

Description

Method for avoiding HFN desynchronization in uplink through WLAN in LTE-WLAN aggregation

The application is a divisional application of the application patent application with international application number of PCT/US2017/059117, international application date of 2017, 10 month and 30 days, stage date of entering China of 2019, 04 month and 01 days, china of application number of 201780061079.0 and the application name of 'HFN desynchronization method in uplink of avoiding passing through WLAN in LTE-WLAN aggregation'.

RELATED APPLICATIONS

The present application claims the benefit of U.S. provisional patent application No.62/416,013 filed on 1/11/2016, the contents of which provisional patent application is incorporated herein by reference as if fully set forth herein.

Background

Wireless cellular telecommunication networks include a Radio Access Network (RAN) that enables a User Equipment (UE) (e.g., a smart phone, a tablet, a laptop, etc.) to connect to a core network. Examples of wireless telecommunication networks may include Evolved Packet Systems (EPS) operating based on third generation partnership project (3 GPP) communication standards. In cellular networks, UEs typically communicate with base stations using channels corresponding to licensed radio spectrum (e.g., the radio spectrum designated for cellular network communications).

Recently, techniques have been implemented that allow unlicensed spectrum to be used to assist or supplement network connectivity provided through licensed spectrum. One such technique 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 a technique that uses LTE in unlicensed spectrum without requiring hardware changes to network infrastructure equipment and UEs. LWA allows two links to be used for a single traffic flow and is generally efficient due to coordination of lower protocol stack layers.

Link aggregation for LWA was initially limited to Downlink (DL) traffic aggregation (i.e., from the base station to the 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 ease of 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 illustrates an architecture of a system according to some embodiments;

FIG. 2 is a diagram illustrating an example of 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 chart illustrating an example procedure for providing PDCP status reports from a base station to a User Equipment (UE);

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

fig. 5 is a diagram conceptually showing concepts consistent with the third embodiment;

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

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

FIG. 8 is a diagram 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 methods 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 the embodiments is defined by the appended claims and their equivalents.

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

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

Various techniques for HFN desynchronization to mitigate or eliminate uplink LWA traffic are described herein. In one embodiment, a separate PDCP discard timer is maintained for packets sent over the WLAN and LTE links. The discard timer may be set independently for WLAN and LTE links. In a second embodiment, status reports indicating Acknowledgements (ACKs) and/or Negative Acknowledgements (NACKs) 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 transmitted once over the WLAN link may be disabled.

As described herein, the first and third embodiments can be used to simplify logic and potentially reduce memory requirements for a UE, as PDCP SDUs sent over a WLAN link may only need to be buffered for a short period of time or not at all. The first and third embodiments may be used in particular 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. The system 100 is shown to include a User Equipment (UE) 101 and a UE 102. The UEs 101 and 102 are shown as smart phones (e.g., handheld touch screen mobile computing devices connectable to one or more cellular networks), but the UEs 101 and 102 may 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, either of the 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) communications, sensor networks, or IoT networks. The M2M or MTC data exchange may be a machine initiated data exchange. IoT networks describe interconnecting IoT UEs, which may include uniquely identifiable embedded computing devices (within the internet infrastructure) with short-term connections. The IoT UE may execute a background application (e.g., keep-alive messages, status updates, etc.) to facilitate connection of the IoT network.

The UEs 101 and 102 may be configured to connect (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 cellular communication protocols, which may be, for example, global system for mobile communications (GSM) protocols, code Division Multiple Access (CDMA) network protocols, push-to-talk (PTT) protocols, PTT-over-cellular (POC) protocols, universal Mobile Telecommunications System (UMTS) protocols, 3GPP Long Term Evolution (LTE) protocols, fifth generation (5G) protocols, new Radio (NR) protocols, and so forth.

In this embodiment, the UEs 101 and 102 may also exchange communication data directly via the ProSe interface 105. ProSe interface 105 may alternatively be referred to as a sidelink interface that includes one or more logical channels including, but not limited to, a physical side link control channel (PSCCH), a physical side link shared channel (PSSCH), a physical side link discovery channel (PSDCH), and a physical side link 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, such as a connection conforming to any IEEE 802.11 protocolThe middle AP 106 will include wireless fidelityAnd a router. In this example, the AP 106 is shown connected to the internet rather than to the core network of the wireless system (described in further detail below).

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

Any of the RAN nodes 111 and 112 may terminate the air interface protocol and may be the first point of contact for the 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.

According to some embodiments, UEs 101 and 102 may be configured to communicate with each other or 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, orthogonal Frequency Division Multiple Access (OFDMA) communication techniques (e.g., for downlink communications) or single carrier frequency division multiple access (SC-FDMA) communication techniques (e.g., for uplink and ProSe-based or sidelink communications), although the scope of the embodiments is not limited in this respect. The OFDM signal may comprise a plurality of orthogonal subcarriers.

In some embodiments, the downlink resource grid may be used for downlink transmissions from any of the RAN nodes 111 and 112 to the UEs 101 and 102, while the 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 time slot. This time-frequency plane representation is a common practice for OFDM systems, which makes radio resource allocation 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 the 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 that 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 be currently allocated. There are several different physical downlink channels transmitted using such resource blocks.

A Physical Downlink Shared Channel (PDSCH) may carry user data and higher layer signaling to UEs 101 and 102. The Physical Downlink Control Channel (PDCCH) may carry information on resource allocation and transport format aspects related to the PDSCH channel, etc. It may also inform UEs 101 and 102 about 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 the RAN nodes 111 and 112 based on channel quality information fed back from any of the 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 a Control Channel Element (CCE). The PDCCH complex-valued symbols may first be organized into quadruples before being mapped to resource elements, and these quadruples 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 a Resource Element Group (REG)), 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, a 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 concepts for resource allocation of control channel information, which are extensions of the concepts described above. 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 above, each ECCE may correspond to a set of nine physical resource elements (referred to as Enhanced Resource Element Group (EREG)), each set of physical resource elements including four physical resource elements. In some cases, ECCEs may have other amounts of EREGs.

RAN 110 is shown communicatively coupled to a Core Network (CN) 120 via an 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 types of CNs. 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 an S1-Mobility Management Entity (MME) interface 115, which is a signaling interface between RAN nodes 111 and 112 and MME 121.

In this embodiment, the CN 120 includes an MME 121, an S-GW 122, a Packet Data Network (PDN) gateway (P-GW) 123, and a 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 entity handling communication sessions. Depending on the number of mobile subscribers, the capacity of the device, the organization of the network, etc., the CN 120 may include one or more HSS 124. For example, the HSS 124 may provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location dependencies, and the like.

S-GW 122 may terminate S1 interface 113 towards RAN 110 and route data packets between RAN 110 and CN 120. Furthermore, the S-GW 122 may be a local mobility anchor for inter-RAN node handover and may also provide anchoring 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. The P-GW 123 may route data packets between the EPC network 123 and external networks, such as networks that include an application server 130 (alternatively referred to as an Application Function (AF)), via an 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 service, 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 IP communication 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.

The 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 associated with an internet protocol connectivity access network (IP-CAN) session of the UE in a Home Public Land Mobile Network (HPLMN). 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) using an appropriate Traffic Flow Template (TFT) and QoS Class Identifier (QCI), which begins QoS and charging specified by application server 130.

Fig. 2 is a diagram illustrating an example of implantation of LWA in the environment of 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 both uplink and downlink traffic. PDCP may be used to transfer user plane and control plane traffic between UE 102 and eNB 111. Each SDU of the traffic may be assigned an SN to allow the UE 102 or eNB 111 to reassemble the stream of SDUs and to ensure that the correct order of SDUs is maintained. In addition, as described above, in addition to SN, in order to limit the size of SN value, overflow counter HFN (super frame number) may be used at UE 102 and eNB 111. The HFN should be synchronized between the UE 102 and the eNB 111 because the HFN is used as input for the subsequent decryption algorithm. If the wrong HFN is associated with the packet, the packet cannot be decrypted. When SN reaches its maximum value, SN will restart from 0 and 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 differently arranged 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, after transmitting PDCP SDUs, the UE 102 may buffer SDUs in case the UE 102 needs to retransmit 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 the 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 the discard timer expires for the PDCP SDU or otherwise confirms successful delivery of the PDCP SDU.

Using too large PDCP discard timer values may result in wasted resources (e.g., the UE 102 needs to maintain a large buffer of PDCP SDUs that are transmitted). Using too small PDCP discard timer values 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 transmitted over the LTE link may be different from the discard timer for PDCP SDUs transmitted over the WLAN link. In one example, the network may configure different (or the same) discard timers based on the estimated round trip times of the various links. In another example, the discard timer of the WLAN may be considered a PDCP buffer protection timer, which may 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 may maintain a WLAN discard timer 310, an LTE discard timer 320, and a PDCP buffer 330. The WLAN discard timer 310 may 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. 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 a status report.

The value of the discard timer (including WLAN discard timer 310) may be set using a number of techniques. In some implementations, dedicated Radio Resource Control (RRC) signaling or broadcast RRC signaling may be used. Alternatively or additionally, in-band signaling (i.e., over the WLAN link) using Medium Access Control (MAC) Control Elements (CEs), PDCP control data units, or additional header information or other data units using the LTE-WLAN convergence adaptation protocol (LWAAP) may be used.

Specifically, in one possible meaning, dedicated RRC signaling (e.g., over an LTE link) may be used, wherein the value of the WLAN discard timer is included in the 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 sub-clause 6.3.2 of 3GPP TS 36.331, wherein bold text in table I is used to show features not in the existing 3GPP standard.

In table I, "discard timer WLAN" may indicate a discard timer value for a packet (e.g., SDU) sent on a 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 the 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 exist.

In a second embodiment, PDCP status reports may be provided from the eNB to the 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 in the status report as being received.

Fig. 4A is a flow chart illustrating an example procedure 400 for providing PDCP status reports from an eNB to a UE. Process 400 may be implemented by, for example, eNB 111.

Process 400 may include determining whether a periodic status report timer has expired for the LWA uplink bearer (block 410-yes) (block 420). 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), PDCP SDUs lost during transmission over the WLAN link will not result in HFN desynchronization between the eNB and the UE.

Fig. 4B is a flow chart illustrating an example of another procedure (procedure 450) for providing PDCP status reports from an eNB to a UE. Process 450 may be implemented by, for example, eNB 111.

Process 450 may include determining, for the LWA uplink bearer (block 460-yes), whether a certain number (N, where N is an integer) of SDUs have been transmitted since a last status report was transmitted to the UE (block 470). When at least N data units have been transmitted since the last status report was transmitted to the UE (block 470, yes), the eNB may provide the status report to the UE associated with the bearer. 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 indicated as successfully received in the status report from the buffer of the UE. In this way, lost PDCP SDUs during transmission over the WLAN link will not result in HFN desynchronization between the eNB and the UE.

Alternatively or additionally, other techniques may be used to trigger generation of PDCP status reports. For example, expiration of a reordering timer at the eNB may trigger PDCP or LWA status reporting 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 PDCP or LWA status reports.

In processes 400 and 450, a number of potential techniques may be used to communicate parameters associated with processes 400 and 450 (e.g., the value of the periodic status report 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 report timer and/or the value of N may be provided as part of an initial setup of the eNB or dynamically determined by the eNB based on the operating 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 not 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 to assist the UE in determining the packets it should retransmit. In this implementation, the UE will not maintain PDCP buffers for uplink PDCP SDUs sent over the WLAN link. Instead, the UE may only need to maintain a buffer for uplink SDUs sent 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 of the low likelihood of data loss occurring over the WLAN, disabling PDCP data recovery for data units sent over the WLAN may not negatively impact operation of the system in this embodiment. Further, because there is no retransmission of packets sent over the WLAN, no WLAN feedback (e.g., WLAN status report) is required.

Fig. 5 is a diagram conceptually showing concepts conforming to the third embodiment. As shown, UL PDCP SDUs may be sent simultaneously on both LTE and WLAN links. The UE 101 may maintain a buffer for PDCP SDUs sent on the LTE link, labeled LTE PDCP buffer 520. However, for WLAN links, the UE may discard the possibility to retransmit PDCP SDUs. Thus, the WLAN link does not require a buffer (shown by the "scratched out" WLAN PDCP buffer). Similarly, feedback, e.g., status reports, may be sent to the UE 101 indicating the SNs of received (or not received) PDCP SDUs 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 received SDUs 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 normally 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 acknowledge that it has received the packet (e.g., by a status report). In this implementation, the UE essentially "spoofs (tricks)" 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 transmissions of status reports may be used.

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

Fig. 6 illustrates example components of a device 600 according to some embodiments. In some embodiments, the 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 components of the illustrated device 600 may be included in a UE or RAN node. In some embodiments, the device 600 may include fewer elements (e.g., the RAN node may not use the application circuitry 602, but instead include 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., the circuitry may be separately included in more than one device for a Cloud-RAN (C-RAN) implementation).

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, the processor of application circuit 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 circuit 604 may interface with application circuit 602 to generate and process baseband signals and control the operation of RF circuit 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 to be developed in or about 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 functionality of baseband processors 604A-D may be included in modules stored in memory 604G and these functions may be performed via 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 functions. In some embodiments, the encoding/decoding circuitry of baseband circuitry 604 may include convolution, tail-biting (tail-biting) convolution, turbo, viterbi, and/or Low Density Parity Check (LDPC) encoder/decoder functions. Embodiments of the modem and encoder/decoder functions are not limited to these examples and may include other suitable functions in other embodiments.

In some embodiments, 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 suitably combined 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 baseband circuitry 604 and application circuitry 602 may be implemented together, for example, on a system on a chip (SOC).

In some embodiments, 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), a Wireless Local Area Network (WLAN), a Wireless Personal Area Network (WPAN). Embodiments in which baseband circuitry 604 is configured to support radio communications for more than one wireless protocol may be referred to as multi-mode baseband circuitry.

The 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 a wireless network. The RF circuitry 606 may include a receive signal path that may include circuitry to down-convert RF signals received from the FEM circuitry 608 and provide baseband signals to the baseband circuitry 604. RF circuitry 606 may also include transmit signal paths 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 circuit 606 may include a mixer circuit 606a, an amplifier circuit 606b, and a filter circuit 606c. In some embodiments, the transmit signal path of RF circuit 606 may include filter circuit 606c and mixer circuit 606a. The RF circuit 606 may also include a synthesizer circuit 606d for synthesizing frequencies for use by the mixer circuit 606a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuit 606a of the receive signal path may be configured to down-convert the RF signal received from the FEM circuit 608 based on the synthesized frequency provided by the synthesizer circuit 606 d. The amplifier circuit 606b may be configured to amplify the down-converted 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 down-converted 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 circuit 606a of the transmit signal path may be configured to upconvert the input baseband signal based on a synthesized frequency provided by the synthesizer circuit 606d to generate an RF output signal for the FEM circuit 608. The baseband signal may be provided by baseband circuitry 604 and may be filtered by filter circuitry 606 c.

In some embodiments, the mixer circuit 606a of the receive signal path and the mixer circuit 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 comprise two or more mixers and may be arranged for image rejection (e.g., hartley) image rejection. In some embodiments, the mixer circuit 606a of the receive signal path and the mixer circuit 606a of the transmit signal path may be arranged for direct down-conversion and/or direct 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 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 circuit 606 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuits, and baseband circuit 604 may include a digital baseband interface to communicate with RF circuit 606.

In some dual mode embodiments, separate radio IC circuits 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 synthesizer or a fractional-N/N +1 synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, the 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 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 circuit 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 a channel indicated by the application processor 602.

The synthesizer circuit 606d of the RF circuit 606 may include a frequency divider, a Delay Locked Loop (DLL), a multiplexer, and a phase accumulator. In some embodiments, the frequency divider may be a dual-mode frequency divider (DMD) and the phase accumulator may be a Digital Phase Accumulator (DPA). In some embodiments, the DMD may be configured to divide the input signal by N or n+1 (e.g., based on the 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 up to Nd equal phase packets, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

In some embodiments, synthesizer circuit 606d may be configured to generate a carrier frequency as an 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 quadrature generator and divider circuits to generate a plurality of signals having a plurality of mutually different phases at the carrier frequency. In some embodiments, the output frequency may be an LO frequency (fLO). In some embodiments, the 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 an amplified version 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 by RF circuitry 606 for transmission by one or more of one or more antennas 610. In various embodiments, amplification via either the transmit signal path or the receive signal path may be accomplished in only RF circuit 606, only FEM 608, or in both RF circuit 606 and FEM 608.

In some embodiments, FEM circuitry 608 may include TX/RX switches to switch between transmit 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 the RF circuitry 606). The transmit signal path of FEM circuitry 608 may include a Power Amplifier (PA) for amplifying an input RF signal (e.g., provided by RF circuitry 606) and one or more filters for generating an RF signal for subsequent transmission (e.g., through one or more of one or more antennas 610).

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

Although fig. 6 shows PMC 612 coupled only to 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 the various power saving mechanisms of device 600. For example, if the device 600 is in an RRC Connected state in which the device 600 is expected to be Connected to the RAN node soon after receiving traffic, then may enter a state called discontinuous reception mode (DRX) after a period of inactivity. During this state, the device 600 may be powered down for a brief interval, thereby conserving power.

If there is no data traffic activity for an extended period of time, the device 600 may transition to an rrc_idle state in which the device 600 is disconnected from the network and no operations such as channel quality feedback, handover, etc. are performed. The device 600 enters a very low power state and performs paging, where the device 600 wakes up again periodically 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 saving mode may allow the device to be unavailable to the network for periods longer than the paging interval (ranging from a few seconds to a few hours). During this time, the device is completely inaccessible to the network and may be completely powered off. Any data transmitted during this period will incur a significant delay and the delay is assumed to be acceptable.

The processor of the application circuit 602 and the processor of the baseband circuit 604 may be used to execute elements of one or more instances of the protocol stack. For example, the processor of baseband circuitry 604 (alone or in combination) may be configured to perform layer 3, layer 2, or layer 1 functions, while the processor of 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, which will be described in further detail below. As mentioned herein, layer 1 may include a Physical (PHY) layer of the UE/RAN node, as will be described in further detail below.

Fig. 7 illustrates an example interface of baseband circuitry according to some embodiments. As described above, the baseband circuitry 604 of fig. 6 may include processors 604A-604E and a 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.

Baseband circuitry 604 may also include one or more interfaces to communicatively couple to other circuits/devices, such as memory interface 712 (e.g., an interface for transmitting/receiving data to/from memory external to baseband circuitry 604), application circuitry interface 714 (e.g., an interface for transmitting/receiving data to/from application circuitry 602 of fig. 6), RF circuitry interface 716 (e.g., an interface for transmitting/receiving data to/from RF circuitry 606 of fig. 6), wireless hardware connection interface 718 (e.g., an interface for transmitting/receiving data to/from Near Field Communication (NFC) components, bluetoothComponent (e.g. Bluetooth->Low power consumption)/(f)>An interface for components and other communication components to send/receive data), and a power management interface 720 (e.g., an interface for sending/receiving power or control signals to/from the 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 in accordance with 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.

PHY layer 801 may transmit or receive information used by MAC layer 802 over one or more air interfaces. PHY layer 801 may also perform link adaptation or Adaptive Modulation and Coding (AMC), power control, cell search (e.g., for purposes of initializing synchronization and handover), and other measurements used by higher layers (e.g., RRC layer 805). PHY layer 801 may further perform error detection, 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 over the transport channels to the PHY, demultiplexing MAC SDUs from one or more logical channels from Transport Blocks (TBs) to be transmitted over the transport channels from the PHY, multiplexing MAC SDUs onto 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 modes of operation 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 sequential delivery of upper layer PDUs when reconstructing lower layers, eliminate duplication of lower layer SDUs when reconstructing lower layers for radio bearers mapped on RLC AM, encrypt and decrypt 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 primary 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 UEs and 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 SIB may include one or more Information Elements (IEs), each of which may include a separate data field or data structure.

The UE 101 and the RAN node 111 may utilize a Uu interface (e.g., an 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.

The non-access stratum (NAS) protocol 806 forms the highest layer of the control plane between the UE 101 and the 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 includes 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.

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

RAN node 111 and MME 121 may utilize an 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. Many examples will be given next 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 methods discussed herein, according to some example embodiments. In particular, FIG. 9 shows a diagrammatic representation of a hardware resource 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 that utilize node virtualization (e.g., NFV), hypervisor 902 can be executed to provide an execution environment for one or more network slices/sub-slices that utilizes hardware resources 900.

The 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, a processor 912 and a processor 914.

Memory/storage 920 may include main memory, disk memory, or any suitable combination thereof. 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.

Communication resources 930 may include an interconnect or network interface component or other suitable device to communicate with one or more peripheral devices 904 or one or more databases 906 via network 908. For example, communication resources 930 may include wired communication components (e.g., for coupling via 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, programs, applications, applets, apps, or other executable code for causing at least any processor 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 device 920, or any suitable combination thereof. Further, any portion of the instructions 950 may be transferred from any combination of the peripheral device 904 or database 906 to the hardware resource 900. Accordingly, the processor 910, memory/storage 920, peripheral 904, and memory of database 906 are examples of computer-readable and machine-readable media.

Many examples will be given next 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 a cellular radio; a second interface to a Radio Frequency (RF) circuit 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 the 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 be discarded from the retransmission buffer; and discarding the selected PDCP SDU from 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 the PDCP SDU 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 of the preceding claims, wherein the one or more processors are further to include the 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 the first retransmission buffer; maintaining a second discard timer for a second retransmission buffer; and deleting the PDCP SDU from the first and second retransmission buffers based on the first and second discard timers, 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 the PDCP SDU from the first and second buffers based on the first and second discard timers, respectively.

In a sixth example, a User Equipment (UE) apparatus includes a computer readable medium comprising program instructions; and one or more processors configured to execute the 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 SDUs; retransmitting selected ones of the PDCP SDUs to the eNB based on feedback from the eNB regarding the transmitted PDCP SDUs; processing Long Term Evolution (LTE) WLAN aggregation (LWA) status reports received via a WLAN radio or via a cellular radio to determine selected ones of the PDCP SDUs to discard from the buffer; and discarding the selected PDCP SDU from 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 PDCP SDUs to be retransmitted from among the PDCP SDUs.

In example 8, the subject matter of example 1 or 6 or any of the preceding claims, wherein the status report includes a Negative Acknowledgement (NACK) of a selected one 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 from the eNB periodically.

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 transmitted 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 a cellular radio; a second interface to a Radio Frequency (RF) circuit 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 a cellular radio; implementing a second buffer using the memory, the second buffer storing a second PDCP data unit transmitted to the eNB via a second interface and using the WLAN radio; implementing a first discard timer for the first PDCP data unit; implementing a second discard timer for a second PDCP data unit; discarding the first PDCP data unit from the first buffer based on the first discard timer; and discarding the second PDCP data unit from the second buffer based on the second discard timer.

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

In example 13, the subject matter of example 10 or 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, the subject matter of example 13 or 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: based on a message received from the eNB via the second interface, a value of a second discard timer is determined.

In example 16, the subject matter of example 11 or 15 or 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, the subject matter of example 11 or 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 to be discarded from the second buffer for transmission using the WLAN radio; and discarding the selected PDCU SDU in the second PDCP SDU based on the LWA status report.

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

In example 19, the subject matter of example 17 or 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 example 20, a computer-readable medium containing instructions that, when executed by a processor of a User Equipment (UE), cause the UE to: controlling uplink transmission of a Packet Data Convergence Protocol (PDCP) Service Data Unit (SDU) 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 be discarded from the retransmission buffer; and discarding a selected PDCP SDU 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: sequence numbers are included in PDCP SDUs.

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 the first retransmission buffer; maintaining a second discard timer for a second retransmission buffer; and deleting the PDCP SDU 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 the PDCP SDU 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 of the preceding claims, wherein the one or more processors are further to: the status report is processed to determine those PDCP SDUs to be retransmitted from among the PDCP SDUs.

In example 26, the subject matter of example 20 or 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 from the eNB periodically.

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

Example 29 includes a method implemented by a User Equipment (UE), comprising: controlling uplink transmission of a Packet Data Convergence Protocol (PDCP) Service Data Unit (SDU) 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 be discarded from the retransmission buffer; and discarding a selected PDCP SDU of the PDCP SDUs based on the LWA status report.

In example 30, the subject matter of example 29 or any of the preceding claims, controlling 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 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 the first retransmission buffer; maintaining a second discard timer for a second retransmission buffer; and deleting the PDCP SDU 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 PDCP SDUs to be retransmitted from among the PDCP SDUs.

In example 34, the subject matter of example 29 or 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 35, the subject matter of example 29 or any of the preceding claims, wherein the status report is received from the eNB periodically.

In example 36, a User Equipment (UE) apparatus comprises: means for controlling uplink transmission of a Packet Data Convergence Protocol (PDCP) Service Data Unit (SDU) 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 transmitted PDCP SDUs; means for processing LWA status reports received from the eNB to determine selected ones of the PDCP SDUs to be discarded 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, the subject matter of example 37 or 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 the first retransmission buffer; means for maintaining a second discard timer for the second retransmission buffer; and deleting the PDCP SDU from the first and second retransmission buffers based on the first and second discard timers, respectively.

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

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 as 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 a 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 performed in parallel.

Obviously, 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 could be designed to implement the aspects based on the description herein.

Although specific combinations of features are set forth in the claims and/or disclosed in the specification, such 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 term "and" does not necessarily exclude an explanation of the phrase "and/or" intended in that example. Similarly, as used herein, an example using the term "or" does not necessarily exclude the intended interpretation of the phrase "and/or" in that example. Furthermore, 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 "a", "an", "only" or similar language are used.

Claims (19)

1. An apparatus for a baseband processor of a user equipment, UE, the apparatus comprising:

a first interface to a radio frequency, RF, circuit configured to communicate via a cellular radio;

A second interface to a radio frequency, RF, circuit 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, using the second interface;

implementing a retransmission buffer to buffer the transmitted PDCP SDUs;

processing LWA status reports of the uplink LWA traffic received from a base station via the first interface or the second interface to determine selected ones of the PDCP SDUs to be discarded from the retransmission buffer, the LWA status reports indicating whether the PDCP SDUs are received; and

discarding the selected PDCP SDU 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:

And controlling uplink retransmission of the PDCP SDU 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:

sequence numbers are included in the PDCP SDUs.

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 SDU from the first and second retransmission buffers based on the first and second discard timers, respectively.

5. The apparatus of claim 1, wherein the retransmission 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 SDU from the first and second buffers based on the first and second discard timers, respectively.

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

7. The apparatus of claim 1, wherein the LWA status report is received from the base station after a predetermined number of PDCP SDUs have been transmitted over the WLAN.

8. A user equipment, UE, apparatus comprising:

a computer readable medium containing program instructions; and

one or more processors configured to execute the program instructions to:

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

buffering the transmitted PDCP SDUs in a buffer;

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 cellular radio to determine a selected one of the PDCP SDUs to be discarded from the buffer, the LWA status report indicating whether the PDCP SDU was received; and

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

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

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

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

sequence numbers are included in the PDCP SDUs.

11. The apparatus of claim 8, 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 SDU from the first and second buffers based on the first and second discard timers, respectively.

12. The apparatus of claim 8, wherein the LWA status report is received periodically from the base station.

13. The apparatus of claim 8, wherein the LWA status report is received from the base station after a predetermined number of PDCP SDUs have been transmitted over the WLAN.

14. A method for a user equipment, UE, device, the method comprising:

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

buffering the transmitted PDCP SDUs in a buffer;

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 cellular radio to determine a selected one of the PDCP SDUs to be discarded from the buffer, the LWA status report indicating whether the PDCP SDU was received; and

Discarding the selected PDCP SDU of the PDCP SDUs based on the LWA status report to mitigate hyper frame number HFN desynchronization associated with the uplink LWA traffic.

15. The method of claim 14, further comprising:

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

16. The method of claim 14, further comprising:

sequence numbers are included in the PDCP SDUs.

17. The method of claim 14, wherein the buffer is implemented as a first buffer for the WLAN radio and a second buffer for the cellular radio, and wherein the method further comprises:

maintaining a first discard timer for the first buffer;

maintaining a second discard timer for the second buffer; and

deleting the PDCP SDU from the first and second buffers based on the first and second discard timers, respectively.

18. The method of claim 14, wherein the LWA status report is received periodically from the base station.

19. The method of claim 14 wherein the LWA status report is received from the base station after a predetermined number of PDCP SDUs have been transmitted over the WLAN.