Reference configuration for inter-centralized unit layer 2 triggered mobility

Abstract

Systems, methods, and circuitries are disclosed for providing per-CU reference configurations for use in inter-centralized unit (CU) Layer 2 triggered (LTM) mobility. In one example a baseband processor, includes a memory configured to store instructions and a processing circuitry coupled to the memory and, when executing instructions, configured to receive a medium access control (MAC) control element (CE) that includes a command to switch from a source cell associated with a source distributed unit (DU) to a target cell associated with a target DU, wherein the source DU is controlled by a source centralized unit (CU) and the target DU is controlled by a target CU, different from the source CU; apply a reference configuration associated with the target CU; apply a Layer-2 triggered mobility (LTM) candidate configuration associated with the target DU;and communicate with the target DU.

Description

REFERENCE CONFIGURATION FOR INTER-CENTRALIZED UNIT LAYER 2 TRIGGERED MOBILITYBACKGROUND

[0001] As the number of mobile devices within wireless networks, and the demand for mobile data traffic, continue to increase, changes are made to system requirements and architectures to better address current and anticipated demands. For example, some wireless communication networks may be developed to implement fifth generation (5G) or new radio (NR) technology, sixth generation (6G) technology, and so on. An aspect of such technology includes device mobility, which may include processes and procedures for enabling a mobile device to move about a network from one wireless network node to another.BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Some examples of circuits, apparatuses and / or methods will be described in the following by way of example only. In this context, reference will be made to the accompanying figures.

[0003] FIG. 1 illustrates an overview of 5G radio access network (RAN) architecture including a centralized unit (CU) and multiple distributed units (DU) .

[0004] FIG. 2 is a message flow diagram of an example Layer 2 (L2) triggered mobility (LTM) process, in accordance with various aspects disclosed.

[0005] FIG. 3 illustrates an example LTM candidate configuration, in accordance with various aspects disclosed.

[0006] FIG. 4 is a message flow diagram of an example inter-CU LTM process, in accordance with various aspects disclosed.

[0007] FIGs. 5A, 5B, and 5C illustrate example modifications to various 3GPP standards to effectuate the process of FIG. 4, in accordance with various aspects disclosed.

[0008] FIG. 6 is a message flow diagram of an example inter-CU LTM process, in accordance with various aspects disclosed.

[0009] FIGs. 6A and 6B illustrate example modifications to various 3GPP standards to effectuate the process of FIG. 6, in accordance with various aspects disclosed.

[0010] FIG. 7 is a message flow diagram of an example inter-CU LTM process, in accordance with various aspects disclosed.

[0011] FIGs. 7A, 7B, 7C, 7D and 7E illustrate example modifications to various 3GPP standards to effectuate the process of FIG. 7, in accordance with various aspects disclosed.

[0012] FIG. 8 is a message flow diagram of an example inter-CU LTM process, in accordance with various aspects disclosed.

[0013] FIG. 9 is a message flow diagram of an example inter-CU LTM process, in accordance with various aspects disclosed.

[0014] FIGs. 9A and 9B illustrate example modifications to various 3GPP standards to effectuate the process of FIG. 9, in accordance with various aspects disclosed.

[0015] FIG. 10 illustrates example modifications to various 3GPP standards to support use of a global LTM channel state indicator (CSI) configuration for an inter-CU LTM process, in accordance with various aspects disclosed.

[0016] FIG. 11 is a flow diagram outlining an example method for configuring a UE for inter-CU LTM, in accordance with various aspects described.

[0017] FIG. 12 is a flow diagram outlining an example method for configuring a UE for inter-CU LTM, in accordance with various aspects described.

[0018] FIG. 13 is a diagram of an example wireless network, according to various aspects disclosed herein.

[0019] FIG. 14 is a diagram of an example of components of a device according to various aspects disclosed herein.DETAILED DESCRIPTION

[0020] The present disclosure is described with reference to the attached figures. The figures are not drawn to scale and they are provided merely to illustrate the disclosure. Several aspects of the disclosure are described below with reference to example applications for illustration. Numerous specific details, relationships, and methods are set forth to provide an understanding of the disclosure. The present disclosure is not limited by the illustrated ordering of acts or events, as some acts may occur in different orders and / or concurrently with other acts or events. Furthermore, not all illustrated acts or events are required to implement a methodology in accordance with the selected present disclosure.

[0021] Distributed Architecture Overview

[0022] FIG. 1 is a block diagram illustrating a logical radio access network (RAN) node 120 that is split into a centralized unit (CU) 120 and n distributed units (DUs) 125. In some examples, a single base station will include a one CU and one DU. In other examples, a CU may be shared by several DUs belonging to different base stations.

[0023] The CU 120 is responsible for non-real time functions associated with the packet data convergence protocol (PDCP) layer, the service data adaptation protocol (SDAP) layer, and the radio resource control (RRC) layer of the 5G protocol stack. Examples of CU functions include transfer of user data, mobility control, RAN sharing, positioning, session management, and so on.

[0024] The CU 120 communicates with the core network and other CUs while the DU 125 communicates with a user equipment (UE) 111. The CU 120 communicates with the core network’s user plane function (UPF) via user plane interface NG-U and with the core network’s access and mobility management function (AMF) via control plane interface NG-C. The CU 120 communicates with other CUs using an Xn interface. The CU and DU communicate using the F1-AP protocol.

[0025] The DU 125 is responsible for radio frequency (RF) processing, baseband processing, and other real time functions associated with the physical (PHY) layer (also called Layer 1) , the medium access control (MAC) layer (also called Layer 2) , and the radio link control (RLC) layer  of the 5G protocol stack. The DU 125 supports one or more cells, with each cell supporting one or more beams. In the illustrated example, the UE 111 is communicating with the RAN node 120 on two beams, a first beam supported by DU 125 (1) and a second beam supported by DU 125 (2) .

[0026] Layer 2 triggered Mobility Process Overview

[0027] Handover or mobility is a process by which a communication session of a UE is transferred from one cell to another cell. Mobility may be categorized as either beam level mobility and cell level mobility. Beam level mobility does not require explicit RRC signaling to be triggered. In beam level mobility the base station provides the UE with a measurement configuration for triggering channel and interference measurements and reports. Beam level mobility is then dealt with at the lower protocol layers by means of PHY and MAC layer control signaling such that a UE does not require explicit RRC signaling to change a beam.

[0028] Through 3GPP Release 17, cell level mobility required explicit RRC signaling to be triggered. A serving cell change is triggered by layer 3 (L3) measurements and the UE is instructed to change serving cells by way of an RRC Reconfiguration process. The RRC Reconfiguration requires reconfiguration of upper layers and / or resetting of lower layers, which may lead to longer latency, larger overhead, and longer interruption time.

[0029] In Release 18, a Layer 2 triggered mobility (LTM) process, also referred to in some contexts as the lower layer triggered mobility process, is introduced to enable serving cell change via L1 / L2 signaling, while keeping configuration of the upper layers and / or minimizing changes of configuration to the upper layers. FIG. 2 is a message flow diagram illustrating an example LTM process. In the illustrated example a UE is communicating with a logical RAN node comprising a CU that supports multiple DUs, including a source DU that is communicating with the UE and several target DUs with which the UE is not yet communicating with the network.

[0030] In a first step, a UE in the RRC_CONNECTED state transmits a Measurement Report message 210 to the source DU. At 220, the CU determines LTM candidate cells and then transmits an RRC Reconfiguration message 230 to the UE that provides LTM candidate configurations for the determined LTM candidate cells.

