PRIORITY CLAIM

[0001] This application claims the benefit of priority to United States

Provisional Patent Application Serial No. 62/378,058, filed August 22, 2016, and entitled "ENHANCED LTE- WIRELESS LAN (WLAN) AGGREGATION USING AN END MARKER FOR HANDOVER WITHOUT WLAN

TERMINATION CHANGE," and United S tates Provisional Patent Application Serial No. 62/398,432, filed September 22, 2016, and entitled "PDCP KEY UPDATE USING END MARKER ON UL LINK," each of which is incorporated herein by reference in its entirety.

TECHNICAL FIELD

[00021 Embodiments pertain to radio access networks. Some embodiments relate to reference signal measurement in various cellular and wireless local area network (WLAN) networks, including Third Generation Partnership Project Long Term Evolution (3GPP LTE) networks and LTE advanced (LTE-A) networks as well as 4 ^th generation (4G) networks and 5 ^th generation (SG) networks. Some embodiments relate to handover of a user equipment (UE) LTE-WLAN Aggregation (LWA) UE, and in particular handover without a WLAN termination (WT) change.

BACKGROUND

[0003] The use of 3GPP LTE systems (including bom LTE and LTE-A systems) has increased due to both an increase in the types of devices user equipment (UEs) using network resources as well as the amount of data and bandwidth being used by various applications, such as video streaming, operating on these UEs. LTE networks typically operate in a number of radio frequency (RF) bands licensed to a wireless operator in which base stations (evolved Node Bs (eNBs)) and an increasing number and varying type of user equipment (UE) communicate.

[0004] Mobile connectivity is continually important is modem life. To this end, one goal mat networks strive for is to provide sufficient signal strength from the radio access network (RAN). Especially in cases in which the UE is moving rapidly or the density of eNBs is high, this may involve multiple handovers between eNBs within the RAN. Each handover involves a variety of control signals between the UE and the RAN and between the RAN and the evolved packet core (EPC). In particular, data destined for the source eNB is stored in the EPC during the process of handover and eventually rerouted to the new source eNB. The current process of data transfer, however, in some cases is problematic due to recent revisions of the 3GPP standard.

BRIEF DESCRIPTION OF THE FIGURES

[0005 ] In the figures, which are not necessarily drawn to scale, like numerals may describe similar components in different views. Like numerals having different letter suffixes may represent different instances of similar components. The figures illustrate generally, by way of example, but not by way of limitation, various embodiments discussed in the present document.

[0006] FIG. 1 shows an example of a portion of an end-to-end network architecture of aLTE network in accordance with some embodiments.

[0007 ] FIG. 2 illustrates components of a communication device in accordance with some embodiments.

[0008] FIG. 3 illustrates a block diagram of a communication device in accordance with some embodiments.

[0009] FIG. 4 illustrates another block diagram of a communication device in accordance with some embodiments.

[0010] FIG. 5 illustrates a LTE-WLAN aggregation adaption protocol

(LWAAP) packet data unit (PDU) in accordance with some embodiments.

[0011 ] FIGS. 6A-6C illustrate PDCP Control PDU formats in accordance with some embodiments.

[0012] FIG. 7 illustrates a PDU type in accordance with some embodiments. [0013| FIG. 8 illustrates a PDCP Data PDU format in accordance with some embodiments.

[0014] FIG. 9 illustrates a flow diagram of handover in accordance with some embodiments.

[0015] FIG. 10 illustrates another flow diagram of handover in accordance with some embodiments.

DETAILED DESCRIPTION

[0016] The following description and the drawings sufficiently illustrate specific embodiments to enable those skilled in the art to practice them Other embodiments may incorporate structural, logical, electrical, process, and other changes. Portions and features of some embodiments may be included in, or substituted for, those of other embodiments. Embodiments set forth in the claims encompass all available equivalents of those claims.

[0017] FIG. 1 shows an example of a portion of an end-to-end network architecture of a LTE network in accordance with some embodiments. As used herein, an LTE network refers to both LTE and LTE Advanced (LTE-A) networks as well as other versions of LTE networks to be developed. The network 100 may comprise a radio access network (RAN) (e.g., as depicted, the E-UTRAN or evolved universal terrestrial radio access network) 101 and core network 120 (e.g., shown as an evolved packet core (EPC)) coupled together through an SI interface 115. For convenience and brevity, only a portion of the core network 120, as well as the RAN 101, is shown in the example.

[0018] The core network 120 may include a mobility management entity (MME) 122, serving gateway (serving GW) 124, and packet data network gateway (PDN GW) 126. The RAN 101 may include evolved node Bs (eNBs) 104 (which may operate as base stations) for communicating with user equipment (UE) 102. The eNBs 104 may include macro eNBs 104a and low power (LP) eNBs 104b. Other elements, such as a Home Location Register (HLR)/Home Subscriber Server (HSS), a database including subscriber information of a 3GPP network that may perform configuration storage, identity management and user state storage, and a Policy and Charging Rule Function (PCRF) that performs policy decision for dynamically applying Quality of Service (QoS) and charging policy per service flow, are not shown for convenience.

[0019] The MME 122 may be similar in function to the control plane of legacy Serving GPRS Support Nodes (SGSN). The MME 122 may manage mobility aspects in access such as gateway selection and tracking area list management, performing both mobility management (MM) and session management (SM). The Non-Access Stratum (N AS) is a part of the control plane between a UE 102 and the MME 122. The NAS is used for signaling between the UE 102 and the EPC in the LTE/UMTS protocol stack. The NAS supports UE mobility and session management for establishing and maintaining an IP connection between the UE 102 and PDN GW 126.

[0020] The serving GW 124 may terminate the user plane interface toward the RAN 101, and route data packets between the RAN 101 and the core network 120. In addition, the serving GW 124 may be a local mobility anchor point for inter-eNB handovers and also may provide an anchor for inter-3GPP mobility. Other responsibilities may include lawful intercept, charging, and policy enforcement, packet routing, idle mode packet buffering, and triggering an MME to page a UE. The serving GW 124 and the MME 122 may be implemented in one physical node or separate physical nodes.

[0021] The PDN GW 126 may terminate a SGi interface toward the packet data network (PDN). The PDN GW 126 may route data packets between the EPC 120 and the external PDN, and may perform policy enforcement and charging data collection UE IP address assignment, packet screening and filtering. The PDN GW 126 may also provide an anchor point for mobility devices with a non-LTE access. The external PDN can be any kind of EP network, as well as an IP Multimedia Subsystem (IMS) domain. The PDN GW 126 and the serving GW 124 may be implemented in a single physical node or separate physical nodes.

[0022] The eNBs 104 (macro and micro) may terminate the air interface protocol and may be the first point of contact for a UE 102. In some embodiments, an eNB 104 may fulfill various logical functions for the RAN 101 including, but not limited to, RNC (radio network controller functions) such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management. In accordance with embodiments, UEs 102 may be configured to communicate orthogonal frequency division multiplexed (OFDM) communication signals with an eNB 104 over a multi carrier communication channel in accordance with an OFDMA communication technique. The OFDM signals may comprise a plurality of orthogonal subcarriers.

[0023J The S 1 interface 115 may be the interface that separates the RAN

101 and the EPC 120. It may be split into two parts: the Sl-U, which may carry traffic data between the eNBs 104 and the serving GW 124, and the Sl-MME, which may be a signaling interface between the eNBs 104 and the MME 122. The X2 interface may be the interface between eNBs 104. The X2 interface may comprise two parts, the X2-C and X2-U. The X2-C may be the control plane interface between the eNBs 104, while the X2-U may be the user plane interface between the eNBs 104.

[00241 With cellular networks, LP cells 104b may be typically used to extend coverage to indoor areas where outdoor signals do not reach well, or to add network capacity in areas with dense usage. In particular, it may be desirable to enhance the coverage of a wireless communication system using cells of different sizes, macrocells, microcells, picocells, and femtocells, to boost system performance. The cells of different sizes may operate on the same frequency band, or may operate on different frequency bands with each cell operating in a different frequency band or only cells of different sizes operating on different frequency bands. As used herein, the term LP eNB refers to any suitable relatively LP eNB for implementing a smaller cell (smaller than a macro ceU) such as a femtocell, apicocell, or amicrocell. Femtocell eNBs may be typically provided by a mobile network operator to its residential or enterprise customers. A femtocell may be typically the size of a residential gateway or smaller and generally connect to a broadband line. The femtocell may connect to the mobile operator's mobile network and provide extra coverage in a range of typically 30 to 50 meters. Thus, a LP eNB 104b might be a femtocell eNB. In some embodiments, when the LP eNB 104b is a Home eNB (HeNB), aHeNB Gateway may be provided between the HeNB and the MME/Service Gateway. This HeNB Gateway may control multiple HeNBs and provide user data and signal traffic from the HeNBs towards me MME/Service Gateway. Similarly, a picocell may be a wireless communication system typically covering a small area, such as in-building (offices, shopping malls, train stations, etc.), or more recently in-aircraft. A picocell eNB may generally connect through the X2 link to another eNB such as a macro eNB through its base station controller (BSC) functionality and/or connect via an S1 interface to an MME/Service Gateway. Thus, LP eNB may be implemented with a picocell eNB since it may be coupled to a macro eNB 104a via an X2 interface. Picocell eNBs or other LP eNBs LP eNB 104b may incorporate some or all functionality of a macro eNB LP eNB 104a In some cases, mis may be referred to as an access point base station or enterprise femtocell.

[0025] The UEs 102 may also be connected with a WLAN 106, which may include an access point (AP). The UEs 102 may thus support multiple Radio Access Technologies (RATs) for communications. The UEs 102 may use IEEE 802.11 protocols to communicate with the WLAN 106. The WLAN 106 may contain a WLAN termination (WT) 106a, a logical node in the WLAN 106 where the Xw interface between the eNB 104 and the WLAN 106 terminates. The WT 106a may be implemented at an access point (AP), access controller or another physical entity. The WLAN 106 may be connected with the eNBs 104 through an Xw interface over which both user and control plane data are communicated. The WLAN 106 also may be connected with the PDN gateway 126 through an evolved Packet Data Gateway (ePDG) or Trusted WLAN Access Gateway (TWAG) 108. As the eNB 104 is the anchor point for both the user and control plane, LTE/WiFi aggregation (LWA) using the WLAN 106 may only be possible when the UE is in the RRC connected state.

[0026] Data plane aggregation may occur at a packet data convergence protocol (PDCP) layer at the eNB 104 and UE 102. The eNB 104 may send a downlink PDCP packet data unit (PDU) over either LTE or WiFi. The eNB 104 may schedule uplink LTE data transmissions and uplink WLAN data transmissions may be initiated by the UE 102. For uplink WLAN transmissions, the UE 102 (or AP to which the UE 102 is connected) may encapsulate the PDCP PDU in a WiFi MAC packet to be transmitted over WiFi. For downlink WLAN transmissions, a WiFi station in the UE 102 may forward the received WiFi packet payload to the UE PDCP layer, using an identifier to specify Ihe presence of an LTE payload.

[0027] FIG. 2 illustrates components of a communication device in accordance with some embodiments. The communication device 200 may be a UE, eNB or other network component as described herein. The communication device 200 may be a stationary, non-mobile device or may be a mobile device. In some embodiments, Ihe UE 200 may include application circuitry 202, baseband circuitry 204, Radio Frequency (RF) circuitry 206, front-end module (FEM) circuitry 208 and one or more antennas 210, coupled together at least as shown. At least some of the baseband circuitry 204, RF circuitry 206, and FEM circuitry 208 may form a transceiver. In some embodiments, other network elements, such as the MME may contain some or all of the components shown in FIG. 2.

[0028] The application or processing circuitry 202 may include one or more application processors. For example, the application circuitry 202 may include circuitry such as, but not limited to, one or more single-core or multi- core processors. The processor(s) may include any combination of general- purpose processors and dedicated processors (e.g., graphics processors, application processors, etc.). The processors may be coupled with and/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 system.

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

encoding/decoding, radio frequency shifting, etc. In some embodiments, modulation/demodulation circuitry of the baseband circuitry 204 may include FFT, precoding, and/or constellation mapping/ demapping functionality. In some embodiments, encoding/de∞ding circuitry of the baseband circuitry 204 may include convolution, tail-biting convolution, turbo, Viterbi, and/or Low Density Parity Check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functionality are not limited to these examples and may include other suitable functionality in other embodiments.

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

[0031] In some embodiments, the baseband circuitry 204 may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 204 may support communication with an EUTRAN and/or other wireless metropolitan area networks (WMAN), a wireless local area network (WLAN), a wireless personal area network (WPAN). Embodiments in which the baseband circuitry 204 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry. In some embodiments, the device can be configured to operate in accordance with communication standards or other protocols or standards, including Institute of Electrical and Electronic Engineers (IEEE) 802.16 wireless technology (WiMax), IEEE 802.11 wireless technology (WiFi) including IEEE 802.11 ad, which operates in the 60 GHz millimeter wave spectrum, various other wireless technologies such as global system for mobile communications (GSM), enhanced data rates for GSM evolution (EDGE), GSM EDGE radio access network (GERAN), universal mobile telecommunications system (UMTS), UMTS terrestrial radio access network (UTRAN), or other 2G, 3G, 4G, SG, etc. technologies either already developed or to be developed.

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

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

[0034] In some embodiments, the mixer circuitry 206a of the transmit signal path may be configured to up-con vert input baseband signals based on the synthesized frequency provided by the synthesizer circuitiy 206d to generate RF output signals for the FEM circuitry 208. The baseband signals may be provided by the baseband circuitry 204 and may be filtered by filter circuitry 206c. The filter circuitry 206c may include a low-pass filter (LPF), although the scope of the embodiments is not limited in this respect

[0035] In some embodiments, the mixer circuitry 206a of the receive signal path and the mixer circuitry 206a of the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion and/or upcon version respectively. In some embodiments, the mixer circuitry 206a of the receive signal path and the mixer circuitry 206a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g.,

Hartley image rejection). In some embodiments, the mixer circuitry 206a of the receive signal path and the mixer circuitry 206a may be arranged for direct downconversion and/or direct upconversion, respectively. In some embodiments, the mixer circuitry 206a of the receive signal path and the mixer circuitry 206a of the transmit signal path may be configured for super-heterodyne operation.

[0036] In some embodiments, the output baseband signals and the input baseband signals may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternate embodiments, the output baseband signals and the input baseband signals may be digital baseband signals. In these alternate embodiments, the RF circuitry 206 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 204 may include a digital baseband interface to communicate with the RF circuitry 206.

[0037] In some dual-mode embodiments, a separate radio IC circuitry may be provided for processing signals for each spectrum, although the scope of the embodiments is not limited in this respect

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

[0039] The synthesizer circuitry 206d may be configured to synthesize an output frequency for use by the mixer circuitry 206a of the RF circuitry 206 based on a frequency input and a divider control input In some embodiments, the synthesizer circuitry 206d may be a fractional N/N+1 synthesizer.

[0040] In some embodiments, frequency input may be provided by a voltage controlled oscillator (V CO), although that is not a requirement Divider control input may be provided by either the baseband circuitry 204 or the applications processor 202 depending on the desired output frequency. In some embodiments, a divider control input (e.g., N) may be determined from a lookup table based on a channel indicated by the applications processor 202.

[0041] Synthesizer circuitry 206d of the RF circuitry 206 may include a divider, a delay-locked loop (DLL), a multiplexer and a phase accumulator. In some embodiments, the divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DP A). In some embodiments, the DMD may be configured to divide the input signal by either N or N+1 (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these embodiments, the delay elements may be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

[0042] In some embodiments, synthesizer circuitry 206d may be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some embodiments, the output frequency may be a LO frequency (fLo). In some embodiments, the RF circuitry 206 may include an IQ/polar converter.

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

[0044] In some embodiments, the FEM circuitry 208 may include a

TX/RX switch to switch between transmit mode and receive mode operation. The FEM circuitry may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry may include a low-noise amplifier (LNA) to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry 206). The transmit signal path of the FEM circuitry 208 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry 206), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 210.

[0045] In some embodiments, the communication device 200 may include additional elements such as, for example, memory/storage, display, camera, sensor, and/or input/output (I/O) interface as described in more detail below. In some embodiments, the communication device 200 described herein may be part of a portable wireless communication device, such as a personal digital assistant (PDA), a laptop or portable computer with wireless

communication capability, a web tablet, a wireless telephone, a smartphone, a wireless headset, a pager, an instant messaging device, a digital camera, an access point, a television, a medical device (e.g., a heart rate monitor, a blood pressure monitor, etc.), or other device that may receive and/or transmit information wirelessly. In some embodiments, the communication device 200 may include one or more user interfaces designed to enable user interaction with the system and/or peripheral component interfaces designed to enable peripheral component interaction with the system. For example, the communication device 200 may include one or more of a keyboard, a keypad, a touchpad, a display, a sensor, a non-volatile memory port, a universal serial bus (USB) port, an audio jack, a power supply interface, one or more antennas, a graphics processor, an application processor, a speaker, a microphone, and other I/O components. The display may be an LCD or LED screen including a touch screen. The sensor may include a gyro sensor, an accelerometer, a proximity sensor, an ambient light sensor, and a positioning unit The positioning unit may communicate with components of a positioning network, e.g., a global positioning system (GPS) satellite.

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

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

[0048] Embodiments may be implemented in one or a combination of hardware, firmware and software. Embodiments may also be implemented as instructions stored on a computer-readable storage device, which may be read and executed by at least one processor to perform the operations described herein. A computer-readable storage device may include any non-transitory mechanism for storing information in a form readable by a machine (e.g., a computer). For example, a computer-readable storage device may include readonly memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, and other storage devices and media Some embodiments may include one or more processors and may be configured with instructions stored on a computer-readable storage device.

[0049] FIG. 3 is a block diagram of a communication device in accordance with some embodiments. The device may be a UE, for example, such as the UE shown in FIG. 1. The physical layer circuitry 302 may perform various encoding and decoding functions that may include formation of baseband signals for transmission and decoding of received signals. The communication device 300 may also include medium access control layer (MAC) circuitry 304 for controlling access to the wireless medium. The communication device 300 may also include processing circuitry 306, such as one or more single-core or multi-core processors, and memory 308 arranged to perform the operations described herein. The physical layer circuitry 302, MAC circuitry 304 and processing circuitry 306 may handle various radio control functions that enable communication with one or more radio networks compatible with one or more radio technologies. The communication device 300 may include packet data convergence protocol (PDCP) and radio link control (RLC) circuitry in the physical layer circuitry 302 or another entity. The radio control functions may include signal modulation, encoding, decoding, radio frequency shifting, etc. For example, similar to the device shown in FIG. 2, in some embodiments, communication may be enabled with one or more of a WMAN, a WLAN, and a WPAN. In some embodiments, the communication device 300 can be configured to operate in accordance with 3GPP standards or other protocols or standards, including WiMax, WiFi, WiGig, GSM, EDGE, GERAN, UMTS, UTRAN, or other 3G, 3G, 4G, SG, etc. technologies erther already developed or to be developed. The communication device 300 may include transceiver circuitry 312 to enable communication with other external devices wirelessly and interfaces 314 to enable wired communication with other external devices. As another example, the transceiver circuitry 312 may perform various transmission and reception functions such as conversion of signals between a baseband range and a Radio Frequency (RF) range.

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

[0051] Although the communication device 300 is illustrated as having several separate functional elements, one or more of the functional elements may be combined and may be implemented by combinations of software-configured elements, such as processing elements including DSPs, and/or other hardware elements. For example, some elements may comprise one or more

microprocessors, DSPs, FPGAs, ASICs, RFICs and combinations of various hardware and logic circuitry for performing at least the functions described herein. In some embodiments, the functional elements may refer to one or more processes operating on one or more processing elements. Embodiments may be implemented in one or a combination of hardware, firmware and software. Embodiments may also be implemented as instructions stored on a computer- readable storage device, which may be read and executed by at least one processor to perform the operations described herein.

[0052] FIG. 4 illustrates another block diagram of a communication device in accordance with some embodiments. In alternative embodiments, the communication device 400 may operate as a standalone device or may be connected (e.g., networked) to other communication devices. In a networked deployment, ifae communication device 400 may operate in the capacity of a server communication device, a client communication device, or both in server- client network environments. In an example, the communication device 400 may act as a peer communication device in peer-to-peer (P2P) (or other distributed) network environment The communication device 400 may be a UE, eNB, PC, a tablet PC, a STB, a PDA, a mobile telephone, a smart phone, a web appliance, a network router, switch or bridge, or any communication device capable of executing instructions (sequential or otherwise) that specify actions to be taken by mat communication device. Further, while only a single communication device is illustrated, the term "communication device" shall also be taken to include any collection of communication devices mat individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein, such as cloud computing, software as a service (SaaS), other computer cluster configurations.

[00531 Examples, as described herein, may include, or may operate on, logic or a number of components, modules, or mechanisms. Modules are tangible entities (e.g., hardware) capable of performing specified operations and may be configured or arranged in a certain manner. In an example, circuits may be arranged (e.g., internally or with respect to external entities such as other circuits) in a specified manner as a module. In an example, the whole or part of one or more computer systems (e.g., a standalone, client or server computer system) or one or more hardware processors may be configured by firmware or software (e.g., instructions, an application portion, or an application) as a module that operates to perform specified operations. In an example, the software may reside on a communication device readable medium In an example, the software, when executed by the underlying hardware of the module, causes the hardware to perform the specified operations.

[0054] Accordingly, the term "module" is understood to encompass a tangible entity, be that an entity that is physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., transitorily) configured (e.g., programmed) to operate in a specified manner or to perform part or all of any operation described herein. Considering examples in which modules are temporarily configured, each of the modules need not be instantiated at any one moment in time. For example, where the modules comprise a general-purpose hardware processor configured using software, the general -purpose hardware processor may be configured as respective different modules at different times. Software may accordingly configure a hardware processor, for example, to constitute a particular module at one instance of time and to constitute a different module at a different instance of time.

[0055] Communication device (e.g., computer system) 400 may include a hardware processor 402 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), a main memory 404 and a static memory 406, some or all of which may communicate with each other via an interlink (e.g., bus) 408. The

