Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
UE CAPABILITY SIGNALING FOR MAKE-BEFORE-BREAK AND RACH-LESS HANDOVER
Document Type and Number:
WIPO Patent Application WO/2018/026401
Kind Code:
A1
Abstract:
A User Equipment (UE) may transmit handover capability information to a cellular network. The UE may signal the cellular network (i.e., transmit the handover capability information to the network) when the UE supports RACH-less and/or make-before-break handover operations. The signaling, by the UE, may be performed when the UE initially accesses the network, such as via a UE Capability Information message. The handover capability information may be transferred between base stations as part of a UE handover operation. The cellular network, such as a particular base station in the cellular network, may subsequently implement handover operations based on the indicated capabilities that are supported by the UE.

Inventors:
YIU, Candy (1750 SW Broadway Drive, Portland, Oregon, 97201, US)
Application Number:
US2017/026712
Publication Date:
February 08, 2018
Filing Date:
April 07, 2017
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
INTEL IP CORPORATION (2200 Mission College Boulevard, Santa Clara, California, 95054, US)
International Classes:
H04W36/00
Attorney, Agent or Firm:
LEDELL, Brian (Ledell Ansari, LLP211 North Union Street,Suite 10, Alexandria Virginia, 22314, US)
Download PDF:
Claims:
WHAT IS CLAIMED IS:

1. An apparatus for a baseband processor of an Evolved NodeB (eNB), the apparatus comprising:

an interface to application circuitry; and

one or more baseband processors to:

process communications, as part of a handover procedure for a User Equipment (UE) device that is attached to the eNB and is being handed over to a target eNB, with the target eNB to inform the target eNB of the handover procedure; and

generate a Radio Resource Control (RRC) message, as part of a handover procedure for the UE, the RRC message including:

an indication that the UE is to perform a handover procedure with the target base station, and

an indication that the UE is to perform the handover procedure using a type of handover procedure that includes: a make-before-break handover or a Random Access Procedure-less (RACH-less) handover.

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

process radio access capability parameters, received from the UE, to determine the type of handover procedures that are supported by the UE.

3. The apparatus of claim 2, wherein the radio access capability parameters, received from the UE, are received as a part of initial attachment of the UE to the cellular network.

4. The apparatus of claim 2, wherein the radio access capability parameters are received as part of a UE Capability Information message.

5. The apparatus of claim 4, wherein the UE Capability Information is provided as an enumerated field in a UE-EUTRA-Capability Information Element (IE).

6. The apparatus of one of claims 1, 2, or 3, wherein the indication that the UE is to perform the handover procedure indicates a RACH-less handover, and wherein the RRC message further includes: uplink grant information that is allocated to the UE for communicating with the target base station.

7. The apparatus of claims 1 or 6, wherein the RRC message further includes: timing advance information for accessing the target base station.

8. The apparatus of claim 1, wherein for the make-bef ore-break handover, the circuitry is further to:

continue to transmit downlink data to the UE after transmitting the RRC message.

9. The apparatus of claim 1, wherein the RRC message includes an RRC

Connection Reconfiguration message.

10. The apparatus of claim 1, wherein the communication with the target base station including an indication of the determined type of handover procedure that is supported by the UE.

11. A base station, for a cellular network, comprising:

a wireless communication interface including a radio frequency (RF) transmission circuit;

a second communication interface to connect the base station to the cellular network; and circuitry to:

communicate, as part of a handover procedure for a User Equipment (UE) device that is attached to the base station and is being handed over to a target base station, with the target base station to inform the target base station of the handover procedure; and

transmit, as part of a handover procedure for the UE, a Radio Resource Control (RRC) message to the UE, the RRC message including:

an indication that the UE is to perform a handover procedure with the target base station, and

an indication that the UE is to perform the handover procedure using a type of handover procedure that includes:

a make-before-break handover in which the UE continues uplink/downlink reception with the base station until after synchronizing with the target base station, or a Random Access Procedure-less (RACH-less) handover in which the RACH procedure with the target base station is skipped.

12. The base station of claim 11, wherein the circuitry is further to:

process radio access capability parameters, received from the UE, to determine the type of handover procedures that are supported by the UE.

13. The base station of claim 12, wherein the radio access capability parameters, received from the UE, are received as a part of initial attachment of the UE to the cellular network.

14. The base station of claim 12, wherein the radio access capability parameters are received as part of a UE Capability Information message. 15. The base station of claim 14, wherein the UE Capability Information is provided as an enumerated field in a UE-EUTRA-Capability Information Element (IE).

16. The base station of one of claims 11, 12, or 13, wherein the indication that the UE is to perform the handover procedure indicates a RACH-less handover, and wherein the RRC message further includes:

uplink grant information that is allocated to the UE for communicating with the target base station.

17. An apparatus for a baseband processor of User Equipment (UE) for a cellular communication network, the apparatus comprising:

an interface to application circuitry; and

one or more baseband processors to:

process a Radio Resource Control (RRC) message from the cellular communication network, to obtain an indication to perform a handover operation using a Random Access Procedure-less (RACH-less) handover procedure, from a source Evolved NodeB (eNB) to a target eNB; and

control synchronization with the target eNB, to implement the handover operation, based on the indicated RACH-less handover procedure, wherein the controlling of the synchronization with the target eNB is based on uplink grant information, for the target eNB, that is obtained from the RRC message.

18. The apparatus of claim 17, wherein the RRC message includes an RRC

Connection Reconfiguration message and the indication is provided as part of an enumerated field in a mobility control Information Element (IE).

19. The apparatus of claim 17, wherein the one or more processors are further to execute the processing instructions to:

generate, as part of attachment of the UE to the cellular communication network, a UE Capability Information message, for transmission to the cellular communication network, that includes an indication that the UE supports make-bef ore-break or the RACH-less handover procedures.

20. The apparatus of claim 19, wherein the UE Capability Information message is transmitted as part of a UE Radio Access Capability Parameters Exchange procedure.

21. The apparatus of one of claims 17, 18, or 19, wherein the handover parameters additionally include target e B security algorithms, a dedicated RACH preamble, and a Cell- Radio Network Temporary Identifier (C-RNTI) associated with the target eNB. 22. The apparatus of one of claims 17, 18, or 19, wherein the one or more processors are to further execute the processing instructions to:

process the RRC message to obtain an indication to perform a handover operation using a make-before-break handover procedure; and

implement the make-before-break procedure by synchronizing with a downlink connection of the target eNB while continuing to maintain a connection to the source eNB procedure.

23. A device comprising:

means for processing radio access capability parameters, received from User Equipment (UE), to determine a type of handover procedure that is supported by the UE;

means for transmitting, as part of a handover request, for the UE and to a target base station, an indication of the determined type of handover procedure that is supported by the UE; and

means for transmitting, as part of a handover procedure for the UE, a Radio Resource Control (RRC) message to the UE, the RRC message including: an indication that the UE is to perform a handover procedure with the target base station, and

an indication of the type of the handover procedure, wherein the indicated type of the handover procedure is a type of handover procedure that has been indicated by the UE as being supported by the UE.

24. The device of claim 23, wherein the radio access capability parameters, received from the UE, are received as a part of initial attachment of the UE to the cellular network.

25. The device of claim 23 or 24, wherein the determined type of the handover procedure is transmitted to the target base station via an X2 interface.

Description:
UE CAPABILITY SIGNALING FOR

MAKE-BEFORE-BREAK AND RACH-LESS HANDOVER

RELATED APPLICATIONS

The present application claims the benefit of U.S. Provisional Patent Application No.

62/371,433, which was filed on August 5, 2016, and of U.S. Provisional Patent Application No. 62/372,663, which was filed on August 9, 2016, the contents of which are hereby incorporated by reference as though fully set forth herein.

BACKGROUND

