Fast Uplink (UL) Access on LTM Candidate Cells

Abstract

A method implemented by user equipment for uplink access on an L1 / L2 trigger cell-to-cell mobility (LTM) candidate cell. The method includes receiving an LTM configuration for at least one LTM candidate cell from a network node, receiving a trigger from the network node, and receiving a first synchronization signal from the LTM candidate cell. The method further includes transmitting a UL signal to the LTM candidate cell during a UL resource opportunity in response to receiving the trigger, the UL signal being transmitted by the UL resource opportunity occurring during a time period between receiving the trigger and receiving the first synchronization signal from the LTM candidate cell. The first synchronization signal is received after the trigger has been received. The relevant network node method, UE, and network node are also disclosed.

Description

[Technical Field]

[0001] This disclosure relates to wireless communication systems, and more particularly to establishing timing matching in wireless communication systems. [Background technology]

[0002] Generally, different user equipment (UE) devices within the same cell are located at different positions within the cell and at different distances from the base station (e.g., NR g node B). Transmissions from different UEs can have the disadvantage of different delays before the transmission reaches the base station. To ensure that uplink (UL) transmissions from UEs reach the base station within the corresponding receive window for the base station, uplink timing control procedures are generally used. This control procedure avoids intra-cell interference both between UEs assigned to transmit on consecutive subframes and between UEs transmitting on adjacent subcarriers.

[0003] Uplink transmission time matching (TA) can be achieved by applying a timing advance value in the UE transmitter to the received downlink timing. Its primary role is to compensate for different propagation delays between different UEs, as shown in Figure 1 and as described below for LTE e node B.

[0004] In particular, Figure 1 shows the time alignment of uplink transmissions in a case without timing advance (a) and a case with timing advance (b). To achieve time alignment in order to obtain UL synchronization, the base station (e.g., g node B, e node B) derives and instructs the UE to use a timing advance value that the UE should use so that the UL transmission reaches the base station within the receive window. When the UE accesses a cell, the UE uses a random access procedure, where the received Msg1 (PRACH preamble) is used by the base station to determine the initial TA of the UE that should be used for UL transmission in the cell. During connection, the base station then continuously monitors whether the UE needs to advance and / or delay the UL transmission to compensate for changes in propagation delay and instructs the UE whether the timing advance value needs to be changed.

[0005] Time alignment in L3 mobility (handover / reconfiguration with synchronization)

[0006] In legacy L3 mobility in 5G New Radio (NR), also known as reconfiguration with synchronization for master cell groups (MCGs), when a UE changes its primary cell (PCell), the UE always performs random access to the target PCell. As part of the random access, the UE sends a PRACH preamble in the UL, which allows the target g node B to calculate a timing advance value for the UE, which is provided in the Random Access Response (RAR). Thus, from Msg3 onward, the UE can send UL messages on PUCCH and / or PUSCH.

[0007] PRACH transmission

[0008] NR allows for diverse cell implementations. For example, some cells (e.g., FR1 cells) may be implemented to provide large coverage, while others (e.g., FR2 cells) may be implemented to provide more throughput over shorter coverage areas. The maximum distance between a base station and an UE within a cell depends on the cell coverage area. Due to these diverse implementations, the same set of PRACH preambles may not work well in all scenarios. To address this, NR introduces different preamble formats with varying PRACH preamble lengths.

[0009] RACH transmission opportunities, or RACH opportunities, depend on the type of RACH. A RACH opportunity is a designated area in the time and frequency domain that is available or reserved for UE transmission of a RACH preamble. NR supports two types of RACH: competition-based RACH and competition-free RACH.

[0010] In the case of competition-based RACH, the RACH opportunity is calculated in the UE based on the network configuration and several conditions observed in the UE.

[0011] In NR, each beam is associated with a different synchronization signal (e.g., SSB) and transmitted in a spatial direction. Each SSB is assigned several preamble indices and several RACH transmit opportunities. Based on the SSB as seen from the UE, the UE determines which preamble index should be transmitted and which RACH opportunity the preamble should be transmitted at. The network can determine which beam UE has been selected because the network can establish a mapping between SSBs and RACH opportunities (ROs). By detecting which RO the UE sends PRACH to, the network can determine which SSB beam the UE has selected.

[0012] The mapping between SSB and RACH opportunities is defined by the following two RRC parameters: i) msg1-FDM (which is set in RACH-ConfigGeneric and may be found in TS38.331 v17.1.0) and ii) ssb-perRACH-OccasionAndCB-PreamblesPerSSB (which is set in RACH-ConfigCommon and may be found in 38.331 v17.1.0).

[0013] Competition-free RACH is scheduled by the network, and scheduling information includes what to send and where to send it. This information is communicated to the UE by a combination of RRC messages and PDCCH orders (for example, through Downlink Control Information (DCI) messages).

[0014] The RRC message that carries CFRA-related information is RACH-ConfigDedicated, which may be found in TS38.331-v17.1.0.

[0015] L1 / L2 inter-cell mobility or L1 / L2 triggered inter-cell mobility (LTM) in Rel-18

[0016] In Release 18, 3GPP agreed on work items concerning further improvements to new radio (NR) mobility, particularly in the technical area entitled L1 / L2 base-cell mobility. For further details, please refer to the WI description (WID) in RP-213565 (https: / / www.3gpp.org / ftp / TSG_RAN / TSG_RAN / TSGR_94e / Docs / / RP-213565.zip).

[0017] According to that WID, when a UE moves from the coverage area of one cell to another cell, at a certain point, a serving cell change needs to be performed. Currently, the serving cell change is triggered by L3 measurements and is performed by RRC signaling triggered Reconfiguration with synchronization for the change of PCell and PSCell, and for the addition of release for SCell when applicable. All cases involve a complete L2 (and L1) reset, which leads to longer latency, larger overhead, and longer interruption time than beam switching mobility. The goal of L1 / L2 mobility improvement is to enable serving cell changes via L1 / L2 signaling in order to reduce latency, signaling overhead, and interruption time.

[0018] As part of the L1-L2 inter-cell mobility measurement framework, it was agreed to support at least L1-RSRP as a reported quantity. This requires the UE to report the L1-RSRP of the candidate cells to the network, meaning that the network can use them for LTM handover (HO) decision-making.

[0019] In Release 17, as part of inter-cell beam management, a solution has been standardized where L1-RSRP is measured and reported for CSI resources not associated with the PCI of the serving cell.