communication device 400 may further include a display unit 410, an alphanumeric input device 412 (e.g., a keyboard), and a user interface (UI) navigation device 414 (e.g., a mouse). In an example, the display unit 410, input device 412 and UI navigation device 414 may be a touch screen display. The communication device 400 may additionally include a storage device (e.g., drive unit) 416, a signal generation device 418 (e.g., a speaker), a network interface device 420, and one or more sensors 421, such as a global positioning system (GPS) sensor, compass, accelerometer, or other sensor. The communication device 400 may include an output controller 428, such as a serial (e.g. , universal serial bus (USB), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate or control one or more peripheral devices (e.g., a printer, card reader, etc.).

[0056] The storage device 416 may include a communication device readable medium 422 on which is stored one or more sets of data structures or instructions 424 (e.g., software) embodying or utilized by any one or more of the techniques or functions described herein. The instructions 424 may also reside, completely or at least partially, within the main memory 404, within static memory 406, or within the hardware processor 402 during execution thereof by the communication device 400. In an example, one or any combination of the hardware processor 402, the main memory 404, the static memory 406, or the storage device 416 may constitute communication device readable media. [00S7| While Ihe communication device readable medium 422 is illustrated as a single medium, the term "communication device readable medium" may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) configured to store the one or more instructions 424.

[0058] The term "communication device readable medium" may include any medium that is capable of storing, encoding, or carrying instructions for execution by me communication device 400 and that cause the communication device 400 to perform any one or more of Ihe techniques of Ihe present disclosure, or that is capable of storing, encoding or carrying data structures used by or associated with such instructions. Non-limiting communication device readable medium examples may include solid-state memories, and optical and magnetic media. Specific examples of communication device readable media may include: non-volatile memory, such as semiconductor memory devices (e.g., Electrically Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM)) and flash memory devices; magnetic disks, such as internal hard disks and removable disks;