Cellular communications networks can provide for wirelessly connectivity, including highspeed data, for User Equipment (UE) such as mobile phones and data terminals. A cellular communication network may include a Radio Access Network (RAN) section and a "core" network section. The RAN section may handle the wireless (radio) communications with the mobile devices. The RAN portion may include a number of geographically distributed wireless transceivers, which may be included within base stations of the network. The core section may handle control functionality relating to providing data services to the UEs.

A handover (HO) is a mobility management technique in which radio connectivity for a UE is transferred from one base station to another. Ideally, the handover process should be seamless from the point of view of the user of the UE. That is, ongoing telephone conversations, data connections (e.g., for video playback), or other application level services should continue uninterrupted. As part of the handover procedure, information relating to the current context of the UE is exchange between the current (source) base station and the next (target) base station. It is desirable that the handover and the exchange of the context information be performed as efficiently as possible.

BRIEF DESCRIPTION OF THE DRAWINGS

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

Fig. 1 is a diagram illustrating an example system in which systems and/or methods described herein may be implemented;

Figs. 2A and 2B are diagrams illustrating an example signaling sequence that illustrates a make-before-break handover operation that may be performed when switching from a source base station to a target base station; Figs. 3 A and 3B are diagrams illustrating an example signaling sequence that illustrates a Random Access Procedure-less (RACH-less) handover operation that may be performed when switching from a source base station to a target base station;

Figs. 4 and 5 are flowcharts illustrating an example process relating to UE handover capability signaling;

Fig. 6 illustrates, for one embodiment, example components of an electronic device; and Fig. 7 is a block diagram illustrating components, according to some example embodiments, of a device able to read instructions from a machine-readable or computer-readable medium (e.g., a machine-readable storage medium) and perform any one or more of the methodologies discussed herein.

DETAILED DESCRIPTION OF PREFERRED EMBODFMENTS

The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. It is to be understood that other embodiments may be utilized and structural or logical changes may be made without departing from the scope of the present disclosure. Therefore, the following detailed description is not to be taken in a limiting sense, and the scope of embodiments is defined by the appended claims and their equivalents.

In the Third Generation Partnership Project (3 GPP) standards for cellular networks, a Random Access Procedure (RACH) is used to synchronize UEs with the cellular network. A separate channel, the Physical Random Access Channel (PRACH), may be used to perform RACH. RACH may be performed in a number of scenarios, including during a handover operation to enable the UE to synchronize with the new (target) base station.

Release 13 of the 3 GPP standard includes architecture mobility enhancements relating to UE handovers. The enhancements include RACH-less handover and a "make-before-break" (i.e., maintaining a source base station NB connection during handover) handover.

Techniques are described herein to enable efficient handover operations in a wireless cellular network. In one implementation, a UE may transmit "handover capability" information to a cellular network. For instance, the UE may signal the cellular network (i.e., transmit the handover capability information to the network) when the UE supports RACH-less and/or make- before-break handover operations. The signaling, by the UE, may be performed when the UE initially accesses the network, such as via a UE Capability Information message. The handover capability information may be transferred between base stations as part of a UE handover operation. The cellular network, such as a particular base station in the cellular network, may subsequently implement handover operations based on the indicated capabilities that are supported by the UE. For example, when a UE indicates that it supports RACH-less handover, the base station may potentially initiate a RACH-less handover operation.

Fig. 1 is a diagram illustrating an example system 100 in which systems and/or methods described herein may be implemented. As illustrated, system 100 may include a number of User Equipment (UEs) 110, which may obtain network connectivity from cellular network 120. In 3 GPP, cellular network 120 may include both the Radio Access Network (RAN) 130 and the core portion of the cellular network, which may be referred to as the Evolved Packet Core (EPC) 140.

UE 110 may include a portable computing and communication device, such as a personal digital assistant (PDA), a smart phone, a cellular phone, a laptop computer with connectivity to the wireless telecommunication network, an Internet of Things (IoT) device, a tablet computer, etc. UE 110 may also include a non-portable computing device, such as a desktop computer, a consumer or business appliance, or another device that has the ability to connect to a RAN (e.g., the LTE RAN and/or the non-3 GPP access network) of the wireless telecommunication network. UE 110 may also include a computing and communication device that may be worn by a user (also referred to as a wearable device) such as a watch, a fitness band, a necklace, glasses, an eyeglass, a ring, a belt, a headset, or another type of wearable device.

RAN 130 may particularly include base stations, which, in the context of a 3 GPP network, may be referred to as Evolved NodeBs (eNBs) 135. eNBs 135 may provide the air (radio) interface for wireless connections with UEs 110. EPC 140 may include an Internet Protocol ("IP")-based network. EPC 140 may include a number of network devices, including a Mobility Management Entity (MME) 142, a Serving Gateway (SGW) 144, a Home Subscriber Server (HSS) 146, and a packet data network gateway (PGW 148). Through EPC 140, UEs 110 may communicate with an external network, such as packet data network (PDN) 150.

eNBs 135 may each include one or more network devices that receive, process, and/or transmit traffic destined for and/or received from UE 110 (e.g., via an air interface). eNBs 135 may include antennas and other logic necessary to wirelessly communicate with UEs 110. eNBs 135 may additionally communicate with other network devices in the core portion of the wireless telecommunications network. Although referred to as an "eNB," eNB 135 may generally represent any base station and/or radio access technology (RAT) node that is implemented in a cellular network as a network device designed to wirelessly communicate with UEs.

MME 142 may include one or more computation and communication devices that act as a control node for eNBs 135 and/or other devices that provide the air interface for the wireless telecommunications network. For example, MME 142 may perform operations to register UEs 110 with the cellular network, to establish user plane bearer channels (e.g., traffic flows), to hand off UE 110 to different eNBs 135, MME, or another network, and/or to perform other operations. MME 142 may perform policing operations on traffic destined for and/or received from UEs 110.

SGW 144 may aggregate traffic received from one or more eNBs 135 and may send the aggregated traffic to an external network or device via PGW 148. Additionally, SGW 144 may aggregate traffic received from one or more PGWs 148 and may send the aggregated traffic to one or more eNBs 135. SGW 144 may operate as an anchor for the user plane during inter -eNB handovers and as an anchor for mobility between different telecommunication networks.

HSS 146 may include one or more devices that may manage, update, and/or store, in a memory associated with HSS 146, profile information associated with a subscriber (e.g., a subscriber associated with UE 110). The profile information may identify applications and/or services that are permitted for and/or accessible by the subscriber; a Mobile Directory Number (MDN) associated with the subscriber; bandwidth or data rate thresholds associated with the applications and/or services; and/or other information. The subscriber may be associated with UE 110. Additionally, or alternatively, HSS 146 may perform authentication, authorization, and/or accounting operations associated with the subscriber and/or a communication session with UE 110.

PGW 148 may include one or more network devices that may aggregate traffic received from one or more SGWs 144, and may send the aggregated traffic to an external network. PGW 148 may also, or alternatively, receive traffic from the external network and may send the traffic toward UE 110 (via SGW 144 and/or eNB 135).

PDN 150 may include one or more packet networks, such as an Internet Protocol (IP) based packet network. PDN 150 may include a wide area network (WAN), a local area network (LAN), and/or combinations of WANs and LANs. Application servers or other computing devices, designed to control or aggregate data from UEs 110, may be connected to PDN 150.

A number of communication interfaces, between the various components of system 100, are illustrated in Fig. 1. The communication interfaces may include 3GPP standardized interfaces. As illustrated, the interfaces may include: an Sl-U interface between eNB 135 and SGW 144, an X2 interface between different eNBs, an S I -MME interface between eNB 135 and MME 142, an S6a interface between MME 142 and HSS 146, and an S5/S8 interface between SGW 144 and PGW 148.