[0031] FIG. 3 illustrates an example of how the LTM candidate configurations are provided at 230. The RRCReconfig-> LTM-Config element includes lists of candidate configurations that are indexed to one ore more ltm-CandidateConfig items. The RRCReconfig->LTM-Config element also includes lists of ltm-CSI-ResourceConfig items. The ltm-CandidateConfig information element provides information about SSB configuration, early uplink synchronization information and transmission configuration index (TCI) information. The LTM-CSI-ResourceConfig information element indicates the particular SSB associated with the LTM candidate cell. RRCRecofig -> ServingCellConfig includes a list of LTM-CSI-ReportConfig items, each of which specifies a measurement resource (e.g., CSI-RS) associated with a given LTM candidate cell for reporting purposes.

[0032] At 240, after storing the LTM candidate configurations, the UE transmits an RRC Reconfiguration Complete message to the source DU. At 250 the UE performs early synchronization with the candidate cells, which may be supported by the source DU and / or any of the target DUs. The UE performs L1 measurements on the configured candidate cells and transmits L1 measurement reports 260 to the source DU. At 270, the CU decides to perform an LTM switch procedure to a target cell selected from the candidate cells. The source DU transmits a message 280 that includes a cell switch command MAC CE (not RRC signaling) to the UE that indicates the target cell. At 290, the UE detaches from the source DU, applies the target cell configuration, and performs a random access channel (RACH) process 295 with the target cell. Of course, since communication with the RAN node may be on multiple cells, the cell switch command and RACH process may be performed with respect to more than one target cell.

[0033] The LTM candidate configurations provided at 230 may modify a small subset of parameters configured in a full RRC Reconfiguration message. While in a traditional handover operations the network provides the RRC Reconfiguration message for the target cell, in LTM there is no RRM messaging in the cell switch process. Since LTM is directed at reducing latency it is not desirable for the LTM candidate configurations to include parameter values included in the RRC Reconfiguration message. Rather, the LTM candidate configurations may only include information for a subset of configuration parameters that may be affected by switching cells. For  example, some parameters configured in an RRC Reconfiguration message but not related radio communication aspects such as radio bearer configurations would not be included in LTM candidate configurations. When this is the case, it may be difficult for the network be able to determine the “full” configuration of the UE after one or more LTM cell switches are performed without any signaling with the network. To address this issue, the UE first “falls back” to a preconfigured reference configuration prior to applying a target candidate configuration for communication with the target cell. This helps the network to know what configuration the UE is using when there is an LTM switch.

[0034] As currently configured, the LTM process is limited to cell switches that occur between cells controlled by DUs connected to the same CU. However, it may be beneficial to enable application of the LTM process to support cell switching between cells controlled by DUs connected to different CUs to avoid overhead RRC signaling incurred by the non-LTM handover process.

[0035] FIG. 4 is a message flow diagram outlining an RRC configuration process during which a UE is pre-configured with LTM candidate configurations and per-CU reference configurations in anticipation of a Layer 2 cell switch command. The UE is already configured with a full RRC configuration for the source CU by virtue of the fact that the UE is currently CONNECTED to the CU. To enable the LTM configuration process, the source CU transmits a HANDOVER REQUEST message 405 to one or more target CUs for which LTM is to be enabled with respect to the UE. The HANDOVER REQUEST from the source CU can also include some additional guidance like the number of candidate cells that the target CU can include for the LTM configuration.

[0036] At 415, the target CUs respond with a HANDOVER REQUEST ACKNOWLEDGE message. The HANDOVER REQUEST and HANDOVER REQUEST ACKNOWLEDGE MESSAGES may be adapted to support this process as will be discussed below. At 420, the source CU prepares per-CU containers with LTM candidate configurations (see, e.g., FIG. 3) . As discussed above, the UE may apply the reference configuration before applying the LTM-candidate configurations. To support this, each per-CU container prepared at 420 also includes a per-CU reference configuration for the associated CU. Several example mechanisms by which  the UE may be provided with the per-CU reference configuration and apply the per-CU reference configuration are disclosed herein. The source CU transmits a UE CONTEXT MODIFICATION message 425 to the DU source DU that includes the per-CU containers. At 430A, the source CU transmits a downlink RRC MESSAGE TRANSFER command 430B to the DU. This command triggers the source DU to transmit an RRC Reconfiguration message to the UE that includes the per-CU containers.

[0037] FIG. 5A illustrates a revised portion of TS 38.331 in which a reference configuration 550 is provided per candidate cell but the reference configuration is only provided on one of the candidates for the associated CU. The information element (IE) shown in FIG. 5A is optional. Another alternative is to have a separate per-CU structure 560 for the reference configuration as shown in FIG. 5B. Yet another alternative is to provide a list of reference configurations 570, each referenced by an ID. A selected ID may be provided to each candidate cell or candidate UE and the UE will use that reference configuration for all the cells supported by the CU.

[0038] FIG. 6 is a message flow diagram that outlines an example LTM configuration process in which the source CU collects independent per-CU reference configurations from the target CUs as follows.

[0039] To enable the LTM configuration process, the source CU transmits a HANDOVER REQUEST message 605 to one or more target CUs for which LTM is to be enabled with respect to the UE. At 610, the target CUs collect configuration information from their respective DUs. For example, target CU1 collects configuration information from target DU10 and target DU11, which are part of the same logical RAN node as CU1. Target CU2 collects configuration information from target DU20. In other examples, the target CUs may have many more DUs under their control, and the target CUs will collect configuration information from any associated DUs that include candidate cells for the LTM process. The target CUs create a per-CU reference configuration based on the information collected from the DUs. At 615, the respective target CUs respond with a HANDOVER REQUEST ACKNOWLEDGE message that includes the respective per-CU reference configuration. In some examples, the per-CU reference configuration is provided to the source CU by way of a different or additional message.

[0040] At 620, the source CU prepares per-CU containers with LTM candidate configurations (see, e.g., FIG. 3) . Each per-CU container prepared at 620 also includes a per-CU reference configuration (received from the target CUs) for the associated target CU. The per-CU reference configurations may be full configurations as would be configured by an RRC Reconfiguration message. In other words, the per-CU reference configurations may include the same parameters as the source reference configuration, but with parameter values for a given target CU.

[0041] The source CU transmits a UE CONTEXT MODIFICATION message 625 to the DU source DU that includes the per-CU containers. At 630A, the source CU transmits a downlink RRC MESSAGE TRANSFER command 630B to the DU. This command triggers the source DU to transmit an RRC Reconfiguration message to the UE that includes the per-CU containers. In some examples, different messaging or signaling may be used to transmit the per-CU reference configurations from the source CU to the UE.

[0042] At 690, in response to a MAC-CE based cell switch command that identifies a target cell that is supported by a target DU / target CU, the UE will apply the per-CU reference configuration from the container associated with the target CU before applying the LTM candidate configuration (also from the per-CU container for the target CU) associated with the target DU.

[0043] FIG. 6A shows a modified portion of TS 38.331, with modification underlined, in which a UE falls back to an ltm-CU-ReferenceConfiguration prior to applying an LTM candidate configuration. FIG. 6B shows a modified portion of TS 38.423 in which the final item shown in a HANDOVER REQUEST ACKNOWLEDGE message instructs the source CU to refrain from commanding the UE to apply the reference configuration included in the HANDOVER REQUEST ACKNOWLEDGE message.