[0020] L3 HO procedure vs. LTM HO procedure from the perspective of total delay (see L3 HO delay requirement TS38.331) 6.1.1.2.1 Handover Delay When the UE receives an RRC message indicating a handover, it is assumed that the UE is ready to start transmitting a new uplink PRACH channel within D milliseconds from the end of the last TTI containing the RRC command. handover Here,​ D handover is equal to the applicable RRC procedure delay defined in section 12 of TS38.331 [2] + the interruption time described in section 6.1.1.2.2. 6.1.1.2.2 Interruption time The interruption time is the time between the end of the last TTI containing the RRC command on the old PDSCH and the time when the UE starts transmitting a new PRACH, excluding the RRC procedure delay. When an intra-frequency or inter-frequency handover is commanded, the interruption time shall be less than T interrupt shall be less. T interrupt = T search + T IU + T processing + T Δ + T margin ms where T search is the time required to search for the target cell when the target cell is not already known when the handover command is received by the UE. If the target cell is known, T search = 0 ms. If it is an intra-frequency cell where the target cell is not known and the target cell Es / Iot ≥ -2 dB, T search = T rs ms. If it is an inter-frequency cell where the target cell is not known and the target cell Es / Iot ≥ -2 dB, T search [[ID=​​​​​​​​​​​​​​​​processing This can be up to 20ms. T margin This is the time required for SSB post-processing. margin It can be as fast as 2ms. T IU This represents the interruption uncertainty when acquiring the first available PRACH opportunity in a new cell. IU This can be, at most, the sum of the SSB-PRACH opportunity association period and 10 ms. The SSB-PRACH opportunity association period is specified in Table 8.1-1 of TS38.213[3]. T rs If the UE provides an SMTC setting for the target NR cell in the handover command, Trs is the SMTC periodicity of the target cell; otherwise, Trs is the SMTC set in the measObjectNR having the same SSB frequency and subcarrier interval. If the measObjectNRs set by MN and SN have different SMTCs but the same SSB frequency and subcarrier interval, Trs is the periodicity of one of the SMTCs, which depends on the UE implementation. If the UE does not provide an SMTC setting or measurement object on this frequency, the requirement in this section is that, assuming the SSB transmission periodicity is 5ms, T rs This applies when =5ms. There is no requirement if the SSB transmission periodicity is not 5ms. If the UE provides an upper layer in smtc2's TS38.331[2] signaling before the handover command, T rs It follows either smtc1 or smtc2 depending on the physical cell ID of the target cell. Under the interruption requirements, a cell is known if it has met the relevant cell identification requirements for the last 5 seconds; otherwise, the cell is unknown. The relevant cell identification requirements are described in Section 9.2.5 for intra-frequency handovers and in Section 9.3.4 for inter-frequency handovers.

[0021] According to the above requirements, L3 HO delay (D handover) is equal to the RRC processing delay and interruption time of the HO command. Here, the interruption delay includes the following components: · SW and HW processing • Cell search • Achieving precise timing • Delay uncertainty in obtaining the PRACH preamble According to the initial discussions of Rel-18 LTM, two potential approaches and two potential timelines were discussed. These are shown in Figures 2 and 3. In particular, Figure 2 shows the agreed baseline timeline for RAN2 for L1 / L2 cell mobility, and Figure 3 shows an exemplary LTM configuration and an example of an LTM cell switching procedure in which the UE accesses LTM candidate cells in LTM cell switching in a random access procedure.

[0022] In LTM, an LTM cell switching procedure is agreed upon in which the UE receives an LTM cell switching command (e.g., a MAC CE containing an instruction for one of the configured LTM candidate cells) and accesses the indicated LTM candidate cell. One option is for 3GPP to assume that the UE accesses an LTM candidate cell in response to an LTM cell switching command that relies on a random access procedure; i.e., when the UE receives an LTM cell switching command from a serving cell (e.g., a PCell), the UE sends a PRACH preamble to the LTM candidate cell and receives a random access response. When the UE receives an LTM cell switching command, one of the steps the UE must perform to increase the delay for accessing the LTM candidate is DL synchronization, in which the UE must perform fine-grained time tracking and obtain complete timing information for the target cell, the LTM candidate cell.

[0023] Referring to Figure 3, it has also been agreed that, in order to further reduce downtime, the UE may be configured to establish time synchronization with one or more LTM candidate cells before the trigger for LTM cell switching, so that at the moment of LTM cell switching, the UE is not required to trigger a random access procedure, and instead, the first UE action in the LTM candidate cell that will become the target cell (i.e., the new PCell) is to monitor the PDCCH and / or send UL signals on the PUCCH and / or PUSCH, which require that UL synchronization be established.

[0024] Different options for this time alignment (TA) procedure (for UL synchronization establishment) are still under discussion in 3GPP, but all of these options rely on the UE receiving a trigger (e.g., PDCCH order) from the PCell to send a UL signal (e.g., a PRACH preamble) to an LTM candidate cell while still connected to the PCell, and so the network-side candidate DU (responsible for the LTM candidate cell) that receives the preamble calculates a timing advance value that should be provided to the UE at a certain time point, for example, in an LTM cell switching command or in a DL response (e.g., via the PCell or the LTM candidate cell). That timing advance value is for the UE and the LTM candidate cell to which the UE sends the PRACH preamble. The TA establishment procedure can be triggered for one or more LTM candidate cells. For example, Figure 4 shows at least one example of what this procedure might look like. In detail, Figure 4 shows an example of a TA establishment procedure in which the UE establishes a TA by sending a PRACH preamble and receives a timing advance value in the LTM cell switching command.

[0025] Currently, there are (one or more) challenges. One challenge with respect to the time alignment (TA) establishment procedure is that before the UE sends a PRACH preamble to an LTM candidate cell, the UE must first perform DL synchronization by, for example, detecting and receiving one or more SSBs of that LTM candidate cell, so that the UE can determine (one or more) PRACH opportunities and send a PRACH preamble upon receiving a TA establishment trigger, for example, a PDCCH order.

[0026] This can, in some cases, be avoided if the TA establishment procedure is triggered very early, and in some cases, far in time from the timing to trigger the LTM cell switchover. However, a common network implementation would only trigger the TA establishment procedure when there is a higher level of certainty that a given LTM candidate is a highly likely candidate that will become known in the network (e.g., S-DU) by receiving further L1 and / or L3 measurements regarding the LTM candidate cell. However, doing so would, in principle, require the procedure for TA establishment to be as fast as possible so that the timing between TA establishment and LTM cell switchover does not become too close in time. Another potential issue with longer delays for sending the PRACH preamble for TA establishment is that it is not always possible for the UE to synchronize with the LTM candidate's SSB and attempt to receive / transmit data from (one or more) serving cells simultaneously, which can affect throughput / data rate.

[0027] Because PRACH opportunities and (one or more) SSBs can be sparse (e.g., tens of milliseconds), the procedure may not be very fast, and the longer it takes, the closer the UE gets to the timing to perform the LTM cell switchover, which can also increase the likelihood of a failed procedure, for example, if the radio conditions on the serving cell become much worse and / or the radio conditions on the LTM candidate become much better during TA establishment. Figure 5 shows an example of typical UE actions in this type of scenario. In particular, Figure 5 shows the delay for TA establishment with the LTM candidate cell.

[0028] Another potential issue in LTM, particularly regarding TA establishment with one or more LTM candidate cells, is that a UE may have multiple LTM candidate cells set as potential target cells. Based on measurement reports from the UE, the network may configure the UE to hand over to one of the candidate cells. While a UE can measure multiple cells, it may not be able to do so because maintaining DL synchronization with all candidate cells can result in higher UE complexity and cost.

[0029] Another challenge concerns the LTM cell switching procedure, which can also rely on a random access procedure, as shown in Figure 6. Before the UE can send a PRACH preamble to an LTM candidate cell in response to an LTM cell switching command (e.g., a MAC CE indicating at least one LTM candidate cell), the UE must first perform DL synchronization to one or more SSBs of that LTM candidate cell, so that the UE can send the PRACH preamble. This can take some time depending on various factors, such as SSB periodicity (where it takes longer for the next possible SSB to be received) or frequency range (e.g., FR2, mmWave frequency), which will require the UE to receive more SSBs in the burst to perform a beam sweep, which also takes longer. In other words, DL synchronization during LTM cell switching increases the LTM cell switching delay and therefore increases the mobility interruption time, which is being optimized across the entire research item in Rel-18. PRACH opportunities and (one or more) SSBs may be sparse (e.g., tens of milliseconds), and / or procedures may be too slow.

[0030] Figure 7 shows a signaling diagram illustrating the problems that need to be solved for LTM cell switching without random access.

[0031] Another potential issue in LTM cell switching is that a UE may have multiple LTM candidate cells configured as potential target cells. Based on measurement reports from the UE, the network may configure the UE to switch to one of the candidate cells or to perform TA establishment. While the UE can measure multiple cells, it may not be able to do so because maintaining DL synchronization with all candidate cells can result in higher UE complexity and cost. [Overview of the project]

[0032] Some aspects of this disclosure and their embodiments may provide solutions to these or other problems. The subject matter disclosed describes how a UE reduces delays in the time alignment (TA) establishment / update procedure with LTM candidate cells and / or in the LTM cell switching procedure.

[0033] Several embodiments provide a method implemented by user equipment for uplink access on an L1 / L2 trigger cell-to-cell mobility (LTM) candidate cell. The method includes receiving an LTM configuration for at least one LTM candidate cell from a network node, receiving a trigger from the network node, and receiving a first synchronization signal from the LTM candidate cell. The method further includes transmitting a UL signal to the LTM candidate cell during a UL resource opportunity in response to receiving the trigger, the UL signal being transmitted by the UL resource opportunity occurring during a time period between receiving the trigger and receiving the first synchronization signal from the LTM candidate cell. The first synchronization signal is received after the trigger has been received.

[0034] Several embodiments provide a method implemented by a network node for user equipment (UE) access on L1 / L2 trigger cell-to-cell mobility (LTM) candidate cells. The method includes sending an LTM configuration for at least one LTM candidate cell from the network node to the UE, and sending a trigger from the network node to the UE.

[0035] Some embodiments provide user equipment for uplink (UL) access on L1 / L2 trigger cell-to-cell mobility (LTM) candidate cells, which includes a processing circuit configured to perform any of the steps of a method performed by a UE, and a power supply circuit configured to supply power to the processing circuit.

[0036] Some embodiments provide a network node for uplink (UL) access on an L1 / L2 trigger cell-to-cell mobility (LTM) candidate cell, the network node comprising a processing circuit configured to perform any of the steps of a method performed by the network node, and a power supply circuit configured to supply power to the processing circuit.

[0037] One reason to send a UL signal between the reception of the trigger and the first synchronization signal (e.g., SSB) of the LTM candidate cell that occurs after the trigger, i.e., before the next synchronization signal (e.g., before the next SSB), is that it is not necessary in this case when the UE is DL synchronized with the LTM candidate cell, and therefore can send it after the UE receives the trigger from the serving cell, on the next available PRACH opportunity or (one or more) allocated / configured PUCCH / PUSCH resources of the LTM candidate cell. Another possibility is to send a UL signal to the LTM candidate cell after the reception of the trigger and before the next SSB that occurs after the reception of the trigger. One benefit is that the UE does not need to receive the LTM candidate cell's SSB before sending a UL signal to the LTM candidate cell.

[0038] According to some embodiments, the trigger may correspond to one or more of the following:

[0039] A trigger for a TA establishment / update procedure, the trigger being received from a serving cell (e.g., a PDCCH order from a primary cell or primary SCG cell) to send a UL signal (e.g., a PRACH preamble) for TA establishment / update,

[0040] A trigger for an LTM cell switching procedure, wherein the trigger corresponds to an LTM cell switching command (e.g., MAC CE from a primary cell or primary SCG cell) from a serving cell (indicating an LTM candidate cell, e.g., an LTM configuration ID) for accessing an LTM candidate.

[0041] According to some embodiments, the UL signal may correspond to one or more of the following:

[0042] In LTM cell switching, the PRACH preamble sent to the PRACH opportunity of the LTM candidate cell,

[0043] In the TA establishment / update procedure, the PRACH preamble sent to the PRACH opportunity of the LTM candidate cell,

[0044] Sounding reference signals (SRS) sent to LTM candidate cells during the TA establishment / update procedure,

[0045] Control information (e.g., scheduling requests) transmitted over the physical uplink control channel (PUCCH) of the LTM candidate cell during the LTM cell switching procedure, and / or

[0046] UL data transmitted over the physical uplink shared channel (PUSCH) of an LTM candidate cell during the LTM cell switching procedure (e.g., including RRC reconfiguration completion as a payload).

[0047] According to some embodiments, UL resource opportunities may correspond to one or more of the following:

[0048] PRACH opportunity for LTM candidate cells,

[0049] The sounding reference signal resource or resource opportunity of the LTM candidate cell that has been set (for example, in the RRC setting of the LTM candidate cell) and / or allocated (for example, in the LTM cell switching command),

[0050] (For example, in the RRC configuration of the LTM candidate cell) the configured and / or (for example, in the LTM cell switching command) the allocated physical uplink control channel (PUCCH) resources or resource opportunities of the LTM candidate cell, and / or

[0051] The physical uplink shared channel (PUSCH) resource or resource opportunity of an LTM candidate cell that has been configured (for example, in the RRC configuration of the LTM candidate cell) and / or allocated (for example, in the LTM cell switching command).

[0052] Figure 8 shows several embodiments in which the UE performs the TA establishment / renewal procedure. Similarly, Figure 9 shows an example in which the disclosed subject matter is used for an LTM cell switching procedure that relies on random access. Figure 10 shows an example in which the disclosed subject matter is used for an LTM cell switching procedure that does not rely on PUCCH and / or PUSCH transmissions during LTM cell switching.

[0053] According to some embodiments, the UE configures multiple LTM candidate cells (i.e., two or more candidate cells) and selects a subset of (one or more) LTM candidate cells / at least one LTM candidate cell to send a UL signal to an LTM candidate cell's UL resource opportunity (e.g., a PRACH opportunity), the UL resource opportunity to which the UE sends the UL signal occurs between the reception of a trigger and a first synchronization signal (e.g., SSB) of the LTM candidate cell after the trigger, and the selection of the subset of (one or more) LTM candidate cells is based on one or more rules (or a combination thereof). In other words, the UE may not be able to perform the actions in this method for all configured cells, and therefore the UE needs to select a subset of cells for which the UE will perform those actions. Several rules for selecting a subset of (one or more) LTM candidate cells, which may be combined, are presented below.

[0054] Figure 11 shows an example of a selection of a subset of LTM candidate cells for performing UL signaling (e.g., PRACH preamble) according to several embodiments of the TA establishment / update procedure.

[0055] Some embodiments may provide one or more of the following technical advantages: By utilizing the disclosed subject matter, delays are reduced when sending UL signals to LTM candidate cells in the TA establishment / update procedure to LTM candidate cells in preparation for LTM cell switching without random access procedures.

[0056] When applied to LTM cell switching, the use of the disclosed subject matter reduces the delay when transmitting the UL signal to an LTM candidate cell during LTM cell switching to an LTM candidate cell with or without a random access procedure.

[0057] A UE can send a UL signal (e.g., a PRACH preamble) to an LTM candidate cell (instructed by a trigger for TA establishment, e.g., a PDCCH order, RRC message, or MAC from a PCell, or in response to an LTM cell switchover) by sending it at a PRACH opportunity (or PUCCH and / or PUSCH) that occurs after the UE receives a trigger and before the next synchronization signal (e.g., an SSB). In other words, the UE is not required to first receive the LTM candidate cell's SSB (or any other synchronization signal) and then send the UL for the first time. This reduces the time required to perform UL synchronization for LTM candidate cells during the TA establishment procedure, which can reduce the time the UE needs to be away from (one or more) serving cells, and therefore, in some cases, improve throughput / data rate.

[0058] This could, in some cases, improve the reliability of the overall UE connection because a shorter time to perform TA establishment / update means the UE can return to the PCell faster after sending the PRACH preamble, which means the UE can be ready to receive the LTM cell switching command from the PCell more quickly.

[0059] Note: UEs have the freedom to implement standardized functions in different ways and in more detail. In one example regarding LTM cell switching and TA establishment, when a UE is configured with multiple available UL resources (e.g., multiple PRACH opportunities and / or PUCCH and / or PUSCH resources), it is up to the UE implementation to determine the internal actions required to access the LTM target cell (or to send to the LTM target cell in the case of TA establishment) after the network sends the trigger, depending on, for example, how much time the UE needs to perform such actions. This is why the network configures multiple available resources, leaving the implementation free to determine what the network may not be aware of and how much time the UE may need.

[0060] One alternative would be to set up a single resource that occurs considerably later to ensure there is sufficient time for the network, but this would also significantly increase the downtime. Note that the UE may have other alternatives, and the UE may not be obligated to access the first resource before the next SSB. [Brief explanation of the drawing]

[0061] [Figure 1] This diagram shows the time matching of uplink transmissions in a case without timing advance (a) and a case with timing advance (b). [Figure 2] This diagram shows the timeline for L1 / L2 cell-to-cell mobility. [Figure 3] This figure shows an example of a procedure for establishing timing alignment (TA). [Figure 4] This figure shows an example of a procedure for establishing timing alignment (TA) according to several embodiments. [Figure 5] This figure shows the delay required to establish a TA with an LTM candidate cell. [Figure 6] This figure shows an LTM cell switching procedure based on a random access procedure. [Figure 7] This figure shows an LTM cell switching procedure that is not based on a random access procedure. [Figure 8] This figure shows the establishment of TA with LTM candidate cells according to several embodiments. [Figure 9] This figure shows the establishment of TA with LTM candidate cells, relying on random access. [Figure 10] This figure shows TA establishment with LTM candidate cells that does not rely on PUCCH and / or PUSCH transmission, according to several embodiments. [Figure 11] This figure shows an example based on the selection of a subset of LTM candidate cells for performing UL signal transmission according to several embodiments. [Figure 12] This is a signaling diagram for establishing TA with LTM candidate cells according to several embodiments. [Figure 13] This is a signaling diagram for LTM cell switching. [Figure 14] This figure shows the transmission of HARQ feedback triggered by PDCCH monitoring in an LTM candidate cell. [Figure 15] This figure shows a method implemented by a UE in a wireless communication network for performing TA with an LTM candidate cell, according to several embodiments. [Figure 16] This figure shows a method implemented by network nodes in a wireless communication network for L1 / L2 base cell-to-cell mobility of UEs to candidate cells, according to several embodiments. [Figure 17] This figure shows an example of a communication system according to several embodiments. [Figure 18] This figure shows an example of a UE according to several embodiments. [Figure 19] This figure shows an example of a network node according to several embodiments. [Figure 20]This is a block diagram of the host. [Figure 21] This is a block diagram of a virtualization environment. [Figure 22] This is a communication diagram of the host. [Modes for carrying out the invention]

[0062] Next, some of the embodiments intended herein will be described more thoroughly with reference to the accompanying drawings. Embodiments are provided as examples to convey the scope of the subject to those skilled in the art.

[0063] Scenarios and Terminology for Embodiments

[0064] The text herein refers to the term "L1 / L2 base cell mobility" as used in work item descriptions in 3GPP, but this text also uses the terms L1 / L2 mobility, L1 mobility, L1 base mobility, L1 / L2 center cell mobility, L1 / L2 cell mobility, or L1 / L2 trigger mobility (LTM) interchangeably.

[0065] The basic principle of LTM is that the UE is initially configured with one or more LTM candidate cells (via RRC), and later, for example, after the UE reports L1 measurements regarding one or more LTM candidate cells, the UE receives lower-layer signaling from the network instructing the UE to change (or switch or activate) its serving cell (e.g., change a PCell from source to target PCell), and this lower-layer signaling is a message / signaling of a lower-layer protocol, sometimes called an L1 / L2 inter-cell mobility execution command (or LTM cell switching command). A change in a serving cell (e.g., a change in PCell) can also lead to a change in (one or more) SCells for the same cell group, for example, if the command triggers the UE to change to a different cell group configuration of the same type (e.g., a different MCG configuration). Before the UE receives the LTM cell switching command, the UE is configured with one or more LTM candidate cells by the network (e.g., receiving an RRC reconfiguration message with at least one candidate cell configuration). Candidate cell settings may include IE CellGroupConfig and / or embedded RRC reconfiguration parameters for each candidate cell.

[0066] Lower layer protocols refer to protocols in the air interface protocol stack that are lower in comparison to RRC protocols. For example, Media Access Control (MAC) is considered a lower layer protocol because MAC is "below" RRC in the air interface protocol stack, in which case lower layer signaling / messages may correspond to MAC control elements (MAC CEs). Another example of a lower layer protocol is Layer 1 (or physical layer, L1), in which case lower layer signaling / messages may correspond to Downlink Control Information (DCI). Signaling information at protocol layers lower than RRC reduces processing time and therefore reduces downtime during mobility. Furthermore, it can also increase mobility robustness because the network can respond to faster changes in channel conditions. Another relevant aspect of L1 / L2 inter-cell mobility is that in multi-beam scenarios, a cell may be associated with multiple SSBs, and different SSBs may be transmitted in different spatial directions (i.e., across the cell's coverage area, using different beams) during a half-frame. A similar reasoning may be applicable to CSI-RS resources, which can also be transmitted in different spatial directions. Thus, in L1 / L2 inter-cell mobility (LTM), the reception of lower-layer signaling instructs the UE to change from one beam in the serving cell to another beam in a neighboring cell (which is a configured candidate cell), thereby changing the serving cell.

[0067] The term LTM cell switching procedure (or simply cell switching) refers to the process by which a UE changes a cell in the UE from a source cell to a target cell (sometimes called a candidate cell) using L1 / L2 triggered mobility (also known here as LTM). In the context of L1 / L2 base cell mobility or L1 / L2 triggered mobility (LTM), the LTM cell switching procedure may also be known as dynamic switching, LTM switching, LTM cell switching, LTM serving cell change, or LTM cell change. Even when the term cell change is used, the term may include changes to the entire cell group configuration, which includes changes to the cell group's SpCell (e.g., PCell changes, or PSCell changes) and SCell changes (e.g., adding, modifying, and / or releasing one or more SCells).

[0068] This text refers to the term “LTM candidate cell” to refer to a cell that is set up for a UE when L1 / L2 inter-cell mobility is configured. An LTM candidate cell is a cell to which a UE can move in the L1 / L2 inter-cell mobility procedure upon receiving lower-layer signaling. These cells may also be called candidate cells, candidates, mobility candidates, non-serving cells, additional cells, etc. This is a cell to which a UE performs measurements (e.g., L1-RSRP measurements or CSI measurements), as disclosed in the disclosed subject, and the UE reports these measurements so that the network can make informed decisions about which beam (e.g., TCI state) and / or cell the UE should switch to. An L1 / L2 inter-cell mobility candidate cell may be a candidate that will become the target PCell, PSCell, or SCell (e.g., MCG SCell) of a cell group. In that sense, when this text refers to resource settings to indicate the SS and / or RS that the UE should measure for CSI for reporting, it may be referring to the SS and / or RS of candidate SCells for MCG, candidate SCells for SCG, candidate PSCell and / or candidate PCell.

[0069] In relation to LTM, according to this method, a UE may be able to acquire downlink (DL) and / or uplink (UL) synchronization before receiving an LTM cell switching command (e.g., a MAC CE indicating an LTM candidate cell, and / or LTM candidate cell configuration). For a UE that is able to acquire DL synchronization before receiving an LTM cell switching command, there may be a limit to the number of cells for which such synchronization can be acquired before receiving an LTM cell switching command. Also, in order to acquire UL synchronization, the UE may need to send a UL signal, such as a PRACH preamble or a sounding reference signal (SRS), to the LTM candidate cells (e.g., target gNB and / or candidate DU). Unless the UE has acquired DL synchronization, the UE will not send a PRACH or SRS to acquire UL synchronization. Each PRACH preamble may be associated with an SSB and RACH opportunity (RO) on which that preamble may be sent. An RO may be a periodically repeating opportunity. For example, if the first RO associated with the PRACH preamble is at 10 ms, then the second RO associated with the same preamble could be at 10 ms + (160 ms), the third RO associated with the same preamble could be at 10 ms + (2 * 160 ms), the fourth RO could be at 10 ms + (3 * 160 ms), and so on.

[0070] In a set of embodiments, the subject matter disclosed includes steps of a method in which a UE receives the configuration of one or more LTM candidate cells, receives a trigger, and in response to the trigger, transmits a UL signal to a UL resource opportunity (e.g., a PRACH opportunity) of the LTM candidate cell, the UL resource opportunity to which the UE transmits the UL signal occurs between the reception of the trigger and a first synchronization signal (e.g., an SSB) of the LTM candidate cell after the trigger.

[0071] The reasoning behind sending a UL signal between the reception of the trigger and the first synchronization signal (e.g., SSB) of the LTM candidate cell after the trigger, i.e., before the next synchronization signal (e.g., before the next SSB), is that it is not necessary when the UE is DL synchronized with the LTM candidate cell, and therefore, after the UE receives a trigger from the serving cell, the UE can send it on the next available PRACH opportunity or (one or more) allocated / configured PUCCH / PUSCH resources of the LTM candidate cell.

[0072] According to this method, the trigger is A trigger for a TA establishment / update procedure, the trigger being received from a serving cell (e.g., a PDCCH order from a primary cell or primary SCG cell) to send a UL signal (e.g., a PRACH preamble) for TA establishment / update, A trigger for an LTM cell switching procedure, wherein the trigger corresponds to an LTM cell switching command (e.g., MAC CE from a primary cell or primary SCG cell) from a serving cell (indicating an LTM candidate cell, e.g., an LTM configuration ID) for accessing an LTM candidate. It may correspond to one or more of these.

[0073] According to this method, the UL signal is In LTM cell switching, the PRACH preamble sent to the PRACH opportunity of the LTM candidate cell, In the TA establishment / update procedure, the PRACH preamble sent to the PRACH opportunity of the LTM candidate cell, Sounding reference signals (SRS) sent to the PUCCH or PUSCH of LTM candidate cells during the TA establishment / update procedure, Control information (e.g., scheduling requests) transmitted over the physical uplink control channel (PUCCH) of the LTM candidate cell during the LTM cell switching procedure, and / or UL data transmitted over the physical uplink shared channel (PUSCH) of an LTM candidate cell during the LTM cell switching procedure (for example, including RRC reconfiguration completion as the payload) It may correspond to one or more of these.

[0074] According to this method, UL resource opportunities are PRACH opportunity for LTM candidate cells, The physical uplink control channel (PUCCH) resource or resource opportunity of the LTM candidate cell that has been configured (for example, in the RRC configuration of the LTM candidate cell) and / or allocated (for example, in the LTM cell switching command), Physical uplink shared channel (PUSCH) resources or resource opportunities of an LTM candidate cell that have been configured (for example, in the RRC configuration of the LTM candidate cell) and / or allocated (for example, in the LTM cell switching command). It may correspond to one or more of these.

[0075] According to this method, the UE has multiple LTM candidate cells (i.e., two or more candidate cells) configured, and selects a subset of (one or more) LTM candidate cells / at least one LTM candidate cell to send a UL signal to an LTM candidate cell's UL resource opportunity (e.g., a PRACH opportunity), the UL resource opportunity to which the UE sends the UL signal occurs between the reception of the trigger and the first synchronization signal (e.g., SSB) of the LTM candidate cell after the trigger, and the selection of the subset of (one or more) LTM candidate cells is based on one or more rules (or a combination thereof). In other words, the UE may not be able to perform the actions in this method for all configured cells, and therefore the UE needs to select a subset of cells for which the UE will perform those actions. Several rules for selecting a subset of (one or more) LTM candidate cells, which may be combined in some cases, are proposed below.

[0076] According to this method, the UE transmits a UL signal to the LTM candidate cell on one or more configured UL channel resources in time and frequency, such as a PRACH opportunity that occurs between the reception of a trigger and the occurrence of the next synchronization signal (e.g., SSB) in the LTM candidate cell, based on DL synchronization performed to the LTM candidate cell prior to the reception of the trigger.

[0077] Performing DL synchronization (also called DL pre-synchronization, pre-sync) with an LTM candidate cell by a UE involves the UE detecting and / or measuring at least one synchronization signal of the LTM candidate cell, such as the synchronization signal block (SSB), for example, the SSB of the LTM candidate cell, associated with an SSB index and / or identifier and transmitted in a spatial direction (beam), as well as the channel status information reference signal (CSI-RS) and / or tracking reference signal (TRS) and / or primary synchronization signal (PSS) and / or secondary synchronization signal (SSS), in this context, measuring involves determining measured quantifiable values ​​such as synchronization signal-based reference signal received power (SS-RSRP) and / or synchronization signal-based reference signal received quality (SS-RSRQ) and / or synchronization signal-based signal-to-noise interference ratio (SS-SINR).

[0078] Performing DL synchronization with an LTM candidate cell by the UE involves performing detailed time tracking and obtaining complete timing information for the LTM candidate cell. Timing acquisition involves obtaining time boundaries for time units of a given LTM candidate cell, such as time slots, OFDM symbols, subframes, and radio frames. Timing acquisition involves synchronizing the clock with the time boundaries for time units of the given LTM candidate cell, such as time slots, OFDM symbols, subframes, and radio frames. The acquired detailed timing is used as a reference point for PRACH transmissions and UE uplink transmissions.

[0079] According to this method, the UE selects a subset of (one or more) LTM candidate cells / at least one LTM candidate cell to perform DL synchronization before the TA establishment procedure is triggered, given that multiple LTM candidate cells (i.e., two or more candidate cells) are set up, and the selection of the subset of (one or more) LTM candidate cells is based on one or more rules (or a combination thereof).

[0080] According to this method, the UE transmits a UL signal to the LTM candidate cell in one or more configured UL channel resources in time and frequency before the next synchronization signal (e.g., SSB) of the LTM candidate cell, and after receiving a trigger, in one or more first configured UL channel resources in time and frequency (e.g., a first PRACH opportunity).

[0081] The reason for sending the UL signal at the first PRACH opportunity set up for TA establishment before the next synchronization signal is that it is not necessary when the UE is DL synchronized with the LTM candidate cell, and therefore the UE can send the trigger for TA establishment from the serving cell, for example, after receiving a PDCCH order from the PCell, at the next available PRACH opportunity of the LTM candidate cell.

[0082] According to this method, before receiving an LTM cell switching command from the serving cell that designates an LTM candidate cell, the UE receives a configuration from the serving cell that includes one or more LTM candidate cell settings to be applied when the LTM cell switching command is received (for example, an LTM setting in an RRC reconfiguration message). This is equivalent to the UE being configured with an LTM by the network.

[0083] According to this method, before receiving an LTM cell switching command from the serving cell indicating an LTM candidate cell, the UE receives a configuration for TA establishment / update with the LTM candidate cell, including one or more UL relation parameters such as PRACH preamble settings, (one or more) PRACH opportunities, and (one or more) PRACH frequency resources. In one option, the configuration for TA establishment / update is included in the same RRC message that sets the UE to LTM, for example, during RRC reset. In another option, the configuration for TA establishment / update is included in a second RRC message, for example, during a second RRC reset, after the UE receives the first RRC message that sets the UE to LTM.

[0084] According to this method, when multiple LTM candidate cells are configured and the UE receives a trigger and transmits an uplink signal to an LTM candidate cell in a first subset of the multiple LTM candidate cells, the UE transmits a UL signal to the LTM candidate cell in the first subset of the multiple LTM candidate cells in time and frequency on one or more configured UL channel resources before the next synchronization signal (e.g., SSB) of the LTM candidate cell.

[0085] According to this method, when multiple LTM candidate cells are configured and the UE receives a trigger from a serving cell (e.g., a PDCCH order from a primary cell or primary SCG cell) and sends a UL signal (e.g., a PRACH preamble) for TA establishment / update to an LTM candidate cell that is not in the first subset of multiple LTM candidate cells, the UE sends the UL signal to the LTM candidate cell that is not in the first subset of multiple LTM candidate cells in time and frequency (one or more) configured UL channel resources after the next synchronization signal (e.g., SSB) of the LTM candidate cell.

[0086] According to this method, the UE has multiple LTM candidate cells (i.e., two or more candidate cells) configured and selects a subset of (one or more) LTM candidate cells / at least one LTM candidate cell to send a UL in accordance with this method (for example, in a UL resource opportunity between the reception of a trigger and the occurrence of an SSB), and the selection of the subset of (one or more) LTM candidate cells is based on one or more rules (or a combination thereof), such as the following:

[0087] 1) The UE selects all (one or more) LTM candidate cells set in the UE.

[0088] In one option, as an example, the UE reports its ability to indicate that DL synchronization is possible with "K" LTM candidate cells, and the UE receives a message containing LTM settings for "K*" LTM candidate cells (e.g., RRC reset), where K* ≤ K, and therefore the UE performs a UL transmission for all LTM candidates (or either, when a single LTM candidate can be indicated in an LTM cell switchover) between receiving the trigger (e.g., in a TA establishment or LTM cell switchover) and the next SSB occurrence.

[0089] Note: There may be two types of capabilities: a first capability related to the TA establishment procedure and a second capability related to the LTM cell switching procedure.

[0090] The capabilities described above may be reported when the UE transitions from an idle state to a connected state.

[0091] Testability / measurability of UE implementation steps: As one example, in the test, we can configure a number of LTM candidate cells that we know the UE is capable of handling, for example, two cells, thanks to the reported UE capabilities. Then, when the network sends a trigger for all or any of these configured LTM candidate cells, we test whether the UE actually sends a UL signal (e.g., a PRACH preamble) on a UL channel opportunity (e.g., a PRACH opportunity) after receiving the trigger and before the next SSB. To do this, we would also need to configure an LTM candidate cell that sends a PRACH opportunity between receiving the trigger and the next SSB.

[0092] A test scenario as one example: Serving cell SC1, and neighboring cell NC2 set as an LTM candidate cell with an SSB set by a known time. Set different timings for SSB. - In order for NCell to move the SSB over known time, a set of time offsets can be added from the signal generator to the asynchronous cell. - An alternative approach is to set up SSB at different time opportunities for NCell within the test sequence. During testing, configure the system to simultaneously send an LTM cell switching command from SCell1. Configure to enable PRACH opportunities for NCell2. Check the time of the UL PRACH sent to NCell, if it is subject to a timing offset or different SSB opportunity.

[0093] 2) The UE selects the strongest LTM candidate cell from among the "N" set LTM candidate cells according to the measured quantity, and the measured quantity may correspond to RSRP, RSRQ, SINR, etc.

[0094] One option, as an example, is to measure RSRP, RSRQ, or SINR.

[0095] In one option, as an example, the strongest LTM candidate cell is selected based on the cell quality of the LTM candidate cell; for example, UE selects the LTM candidate with the strongest cell RSRP value.

[0096] In one option, as an example, the strongest LTM candidate cell is selected based on the beam / SSB / CSI-RS quality of the LTM candidate cell. For example, the UE selects the LTM candidate with the strongest beam level RSRP value (SS-RSRP value).

[0097] Testability / measurability of the UE implementation step: In testing, the UE can be configured to report a metric for LTM candidate cells, and thus the value of that metric can be observed (e.g., SS-RSRP for configured LTM candidate cells; thus, when the situation does not change, a trigger can be sent to the UE based on the observation (e.g., for a TA establishment procedure or LTM cell switching), and the UE can determine whether the reported value has selected a cell that fulfills rule number 2).

[0098] A test scenario as one example: Serving cell SC1, neighboring cell NC2 as a first set LTM candidate cell with a first SSB set by a known first time, and second neighboring cell NC3 as a second set LTM candidate cell with a second SSB set by a known second time. NC2 is set to a first power level 1 corresponding to RSRP1, and NC3 is set to a second power level 2 corresponding to RSRP2. - Configure the system to simultaneously send LTM cell switching commands from SCell 1 during testing. - Configure to enable PRACH opportunities for NC2 and NC3. - Check the time of the UL PRACH sent to NC2 or NC3 if it is the strongest RSRP, and if the UL PRACH was sent between the switch command and the known SSB time from either NC2 or NC3.

[0099] 3) The UE selects K of the strongest LTM candidate cells from N set LTM candidate cells according to the measured quantity, and the measured quantity may correspond to RSRP, RSRQ, SINR, etc.