The quantity of devices and/or networks, illustrated in Fig. 1, is provided for explanatory purposes only. In practice, there may be additional devices and/or networks; fewer devices and/or networks; different devices and/or networks; or differently arranged devices and/or networks than illustrated in Fig. 1. Alternatively, or additionally, one or more of the devices of system 100 may perform one or more functions described as being performed by another one or more of the devices of system 100.

Figs. 2A and 2B are diagrams illustrating an example signaling sequence that illustrates a make-before-break handover operation that may be performed when switching from a current (source) eNB 135-1 to a next (target) eNB 135-2. In the make-before-break handover operation, source eNB 135-1 may continue to send data to UE 110 after the handover command is transmitted to UE 110. UE 110 may continue downlink and uplink transmission with source eNB 135-1 until UE 110 performs the RACH procedure (i.e., the UE performs a synchronization and timing operation with target eNB 135-2). By maintaining connectivity with source eNB 135-1, even after receipt of the handover command, the interruption time during the handover operation can be reduced.

As shown in Fig. 2 A, the UE context with source eNB 135-1 may contain information regarding roaming and access restrictions that were provided either at connection establishment or at the last Tracking Area (TA) update (at 202, "Area Restriction Provided"). Source eNB 135-1 may provide measurement control information to UE 110 (at 204, "Measurement

Control). The measurement control information may be used to configure measurement procedures (relating to network conditions), at UE 110, according to roaming and access restriction information for the UE. For example, the measurement control information may include an indication of the frequency bands that the UE is to measure. The measurement control information, provided by source eNB 135-1, may also include measurements relating to network conditions which may relate to network mobility of UE 110. The measurement control information may also include indications of measurement event configuration being requested, by eNB 135-1, from UE 110.

User packet data may be exchanged, at this point, between UE 110 and SGW 144 (via source eNB 135-1). Additionally, source eNB 135-1 may provide resource allocation information to UE 110, such as information that will allow UE 110 to send the measurement report to source eNB 135-1 (at 206, "UL allocation").

UE 110 may, at certain times, generate and transmit measurement reports to source eNB 135-1 (at 208, "Measurement Reports"). The measurement report is the mechanism used by UE 110 to inform source eNB 135-1 of measurements (or other information) relating to the surrounding network. The measurement report may include, for example, particular

measurements that were previously requested by source eNB 135-1 (such as in the measurement control message). Examples of measurements may include measurements relating to Reference Signal Received Power (RSRP), Reference Signal Received Quality (RSRQ), and/or Signal -to- Noise-plus-Interference (SINR) values of neighboring cells in the measured frequencies..

Based on the measurement report and radio resource management (RRM) information, source eNB 135-1 may, at some point, make a handover decision to cause UE 110 to connect to target eNB 135-2 (at 210, "HO decision"). Source eNB 135-1 may issue a handover request to target eNB 135-2 (at 212, "Handover request"). As part of the handover request, source eNB 135-1 may pass necessary information to prepare the handover at target eNB 135-2. The information may include context information, such as UE X2 signaling context information and UE SI EPC signaling context information. The information may also include an identifier (ID) of the target cell, an eNB key (K e NB), Radio Resource Control (RRC) context information including the C-RNTI (Cell-Radio Network Temporary Identifier), and E-Radio Access Bearer (E-RAB) context and physical layer identifier of the source cell. The UE X2/UE SI signaling information may enable target eNB 135-2 to address source eNB 135-1 and the EPC. The E- RAB context may include necessary Radio Network Layer (RNL) and Transport Network Layer (TNL) addressing information, and Quality of Service (QoS) profiles of the E-RABs. The handover request may also include UE handover capability information, which may be transmitted using an X2 interface between source eNB 135-1 and target eNB 135-2.

User packet data may continue to be exchanged, during the handover signaling, between UE 110 and source eNB 135-1.

Admission Control may be performed by target eNB 135-2 to determine if the needed resources can be granted by target eNB 135-2 (at 214, "Admission Control"). The admission control operation may be performed based on the received E-RAB QoS information. Target eNB 135-2 may configure the required resources according to the received E-RAB QoS information and reserve a C-RNTI and optionally a RACH preamble. The Access Stratum (AS)

configuration to be used in the target cell can either be specified independently (i.e., an

"establishment") or as a delta compared to the AS -configuration used in the source cell (i.e., a "reconfiguration").

Target eNB 135-2 may prepare for the handover and transmit a handover request acknowledgement (ACK) to source eNB 135-1 (at 216, "Handover Request Ack"). The handover request acknowledge message may include information that is to be sent to UE 110 as an RRC message and that causes UE 100 to perform the handover. The information may include mobility control information, such as a new C-RNTI, target eNB security algorithm identifiers for the selected security algorithms, a dedicated RACH preamble, and possibly other parameters (i.e. access parameters, SIBs, etc.). The handover request acknowledge message may also include RNL/TNL information. The handover request acknowledge may be sent over the X2 interface.

Source eNB 135-1 may provide downlink (DL) allocation information to UE 110 (at 218, "DL Allocation").

Source eNB 135-1 may generates an RRC message (e.g., RRC Connection Reconfiguration message) to cause the handover to be performed by UE 110 (at 220, "RRC Conn. Reconf "). The RRC message may include the mobility control information (i.e., handover parameters that the UE may need to connect with target eNB 135-2) relating to target eNB 135-2. Source eNB 135- 1 may send the message using integrity protection ciphering techniques to protect the message. The handover parameters may include, for example, the new C-RNTI, the target eNB security algorithm identifiers, a dedicated RACH preamble, target eNB SIBs, and/or other parameters. UE 110 does not need to delay the handover execution for delivering the Automatic Repeat Request (ARQ) or Hybrid ARQ (HARQ) responses to source eNB 135-1. Source eNB 135-1 may continue sending downlink data (packet data) to UE 110 after sending the RRC message to UE 110. In this manner, when UE 110 supports enhanced handover operations (i.e., UE 110 is an enhanced mobility (eMOB) capable UE) and eMOB is enabled by the network, the UE may continue to receive/transmit from source eNB 135-1 until the UE is ready to perform retuning or camp to target eNB 135-2 (when the UE may then follow normal handover procedures). That is, the UE may synchronize with target eNB 135-2 while concurrently continuing to communicate with source eNB 135-1.

When source eNB 135-1 sends the RRC Connection Reconfiguration message, including the mobility control information, source eNB 135-1 may begin to buffer data for UE 110 while continuing to send data to UE 110. At some point, source eNB 135-1 may stop data transmission to UE 110 and start forwarding the buffered data to target eNB 135-2 (at 222, Delivered buffered and in transit packets to target eNB). Source eNB 135-1 may make the determination to start forwarding the buffered data to target eNB 135-2 based on, for example, an estimate of when UE 110 has synchronized with a new cell and/or based on a determination of poor channel conditions with UE 110. Optionally, target eNB 135-2 can signal source eNB 135-1 when the UE has synchronized. Source eNB 135-1 may remove/delete its buffered data whenever UE 110 acknowledges receiving the data.

Source eNB 135-1 may transmit a Sequence Number (SN) status transfer message to target eNB 135-2 (at 224, "SN Status Transfer"). The SN status transfer message may convey the uplink Packet Data Convergence Protocol (PDCP) SN receiver status and the downlink PDCP SN transmitter status of E-RABs for which PDCP status preservation applies. The uplink PDCP SN receiver status may include at least the PDCP SN of the first missing UL Service Data Unit (SDU) and may include a bit map of the receive status of the out-of-sequence UL SDUs, if any, that UE 110 should retransmit in the target cell. The downlink PDCP SN transmitter status may indicate the next PDCP SN that the target eNB shall assign to new SDUs. Source eNB 135-1 may omit sending this message if none of the E-RABs of the UE shall be treated with PDCP status preservation.