[0044] In the example of FIG. 6, the source CU simply collects per-CU reference configurations from the target CUs and provides them to the UE. This simplifies the operation of the source CU, however significant signaling overhead may be involved at 615 when the target CUs provide their respective per-CU reference configurations to the source CU.

[0045] FIG. 7 illustrates an example source CU mediated LTM configuration process in which rather than providing a full reference configuration, the target CUs provide delta reference configurations to the source CU as follows.

[0046] To enable the LTM configuration process, the source CU transmits a HANDOVER REQUEST message 705 to one or more target CUs for which LTM is to be enabled with respect to the UE. The HANDOVER REQUEST message includes the source reference configuration and, as discussed above, may also include some additional guidance like the number of candidate cells that the target CU can include for the LTM configurations. At 710, the target CUs collect configuration information from their respective DUs. The target CUs create a per-CU delta reference configuration based on the information collected from the DUs. The per-CU delta reference configuration includes only parameters that are changed with respect to the source reference configuration. At 715, the respective target CUs respond with a HANDOVER REQUEST ACKNOWLEDGE message that includes the respective per-CU delta reference configuration. Since only delta reference configurations are included in the message 715, the signaling is significantly reduced as compared to the example LTM configuration process of FIG. 6. In some examples, the per-CU delta reference configuration is provided to the source CU by way of a different or additional message.

[0047] At 720, the source CU prepares per-CU containers with LTM candidate configurations (see, e.g., FIG. 3) . Each per-CU container prepared at 720 also includes a per-CU delta reference configuration (received from the target CUs) for the associated target CU.

[0048] The source CU transmits a UE CONTEXT MODIFICATION message 725 to the DU source DU that includes the per-CU containers. At 730A, the source CU transmits a downlink RRC MESSAGE TRANSFER command 730B to the DU. This command triggers the source DU to transmit an RRC Reconfiguration message to the UE that includes the per-CU containers. In some examples, different messaging or signaling may be used to transmit the per-CU reference configurations from the source CU to the UE.

[0049] At 790, in response to a MAC-CE based cell switch command that identifies a target cell that is supported by a target DU / target CU, the UE will apply the per-CU delta reference configuration from the container associated with the target CU to the source reference  configuration to generate the per-CU reference configuration for the target CU. The UE applies the per-CU reference configuration before applying the LTM candidate configuration (also from the per-CU container for the target CU) associated with the target DU. The UE may be already configured with a full RRC configuration for the source CU, the source reference configuration, by virtue of the fact that the UE is currently CONNECTED to the source CU. For example, the UE may have received the source reference configuration in a prior RRC Reconfiguration message that connected the UE to the source CU. In other examples, the UE receives the source reference configuration by way of other signaling or messages, or is included in the message 730B.

[0050] FIG. 7A shows a modified portion of TS 38.331, with modification underlined, in which a UE falls back to an ltm-CU-ReferenceConfiguration and then, for the fields and configurations to be released, applies an LTM candidate configuration. FIG. 7B shows a modified portion of TS 38.423 in which the HANDOVER REQUEST message instructs the target CUs to use the provided ReferenceConfiguration in the UE context information when the target CU prepares the UE configuration. FIG. 7C shows a modified portion of TS 38.423 in which the final item shown in a HANDOVER REQUEST ACKNOWLEDGE message informs the source CU that the reference configuration included in the HANDOVER REQUEST ACKNOWLEDGE message considered the source provided reference configuration as input (i.e., the included reference configuration has in it the source reference configuration applied or not) . FIG. 7D shows a modified portion of TS 38.423 in which the HANDOVER REQUEST IE is modified (as underlined) to include a reference configuration source field that contains the reference configuration that the target CUs can use when creating their own reference configurations. FIG. 7E shows a modified portion of TS 38.423 in which the HANDOVER REQUEST ACKNOWLEDGE IE is modified (as underlined) to include a reference configuration field for a per-CU reference configuration to be provided to the source CU.

[0051] In the example of FIG. 7, the source CU collects target CU delta reference configurations from the target CUs and provides them to the UE and the UE then applies the target per-CU delta reference configuration to the source reference configuration. This reduces the signaling between the target CUs and the source CU and the source CU and the UE, however  the UE is tasked with applying a delta reference configuration to a source reference configuration.

[0052] FIG. 8 illustrates an example source CU mediated LTM configuration process in which rather than providing a full reference configuration, the target CUs provide delta reference configurations to the source CU and the source CU compiles full per-CU reference configurations for each target CU as follows.

[0053] To enable the LTM configuration process, the source CU transmits a HANDOVER REQUEST message 805 to one or more target CUs for which LTM is to be enabled with respect to the UE. The HANDOVER REQUEST message includes the source reference configuration. At 810, the target CUs collect configuration information from their respective DUs. The target CUs create a per-CU delta reference configuration based on the information collected from the DUs. The per-CU delta reference configuration includes only parameters that are changed with respect to the source reference configuration. At 815, the respective target CUs respond with a HANDOVER REQUEST ACKNOWLEDGE message that includes the respective per-CU delta reference configuration. Since only delta reference configurations are included in the message 815, the signaling is significantly reduced as compared to the example LTM configuration process of FIG. 6. In some examples, the per-CU delta reference configuration is provided to the source CU by way of a different or additional message.

[0054] At 820, the source CU merges the target CU delta configurations with the source reference configuration to form per-CU reference configurations. The source CU prepares per-CU containers with LTM candidate configurations (see, e.g., FIG. 3) . Each per-CU container prepared at 720 also includes a per-CU reference configuration (created based on the delta reference configurations received from the target CUs) for the associated target CU.

[0055] The source CU transmits a UE CONTEXT MODIFICATION message 825 to the DU source DU that includes the per-CU containers. At 830A, the source CU transmits a downlink RRC MESSAGE TRANSFER command 830B to the DU. This command triggers the source DU to transmit an RRC Reconfiguration message to the UE that includes the per-CU containers. In some examples, different messaging or signaling may be used to transmit the per-CU reference configurations from the source CU to the UE.

[0056] At 890, in response to a MAC-CE based cell switch command that identifies a target cell that is supported by a target DU / target CU, the UE will apply the per-CU reference configuration from the container associated with the target CU before applying the LTM candidate configuration (also from the per-CU container for the target CU) associated with the target DU. In this manner, the UE may simply use the per-CU reference configuration found in the target CU container when performing a cell switch operation, without having to apply a delta reference configuration.

[0057] FIG. 9 illustrates an example source CU mediated LTM configuration process in which flexibility is provided for the type of per-CU reference configuration (full per-CU reference configuration or per-CU delta reference configuration) that is contained in the per-CU containers provided to the UE at LTM configuration.

[0058] To enable the LTM configuration process, the source CU transmits a HANDOVER REQUEST message 905 to one or more target CUs for which LTM is to be enabled with respect to the UE. The HANDOVER REQUEST message includes the source reference configuration. At 910, the target CUs collect configuration information from their respective DUs. Each target CU may either consider the source reference configuration and create a per-CU delta reference configuration based on the information collected from the DUs or not consider the source reference configuration and create a full per-CU reference configuration. At 915, the respective target CUs respond with a HANDOVER REQUEST ACKNOWLEDGE message that includes the respective per-CU delta reference configuration or full per-CU reference configuration. The message also includes a source reference indicator that indicates whether the provided per-CU reference configuration is a delta reference configuration (meaning source reference configuration was considered) or a full reference configuration (meaning source reference was not considered) . In some examples, the per-CU delta reference configuration is provided to the source CU by way of a different or additional message.