[0100] In one option, as an example, the UE reports its ability to indicate that it is capable of DL synchronization (or DL ​​pre-synchronization) with "K" LTM candidate cells, and the UE receives a message (e.g., RRC reset) containing LTM settings for "N" LTM candidate cells, where N > K, and therefore, after receiving the LTM candidate cell settings and upon receiving a trigger (e.g., for a TA establishment procedure or LTM cell switching), the UE sends a UL signal to one of the K strongest LTM candidate cells for the meter during the UL resource opportunity between the reception of the trigger and the next SSB occurrence.

[0101] One option, as an example, is to measure RSRP, RSRQ, or SINR.

[0102] In one option, as an example, the K strongest LTM candidate cells are selected based on the cell quality of the LTM candidate cells, for example, UE selects the LTM candidate with the strongest cell RSRP value.

[0103] In one option, as an example, K of the strongest LTM candidate cells are selected based on the beam / SSB / CSI-RS quality of the LTM candidate cells, for example, the UE selects the LTM candidate with the strongest beam level RSRP value (SS-RSRP value).

[0104] Testability / Measurability of UE Implementation Steps: In the case of TA establishment, it is possible to trigger the UE to perform the procedure with multiple candidates, and thus in testing, it is possible to trigger TA establishment to N candidate cells and, in some cases, observe UL transmissions for K cells that fulfill the conditions in the rule. To verify whether K cells are the strongest, the UE can be configured to periodically send L1 and / or L3 measurement reports for N LTM candidate cells. In testing, the UE can be configured to report measurements for LTM candidate cells, and thus the values ​​of those measurements can be observed, for example, SS-RSRP for the configured LTM candidate cells. Thus, when the situation does not change, it is possible to trigger the TA establishment procedure based on the observation and know whether the UE has selected cells that fulfill rule number 3 based on the reported values.

[0105] In the case of LTM cell switching, the test can be performed by configuring the UE to perform L1 or L3 measurements, which should be reported for all N candidates, and to trigger the LTM cells one by one. Thus, when an LTM cell switch is triggered for any of the K strongest cells, it can be observed that the UE sends a UL signal during the UL resource opportunity between the reception of the trigger and the next SSB occurrence. Alternatively, the test can be performed in reliance on subsequent LTM cell switches, which include the UE receiving a trigger for an LTM and switching to an LTM candidate cell, and while the UE is there, the UE receives another trigger for an LTM cell switch to another LTM candidate cell.

[0106] 4) The UE selects all (one or more) LTM candidate cells configured for TA establishment / update when it receives an RRC message containing TA establishment settings, for example, when the number of LTM candidate cells configured for TA establishment / update does not exceed the UE's capacity corresponding to the maximum number of cells that the UE can DL synchronize before receiving a trigger.

[0107] For example, if a UE reports its ability to DL synchronize with "K" LTM candidate cells, and the UE receives a message (e.g., RRC reset) containing an LTM setting that includes a TA establishment setting for K* LTM candidate cells, and K* ≤ K, then upon receiving the trigger, the UE may send a UL signal to any of the LTM candidate cells during the UL resource opportunity between the reception of the trigger and the next SSB occurrence.

[0108] The capabilities described above may be reported when the UE transitions from an idle state to a connected state.

[0109] There may be capabilities related to LTM cell switching and other capabilities related to TA establishment / update procedures.

[0110] Testability / measurability of UE implementation steps: In testing, a TA establishment could be set up for a subset of LTM candidate cells ("K"), triggering the TA establishment procedure for these K cells, and verifying whether the UE sends a UL signal (e.g., a PRACH preamble) on the first PRACH opportunity after receiving the trigger, but before the next SSB.

[0111] 5) The UE selects (one or more) LTM candidate cells set up for TA establishment / update that have a sufficiently strong metric (e.g., RSRP).

[0112] In one option, as an example, the measured quantity could correspond to RSRP, RSRQ, or SINR.

[0113] In one option, as an example, the measurement could correspond to a cell-based measurement, such as the cell RSRP for LTM candidate cells.

[0114] In one option, as an example, the measurement could correspond to a beam / SSB / CSI-RS based measurement. For example, the UE selects a cell where the strongest SS-RSRP is sufficient / reasonable.

[0115] Testability / measurability of UE implementation steps: In testing, a TA establishment could be set up for a subset of LTM candidate cells ("K"), triggering the TA establishment procedure for these K cells, and verifying whether the UE sends a UL signal (e.g., a PRACH preamble) on the first PRACH opportunity after receiving the trigger, but before the next SSB.

[0116] 6) The UE selects the K strongest LTM candidate cells from the N set LTM candidate cells set for TA establishment according to the measured quantity, and the measured quantity may correspond to RSRP, RSRQ, SINR, etc.

[0117] In one option, as an example, the UE reports its ability to indicate that DL synchronization is possible before TA establishment or LTM cell switching with the "K" LTM candidate cells set up for TA establishment, and the UE receives a message (e.g., RRC reset) containing LTM settings for "N" LTM candidate cells, where N > K, and therefore, upon receiving the trigger, the UE sends a UL signal to one of the K strongest LTM candidate cells for the quantifier during the UL resource opportunity between receiving the trigger and the next SSB occurrence.

