WO2018031110A1 - X2 support for enhanced mobility (emob) - Google Patents

Abstract

Briefly, in accordance with one or more embodiments, an apparatus of a source evolved Node B (eNB) to perform a handover of a user equipment (UE) to a target eNB comprises one or more baseband processors to generate a handover request message for the target eNB, wherein the handover request message indicates a RACH-less handover is to be used, and to process a handover request acknowledge message from the target eNB, and a memory to store the handover request acknowledge message. The one or more baseband processors determine if a RACH-less handover should be applied based at least in part on the handover acknowledge message, and the handover request acknowledge message indicates that the target eNB is capable of a RACH-less handover via a periodic uplink grant in mobility control information in the handover request acknowledge message.

Description

X2 SUPPORT FOR ENHANCED MOBILITY (EMOB)

CROSS-REFERENCE TO RELATED APPLICATIONS The present application claims the benefit of US Provisional Application No. 62/372,501 (P108037Z) filed August 9, 2016. Said Application No. 62/372,501 is hereby incorporated herein by reference in its entirety.

BACKGROUND

During a handover from a source cell or source evolved Node B (eNB) to a target cell or target eNB, the random-access channel (RACH) procedure is utilized to obtain a timing advance (TA) value for the target eNB 112. A RACH procedure may be avoided at least in some deployments without introducing any new time alignment control or estimation mechanisms because the network knows when the timing alignment is the same for both source and target cells. A RACH-less solution, therefore, may be applicable to some scenarios in the case of reusing of time alignment values. Scenarios including a small cell also are applicable by using a timing advance value of TA = 0.

DESCRIPTION OF THE DRAWING FIGURES

Claimed subject matter is particularly pointed out and distinctly claimed in the concluding portion of the specification. However, such subject matter may be understood by reference to the following detailed description when read with the accompanying drawings in which:

FIG. 1 is a diagram of a RACH-less handover procedure wherein a timing advance for a target cell is approximately equal to zero in accordance with one or more embodiments;

FIG. 2 is a diagram of a RACH-less handover procedure using a MobilityControlInfo information element in accordance with one or more embodiments;

FIG. 3A and FIG. 3B show a flow diagram of a RACH-less handover procedure in accordance with one or more embodiments;

FIG. 4 illustrates example components of a device 400 in accordance with some embodiments; and

FIG. 5 illustrates example interfaces of baseband circuitry in accordance with some embodiments.

It will be appreciated that for simplicity and or clarity of illustration, elements illustrated in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity. Further, if considered appropriate, reference numerals have been repeated among the figures to indicate corresponding and/or analogous elements.

DETAILED DESCRIPTION

In the following detailed description, numerous specific details are set forth to provide a thorough understanding of claimed subject matter. It will, however, be understood by those skilled in the art that claimed subject matter may be practiced without these specific details. In other instances, well-known methods, procedures, components and/or circuits have not been described in detail.

In the following description and/or claims, the terms coupled and/or connected, along with their derivatives, may be used. In particular embodiments, connected may be used to indicate that two or more elements are in direct physical and/or electrical contact with each other. Coupled may mean that two or more elements are in direct physical and/or electrical contact. However, coupled may also mean that two or more elements may not be in direct contact with each other, but yet may still cooperate and/or interact with each other. For example, "coupled" may mean that two or more elements do not contact each other but are indirectly joined together via another element or intermediate elements. Finally, the terms "on," "overlying," and "over" may be used in the following description and claims. "On," "overlying," and "over" may be used to indicate that two or more elements are in direct physical contact with each other. It should be noted, however, that "over" may also mean that two or more elements are not in direct contact with each other. For example, "over" may mean that one element is above another element but not contact each other and may have another element or elements in between the two elements. Furthermore, the term "and/or" may mean "and", it may mean "or", it may mean "exclusive-or", it may mean "one", it may mean "some, but not all", it may mean "neither", and/or it may mean "both", although the scope of claimed subject matter is not limited in this respect. In the following description and/or claims, the terms "comprise" and "include," along with their derivatives, may be used and are intended as synonyms for each other.

Referring now to FIG. 1, a diagram of a RACH-less handover procedure wherein a timing advance for a target cell is approximately equal to zero in accordance with one or more embodiments will be discussed. During a handover from a source cell or source evolved Node B (eNB) 110 to a target cell or target eNB 112, the random-access channel (RACH) procedure is utilized to obtain a timing advance (TA) value for the target eNB 112. In the absence of the RACH procedure, referred to as a RACH-less handover or a RACH-skip, user equipment (UE) 114 may be able to obtain the TA value for the target eNB 112 without an explicit TA command if the source eNB 110 and the target eNB 112 are time synchronized. As shown in FIG. 1, UE 114 may obtain the difference in downlink (DL) propagation delays between the source eNB 110, having a propagation delay Tl, and the target eNB 112, having a propagation delay T2. The DL propagation delay difference is T1-T2. If it is assumed that the uplink (UL) propagation delay is the same as the DL propagation delay, UE 114 may derive the TA value for the target eNB 112 from the TA value of the source eNB 110 as follows:

TAtarget— TAsource 2(T1 T2)

Another purpose of the RACH procedure during handover is to obtain an UL grant for the transmission of the handover command response, the radio resource control (RRC) Connection Reconfiguration Complete message. In the absence of the RACH procedure for the target eNB 112, allocation of the UL grant is needed in the target eNB 112. One option is to utilize a UL grant pre-allocation in handover command. The pre-allocated UL grant may be kept valid within a period of time, starting from the time when UE 114 achieves synchronization with the target eNB 112. Another option is to utilize a UL grant allocation by dynamic scheduling in the target eNB 112. The target eNB 112 may allocate an UL grant to UE 114 by dynamic scheduling from the time when target eNB 112 expects UE 114 to be available for scheduling, for example based on mutually agreed time, or sometime later after the handover preparation procedure which is subject to implementation by the target eNB 112. The initial value of physical uplink shared channel (PUSCH) transmission power control may be based on physical random access channel (PRACH) preamble power and total power ramp. If the PRACH procedure is removed, power control in the PUSCH may be modified.

In one or more embodiments as discussed herein, a RACH-less procedure may involve obtaining a TA value for the target eNB 112, power ramping, and an UL grant. In order for UE 114 to obtain a TA value from the target eNB 112, the TA value may be obtained from either a calculation performed by UE 114 or from a calculation performed by the network such as by the source eNB 110 or the target eNB 112. In one or more embodiments, it may be possible to skip the RACH procedure for handover to small cell which has a small radius, for example less than about 240 meters, although the scope of the claimed subject matter is not limited in this respect. In such a situation, UE 114 may utilize a timing advance value of zero (TA = 0, configured by the network) for the target eNB 112. Thus, in accordance with one or more embodiments, a RACH-less handover may be applied in a handover from a macro cell to a small cell, wherein the source eNB 110 is a macro cell and the target eNB 112 is a small cell. In accordance with one or more alternative embodiments, a RACH-less handover may be applied in a handover from a small cell to a small cell, wherein the source eNB 110 is a small cell and the target eNB 112 is a small cell. A macro cell may refer to a cell in a cellular network that generally may provide a higher power cellular base station, typically the highest power base station on the network with an output power on the order of tens of watts. A small cell may refer to a radio access node of a network that may operate on the network with a lower output power and range that is less than the power of the higher power macro cell and which may include, for example, femtocells, picocells, and/or microcells, although the scope of the claimed subject matter is not limited in this respect. Options for providing knowledge to UE 114 to know if a RACH-less handover may be utilized are shown in and described with respect to FIG. 2, below.