[0059] At 920, the source CU prepares per-CU containers with LTM candidate configurations (see, e.g., FIG. 3) . Each per-CU container prepared at 720 also includes a per-CU reference configuration that includes the source reference indicator which indicates whether the  per-CU reference configuration is a full per-CU reference configuration or a delta reference configuration as described above.

[0060] The source CU transmits a UE CONTEXT MODIFICATION message 925 to the DU source DU that includes the per-CU containers. At 930A, the source CU transmits a downlink RRC MESSAGE TRANSFER command 930B to the DU. This command triggers the source DU to transmit an RRC Reconfiguration message to the UE that includes the per-CU containers. In some examples, different messaging or signaling may be used to transmit the per-CU reference configurations from the source CU to the UE.

[0061] At 990, in response to a MAC-CE based cell switch command that identifies a target cell that is supported by a target DU / target CU, the UE will, when the source reference indicator indicates that the source reference configuration was not considered, apply the per-CU reference configuration from the container associated with the target CU before applying the LTM candidate configuration (also from the per-CU container for the target CU) associated with the target DU. In this manner, the UE may simply use the per-CU reference configuration found in the target CU container when performing a cell switch operation.

[0062] When the source reference indicator indicates that the source reference configuration was considered, the UE will apply the per-CU reference configuration from the container associated with the target CU to the source reference configuration to generate the per-CU reference configuration for the target CU. The UE applies the per-CU reference configuration before applying the LTM candidate configuration (also from the per-CU container for the target CU) associated with the target DU.

[0063] FIG. 9A shows a modified portion of TS 38.423 in which HANDOVER REQUEST ACKNOWLEDGE IE is modified (as underlined) to include an IE which informs if the source reference configuration was used or not. FIG. 9B shows a modified portion of TS 38.331 in which a field or parameter useSourceRefConfig-R19 (circled) is included in an LTM-CU-Config-r19 IE.

[0064] There are several approaches to providing an CSI configuration for LTM reference configuration purposes. In one example, the per-CU reference configuration includes an LTM-CSI-Configuration. In this manner the source CU may identify the target CU reference  configuration based on a per-CU reference configuration identifier or based on an LTM-CSI configuration identifier. The UE applies this LTM-CSI-Configuration before applying the candidate specific LTM-CSI-Configuration. In one example, even with per-CU reference configuration identifiers, the network only includes the radio-bearer configuration per-CU, and the LTM CSI configuration is global, meaning there is only one LTM CSI configuration. FIG. 10 shows a modified portion of TS 38.331 that includes (in bold) an exception for the parameter ltm-CSI-ResourceConfig in a provided ltm-CU-ReferenceConfiguration.

[0065] FIG. 11 is a flow diagram outlining an example method 1100 for configuring a UE for LTM. The method 1100 may be performed by the UE of FIGs. 4, 6, 7, 8, or 9. The method includes, at 1110, receiving a medium access control (MAC) control element (CE) that includes a command to switch from a source cell associated with a source distributed unit (DU) to a target cell associated with a target DU, wherein the source DU is controlled by a source centralized unit (CU) and the target DU is controlled by a target CU, different from the source CU. In some examples, the method includes identifying the reference configuration based on a per-CU reference configuration identifier or an LTM channel state information (CSI) configuration identifier.

[0066] At 1120, the method includes applying a reference configuration associated with the target CU. 2. In some examples, see FIGs. 6 and 8, the method includes receiving per-CU reference configurations, including the reference configuration associated with the target CU, during an RRC Reconfiguration process.

[0067] In some examples, see FIG. 7, the method includes determining the reference configuration associated with the target CU by identifying a source reference configuration and a delta reference configuration associated with the target CU and applying the delta reference configuration associated with the target CU to the source reference configuration to generate the reference configuration associated with the target CU. In some examples, the method includes receiving the per-CU delta reference configurations, including the delta reference configuration associated with the target CU, during an RRC Reconfiguration process. In some examples, the method includes receiving the source reference configuration from the source CU, during an RRC Reconfiguration process.

[0068] In some examples, see FIG. 9, the method includes determining the reference configuration associated with the target CU by identifying a per-CU reference configuration associated with the target CU and a source reference configuration, wherein the per-CU reference configuration includes an indicator that indicates whether the per-CU reference configuration is a delta reference configuration. When the indicator indicates that the per-CU reference configuration is a delta reference configuration, the method includes applying the per-CU reference configuration associated with the target CU to the source reference configuration. When the indicator indicates that the per-CU reference configuration is not a delta reference configuration, the method includes determining that the per-CU reference configuration is the reference configuration without applying the per-CU reference configuration associated with the target CU to the source reference configuration.

[0069] The method includes, at 1130, applying a Layer 2 triggered mobility (LTM) candidate configuration associated with the target DU and, at 1140, communicating with the target DU.

[0070] FIG. 12 is a flow diagram outlining an example method 1200 for configuring a UE for LTM. The method 1200 may be performed by the source CU of FIGs. 4, 6, 7, 8, or 9. The method includes, at 1210, collecting information related to one or more reference configurations associated with respective one or more target centralized units (CUs) . At 1220, the information related to one or more reference configurations is provided to a UE for use in LTM-based cell switching.

[0071] In some examples, see FIG. 6, the method includes collecting a per-CU reference configuration from each of the one or more target CUs and providing the per-CU reference configurations to the UE.

[0072] In some examples, see FIG. 7, the method includes providing a source reference configuration to the one or more target CUs, collecting a per-CU delta reference configuration from the one or more target CUs, and providing the per-CU delta reference configurations to the UE.

[0073] In some examples, see FIG. 8, the method includes providing a source reference configuration to the one or more target CUs, collecting a per-CU delta reference configuration from the one or more target CUs, applying the per-CU delta reference configurations to the source reference configuration to generate respective per-CU reference configurations, and providing the  per-CU reference configurations to the UE.

[0074] In some examples, see FIG. 9, the method includes providing a source reference configuration to the one or more target CUs, collecting a per-CU delta reference configuration from the one or more target CUs, wherein each per-CU delta reference configuration includes an associated indicator that indicates whether the source reference configuration was considered for the per-CU delta reference configuration, and providing the per-CU delta reference configurations and the associated indicators to the UE.

[0075] Included herein are several flow diagrams outlining example methods. In this description and the appended claims, use of the term “determine” with reference to some entity (e.g., parameter, variable, and so on) in describing a method step or function is to be construed broadly. For example, “determine” is to be construed to encompass, for example, receiving and parsing a communication that encodes the entity or a value of an entity. “Determine” should be construed to encompass accessing and reading memory (e.g., lookup table, register, device memory, remote memory, and so on) that stores the entity or value for the entity. “Determine” should be construed to encompass computing or deriving the entity or value of the entity based on other quantities or entities. “Determine” should be construed to encompass any manner of deducing or identifying an entity or value of the entity.

[0076] As used herein, the term identify when used with reference to some entity or value of an entity is to be construed broadly as encompassing any manner of determining the entity or value of the entity. For example, the term identify is to be construed to encompass, for example, receiving and parsing a communication that encodes the entity or a value of the entity. The term identify should be construed to encompass accessing and reading memory (e.g., device queue, lookup table, register, device memory, remote memory, and so on) that stores the entity or value for the entity.