[0118] In one option, as an example, the measured quantity could correspond to RSRP, RSRQ, or SINR.

[0119] In one option, as an example, the K strongest LTM candidate cells are selected based on the cell quality of the LTM candidate cells, for example, UE selects the LTM candidate with the strongest cell RSRP value.

[0120] In one option, as an example, K of the strongest LTM candidate cells are selected based on the beam / SSB / CSI-RS quality of the LTM candidate cells, for example, the UE selects the LTM candidate with the strongest beam level RSRP value (SS-RSRP value).

[0121] 8) The UE selects one or more LTM candidate cells based on the latest L1 measurement report, for example, the SS-RSRP of the reported LTM candidate cells.

[0122] In one option, as an example, the UE is configured to perform L1 measurements on one or more LTM candidate cells, such as CSI measurements, SS-RSRP measurements, etc. The UE then selects LTM candidate cells as cells for which the UE has sent L1 reports. The inference is that these may also be LTM candidate cells that are more likely to be requested by the network (e.g., S-DU) for TA establishment and / or LTM cell switching.

[0123] In one option, as an example, the UE does this on several LTM candidate cells before its ability to perform DL synchronization or pre-synchronization on a number of cells is exceeded.

[0124] Testability / measurability of UE implementation steps: In testing, the UE may be configured to send an L1 report for an LTM candidate cell, trigger a TA establishment (or LTM cell switchover) a short time later, and verify for that cell whether the UE sent a PRACH preamble at the first PRACH opportunity and / or at the PRACH opportunity between receiving the trigger for TA establishment and the next SSB of the LTM candidate cell.

[0125] 9) The UE selects one or more LTM candidate cells based on the L3 measurement of the LTM candidate cells, for example, cell-based RSRP.

[0126] In one option, as an example, the UE is configured to perform L3 measurements on one or more LTM candidate cells, such as L3-filtered cell-based RSRP, RSRQ, and Radio Resource Management (RRM) measurements like SINR. The UE then selects LTM candidate cells, e.g., triggered cells, for which the UE has sent an L3 measurement report, that satisfy one or more conditions of an event set in the reporting configuration, e.g., an A3 or A5 event. The inference is that these triggered cells that perform one or more events may be configured by the network as LTM candidate cells and may be requested by the network (e.g., S-DU) for TA establishment.

[0127] In one option, as an example, the UE does this on several neighboring cells (e.g., the triggered cell) before the UE's capabilities are exceeded, and the UE reports a number of cells up to the number of LTM candidate cells on which the UE can perform DL synchronization before TA establishment.

[0128] In one option, as an example, the UE updates neighboring cells (e.g., the triggered cell) where the UE performs DL synchronization, depending on the reported cell.

[0129] Testability / measurability of UE implementation steps: In testing, the UE may be configured to send an L3 report about an LTM candidate cell (e.g., periodically), trigger a TA establishment a short time later, and verify for that cell whether the UE sent a PRACH preamble at the first PRACH opportunity and / or at the PRACH opportunities between receiving the trigger for TA establishment and the next SSB of the LTM candidate cell.

[0130] 12) The UE selects cells at higher frequencies and / or within a specific frequency range, such as FR2 cells, because these may take longer to perform DL synchronization and / or measurement.

[0131] In one option, as an example, the UE selects one or more LTM candidate cells (or a subset of LTM candidate cells) where (one or more) SSBs are at high frequencies and / or within a specific frequency range (FR2).

[0132] The reasoning is that for these cells, it may take longer to obtain DL synchronization, and therefore, if the UE needs to wait for a trigger to send the UL signal and perform DL synchronization first, it may take too long.

[0133] Testability / measurability of UE implementation steps: In testing, the UE can be configured with LTM candidate cells in different frequency ranges, and for several frequency ranges (e.g., FR2), it can be observed that at the trigger for TA establishment, the UE transmits a UL signal (e.g., a PRACH preamble) during the PRACH opportunity between the trigger and the next SSB of the LTM candidate that occurs after the trigger.

[0134] 13) UE selects cells with "long" SSB periodicity.

[0135] In one option, as an example, the UE performs DL synchronization for LTM candidate cells (or a subset of LTM candidate cells) where the SSB (one or more) has a long periodicity, for example, greater than 20ms.

[0136] One option, as an example, is to set the periodicity so that the UE performs DL synchronization to cells with a periodicity longer than a set value (e.g., periodicity threshold).

[0137] The reasoning is that for these cells, it may take longer to obtain DL synchronization, and therefore, if the UE needs to wait for a trigger to send the UL signal and perform DL synchronization first, it may take too long.

[0138] Testability / measurability of UE implementation steps: In testing, the UE can be configured with LTM candidate cells having different longer and shorter periodicities, and for longer periodicities (e.g., 50ms and above), it can be observed that at the trigger for TA establishment, the UE transmits a UL signal (e.g., a PRACH preamble) during the PRACH opportunity between the trigger and the next SSB of the LTM candidate that occurs after the trigger.

[0139] According to this method, one or more rules may be based on one or more parameters set in the UE. The UE may receive the setting of one or more parameters in the RRC reset message, and one or more parameters may be set for one or more LTM candidate cells.

[0140] An example of the signaling flow for this method is shown in Figures 12 and 13, where the method is applied to the TA establishment procedure. Triggers may correspond to a PDCCH order for an LTM candidate cell or to an LTM cell switching command, and some of the steps are performed by the involved network nodes, such as the source DU (S-DU), central unit (CU), and candidate DU (C-DU).

[0141] In a set of embodiments, the UE receives the configuration of one or more LTM candidate cells, then receives an LTM cell switching command, and in response to the LTM cell switching command, the UE sends a UL signal (e.g., HARQ control information) to a UL channel (e.g., PUCCH) to the LTM candidate cell, the UL signal including a scheduling request for sending Hybrid Auto Retransmission Request (HARQ) feedback.

[0142] In one embodiment, the UE receives an LTM cell switching command, and in response to the LTM cell switching command, the UE receives information on a DL control channel (e.g., PDCCH) opportunity (e.g., a given frame / subframe / time slot / one or more OFDM symbols), such as a downlink control instruction (DCI) that points to a DL data channel (e.g., PDSCH) with downlink data, and therefore, in response, the UE needs to send HARQ feedback. To send that HARQ feedback, the UE sends a scheduling request on PUCCH. According to this method, the DL control channel opportunity occurs between the reception of the LTM cell switching and the first synchronization signal (e.g., SSB) of the LTM candidate cell after the trigger.

[0143] Figure 14 illustrates several embodiments that show the additional delays that would result if this method were not present. Without this method, which may rely on the UE performing DL pre-synchronization with the LTM candidate cell's SSB before receiving a trigger, the UE would have to wait for the LTM candidate cell's SSB after receiving the trigger, then monitor the PDCCH, look up the DCI, retrieve the downlink data on the PDSCH, and only then send the HARQ feedback on the PUCCH.

[0144] Figure 15 is a flowchart illustrating an exemplary method 1500 for performing UL access, such as high-speed UL access, to an LTM candidate cell. Referring to Figure 15, in block 1502, the method includes receiving an LTM configuration for at least one LTM candidate cell from a network node. In some embodiments, the UE is configured to receive the LTM configuration from the network node. In block 1504, the method includes receiving a trigger from the network node. In some embodiments, the UE is configured to receive the trigger from the network node. In block 1506, in response to receiving the trigger, the method includes transmitting a UL signal during a UL resource opportunity (e.g., a PRACH opportunity) corresponding to the LTM candidate cell, the UL resource opportunity occurring during a time period between receiving the trigger and receiving a first synchronization signal (e.g., an SSB) of the LTM candidate cell, the first synchronization signal occurring after the trigger has been received. In some embodiments, the UE is configured to transmit a UL signal during a UL resource opportunity in response to receiving the trigger.

[0145] Figure 16 is a flowchart illustrating an exemplary method 1600 for a network node to enable a UE to perform high-speed UL access on an LTM candidate cell. Referring to Figure 16, in block 1602, the method includes the network node transmitting an LTM configuration for at least one LTM candidate cell to the UE. In block 1604, the method includes the network node transmitting a trigger to the UE. In some embodiments, the UE is configured to receive a trigger from the network node. In block 1606, the method optionally includes, in response to the UE receiving a trigger, the network node receiving a UL signal from the UE during a UL resource opportunity (e.g., a PRACH opportunity) corresponding to the LTM candidate cell, the UL resource opportunity occurring during a time period between the UE receiving the trigger and receiving a first synchronization signal (e.g., an SSB) for the LTM candidate cell, the first synchronization signal occurring after the trigger has been received by the UE, and receiving the UL signal.

[0146] Figure 17 shows an example of the QQ100 communication system according to several embodiments.

[0147] In this example, the communication system QQ100 includes a communication network QQ102 which includes an access network QQ104 such as a radio access network (RAN) and a core network QQ106 which includes one or more core network nodes QQ108. The access network QQ104 includes one or more access network nodes (one or more of which are commonly referred to as network nodes QQ110), such as network nodes QQ110a and QQ110b, or any other similar Third Generation Partnership Project (3GPP) access nodes or non-3GPP access points. Furthermore, as will be understood by those skilled in the art, network nodes are not necessarily limited to implementations in which the radio and baseband portions are supplied and integrated by a single vendor. That is, network nodes will be understood to include separate implementations or parts thereof. For example, in some embodiments, the communication network QQ102 includes one or more open RAN (ORAN) network nodes. An ORAN network node is a node in the communications network QQ102 that supports the ORAN specification (for example, a specification published by the O-RAN Alliance or any similar organization), and can operate alone or with other nodes to implement one or more functions of any node in the communications network QQ102, including one or more network nodes QQ110 and / or core network node QQ108.

[0148] An example of an ORAN network node includes an O-CU (including an Open Radio Unit (O-RU), Open Distributed Unit (O-DU), Open Central Unit (O-CU) Control Plane (O-CU-CP), or O-CU User Plane (O-CU-UP), a RAN intelligent controller (near-real-time or non-real-time) hosting software or software plug-ins such as a near-real-time control application (e.g., xApp) or a non-real-time control application (e.g., rApp), or any combination thereof (the adjective "open" specifies support for the ORAN specification). A network node may support the specification by supporting interfaces defined by the ORAN specification, such as A1, F1, W1, E1, E2, X2, Xn interfaces, an open fronthaul user plane interface, or an open fronthaul management plane interface. Furthermore, an ORAN access node may be a logical node within a physical node. In addition, an ORAN network node may be implemented in a virtualized environment where one or more network functions are virtualized (as further described below). For example, a virtualized environment may include an O-cloud computing platform organized by a service management and orchestration framework via an O-2 interface defined by the O-RAN Alliance or equivalent technology. Network node QQ110 facilitates direct or indirect connectivity of user equipment (UEs), such as by connecting UEs QQ112a, QQ112b, QQ112c, and QQ112d (one or more of which are commonly referred to as UE QQ112) to the core network QQ106 over one or more wireless connections.

[0149] Exemplary wireless communication over a wireless connection involves transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transmitting information without using wires, cables, or other material conductors. Furthermore, in different embodiments, the communication system QQ100 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that can facilitate or participate in the communication of data and / or signals, whether via a wired or wireless connection. The communication system QQ100 may include and / or interface with any type of communication, telecommunication, data, cellular, wireless network, and / or other similar types of systems.

[0150] UE QQ112 may be any of a wide variety of communication devices, including a wireless device configured, set up, and / or operable to communicate wirelessly with network node QQ110 and other communication devices. Similarly, network node QQ110 may be configured, capable, set up, and / or operable to communicate directly or indirectly with UE QQ112 and / or with other network nodes or devices in communication network QQ102 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in communication network QQ102.

[0151] In the illustrated example, the core network QQ106 connects network node QQ110 to one or more hosts, such as host QQ116. These connections may be direct or indirect, via one or more intermediate networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network QQ106 includes one or more core network nodes (e.g., core network node QQ108) structured with hardware and software components. The characteristics of these components may be substantially similar to those described for the UE, network nodes, and / or hosts, and therefore their descriptions are generally applicable to the corresponding components of core network node QQ108. An exemplary core network node includes one or more functions from among the following: Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscriber Identifier Decryption Function (SIDF), Unified Data Management (UDM), Security Edge Protected Proxy (SEPP), Network Exposure Function (NEF), and / or User Plane Function (UPF).

[0152] Host QQ116 may be owned or controlled by a service provider other than the operator or provider of the access network QQ104 and / or the communication network QQ102, and may be operated by or on behalf of the service provider. Host QQ116 may host a variety of applications to provide one or more services. Examples of such applications include data collection services such as extracting and compiling live and pre-recorded audio / video content, data on various ambient conditions detected by multiple UEs, analytical functions, social media, functions for controlling or, in some cases, interacting with remote devices, functions for alarms and surveillance centers, or any other such functions performed by the server.

[0153] Overall, the communication system QQ100 in Figure QQ1 enables connectivity between the UE, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, including, but not limited to, any other suitable wireless communication standards, such as GSM (Global System for Mobile Communications), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future-generation standard (e.g., 6G), wireless local area network (WLAN) standards such as the IEEE 802.11 standard (WiFi), and / or any other suitable wireless communication standards such as global interoperability for microwave access (WiMAX), Bluetooth, Z-Wave, near-field communications (NFC) ZigBee, LiFi, and / or LoRa and Sigfox, or any low-power wide area network (LPWAN) standards.

[0154] In some examples, the communication network QQ102 is a cellular network that implements 3GPP standardized features. Therefore, the communication network QQ102 may support network slicing to provide different logical networks to different devices connected to the communication network QQ102. For example, the communication network QQ102 may provide ultra-high reliability low latency communication (URLLC) services to some UEs while providing extended mobile broadband (eMBB) services to other UEs, and / or also provide massive machine-type communication (mMTC) / massive IoT services to further UEs.

[0155] In some examples, UE QQ112 is configured to transmit and / or receive information without direct human interaction. For example, the UE may be designed to transmit information to access network QQ104 on a predetermined schedule when triggered by an internal or external event, or in response to a request from access network QQ104. Furthermore, the UE may be configured to operate in single, multi-RAT, or multi-standard modes. For example, the UE may operate with one or a combination of Wi-Fi, NR (New Radio), and LTE, i.e., configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Enhanced UMTS Terrestrial Radio Access Network) New Radio-Dual Connectivity (EN-DC).

[0156] In this example, Hub QQ114 communicates with the access network QQ104 to facilitate indirect communication between one or more UEs (e.g., UE QQ112c and / or QQ112d) and a network node (e.g., network node QQ110b). In some examples, Hub QQ114 may be a controller, router, content source and content analysis, or any other communication device described herein with respect to the UE. For example, Hub QQ114 may be a broadband router that enables access to the core network QQ106 for the UE. In another example, Hub QQ114 may be a controller that sends commands or instructions to one or more actuators in the UE. Commands or instructions may be received from the UE, network node QQ110, or by executable code, scripts, processes, or other instructions in Hub QQ114. In yet another example, Hub QQ114 may be a data collector acting as temporary storage for UE data, and in some embodiments may perform data analysis or other processing. In yet another example, Hub QQ114 may be a content source. For example, with respect to a UE that is a VR headset, display, loudspeaker, or other media distribution device, the Hub QQ114 can retrieve VR assets, video, audio, or other media or data related to sensory information via network nodes, which the Hub QQ114 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In yet another example, the Hub QQ114 acts as a proxy server or orchestrator for the UE, especially if one or more of the UEs are low-energy IoT devices.