magneto-optical disks; Random Access Memory (RAM); and CD-ROM and DVD-ROM disks. In some examples, communication device readable media may include non-transitory communication device readable media In some examples, commumcation device readable media may include communication device readable media that is not a transitory propagating signal.

[0059 ] The instructions 424 may further be transmitted or received over a communications network 426 using a transmission medium via the network interface device 420 utilizing any one of a number of transfer protocols (e.g., frame relay, internet protocol (IF), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc.). Example commumcation networks may include a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), mobile telephone networks (e.g., cellular networks), Plain Old Telephone (POTS) networks, and wireless data networks (e g., IEEE 802.11 family of standards known as WiFi®, IEEE 802.16 family of standards known as WiMax®), IEEE 802.1S.4 family of standards, a LTE family of standards, a UMTS family of standards, peer-to-peer (P2P) networks, among others. In an example, the network interface device 420 may include one or more physical jacks (e.g., Ethernet, coaxial, or phone jacks) or one or more antennas to connect to the communications network 426. In an example, the network interface device 420 may include a plurality of antennas to wirelessly communicate using at least one of single-input multiple-output (SIMO), MIMO, or multiple-input single-output (MISO) techniques. In some examples, the network interface device 420 may wirelessly communicate using Multiple User MIMO techniques. The term "transmission medium" shall be taken to include any intangible medium that is capable of storing, encoding or carrying instructions for execution by the communication device 400, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software.