UE 110 may detach from the old cell (provided by source eNB 135-1) and synchronize with the new cell (provided by target eNB 135-2) (at 226, "Detach from old cell and synchronize to new cell"). Target eNB 135-2 may buffer packets from source eNB 135-1 until UE 110 has attached to the new cell (at 228, "Buffer packets from source eNB").

The synchronization procedure, for UE 110 to attach to target eNB 135-2, may be performed using the RACH procedure (at 230, "Synchronization"). In particular, after receiving the RCConnectionReconfiguration message, including the mobility control information, UE 110 may synchronize, to target eNB 135-2 (and to accesses the target cell) via RACH. Depending on whether a dedicated RACH preamble was indicated in the mobile control information, the RACH procedure may follow a contention-free or contention-based RACH procedure (i.e., a contention-free procedure may be used when a RACH preamble was indicated and a contention- based RACH procedure may otherwise be performed). UE 110 may derive target eNB specific keys and configure the selected security algorithms to be used in the target cell. Target eNB 135- 2 may respond with UL allocation information and Timing Advance information for UE 110 (at 232, "UL allocation and TA for UE").

When UE 110 has successfully accessed the target cell, UE 110 may send the RRC

Connection Reconfiguration Complete message (C-RNTI) to confirm the handover, along with an uplink buffer status report and PDCP status report (at 234, "RRC Conn. Reconf Complete + PDCP status report"). UE 110 may thus indicate, to target eNB 135-2, that the handover procedure is completed. Target eNB 135-2 may verify the C-RNTI sent in the RRC Connection Reconfiguration Complete message. The target eNB may remove buffered PDCP packets based on the PDCP status report, and may begin sending data to UE 110.

The handover completion phase of the handover is illustrated at 236-250 of Fig. 2B and may generally involve notifying the core network of the handover. As shown, target eNB 135-2 may transmit a path switch request to MME 142 (at 236, "Path Switch Request"). MME 142 may respond by transmitting a bearer modification request to SGW 144 (at 238, "Modify Bearer Request"). SGW 144 may switch the downlink path for data destined for UE 110 (at 240, "Switch DL Path"). A response to the bearer modification request may then be transmitted back to MME 142 (at 242, "Modify Bearer Response"), the path switch request may be acknowledged to target eNB 135-2 (at 244, "Path Switch Request Ack"), and source eNB 135-1 informed that the UE context can be released (at 246, "UE context release"). The source eNB may correspondingly release resources that were dedicated to UE 110 (at 248, "Release Resources").

Figs. 3 A and 3B are diagrams illustrating an example signaling sequence that illustrates a RACH-less handover operation that may be performed when switching from a source eNB 135- 1 to target eNB 135-2. In the RACH-less handover operation, UE 110 may continue downlink and uplink transmissions with the source eNB until the UE is ready to switch, at which point the UE may use the earliest available uplink (UL) grant of the target eNB to perform

synchronization with the target eNB. The UL grant information may be received from source eNB 135-1 and may indicate resource allocations that UE 110 can use to communicate with target eNB 135-2.

In Fig. 3 A, initial signaling may be identical to that shown in Fig. 2 A. In particular, the signaling and decisions for the labeled operations 302-314 may be generally similar to that shown in Fig. 2 A for the labeled operations 202-214, respectively.

Target eNB 135-2 may prepare for the handover and transmit a handover request acknowledgement to source eNB 135-1 (at 316, "Handover Request Ack"). The handover request acknowledge message may include information that is to be sent to UE 110 as an RRC message to cause UE 110 to perform the handover. The information may include a new C-RNTI, target eNB security algorithm identifiers for the selected security algorithms, and possibly other parameters (i.e. access parameters, SIBs, etc.). The container may additionally include an UL grant indication. In situations in which the UL grant indication is included in the L3 signaling, there may be no need for LI signaling of the UL grant indication (e.g., no need for periodic UL grant 332 and 334). The handover request acknowledge message may also include RNL/TNL information. The handover request acknowledge may be sent over the X2 interface.

Source eNB 135-1 may provide downlink (DL) allocation information to UE 110 (at 318, "DL Allocation").

Source eNB 135-1 may generate an RRC message (e.g., RRC Connection Reconfiguration message) to perform the handover (at 320, "RRC Conn. Reconf "). The RRC message may include the mobility control information (i.e., handover parameters that the UE may need to connect with target eNB 135-2) relating to target eNB 135-2. Source eNB 135-1 may send the message using integrity protection ciphering techniques of the message to protect the message. The RRC message may include handover parameters that the UE may need to connect with target eNB 135-2. The handover parameters may include, for example, the new C-RNTI, the target eNB security algorithm identifiers, target eNB SIBs, UL grant information, and/or other parameters. The UL grant information may include an uplink grant that is preallocated to UE 110 for the target eNB. UE 110 may use the uplink grant to communicate with the target eNB in the RACH-less handover procedure. UE 110 does not need to delay the handover execution for delivering the Automatic Repeat Request (ARQ) or Hybrid ARQ (HARQ) responses to source eNB 135-1. Source eNB 135-1 may continue sending downlink data (packet data) to UE 110, in the slot that is not allocated for the periodic UL grant, after sending the RRC Connection Reconfiguration message to the UE. In this manner, when UE 110 supports enhanced handover operations (i.e., UE 110 is an enhanced mobility (eMOB) capable UE) and eMOB is enabled by the network, the UE may continue to receive/transmit from source eNB 135-1 until the UE is ready to perform retuning or camp to target eNB 135-2135-2 (when the UE may then follow normal handover procedures).

UE 110 may detach from the old cell (provided by source eNB 135-1) and begin

synchronization with the new cell (provided by target eNB 135-2) (at 322, "Detach from old cell and synchronize to new cell"). Source eNB 135-1 may forward any buffered data, for UE 110, to target eNB 135-2 (at 324, "Deliver buffered and in transit packets to target eNB").

Source eNB 135-1 may transmit a SN status transfer message to target eNB 135-2 (at 326, "SN Status Transfer"). The SN status transfer message may convey the uplink Packet Data

Convergence Protocol (PDCP) SN receiver status and the downlink PDCP SN transmitter status of E-RABs for which PDCP status preservation applies (i.e., for RLC AM). The uplink PDCP SN receiver status may include at least the PDCP SN of the first missing UL SDU and may include a bit map of the receive status of the out-of-sequence UL SDUs, if any, that UE 110 should retransmit in the target cell. The downlink PDCP SN transmitter status may indicate the next PDCP SN that the target eNB shall assign to new SDUs. Source eNB 135-1 may omit sending this message if none of the E-RABs of the UE shall be treated with PDCP status preservation.

The buffered packets may be forwarded to target eNB 135-2 (at 328, "Data forwarding"). Target eNB 135-2 may buffer packets from source eNB 135-1, as needed (at 330, "Buffer packets from source eNB").

UE 110 may receive the UL grant information from target eNB 135-2 (at 332 and 334, "Periodic UL Grant").

To synchronize to the target eNB, UE 110 may use the earliest pre-allocated UL grant to send the RRC Connection Reconfiguration Complete message (C-RNTI), to target eNB 135-2, to confirm the handover (at 3336, "RRC Conn. Reconf. Complete"). UE 110 may also send an uplink Buffer Status Report, when possible, to target eNB 135-2 to indicate that the handover procedure is completed by the UE. Target eNB 135-2 may verify the C-RNTI value sent in the RRC Connection Reconfiguration Complete message. Target eNB 135-2 may begin sending packet data to UE 110. Target e B 135-2 may transmit an indicator to source eNB 135-1 indicating that UE 110 has successfully accessed the target cell (at 338, "UE camps to target").