[0157] Hub QQ114 may have always-on / persistent or intermittent connections to network node QQ110b. Hub QQ114 may also enable different communication methods and / or schedules between Hub QQ114 and UEs (e.g., UE QQ112c and / or QQ112d), and between Hub QQ114 and the core network QQ106. In other examples, Hub QQ114 connects to the core network QQ106 and / or one or more UEs via a wired connection. Furthermore, Hub QQ114 may be configured to connect to an M2M service provider on the access network QQ104 and / or another UE via a direct connection. In some scenarios, a UE may establish a wireless connection with network node QQ110 while still being connected via wired or wireless connections through Hub QQ114. In some embodiments, the hub QQ114 may be a dedicated hub, i.e., a hub whose primary function is to route communication from the UE to the network node QQ110b and from the network node QQ110b to the UE. In other embodiments, the hub QQ114 may be a non-dedicated hub, i.e., a device that can operate to route communication between the UE and the network node QQ110b, but can also operate as a communication start point and / or end point for several data channels.

[0158] Figure 18 shows the UE QQ200 in several embodiments. As used herein, UE refers to a device that is capable of, configured, and / or operable of communicating wirelessly with network nodes and / or other UEs. Examples of UEs include, but are not limited to, smartphones, mobile phones, cell phones, voice over IP (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, gaming consoles or devices, music storage devices, playback devices, wearable terminal devices, wireless endpoints, mobile stations, tablets, laptop computers, laptop embedded equipment (LEE), laptop mounted equipment (LME), smart devices, wireless customer premises equipment (CPE), vehicles, vehicle-mounted or vehicle-embedded / integrated wireless devices, etc. Other examples include any UE identified by the Third Generation Partnership Project (3GPP), including narrowband Internet of Things (NB-IoT) UEs, machine-type communications (MTC) UEs, and / or enhanced MTC (eMTC) UEs.

[0159] A UE may support device-to-device (D2D) communication by implementing 3GPP standards for sidelink communication, dedicated short-range communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, a UE does not necessarily have a user in the sense of a human user who owns and / or operates the associated device. Instead, a UE may represent a device (e.g., a smart sprinkler controller) that is intended to be sold to or operated by a human user, but may not be associated with a particular human user, or may not be initially associated with a particular human user. Alternatively, a UE may represent a device (e.g., a smart electricity meter) that is not intended to be sold to or operated by an end user, but may be associated with a user or may operate for the user's benefit.

[0160] UE QQ200 includes a processing circuit QQ202 operably coupled via bus QQ204 to an input / output interface QQ206, a power supply QQ208, a memory QQ210, a communication interface QQ212, and / or any other components, or any combination thereof. Some UEs may utilize all or a subset of the components shown in Figure QQ2. The level of integration between components may vary from UE to UE. Furthermore, some UEs may contain multiple instances of components, such as multiple processors, memories, transceivers, transmitters, and receivers.

[0161] The processing circuit QQ202 may be configured to implement any sequential state machine capable of processing instructions and data and operating to execute instructions stored in memory QQ210 as machine-readable computer programs. The processing circuit QQ202 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc.), programmable logic with appropriate firmware, a microprocessor or digital signal processor (DSP) with appropriate software, one or more stored computer programs, a general-purpose processor, or any combination of the above. For example, the processing circuit QQ202 may include multiple central processing units (CPUs).

[0162] In this example, the input / output interface QQ206 may be configured to provide an input device, an output device, or one or more interfaces to one or more input and / or output devices. Examples of output devices include speakers, sound cards, video cards, displays, monitors, printers, actuators, emitters, smart cards, other output devices, or any combination thereof. Input devices may allow a user to capture information to the UE QQ200. Examples of input devices include touch-sensitive or presence-sensitive displays, cameras (e.g., digital cameras, digital video cameras, webcams, etc.), microphones, sensors, mice, trackballs, directional pads, trackpads, scroll wheels, smart cards, etc. Presence-sensitive displays may include capacitive or resistive touch sensors for detecting user input. Sensors may include, for example, accelerometers, gyroscopes, tilt sensors, force sensors, magnetometers, light sensors, proximity sensors, biosensors, or any combination thereof. Output devices may use the same type of interface port as input devices. For example, a Universal Serial Bus (USB) port may be used to provide input and output devices.

[0163] In some embodiments, the power supply QQ208 is structured as a battery or battery pack. Other types of power sources may be used, such as an external power source (e.g., an electrical outlet), a photovoltaic device, or a battery. The power supply QQ208 may further include a power circuit for distributing power from the power supply QQ208 itself and / or from an external power source via an interface such as an input circuit or power cable. Distributing power may, for example, be for charging the power supply QQ208. The power circuit may perform any formatting, conversion, or other modifications to the power from the power supply QQ208 to make that power suitable for each component of the UE QQ200 to which it is supplied.

[0164] Memory QQ210 may be memory, or configured to contain memory, such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, or flash drives. For example, memory QQ210 may contain one or more application programs QQ214, such as an operating system, web browser application, widget, gadget engine, or other application, and corresponding data QQ216. Memory QQ210 may store a variety of operating systems or combinations of operating systems for use by the UE QQ200.

[0165] The QQ210 memory can be configured to include several physical drive units, such as a redundant array of independent disks (RAID), flash memory, USB flash drives, external hard disk drives, thumb drives, pen drives, key drives, high-density digital versatile disk (HD-DVD) optical drives, internal hard disk drives, Blu-ray optical drives, holographic digital data storage (HDDS) optical drives, external mini dual in-line memory modules (DIMMs), synchronous dynamic random access memory (SDRAM), external microDIMM SDRAM, smart card memory such as a tamper-proof module in the form of a universal integrated circuit card (UICC) containing one or more subscriber identification modules (SIMs) such as USIM and / or ISIM, other memory, or any combination thereof. The UICC may be, for example, an embedded UICC (eUICC), an integrated UICC (iUICC), or a removable UICC commonly known as a "SIM card". Memory QQ210 may enable UE QQ200 to access instructions, application programs, etc., stored in temporary or non-temporary memory media, to offload data, or to upload data. Products such as products utilizing communication systems may be tangibly embodied as or within memory QQ210, and memory QQ210 may be a device-readable storage medium or may contain a device-readable storage medium.

[0166] The processing circuit QQ202 may be configured to communicate with an access network or other networks using the communication interface QQ212. The communication interface QQ212 may comprise one or more communication subsystems, including or communicatively coupled to an antenna QQ222. The communication interface QQ212 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or network node in the access network). Each transceiver may include a transmitter QQ218 and / or a receiver QQ220 suitable for providing network communication (e.g., optical, electrical, frequency-allocated, etc.). Furthermore, the transmitter QQ218 and receiver QQ220 may be coupled to one or more antennas (e.g., antenna QQ222), and may share circuit components, software, or firmware, or alternatively, may be implemented separately.

[0167] In the embodiments shown, the communication functions of the communication interface QQ212 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communication such as Bluetooth, near-field communication, location-based communication such as the use of the Global Positioning System (GPS) to determine location, other similar communication functions, or any combination thereof. The communication may be implemented in accordance with one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMAX, Ethernet, Transmission Control Protocol / Internet Protocol (TCP / IP), Synchronous Optical Networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), etc.

[0168] Regardless of the sensor type, a UE may provide the output of data captured by its sensors to network nodes via a wireless connection through the UE's communication interface QQ212. The data captured by the UE's sensors may be communicated to network nodes via another UE through a wireless connection. The output may be periodic (e.g., once every 15 minutes if reporting detected temperature), in response to a triggering event (e.g., an alarm is sent when humidity is detected), in response to a request (e.g., a user-initiated request), random (e.g., to equalize the load from reports from several sensors), or a continuous stream (e.g., a live video feed of a patient).

[0169] As another example, the UE may include an actuator, motor, or switch relating to a communication interface configured to receive radio input from a network node via a wireless connection. In response to the received radio input, the state of the actuator, motor, or switch may change. For example, the UE may include a motor that adjusts the control surface or rotor of a drone in flight according to the received input, or a robotic arm that performs a medical procedure according to the received input.

[0170] A UE, in the form of an Internet of Things (IoT) device, can be a device for use in one or more application areas, which include, but are not limited to, urban wearable technology, augmented industrial applications, and healthcare. Non-exclusive examples of such IoT devices are devices that are connected refrigerators or freezers, TVs, connected lighting devices, energy meters, robotic vacuum cleaners, voice-controlled smart speakers, home security cameras, motion detectors, thermostats, smoke detectors, door / window sensors, flood / humidity sensors, electric door locks, connected doorbells, air conditioning systems such as heat pumps, autonomous vehicles, surveillance systems, weather monitoring devices, vehicle parking monitoring devices, electric vehicle charging stations, smartwatches, fitness trackers, head-mounted displays for augmented reality (AR) or virtual reality (VR), wearables for haptic augmentation or perceptual augmentation, water sprinklers, animal or product tracking devices, sensors for monitoring plants or animals, industrial robots, unmanned aerial vehicles (UAVs), and any kind of medical device such as a heart rate monitor or remotely controlled surgical robot, or devices embedded in them. The UE in the form of an IoT device includes, in addition to the other components described with respect to the UE QQ200 shown in Figure 18, circuitry and / or software depending on the intended application of the IoT device.

[0171] In another specific example, in an IoT scenario, a UE may represent a machine or other device that performs monitoring and / or measurement and transmits the results of such monitoring and / or measurement to another UE and / or network node. In this case, the UE could be an M2M device, which is sometimes called an MTC device in a 3GPP context. In one specific example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, the UE may represent a vehicle, such as a car, bus, truck, ship, and airplane, or other equipment capable of monitoring its operational status and / or reporting on its operational status, or other functions associated with its operation.

[0172] In practice, any number of UEs can be used together for a single use case. For example, the first UE may be the drone itself, or integrated within the drone, providing the drone's speed information (obtained through a speed sensor) to the second UE, which is the remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (for example, by controlling an actuator) to increase or decrease the drone's speed. The first and / or second UEs may also include two or more of the functions described above. For example, the UE may have sensors and actuators and handle the communication of data about both the speed sensor and the actuator.

[0173] Figure 19 shows a network node QQ300 according to several embodiments. As used herein, a network node refers to a device that is configured, set up, and / or operable to communicate directly or indirectly with UEs in a communication network and / or with other network nodes or devices. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, node B, evolved node B (eNB), and NR node B (gNB)), O-RAN nodes, or components of O-RAN nodes (e.g., O-RU, O-DU, O-CU).

[0174] Base stations can be categorized based on the amount of coverage they provide (or, in other words, the base station's transmit power level), and are therefore sometimes called femto base stations, pico base stations, micro base stations, or macro base stations, depending on the amount of coverage they provide. A base station can be a relay node or relay donor node that controls relays. Network nodes may also include one or more (or all) parts of a distributed radio base station, such as a centralized digital unit, a distributed unit (e.g., in an O-RAN access node), and / or a remote radio unit (RRU), sometimes called a remote radio head (RRH). Such remote radio units may or may not be integrated with an antenna as an antenna-integrated radio. Parts of a distributed radio base station are sometimes called nodes in a distributed antenna system (DAS).

[0175] Other examples of network nodes include multiple transmit point (multi-TRP) 5G access nodes, MSR equipment such as multi-standard radio (MSR) BS, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base station transceiver stations (BTSs), transmit points, transmit nodes, multi-cell / multicast coordinated entities (MCEs), operation and maintenance (O&M) nodes, operation support system (OSS) nodes, self-organizing network (SON) nodes, positioning nodes (e.g., evolved serving mobile location centers (E-SMLCs)), and / or drive test minimization (MDTs).

[0176] Network node QQ300 includes a processing circuit QQ302, memory QQ304, a communication interface QQ306, and a power supply QQ308. Network node QQ300 can be assembled from multiple physically distinct components (e.g., node B components and RNC components, or BTS components and BSC components), each of which may have its own respective components. In some scenarios where network node QQ300 has multiple distinct components (e.g., BTS components and BSC components), one or more of the distinct components may be shared among several network nodes. For example, a single RNC may control multiple node Bs. In such a scenario, each unique node B-RNC pair may, in some cases, be considered a single distinct network node. In some embodiments, network node QQ300 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory QQ304 for different RATs), and some components may be reused (e.g., the same antenna QQ310 may be shared by different RATs). Network node QQ300 may also include multiple sets of various shown components for different radio technologies, such as GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, radio frequency identification (RFID), or Bluetooth radio technologies, integrated into network node QQ300. These radio technologies may be integrated into the same or different chips or sets of chips, and other components within network node QQ300.

[0177] The processing circuit QQ302 may comprise one or more combinations of microprocessors, controllers, central processing units, digital signal processors, application-specific integrated circuits, field-programmable gate arrays, or any other suitable computing devices, resources, or combinations of hardware, software, and / or encoded logic, either on its own or in conjunction with other network node QQ300 components such as memory QQ304, that are capable of providing network node QQ300 functionality.

[0178] In some embodiments, the processing circuit QQ302 includes a system-on-a-chip (SOC). In some embodiments, the processing circuit QQ302 includes one or more of the radio frequency (RF) transceiver circuit QQ312 and the baseband processing circuit QQ314. In some embodiments, the radio frequency (RF) transceiver circuit QQ312 and the baseband processing circuit QQ314 may be on separate chips (or sets of chips), boards, or units such as radio and digital units. In alternative embodiments, some or all of the RF transceiver circuit QQ312 and the baseband processing circuit QQ314 may be on the same chip or set of chips, board, or unit.

[0179] Memory QQ304 may include, but is not limited to, any form of volatile or non-volatile computer-readable memory, including persistent storage, solid memory, remote-mount memory, magnetic media, optical media, random-access memory (RAM), read-only memory (ROM), mass storage media (e.g., hard disks), removable storage media (e.g., flash drives, compact discs (CDs), or digital video discs (DVDs)), and / or any other volatile or non-volatile, non-temporary device-readable and / or computer-executable memory devices that store information, data, and / or instructions that can be used by the processing circuit QQ302. Memory QQ304 may store any suitable instructions, data, or information, including other instructions, that can be executed by the processing circuit QQ302 and utilized by the network node QQ300, including applications that include one or more computer programs, software, logic, rules, code, and tables. Memory QQ304 may be used to store calculations performed by the processing circuit QQ302 and / or data received via the communication interface QQ306. In some embodiments, the processing circuit QQ302 and memory QQ304 are integrated.

[0180] The communication interface QQ306 is used in wired or wireless signaling and / or data between network nodes, access networks, and / or UEs. As shown, the communication interface QQ306 includes (one or more) ports / (one or more) terminals QQ316 for sending and receiving data to and from the network, for example, over a wired connection. The communication interface QQ306 also includes a wireless front-end circuit QQ318, which is coupled to or, in some embodiments, may be part of the antenna QQ310. The wireless front-end circuit QQ318 includes a filter QQ320 and an amplifier QQ322. The wireless front-end circuit QQ318 may be connected to the antenna QQ310 and the processing circuit QQ302. The wireless front-end circuit may be configured to adjust signals communicated between the antenna QQ310 and the processing circuit QQ302. The wireless front-end circuit QQ318 may receive digital data to be sent to other network nodes or UEs via the wireless connection. The wireless front-end circuit QQ318 can convert digital data into a radio signal with appropriate channel and bandwidth parameters using a combination of filter QQ320 and / or amplifier QQ322. The radio signal can then be transmitted via antenna QQ310. Similarly, when receiving data, antenna QQ310 can collect a radio signal, which is then converted into digital data by the wireless front-end circuit QQ318. The digital data can then be passed to processing circuit QQ302. In other embodiments, the communication interface may comprise different components and / or different combinations of components.

[0181] In some alternative embodiments, the network node QQ300 does not include a separate radio front-end circuit QQ318; instead, the processing circuit QQ302 includes the radio front-end circuit and is connected to the antenna QQ310. Similarly, in some embodiments, all or part of the RF transceiver circuit QQ312 is part of the communication interface QQ306. In yet another embodiment, the communication interface QQ306, as part of a radio unit (not shown), includes one or more ports or terminals QQ316, the radio front-end circuit QQ318, and the RF transceiver circuit QQ312, and the communication interface QQ306 communicates with a baseband processing circuit QQ314, which is part of a digital unit (not shown).