[0077] As used herein, the term select when used with reference to some entity or value of an entity is to be construed broadly as encompassing any manner of determining the entity or value of the entity from amongst a plurality or range of possible choices. For example, the term select is to be construed to encompass accessing and reading memory (e.g., lookup table, register, device memory, remote memory, and so on) that stores the entities or values for the entity and  returning one entity or entity value from amongst those stored. The term select is to be construed as applying one or more constraints or rules to an input set of parameters to determine an appropriate entity or entity value. The term select is to be construed as broadly encompassing any manner of choosing an entity based on one or more parameters or conditions.

[0078] As used herein, the term derive when used with reference to some entity or value of an entity is to be construed broadly. “Derive” should be construed to encompass accessing and reading memory (e.g., lookup table, register, device memory, remote memory, and so on) that stores some initial value or foundational values and performing processing and / or logical / mathematical operations on the value or values to generate the derived entity or value for the entity. “Derive” should be construed to encompass computing or calculating the entity or value of the entity based on other quantities or entities. “Derive” should be construed to encompass any manner of deducing or identifying an entity or value of the entity.

[0079] The term “couple” is used throughout the specification. The term may cover connections, communications, or signal paths that enable a functional relationship consistent with the description of the present disclosure. For example, if device A generates a signal to control device B to perform an action, in a first example device A is coupled to device B, or in a second example device A is coupled to device B through intervening component C if intervening component C does not substantially alter the functional relationship between device A and device B such that device B is controlled by device A via the control signal generated by device A.

[0080] As used herein, the term “provide” when used with reference to information or data or a signal encoding data is to be construed broadly as encompassing any manner of communicating the information, data, or signal encoding data either explicitly or implicitly. “Provide” should be construed to encompass transmitting a message that indicates the information or data, storing the information or data in memory accessible to the recipient of the providing, controlling electrical signals on conductors in a circuit to encode the information or data, and so on.

[0081] As used herein, the term “obtain” when used with reference to information or data or a signal encoding data is to be construed broadly as encompassing any manner of receiving the  information, data, or signal encoding data either explicitly or implicitly. “Obtain” should be construed to encompass receiving a message that indicates the information or data, reading the information or data from memory, performing computations or processing on other data to obtain the information or data, detecting electrical signals on conductors in a circuit detect the information or data, and so on.

[0082] FIG. 13 is an example network 1300 that supports inter-CU LTM according to one or more implementations described herein. Example network 1300 may include UEs 1311-1, 1311-2, a radio access network (RAN) 1320, a core network (CN) 1330, application servers 1340, and external networks 1350.

[0083] The systems and devices of example network 1300 may operate in accordance with one or more communication standards, such as 2nd generation (2G) , 3rd generation (3G) , 4th generation (4G) (e.g., long-term evolution (LTE) ) , and / or 5th generation (5G) (e.g., new radio (NR) ) communication standards of the 3rd generation partnership project (3GPP) . Additionally, or alternatively, one or more of the systems and devices of example network 1300 may operate in accordance with other communication standards and protocols discussed herein, including future versions or generations of 3GPP standards (e.g., sixth generation (6G) standards, seventh generation (7G) standards, etc. ) , institute of electrical and electronics engineers (IEEE) standards (e.g., wireless metropolitan area network (WMAN) , worldwide interoperability for microwave access (WiMAX) , etc. ) , and more.

[0084] As shown, the UE 1311 may include a smartphone (e.g., handheld touchscreen mobile computing devices connectable to one or more wireless communication networks) . Additionally, or alternatively, the UE 1311 may include other types of mobile or non-mobile computing devices capable of wireless communications, such as personal data assistants (PDAs) , pagers, laptop computers, desktop computers, wireless handsets, watches etc.

[0085] Additionally, or alternatively, an IoT device may utilize one or more types of technologies, such as machine-to-machine (M2M) communications or machine-type communications (MTC) (e.g., to exchanging data with an MTC server or other device via a public land mobile network (PLMN) ) , proximity-based service (ProSe) or device-to-device (D2D) communications, sensor networks, IoT networks, and more. Depending on the scenario,  an M2M or MTC exchange of data may be a machine-initiated exchange, and an IoT network may include interconnecting IoT UEs (which may include uniquely identifiable embedded computing devices within an Internet infrastructure) with short-lived connections. In some scenarios, IoT UEs may execute background applications (e.g., keep-alive messages, status updates, etc. ) to facilitate the connections of the IoT network.

[0086] The UE 1311 may include stored inter-CU LTM instructions and information to enable the UE to perform operations disclosed above with reference to FIGs. 4-10.

[0087] The UE 1311 may communicate and establish a connection with (e.g., be communicatively coupled) with RAN 1320, which may involve a wireless channel that carriers a D2R signal 1312, which may comprise a physical communications interface  / layer.

[0088] As shown, UE 1311 may also, or alternatively, connect to access point (AP) 1316 via connection interface 1318, which may include an air interface enabling UE 1311 to communicatively couple with AP 1316. AP 1316 may comprise a wireless local area network (WLAN) , WLAN node, WLAN termination point, etc. The connection 1318 may comprise a local wireless connection, such as a connection consistent with any IEEE 702.11 protocol, and AP 1316 may comprise a wireless fidelity  router or other AP. While not explicitly depicted in FIG. 13, AP 1316 may be connected to another network (e.g., the Internet) without connecting to RAN 1320 or CN 1330.

[0089] RAN 1320 may include one or more RAN nodes 1322-1 and 1322-2 (referred to collectively as RAN nodes 1322, and individually as RAN node 1322) that enable channel 1314 to be established between the UE 1311 and RAN 1320. RAN nodes 1322 may include network access points configured to provide radio baseband functions for data and / or voice connectivity between users and the network based on one or more of the communication technologies described herein (e.g., 2G, 3G, 4G, 5G, WiFi, etc. ) . As examples therefore, a RAN node may be an E-UTRAN Node B (e.g., an enhanced Node B, eNodeB, eNB, 4G base station, etc. ) , a next generation base station (e.g., a 5G base station, NR base station, next generation eNBs (gNB) , etc. ) . RAN nodes 1322 may include a roadside unit (RSU) , a transmission reception point (TRxP or TRP) , and one or more other types of ground stations (e.g., terrestrial access points) . In some scenarios, RAN node 1322 may be a dedicated physical device, such as a macrocell base station,  and / or a low power (LP) base station for providing femtocells, picocells or the like having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells. Additionally, or alternatively, one or more of RAN nodes 1322 can be next generation eNBs (i.e., gNBs) that can provide evolved universal terrestrial radio access (E-UTRA) user plane and control plane protocol terminations 1326, 1328 toward UEs 1311, and that can be connected to a 5G core network (5GC) 130 via an NG interface 1324.

[0090] In some implementations, an individual RAN node 1322 may represent individual gNB-distributed units (DUs) connected to a gNB-control unit (CU) via individual F1 or other interfaces. In such implementations, the gNB-DUs may include one or more remote radio heads or radio frequency (RF) front end modules (RFEMs) , and the gNB-CU may be operated by a server (not shown) located in RAN 1320 or by a server pool (e.g., a group of servers configured to share resources) in a similar manner as the CRAN / vBBUP. Additionally, or alternatively, one or more of RAN nodes 1322 may be next generation eNBs (i.e., gNBs) that may provide evolved universal terrestrial radio access (E-UTRA) user plane and control plane protocol terminations toward UEs 1311, and that may be connected to a 5G core network (5GC) 1330 via an NG interface.