Referring now to FIG. 2, a diagram of a RACH-less handover procedure using a MobilityControUnjo information element in accordance with one or more embodiments will be discussed. As shown in FIG. 2, UE 114 may perform a handover from source eNB 110 using link 116 to target eNB 112 using link 118. UE 114 may know whether or not a RACH-less handover (HO), or a RACH-skip, may be utilized as follows. In one embodiment, after UE 114 obtains a measurement report for the target eNB 112, UE 114 sends the measurement report to the source eNB 110. The source eNB 110 then may decide whether or not to handover UE 114 to the target eNB 112. If the target eNB 112 is a small cell, then the target eNB 110 may decide to apply a RACH-less handover when receive HO request from source eNB. The decision to apply a RACH-less handover may be indicated in the handover command sent to UE 114 from the source eNB 110 (but the information for mobility is generated by target eNB), for example in the mobility control information element (IE) MobilityControlInfo (generated by target eNB) that is sent with the RRC Connection Reconfiguration message RRCConnectionReconfiguration in the handover command in accordance with the Third Generation Partnership Project (3 GPP) Technical Standard (TS) 36.331 shown below. The mobility control IE MobilityControlInfo includes parameters relevant for network controlled mobility to and/or within the Evolved Universal Terrestrial Radio Access (E-UTRA). The modification to the mobility control information element (IE) MobilityControlInfo providing the indication to apply a RACH-less handover to a small is shown in underlining, below.

In accordance with one or more embodiments, a handover (HO) of UE 114 from source eNB 110 to target eNB 112 may be implemented in compliance with a 3GPP Technical Standard (TS), for example as described in Section 5.3.1.3 "Connected mod mobility" of 3GPP TS 36.331 Release 14, although the scope of the claimed subject matter is not limited in this respect. In such an arrangement, in RRC_CONNECTED, the network controls UE 114 mobility, i.e. the network decides when the UE 114 shall connect to which Evolved Universal Terrestrial Radio Access (E-UTRA) cell(s), or inter Radio Access Technology (inter-RAT) cell. For network controlled mobility in RRC_CONNECTED, the Primary Cell (PCell) can be changed using an RRCConnectionReconfiguration message including the mobilityControlInfo (handover), whereas the Secondary Cell or Cells (SCell(s)) can be changed using the RRCConnectionReconfiguration message either with or without the mobilityControlInfo.

An SCG can be established, reconfigured or released by using an

RRCConnectionReconfiguration message with or without the mobilityControlInfo. In case Random Access to the PSCell or initial PUSCH to the PSCell if rach-SkipSCG is configured is required upon Secondary Cell Group (SCG) reconfiguration, E-UTRAN employs the SCG change procedure (i.e. an RRCConnectionReconfiguration message including the

mobilityControlInfoSCG). The Primary SCell (PSCell) can only be changed using the SCG change procedure and by release and addition of the PSCell.

The network triggers the handover procedure, for example based on radio conditions, load. To facilitate this, the network may configure the UE 114 to perform measurement reporting (possibly including the configuration of measurement gaps). The network may also initiate handover blindly, that is without having received measurement reports from the UE 114.

Before sending the handover message to the UE 114, the source eNB 110 prepares one or more target cells. The source eNB 110 selects the target PCell. The source eNB 110 may also provide the target eNB 112 with a list of best cells on each frequency for which measurement information is available, in order of decreasing Reference Signal Received Power (RSRP). The source eNB 110 may also include available measurement information for the cells provided in the list. The target eNB 112 decides which SCells are configured for use after handover, which may include cells other than the ones indicated by the source eNB. If an SCG is configured, handover involves either SCG release or SCG change. In case the UE 114 was configured with Downlink Control (DC), the target eNB 112 indicates in the handover message whether the UE 114 shall release the entire SCG configuration. Upon connection re-establishment, the UE 114 releases the entire SCG configuration except for the Data Radio Bearer (DRB) configuration, while E-UTRAN in the first reconfiguration message following the re-establishment either releases the DRB(s) or reconfigures the DRB(s) to Master Cell Group (MCG) DRB(s).

The target eNB 112 generates the message used to perform the handover, i.e. the message including the Access Stratum configuration (AS-configuration) to be used in the target cell(s). The source eNB 110 transparently (i.e. does not alter values/ content) forwards the handover message/ information received from the target to the UE. When appropriate, the source eNB 110 may initiate data forwarding for (a subset of) the DRBs.

After receiving the handover message, the UE 114 attempts to access the target PCell at the first available RACH occasion according to Random Access resource selection defined in 3GPP TS 36.321, i.e. the handover is asynchronous, or at the first available Physical Uplink Control Channel (PUSCH) occasion if RACH-Skip is configured. Consequently, when allocating a dedicated preamble for the random access in the target PCell, E-UTRA shall ensure it is available from the first RACH occasion the UE 114 may use. Upon successful completion of the handover, the UE 114 sends a message used to confirm the handover.

If the target eNB 112 does not support the release of Radio Resource Control (RRC) protocol which the source eNB 110 used to configure the UE 114, the target eNB 112 may be unable to comprehend the UE 114 configuration provided by the source eNB 110. In this case, the target eNB 112 should use the full configuration option to reconfigure the UE 114 for Handover and Re-establishment. Full configuration option includes an initialization of the radio configuration, which makes the procedure independent of the configuration used in the source cell(s) with the exception that the security algorithms are continued for the RRC re- establishment.

After the successful completion of handover, Packet Data Convergence Protocol (PDCP) Service Data Units (SDUs) may be re-transmitted in the target cell(s). This only applies for DRBs using Radio Link Control Acknowledgement Mode (RLC-AM) mode and for handovers not involving full configuration option. The further details are specified in 3GPP TS 36.323. After the successful completion of handover not involving full configuration option, the Sequence Number (SN) and the Hyper Frame Number (HFN) are reset except for the DRBs using RLC-AM mode (for which both SN and HFN continue). For reconfigurations involving the full configuration option, the PDCP entities are newly established (SN and HFN do not continue) for all DRBs irrespective of the RLC mode. The further details are specified in 3GPP TS 36.323.

One UE 114 behavior to be performed upon handover is specified, i.e. this is regardless of the handover procedures used within the network (e.g. whether the handover includes X2 or SI signaling procedures). The source eNB 110 should, for some time, maintain a context to enable the UE 114 to return in case of handover failure. After having detected handover failure, the UE 114 attempts to resume the RRC connection either in the source PCell or in another cell using the RRC re-establishment procedure. This connection resumption succeeds only if the accessed cell is prepared, i.e. concerns a cell of the source eNB 110 or of another eNB towards which handover preparation has been performed. The cell in which the re-establishment procedure succeeds becomes the PCell while SCells and Secondary Timing Advance Groups (STAGs), if configured, are released. Normal measurement and mobility procedures are used to support handover to cells broadcasting a Closed Subscriber Group (CSG) identity. In addition, E-UTRAN may configure the UE 114 to report that it is entering or leaving the proximity of cell(s) included in its CSG whitelist. Furthermore, E-UTRAN may request the UE 114 to provide additional information broadcast by the handover candidate cell e.g. global cell identity, CSG identity, CSG membership status.

It should be noted that E-UTRAN may use the 'proximity report' to configure measurements as well as to decide whether or not to request additional information broadcast by the handover candidate cell. The additional information is used to verify whether or not the UE 114 is authorized to access the target PCell and may also be needed to identify handover candidate cell (Physical Cell Identity (PCI) confusion i.e. when the physical layer identity that is included in the measurement report does not uniquely identify the cell).

Referring now to FIG. 3 A and 3B, a flow diagram of a RACH-less handover procedure in accordance with one or more embodiments will be discussed. The RACH-less handover procedure shown in FIG. 3A and 3B may be adopted in a Third-Generation Partnership Project (3 GPP) Technical Standard (TS) such as 3GPP TS 36.300. The procedure of FIG. 3A and 3B may include the following procedures including one or more procedures for an enhanced mobility (eMOB) UE 114 as discussed below.

For operation 0, the UE 114 context within the source eNB 110 contains information regarding roaming and access restrictions which were provided either at connection establishment or at the last timing advance (TA) update. For operation 1, the source eNB 110 configures the UE 114 measurement procedures according to the roaming and access restriction information and the available multiple frequency band information. Measurements provided by the source eNB 110 may assist the function controlling the UE's connection mobility. For operation 2, a MEASUREMENT REPORT is triggered and sent to the source eNB 110. At operation 3, the source eNB 110 makes decision based on MEASUREMENT REPORT and radio resource management (RRM) information to hand off the UE 114. At operation 4, the source eNB 110 issues a HANDOVER REQUEST message to the target eNB 112 passing necessary information to prepare the handover (HO) at the target side via UE X2 signaling context reference at source eNB 110, UE SI EPC signaling context reference, target cell 112 identifier (ID), evolved Node B key (KeNB*), radio resource control (RRC) context including the cell radio network temporary identifier (C-RNTI) of the UE 114 in the source eNB 110, access stratum (AS) configuration, E-UTRAN Radio Access Bearer (E-RAB) context and physical layer ID of the source cell and short Message Authentication Code Integrity (MAC-I) for possible radio link failure (RLF) recovery. UE X2 / UE S 1 signaling references enable the target eNB 112 to address the source eNB 110 and the Evolved Packet Core (EPC). The E-RAB context includes necessary Radio Network Layer (RNL) and Transport Network Layer (TNL) addressing information, and Quality of Service (QoS) profiles of the E-RABs.