[0182] Antenna QQ310 may include one or more antennas or antenna arrays configured to transmit and / or receive radio signals. Antenna QQ310 may be coupled to the radio front-end circuit QQ318 and may be any type of antenna capable of wirelessly transmitting and receiving data and / or signals. In some embodiments, antenna QQ310 is separate from the network node QQ300 and can be connected to the network node QQ300 through an interface or port.

[0183] The antenna QQ310, the communication interface QQ306, and / or the processing circuit QQ302 may be configured to perform any receiving operations and / or certain acquisition operations as described herein as being performed by a network node. Any information, data, and / or signals may be received from the UE, another network node, and / or any other network equipment. Similarly, the antenna QQ310, the communication interface QQ306, and / or the processing circuit QQ302 may be configured to perform any transmitting operations as described herein as being performed by a network node. Any information, data, and / or signals may be transmitted to the UE, another network node, and / or any other network equipment.

[0184] Power supply QQ308 provides power to the various components of network node QQ300 in a form suitable for each component (for example, at the voltage and current levels required for each respective component). Power supply QQ308 may further include, or be coupled to, a power management circuit for supplying power to the components of network node QQ300 to perform the functions described herein. For example, network node QQ300 may be connectable to an external power source (e.g., a power grid, an electrical outlet) via an input circuit or interface such as an electrical cable, thereby the external power source powers the power circuit of power supply QQ308. As a further example, power supply QQ308 may include a power source in the form of a battery or battery pack, connected to or integrated into the power circuit. The battery may provide backup power in the event of an external power failure.

[0185] Embodiments of the network node QQ300 may include additional components other than those shown in Figure 19 to provide several aspects of the network node's functionality, including any of the functions described herein and / or any functions necessary to support the subject matter described herein. For example, the network node QQ300 may include user interface equipment for enabling the input of information to and from the network node QQ300. This may enable a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node QQ300.

[0186] Figure 20 is a block diagram of host QQ400, which may be one embodiment of host QQ116 in Figure 17, according to various aspects described herein. Host QQ400 as used herein may be a variety of combinations of hardware and / or software, including standalone servers, blade servers, cloud implementation servers, distributed servers, virtual machines, containers, or processing resources in a server farm. Host QQ400 may provide one or more services to one or more UEs.

[0187] The host QQ400 includes a processing circuit QQ402 operably coupled to an input / output interface QQ406, a network interface QQ408, a power supply QQ410, and memory QQ412 via a bus QQ404. Other embodiments may include other components. The characteristics of these components may be substantially the same as those described with respect to the devices in previous figures, such as Figures 18 and 19, and therefore their descriptions are generally applicable to the corresponding components of the host QQ400.

[0188] Memory QQ412 may include one or more computer programs, including one or more host application programs QQ414 and data QQ416, where data QQ416 may include user data, for example, data generated by the UE for host QQ400, or data generated by host QQ400 for the UE. Embodiments of host QQ400 may utilize only a subset or all of the components shown. Host application program QQ414 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Multipurpose Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different classes, types, or implementation forms of the UE (e.g., handsets, desktop computers, wearable display systems, heads-up display systems). The host application program QQ414 can also provide user authentication and license checks, and can periodically report health, root, and content availability to a central node, such as devices in the core network or devices at the edge of the core network. Thus, the host QQ400 can select and / or direct different hosts for over-the-top services for the UE. The host application program QQ414 can support various protocols, including HTTP Live Streaming (HLS), Real-Time Messaging Protocol (RTMP), Real-Time Streaming Protocol (RTSP), and Dynamic Adaptive Streaming over HTTP (MPEG-DASH).

[0189] Figure 21 is a block diagram of a virtualized environment QQ500 in which functions implemented by several embodiments may be virtualized. In this context, virtualization means creating a virtual version of a device or apparatus, which may include virtualizing hardware platforms, storage devices, and networking resources. The virtualization used herein may apply to any device or its components described herein and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components, executed by one or more virtual machines (VMs) implemented in one or more virtualized environments QQ500 hosted by one or more hardware nodes, such as network nodes, UEs, core network nodes, or hardware computing devices acting as hosts. Furthermore, in embodiments in which the virtual nodes do not require radio connectivity (e.g., core network nodes or hosts), the nodes may be fully virtualized. In some embodiments, the virtualized environment QQ500 includes components defined by the O-RAN Alliance, such as an O-cloud environment organized by a service management and orchestration framework via an O-2 interface.

[0190] Application QQ502 (which may alternatively be referred to as a software instance, virtual appliance, network function, virtual node, virtual network function, etc.) runs in the virtualized environment Q400 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.

[0191] Hardware QQ504 includes processing circuits, memory for storing software and / or instructions executable by the hardware processing circuits, and / or other hardware devices described herein, such as network interfaces and input / output interfaces. The software is executed by the processing circuits to instantiate one or more virtualization layers QQ506 (also called a hypervisor or virtual machine monitor (VMM)), providing VM QQ508a and QQ508b (one or more of which may commonly be referred to as VM QQ508), and / or may implement any of the functions, features and / or benefits described with respect to some embodiments described herein. The virtualization layer QQ506 may present VM QQ508 with a virtual operating platform that appears to be networking hardware.

[0192] VM QQ508 features virtual processing, virtual memory, virtual networking or interfaces, and virtual storage, and may be powered by the corresponding virtualization layer QQ506. Different embodiments of the virtual appliance QQ502 may be implemented on one or more VM QQ508s, and the implementation may be carried out in different ways. Hardware virtualization is referred to as network function virtualization (NFV) in several contexts. NFV can be used to consolidate many types of network equipment onto industry-standard high-volume server hardware, physical switches, and physical storage, which may reside in data centers and customer premises equipment.

[0193] In the context of NFV, a VM QQ508 can be a software implementation of a physical machine, where programs run as if they were running on a physical, non-virtualized machine. Each VM QQ508 and its portion of the hardware QQ504 on which it runs, whether dedicated hardware for that VM and / or hardware shared by that VM with other VMs in the VM, form a separate virtual network element. Furthermore, in the context of NFV, the virtual network function is responsible for handling specific network functions running in one or more VM QQ508s on the hardware QQ504, and corresponds to the application QQ502.

[0194] Hardware QQ504 can be implemented in a standalone network node with general or specific components. Hardware QQ504 can implement some functions through virtualization. Alternatively, Hardware QQ504 may be part of a larger cluster of hardware (such as in a data center or CPE) where many hardware nodes cooperate and are managed via management and orchestration QQ510, which oversees the lifecycle management of applications QQ502. In some embodiments, Hardware QQ504 is coupled to one or more radio units, each including one or more transmitters and one or more receivers, which may be coupled to one or more antennas. The radio units may communicate directly with other hardware nodes via one or more suitable network interfaces and may be used in combination with virtual components to provide a virtual node with radio capabilities, such as a radio access node or base station. In some embodiments, some signaling may be provided using a control system QQ512, which may be used alternatively for communication between hardware nodes and radio units.

[0195] Figure 22 shows a communication diagram of host QQ602 communicating with UE QQ606 via network node QQ604 over a partial wireless connection, according to several embodiments. Next, exemplary implementations of various embodiments of the UE (such as UE QQ112a in Figure 17 and / or UE QQ200 in Figure 18), network nodes (such as network node QQ110a in Figure 17 and / or network node QQ300 in Figure 19), and hosts (such as host QQ116 in Figure 17 and / or host QQ400 in Figure 20), as described in the previous paragraph, will be described with reference to Figure 22.

[0196] Similar to the host QQ400, embodiments of the host QQ602 include hardware such as a communication interface, processing circuitry, and memory. The host QQ602 also includes software that is stored in or accessible by the host QQ602 and executable by the processing circuitry. The software includes a host application that may be capable of operating to serve a remote user, such as a UE QQ606 connected via an over-the-top (OTT) connection QQ650 extending between the UE QQ606 and the host QQ602. When serving a remote user, the host application may provide user data transmitted using the OTT connection QQ650.

[0197] Network node QQ604 includes hardware that enables network node QQ604 to communicate with host QQ602 and UE QQ606. Connectivity QQ660 can be direct or traverse one or more other intermediate networks, such as a core network (similar to core network QQ106 in Figure 17) and / or one or more public networks, private networks, or hosted networks. For example, the intermediate network could be a backbone network or the internet.

[0198] The UE QQ606 includes hardware and software that is stored in or accessible by the UE QQ606 and executable by the UE's processing circuitry. The software includes client applications, such as a web browser or operator-specific “app,” which may be capable of operating to serve human or non-human users through the UE QQ606, with the support of the host QQ602. On the host QQ602, the running host application may communicate with the running client application via the UE QQ606 and the OTT connection QQ650, which terminates on the host QQ602. When serving a user, the UE's client application may receive request data from the host's host application and provide user data in response to the request data. The OTT connection QQ650 may transfer both the request data and the user data. The UE's client application may interact with the user to generate user data that the UE's client application provides to the host application via the OTT connection QQ650.

[0199] The OTT connection QQ650 may extend via connection QQ660 between host QQ602 and network node QQ604, and via radio connection QQ670 between network node QQ604 and UE QQ606, in order to provide connectivity between host QQ602 and UE QQ606. The connections QQ660 and radio connection QQ670, which the OTT connection QQ650 may provide, are depicted abstractly to illustrate communication between host QQ602 and UE QQ606 via network node QQ604, without explicit reference to the intermediary devices and the precise routing of messages through these devices.

[0200] As an example of transmitting data via an OTT connection QQ650, in step QQ608, host QQ602 provides user data, which may be done by running a host application. In some embodiments, the user data is associated with a specific human user interacting with UE QQ606. In other embodiments, the user data is associated with UE QQ606 sharing data with host QQ602 without explicit human interaction. In step QQ610, host QQ602 initiates a transmission to carry the user data toward UE QQ606. Host QQ602 may initiate a transmission in response to a request sent by UE QQ606. The request may be triggered by human interaction with UE QQ606 or by the operation of a client application running on UE QQ606. The transmission may proceed through network node QQ604, as taught in the embodiments described throughout this disclosure. Accordingly, in step QQ612, network node QQ604 transmits the user data carried in the transmission initiated by host QQ602 to UE QQ606, in accordance with the teachings of the embodiments described throughout this disclosure. In step QQ614, UE QQ606 receives the user data carried in the transmission, which may be done by a client application running on UE QQ606 associated with a host application run by host QQ602.

[0201] In some examples, UE QQ606 runs a client application that provides user data to host QQ602. User data may be provided in response to or in reaction to data received from host QQ602. Thus, in step QQ616, UE QQ606 may provide user data, which may be done by running a client application. When providing user data, the client application may further consider user input received from the user via the input / output interface of UE QQ606. Regardless of the particular format in which the user data is provided, UE QQ606 initiates the transmission of the user data to host QQ602 via network node QQ604 in step QQ618. In step QQ620, in accordance with the teachings of embodiments described throughout this disclosure, network node QQ604 receives user data from UE QQ606 and initiates the transmission of the received user data to host QQ602. In step QQ622, host QQ602 receives user data carried in a transmission initiated by UE QQ606.

[0202] One or more of the various embodiments improve the performance of OTT services provided to UE QQ606 by using OTT connection QQ650, in which wireless connection QQ670 forms the final segment. More precisely, the teachings of these embodiments may reduce the delay when transmitting UL signals to LTM candidate cells during TA establishment / update procedures, thereby providing benefits such as (one or more) reduced user wait / connection times, better responsiveness, and improved overall UE connection reliability.

[0203] In an exemplary scenario, factory status information may be collected and analyzed by the host QQ602. As another example, the host QQ602 may process audio and video data that may be extracted from the UE for use in creating maps. As yet another example, the host QQ602 may collect and analyze real-time data to help control vehicle congestion (e.g., control traffic signals). As yet another example, the host QQ602 may store surveillance video uploaded by the UE. As yet another example, the host QQ602 may store or control access to media content, such as video, audio, VR, or AR, which the host QQ602 can broadcast, multicast, or unicast to the UE. As yet another example, the host QQ602 may be used for energy pricing, remote control of non-time-constrained electrical loads to balance generation needs, location services, presentation services (such as compiling diagrams etc. from data collected from remote devices), or any other function of collecting, extracting, storing, analyzing, and / or transmitting data.

[0204] In some embodiments, measurement procedures may be provided for the purpose of monitoring data rate, latency, and other factors, which are improved by one or more embodiments. Further optional network functions may be available to reconfigure the OTT connection QQ650 between host QQ602 and UE QQ606 in response to variations in measurement results. Measurement procedures and / or network functions for reconfiguring the OTT connection may be implemented in the software and hardware of host QQ602 and / or UE QQ606. In some embodiments, sensors (not shown) may be deployed in or in relation to other devices through which the OTT connection QQ650 passes, and the sensors may participate in the measurement procedure by supplying values ​​of the monitored quantities exemplified above, or values ​​of other physical quantities that the software can calculate or estimate the monitored quantities of. Reconfiguring the OTT connection QQ650 may include message formatting, retransmission settings, preferred routing, etc., and the reconfiguration does not require direct modification of the operation of network node QQ604. Such procedures and functions are known and practiced in the art. In some embodiments, the measurements may involve proprietary UE signaling by the host QQ602 to facilitate measurements such as throughput, propagation time, and latency. The measurements may be implemented in which software uses an OTT-connected QQ650 to cause messages, particularly empty or "dummy" messages, to be sent while monitoring propagation time, errors, etc.

[0205] The computing devices described herein (e.g., UEs, network nodes, hosts) may include the shown combinations of hardware components, but other embodiments may comprise computing devices with different combinations of components. It should be understood that these computing devices may comprise any suitable combination of hardware and / or software required to perform the tasks, features, functions, and methods disclosed herein. The determining, calculating, acquiring, or similar operations described herein may be performed by processing circuits, which may process information by, for example, converting acquired information to other information, comparing acquired or converted information to information stored in a network node, and / or performing one or more operations based on the acquired or converted information and as a result of the processing making decisions. Furthermore, although components are illustrated as a single box located within a larger box, or as a single box nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that constitute a single shown component, and functions may be separated between the distinct components. For example, a communication interface may be configured to include any of the components described herein, and / or the functions of those components may be separated between the processing circuit and the communication interface. In another example, the non-computation-intensive functions of any of such components may be implemented in software or firmware, while the computation-intensive functions may be implemented in hardware.

[0206] In some embodiments, some or all of the functions described herein may be provided by a processing circuit that executes instructions stored in memory, which in some embodiments may be a computer program product in the form of a non-temporary computer-readable storage medium. In alternative embodiments, some or all of the functions may be provided by a processing circuit without executing instructions stored in a separate or individual device-readable storage medium, such as in a hardwired manner. In any of those particular embodiments, whether or not it executes instructions stored in a non-temporary computer-readable storage medium, the processing circuit may be configured to perform the functions described. The benefits provided by such functions are enjoyed by the processing circuit alone, or by the computing device as a whole, but not limited to other components of the computing device, and / or generally by the end user and the wireless network.

[0207] Further embodiments