[0060] As above, Release 14 of the 3GPP LTE specification introduced changes to the handover process, the handover may be an inter- or intra- E- UTRAN handover. Independent of whether the handover is intra- or internetwork, the handover process may take a number of operations and it may overall take a significant amount of time to complete the operations involved in the handover process. These operations may include, for example, the UE measuring signal and/or channel qualities of reference signals transmitted by the source eNB. The UE may subsequently transmit a report to the source eNB. The report may include, for example, Reference Signal Received Power (RSRP), Reference Signal Received Quality (RSRQ), signal-to-noise ratio measurements (SINR), signal-to-interference ratio measurements (SIR), error rate, etc.

[0061 ] In general, the source eNB may determine from the report whether to initiate a handover. If handover is to occur, the source eNB may determine a target eNB and send a handover request containing UE information to the target eNB. The handover request may contain the LWA configuration for the UE. The source eNB may in response receive an acknowledgement from the target eNB, once the target eNB accepts the handover request. The target eNB may send a WT addition request to the WT to indicate that the target eNB is to be associated with the UE. The WT may reply to the target eNB with a WT addition request ACK. [00621 The source eNB may then send allocation and reconfiguration information to the UE and instruct the UE to perform handover to the target eNB via a handover command. The reconfiguration information may be sent in a RRC Connection Reconfiguration message that includes the handover command (i.e. MobililyControllnfo). The source eNB may send a Sequence Number (SN) transfer message to the target eNB to convey uplink/downlink PDCP sequence number receiver/transmitter status of at least some radio access bearers. The source eNB may also start forwarding data for the UE to the target eNB.

[00fi3] After reception of the RRC Connection Reconfiguration message, the UE may subsequently detach from the source eNB and attach to (synchronize to and access) the target eNB using a random access channel (RACH). The target eNB may, upon receiving a RACH preamble from the UE, subsequently transmit allocation and timing information to the UE. The UE may transmit via a RRCConnectionReconfigurationComplete message confirmation that the reconfiguration is complete prior to the UE sending data to the target eNB.

[0064] Once the target eNB determines that the UE is able to

communicate, the target eNB may transmit a switch message to the MME to indicate that the eNB serving the UE has changed. The MME may in response send an update request to the serving gateway to update the user plane, which the serving gateway may use to switch the downlink path from the source eNB to the target eNB. The serving gateway may also send one or more end marker packets to the source eNB before releasing the user plane resources of the UE that are associated with the source eNB and before sending a response to the update request to the MME. The source eNB may supply the end marker to the target UE. The MME may subsequently confirm the update to the target eNB in a response to the switch message, which then may confirm this information with the source eNB through a UE context release message. The source eNB may then release user and control plane related resources associated to the UE context.

[00651 Thus, identification, address, channel, signal strength, security,

Quality of Service (QoS) and other information may be communicated from the UE to the source and/or target eNB to enable the target eNB to select the appropriate channel to use in communications with the UE. After the information is communicated, a communication link between the UE and target eNB may be established and subsequently, the existing communication link between the UE and the source eNB may be torn down.

[0066] In some situations, for example, handover involving micro (or smaller) eNBs, the WLAN that the UE is connected to may remain the same, whether or not the AP changes. Release 14 of the 3GPP LTE specification permits continued data reception and transmission at the UE from/towards the WT during handover if the target eNB is able to accept the same WT

configuration as used by the source eNB. This is entirely different from previous releases, in which the WT is associated with the UE and a single eNB, thus the source eNB would first release the LWA configuration for the UE and the target eNB would then reconfigure the LWA for the UE after the handover is complete; that is, the UE would first deassociate from the WT and subsequently reassocdate with the same or a different WT for communication. However, when the LWA configuration and the WT are retained during handover, as permitted for example in 3GPP Release 14 and onwards, encryption and decryption of the data when using the WLAN remains problematic due to the timing of the PDCP key used by the UE due to the changing of eNBs (and thus the PDCP dphering/deciphering keys). Although the key update at the UE can be delayed after the handover is completed, which allows the UEto remain associated to the same WT after the handover, a problem can arise related to the PDCP key update during handover as the WT may be unaware of the timing when the UE is able to communicate with the target eNB.

[0067] As indicated above, in some embodiments, data transmission from the source eNB may be stopped when the handover command from the source eNB is transmitted to (or acknowledged by) the UE. This is to say that for handover without a WT change, PDCP packets from the WT to the UE may be sent from the source eNB and thus encrypted using the source eNB KeNB until the source eNB sends the handover command to the UE. In other embodiments, this termination of data from the source eNB may not occur until later, e.g., after the handover procedure is completed.

[0068] In some embodiments, upon receiving the handover command, which contains the PDCP key for the target eNB, the UE may update the uplink PDCP key from the source eNB key to me target eNB key and start using the target eNB key (KCNB) for uplink transmissions. The PDCP packets from either or both the source or target eNB may be buffered in the WT, for exampl e, and forwarded to the UE when indicated by the UE or target eNB. Since WT has no knowledge of when UE receives the handover command, the source eNB PDCP packets may be sent from the WT to the UE after the UE has switched to the target eNB KeNB. Unfortunately, in some circumstances this means that the UE may be unable to decrypt the source eNB PDCP packets from the WT.

[0069] Various embodiments herein may permit the UE to be able to decrypt PDCP packets encrypted with the source eNB KeNB and that are buffered in the WT during handover. In some embodiments, a LWA end-marker may be introduced to indicate the end of PDCP packets encrypted by the source eNB KeNB. Thus, any PDCP packets received after the PDCP packet containing the LWA end-marker may be determined to be from the target eNB rather than the source eNB. Additionally or alternatively, the end-marker packet may include the last SN (LSN) of the PDCP packet encrypted using source eNB key. Thus, the PDCP packet containing the LWA end-marker may be from either the source or target eNB, depending on the embodiment.

[0070] As above, when the source eNB sends the handover command to the UE, the source eNB may stop PDCP data encryption using the source eNB key. The source eNB may instead forward data to the target eNB from that point on, for transmission of the data to the UE through the WT. Before the data is forwarded, however, the source eNB may send a LWA end-marker to the UE, which may be inspected by the WT, to indicate the end of data transmission from the source eNB. In some embodiments, the LWA end-marker may in addition or instead indicate the start of the data transmission from the target eNB. The PCDP packet and LWA end-marker may be inspected by theWT before passing the PCDP packet to the UE.

[00711 In some circumstances, the WT may receive LWA AP PDUs for the UE from the target eNB prior to reception of the LWA end-marker from the source eNB. This may occur when the backhaul delay from the source eNB to the WT is longer than the delay from the target eNB to the WT. In this case, the WT may start getting data from target eNB before all the packets from the source eNB have arrived at the WT. When this occurs, the WT may buffer the LWA PDUs received from the target eNB until reception of the LWA end- marker from the source eNB.

[0072] Upon reception of the LWA end-marker from the source eNB, the WT may forward the LWA end-marker to the UE. The UE may then use the LWA end-marker to identify when the packets encrypted by source eNB key end, such that the UE can update the PDCP key accordingly. The UE may in some embodiments thus use the LWA end-marker to determine which key to use to decrypt the packets received from the WT. Depending on the content of the LWA end-marker, the UE actions may be different as described later. In some embodiments, the WT may flush the source eNB packet in response to reception of the LWA end-marker. In such embodiments, the WT may only forward target eNB packets to the UE after the LWA end-marker is received; that is, only source eNB packets may be forwarded to the UE before the LWA end-marker is received by the WT.

[0073] Rather than reception of an LWA end-marker, the WT may receive a direct or indirect indication of handover or key update from the UE. In some embodiments, a UE may indicate the key update to the WT. The UE may determine the key update after receiving the handover command from the source eNB. In one embodiment, the UE may supply the indication directly to the WT in response to a determination of the key update. After the WT receives the indication from the UE, the WT may flush all source eNB packets and only forward target eNB packets to the UE.

[0074] In another embodiment, the target eNB may receive the indication from the UE and forward the indication to the WT. The WT, after receiving the indication from the target eNB, may flush all the packets from source eNB and only forward the packets from target eNB to the UE.

[0075] In another embodiment, when the key change is received at the

UE, the UE may send a PDCP status report or LWA status report to the target eNB. The target eNB may, in response to reception of the report, transmit a message to the WT. The message may specify to the WT which packers) to transmit and/or which packers) to flush. In some embodiments, the

transmission of the report may automatically indicate which packet(s) to transmit and/or winch packers) to flush. Alternatively or additionally, the target eNB may, in response to reception of the report, decide which packers) to retransmit and/or which packers) to flush.