For operation 5, Admission Control may be performed by the target eNB 112 dependent on the received E-RAB QoS information to increase the likelihood of a successful HO, if the resources can be granted by the target eNB 112. The target eNB 112 configures the required resources according to the received E-RAB QoS information and reserves a C-RNTI and optionally a RACH preamble. The AS-configuration to be used in the target cell 112 may either be specified independently, as an "establishment", or as a delta compared to the AS- configuration used in the source cell, as a "reconfiguration". For operation 6, the target eNB 112 prepares HO with Layer 1 and Layer 2 (L1/L2) and sends the HANDOVER REQUEST ACKNOWLEDGE to the source eNB 110, for example via the X2 interface. The HANDOVER REQUEST ACKNOWLEDGE message includes a transparent container to be sent to the UE 114 as an RRC message to perform the handover. The container includes a new C-RNTI, target eNB 112 security algorithm identifiers for the selected security algorithms, and may include a dedicated RACH preamble, periodic uplink (UL) grant and possibly some other parameters, that is access parameters, System Information Blocks (SIBs), and so on. The HANDOVER REQUEST ACKNOWLEDGE message may also include RNL/TNL information for the forwarding tunnels, if necessary. In an alternative embodiment, the target eNB 112 prepares handover (HO) with L1/L2 and sends the HANDOVER REQUEST ACKNOWLEDGE to the source eNB 110, for example via the X2 interface. The HANDOVER REQUEST ACKNOWLEDGE message includes a transparent container to be sent to the UE 114 as an RRC message to perform the handover. The container includes a new C-RNTI, target eNB 112 security algorithm identifiers for the selected security algorithms, may include a dedicated RACH preamble, and possibly some other parameters i.e., access parameters, SIBs, etc. If RACH-less HO is configured, the container includes timing adjustment indication and optionally a pre-allocated uplink grant. The HANDOVER REQUEST ACKNOWLEDGE message may also include RNL/TNL information for the forwarding tunnels, if necessary. Thus, for a RACH- less solution, the target eNB 112 may acknowledge a RACH-less handover via a pre-allocated periodic uplink (UL) grant via the HANDOVER REQUEST ACKNOWLEDGE message. In such an arrangement, the indication by target eNB 112 of a RACH-less handover may be implicit via target eNB 112 providing a pre-allocated UL grant to the UE 114 via the HANDOVER REQUEST ACKNOWLEDGE message in response to a RACH-less HANDOVER REQUEST message provided by source eNB 110 to target eNB 112.

Operation 7 through operation 16 provide a mechanism to avoid data loss during HO and are further detailed in sections 10.1.2.1.2 and 10.1.2.3 of 3 GPP TS 36.300. For operation 7, the target eNB 112 generates the RRC message to perform the handover, that is the RRCConnectionReconfiguration message including the mobility Controllnformation, to be sent by the source eNB 110 towards the UE 114. The source eNB 110 performs the necessary integrity protection and ciphering of the message. The UE 114 receives the RRCConnectionReconfiguration message with necessary parameters, including new C-RNTI, target eNB 112 security algorithm identifiers, and optionally dedicated RACH preamble, target eNB SIBs, UL grant, and so on, and is commanded by the source eNB 110 to perform the HO. The UE 114 does not need to delay the handover execution for delivering the hybrid automatic repeat request and/or automatic repeat request (HARQ/ARQ) responses to source eNB 110. The source eNB 110 continues sending downlink data to the UE 114 in the subframe that is not allocated for periodic UL grant after sending the RRCConnectionReconfiguration message to the UE 114. For operation 8, the source eNB 110 sends the sequence number (SN) status transfer SN STATUS TRANSFER message to the target eNB 112 to convey the uplink Packet Data Convergence Protocol SN (PDCP SN) receiver status and the downlink PDCP SN transmitter status of E-RABs for which PDCP status preservation applies, that is for RLC Acknowledge Mode (AM). The uplink PDCP SN receiver status includes 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 Service Data Units (SDUs) that the UE 114 needs to retransmit in the target cell 112, if there are any such SDUs. The downlink PDCP SN transmitter status indicates the next PDCP SN that the target eNB 112 shall assign to new SDUs, not having a PDCP SN yet. The source eNB 110 may omit sending this message if none of the E-RABs of the UE 114 shall be treated with PDCP status preservation.

For operation 9, when the UE 114 is ready to synchronize to the target eNB 112, it uses the earliest periodic UL grant to send the RRCConnectionReconfigurationComplete message (C- RNTI) to confirm the handover, along with an uplink Buffer Status Report, whenever possible, to the target eNB 112 to indicate that the handover procedure is completed for the UE 114. The target eNB 112 verifies the C-RNTI sent in the RRCConnectionReconfigurationComplete message. The target eNB can now begin sending data to the UE. For operation 10, the target eNB 112 can optionally send an indicator to source eNB 110 indicating the UE 114 has successfully accessed the target cell 112. The description above is directed to a RACH-less solution, and also may apply to the case where RACH-less operation may be combined with make before break solution. In order to support an enhanced mobility (eMoB) feature for RACH-less handover, both source eNB 110 and target eNB 112 will support such a feature. Therefore, the source eNB 110 may indicate to the target eNB 112 in the handover request message that this handover maybe using RACH-less handover. If the target eNB 112 is able to support it, the target eNB 112 will generate the periodic UL grant in the transparent container in the handover request message. As shown below, the existing information element (IE) for a handover request in 3GPP TS 36.423 with the added information to support a RACH-less handover indicated via underlining.

HandoverRequest-IEs X2AP- PROTOCOL- IES ::=

{ ID id-01d-eNB-UE-X2AP-ID CRITICALITY reject TYPE UE-X2AP-ID PRESENCE mandatory}!

{ ID id-Cause CRITICALITY ignore

TYPE Cause PRESENCE mandatory}!

{ ID id-TargetCell-ID CRITICALITY reject TYPE ECGI

PRESENCE mandatory}!

{ ID id-GUMMEI-ID CRITICALITY reject TYPE GUMMEI PRESENCE mandatory}!

{ ID id-UE-Contextlnformation CRITICALITY reject TYPE UE- Contextlnformation PRESENCE mandatory}!

{ ID id-UE-Historylnformation CRITICALITY ignore TYPE UE- History Information PRESENCE mandatory} !

{ ID id-TraceActivation CRITICALITY ignore

TYPE TraceActivation PRESENCE optional}!

{ ID id-SRVCCOperationPossible CRITICALITY ignore TYPE SRVCCOperationPossible PRESENCE optional}!

{ ID id-CSGMembershipStatus CRITICALITY reject TYPE CSGMembershipStatus PRESENCE optional}!

{ ID id-Mobilitylnformation CRITICALITY ignore TYPE Mobility Information PRESENCE optional}! { ID id-Masked-IMEISV CRITICALITY ignore

TYPE Masked-IMEISV PRESENCE optional} !

{ ID id-UE-HistorylnformationFromTheUE CRITICALITY ignore TYPE UE- History InformationFromTheUE PRESENCE optional}!

{ ID id-ExpectedUEBehaviour CRITICALITY ignore

TYPE ExpectedUEBehaviour PRESENCE optional } I

{ ID id-ProSeAuthorized CRITICALITY ignore

TYPE ProSeAuthorized PRESENCE optional } I

{ ID id-UE-ContextReferenceAtSeNB CRITICALITY ignore TYPE

UE-ContextReferenceAtSeNB PRESENCE optional}!

{ ID id-01d-eNB-UE-X2AP-ID-Extension CRITICALITY reject TYPE UE-X2AP-ID-

Extension PRESENCE optional}!

{ ID id-RACH-lessHO CRITICALITY reject TYPE RACH-lessHO PRESENCE optional},

}