[0208] Group A Embodiment A1. A method implemented by user equipment (UE) for providing high-speed uplink (UL) access on an L1 / L2 trigger cell-to-cell mobility (LTM) candidate cell, the method being: Receiving LTM settings for at least one LTM candidate cell from the network node (1502), Receiving triggers from network nodes (1504), In response to receiving a trigger, transmit a UL signal during a UL resource opportunity (e.g., a PRACH opportunity) corresponding to an LTM candidate cell, using data in the LTM setup (1506), wherein the UL resource opportunity occurs during a time period between receiving the trigger and receiving a first synchronization signal (e.g., an SSB) of the LTM candidate cell, and the first synchronization signal occurs after the trigger has been received (1506) Methods that include... A2. The trigger includes at least one of the following: RRC message, IE, field, parameter, MAC control element (MAC CE), or PDCCH order, and the trigger is A trigger for a time alignment (TA) establishment / update procedure, wherein the trigger is received from a network node in a serving cell (e.g., a PDCCH order from a primary cell or primary SCG cell) and instructs the UE to send a UL signal (e.g., a PRACH preamble) for the time alignment (TA) establishment / update procedure, and / or A trigger for an LTM cell switching procedure from a network node in a serving cell (e.g., MAC CE from a primary cell or primary SCG cell), wherein the trigger corresponds to an LTM cell switching command that indicates the LTM candidate cell (e.g., LTM configuration ID) that the UE should access. The method according to Embodiment A1, which corresponds to one or more of the above. A3. The method according to Embodiment A1 or A2, wherein the trigger indicates at least one of the following: a MAC control element (MAC CE), downlink control instruction (DCI) layer 1 (L1) signaling, layer 2 (L2) signaling, or L1 / L2 signaling, and a configured LTM candidate cell (e.g., LTM candidate ID or LTM configuration ID). A4. The UL signal is In LTM cell switching, the PRACH preamble sent to the PRACH opportunity of the LTM candidate cell, In the Time Alignment (TA) establishment / update procedure, the PRACH preamble sent to the PRACH opportunity of the LTM candidate cell, Sounding reference signals (SRS) sent to LTM candidate cells during the TA establishment / update procedure, Control information (e.g., scheduling requests) transmitted over the physical uplink control channel (PUCCH) of the LTM candidate cell during the LTM cell switching procedure, and / or UL data transmitted over the physical uplink shared channel (PUSCH) of an LTM candidate cell during the LTM cell switching procedure (for example, including RRC reconfiguration completion as the payload) The method according to any one of embodiments A1 to A3, comprising one or more of the above. A5. UL resource opportunities, PRACH opportunity for LTM candidate cells, The sounding reference signal resource or resource opportunity of the LTM candidate cell that has been set (for example, in the RRC setting of the LTM candidate cell) and / or allocated (for example, in the LTM cell switching command), (For example, in the RRC configuration of the LTM candidate cell) the configured and / or (for example, in the LTM cell switching command) the allocated physical uplink control channel (PUCCH) resources or resource opportunities of the LTM candidate cell, and / or Physical uplink shared channel (PUSCH) resources or resource opportunities of an LTM candidate cell that have been configured (for example, in the RRC configuration of the LTM candidate cell) and / or allocated (for example, in the LTM cell switching command). The method according to any one of embodiments A1 to A4, which includes one or more of the above. A6. The method according to any one of embodiments A1 to A5, wherein the UE transmits a UL signal to the LTM candidate cell in one or more configured UL channel resources in time and frequency before the next synchronization signal (e.g., SSB) of the LTM candidate cell, and the UE transmits a UL signal in one or more first configured UL channel resources (e.g., first PRACH opportunity) in time and frequency after receiving a trigger. A7. The method according to any one of embodiments A1 to A6, wherein, prior to receiving a trigger, the UE receives a setting from the serving cell that includes one or more LTM candidate cell settings to be applied when it receives an LTM cell switching command. A8. The method according to any one of Embodiments A1 to A7, wherein, prior to receiving a trigger, the UE receives a setting for establishing / updating time alignment with an LTM candidate cell, and the setting includes one or more UL relation parameters, such as a PRACH preamble setting, one or more PRACH opportunities, and one or more PRACH frequency resources. A9. The method according to any one of embodiments A1 to A8, wherein the UE has configured multiple LTM candidate cells, and when the UE receives a trigger and transmits a UL signal to an LTM candidate cell that is not in a first subset of the multiple LTM candidate cells, the UL signal is transmitted to the LTM candidate cell that is not in a first subset in time and frequency after the next synchronization signal (e.g., SSB) of the LTM candidate cell in one or more configured UL channel resources. A10. Prior to receiving a trigger, the UE performs a downlink (DL) synchronization (or pre-synchronization) with at least one of the LTM candidate cells, and the DL synchronization is performed. i) Detecting and / or measuring at least one synchronization signal of an LTM candidate cell, wherein at least one synchronization signal includes the SSB of the LTM candidate cell, and / or CSI-RS and / or TRS and / or PSS and / or SSS, which are associated with an SSB index and / or identifier and transmitted in a spatial direction (beam). ii) Conduct detailed time tracking to obtain complete timing information for LTM candidate cells. iii) Obtaining time boundaries for time units of a given LTM candidate cell, such as time slots, OFDM symbols, subframes, and / or wireless frames, and / or iv) Synchronize the clock with the time boundaries of a given LTM candidate cell's time unit, such as a time slot, OFDM symbol, subframe, and / or wireless frame. The method according to any one of embodiments A1 to A9, which includes one or more of the above. A11. Providing user data, Forwarding user data to a host via transmission to a network node and The method according to any one of embodiments A1 to A10, further comprising:

[0209] Group B Embodiment B1. A method implemented by a network node for enabling user equipment (UE) to perform high-speed uplink (UL) access on L1 / L2 trigger cell-to-cell mobility (LTM) candidate cells, wherein the method is: Sending LTM settings for at least one LTM candidate cell from the network node to the UE (1602), Sending a trigger from the network node to the UE (1604) Methods that include... B1A. The method according to Embodiment B1, further comprising receiving a UL signal from the UE during a UL resource opportunity (e.g., a PRACH opportunity) corresponding to an LTM candidate cell, after sending a trigger (1606), the UL resource opportunity occurring during a time period between the UE receiving the trigger and the UE receiving a first synchronization signal (e.g., an SSB) for the LTM candidate cell, the first synchronization signal occurring after the trigger has been received by the UE, and receiving a UL signal (1606). B2. The trigger includes at least one of the following: RRC message, IE, field, parameter, MAC control element (MAC CE), or PDCCH order, and the trigger is A trigger for a time alignment (TA) establishment / update procedure, wherein the trigger is received from a network node in a serving cell (e.g., a PDCCH order from a primary cell or primary SCG cell) and instructs the UE to send a UL signal (e.g., a PRACH preamble) for the time alignment (TA) establishment / update procedure, and / or A trigger for an LTM cell switching procedure from a network node in a serving cell (e.g., MAC CE from a primary cell or primary SCG cell), wherein the trigger corresponds to an LTM cell switching command that indicates the LTM candidate cell (e.g., LTM configuration ID) that the UE should access. The method according to Embodiment B1 or B1A, corresponding to one or more of the above. B3. The method according to Embodiment B1 or B2, wherein the trigger indicates at least one of the following: a MAC control element (MAC CE), downlink control instruction (DCI) layer 1 (L1) signaling, layer 2 (L2) signaling, or L1 / L2 signaling, and a configured LTM candidate cell (e.g., LTM candidate ID or LTM configuration ID). B4. The UL signal is In LTM cell switching, the PRACH preamble sent to the PRACH opportunity of the LTM candidate cell, In the Time Alignment (TA) establishment / update procedure, the PRACH preamble sent to the PRACH opportunity of the LTM candidate cell, Sounding reference signals (SRS) sent to LTM candidate cells during the TA establishment / update procedure, Control information (e.g., scheduling requests) transmitted over the physical uplink control channel (PUCCH) of the LTM candidate cell during the LTM cell switching procedure, and / or UL data transmitted over the physical uplink shared channel (PUSCH) of an LTM candidate cell during the LTM cell switching procedure (for example, including RRC reconfiguration completion as the payload) The method according to any one of Embodiments B1 to B3, which includes one or more of the above. B5. UL resource opportunities, PRACH opportunity for LTM candidate cells, The sounding reference signal resource or resource opportunity of the LTM candidate cell that has been set (for example, in the RRC setting of the LTM candidate cell) and / or allocated (for example, in the LTM cell switching command), (For example, in the RRC configuration of the LTM candidate cell) the configured and / or (for example, in the LTM cell switching command) the allocated physical uplink control channel (PUCCH) resources or resource opportunities of the LTM candidate cell, and / or Physical uplink shared channel (PUSCH) resources or resource opportunities of an LTM candidate cell that have been configured (for example, in the RRC configuration of the LTM candidate cell) and / or allocated (for example, in the LTM cell switching command). The method according to any one of embodiments B1 to B4, which includes one or more of the above. B6. The method according to any one of embodiments B1 to B5, wherein the UE transmits a UL signal to the LTM candidate cell in one or more configured UL channel resources in time and frequency before the next synchronization signal (e.g., SSB) of the LTM candidate cell, and the UE transmits a UL signal in one or more first configured UL channel resources (e.g., first PRACH opportunity) in time and frequency after receiving a trigger. B7. The method according to any one of embodiments B1 to B6, wherein, prior to the UE receiving a trigger, the UE receives a configuration from a network node in the serving cell, which includes one or more LTM candidate cell configurations to be applied when an LTM cell switching command is received. B8. The method according to any one of Embodiments B1 to B7, wherein, prior to receiving a trigger, the UE receives a setting for establishing / updating time alignment with an LTM candidate cell, and the setting includes one or more UL relation parameters such as a PRACH preamble setting, one or more PRACH opportunities, and one or more PRACH frequency resources. B9. The method according to any one of embodiments B1 to B8, wherein the UE has configured multiple LTM candidate cells, and when the UE receives a trigger and transmits a UL signal to an LTM candidate cell that is not in a first subset of the multiple LTM candidate cells, the UL signal is transmitted to the LTM candidate cell that is not in a first subset in time and frequency after the next synchronization signal (e.g., SSB) of the LTM candidate cell. B10. Prior to receiving a trigger, the UE performs a downlink (DL) synchronization (or pre-synchronization) with at least one of the LTM candidate cells, and the DL synchronization is performed. i) Detecting and / or measuring at least one synchronization signal of an LTM candidate cell, wherein at least one synchronization signal includes the SSB of the LTM candidate cell, and / or CSI-RS and / or TRS and / or PSS and / or SSS, which are associated with an SSB index and / or identifier and transmitted in a spatial direction (beam). ii) Conduct detailed time tracking to obtain complete timing information for LTM candidate cells. iii) Obtaining time boundaries for time units of a given LTM candidate cell, such as time slots, OFDM symbols, subframes, and / or wireless frames, and / or iv) Synchronize the clock with the time boundaries of a given LTM candidate cell's time unit, such as a time slot, OFDM symbol, subframe, and / or wireless frame. The method according to any one of embodiments B1 to B9, which includes one or more of the above. B11. Obtaining user data, Forwarding user data to a host or user device and The method according to any one of embodiments B1 to B10, further comprising:

[0210] Group C Embodiment C1. User equipment for providing high-speed uplink (UL) access on L1 / L2 trigger cell-to-cell mobility (LTM) candidate cells, A processing circuit configured to perform any of the steps described in any one of the embodiments of Group A, A power supply circuit configured to supply power to the processing circuit and User equipment equipped with these features. C2. A network node for providing high-speed uplink (UL) access on L1 / L2 trigger cell-to-cell mobility (LTM) candidate cells, wherein the network node is A processing circuit configured to perform any of the steps described in any one of the embodiments of Group B, A power supply circuit configured to supply power to the processing circuit and A network node equipped with these features. C3. User equipment (UE) for providing high-speed uplink (UL) access on L1 / L2 trigger cell-to-cell mobility (LTM) candidate cells, wherein the UE is An antenna configured to send and receive wireless signals, A wireless front-end circuit connected to an antenna and a processing circuit, configured to adjust the signals communicated between the antenna and the processing circuit, The processing circuit is configured to perform any of the steps described in any one of the embodiments of Group A. Wireless front-end circuit and An input interface connected to a processing circuit and configured to allow information input to the UE to be processed by the processing circuit, An output interface connected to a processing circuit and configured to output information from the UE processed by the processing circuit, A battery and a processing circuit connected to the UE, configured to supply power to the UE. User equipment (UE) equipped with these features. C4. A host configured to operate in a communication system for providing over-the-top (OTT) services, wherein the host is A processing circuit configured to provide user data, A network interface configured to initiate the transmission of user data to a network node in a cellular network for transmission to a user device (UE), wherein the network node has a communication interface and a processing circuit, and the processing circuit of the network node is configured to perform any of the operations described in any one of the embodiments of Group B in order to transmit user data from a host to a UE, and A host equipped with these features. C5. The host's processing circuit is configured to run a host application that provides user data. The UE includes processing circuitry configured to run a client application associated with the host application in order to receive user data transmitted from the host. The host described in Embodiment C4. C6. A method implemented on a host configured to operate in a communication system further including network nodes and user equipment (UE), the method being: To provide user data for UE, Initiating a transmission to transport user data to a UE via a cellular network comprising network nodes, wherein the network nodes perform any of the operations described in any one of the embodiments of Group B in order to transmit user data from a host to a UE. Methods that include... C7. The method of embodiment C6, further comprising transmitting user data provided by the host for the UE at a network node. C8. The method according to Embodiment C6 or C7, wherein user data is provided on the host by running a host application that interacts with a client application running on the UE, and the client application is associated with the host application. C9. A communication system configured to provide over-the-top (OTT) services, wherein the communication system is Being a host, A processing circuit configured to provide user data for a user equipment (UE), wherein the user data is associated with an over-the-top service, A network interface configured to initiate the transmission of user data to a cellular network node for transmission to a UE, wherein the network node has a communication interface and a processing circuit, and the processing circuit of the network node is configured to perform any of the operations described in any one of the embodiments of Group B in order to transmit user data from the host to the UE. A communication system that includes a host. C10. Network nodes, and / or UE The communication system according to embodiment C9, further comprising the above. C11. A host configured to operate in a communication system for providing over-the-top (OTT) services, wherein the host is A processing circuit configured to initiate the reception of user data, A network interface configured to receive user data from a network node in a cellular network, wherein the network node has a communication interface and a processing circuit, and the processing circuit of the network node is configured to perform any of the operations described in any one of the embodiments of Group B in order to receive user data from a user equipment (UE) on behalf of a host, and A host equipped with these features. C12. The host processing circuit is configured to run a host application that receives user data. The host application is configured to interact with a client application running on the UE, and the client application is associated with the host application. A host according to embodiment C10 or C11. C13. A host according to embodiment C11 or C12, wherein initiating the reception of user data includes requesting user data. C14. A method implemented by a host configured to operate in a communication system further including network nodes and user equipment (UE), the method being: Initiating reception of user data from the UE on the host, wherein the user data originates from a transmission received by the network node from the UE, and the network node initiates reception by performing one of the steps described in any one of the embodiments of Group B in order to receive user data from the UE for the host. Methods that include... C15. The method according to embodiment C14, further comprising transmitting received user data to a host at a network node. C16. A host configured to operate in a communication system for providing over-the-top (OTT) services, wherein the host is A processing circuit configured to provide user data, A network interface configured to initiate the transmission of user data to a cellular network for transmission to a user device (UE), wherein the UE comprises a communication interface and a processing circuit, and the UE's communication interface and processing circuit are configured to perform any of the operations described in any one of the embodiments of Group A in order to receive user data from a host. A host equipped with these features. C17. The host according to Embodiment C16, further comprising a cellular network, network nodes configured to communicate with the UE in order to transmit user data from the host to the UE. C18. The processing circuit of the host is configured to execute a host application, thereby providing user data, The host application is configured to interact with a client application running on the UE, and the client application is associated with the host application, The host according to Embodiment C16 or C17. C19. A method implemented by a host operating in a communication system further including a network node and a user equipment (UE), the method comprising: Providing user data for the UE; Initiating a transmission to carry the user data to the UE via a cellular network comprising a network node, wherein the UE performs any of the operations described in any one of the Embodiments of Group A to receive the user data from the host, initiating the transmission; A method comprising. C20. In the host, executing a host application associated with a client application running on the UE to receive user data from the host application The method according to Embodiment C19, further comprising. C21. In the host, transmitting input data to a client application running on the UE, the input data being provided by executing the host application; Further comprising, The method according to Embodiment C20, wherein the user data is provided by the client application in response to the input data from the host application. C22. A host configured to operate in a communication system for providing an over-the-top (OTT) service, the host comprising: A processing circuit configured to provide user data; A network interface configured to initiate transmission of user data to a cellular network for transmission to a user equipment (UE), wherein the UE comprises a communication interface and a processing circuit, and the communication interface and processing circuit of the UE are configured to perform any of the steps described in any one of the embodiments of Group A for transmitting user data to a host, the network interface and A host comprising C23. The host according to embodiment C22, wherein the cellular network further comprises a network node configured to communicate with the UE for transmitting user data from the UE to the host. C24. The processing circuit of the host is configured to execute a host application, thereby providing user data, The host application is configured to interact with a client application running on the UE, and the client application is associated with the host application. The host according to embodiment C22 or C23. C25. A method implemented by a host configured to operate in a communication system further comprising a network node and a user equipment (UE), the method comprising: Receiving, at the host, user data transmitted to the host via the network node by the UE, wherein the UE performs any of the steps described in any one of the embodiments of Group A for transmitting user data to the host. The method comprising. C26. Further comprising, at the host, executing a host application associated with a client application running on the UE for receiving user data from the UE. The method according to embodiment C25. C27. On the host, sending input data to a client application running on the UE, wherein the input data is provided by running the host application. It further includes, The method according to Embodiment C25 or C26, wherein user data is provided by a client application in response to input data from a host application.