[0091] Any of the RAN nodes 1322 can terminate an air interface protocol and can be the first point of contact for UEs 1311. In some implementations, any of the RAN nodes 1322 can fulfill various logical functions for the RAN 1320 including, but not limited to, radio network controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management. UE 1311 can be configured to communicate using orthogonal frequency-division multiplexing (OFDM) communication signals with each other or with any of the RAN nodes 1322 over a multicarrier communication channel in accordance with various communication techniques, such as, but not limited to, an OFDMA communication technique (e.g., for downlink communications) or a single carrier frequency-division multiple access (SC-FDMA) communication technique (e.g., for uplink and ProSe or sidelink (SL) communications) , although the scope of such implementations are not necessarily limited in this regard. The OFDM signals can comprise a plurality of orthogonal subcarriers.

[0092] The RAN nodes 1322 may be configured to communicate with one another via interface 1323. In implementations where the system is an LTE system, interface 1323 may be an X2 interface. In NR systems, interface 1323 may be an Xn interface. The X2 interface may be defined between two or more RAN nodes 1322 (e.g., two or more eNBs  / gNBs or a combination thereof) that connect to evolved packet core (EPC) or CN 1330, or between two eNBs connecting to an EPC.

[0093] The RAN nodes 1322 may include stored inter-CU LTM instructions and information to enable the RAN nodes to perform operations disclosed above with reference to FIGs. 4-10.

[0094] CN 1330 may comprise a plurality of network elements or nodes 1332, which are configured to offer various data and telecommunications services to customers / subscribers (e.g., users of UEs 1311) who are connected to the CN 1330 via the RAN 1320. In some implementations, CN 1330 may include an evolved packet core (EPC) , a 5G CN, and / or one or more additional or alternative types of CNs. The components of the CN 1330 may be implemented in one physical node or separate physical nodes including components to read and execute instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium. The CN 1331 may include stored inter-CU LTM instructions and information to enable the CN to perform operations disclosed above with reference to FIGs. 4-10.

[0095] As shown, CN 1330, application servers 1340, and external networks 1350 may be connected to one another via interfaces 1334, 1336, and 1338, which may include IP network interfaces.

[0096] FIG. 14 is a diagram of an example of components of a device according to one or more implementations described herein. In some implementations, the device 1400 can include application circuitry 1402, baseband circuitry 1404, RF circuitry 1406, front-end module (FEM) circuitry 1408, one or more antennas 1410, and power management circuitry (PMC) 1412 coupled together at least as shown. In some implementations, the device 1400 can include fewer elements (e.g., a RAN node may not utilize application circuitry 1402, and instead include a processor / controller to process IP data received from a CN or an Evolved Packet Core (EPC) ) . In some implementations, the device 1400 can include additional elements such as, for example,  memory / storage, display, camera, sensor (including one or more temperature sensors, such as a single temperature sensor, a plurality of temperature sensors at different locations in device 1400, etc. ) , or input / output (I / O) interface. In other implementations, the components described below can be included in more than one device (e.g., said circuitries can be separately included in more than one device for Cloud-RAN (C-RAN) implementations) .

[0097] The baseband circuitry 1404 can include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 1404 can include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry 1406 and to generate baseband signals for a transmit signal path of the RF circuitry 1406. Baseband circuitry 1404 can interface with the application circuitry 1402 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 1406. For example, in some implementations, the baseband circuitry 1404 can include a 3G baseband processor 1404A, a 4G baseband processor 1404B, a 5G baseband processor 1404C, or other baseband processor (s) 1404D for other existing generations, generations in development or to be developed in the future (e.g., 5G, 6G, etc. ) .

[0098] The baseband circuitry 1404 (e.g., one or more of baseband processors 1404A-D) can handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 1406. In other implementations, some or all of the functionality of baseband processors 1404A-D can be included in modules stored in the memory 1404G and executed via a Central Processing Unit (CPU) 1404E. The radio control functions can include, but are not limited to, signal modulation / demodulation, encoding / decoding, radio frequency shifting, etc. In some implementations, modulation / demodulation circuitry of the baseband circuitry 1404 can include Fast-Fourier Transform (FFT) , precoding, or constellation mapping / de-mapping functionality. In some implementations, encoding / decoding circuitry of the baseband circuitry 1404 can include convolution, tail-biting convolution, turbo, Viterbi, or Low-Density Parity Check (LDPC) encoder / decoder functionality. Implementations of modulation / demodulation and encoder / decoder functionality are not limited to these examples and can include other suitable functionality in other implementations.

[0099] In some implementations, memory 1404G may receive and / or store inter-CU LTM instructions and information to enable the device to perform operations disclosed above with reference to FIGs. 4-10.

[0100] In some implementations, the baseband circuitry 1404 can include one or more audio digital signal processor (s) (DSP) 1404F. The audio DSPs 1404F can include elements for compression / decompression and echo cancellation and can include other suitable processing elements in other implementations.

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

[0102] In some implementations, the receive signal path of the RF circuitry 1406 can include mixer circuitry 1406A, amplifier circuitry 1406B and filter circuitry 1406C. RF circuitry 1406 can also include synthesizer circuitry 1406D for synthesizing a frequency for use by the mixer circuitry 1406A of the receive signal path and the transmit signal path.

[0103] The RF circuitry 1406 can include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 1404 can include a digital baseband interface to communicate with the RF circuitry 1406.

[0104] Synthesizer circuitry 1406D of the RF circuitry 1406 can include a divider, a delay-locked loop (DLL) , a multiplexer and a phase accumulator.

[0105] FEM circuitry 1408 can include a receive signal path which can include circuitry configured to operate on RF signals received from one or more antennas 1410, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 1406 for further processing. FEM circuitry 1408 can also include a transmit signal path which  can include circuitry configured to amplify signals for transmission provided by the RF circuitry 1406 for transmission by one or more of the one or more antennas 1410. In various implementations, the amplification through the transmit or receive signal paths can be done solely in the RF circuitry 1406, solely in the FEM circuitry 1408, or in both the RF circuitry 1406 and the FEM circuitry 1408.

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

[0107] While FIG. 14 shows the PMC 1412 coupled only with the baseband circuitry 1404. However, in other implementations, the PMC 1412 may be additionally or alternatively coupled with, and perform similar power management operations for, other components such as, but not limited to, application circuitry 1402, RF circuitry 1406, or FEM circuitry 1408.

[0108] In this regard, while the disclosed subject matter has been described in connection with various examples, implementations, aspects, etc., and corresponding Figures, where applicable, it is to be understood that other similar aspects can be used or modifications and additions can be made to the disclosed subject matter for performing the same, similar, alternative, or substitute function of the subject matter without deviating therefrom. Therefore, the disclosed subject matter should not be limited to any single example, implementation, or aspect described herein, but rather should be construed in breadth and scope in accordance with the appended claims below.

[0109] In particular regard to the various functions performed by the above described components or structures (assemblies, devices, circuits, systems, etc. ) , the terms (including a reference to a “means” ) used to describe such components are intended to correspond, unless otherwise indicated, to any component or structure which performs the specified function of the described component (e.g., that is functionally equivalent) , even though not structurally equivalent to the disclosed structure which performs the function in the herein illustrated  exemplary implementations. In addition, while a particular feature may have been disclosed with respect to only one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired and advantageous for any given application.