The handover completion phase of the handover is illustrated at 340-350 of Fig. 3B and may generally involve notifying the core network of the handover. As shown, target eNB 135-2 may transmit a path switch request to MME 142 (at 340, "Path Switch Request"). MME 142 may respond by transmitting a bearer modification request to SGW 144 (at 342, "Modify Bearer Request"). SGW 144 may switch the downlink path for data destined for UE 110 (at 344, "Switch DL Path"). A response to the bearer modification request may then be transmitted back to MME 142 (at 344, "Modify Bearer Response"), the path switch request may be acknowledged to target eNB 135-2 (at 346, "Path Switch Request Ack"), and source eNB 135-1 informed that the UE context can be released (at 348, "UE context release"). The source eNB may

correspondingly release resources that were dedicated to UE 110 (at 350, "Release Resources").

Fig. 4 is a flowchart illustrating an example process 400 relating to UE handover capability signaling. Process 400 may be performed by, for example, UE 110.

UE 110, may, at some point, attach to cellular network 120 (block 410). The "attachment" of the UE to cellular network 120 may refer to the initial process by which UE registers with the network to receive services that require registration. The registration is known as the "network attachment." Internet Protocol (IP) connectivity for the UE may be enabled after establishing a default EPS bearer during the network attachment procedure.

As part of the attachment process, or subsequent to the attachment process, the UE may transmit Radio Access Capability Parameters to the eNB (block 420). The Radio Access Capability Parameters may include handover capability information (block 420). The handover capability information may indicate whether the UE supports make-before-break (e.g., as illustrated in Figs. 2A and 2B) and/or RACH-less (e.g., as illustrated in Figs. 3 A and 3B) handover procedures.

In one implementation, the handover capability information may be transmitted, by the UE, as an Information Element (IE) in a UE Capability Information message. The UE Capability Information message may be transmitted, by UE 110 and to eNB 135, in response to a UE Capability Enquiry message that is transmitted by eNB 135.

An example UE Capability Information message that includes a make-before-break handover capability indication, is illustrated in Table I, below. Different Radio Access

Technologies (RATs) may use different UE Capability Information messages. In Table I, an example message is included for a E-UTRA RAT (the UE-EUTRA-Capability IE). In Table I, text indicated in bold may include information that is added to the 3GPP TS 36.306 and 36.331 (vl3) specification. The added fields may be added as a non-critical extension. As shown in Table I, the UE-EUTRA-Capability IE may be modified to include an indication of whether UE 110 supports enhanced (make-before-break) handover operations. In one implementation, the enhanced handover operations may be indicated as a field, having a predetermined length, in which each bit in the field is used to indicate whether the UE supports a particular type of handover operation. For example, the field may include a single bit that is set to true (e.g., value one) when the UE supports make-before-break handover operations. In this implementation, the handover capability information may thus be included in the UE capability information message as a one-bit or multi-bit field.

Table I