[0211] References [1]3GPP TS38.331 v17.1.0,Radio Resource Control(RRC) Protocol Specification [2]3GPP TS38.133, v18.0.0,Requirements for Support of Radio Resource Management [3]3GPP TS38.213,v17.4.0,Physical Layer Procedures for Control

[0212] Abbreviation At least some of the following abbreviations may be used in this disclosure. In the event of any inconsistency between abbreviations, the usage of the abbreviation above should be preferred. If a listing appears multiple times below, the first listing should be preferred over subsequent listings (one or more).

[0213] 1xRTT CDMA2000 1xWireless Transmission Technology 3GPP Third Generation Partnership Project 5G (5th generation) 6G (6th Generation) ABS Almost Blank Subframe ARQ Automatic Resend Request AWGN Additive White Gaussian Noise BCCH Broadcast Control Channel BCH Broadcast Channel CA Career Aggregation CC Carrier Component CCCH SDU Common Control Channel SDU CDMA Code Division Multiple Access CGI Cell Global Identifier CIR Channel Impulse Response CP Cyclic Prefix CPICH Common Pilot Channel CPICH Ec / No CPICH received energy per chip divided by the power density in the band CQI Channel Quality Information C-RNTI Cell RNTI CSI Channel State Information DCCH Dedicated Control Channel DL Downlink DM Demodulation DMRS Demodulation Reference Signal DRX Discontinuous Reception DTX Discontinuous Transmission DTCH Dedicated Traffic Channel DUT Device Under Test E-CID Enhanced Cell ID (positioning method) eMBMS Evolved Multimedia Broadcast Multicast Service E-SMLC Evolved Serving Mobile Location Center ECGI Evolved CGI eNB E-UTRAN Node B ePDCCH Enhanced Physical Downlink Control Channel E-SMLC Evolved Serving Mobile Location Center E-UTRA Evolved UTRA E-UTRAN Evolved UTRAN FDD Frequency Division Duplex FFS Further Consideration Required gNB Base Station in NR GNSS Global Navigation Satellite System HARQ Hybrid Automatic Repeat Request HO Handover HSPA High-Speed ​​Packet Access HRPD High-Speed ​​Packet Data LOS line of sight LPP LTE positioning protocol LTE Long-Term Evolution MAC Media Access Control MAC Message Authentication Code MBSFN Multimedia Broadcast Multicast Service Single Frequency Network MBSFN ABS MBSFN Almost Blank Subframe Minimizing MDT drive tests MIB Master Information Block MME Mobility Management Entity MSC Mobile Switching Center NPDCCH Narrowband Physical Downlink Control Channel NR new radio OCNG OFDMA Channel Noise Generator OFDM (Orthogonal Frequency Division Multiplexing) OFDMA (Orthogonal Frequency Division Multiple Access) OSS Operation Support System OTDOA Observation Arrival Time Difference O&M operation and maintenance PBCH Physical Broadcast Channel P-CCPCH Primary Common Control Physical Channel PCell Primary Cell PCFICH Physical Control Format Indicator Channel PDCCH Physical Downlink Control Channel PDCP Packet Data Convergence Protocol PDP Profile Delay Profile PDSCH Physical Downlink Shared Channel PGW Packet Gateway PHICH Physical Hybrid ARQ Instruction Channel PLMN Public Land Mobile Network PMI Precoder Matrix Indicator PRACH Physical Random Access Channel PRS positioning reference signal PSS primary synchronization signal PUCCH Physical Uplink Control Channel PUSCH Physical Uplink Shared Channel RACH Random Access Channel QAM (Quaternary Amplitude Modulation) RAN (Radio Access Network) RAT (Radio Access Technology) RLC Wireless Link Control RLM Wireless Link Management RNC Wireless Network Controller RNTI (Radio Network Temporary Identifier) RRC (Radio Resource Control) RRM Wireless Resource Management RS reference signal RSCP Received Signal Code Power RSRP reference symbol received power or Reference signal received power RSRQ reference signal reception quality or Reference symbol reception quality RSSI Received Signal Strength Indicator RSTD reference signal time difference SCH Synchronization Channel SCell 2nd Cell SDAP Service Data Adaptive Protocol SDU Service Data Unit SFN System Frame Number SGW Serving Gateway SI System Information SIB System Information Block SNR (Signal-to-Noise Ratio) SON Self-Optimizing Network SS synchronization signal SSS secondary synchronization signal TDD time division duplex TDOA arrival time difference TOA arrival time TSS 3rd synchronous signal TTI transmission time interval UE User Equipment UL Uplink USIM (Universal Subscriber Identification Module) UTDOA Uplink Arrival Time Difference WCDMA WideCDMA WLAN (Wide Local Area Network)

Claims

1. A method (1500) performed by a user device (UE) for uplink (UL) access on an L1 / L2 trigger cell-to-cell mobility (LTM) candidate cell, wherein the method is: Receiving LTM settings for at least one LTM candidate cell from a network node (1502), Receiving a trigger from the aforementioned network node (1504), Receiving a first synchronization signal from the LTM candidate cell (1505), In response to receiving the trigger, transmit a UL signal to the LTM candidate cell during a UL resource opportunity (1506), wherein the UL resource opportunity occurs during a time period between receiving the trigger and receiving the first synchronization signal from the LTM candidate cell, and the first synchronization signal is received after the trigger has been received, and transmit a UL signal (1506) Method (1500), including the above.

2. The trigger includes at least one of the following: RRC message, IE, field, parameter, MAC control element (MAC CE), or PDCCH order, and the trigger is A trigger for a time alignment (TA) establishment / update procedure, wherein the trigger is received from the network node in the serving cell and instructs the UE to transmit a UL signal for the TA establishment / update procedure, and / or A trigger for an LTM cell switching procedure from the network node in the serving cell, wherein the trigger corresponds to an LTM cell switching command that indicates the LTM candidate cell to be accessed by the UE. The method according to claim 1, which corresponds to one or more of the following.

3. The method according to claim 1 or 2, wherein the trigger corresponds to a MAC control element (MAC CE), downlink control information (DCI) layer 1 (L1) signaling, layer 2 (L2) signaling, and L1 / L2 signaling, and indicates at least one of the set LTM candidate cells.

4. The UL signal is, In LTM cell switching, the PRACH preamble transmitted during the physical random access channel (PRACH) opportunity of the LTM candidate cell, In the TA establishment / update procedure, the PRACH preamble transmitted during the PRACH opportunity of the LTM candidate cell, In the TA establishment / update procedure, the sounding reference signal (SRS) transmitted to the LTM candidate cell, Control information transmitted on the physical uplink control channel (PUCCH) of the LTM candidate cell in the LTM cell switching procedure, and / or UL data transmitted on the physical uplink shared channel (PUSCH) of the LTM candidate cell in the LTM cell switching procedure. The method according to any one of claims 1 to 3, comprising one or more of the above.

5. The aforementioned UL resource opportunity, PRACH opportunity of the aforementioned LTM candidate cell, The sounding reference signal resource or resource opportunity of the configured and / or allocated LTM candidate cell, The configured and / or allocated physical uplink control channel (PUCCH) resources or resource opportunities of the LTM candidate cell, and / or The configured and / or allocated physical uplink shared channel (PUSCH) resources or resource opportunities of the LTM candidate cell. The method according to any one of claims 1 to 4, comprising one or more of the above.

6. The method according to any one of claims 1 to 5, wherein the UE transmits the UL signal to the LTM candidate cell in a set UL channel resource in time and frequency before the next synchronization signal of the LTM candidate cell, and the UE transmits the UL signal in a first set UL channel resource in time and frequency after the reception of the trigger.

7. The method according to any one of claims 1 to 6, wherein, prior to receiving the trigger, the UE receives a setting from the serving cell that includes one or more LTM candidate cell settings that are applied when an LTM cell switching command is received.

8. The method according to any one of claims 1 to 7, wherein, prior to receiving the trigger, the UE receives a setting for establishing / updating time synchronization with the LTM candidate cell, the setting includes one or more UL relational parameters such as a PRACH preamble setting, a PRACH opportunity, and a PRACH frequency resource.

9. The method according to any one of claims 1 to 8, wherein the UE has a plurality of LTM candidate cells set up, and when the UE receives the trigger and transmits a UL signal to an LTM candidate cell that is not in the first subset of the plurality of LTM candidate cells, the UE transmits the UL signal to the LTM candidate cell that is not in the first subset in a set UL channel resource in time and frequency after the next synchronization signal of the LTM candidate cell.

10. Prior to receiving the trigger, the UE performs a downlink (DL) synchronization with at least one of the LTM candidate cells, and the DL synchronization is i) Detecting and / or measuring at least one synchronization signal of the LTM candidate cell, wherein the at least one synchronization signal includes the SSB of the LTM candidate cell, and / or CSI-RS and / or TRS and / or PSS and / or SSS, which are associated with an SSB index and / or identifier and transmitted in the spatial direction. ii) Perform detailed time tracking to obtain complete timing information for the LTM candidate cells. iii) Obtaining time boundaries of a given LTM candidate cell in time units, such as time slots, OFDM symbols, subframes, and / or wireless frames, and / or iv) Synchronize the clock with the time boundaries of a given LTM candidate cell's time unit, such as a time slot, OFDM symbol, subframe, and / or wireless frame. The method according to any one of claims 1 to 9, comprising one or more of the above.

11. Providing user data, The user data is forwarded to the host via transmission to the aforementioned network node. The method according to any one of claims 1 to 10, further comprising:

12. A method (1600) implemented by a network node for user equipment (UE) uplink (UL) access on an L1 / L2 trigger cell-to-cell mobility (LTM) candidate cell, wherein the method is The network node transmits the LTM configuration for at least one LTM candidate cell to the UE (1602), Sending a trigger from the network node to the UE (1604) Method (1600), including the above.

13. After transmitting the trigger, (1606) Receiving a UL signal from the UE during a UL resource opportunity corresponding to the LTM candidate cell, the UL resource opportunity occurring during a time period between the UE receiving the trigger and the UE receiving a first synchronization signal from the LTM candidate cell, the first synchronization signal being received after the trigger has been received by the UE, and receiving a UL signal. The method according to claim 12, further comprising:

14. The trigger includes at least one of the following: RRC message, IE, field, parameter, MAC control element (MAC CE), or PDCCH order, and the trigger is A trigger for a time alignment (TA) establishment / update procedure, wherein the trigger is received from the network node in the serving cell and instructs the UE to transmit a UL signal for the TA establishment / update procedure, and / or A trigger for an LTM cell switching procedure received from the network node in the serving cell, wherein the trigger corresponds to an LTM cell switching command that indicates the LTM candidate cell to be accessed by the UE. The method according to claim 12 or 13, corresponding to one or more of the above.

15. The method according to any one of claims 12 to 14, wherein the trigger corresponds to a MAC control element (MAC CE), downlink control information (DCI) layer 1 (L1) signaling, layer 2 (L2) signaling, and L1 / L2 signaling, and indicates at least one of the set LTM candidate cells.

16. The UL signal, In LTM cell switching, the PRACH preamble transmitted during the physical random access channel (PRACH) opportunity of the LTM candidate cell, In the Time Alignment (TA) establishment / update procedure, the PRACH preamble transmitted during the PRACH opportunity of the LTM candidate cell, In the TA establishment / update procedure, the sounding reference signal (SRS) transmitted to the LTM candidate cell, Control information transmitted on the physical uplink control channel (PUCCH) of the LTM candidate cell in the LTM cell switching procedure, and / or UL data transmitted on the physical uplink shared channel (PUSCH) of the LTM candidate cell in the LTM cell switching procedure. The method according to any one of claims 12 to 15, comprising one or more of the above.

17. UL resource opportunities, PRACH opportunity of the aforementioned LTM candidate cell, The sounding reference signal resource or resource opportunity of the configured LTM candidate cell, The configured and / or allocated physical uplink control channel (PUCCH) resources or resource opportunities of the LTM candidate cell, and / or The configured and / or allocated physical uplink shared channel (PUSCH) resources or resource opportunities of the LTM candidate cell. The method according to any one of claims 12 to 16, comprising one or more of the above.

18. The method according to any one of claims 12 to 17, wherein the UE transmitting a UL signal to the LTM candidate cell in a set UL channel resource in time and frequency before the next synchronization signal of the LTM candidate cell includes the UE transmitting the UL signal in a first set UL channel resource in time and frequency after receiving the trigger.

19. The method according to any one of claims 12 to 18, wherein, prior to the UE receiving the trigger, the UE receives a setting from the network node in the serving cell, which includes one or more LTM candidate cell settings that will be applied when an LTM cell switching command is received.

20. The method according to any one of claims 12 to 19, wherein, prior to receiving the trigger, the UE receives a setting for establishing / updating time alignment with the LTM candidate cell, the setting includes one or more UL relational parameters such as a PRACH preamble setting, a PRACH opportunity, and a PRACH frequency resource.

21. The method according to any one of claims 12 to 20, wherein the UE has a plurality of LTM candidate cells configured, and when the UE receives the trigger and transmits a UL signal to an LTM candidate cell that is not in the first subset of the plurality of LTM candidate cells, the UE transmits the UL signal to the LTM candidate cell that is not in the first subset in a configured UL channel resource in time and frequency after the next synchronization signal of the LTM candidate cell.

22. Prior to receiving the trigger, the UE performs a downlink (DL) synchronization with at least one of the LTM candidate cells, and the DL synchronization is i) Detecting and / or measuring at least one synchronization signal of the LTM candidate cell, wherein the at least one synchronization signal includes the SSB of the LTM candidate cell, and / or CSI-RS and / or TRS and / or PSS and / or SSS, which are associated with an SSB index and / or identifier and transmitted in a spatial direction (beam). ii) Perform detailed time tracking to obtain complete timing information for the LTM candidate cells. iii) Obtaining time boundaries of a given LTM candidate cell in time units, such as time slots, OFDM symbols, subframes, and / or wireless frames, and / or iv) Synchronize the clock with the time boundaries of a given LTM candidate cell's time unit, such as a time slot, OFDM symbol, subframe, and / or wireless frame. The method according to any one of claims 12 to 21, comprising one or more of the above.

23. Obtaining user data, Forwarding the user data to the host or user equipment The method according to any one of claims 12 to 22, further comprising:

24. User equipment for uplink (UL) access on L1 / L2 trigger cell-to-cell mobility (LTM) candidate cells, A processing circuit configured to perform any of the steps described in any one of claims 1 to 11, A power supply circuit configured to supply power to the aforementioned processing circuit and User equipment equipped with these features.

25. A network node for uplink (UL) access on an L1 / L2 trigger cell-to-cell mobility (LTM) candidate cell, wherein the network node is A processing circuit configured to perform any of the steps described in any one of claims 12 to 23, A power supply circuit configured to supply power to the aforementioned processing circuit and A network node equipped with these features.

Images