[0110] As used herein, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or” . That is, unless specified otherwise, or clear from context, “X employs A or B” is intended to mean any of the natural inclusive permutations. That is, if X employs A; X employs B; or X employs both A and B, then “X employs A or B” is satisfied under any of the foregoing instances. In addition, the articles “a” and “an” as used in this application and the appended claims should generally be construed to mean “one or more” unless specified otherwise or clear from context to be directed to a singular form. Furthermore, to the extent that the terms “including” , “includes” , “having” , “has” , “with” , or variants thereof are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term “comprising. ” Additionally, in situations wherein one or more numbered items are discussed (e.g., a “first X” , a “second X” , etc. ) , in general the one or more numbered items can be distinct, or they can be the same, although in some situations the context may indicate that they are distinct or that they are the same.

[0111] While the methods are illustrated and described above as a series of acts or events, it will be appreciated that the illustrated ordering of such acts or events are not to be interpreted in a limiting sense. For example, some acts may occur in different orders and / or concurrently with other acts or events apart from those illustrated and / or described herein. In addition, not all illustrated acts may be required to implement one or more aspects or examples of the disclosure herein. Also, one or more of the acts depicted herein may be carried out in one or more separate acts and / or phases. In some examples, the methods illustrated above may be implemented in a computer readable medium using instructions stored in a memory. Many other examples and variations are possible within the scope of the claimed disclosure.

[0112] Examples

[0113] Example 1 is a baseband processor, including a memory configured to store instructions and a processing circuitry coupled to the memory and, when executing instructions,  configured to: receive a medium access control (MAC) control element (CE) that includes a command to switch from a source cell associated with a source distributed unit (DU) to a target cell associated with a target DU, wherein the source DU is controlled by a source centralized unit (CU) and the target DU is controlled by a target CU, different from the source CU; apply a reference configuration associated with the target CU; apply a Layer 2 triggered mobility (LTM) candidate configuration associated with the target DU; and communicate, based at least in part on the reference configuration and the LTM candidate configuration, with the target DU.

[0114] Example 2 includes the subject matter of example 1, including or omitting optional elements, wherein the processing circuitry is configured to receive per-CU reference configurations, including the reference configuration associated with the target CU, during an RRC Reconfiguration process.

[0115] Example 3 includes the subject matter of example 1, including or omitting optional elements, wherein the processing circuitry is configured to determine the reference configuration associated with the target CU by identifying a source reference configuration and a delta reference configuration associated with the target CU; and apply the delta reference configuration associated with the target CU to the source reference configuration to generate the reference configuration associated with the target CU.

[0116] Example 4 includes the subject matter of example 3, including or omitting optional elements, wherein the processing circuitry is configured to receive per-CU delta reference configurations, including the delta reference configuration associated with the target CU, during an RRC Reconfiguration process.

[0117] Example 5 includes the subject matter of example 3, including or omitting optional elements, wherein the processing circuitry is configured to receive the source reference configuration from the source CU, during an RRC Reconfiguration process.

[0118] Example 6 includes the subject matter of example 1, including or omitting optional elements, wherein the processing circuitry is configured to determine the reference configuration associated with the target CU by identifying a per-CU reference configuration associated with the target CU and a source reference configuration, wherein the per-CU reference configuration includes an indicator that indicates whether the per-CU reference configuration is a delta reference  configuration; when the indicator indicates that the per-CU reference configuration is a delta reference configuration, applying the per-CU reference configuration associated with the target CU to the source reference configuration; and when the indicator indicates that the per-CU reference configuration is not a delta reference configuration, determining that the per-CU reference configuration is the reference configuration without applying the per-CU reference configuration associated with the target CU to the source reference configuration.

[0119] Example 7 includes the subject matter of any of examples 1-6, including or omitting optional elements, wherein the processing circuitry is configured to identify the reference configuration based on a per-CU reference configuration identifier or an LTM channel state information (CSI) configuration identifier.

[0120] Example 8 includes the subject matter of example 7, including or omitting optional elements, wherein the per-CU reference configuration identifier or the LTM CSI configuration identifier is included in the command.

[0121] Example 9 is a wireless communication device, including a memory and processing circuitry configured to, when executing instructions stored in the memory, collect information related to one or more reference configurations associated with respective one or more target centralized units (CUs) ; and provide the information related to one or more reference configurations to a user equipment (UE) for use in LTM-based cell switching.

[0122] Example 10 includes the subject matter of example 9, including or omitting optional elements, wherein the processing circuitry is configured to collect a per-CU reference configuration from each of the one or more target CUs; and provide the per-CU reference configurations to the UE.

[0123] Example 11 includes the subject matter of example 9, including or omitting optional elements, wherein the processing circuitry is configured to provide a source reference configuration to the one or more target CUs; collect a per-CU delta reference configuration from the one or more target CUs; and provide the per-CU delta reference configurations to the UE.

[0124] Example 12 includes the subject matter of example 9, including or omitting optional elements, wherein the processing circuitry is configured to provide a source reference  configuration to the one or more target CUs; collect a per-CU delta reference configuration from the one or more target CUs; and apply the per-CU delta reference configurations to the source reference configuration to generate respective per-CU reference configurations; and provide the per-CU reference configurations to the UE.

[0125] Example 13 includes the subject matter of example 9, including or omitting optional elements, wherein the processing circuitry is configured to provide a source reference configuration to the one or more target CUs; collect a per-CU delta reference configuration from the one or more target CUs, wherein each per-CU delta reference configuration includes an associated indicator that indicates whether the source reference configuration was considered for the per-CU delta reference configuration; and provide the per-CU delta reference configurations and the associated indicators to the UE.

[0126] Example 14 includes the subject matter of any of examples 9-13, including or omitting optional elements, wherein the processing circuitry is configured to include a per-CU reference configuration identifier or an LTM channel state information (CSI) configuration identifier to the UE in an LTM-based cell switch command.

[0127] Example 15 includes the subject matter of any of examples 9-13, including or omitting optional elements, wherein the processing circuitry is configured to include operating parameters to the one or more target CUs prior to collecting the information related to one or more reference configurations.

[0128] Example 16 is a user equipment (UE) , including: radio frequency (RF) circuitry; and baseband processing circuitry configured to receive a medium access control (MAC) control element (CE) that includes a command to switch from a source cell associated with a source distributed unit (DU) to a target cell associated with a target DU, wherein the source DU is controlled by a source centralized unit (CU) and the target DU is controlled by a target CU, different from the source CU; apply a reference configuration associated with the target CU; apply a Layer 2 triggered mobility (LTM) candidate configuration associated with the target DU; and control the RF circuitry to communicate with the target DU based at least on the reference configuration and the LTM candidate configuration.

[0129] Example 17 includes the subject matter of example 16, including or omitting optional  elements, wherein the baseband processing circuitry is configured to receive per-CU reference configurations, including the reference configuration associated with the target CU, during an RRC Reconfiguration process.

[0130] Example 18 includes the subject matter of example 16, including or omitting optional elements, wherein the baseband processing circuitry is configured to determine the reference configuration associated with the target CU by identifying a source reference configuration and a delta reference configuration associated with the target CU; and apply the delta reference configuration associated with the target CU to the source reference configuration to generate the reference configuration associated with the target CU.

[0131] Example 19 includes the subject matter of example 18, including or omitting optional elements, wherein the baseband processing circuitry is configured to receive per-CU delta reference configurations, including the delta reference configuration associated with the target CU, during an RRC Reconfiguration process.