RACH-lessHO: := ENUMERATED {True! Alternatively, RACH-lessHO can be Boolean as follows:

RACH-lessHO: := Boolean For the target eNB 112 side, if it supports RACH-less handover, then target eNB 112 may reply with the following options. For Option 1 : Target eNB 112 provides an implicit reply with the periodic UL grant in the mobilityConrolInfo in the HANDOVER REQUEST ACKNOWLEDGE message. For Option 2: Target eNB 112 may provide an explicit indicator in the HANDOVER REQUEST ACKNOWLEDGE message with the periodic UL grant in the mobilityConrolInfo in the HANDOVER REQUEST ACKNOWLEDGE message.

If the target eNB 112 does not support RACH-less handover, target eNB 112 may reply with the following options. For Option 1 : Target eNB 112 provides an implicit reject without the periodic UL grant in the mobilityConrolInfo in the HANDOVER REQUEST ACKNOWLEDGE message. For Option 2: Target eNB 112 provides an explicit indication in the HANDOVER REQUEST ACKNOWLEDGE message that target eNB 112 does not support RACH-less handover. Option 1 may involve changes in 3GPP TS 36.331. If RACH-less handover is supported, periodic UL grants for handover purposes may be specified in 3GPP TS 36.331. The reception of an RRCConnectionReconfiguration message including the mobilityControlInfo may be described in 3GPP TS 36.331 as follows.

5.3.5.4 Reception of an RRCConnectionReconfiguration including the mobilityControlInfo by the UE (handover) If the RRCConnectionReconfiguration message includes the mobilityControlInfo and the UE is able to comply with the configuration included in this message, the UE shall:

1> stop timer T310, if running;

1> stop timer T312, if running;

1> start timer T304 with the timer value set to t304, as included in the mobilityControlInfo; 1> stop timer T370, if running;

1> if the carrierFreq is included:

2> consider the target PCell to be one on the frequency indicated by the carrierFreq with a physical cell identity indicated by the targetPhysCellld;

1> else:

2> consider the target PCell to be one on the frequency of the source PCell with a physical cell identity indicated by the targetPhysCellld;

1> start synchronising to the DL of the target PCell;

NOTE 1 : The UE should perform the handover as soon as possible following the reception of the RRC message triggering the handover, which could be before confirming successful reception (HARQ and ARQ) of this message.

1> if BL UE or UE in CE:

2> acquire the MasterlnformationBlock in the target PCell;

1> if makeBeforeBreak is configured:

2> start synchronising to the DL of the target PSCell, if mobilityControlInfoSCG is included;

2> perform the remainder of this procedure including and following resetting MAC after the UE stops the uplink transmission/downlink reception with the source cell(s); NOTE x: It is up to UE implementation when to stop the uplink transmission/ downlink reception with the source cell(s) to initiate re-tuning for connection to the target cell [16], if makeBeforeBreak is configured.

1> reset MCG MAC and SCG MAC, if configured;

1> re-establish PDCP for all RBs that are established;

NOTE 2: The handling of the radio bearers after the successful completion of the PDCP re- establishment, e.g. the re-transmission of unacknowledged PDCP SDUs (as well as the associated status reporting), the handling of the SN and the HFN, is specified in TS 36.323 [8]. 1> re-establish MCG RLC and SCG RLC, if configured, for all RBs that are established; 1> configure lower layers to consider the SCell(s) other than the PSCell, if configured, to be in deactivated state;

1> apply the value of the newUE-Identity as the C-RNTI;

1> if the RRCConnectionReconfiguration message includes the fullConfig:

2> perform the radio configuration procedure as specified in 5.3.5.8;

1> configure lower layers in accordance with the received radioResourceConfigCommon; 1> if the received RRCConnectionReconfiguration message includes the rach-Skip:

2> apply the NTA value for the target MCG PTAG, see TS 36.213 [23], as indicated by targetTA in rach-Skip;

1> configure lower layers in accordance with any additional fields, not covered in the previous, if included in the received mobilityControlInfo;

1> if the received RRCConnectionReconfiguration includes the sCellToReleaseList:

2> perform SCell release as specified in 5.3.10.3a;

1> if the received RRCConnectionReconfiguration includes the scg-Configuration; or 1> if the current UE configuration includes one or more split DRBs and the received RRCConnectionReconfiguration includes radioResourceConfigDedicated including drb- ToAddModList:

2> perform SCG reconfiguration as specified in 5.3.10.10;

1> if the RRCConnectionReconfiguration message includes the radioResourceConfigDedicated:

2> perform the radio resource configuration procedure as specified in 5.3.10;

1> if the keyChangelndicator received in the securityConfigHO is set to TRUE:

2> update the KeNB key based on the KASME key taken into use with the latest successful NAS SMC procedure, as specified in TS 33.401 [32];

1> else: 2> update the KeNB key based on the current KeNB or the NH, using the nextHopChainingCount value indicated in the securityConfigHO, as specified in TS 33.401 [32]; 1> store the nextHopChainingCount value;

1> if the security AlgorithmConfig is included in the securityConfigHO:

2> derive the KRRCint key associated with the integrityProtAlgorithm, as specified in TS 33.401 [32];

2> if connected as an RN:

3> derive the KUPint key associated with the integrityProtAlgorithm, as specified in TS 33.401 [32];

2> derive the KRRCenc key and the KUPenc key associated with the cipheringAlgorithm, as specified in TS 33.401 [32];

1> else:

2> derive the KRRCint key associated with the current integrity algorithm, as specified in TS 33.401 [32];

2> if connected as an RN:

3> derive the KUPint key associated with the current integrity algorithm, as specified in TS 33.401 [32];

2> derive the KRRCenc key and the KUPenc key associated with the current ciphering algorithm, as specified in TS 33.401 [32];

1> configure lower layers to apply the integrity protection algorithm and the KRRCint key, i.e. the integrity protection configuration shall be applied to all subsequent messages received and sent by the UE, including the message used to indicate the successful completion of the procedure;

1> configure lower layers to apply the ciphering algorithm, the KRRCenc key and the KUPenc key, i.e. the ciphering configuration shall be applied to all subsequent messages received and sent by the UE, including the message used to indicate the successful completion of the procedure;

1> if connected as an RN:

2> configure lower layers to apply the integrity protection algorithm and the KUPint key, for current or subsequently established DRBs that are configured to apply integrity protection, if any;

1> if the received RRCConnectionReconfiguration includes the sCellToAddModList:

2> perform SCell addition or modification as specified in 5.3.10.3b; 1> if the received RRCConnectionReconfiguration includes the systemlnformationBlockType 1 Dedicated:

2> perfom the actions upon reception of the SystemlnformationBlockTypel message as specified in 5.2.2.7;

1> perform the measurement related actions as specified in 5.5.6.1;

1> if the RRCConnectionReconfiguration message includes the measConfig:

2> perform the measurement configuration procedure as specified in 5.5.2;

1> perform the measurement identity autonomous removal as specified in 5.5.2.2a;

1> release reportProximityConfig and clear any associated proximity status reporting timer; 1> if the RRCConnectionReconfiguration message includes the otherConfig:

2> perform the other configuration procedure as specified in 5.3.10.9;

1> if the RRCConnectionReconfiguration message includes the sl-DiscConfig or sl- CommConfig:

2> perform the sidelink dedicated configuration procedure as specified in 5.3.10.15;

1> if the RRCConnectionReconfiguration message includes wlan-Offloadlnfo:

2> perform the dedicated WLAN offload configuration procedure as specified in 5.6.12.2;

1> release the LWA configuration, if configured, as described in 5.6.14.3;

1> release the LWIP configuration, if configured, as described in 5.6.17.3;

1> if the RRCConnectionReconfiguration message includes rclwi-Configuration:

2> perform the WLAN traffic steering command procedure as specified in 5.6.16.2;

1> if the RRCConnectionReconfiguration message includes lwa-Configuration:

2> perform the LWA configuration procedure as specified in 5.6.14.2;

1> if the RRCConnectionReconfiguration message includes lwip-Configuration:

2> perform the LWIP reconfiguration procedure as specified in 5.6.17.2;

1> if the RRCConnectionReconfiguration message includes the sl-V2X-ConfigDedicated or mobilityControlInfoV2X:

2> perform the V2X sidelink communication dedicated configuration procedure as specified in 5.3.10.15a;

1> set the content of RRCConnectionReconfigurationComplete message as follows:

2> if the UE has radio link failure or handover failure information available in VarRLF- Report and if the RPLMN is included in plmn-IdentityList stored in VarRLF-Report:

3> include rlf-Info Available;

2> if the UE has MBSFN logged measurements available for E-UTRA and if the RPLMN is included in plmn-IdentityList stored in VarLogMeasReport and if T330 is not running: 3> include logMeasAvailableMBSFN;

2> else if the UE has logged measurements available for E-UTRA and if the RPLMN is included in plmn-IdentityList stored in VarLogMeasReport:

3> include the logMeas Available;

2> if the UE has connection establishment failure information available in VarConnEstFailReport and if the RPLMN is equal to plmn-Identity stored in VarConnEstFailReport:

3> include connEstFaillnfoAvailable;

1> submit the RRCConnectionReconfigurationComplete message to lower layers for transmission;

1> if MAC successfully completes the random access procedure; or

1> if MAC indicates the successful reception of a PDCCH transmission addressed to C- RNTI:

2> stop timer T304;

2> release ul-Configlnfo, if configured;

2> apply the parts of the CQI reporting configuration, the scheduling request configuration and the sounding RS configuration that do not require the UE to know the SFN of the target PCell, if any;

2> apply the parts of the measurement and the radio resource configuration that require the UE to know the SFN of the target PCell (e.g. measurement gaps, periodic CQI reporting, scheduling request configuration, sounding RS configuration), if any, upon acquiring the SFN of the target PCell;

NOTE 3: Whenever the UE shall setup or reconfigure a configuration in accordance with a field that is received it applies the new configuration, except for the cases addressed by the above statements.

2> if the UE is configured to provide IDC indications:

3> if the UE has transmitted an InDeviceCoexIndication message during the last 1 second preceding reception of the RRCConnectionReconfiguration message including mobilityControlInf o :

4> initiate transmission of the InDeviceCoexIndication message in accordance with 5.6.9.3; 2> if the UE is configured to provide power preference indications:

3> if the UE has transmitted a UEAssistancelnformation message during the last 1 second preceding reception of the RRCConnectionReconfiguration message including mobilityControlInf o : 4> initiate transmission of the UEAssistancelnformation message in accordance with 5.6.10.3;

2> if SystemInformationBlockTypel5 is broadcast by the PCell:

3> if the UE has transmitted a MBMSInterestlndication message during the last 1 second preceding reception of the RRCConnectionReconfiguration message including mobilityControlInf o :

4> ensure having a valid version of SystemInformationBlockTypel5 for the PCell;

4> determine the set of MBMS frequencies of interest in accordance with 5.8.5.3;

4> determine the set of MBMS services of interest in accordance with 5.8.5.3a;

4> initiate transmission of the MBMSInterestlndication message in accordance with 5.8.5.4; 2> if SystemInformationBlockTypel8 is broadcast by the target PCell; and the UE transmitted a SidelinkUEInformation message indicating a change of sidelink communication related parameters relevant in target PCell (i.e. change of commRxInterestedFreq or commTxResourceReq, commTxResourceReqUC if SystemInformationBlockTypel8 includes commTxResourceUC-ReqAllowed or commTxResourcelnfoReqRelay if PCell broadcasts SystemInformationBlockTypel9 including discConfigRelay) during the last 1 second preceding reception of the RRCConnectionReconfiguration message including mobilityControlInf o; or 2> if SystemInformationBlockTypel9 is broadcast by the target PCell; and the UE transmitted a SidelinkUEInformation message indicating a change of sidelink discovery related parameters relevant in target PCell (i.e. change of discRxInterest or discTxResourceReq, discTxResourceReqPS if SystemInformationBlockTypel9 includes discConfigPS or discRxGapReq or discTxGapReq if the UE is configured with gapRequestsAUowedDedicated set to true or if the UE is not configured with gapRequestsAUowedDedicated and SystemInformationBlockTypel9 includes gapRequestsAllowedCommon) during the last 1 second preceding reception of the RRCConnectionReconfiguration message including mobilityControlInf o :

3> initiate transmission of the SidelinkUEInformation message in accordance with 5.10.2.3; 2> the procedure ends;

NOTE 4: The UE is not required to determine the SFN of the target PCell by acquiring system information from that cell before performing RACH access in the target PCell, except for BL UEs or UEs in CE. Furthermore, the MobilityControlInfo information element may be described in 3GPP TS 36.331 as follows.

MobilityControlInfo information element

- ASN1 START

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-vl310},