[0076] FIG. 5 illustrates a LTE-WLAN aggregation adaption protocol (LWAAP) packet data unit (PDU) in accordance with some embodiments. The LWAAP PDU 500 contains multiple octets, of which the first octet is an LWAAP header 502 that contains control information, and the remaining, variable number of octets contain a LWAAP service data unit (SDU) 510 in a data field. The LWAAP header 502 may contain 3 reserved bits 504 and a 5 bit Data Radio Bearer ID (DRBID) field 506. The DRBID field 506 may indicate the RRC configured DRB identity to which the corresponding LWAAP SDU 510 belongs. In some embodiments, one of the legacy reserve bits 504 may be used to indicate the LWA end-marker. In some embodiments, the LWA end- marker may be added to the LWAAP header 502.

[0077] In some embodiments, one of the reserved bits 504 may be used to indicate that the payload (LWAAP SDU 510) corresponds to the last packet from the source eNB. In some embodiments, the last packet may correspond to the PDCP packet with the highest PDCP COUNT corresponding to the PDCP sequence number (SN) of the packets from the source eNB.

[0078] In other embodiments, one of the reserved bits 504 can be used to indicate that the payload 510 corresponds to the first packet from the target eNB. Similar to the above, in some embodiments, the first packet may correspond to the PDCP packet with the smallest PDCP COUNT corresponding to the PDCP SN of the packets from the target eNB.

[0079] In some embodiments, a LWAAP data PDU 500 that contains an

LWA end-marker may be identified using one of the reserved bits, as above. However, the LWAAP data PDU 500 may have no payload in the data field 510.

[0080] In some embodiments, a new LWAAP PDU type may be introduced to indicate the LWA end-marker. In such embodiments, the LWA end-marker identification can be the payload of the LWAAP data PDU 500. In various embodiments, the LWA end-marker payload may contain the PDCP SN of the last PDCP packet or the PDCP COUNT of the last PDCP packet encrypted by the source eNB using source eNB key. Note that in some embodiments, while me PDCP packet may encrypted, the PDCP SN and PDCP COUNT may not be encrypted. Similarly, the LWA end-marker payload may contain the PDCP SN of the first PDCP packet or the PDCP COUNT of the first PDCP packet encrypted by the target eNB using target eNB key. In other embodiments, the LWA end-marker may be a different PDU type without any payload.

[0081] FIGS. 6A-C illustrates PDU Control PDU formats in accordance with some embodiments. In particular, FIG. 6A illustrates a PDU Control PDU format 610 for LWA end-marker packet using a 12 bit SN in accordance with some embodiments; FIG. 6B illustrates a PDU Control PDU format 620 for LWA end-marker packet using a IS bit SN in accordance with some embodiments; and FIG. 6C illustrates a PDU Control PDU format 620 for LWA end-marker packet using a 18 bit SN in accordance with some embodiments.

[0082] Each of the PDU Control PDU format 610, 620, 630 may contain a single D/C bit 612 that indicates whether the PDU is a data or control PDU, PDU type bits 614 that indicate the payload of the PDU and a last SN (LSN) 616. The PDU Control PDU format 610, 620, 630 may be two or three octets in length, depending on the embodiment In addition, at least one of me PDU Control PDU format 610, 620, 630 may also contain additional reserve bits 628 used to provide additional information or merely to pad the octets.

[0083] The PDCP Control PDU may be used to convey several pieces of information. In some embodiments, the PDCP Control PDU may contain a PDCP status report indicating which PDCP SDUs are missing and which are not following a PDCP re-establishment. The PDCP Control PDU may contain header compression control information, e.g. interspersed Robust Header

Compression (ROHC) feedback. The PDCP Control PDU may further contain a LWA status report and/or a LWA end-marker packet, as discussed below.

[0084] FIG. 7 illustrates a new PDU type in accordance with some embodiments. In some embodiments, a new PDCP PDU type 700 may be created for the LWA end-marker. The PDCP PDU type 700 may be 3 bits in length in some embodiments, as shown in FIGS. 6A-6C. As shown, several values of the PDU type identify particular payloads, while others are reserved. The payloads may include a PDCP status report (value 000), Interspersed ROHC feedback packet (value 001), LWA status report (value 010) or LWA end- marker packet (value Oi l). In some embodiments, the remaining values (as shown, from 100-111) may be reserved. The LWA end-marker identification may be the payload of the PDCP PDU associated with me PDCP PDU type 700. As above, in various embodiments, the LWA end-marker payload may contain the PDCP SN of the last PDCP packet from/to source eNB or the PDCP COUNT of the last PDCP packet encrypted by the source eNB using source eNB key. Similarly, the LWA end-marker payload may contain the PDCP SN of the first PDCP packet or the PDCP COUNT of the first PDCP packet encrypted by the target eNB using target eNB key. Alternatively, the payload may be empty and the presence of the PDU type itself may indicate the LWA end-marker.

[0085] FIG. 8 illustrates a PDCP Data PDU in accordance with some embodiments. The PDCP Data PDU 800 contains multiple octets that include a PDCP header 802 and a variable number of octets contain a PDCP SDU 810 in a data field. As above, the PDCP header 802 may contain 3 reserved bits 804. However, an initial bit 808 before the reserved bits 804 may indicate whether the PDCP PDU is a control or PDCP data PDU. A PDCP SN 806 may follow the reserved bits 804. As shown, a 12 bit PDCP SN 806 may be used in the PDCP data PDU 800.

[0086] In the PDCP data PDU 800, a single bit of the reserved bits 804 may be used in the PDCP header 802 to indicate that the PDCP data PDU 800 contains or otherwise indicates an LWA end-marker in the PDCP data packet For example, one of the reserved bits 804 can be used to indicate mat the payload 810 corresponds to the last packet from the source eNB. The last packet may correspond to the PDCP packet with the highest PDCP COUNT

corresponding to the PDCP SN of the packets from the source eNB.