[0132] Example 20 includes the subject matter of example 16, including or omitting optional elements, wherein the baseband processing circuitry is configured to determine the reference configuration associated with the target CU by identifying a per-CU reference configuration associated with the target CU and a source reference configuration, wherein the per-CU reference configuration includes an indicator that indicates whether the per-CU reference configuration is a delta reference configuration; when the indicator indicates that the per-CU reference configuration is a delta reference configuration, applying the per-CU reference configuration associated with the target CU to the source reference configuration; and when the indicator indicates that the per-CU reference configuration is not a delta reference configuration, determining that the per-CU reference configuration is the reference configuration without applying the per-CU reference configuration associated with the target CU to the source reference configuration.

[0133] Example 21 is a method as substantially described herein with reference to each or any combination substantially described herein, comprised in examples 1-20, or in the Detailed Description.

[0134] Example 22 is a non-transitory computer readable medium as substantially described herein with reference to each or any combination substantially described herein, comprised in examples 1-20, or in the Detailed Description.

[0135] Example 23 is a user equipment as substantially described herein with reference to each or any combination substantially described herein, comprised in examples 1-20, or in the Detailed Description.

[0136] Example 24 is a base station as substantially described herein with reference to each or any combination substantially described herein, comprised in examples 1-20, or in the Detailed Description.

[0137] Example 25 is a wireless device configured to perform any action or combination of actions as substantially described herein, comprised in examples 1-20, or in the Detailed Description.

[0138] Example 26 is an apparatus including the baseband processor or processor of examples 1-20.

[0139] It is well understood that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. In particular, personally identifiable information data should be managed and handled so as to minimize risks of unintentional or unauthorized access or use, and the nature of authorized use should be clearly indicated to users.

Claims

1.A baseband processor, comprising a memory configured to store instructions and a processing circuitry coupled to the memory and, when executing instructions, configured to:receive a medium access control (MAC) control element (CE) that includes a command to switch from a source cell associated with a source distributed unit (DU) to a target cell associated with a target DU, wherein the source DU is controlled by a source centralized unit (CU) and the target DU is controlled by a target CU, different from the source CU;apply a reference configuration associated with the target CU;apply a Layer 2 triggered mobility (LTM) candidate configuration associated with the target DU; andcommunicate, based at least in part on the reference configuration and the LTM candidate configuration, with the target DU.2.The baseband processor of claim 1, wherein the processing circuitry is configured to receive per-CU reference configurations, including the reference configuration associated with the target CU, during an RRC Reconfiguration process.3.The baseband processor of claim 1, wherein the processing circuitry is configured to determine the reference configuration associated with the target CU byidentifying a source reference configuration and a delta reference configuration associated with the target CU; andapply the delta reference configuration associated with the target CU to the source reference configuration to generate the reference configuration associated with the target CU.4.The baseband processor of claim 3, wherein the processing circuitry is configured to receive per-CU delta reference configurations, including the delta reference configuration associated with the target CU, during an RRC Reconfiguration process.5.The baseband processor of claim 3, wherein the processing circuitry is configured to receive the source reference configuration from the source CU, during an RRC Reconfiguration process.6.The baseband processor of claim 1, wherein the processing circuitry is configured to determine the reference configuration associated with the target CU byidentifying a per-CU reference configuration associated with the target CU and a source reference configuration, wherein the per-CU reference configuration includes an indicator that indicates whether the per-CU reference configuration is a delta reference configuration;when the indicator indicates that the per-CU reference configuration is a delta reference configuration, applying the per-CU reference configuration associated with the target CU to the source reference configuration; andwhen the indicator indicates that the per-CU reference configuration is not a delta reference configuration, determining that the per-CU reference configuration is the reference configuration without applying the per-CU reference configuration associated with the target CU to the source reference configuration.7.The baseband processor of any of claims 1-6, wherein the processing circuitry is configured to identify the reference configuration based on a per-CU reference configuration identifier or an LTM channel state information (CSI) configuration identifier.8.The baseband processor of claim 7, wherein the per-CU reference configuration identifier or the LTM CSI configuration identifier is included in the command.9.A wireless communication device, comprising a memory and processing circuitry configured to, when executing instructions stored in the memory,collect information related to one or more reference configurations associated with respective one or more target centralized units (CUs) ; andprovide the information related to one or more reference configurations to a user equipment (UE) for use in LTM-based cell switching.10.The wireless communication device of claim 9, wherein the processing circuitry is configured tocollect a per-CU reference configuration from each of the one or more target CUs; andprovide the per-CU reference configurations to the UE.11.The wireless communication device of claim 9, wherein the processing circuitry is configured toprovide a source reference configuration to the one or more target CUs;collect a per-CU delta reference configuration from the one or more target CUs; andprovide the per-CU delta reference configurations to the UE.12.The wireless communication device of claim 9, wherein the processing circuitry is configured toprovide a source reference configuration to the one or more target CUs;collect a per-CU delta reference configuration from the one or more target CUs; andapply the per-CU delta reference configurations to the source reference configuration to generate respective per-CU reference configurations; andprovide the per-CU reference configurations to the UE.13.The wireless communication device of claim 9, wherein the processing circuitry is configured toprovide a source reference configuration to the one or more target CUs;collect a per-CU delta reference configuration from the one or more target CUs, wherein each per-CU delta reference configuration includes an associated indicator that indicates whether the source reference configuration was considered for the per-CU delta reference configuration; andprovide the per-CU delta reference configurations and the associated indicators to the UE.14.The wireless communication device of any of claims 9-13, wherein the processing circuitry is configured to include a per-CU reference configuration identifier or an LTM channel state information (CSI) configuration identifier to the UE in an LTM-based cell switch command.15.The wireless communication device of any of claims 9-13, wherein the processing circuitry is configured to include operating parameters to the one or more target CUs prior to collecting the information related to one or more reference configurations.16.A user equipment (UE) , comprising:radio frequency (RF) circuitry; andbaseband processing circuitry configured toreceive a medium access control (MAC) control element (CE) that includes a command to switch from a source cell associated with a source distributed unit (DU) to a target cell associated with a target DU, wherein the source DU is controlled by a source centralized unit (CU) and the target DU is controlled by a target CU, different from the source CU;apply a reference configuration associated with the target CU;apply a Layer 2 triggered mobility (LTM) candidate configuration associated with the target DU; andcontrol the RF circuitry to communicate with the target DU based at least on the reference configuration and the LTM candidate configuration.17.The UE of claim 16, wherein the baseband processing circuitry is configured to receive per-CU reference configurations, including the reference configuration associated with the target CU, during an RRC Reconfiguration process.18.The UE of claim 16, wherein the baseband processing circuitry is configured to  determine the reference configuration associated with the target CU byidentifying a source reference configuration and a delta reference configuration associated with the target CU; andapply the delta reference configuration associated with the target CU to the source reference configuration to generate the reference configuration associated with the target CU.19.The UE of claim 18, wherein the baseband processing circuitry is configured to receive per-CU delta reference configurations, including the delta reference configuration associated with the target CU, during an RRC Reconfiguration process.20.The UE of claim 16, wherein the baseband processing circuitry is configured to determine the reference configuration associated with the target CU byidentifying a per-CU reference configuration associated with the target CU and a source reference configuration, wherein the per-CU reference configuration includes an indicator that indicates whether the per-CU reference configuration is a delta reference configuration;when the indicator indicates that the per-CU reference configuration is a delta reference configuration, applying the per-CU reference configuration associated with the target CU to the source reference configuration; andwhen the indicator indicates that the per-CU reference configuration is not a delta reference configuration, determining that the per-CU reference configuration is the reference configuration without applying the per-CU reference configuration associated with the target CU to the source reference configuration.

Images