newUE-Identity C-RNTI,

radioResourceConfigCommon RadioResourceConfigCommon, rach-ConfigDedicated RACH-ConfigDedicated

OPTIONAL, - Need OP

. ,

[[ carrierFreq-v9eO CarrierFreqEUTRA-v9eO

OPTIONAL - Need ON

]],

[[ drb-ContinueROHC-rl l ENUMERATED {true}

OPTIONAL - Cond HO

]],

[[ mobilityControlInfoV2X-rl4 MobilityControlInfoV2X-rl4

OPTIONAL, - Need OR

makeBeforeBreak-rl4 ENUMERATED {true}

OPTIONAL, - Need OR rach-Skip-rl4 RACH-Skip-rl4

OPTIONAL - Need OR

]]

MobilityControlInfoSCG-rl2 ::= SEQUENCE {

t307-rl2 ENUMERATED {

ms50, mslOO, msl50, ms200, ms500, mslOOO,

ms2000, sparel },

ue-IdentitySCG-rl2 C-RNTI

OPTIONAL, - Cond SCGEst,

rach-ConfigDedicated-rl2 RACH-ConfigDedicated

OPTIONAL, - Need OP

cipheringAlgorithmSCG-rl2 CipheringAlgorithm-rl2 OPTIONAL,

- Need ON

. ,

[[ makeBeforeBreakSCG-rl4 ENUMERATED {true}

OPTIONAL, - Need OR

rach-SkipSCG-rl4 RACH-Skip-rl4

OPTIONAL - Need OR

]]

}

MobilityControlInfoV2X-rl4 ::= SEQUENCE {

v2x-CommTxPoolExceptional-rl4 SL-CommResourcePoolV2X-rl4

OPTIONAL, - Need OR

v2x-CommRxPool-r 14 SL-CommRxPoolListV2X- rl4 OPTIONAL, - Need OR

v2x-CommSyncConfig-rl4 SL-SyncConfigListV2X-rl4

OPTIONAL - Need OR

} CarrierBandwidthEUTRA ::= SEQUENCE {

dl-Bandwidth ENUMERATED {

n6, nl5, n25, n50, n75, nlOO, sparelO,

spare9, spare8, spare7, spare6, spare5,

spare4, spare3, spare2, sparel },

ul-Bandwidth ENUMERATED {

n6, nl5, n25, n50, n75, nlOO, sparelO,

spare9, spare8, spare7, spare6, spare5,

spare4, spare3, spare2, sparel } OPTIONAL -- Need OP

}