Alternatively, one of the reserved bits 804 can be used to indicate that the payload 810 corresponds to the first packet from the target eNB. The first packet may correspond to the PDCP packet with the smallest PDCP COUNT corresponding to the PDCP SN of the packets from the target eNB. As above, the PDCP data PDU with LWA end-marker may be identified using one of the reserved bits but may have no payload. [0087| Whether a new PDCP PDU type is used or a reserved bit of the

PDCP data PDU is used, the WT may inspect the PDCP data PDU to find out if the PDCP PDU is the LWA end-marker. The WT may thus decode the PDCP data PDU type, reserved bit, or payload to make the determination.

[0088] In other embodiments, rather than a direct indication from the UE to the WT, the LWA end-marker can also be sent indirectly to the WT via Xw- AP signaling (using the Xw interface). The source eNB can send an LWA end- marker signal directly to the WT to indicate the handover command was sent to the UE. All other WT and UE behavior may be the same as indicated above.

[0089] Turning to the actions of the UE rather than the WT, different embodiments may produce different actions from the UE. For example, the UE actions may vary depending on the content of the LWA end-marker. In some embodiments, the UE may continue to use the source eNB key to decrypt the PDCP packets for which the PDCP COUNT is below or equal to the COUNT corresponding to the PDCP SN indicated by the LWA end-marker. The UE may switch to using the target eNB key for the PDCP packets with a COUNT value that is larger than the COUNT value corresponding to the PDCP SN indicated in the LWA end-marker. In other emboo^iments, in which the LWA end-marker may indicate the PDCP COUNT of the last PDCP packet encrypted using the source eNB key, the UE may continue to use the source eNB key to decrypt the PDCP packets for which the PDCP COUNT is below or equal to the PDCP COUNT indicated by the LWA end-marker. The UE may switch to using the target eNB key for the PDCP packets with a PDCP COUNT value higher than the COUNT value indicated in the LWA end-marker.

[0090] In some embodiments, the UE may continue to use the source eNB PDCP key to decrypt the packets until the UE receives the LWA end- marker. After receiving the LWA end-marker, the UE may switch to using the target eNB key.

[0091] FIG. 9 illustrates a flow diagram of handover in accordance with some embodiments. This handover process may be similar to that provided above. As shown, the UE 902 may initially use the source eNB PDCP key for both UL and DL communications. At operation 1, the source eNB 904 may initiate handover by transmitting a handover request containing LWA configuration for the UE 902902 to the target eNB 908.

[0092] The target eNB 908, having received the handover request, may send a WT addition request to the WT 906 at operation 2. The WT 906 may reply to the target eNB 908 with a WT addition request ACK at operation 3. Having received the WT addition request ACK, at operation 4 the target eNB 908 may send a handover request ACK with the LWA configuration to the source eNB 904.

[0093] At this point, the downlink data flow still proceeds through from the S-GW 910 to the source eNB 904. The downlink data proceeds from the source eNB 904 to the WT 906. Then, the data proceeds from the WT 906 ultimately to the UE 902. The uplink data flow conversely from the UE 902 to the WT 910. The uplink data proceeds from the WT 906 to the source eNB 904. Then, the uplink data proceeds from the source eNB 904 to the S-GW 910. At this point, the source eNB 904 may send to the UE 902 at operation 5 a RRC Connection Reconfiguration message mstructing the UE 902 to perform handover. The RRCConnectionReconfiguration message may include the LWA information, as well as mobility information (handover command) and the target eNB key.

[0094] The source eNB 902 may, in communicating with the WT 910, transmit a last packet before transition to the target eNB 908. The last packet may contain an LWA end-marker. The source eNB 904 may thereafter stop data transmission to the WT 910. The WT 910 may also forward the LWA end- marker to the UE 902. The WT 910 thus may forward all packets to the UE 902 from the source eNB 904 until receiving the LWA end-marker, after which the WT 910 may start forwarding packets from the target eNB 908. Any packet received from the source eNB 904 after the LWA end-marker has been received may be flushed by the WT 910.

[0095 ] The UE 902 may transmit to the WT 906 a last packet, which may shuttle the packet to the S-GW 910 through the source eNB 904. The UE 902 may transmit to the WT 906 packets encrypted using the source eNB PDCP key until the LWA end-marker is received, after which the UE 902 may transmit to the WT 906 packets encrypted using the target eNB PDCP key. In some embodiments, the UE 902 may send the LAVA end-marker to the WT 906. In oilier embodiments, the UE 902 may switch from using the source eNB PDCP key to using the target eNB PDCP key after the RRCConnectionReconfiguration message is transmitted.

[0096] The source eNB 904 may at operation 6 send a SN status transfer message to the target eNB 908 to convey the PDCP sequence number for both uplink and downlink communications. The UE 902 may also start transmitting data to the WT 906 for the target eNB 908. The WT 906 may buffer the data for the target eNB 908 or may immediately transmit the data to the target eNB 908, where the data is buffered.

[0097] After reception of the RRC Connection Reconfiguration message, the UE 902 may subsequently synchronize to and access the target eNB 908 using a random access channel (RACH) at operation 8. The synchronization may include obtaining system information and timing advance for the target eNB 908.

[0098] Once me UE 902 has obtained the system information and synchronized to the target eNB 908 using the RACH procedure, the UE 902 may indicate completion to the target eNB 908. The target eNB 908 may convey this information at operation 9 via a RRCConnecticiiRecciifigurationComplete message confirmation transmitted to the target eNB 908 that the reconfiguration is complete prior to the UE 902 sending data to the target eNB 908.

[00991 Once me target eNB 908 determines that the UE 902 is able to communicate with the target eNB 908 (e.g., based on reception of the

RRCConnectionReconfigurationComplete), the target eNB 908 may transmit a path switch request to the MME 912 at operation 10. The path switch request may indicate that the eNB serving the UE 902 has changed from the source eNB 910 to the target eNB 908 and that the radio bearers for the UE 902 should be updated. The path switch request may contain identification of the UE 902 and the target eNB 908.

[00100] The MME 912 may, in response to reception of the path switch request, send an update request to the S-GW 910 at operation 10. The update request may indicate to the S-GW 910 to update the EPS (user and control plane) bearers by switching the paths from the source eNB 904 to the target eNB 908, e.g., releasing the bearers between the source eNB 904 and the UE 902 and building bearers between the target eNB 908 and the UE 902.

[00101] Although not shown, the S-GW 910 may also send one or more end marker packets to the source eNB 904 before releasing the user/control plane resources of the UE 902 that are associated with the source eNB 904 and before sending a response to the update request to the MME 912. After the response has been received by the MME 912, the MME 912 may in turn transmit to the target eNB 908 an ACK to the path switch request at operation 11.

[00102] The target eNB 908 may at operation 12 transmit a UE context release message to the source eNB 904. The UE context release message may allow the source eNB 904 to release the EPS bearers for the UE 902. The target eNB 908 may also transmit the buffered data from the UE 902 to the S-GW 910. Downlink data may also begin to flow from the S-GW 910 to the UE 902 through the target eNB 908 and then WT 906.

[00103] FIG. 10 illustrates another flow diagram of handover in accordance with some embodiments. In a number of respects, the method shown in FIG. 10 is similar to that of FIG. 9. That is, the UE 1002 communicates with the source eNB 1004 and the target eNB 1008 directly and through the WT 1006. The MME 1012 coordinates switching of the EPS bearers of the S-GW 1010 so that uplink and downlink data associated with the UE 1002 is routed through the appropriate eNB.

[00104] However, several differences also exist In particular, operations 8 and 9 occur prior to operation 6. That is the RACH procedure and

RRCConnectionReconfigurationComplete between the UE 1002 and the target eNB 1008 occurs before the LWA end-marker is received by the UE 1002. The source eNB 1004 continues to use the WT 1006 to forward data from the S-GW 1010 to the UE 1002 until the UE 1002 camps on the target eNB 1008. The SN status transfer message from the source eNB 1008 to the target eNB 1008 is delayed until after the RACH procedure and

RRCCorinectionReconfiguranonComplete message are completed by the UE 1002.

[00105] Thus, various embodiments exist to permit the continuous use of the WT. In some embodiments, after receiving the WT addition request from the target eNB, the WT may buffer all downlink data for the UE, irrespective of the eNB from which mat data was received, until the LWA end-marker is received from the UE, the source eNB or Ihe target eNB, e.g., depending on what the LWA end-marker indicates. In this case, after the LWA end-marker is received, the WT may then send the appropriate packets to the UE as indicated by the LWA end-marker.

[00106] In some embodiments, the UE may receive the LWA end-marker in a PDCP packet from the source eNB or WT, or in the handover command from the source eNB. The UE may, in response, transmit a new control signal to the WT that indicates to the WT to eliminate some or all of the buffered source eNB packets and deliver the buffered target eNB packets. In some

embodiments, the UE may send a status report to the target eNB. The status report may be used by the target eNB as an indication that the UE has updated the PDCP key to mat of the target eNB. In response, the target eNB may send the LWA end-marker to the WT, which then dirninates the buffered source eNB packets and transmits the buffered target eNB packets.

[00107] Moreover, in some embodiments Ihe UE may use different PDCP keys dependent on PDCP packet direction, or in other embodiments may use the same PDCP key independent of the PDCP packet direction. For example, in some embodiments, the UE may use the target eNB key provided in the

RRCConnectionReconfiguration message for uplink communications when the handover command is received and wait until the LWA end-marker received to use the target eNB key for downlink PDCP packets. In other embodiments, after the handover command is received, the UE may continue to use the source eNB key for both uplink and downlink communications until the LWA end-marker received, at which point the UE may switch to using the target eNB key. In other embodiments, after the handover command is received, the UE may continue to use the source eNB key for bom uplink and downlink

communications until handover is completed.

[00108] For example, in either embodiment shown in FIG. 9 or 10, the WT may buffer in memory PDCP packets received for the UE from the target eNB until receiving the LWA end-marker from the source eNB (or the UE as shown), which indicates that the UE is able to decode the packets from the target eNB. As above, such an event may occur when the LWA end-marker is received from the source eNB, as a result of the backhaul delay from the source eNB to the WT being longer man the delay from the target eNB to the WT. Packets for the UE received from the source eNB by the WT after reception of the LWA end-marker may be eliminated. Thus, the UE may receive target eNB packets only after transmitting the LWA end-marker to the WT. The UE may also send a PDCP or LWA status report to the target eNB, which can be used by the target eNB to indicate to the WT which packers) to transmit or ehminate.

[00109] The LWA end-marker may be indicated in messages of one or more of different protocol layers. In some embodiments, the LWAAP PDU may be used to provide the LWA end-marker, while in other embodiments the PDCP PDU may be used. The header in each of the LWAAP and PDCP PDU has reserved bits, one of which may be used to indicate that the PDU contains or is the LWA end-marker. This is to say that the payload of the LWAAP and PDCP PDU may indicate the last SN or COUNT of the last PDCP packet encrypted by the source eNB or of the first PDCP packet encrypted by the target eNB. Use of the SN may, for example, aid when PDCP packets arrive at the WT out of order, which may occur for a variety of reasons. Alternatively, LWAAP and PDCP PDU may contain no payload, merely indicating when received that the UE is to use the target eNB thereafter. In some embodiments, rather than using a reserved bit to designate the LWA end-marker, a new LWAAP or PDCP PDU type indicated by higher layer signaling may be used. The PDCP PDU type, if used, may be indicated by one of the reserved values of the 3 bit variable used to indicate the type. In this case, the LWA end-marker identification may be in the payload of the PDCP PDU in the manner indicated above. When the PDCP PDU (either type or header) is used, the WT may inspect the PDCP to determine whether the PDCP contains the LWA end-marker. Alternately, or in addition, the LWA end -marker may be sent from the source eNB to the WT via the Xw interface to indicate that the UE has received the handover command.

[00110] Thus, in some embodiments when upper layers request a PDCP re-establishment for a LWA bearer where LWA configuration is retained with the same WT, the UE may perform a number of functions. The UE may, via the processor, compile a LWA end-marker PDCP Control PDU by setting the LSN field to the PDCP SN of the last PDCP Data PDU for which the PDCP SN has been associated. The UE may submit the LWA end-marker PDCP Control PDU to lower layers as the next PDCP PDU for the transmission after the PDCP Data PDU corresponding to the LSN has been submitted to lower layers. The UE may start using the key provided by upper layers during the re-establishment procedure for the ciphering of the data part of the uplink PDCP PDUs with associated COUNT values above the COUNT value corresponding to LSN.

[00111] Subsequently, when upper layers request a PDCP re- establishment for a LWA bearer where LWA configuration is retained with the same WT, after the LWA end-marker PDCP Control PDU is received, the UE may start using the key provided by upper layers during the re-establishment procedure for the deciphering of the data part of downlink PDCP PDUs with associated COUNT values above the COUNT value corresponding to LSN. When the LWA status report is received in the downlink, for each PDCP SDU with the associated COUNT value less than the COUNT value of the PDCP SDU identified by the FMS field, the successful delivery of the corresponding PDCP SDU is confirmed, and the UE may process the PDCP SDU.

[00112] Examples

[00113] Example 1 is an apparatus of user equipment (UE), the apparatus comprising: a plurality of interfaces over each of which the UE communicates with evolved Node Bs (eNBs), including a target eNB and a source eNB, and a wireless local area network (WLAN) termination (WT); and processing circuitry in communication with the interfaces and arranged to: use a source eNB packet data convergence protocol (PDCP) key to at least one of encrypt PDCP packet data units (PDUs) to be transmitted to the source eNB through the WT or decrypt PDCP PDUs received from the source eNB through the WT; decode a Long Term Evolution (LTE)/WiFi aggregation (LWA) end-marker mat indicates that the UE is to use a target eNB PDCP key to, starting with one of a current PDCP PDU or a next PDCP PDU, at least one of encrypt subsequent PDCP

PDUs to be transmitted to the source eNB through the WT or decrypt subsequent PDCP PDUs received from the source eNB through the WT; and after reception of the LWA end-marker, use the target eNB PDCP key to at least one of encrypt the subsequent PDCP PDUs to be transmitted to the source eNB through the WT or decrypt the subsequent PDCP PDUs received from the source eNB through the WT.

[00114] In Example 2, the subject matter of Example 1 optionally includes wherein: the LWA end-marker is received in a PDCP packet from the WT.

[00115] In Example 3, Ihe subject matter of any one or more of Examples 1-2 optionally include wherein: the LWA end-marker is received in a LWA end- marker PDCP PDU from Ihe source eNB.

[00116] In Example 4, Ihe subject matter of any one or more of Examples 1-3 optionally include wherein: the LWA end-marker is received in a Long Term Evolution (LTE)-WLAN aggregation adaption protocol (LWAAP) packet from Ihe WT.

[00117] In Example 5, Ihe subject matter of any one or more of Examples 1-4 optionally include wherein: the LWA end-marker comprises a PDCP sequence number (SN) of a last PDCP packet encrypted using the source eNB key.

[00118] In Example 6, the subject matter of any one or more of Examples 1-5 optionally include wherein the processing circuitry is further arranged to: in response to reception of a handover command comprising Ihe target eNB PDCP key, encrypt uplink PDCP packets to the WT with the target eNB PDCP key.

[00119] In Example 7, the subject matter of Example 6 optionally includes wherein the processing circuitry is further arranged to: delay decryption of downlink PDCP packets from the WT with ihe target eNB key until the LWA end-marker is received.

[00120] In Example 8, the subject matter of any one or more of Examples 1-7 optionally include wherein the processing circuitry is further arranged to: after reception of a handover command comprising the target eNB PDCP key, continue to encrypt uplink PDCP packets to the WT and decrypt downlink PDCP packets from the WT with the source eNB PDCP key until the LWA end- marker is received and thereafter encrypt uplink PDCP packets to the WT and decrypt downlink PDCP packets from the WT with the target eNB PDCP key. [00121] In Example 9, the subject matter of any one or more of Examples 1-8 optionally include wherein the processing circuitry is further arranged to: after reception of a handover command comprising the target eNB PDCP key, continue to encrypt uplink PDCP packets to the WT with the source eNB PDCP key until the LWA end-marker is received and thereafter encrypt uplink PDCP packets to the WT with the target eNB PDCP key.

[00122] In Example 10, the subject matter of any one or more of

Examples 1-9 optionally include wherein the processing circuitry is further arranged to: after reception of a handover command comprising the target eNB PDCP key, continue to decrypt downlink PDCP packets from the WT with the source eNB PDCP key until the LWA end-marker is received and thereafter decrypt downlink PDCP packets from the WT with the target eNB PDCP key.

[00123] In Example 11, the subject matter of any one or more of

Examples 1-10 optionally include wherein the processing circuitry is further arranged to: generate, for transmission to the target eNB, a PDCP or LWA status report that indicates which PDCP packets are to be transmitted to the UE and which packets are to be eliminated.

[00124] In Example 12, the subject matter of any one or more of

Examples 1-11 optionally include wherein: the LWA end-marker is contained within a legacy reserve bit of a LWA adaption protocol (LWAAP) header, the LWAAP header is contained in a LWAAP packet data unit (PDU); and a payload of the LWAAP packet data unit (PDU) one of: comprises a PDCP sequence number corresponding to a greatest PDCP COUNT of PDCP packets encrypted using the source eNB key, which indicates a last packet from the source eNB, comprises a PDCP sequence number corresponding to a smallest PDCP COUNT of PDCP packets from the target eNB, which indicates a first packet from the target eNB, or is empty.

[00125] In Example 13, the subject matter of any one or more of

Examples 1-12 optionally include wherein: the LWA end-marker is indicated by a LWA adaption protocol (LWAAP) packet data unit (PDU) type, a payload of the LWAAP PDU one of: comprises one of a PDCP sequence number (SN) or a PDCP COUNT of a last packet encrypted by the source eNB using a source eNB PDCP key, comprises one of a PDCP SN or a PDCP COUNT of a first packet encrypted by the target eNB using the target eNB PDCP key, or is empty.

[00126] In Example 14, the subject matter of any one or more of

Examples 1-13 optionally include wherein: the LWA end-marker is contained within a legacy reserve bit of a PDCP packet data unit (PDU) header.

[00127] In Example 15, me subject matter of Example 14 optionally includes wherein: the payload of the LWAAP PDCP PDU comprises the PDCP sequence number corresponding to the greatest PDCP COUNT of PDCP packets from the source eNB.

[00128] In Example 16, the subject matter of any one or more of

Examples 1-15 optionally include wherein: the LWA end-marker indicates a last sequence number (LSN), and in response to reception of the LWA end-marker, the processing circuitry is configured to use the target eNB PDCP key to, for packets with a sequence number larger than the LSN, at least one of: encrypt uplink PDCP packets to the WT, or decrypt downlink PDCP packets from the WT.

[00129] In Example 17, the subject matter of any one or more of

Examples 1-16 optionally include wherein: the processing circuitry comprises a baseband processor, and the apparatus further comprises a transceiver configured to communicate with at least one of the source or target eNB or the WT via one of the interfaces.

[00130] Example 18 is an apparatus of a wireless local area network (WLAN) termination (WT), the apparatus comprising: a plurality of interfaces over each of which the WT communicates with a plurality of evolved NodeBs (eNBs), including a source eNB and target eNB, and a user equipment (UE); and processing circuitry in communication with the interfaces and arranged to:

forward packet data convergence protocol (PDCP) packets between the UE and the source eNB; decode an addition request from the target eNB; in response to reception of the addition request, buffer downlink PDCP packets from the source and target eNBs; decode a Long Term Evolution (LTE)/WiFi aggregation

(LWA) end-marker that indicates which of the buffered PDCP packets from the source eNB are to be transmitted to the UE; and transmit to the UE the buffered PDCP packets from the source eNB indicated by the LWA end-marker and the buffered PDCP packets from the target eNB.

[00131] In Example 19, the subject matter of Example 18 optionally includes wherein: the LWA end-marker is received from the source eNB and forwarded to the UE from the WT.

[00132] In Example 20, the subject matter of any one or more of Examples 18-19 optionally include wherein: the LWA end-marker is received from the UE.

[00133] In Example 21 , the subject matter of any one or more of Examples 18-20 optionally include wherein: the LWA end-marker is received from the target eNB.

[00134] In Example 22, the subject matter of any one or more of Examples 18-21 optionally include wherein the processing circuitry is further arranged to: after reception of the addition request and prior to reception of the LWA end-marker, forward uplink PDCP packets from the UE encrypted with the target eNB PDCP key.

[00135] In Example 23, the subject matter of any one or more of Examples 18-22 optionally include wherein: the LWA end-marker is contained within a legacy reserve bit of a LWA adaption protocol (LWAAP) header, the LWAAP header is contained in a LWAAP packet data unit (PDU); and a payload of the LWAAP packet data unit (PDU) one of: comprises a PDCP sequence number corresponding to a greatest PDCP COUNT of PDCP packets encrypted using the source eNB key, which indicates a last packet from the source eNB, comprises a PDCP sequence number corresponding to a smallest PDCP COUNT of PDCP packets from the target eNB, which indicates a first packet from the target eNB, or is empty.

[00136] In Example 24, the subject matter of any one or more of Examples 18-23 optionally include wherein: the LWA end-marker is indicated by a LWA adaption protocol (LWAAP) packet data unit (PDU) type, a payload of the LWAAP PDU comprises one of: a PDCP sequence number (SN) or a PDCP COUNT of a last packet from the source eNB, a PDCP SN or a PDCP COUNT of a first packet from the target eNB, or is empty. [00137] In Example 25, the subject matter of any one or more of

Examples 18-24 optionally include wherein: the LWA end-marker is contained within a legacy reserve bit of a PDCP packet data unit (PDU) header.

[00138] In Example 26, the subject matter of any one or more of

Examples 18-25 optionally include wherein: the LWA end-marker indicates a last sequence number (LSN), and in response to reception of the LWA end- marker, the processing circuitry is configured to use the target eNB PDCP key to, for packets with a sequence number larger than the LSN, at least one of: encrypt uplink PDCP packets to the WT, or decrypt downlink PDCP packets from the WT.

[00139] In Example 27, the subject matter of any one or more of

Examples 18-26 optionally include wherein: the LWA end-marker is indicated by PDCP packet data unit (PDU) type, a payload of the PDCP PDU one of: comprises one of a PDCP sequence number (SN) or a PDCP COUNT of a last packet from me source eNB, comprises one of a PDCP SN or a PDCP COUNT of a first packet from the target eNB, or is empty.

[00140] Example 28 is a computer-readable storage medium that stores instructions for execution by one or more processors, the one or more processors of a user equipment (UE) to: communicate with a source eNB through a wireless local area network (WLAN) termination (WT); receive a handover command to communicate with a target eNB through the WT; receive a Long Term Evolution (LTE)/WiFi aggregation (LWA) end-marker that indicates which packets from the WT to decrypt with a source eNB packet data convergence protocol (PDCP) key and which packets from the WT to decrypt with a target eNB PDCP key; and apply the source or target eNB key as indicated by the LWA end-marker.

[00141] In Example 29, the subject matter of Example 28 optionally includes wherein: the LWA end-marker is received in one of: the handover command, or a packet data unit (PDU) from the WT.

[00142] In Example 30, the subject matter of any one or more of

Examples 28-29 optionally include wherein one of: the LWA end-marker is contained within a legacy reserve bit of a LWA adaption protocol (LW AAP) header or PDCP packet data unit (PDU) header, and a payload of a LW AAP PDU comprising the LWAAP header or PDCP PDU comprising the PDCP PDU header comprises a greatest PDCP COUNT corresponding to a PDCP sequence number of PDCP packets from the source eNB, which indicates a last packet from the source eNB; or the LWA end-marker is indicated by a LWAAP or PDCP PDU type, a payload of the LWAAP or PDCP PDU comprises one of a PDCP sequence number (SN) or a PDCP COUNT of the last packet from the source eNB.

[00143] Example 31 is a method of performing handover of a user equipment (UE), the method comprising: communicating with a source eNB through a wireless local area network (WLAN) termination (WT); receiving a handover command to communicate with a target eNB through the WT;

receiving a Long Term Evolution (LTE)/WiFi aggregation (LWA) end-marker that indicates which packets from the WT to decrypt with a source eNB packet data convergence protocol (PDCP) key and which packets from the WT to decrypt with a target eNB PDCP key; and applying the source or target eNB key as indicated by the LWA end-marker.

[00144] In Example 32, the subject matter of Example 31 optionally includes wherein: the LWA end-marker is received in one of: the handover command, or a packet data unit (PDU) from the WT.

[00145] In Example 33, the subject matter of any one or more of Examples 31-32 optionally include wherein one of: the LWA end-marker is contained within a legacy reserve bit of a LWA adaption protocol (LWAAP) header or PDCP packet data unit (PDU) header, and a payload of a LWAAP PDU comprising the LWAAP header or PDCP PDU comprising the PDCP PDU header comprises a greatest PDCP COUNT corresponding to a PDCP sequence number of PDCP packets from the source eNB, which indicates a last packet from the source eNB; or the LWA end-marker is indicated by a LWAAP or PDCP PDU type, a payload of the LWAAP or PDCP PDU comprises one of a PDCP sequence number (SN) or a PDCP COUNT of the last packet from the source eNB.

[00146] Example 34 is an apparatus of a user equipment (UE), the apparatus comprising: means for communicating with a source eNB through a wireless local area network (WLAN) termination (WT); means for receiving a handover command to communicate with a target eNB through the WT; means for receiving a Long Term Evolution (LTE)AViFi aggregation (LWA) end- marker that indicates which packets from the WT to decrypt with a source eNB packet data convergence protocol (PDCP) key and which packets from the WT to decrypt with a target eNB PDCP key; and means for applying the source or target eNB key as indicated by the LWA end-marker.

[00147] In Example 35, the subject matter of Example 34 optionally includes wherein: the LWA end-marker is received in one of: the handover command, or a packet data unit (PDU) from the WT.

[00148] In Example 36, the subject matter of any one or more of Examples 34-35 optionally include wherein one of: the LWA end-maiker is contained within a legacy reserve bit of a LWA adaption protocol (LWAAP) header or PDCP packet data unit (PDU) header, and a pay load of a LWAAP PDU comprising the LWAAP header or PDCP PDU comprising the PDCP PDU header comprises a greatest PDCP COUNT corresponding to a PDCP sequence number of PDCP packets from me source eNB, which indicates a last packet from the source eNB; or the LWA end-marker is indicated by a LWAAP or PDCP PDU type, a payload of the LWAAP or PDCP PDU comprises one of a PDCP sequence number (SN) or a PDCP COUNT of the last packet from the source eNB.

[00149] Although an embodiment has been described with reference to specific example embodiments, it will be evident mat various modifications and changes may be made to these embodiments without departing from the broader scope of the present disclosure. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The

accompanying drawings that form a part hereof show, by way of illustration, and not of limitation, specific embodiments in which the subject matter may be practiced. The embodiments illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. This Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with me full range of equivalents to which such claims are entitled.

[00150] The subject matter may be referred to herein, individually and/or collectively, by the term "embodiment" merely for convenience and without intending to voluntarily limit the scope of this application to any single inventive concept if more than one is in fact disclosed. Thus, although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.

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

[00152] The Abstract of the Disclosure is provided to comply with 37 C.F.R. §1.72(b), requiring an abstract that will allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding mat it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in a single embodiment for the purpose of strearnlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features Ifaan are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.