UE-EUTRA-Capability-vl310-IEs ::= SEQUENCE {

ue-CategoryDL-vl310 ENUMERATED {nl7, ml} OPTIONAL,

ue-CategoryUL-vl310 ENUMERATED {nl4, ml} OPTIONAL,

pdcp-Parameters-vl310 PDCP-Parameters-vl310,

rlc-Parameters-vl310 RLC-Parameters-vl310,

mac-Parameters-vl310 MAC-Parameters-vl310 OPTIONAL,

phyLayerParameters-vl310 PhyLayerParameters-vl310 OPTIONAL,

rf-Parameters-vl310 RF-Parameters-vl310 OPTIONAL,

measParameters-vl310 MeasParameters-vl310 OPTIONAL,

dc-Parameters-vl310 DC-Parameters-vl310 OPTIONAL,

sl-Parameters-vl310 SL-Parameters-vl310 OPTIONAL,

scptm-Parameters-rl3 SCPTM-Parameters-rl3 OPTIONAL,

mtc-Parameters-rl3 MTC-Parameters-rl3 OPTIONAL,

interRAT-ParametersWLAN-rl3 IRAT-ParametersWLAN-rl3 ,

laa-Parameters-rl3 LAA-Parameters-rl3 OPTIONAL,

lwa-Parameters-rl3 LWA-Parameters-rl3 OPTIONAL,

wlan-IW-Parameters-vl310 WLAN-IW-Parameters-vl310,

lwip-Parameters-rl3 LWIP-Parameters-rl3 ,

fdd-Add-UE-EUTRA-Capabilities-vl310

UE-EUTRA-CapabilityAddXDD-Mode-vl310 OPTIONAL, tdd-Add-UE-EUTRA-Capabilities-vl310

UE-EUTRA-CapabilityAddXDD-Mode-vl310 OPTIONAL, nonCriticalExtension UE-EUTRA-Capability-vxxxx-IEs OPTIONAL l-EUTRA-Capability-vxxxx-IEs : : = SEQUENCE

ehanceHO-rl4 ENUMERATED {true} OPTIONAL

For a make-before-break handover, the network (e.g., eNB 135) may correspondingly indicate to UE 110 to continue receiving data after receiving the handover command (i.e., the eNB may indicate to the UE to perform a handover using the make-before-break handover procedure). In one implementation, eNB 135 may indicate that UE 110 should continue to receive data, after receiving the handover command, in the mobility control message (e.g., as part of the RRC Connection Reconfiguration message 220) that is transmitted to UE 110. The network can indicate this in the mobility control information message. Table Π, as shown below, illustrates an example mobility control information message. In Table II, text indicated in bold may include information that is added to the 3GPP TS 36.331 (vl3) specification for the MobilityControlInfo IE. As shown in Table II, an additional field, "enhanceHO-14," as an enumerated field that may be used to indicate, to UE 110, that the UE is to continue to receive packet data, even after receiving the handover command from the e B.

I Table II

MobilityControlInfo ::= SEQUENCE {

targetPhysCellld PhysCellld,

carrierFreq CarrierFreqEUTRA OPTIONAL, Cond HO-toEUTRA2 carrierBandwidth CarrierBandwidthEUTRA OPTIONAL, Cond HO- toEUTRA

additionalSpectrumEmission AdditionalSpectrumEmission OPTIONAL, Cond HO- toEUTRA

t304 ENUMERATED {

ms50, mslOO, msl50, ms200, ms500, mslOOO, ms2000, msl0000-vl3xy} , newUE-Identity C-RNTI,

radioResourceConfigCommon RadioResourceConfigCommon,

rach-ConfigDedicated RACH-ConfigDedicated OPTIONAL, — Need OP enhanceHO-rl4 ENUMERATED {true} OPTIONAL, Need OR

. . . r

[ [ carrierFreq-v9eO CarrierFreqEUTRA-v9eO OPTIONAL — Need ON] ] ,

[[ drb-ContinueROHC-rll ENUMERATED {true} OPTIONAL — Cond HO ]]

}

An example UE Capability Information message that includes a RACH-less capability flag, is illustrated in Table III, below. In Table III, an example message is included for a E-UTRA RAT (the UE-EUTRA-Capability IE). In Table III, text indicated in bold may include information that is added to the 3GPP TS 36.306 and 36.331 (vl3) specification. The added fields may be added as a non-critical extension.

As shown in Table III, the UE-EUTRA-Capability IE may be modified to include an indication of whether UE 110 supports enhanced handover operations. In one implementation, the enhanced handover operations may be indicated as a field, having a predetermined length, in which each bit in the field is used to indicate whether the UE supports a particular type of handover operation. For example, the field may include a single bit that is set to true (e.g., value one) when the UE supports RACH-less handover operations. In this implementation, the handover capability information may thus be included in the UE capability information message as a one-bit or multi-bit field.

Table III

UE-EUTRA-Capability-vl31 ClIEs : := SEQUENCE {

ue-CategoryDL-vl310 ENUMERATED {nl7, ml} OPTIONAL,

ue-CategoryUL-vl310 ENUMERATED {nl4, ml} OPTIONAL,

pdcp-Parameters-vl310 PDCP-Parameters-vl310,

rlc-Parameters-vl310 RLC-Parameters-vl310,

mac-Parameters -vl310 MAC-Parameters-vl310 OPTIONAL,

phyLayerParameters-vl310 PhyLayerParameters-vl310 OPTIONAL,

rf-Parameters-vl310 RF-Parameters-vl310 OPTIONAL,

meas Parameters -vl310 MeasParameters-vl310 OPTIONAL, dc-Parameters-vl310 DC-Parameters-vl310 OPTIONAL,

sl-Parameters-vl310 SL-Parameters-vl310 OPTIONAL,

scptm-Parameters-rl3 SCPTM-Parameters-rl3 OPTIONAL,

mtc-Parameters-rl3 MTC-Parameters-rl3 OPTIONAL,

interRAT-ParametersWLAN-rl3 IRAT-ParametersWLAN-rl3 ,

laa-Parameters-rl3 LAA-Parameters-rl3 OPTIONAL,

lwa-Parameters-rl3 LWA-Parameters-rl3 OPTIONAL,

wlan-IW-Parameters-vl310 WLAN-IW-Parameters-vl310,

lwip-Parameters-rl3 LWIP-Parameters-rl3 ,

fdd-Add-UE-EUTRA-Capabilities-vl310

UE-EUTRA-CapabilityAddXDD-Mode-vl310 OPTIONAL, tdd-Add-UE-EUTRA-Capabilities-vl310

UE-EUTRA-CapabilityAddXDD-Mode-vl310 OPTIONAL, nonCriticalExtension UE-EUTRA-Capability-vxxxx-IEs OPTIONAL

UE-EUTRA-Capability-vxxxx-IEs : : = SEQUENCE {

ehanceHOSkipRach-rl4 ENUMERATED {true} OPTIONAL

}

For a RACH-less handover, the network (e.g., eNB 135) may correspondingly indicate to UE 110 to continue receiving data after receiving the handover command and for the UE to skip the RACH procedure (i.e., to perform the RACH-less handover). In one implementation, eNB 135 may indicate that UE 110 should perform a RACH-less handover via mobility control information (e.g., as transmitted in the RRC Connection Reconfiguration message). Table IV, as shown below, illustrates an example mobility control information message. In Table IV, text indicated in bold may include information that is added to the 3GPP TS 36.331 (vl3) specification for the MobilityControlInfo IE. As shown in Table IV, an additional field, "rach- Skip-rl4," as an enumerated field that may be used to indicate, to UE 110, that the UE is to perform a RACH-less handover. Another field, "ul-Configlnfo," may be used for configuration of UL resource grant(s) to be used by the UE to send RRCConnectionReconfigurationComplete messages in the situation when a RACH-less handover is specified. The field

"implicitReleaseAfter" may indicate the number of skipped transmissions by the UE to the target eNB before implicit release. The value e2 may correspond to two transmissions, the value e3 may correspond to three transmissions, etc. The field "ul-StartTime-rl4" may indicate the start time in terms of the target eNB System Frame Number (SFN) and subframe index at which the allocation starts. The fields "ul-StartSFN" and "ul-StartSubframe" may indicate the target eNB SFN at which the UL allocation starts and the target eNB subframe index at which the UL allocation starts.

Table IV

MobilityControlInfo : := SEQUENCE {

targetPhysCellId PhysCellld,

carrierFreq CarrierFreqEUTRA OPTIONAL, Cond HO-toEUTRA2

Fig. 5 is a flowchart illustrating an example process 500 relating to UE handover capability signaling. Process 500 may be performed by, for example, a network device such as eNB 135.

Process 500 may include receiving handover capability information from a UE (block 510). As mentioned above, the handover capability information may be received during initial attachment of a UE to cellular network 120 and may indicate the type of handover procedures that are supported by the UE, such as whether the UE supports make-before-break and/or RACH-less handover procedures. The handover capability information may be transmitted as part of a UE capability information message, such as an enumerated field in the UE-EUTRA- Capability IE.

At some point, eNB 135 may make a determination to signal a handover operation. Based on the handover capability information that what received from a particular UE, eNB 135 may determine whether to perform the handover operation using an enhanced handover procedure (e.g., make-before-break or RACH-less handover) (block 520). Thus, if a particular UE indicates support for make-before-break or RACH-less handover, eNB 135 may indicate indicate that a make-before-break or RACH-less handover is to be performed (e.g., via mobility control information (transmitted in the RRC Connection Reconfiguration message).

During the course of a handover, the UE handover capability information may be transmitted from the source eNB to the target eNB (at 530). For example, the UE handover capability information may be transmitted during the handover request or at another time.

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

Embodiments described herein may be implemented into a system using any suitably configured hardware and/or software. Fig. 6 illustrates, for one embodiment, example components of an electronic device 600. In embodiments, the electronic device 600 may be a mobile device, a RAN node, a network controller, a subscription repository, a data gateway, a service gateway, or an application server. In some embodiments, the electronic device 600 may include application circuitry 602, baseband circuitry 604, Radio Frequency (RF) circuitry 606, front-end module (FEM) circuitry 608 and one or more antennas 660, coupled together at least as shown. In embodiments in which a radio interface is not needed for electronic device 600 (e.g., a data gateway, network controller, etc.), the RF circuitry 606, FEM circuitry 608, and antennas 660 may be omitted. In other embodiments, any of said circuitries can be included in different devices.

Application circuitry 602 may include one or more application processors. For example, the application circuitry 602 may include circuitry such as, but not limited to, one or more single- core or multi-core processors. The processor(s) may include any combination of general-purpose processors and 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. The memory/storage may include, for example, computer-readable medium 603, which may be a non-transitory computer-readable medium.

Application circuitry 602 may, in some embodiments, connect to or include one or more sensors, such as environmental sensors, cameras, etc.

Baseband circuitry 604 may include circuitry such as, but not limited to, one or more single- core or multi-core processors. The baseband circuitry 604 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 606 and to generate baseband signals for a transmit signal path of the RF circuitry 606. Baseband processing circuitry 604 may interface with the application circuitry 602 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 606. For example, in some embodiments, the baseband circuitry 604 may include a second generation (2G) baseband processor 604a, third generation (3G) baseband processor 604b, fourth generation (4G) baseband processor 604c, and/or other baseband processor(s) 604d for other existing generations, generations in development or to be developed in the future (e.g., fifth generation (5G), 6G, etc.). The baseband circuitry 604 (e.g., one or more of baseband processors 604a-d) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 606. The radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency shifting, etc. In some implementations, the functionality of baseband circuitry 604 may be wholly or partially implemented by memory/storage devices configured to execute instructions stored in the memory/storage. The memory/storage may include, for example, a non-transitory computer-readable medium 604h.

In some embodiments, modulation/demodulation circuitry of the baseband circuitry 604 may include Fast -Fourier Transform (FFT), precoding, and/or constellation mapping/demapping functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry 604 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.

In some embodiments, the baseband circuitry 604 may include elements of a protocol stack such as, for example, elements of an evolved universal terrestrial radio access network

(EUTRAN) protocol including, for example, physical (PHY), media access control (MAC), radio link control (RLC), packet data convergence protocol (PDCP), radio resource control (RRC) elements, and/or Non- Access Stratum (NAS) elements. A central processing unit (CPU) 604e of the baseband circuitry 604 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 processor(s) (DSP) 604f. The audio DSP(s) 604f may be include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments.

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

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 604 and the application circuitry 602 may be implemented together such as, for example, on a system on a chip (SOC).

In some embodiments, the baseband circuitry 604 may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 604 may support communication with an evolved universal terrestrial radio access network (EUTRAN) and/or other wireless metropolitan area networks (WMAN), a wireless local area network (WLAN), a wireless personal area network (WPAN). Embodiments in which the baseband circuitry 604 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

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

In some embodiments, the RF circuitry 606 may include a receive signal path and a transmit signal path. The receive signal path of the RF circuitry 606 may include mixer circuitry 606a, amplifier circuitry 606b and filter circuitry 606c. The transmit signal path of the RF circuitry 606 may include filter circuitry 606c and mixer circuitry 606a. RF circuitry 606 may also include synthesizer circuitry 606d for synthesizing a frequency for use by the mixer circuitry 606a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 606a of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry 608 based on the synthesized frequency provided by synthesizer circuitry 606d. The amplifier circuitry 606b may be configured to amplify the down-converted signals and the filter circuitry 606c 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 604 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 606a of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.

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

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

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

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

In some embodiments, the synthesizer circuitry 606d may be a fractional-N synthesizer or a fractional N/N+6 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 606d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider. The synthesizer circuitry 606d may be configured to synthesize an output frequency for use by the mixer circuitry 606a of the RF circuitry 606 based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 606d may be a fractional N/N+6 synthesizer.

In some embodiments, frequency input may be provided by a voltage-controlled oscillator

(VCO), although that is not a requirement. Divider control input may be provided by either the baseband circuitry 604 or the applications processor 602 depending on the desired output frequency. In some embodiments, a divider control input (e.g., N) may be determined from a look-up table based on a channel indicated by the applications processor 602.

Synthesizer circuitry 606d of the RF circuitry 606 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+6 (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these embodiments, the delay elements may be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

In some embodiments, synthesizer circuitry 606d may be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used 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 606 may include an IQ/polar converter.

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

In some embodiments, the FEM circuitry 608 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 606). The transmit signal path of the FEM circuitry 608 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry 606), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 660).

In some embodiments, the electronic device 600 may include additional elements such as, for example, memory/storage, display, camera, sensors, and/or input/output (I/O) interface. In some embodiments, the electronic device of Fig. 6 may be configured to perform one or more methods, processes, and/or techniques such as those described herein.

Fig. 7 is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a machine-readable storage medium) and perform any one or more of the methodologies discussed herein. Specifically, Fig. 7 shows a diagrammatic representation of hardware resources 700 including one or more processors (or processor cores) 710, one or more memory/storage devices 720, and one or more communication resources 730, each of which are communicatively coupled via a bus 740.

The processors 710 (e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP) such as a baseband processor, an application specific integrated circuit (ASIC), a radio-frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, a processor 712 and a processor 714. The memory/storage devices 720 may include main memory, disk storage, or any suitable combination thereof.

The communication resources 730 may include interconnection and/or network interface components or other suitable devices to communicate with one or more peripheral devices 704 and/or one or more databases 706 via a network 708. For example, the communication resources 730 may include wired communication components (e.g., for coupling via a Universal Serial Bus (USB)), cellular communication components, Near Field Communication (NFC) components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components.

Instructions 750 may comprise software, a program, an application, an applet, an app, or other executable code for causing at least any of the processors 710 to perform any one or more of the methodologies discussed herein. The instructions 750 may reside, completely or partially, within at least one of the processors 710 (e.g., within the processor's cache memory), the memory/storage devices 720, or any suitable combination thereof. Furthermore, any portion of the instructions 750 may be transferred to the hardware resources 700 from any combination of the peripheral devices 704 and/or the databases 706. Accordingly, the memory of processors 710, the memory/storage devices 720, the peripheral devices 704, and the databases 706 are examples of computer-readable and machine-readable media.

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

In a first example, an apparatus for a baseband processor of an Evolved NodeB (eNB) may include an interface to application circuitry and one or more baseband processors to: process communications, as part of a handover procedure for a User Equipment (UE) device that is attached to the eNB and is being handed over to a target eNB, with the target eNB to inform the target eNB of the handover procedure; and generate a Radio Resource Control (RRC) message, as part of a handover procedure for the UE. The RRC message may include an indication that the UE is to perform a handover procedure with the target base station, and an indication that the UE is to perform the handover procedure using a type of handover procedure that includes: a make-before-break handover or a Random Access Procedure-less (RACH-less) handover.

In example 2, the subject matter of example 1, wherein the one or more baseband processors are further to: process radio access capability parameters, received from the UE, to determine the type of handover procedures that are supported by the UE.

In example 3, the subject matter of example 2, or any of the preceding examples, wherein the radio access capability parameters, received from the UE, are received as a part of initial attachment of the UE to the cellular network.

In example 4, the subject matter of example 2, or any of the preceding examples, wherein the radio access capability parameters are received as part of a UE Capability Information message.

In example 5, the subject matter of example 4, or any of the preceding examples, wherein the UE Capability Information is provided as an enumerated field in a UE-EUTRA-Capability

Information Element (IE).

In example 6, the subject matter of one of examples 1, 2, or 3, or any of the preceding examples, wherein the indication that the UE is to perform the handover procedure indicates a RACH-less handover, and wherein the RRC message further includes: uplink grant information that is allocated to the UE for communicating with the target base station.

In example 7, the subject matter of example 1 or 6, or any of the preceding examples, wherein the RRC message further includes: timing advance information for accessing the target base station. In example 8, the subject matter of example 1, or any of the preceding examples, wherein for the make-before-break handover, the circuitry is further to: continue to transmit downlink data to the UE after transmitting the RRC message.

In example 9, the subject matter of example 1, or any of the preceding examples, wherein the RRC message includes an RRC Connection Reconfiguration message.

In example 10, the subject matter of example 1, or any of the preceding examples, wherein the communication with the target base station including an indication of the determined type of handover procedure that is supported by the UE.

In an eleventh example, a base station, for a cellular network, may comprise: a wireless communication interface including a radio frequency (RF) transmission circuit; a second communication interface to connect the base station to the cellular network; and circuitry to: communicate, as part of a handover procedure for a User Equipment (UE) device that is attached to the base station and is being handed over to a target base station, with the target base station to inform the target base station of the handover procedure; and transmit, as part of a handover procedure for the UE, a Radio Resource Control (RRC) message to the UE, the RRC message including: an indication that the UE is to perform a handover procedure with the target base station, and an indication that the UE is to perform the handover procedure using a type of handover procedure that includes: a make-before-break handover in which the UE continues uplink/downlink reception with the base station until after synchronizing with the target base station, or a Random Access Procedure-less (RACH-less) handover in which the RACH procedure with the target base station is skipped.

In example 12, the subject matter of example 11, or any of the preceding examples, wherein the circuitry is further to: process radio access capability parameters, received from the UE, to determine the type of handover procedures that are supported by the UE.

In example 13, the subject matter of example 12, or any of the preceding examples, wherein the radio access capability parameters, received from the UE, are received as a part of initial attachment of the UE to the cellular network.

In example 14, the subject matter of example 12, or any of the preceding examples, wherein the radio access capability parameters are received as part of a UE Capability Information message.

In example 15, the subject matter of example 14, or any of the preceding examples, wherein the UE Capability Information is provided as an enumerated field in a UE-EUTRA-Capability Information Element (IE).

In example 16, the subject matter of any of examples 11, 12, or 13, or any of the preceding examples, wherein the indication that the UE is to perform the handover procedure indicates a RACH-less handover, and wherein the RRC message further includes: uplink grant information that is allocated to the UE for communicating with the target base station.

In example 17, the subject matter of examples 11 or 16, or any of the preceding examples, wherein the RRC message further includes: timing advance information for accessing the target base station.

In example 18, the subject matter of example 11, or any of the preceding examples, wherein for the make-before-break handover, the circuitry is further to: continue to transmit downlink data to the UE after transmitting the RRC message.

In example 19, the subject matter of example 11, or any of the preceding examples, wherein the RRC message includes an RRC Connection Reconfiguration message.

In example 20, the subject matter of example 11, or any of the preceding examples, wherein the communication with the target base station including an indication of the determined type of handover procedure that is supported by the UE.

In a 21 st example, an apparatus for a baseband processor of User Equipment (UE) for a cellular communication network comprises: an interface to application circuitry; and one or more baseband processors to: process a Radio Resource Control (RRC) message from the cellular communication network, to obtain an indication to perform a handover operation using a Random Access Procedure-less (RACH-less) handover procedure, from a source Evolved NodeB (eNB) to a target eNB; and control synchronization with the target eNB, to implement the handover operation, based on the indicated RACH-less handover procedure, wherein the controlling of the synchronization with the target eNB is based on uplink grant information, for the target eNB, that is obtained from the RRC message.

In example 22, the subject matter of example 21 or any of the preceding examples, wherein the RRC message includes an RRC Connection Reconfiguration message and the indication is provided as part of an enumerated field in a mobility control Information Element (IE).

In example 23, the subject matter of example 21, or any of the preceding examples, wherein the one or more processors are further to execute the processing instructions to: generate, as part of attachment of the UE to the cellular communication network, a UE Capability Information message, for transmission to the cellular communication network, that includes an indication that the UE supports make-before-break or the RACH-less handover procedures.

In example 24, the subject matter of example 23, or any of the preceding examples, wherein the UE Capability Information message is transmitted as part of a UE Radio Access Capability Parameters Exchange procedure.

In example 25, the subject matter of examples 21, 22, or 23, or any of the preceding examples, wherein the handover parameters additionally include target eNB security algorithms, a dedicated RACH preamble, and a Cell-Radio Network Temporary Identifier (C-RNTI) associated with the target eNB.

In example 26, the subject matter of examples 21, 22, or 23, or any of the preceding examples, wherein the one or more processors are to further execute the processing instructions to: process the RRC message to obtain an indication to perform a handover operation using a make-before-break handover procedure; and implement the make-before-break procedure by synchronizing with a downlink connection of the target eNB while continuing to maintain a connection to the source eNB procedure.

In a 27 th example, User Equipment (UE) for a cellular communication network may comprise: a computer-readable medium containing processing instructions; and one or more processors, to execute the processing instructions to: generate, as part of attachment of the UE to the cellular communication network, a UE Capability Information message, for transmission to the cellular communication network, that includes an indication that the UE supports make- before-break or Random Access Procedure-less (RACH-less) handover procedures; process a Radio Resource Control (RRC) message from the cellular communication network to obtain an indication to perform a handover operation, using the indicated make-before-break or RACH- less handover procedure, from a source Evolved NodeB (eNB) to a target eNB; and synchronize with the target eNB, to implement the handover operation, based on the indicated make-before- break or RACH-less handover procedure.

In example 28, the subject matter of example 27, or any of the preceding examples, wherein the RRC message includes an RRC Connection Reconfiguration message and the indication is provided as part of an enumerated field in a mobility control Information Element (IE).

In example 29, the subject matter of example 27, or any of the preceding examples, wherein the UE Capability Information message is transmitted as part of a UE Radio Access Capability Parameters Exchange procedure.

In example 30, the subject matter of example 29, or any of the preceding examples, wherein the UE Capability Information is provided as an enumerated field in a UE-EUTRA-Capability Information Element (IE).

In example 31, the subject matter of example 27, 28, or 29, or any of the preceding examples, wherein the indicated handover procedure includes a RACH-less handover procedure, and wherein the RRC message includes handover parameters that include uplink (UL) grant information that indicates resource allocations for the UE to communicate with the target eNB.

In example 32, the subject matter of example 27, 28, or 29, or any of the preceding examples, wherein the handover parameters additionally include target eNB security algorithms, a dedicated RACH preamble, and a Cell-Radio Network Temporary Identifier (C-RNTI) associated with the target eNB.

In a 33 rd example, a method includes processing radio access capability parameters, received from User Equipment (UE), to determine a type of handover procedure that is supported by the UE; transmitting, as part of a handover request, for the UE and to a target base station, an indication of the determined type of handover procedure that is supported by the UE; and transmitting, as part of a handover procedure for the UE, a Radio Resource Control (RRC) message to the UE, the RRC message including: an indication that the UE is to perform a handover procedure with the target base station, and an indication of the type of the handover procedure, wherein the indicated type of the handover procedure is a type of handover procedure that has been indicated by the UE as being supported by the UE.

In example 34, the subject matter of example 33, or any of the preceding examples, wherein the radio access capability parameters, received from the UE, are received as a part of initial attachment of the UE to the cellular network.

In example 35, the subject matter of example 33 or 34, or any of the preceding examples, wherein the determined type of the handover procedure is transmitted to the target base station via an X2 interface.

In example 36, the subject matter of example 33, 34, or 35, or any of the preceding examples, wherein the received type of handover procedure that is supported by the UE is a make-before-break or a Random Access Procedure-less (RACH-less) handover procedure.

In example 37, the subject matter of any one of examples 33-36, or any of the preceding examples, wherein the RRC message includes an RRC Connection Reconfiguration message and the indication of the type of the handover procedure is provided as part of an enumerated field in a mobility control Information Element (IE).

In example 38, the subject matter of example 33, or any of the preceding examples, wherein the radio access capability parameters are received as part of a UE Capability Information message.

In example 39, the subject matter of example 33, or any of the preceding examples, wherein the determined type of handover procedure that is supported by the UE includes a Random Access Procedure-less (RACH-less) handover procedure, and wherein the method further comprises: receiving a handover acknowledgement message from the target base station, the handover acknowledgement message including uplink (UL) grant information that indicates resource allocations for the UE to communicate with the target base station.

In a 40 th example, a device comprises: means for processing radio access capability parameters, received from User Equipment (UE), to determine a type of handover procedure that is supported by the UE; means for transmitting, as part of a handover request, for the UE and to a target base station, an indication of the determined type of handover procedure that is supported by the UE; and means for transmitting, as part of a handover procedure for the UE, a Radio Resource Control (RRC) message to the UE, the RRC message including: an indication that the UE is to perform a handover procedure with the target base station, and an indication of the type of the handover procedure, wherein the indicated type of the handover procedure is a type of handover procedure that has been indicated by the UE as being supported by the UE.

In example 41, the subject matter of example 40, or any of the preceding examples, wherein the radio access capability parameters, received from the UE, are received as a part of initial attachment of the UE to the cellular network.

In example 42, the subject matter of examples 40 or 41, or any of the preceding examples, wherein the determined type of the handover procedure is transmitted to the target base station via an X2 interface.

In example 43, the subject matter of any of examples 40, 41, or 42, or any of the preceding examples, wherein the received type of handover procedure that is supported by the UE is a make-before-break or a Random Access Procedure-less (RACH-less) handover procedure.

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

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

It will be apparent that example aspects, as described above, may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement these aspects should not be construed as limiting. Thus, the operation and behavior of the aspects were described without reference to the specific software code— it being understood that software and control hardware could be designed to implement the aspects based on the description herein.

Even though particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to be limiting. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification. No element, act, or instruction used in the present application should be construed as critical or essential unless explicitly described as such. An instance of the use of the term "and," as used herein, does not necessarily preclude the interpretation that the phrase "and/or" was intended in that instance. Similarly, an instance of the use of the term "or," as used herein, does not necessarily preclude the interpretation that the phrase "and/or" was intended in that instance. Also, as used herein, the article "a" is intended to include one or more items, and may be used interchangeably with the phrase "one or more." Where only one item is intended, the terms "one," "single," "only," or similar language is used.