CarrierFreqEUTRA ::= SEQUENCE {

dl-CarrierFreq ARFCN-ValueEUTRA,

ul-CarrierFreq ARFCN-ValueEUTRA

OPTIONAL Cond FDD

CarrierFreqEUTRA-v9eO ::= SEQUENCE {

dl-CarrierFreq- v9e0 ARFCN-ValueEUTRA-r9, ul-CarrierFreq-v9eO ARFCN-ValueEUTRA-r9

OPTIONAL Cond FDD

RACH-Skip-rl4 ::= SEQUENCE {

targetTA-rl4 CHOICE {

ta0-rl4 NULL,

ptag-rl4 NULL,

pstag-rl4 NULL, -STAG-rl4 STAG-Id-rl l,

-STAG-rl4 STAG-Id-rl l

} ,

ul-ConfigInfo-rl4 SEQUENCE {

numberOfConfUL-Processes- INTEGER (1..8), ul-SchedInterval-rl4 ENUMERATED {sf2, sf5, sflO}, ul- S tartSubf r ame-r 14 INTEGER (0..9),

ul-Grant-rl4 BIT STRING (SIZE (16))

}

OPTIONAL - Need OR

ASN1STOP

Option 2 may involve changes in 3GPP TS 36.423 as shown below in underlining.

HandoverRequestAcknowledge-IEs X2AP-PROTOCOL-IES ::= {

{ ID id-01d-eNB-UE-X2AP-ID

CRITICALITY ignore TYPE UE-X2AP-ID PRESENCE mandatory}! { ID id-New-eNB-UE-X2AP-ID

CRITICALITY ignore TYPE UE-X2AP-ID PRESENCE mandatory}!

{ ID id-E-RABs- Admitted-List

CRITICALITY ignore TYPE E-RABs- Admitted-List PRESENCE mandatory}!

{ ID id-E-RABs-NotAdmitted-List

CRITICALITY ignore TYPE E-RAB-List PRESENCE optional}!

{ ID id-TargeteNBtoSource-eNBTransparentContainer CRITICALITY ignore TYPE TargeteNBtoSource-eNBTransparentContainer PRESENCE mandatory}! { ID id-CriticalityDiagnostics CRITICALITY ignore TYPE CriticalityDiagnostics PRESENCE optional}!

{ ID id-UE-ContextKeptlndicator

CRITICALITY ignore TYPE UE-ContextKeptlndicator PRESENCE optional}! { ID id-SeNB-UE-X2AP-ID-Extension

CRITICALITY ignore TYPE UE-X2AP-ID-Extension PRESENCE optional} !

{ ID id-01d-eNB-UE-X2AP-ID-Extension CRITICALITY ignore TYPE UE-X2AP-ID-Extension PRESENCE optional} !

{ ID id-New-eNB-UE-X2AP-ID-Extension CRITICALITY reject

TYPE UE-X2AP-ID-Extension PRESENCE optional } I

{ ID id-RACH-lessHO CRITICALITY reject TYPE RACH-lessHO PRESENCE optional},

}

RACH-lessHO: := ENUMERATED {True. False! Alternatively, RACH-lessHO may be Boolean as follows:

RACH-lessHO: := Boolean

FIG. 4 illustrates example components of a device 400 in accordance with some embodiments. In some embodiments, the device 400 may include application circuitry 402, baseband circuitry 404, Radio Frequency (RF) circuitry 406, front-end module (FEM) circuitry 408, one or more antennas 410, and power management circuitry (PMC) 412 coupled together at least as shown. The components of the illustrated device 400 may be included in a UE or a RAN node. In some embodiments, the device 400 may include less elements (e.g., a RAN node may not utilize application circuitry 402, and instead include a processor/controller to process IP data received from an EPC). In some embodiments, the device 400 may include additional elements such as, for example, memory/storage, display, camera, sensor, or input/output (I/O) interface. In other embodiments, the components described below may be included in more than one device (e.g., said circuitries may be separately included in more than one device for Cloud- RAN (C-RAN) implementations).

The application circuitry 402 may include one or more application processors. For example, the application circuitry 402 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 or may include memory/storage and may be configured to execute instructions stored in the memory/storage to enable various applications or operating systems to run on the device 400. In some embodiments, processors of application circuitry 402 may process IP data packets received from an EPC.

The baseband circuitry 404 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 404 may include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry 406 and to generate baseband signals for a transmit signal path of the RF circuitry 406. Baseband processing circuity 404 may interface with the application circuitry 402 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 406. For example, in some embodiments, the baseband circuitry 404 may include a third generation (3G) baseband processor 404A, a fourth generation (4G) baseband processor 404B, a fifth generation (5G) baseband processor 404C, or other baseband processor(s) 404D for other existing generations, generations in development or to be developed in the future (e.g., second generation (2G), sixth generation (6G), etc.). The baseband circuitry 404 (e.g., one or more of baseband processors 404A-D) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 406. In other embodiments, some or all of the functionality of baseband processors 404A-D may be included in modules stored in the memory 404G and executed via a Central Processing Unit (CPU) 404E. 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 404 may include Fast-Fourier Transform (FFT), precoding, or constellation mapping/demapping functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry 404 may include convolution, tail-biting convolution, turbo, Viterbi, 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 404 may include one or more audio digital signal processor(s) (DSP) 404F. The audio DSP(s) 404F 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 404 and the application circuitry 402 may be implemented together such as, for example, on a system on a chip (SOC).

In some embodiments, the baseband circuitry 404 may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 404 may support communication with an evolved universal terrestrial radio access network (EUTRAN) 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 404 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

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

In some embodiments, the receive signal path of the RF circuitry 406 may include mixer circuitry 406a, amplifier circuitry 406b and filter circuitry 406c. In some embodiments, the transmit signal path of the RF circuitry 406 may include filter circuitry 406c and mixer circuitry 406a. RF circuitry 406 may also include synthesizer circuitry 406d for synthesizing a frequency for use by the mixer circuitry 406a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 406a of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry 408 based on the synthesized frequency provided by synthesizer circuitry 406d. The amplifier circuitry 406b may be configured to amplify the down-converted signals and the filter circuitry 406c 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 404 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 406a 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 406a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 406d to generate RF output signals for the FEM circuitry 408. The baseband signals may be provided by the baseband circuitry 404 and may be filtered by filter circuitry 406c.

In some embodiments, the mixer circuitry 406a of the receive signal path and the mixer circuitry 406a of the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion and upconversion, respectively. In some embodiments, the mixer circuitry 406a of the receive signal path and the mixer circuitry 406a 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 406a of the receive signal path and the mixer circuitry 406a may be arranged for direct downconversion and direct upconversion, respectively. In some embodiments, the mixer circuitry 406a of the receive signal path and the mixer circuitry 406a 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 406 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 404 may include a digital baseband interface to communicate with the RF circuitry 406.

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 406d may be a fractional-N synthesizer or a fractional N/N+l 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 406d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

The synthesizer circuitry 406d may be configured to synthesize an output frequency for use by the mixer circuitry 406a of the RF circuitry 406 based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 406d may be a fractional N/N+l 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 404 or the applications processor 402 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 402.

Synthesizer circuitry 406d of the RF circuitry 406 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 (DPA). In some embodiments, the DMD may be configured to divide the input signal by either N or N+l (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 406d 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 406 may include an IQ/polar converter.

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

In some embodiments, the FEM circuitry 408 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 an LNA to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry 406). The transmit signal path of the FEM circuitry 408 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry 406), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 410).

In some embodiments, the PMC 412 may manage power provided to the baseband circuitry 404. In particular, the PMC 412 may control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion. The PMC 412 may often be included when the device 400 is capable of being powered by a battery, for example, when the device is included in a UE. The PMC 412 may increase the power conversion efficiency while providing desirable implementation size and heat dissipation characteristics.

While FIG. 4 shows the PMC 412 coupled only with the baseband circuitry 404. In other embodiments, however, the PMC 4 12 may be additionally or alternatively coupled with, and perform similar power management operations for, other components such as, but not limited to, application circuitry 402, RF circuitry 406, or FEM 408.

In some embodiments, the PMC 412 may control, or otherwise be part of, various power saving mechanisms of the device 400. For example, if the device 400 is in an RRC_Connected state, where it is still connected to the RAN node as it expects to receive traffic shortly, then it may enter a state known as Discontinuous Reception Mode (DRX) after a period of inactivity. During this state, the device 400 may power down for brief intervals of time and thus save power.

If there is no data traffic activity for an extended period of time, then the device 400 may transition off to an RRC_Idle state, where it disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. The device 400 goes into a very low power state and it performs paging where again it periodically wakes up to listen to the network and then powers down again. The device 400 may not receive data in this state, in order to receive data, it must transition back to RRC_Connected state.

An additional power saving mode may allow a device to be unavailable to the network for periods longer than a paging interval (ranging from seconds to a few hours). During this time, the device is totally unreachable to the network and may power down completely. Any data sent during this time incurs a large delay and it is assumed the delay is acceptable.

Processors of the application circuitry 402 and processors of the baseband circuitry 404 may be used to execute elements of one or more instances of a protocol stack. For example, processors of the baseband circuitry 404, alone or in combination, may be used execute Layer 3, Layer 2, or Layer 1 functionality, while processors of the application circuitry 404 may utilize data (e.g., packet data) received from these layers and further execute Layer 4 functionality (e.g., transmission communication protocol (TCP) and user datagram protocol (UDP) layers). As referred to herein, Layer 3 may comprise a radio resource control (RRC) layer, described in further detail below. As referred to herein, Layer 2 may comprise a medium access control (MAC) layer, a radio link control (RLC) layer, and a packet data convergence protocol (PDCP) layer, described in further detail below. As referred to herein, Layer 1 may comprise a physical (PHY) layer of a UE/RAN node, described in further detail below.

FIG. 5 illustrates example interfaces of baseband circuitry in accordance with some embodiments. As discussed above, the baseband circuitry 404 of FIG. 4 may comprise processors 404A-404E and a memory 404G utilized by said processors. Each of the processors 404A-404E may include a memory interface, 504A-504E, respectively, to send/receive data to/from the memory 404G.

The baseband circuitry 404 may further include one or more interfaces to communicatively couple to other circuitries/devices, such as a memory interface 512 (e.g., an interface to send/receive data to/from memory external to the baseband circuitry 404), an application circuitry interface 514 (e.g., an interface to send/receive data to/from the application circuitry 402 of FIG. 4), an RF circuitry interface 516 (e.g., an interface to send/receive data to/from RF circuitry 406 of FIG. 4), a wireless hardware connectivity interface 518 (e.g., an interface to send/receive data to/from Near Field Communication (NFC) components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components), and a power management interface 520 (e.g., an interface to send/receive power or control signals to/from the PMC 412.

As used herein, the terms "circuit" or "circuitry" may refer to, be part of, or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group), and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable hardware components that provide the described functionality. 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.

The following are example implementations of the subject matter described herein. It should be noted that any of the examples and the variations thereof described herein may be used in any permutation or combination of any other one or more examples or variations, although the scope of the claimed subject matter is not limited in these respects. In example one, an apparatus of a source evolved Node B (eNB) to perform a handover of a user equipment (UE) to a target eNB, comprises one or more baseband processors to generate a handover request message for the target eNB, wherein the handover request message indicates a RACH-less handover is to be used, and to process a handover request acknowledge message from the target eNB, and a memory to store the handover request acknowledge message, wherein the one or more baseband processors determine if a RACH-less handover should be applied based at least in part on the handover acknowledge message, and wherein the handover request acknowledge message indicates that the target eNB is capable of a RACH-less handover via a periodic uplink grant in mobility control information in the handover request acknowledge message. In example two, the apparatus may include the subject matter of example one or any of the examples described herein, wherein the handover request acknowledge message indicates that the target eNB is capable of a RACH-less handover via an indicator in the handover request acknowledge message. In example three, the apparatus may include the subject matter of example one or any of the examples described herein, wherein the handover request acknowledge message indicates that the target eNB has rejected the RACH-less handover via an absence of a periodic uplink grant in mobility control information in the handover request acknowledge message. In example four, the apparatus may include the subject matter of example one or any of the examples described herein, wherein the handover request acknowledge message indicates that the target eNB has rejected the RACH-less handover via an indicator in the handover request acknowledge message. In example five, the apparatus may include the subject matter of example one or any of the examples described herein, wherein the handover request message or the handover request acknowledge message, or a combination thereof, are sent via X2 signaling.

In example six, an apparatus of a target evolved Node B (eNB) to perform a handover of a user equipment (UE) from a source eNB, comprises one or more baseband processors to process a handover request message from the source eNB, wherein the handover request message indicates a RACH-less handover is to be used, and a memory to store the handover request message, wherein the one or more baseband processors are to generate a handover request acknowledge message for the source eNB, including information whether a RACH-less handover should be applied, and wherein the handover request acknowledge message indicates that the target eNB is capable of a RACH-less handover via a periodic uplink grant in mobility control information in the handover request acknowledge message. In example seven, the apparatus may include the subject matter of example six or any of the examples described herein, wherein the handover request acknowledge message indicates that the target eNB is capable of a RACH-less handover via an indicator in the handover request acknowledge message. In example eight, the apparatus may include the subject matter of example six or any of the examples described herein, wherein the handover request acknowledge message indicates that the target eNB has rejected the RACH-less handover via an absence of a periodic uplink grant in mobility control information in the handover request acknowledge message. In example nine, the apparatus may include the subject matter of example six or any of the examples described herein, wherein the handover request acknowledge message indicates that the target eNB has rejected the RACH-less handover via an indicator in the handover request acknowledge message. In example ten, the apparatus may include the subject matter of example six or any of the examples described herein, wherein the handover request message or the handover request acknowledge message, or a combination thereof, are sent via X2 signaling.

In example eleven, one or more machine readable media have instructions thereon that, if executed by an apparatus of a source evolved Node B (eNB) to perform a handover of a user equipment (UE) to a target eNB, result in generating a handover request message for the target eNB, wherein the handover request message indicates a RACH-less handover is to be used, and to process a handover request acknowledge message from the target eNB 112, storing the handover request acknowledge message in a memory, and determining if a RACH-less handover should be applied based at least in part on the handover acknowledge message, wherein the handover request acknowledge message indicates that the target eNB is capable of a RACH-less handover via a periodic uplink grant in mobility control information in the handover request acknowledge message. In example twelve, the one or more machine readable media have instructions stored thereon that, if executed, may result in the subject matter of example eleven or any of the examples described herein, wherein the handover request acknowledge message indicates that the target eNB is capable of a RACH-less handover via an indicator in the handover request acknowledge message. In example thirteen, the one or more machine readable media have instructions stored thereon that, if executed, may result in the subject matter of example eleven or any of the examples described herein, wherein the handover request acknowledge message indicates that the target eNB has rejected the RACH-less handover via an absence of a periodic uplink grant in mobility control information in the handover request acknowledge message. In example fourteen, the one or more machine readable media have instructions stored thereon that, if executed, may result in the subject matter of example eleven or any of the examples described herein, wherein the handover request acknowledge message indicates that the target eNB has rejected the RACH-less handover via an indicator in the handover request acknowledge message. In example fifteen, the one or more machine readable media have instructions stored thereon that, if executed, may result in the subject matter of example eleven or any of the examples described herein, wherein the handover request message or the handover request acknowledge message, or a combination thereof, are sent via X2 signaling.

In example sixteen, one or more machine readable media having instructions thereon that, if executed by an apparatus a target evolved Node B (eNB) to perform a handover of a user equipment (UE) from a source eNB, result in processing a handover request message from the source eNB, wherein the handover request message indicates a RACH-less handover is to be used, storing the handover request message in a memory, and generating a handover request acknowledge message for the source eNB, including information whether a RACH-less handover should be applied, wherein the handover request acknowledge message indicates that the target eNB is capable of a RACH-less handover via a periodic uplink grant in mobility control information in the handover request acknowledge message. In example seventeen, the one or more machine readable media have instructions stored thereon that, if executed, may result in the subject matter of example sixteen or any of the examples described herein, wherein the handover request acknowledge message indicates that the target eNB is capable of a RACH- less handover via an indicator in the handover request acknowledge message. In example eighteen, the one or more machine readable media have instructions stored thereon that, if executed, may result in the subject matter of example sixteen or any of the examples described herein, wherein the handover request acknowledge message indicates that the target eNB has rejected the RACH-less handover via an absence of a periodic uplink grant in mobility control information in the handover request acknowledge message. In example nineteen, the one or more machine readable media have instructions stored thereon that, if executed, may result in the subject matter of example sixteen or any of the examples described herein, wherein the handover request acknowledge message indicates that the target eNB has rejected the RACH-less handover via an indicator in the handover request acknowledge message. In example twenty, the one or more machine readable media have instructions stored thereon that, if executed, may result in the subject matter of example sixteen or any of the examples described herein, wherein the handover request message or the handover request acknowledge message, or a combination thereof, are sent via X2 signaling.

In example twenty-one, an apparatus of a source evolved Node B (eNB) to perform a handover of a user equipment (UE) to a target eNB, comprises means for generating a handover request message for the target eNB, wherein the handover request message indicates a RACH- less handover is to be used, and to process a handover request acknowledge message from the target eNB, means for storing the handover request acknowledge message in a memory, and means for determining if a RACH-less handover should be applied based at least in part on the handover acknowledge message, wherein the handover request acknowledge message indicates that the target eNB is capable of a RACH-less handover via a periodic uplink grant in mobility control information in the handover request acknowledge message. In example twenty-two, the apparatus may include the subject matter of example twenty-one or any of the examples described herein, wherein the handover request acknowledge message indicates that the target eNB is capable of a RACH-less handover via an indicator in the handover request acknowledge message. In example twenty-three, the apparatus may include the subject matter of example twenty-one or any of the examples described herein, wherein the handover request acknowledge message indicates that the target eNB has rejected the RACH-less handover via an absence of a periodic uplink grant in mobility control information in the handover request acknowledge message. In example twenty-four, the apparatus may include the subject matter of example twenty-one or any of the examples described herein, wherein the handover request acknowledge message indicates that the target eNB has rejected the RACH-less handover via an indicator in the handover request acknowledge message. In example twenty-five, the apparatus may include the subject matter of example twenty-one or any of the examples described herein, wherein the handover request message or the handover request acknowledge message, or a combination thereof, are sent via X2 signaling.

In example twenty-six, an apparatus a target evolved Node B (eNB) to perform a handover of a user equipment (UE) from a source eNB, comprises means for processing a handover request message from the source eNB, wherein the handover request message indicates a RACH-less handover is to be used, means for storing the handover request message in a memory, and means for generating a handover request acknowledge message for the source eNB, including information whether a RACH-less handover should be applied, wherein the handover request acknowledge message indicates that the target eNB is capable of a RACH-less handover via a periodic uplink grant in mobility control information in the handover request acknowledge message. In example twenty-seven, the apparatus may include the subject matter of example twenty-six or any of the examples described herein, wherein the handover request acknowledge message indicates that the target eNB is capable of a RACH-less handover via an indicator in the handover request acknowledge message. In example twenty-eight, the apparatus may include the subject matter of example twenty- six or any of the examples described herein, wherein the handover request acknowledge message indicates that the target eNB has rejected the RACH-less handover via an absence of a periodic uplink grant in mobility control information in the handover request acknowledge message. In example twenty-nine, the apparatus may include the subject matter of example twenty-six or any of the examples described herein, wherein the handover request acknowledge message indicates that the target eNB has rejected the RACH-less handover via an indicator in the handover request acknowledge message. In example thirty, the apparatus may include the subject matter of example twenty-six or any of the examples described herein, wherein the handover request message or the handover request acknowledge message, or a combination thereof, are sent via X2 signaling. In example thirty-one, machine-readable storage includes machine-readable instructions, when executed, to realize an apparatus as claimed in any preceding claim.

Although the claimed subject matter has been described with a certain degree of particularity, it should be recognized that elements thereof may be altered by persons skilled in the art without departing from the spirit and/or scope of claimed subject matter. It is believed that the subject matter pertaining to X2 support for enhanced mobility (EMOB) and many of its attendant utilities will be understood by the forgoing description, and it will be apparent that various changes may be made in the form, construction and/or arrangement of the components thereof without departing from the scope and/or spirit of the claimed subject matter or without sacrificing all of its material advantages, the form herein before described being merely an explanatory embodiment thereof, and/or further without providing substantial change thereto. It is the intention of the claims to encompass and/or include such changes.

Claims

What is claimed is: 1. An apparatus of a source evolved Node B (eNB) to perform a handover of a user equipment (UE) to a target eNB, the source eNB comprising:

one or more baseband processors to generate a handover request message for the target eNB, wherein the handover request message indicates a RACH-less handover is to be used, and to process a handover request acknowledge message from the target eNB ; and

a memory to store the handover request acknowledge message;

wherein the one or more baseband processors determine if a RACH-less handover should be applied based at least in part on the handover acknowledge message, and wherein the handover request acknowledge message indicates that the target eNB is capable of a RACH-less handover via a periodic uplink grant in mobility control information in the handover request acknowledge mes sage.

2. The apparatus of claim 1, wherein the handover request acknowledge message indicates that the target eNB is capable of a RACH-less handover via an indicator in the handover request acknowledge message.

3. The apparatus of any of claims 1-2, wherein the handover request acknowledge message indicates that the target eNB has rejected the RACH-less handover via an absence of a periodic uplink grant in mobility control information in the handover request acknowledge message.

4. The apparatus of any of claims 1-3, wherein the handover request acknowledge message indicates that the target eNB has rejected the RACH-less handover via an indicator in the handover request acknowledge message.

5. The apparatus of any of claims 1-4, wherein the handover request message or the handover request acknowledge message, or a combination thereof, are sent via X2 signaling.

6. An apparatus of a target evolved Node B (eNB) to perform a handover of a user equipment (UE) from a source eNB, the target eNB comprising: one or more baseband processors to process a handover request message from the source eNB, wherein the handover request message indicates a RACH-less handover is to be used; and a memory to store the handover request message;

wherein the one or more baseband processors are to generate a handover request acknowledge message for the source eNB, including information whether a RACH-less handover should be applied, and wherein the handover request acknowledge message indicates that the target eNB is capable of a RACH-less handover via a periodic uplink grant in mobility control information in the handover request acknowledge message.

7. The apparatus of claim 6, wherein the handover request acknowledge message indicates that the target eNB is capable of a RACH-less handover via an indicator in the handover request acknowledge message.

8. The apparatus of any of claims 6-7, wherein the handover request acknowledge message indicates that the target eNB has rejected the RACH-less handover via an absence of a periodic uplink grant in mobility control information in the handover request acknowledge message.

9. The apparatus of any of claims 6-8, wherein the handover request acknowledge message indicates that the target eNB has rejected the RACH-less handover via an indicator in the handover request acknowledge message.

10. The apparatus of any of claims 6-9, wherein the handover request message or the handover request acknowledge message, or a combination thereof, are sent via X2 signaling.

11. One or more machine readable media having instructions thereon that, if executed by an apparatus of a source evolved Node B (eNB) to perform a handover of a user equipment (UE) to a target eNB, result in:

generating a handover request message for the target eNB, wherein the handover request message indicates a RACH-less handover is to be used, and to process a handover request acknowledge message from the target eNB;

storing the handover request acknowledge message in a memory; and

determining if a RACH-less handover should be applied based at least in part on the handover acknowledge message, wherein the handover request acknowledge message indicates that the target eNB is capable of a RACH-less handover via a periodic uplink grant in mobility control information in the handover request acknowledge message.

12. The one or more machine readable media of claim 11, wherein the handover request acknowledge message indicates that the target eNB is capable of a RACH-less handover via an indicator in the handover request acknowledge message.

13. The one or more machine readable media of any of claims 11-12, wherein the handover request acknowledge message indicates that the target eNB has rejected the RACH- less handover via an absence of a periodic uplink grant in mobility control information in the handover request acknowledge message.

14. The one or more machine readable media of any of claims 11-13, wherein the handover request acknowledge message indicates that the target eNB has rejected the RACH- less handover via an indicator in the handover request acknowledge message.

15. The one or more machine readable media of any of claims 11-14, wherein the handover request message or the handover request acknowledge message, or a combination thereof, are sent via X2 signaling.

16. One or more machine readable media having instructions thereon that, if executed by an apparatus a target evolved Node B (eNB) to perform a handover of a user equipment (UE) from a source eNB, result in:

processing a handover request message from the source eNB, wherein the handover request message indicates a RACH-less handover is to be used;

storing the handover request message in a memory; and

generating a handover request acknowledge message for the source eNB, including information whether a RACH-less handover should be applied, wherein the handover request acknowledge message indicates that the target eNB is capable of a RACH-less handover via a periodic uplink grant in mobility control information in the handover request acknowledge message.

17. The one or more machine readable media of claim 16, wherein the handover request acknowledge message indicates that the target eNB is capable of a RACH-less handover via an indicator in the handover request acknowledge message.

18. The one or more machine readable media of any of claims 16-17, wherein the handover request acknowledge message indicates that the target eNB has rejected the RACH- less handover via an absence of a periodic uplink grant in mobility control information in the handover request acknowledge message.

19. The one or more machine readable media of any of claims 16-18, wherein the handover request acknowledge message indicates that the target eNB has rejected the RACH- less handover via an indicator in the handover request acknowledge message.

20. The one or more machine readable media of any of claims 16-19, wherein the handover request message or the handover request acknowledge message, or a combination thereof, are sent via X2 signaling.