Fast uplink (UL) access on LTM candidate cells
By directly sending UL signals during LTM candidate cell handover without waiting for DL synchronization, the problem of TA establishment and cell handover delay in L1/L2 inter-cell mobility is solved, achieving faster mobility handover and higher data rates.
Patent Information
- Application Number
- CN202480024224.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2023-04-04
- Filing Date
- 2024-04-04
- Publication Date
- 2025-11-04
AI Technical Summary
In L1/L2 inter-cell mobility, there is a delay in the establishment of time alignment (TA) between the UE and LTM candidate cells and in the cell handover process. Especially when multiple LTM candidate cells are configured, the UE needs to perform DL synchronization and random access procedures, which increases the mobility interruption time.
After receiving the trigger, the UE directly sends the UL signal, such as the PRACH preamble or PUCCH/PUSCH signal, to the LTM candidate cell before the next synchronization signal, without needing to perform a complete DL synchronization with the LTM candidate cell first. The UL resource timing is configured to reduce latency.
It reduces the latency of TA establishment and LTM cell handover processes, improves UE throughput and data rate, and reduces mobility interruption time and UE complexity.
Smart Images

Figure CN120898485A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present disclosure relates to wireless communication systems, and in particular, to the establishment of time alignment in wireless communication systems. BACKGROUND
[0002] Different user equipment (UE) devices in the same cell are typically located at different locations within the cell and at different distances from the base station (e.g. NR NodeB). Therefore, transmissions from different UEs can suffer from different delays before these transmissions reach the base station. To ensure that uplink (UL) transmissions from UEs reach the base station within the corresponding reception window at the base station, an uplink timing control procedure is typically used. This control procedure avoids intra-cell interference between UEs assigned to transmit in consecutive subframes and between UEs transmitting on adjacent subcarriers.
[0003] Time alignment (TA) of uplink transmissions can be achieved by applying at the UE transmitter a timing advance value with respect to the received downlink timing. Its main role is to counteract the different propagation delays between different UEs, as Figure 1 illustrated in Figure 1 and described below for LTE eNodeB:
[0004] Notably, Figure 1 Time alignment of uplink transmissions is illustrated without timing advance (a) and with timing advance (b). To achieve time alignment, i.e. to obtain UL synchronization, the base station (e.g. gNodeB, eNodeB) derives the timing advance value that the UE needs to use to bring the UL within the reception window to reach the base station and indicates it to the UE. When the UE accesses the cell, it uses a random access procedure where the base station uses the received Msg1 (PRACH preamble) to determine the initial TA that the UE uses for UL transmissions in that cell. Then, during the connection, the base station continuously monitors whether the UE needs to advance and / or delay the UL transmission to compensate for changes in the propagation delay and indicates to the UE whether it needs to change the timing advance value.
[0005] Time alignment (synchronous handover / reconfiguration) in L3 mobility
[0006] In legacy L3 mobility in 5G New Radio (NR), also known as synchronous reconfiguration of the master cell group (MCG), when the UE changes its primary cell (PCell), the UE always performs a random access with the target PCell. As part of this procedure, the UE transmits a PRACH preamble in the UL, which enables the target gNodeB to compute the timing advance value of the UE, which is provided in the random access response (RAR), so that from Msg3 onwards the UE is able to transmit UL messages on PUCCH and / or PUSCH.
[0007] PRACH transmission
[0008] In NR, multiple implementations of a cell can be implemented. For example, some cells (e.g., FR1 cells) can be implemented to provide large coverage, and some cells (e.g., FR2 cells) can be implemented to provide greater throughput within a small coverage area. The maximum distance between a base station and a UE in a cell depends on the cell coverage area. Due to the diversity of implementations, a set of same PRACH preambles can not work well in all scenarios. To address this issue, different preamble formats with different PRACH preamble lengths are introduced in NR.
[0009] A RACH transmission occasion or RACH occasion depends on the type of RACH. A RACH occasion is a region in time and frequency domain designated to be used or reserved for a UE to transmit a RACH preamble. In NR, two types of RACH are supported, i.e., contention-based RACH and contention-free RACH.
[0010] For contention-based RACH, a RACH occasion is calculated at the UE based on the configuration from the network and specific conditions observed at 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 configured with a specific preamble index and a specific RACH transmission occasion. Based on the SSB seen by the UE, the UE determines the preamble index to be transmitted and the RACH occasion to transmit the preamble. The network can determine which beam the UE has selected because the network can configure the mapping between SSBs and RACH occasions (ROs). By detecting to which RO the UE transmits the PRACH, the network can determine which SSB beam the UE has selected.
[0012] The mapping between SSBs and RACH occasions is defined by the following two RRC parameters: i) msgl-FDM (which is configured in RACH-ConfigGeneric and can be found in TS 38.331 v17.1.0) and ii) ssb-perRACH-OccasionAndCB-PreamblesPerSSB (which is configured in RACH-ConfigCommon and can be found in 38.331 v17.1.0).
[0013] Contention-free RACH is scheduled by the network, and the scheduling information contains what to transmit and where to transmit. This information is conveyed to the UE through a combination of RRC messages and PDCCH (e.g., through a downlink control information (DCI) message) commands.
[0014] The RRC message carrying the CFRA related information is RACH-ConfigDedicated and it can be found in TS 38.331-v17.1.0.
[0015] L1 / L2 inter-cell mobility or L1 / L2 triggered inter-cell mobility (LTM) in Rel-18
[0016] In Rel-18, 3GPP has reached an agreement on a work item for further New Radio (NR) mobility enhancements, specifically in the technical area titled “L1 / L2 based inter-cell mobility”. For further details, see 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 the WID, when a UE moves from the coverage area of one cell to another, a serving cell change needs to be performed at some point in time. Currently, serving cell changes are triggered by L3 measurements and are done by synchronous reconfiguration (for PCell and PSCell switching) triggered by RRC signaling and addition of releasing SCells when applicable. All cases involve a full L2 (and L1) reset, resulting in longer latency, larger overhead and longer interruption time than beam switching mobility. The goal of L1 / L2 mobility enhancements 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 the reported quantity. This means that the UE needs to report the L1-RSRP of candidate cells to the network so that the network can use them for LTM handover (HO) decision.
[0019] In Rel-17, as part of inter-cell beam management, a solution has been standardized where L1-RSRP is measured and reported on CSI resources that are not associated with the PCI of the serving cell.
[0020] From total latency perspective, L3 HO procedure vs. LTM HO procedure (see L3 HO latency requirement TS 38.331)
[0021] 6.1.1.2.1 Handover delay
[0022] When the UE receives the RRC message implying a handover, the UE shall be ready to start transmitting the new uplink PRACH channel within D 切换 milliseconds from the end of the last TTI containing the RRC command.
[0023] where:
[0024] D 切换 is equal to the applicable RRC procedure delay defined in clause 12 of TS 38.331 [2] plus the interruption time specified in clause 6.1.1.2.2
[0025] 6.1.1.2.2 Interruption time
[0026] The interruption time is the time between the end of the last TTI containing the RRC command on the old PDSCH and the time the UE starts transmitting the new PRACH, excluding the RRC procedure delay.
[0027] When the command is for an intra- or inter-frequency handover, the interruption time shall be less than T 中断
[0028]
[0029] where:
[0030] T 搜索 is the time needed to search for the target cell when it is not already known by the UE at the time the handover command is received. If the target cell is known, T 搜索 = 0 ms. If the target cell is an unknown intra-frequency cell and the target cell Es / Iot ≥ -2 dB, T 搜索 = T rs ms. If the target cell is an unknown inter-frequency cell and the target cell Es / Iot ≥ -2 dB, T 搜索 = 3 * T rs ms. T 搜索 shall still be based on the non-DRX target cell search time, regardless of whether the UE is using DRX or not.
[0031] is the time for fine time tracking and acquiring full timing information of the target cell. For known target cells and unknown target cells, .
[0032] T 处理 is the time for UE processing. T 处理 may be up to 20 ms.
[0033] T 裕度 is the time for SSB post-processing. T 裕度 may be up to 2 ms.
[0034] T IU is the interruption uncertainty when acquiring the first available PRACH occasion in the new cell. T IUThe SSB to PRACH association period can be up to the sum of 10 ms. The SSB to PRACH association period is defined in Table 8.1-1 of TS 38.213 [3].
[0035] If the UE has been provided with SMTC configuration of the target cell in the handover command, T rs is the SMTC period of the target NR cell, otherwise T rs is the SMTC configured in measObjectNR with the same SSB frequency and subcarrier spacing. If the measObjectNR with the same SSB frequency and subcarrier spacing configured by the MN and SN have different SMTC, T rs is the period of one of the SMTCs, which depends on the UE implementation. If the UE has not been provided with SMTC configuration or measurement object at this frequency, the requirement in this clause applies to T rs = 5 ms, assuming the SSB transmission period is 5 ms. If the SSB transmission period is not 5 ms, there is no requirement. If the UE has been provided with high layer signaling smtc2 in TS 38.331 [2] prior to the handover command, T rs follows smtc1 or smtc2 according to the physical cell ID of the target cell.
[0036] In the interruption requirement, a cell is known if it has fulfilled the relevant cell identification requirement during the past 5 seconds, otherwise the cell is unknown. For intra-frequency handover, the relevant cell identification requirement is described in clause 9.2.5, and for inter-frequency handover, the relevant cell identification requirement is described in clause 9.3.4
[0037] According to the requirement shown above, the L3 HO delay (D 切换 ) is equal to the RRC processing delay of the HO command and the interruption time. Wherein, the interruption delay includes the following components: SW and HW processing; cell search; fine timing acquisition; and the delay uncertainty of obtaining PRACH preamble.
[0038] According to the preliminary discussion of Rel-18 LTM, two possible methods and two possible timelines are discussed. Figure 2 and Figure 3 These methods and timelines are shown in FIGS. 1 and 2. Notably, Figure 2 FIG. 1 shows the baseline timeline of L1 / L2 inter-cell mobility agreed by RAN2, and Figure 3 depicts an example LTM configuration and an example of LTM cell handover procedure in which the UE accesses the LTM candidate cell in a random access procedure at the LTM cell handover.
[0039] In LTM, it has been agreed that the LTM cell change procedure, where the UE receives an LTM cell change command (e.g., a MAC CE including an indication of one of the configured LTM candidate cells) and accesses the indicated LTM candidate cell. In one option, 3GPP assumes that the UE accesses the LTM candidate cell in response to an LTM cell change command relying on a random access procedure, i.e., when the UE receives an LTM cell change command from the serving cell (e.g., PCell), the UE sends a PRACH preamble to the LTM candidate cell and receives a random access response. One of the steps the UE needs to perform when it receives an LTM cell change command is DL synchronization (which increases the delay to access the LTM candidate cell), where the UE needs to perform fine time tracking and acquire the full timing information of the LTM candidate cell (which is the target cell).
[0040] Reference Figure 3 To further reduce the interruption time, it has also been agreed that the UE can be configured to establish time alignment with one or more LTM candidate cells prior to triggering the LTM cell change, so that at the time of the LTM cell change, the UE will not need to trigger a random access procedure and instead the first action of the first UE at the LTM candidate cell that becomes the target cell (i.e., the new PCell) is to monitor the PDCCH and / or send UL signals on PUCCH and / or PUSCH, which requires establishing UL synchronization.
[0041] Different options for this time alignment (TA) procedure (for UL synchronization establishment) are still under discussion in 3GPP, but they all rely on the UE receiving a trigger (e.g., a PDCCH order) from the PCell while still connected to the PCell to send UL signals (e.g., PRACH preambles) to the LTM candidate cell, so that the candidate DU at the network side (responsible for the LTM candidate cell) that receives the preamble calculates a timing advance value to be provided to the UE at some point in time (e.g., at the LTM cell change command, or in a DL response) (e.g., via the PCell or via the LTM candidate cell). This timing advance value is a value for the UE and the LTM candidate cell where the UE sent the PRACH preamble. The TA establishment procedure can be triggered for one or more LTM candidate cells. For example, Figure 4 At least one example of this procedure is shown. In particular, Figure 4 An example of the TA establishment procedure is depicted, where the UE establishes TA by sending a PRACH preamble and receives the timing advance value in the LTM cell change command.
[0042] There are currently certain challenge(s). One challenge for the time alignment (TA) setup procedure is that before the UE sends a PRACH preamble to an LTM candidate cell, the UE needs to first perform DL synchronization, e.g., by detecting and receiving one or more SSBs of the LTM candidate cell, so that the UE can determine a PRACH occasion and send a PRACH preamble when it receives a TA setup trigger (e.g., a PDCCH order).
[0043] This can be avoided if the TA setup procedure is triggered quite early, much earlier than the timing of triggering the LTM cell switch. However, a typical network implementation would only trigger the TA setup procedure when it is certain to some extent that a certain LTM candidate is a high likelihood candidate cell, which the network (e.g., S-DU) can know by receiving further L1 and / or L3 measurements on the LTM candidate cell. However, doing so would in principle require the TA setup procedure to be as fast as possible so that the timing between the TA setup and the LTM cell switch is not too close. Another potential issue with the longer delay to send a PRACH preamble for TA setup is that the UE can not always be able to attempt to synchronize with the SSB of the LTM candidate and at the same time receive / transmit data from the serving cell, which can impact the throughput / data rate.
[0044] Since the PRACH occasions and SSBs can be sparse (e.g., 10 ms), the procedure can not be that fast and the longer it takes, the closer the UE gets to the timing of performing the LTM cell switch, which can also increase the likelihood of a failed procedure, e.g., the radio conditions of the serving cell become worse and / or the radio conditions on the LTM candidate become better during the TA setup. Figure 5 An example is shown that illustrates typical UE actions in this type of scenario. It is worth noting that, Figure 5 The delay to setup TA for the LTM candidate cell is shown.
[0045] Another potential issue in LTM, especially when TA setup involving one or more LTM candidate cells, is that the UE can be configured with multiple LTM candidate cells as potential target cells. Based on the measurement report from the UE, the network can configure the UE to switch to one of the candidate cells. Although the UE can measure multiple cells, the UE can not be able to maintain DL synchronization with all the candidate cells as this can lead to higher UE complexity and cost.
[0046] Another challenge is the LTM cell switch procedure, which can also rely on a random access procedure, as Figure 6The UE needs to first perform DL synchronization with one or more SSBs of the LTM candidate cell before it sends the PRACH preamble to the LTM candidate cell in response to the LTM cell switch command (e.g., a MAC CE indicating at least the LTM candidate cell). This can take some time depending on various factors, e.g., SSB periodicity (making it take longer to receive the next possible SSB) or frequency range (e.g., FR2, mmWave frequencies) where the UE will need to receive more SSBs in a burst to perform beam sweeping, which also takes longer. In other words, the DL synchronization when doing an LTM cell switch adds to the LTM cell switch delay, increasing the mobility interruption time, which is being optimized throughout the study item in Rel-18. The PRACH occasions and SSBs can be sparse (e.g., 10 ms) and / or the procedure can be too slow.
[0047] Figure 7 A signaling diagram illustrating problems to be solved for LTM cell switch without random access is shown.
[0048] Another potential problem with LTM cell switch is that the UE can be configured with multiple LTM candidate cells as potential target cells. Based on the measurement report from the UE, the network can configure the UE to switch to one of the candidate cells or perform TA establishment. Although the UE can measure multiple cells, the UE can not be able to maintain DL synchronization with all candidate cells as this can lead to higher UE complexity and cost. SUMMARY
[0049] Certain aspects of the present disclosure and their embodiments can provide solutions to these challenges or other challenges. The disclosed subject matter describes how a UE can reduce the delay in the time alignment (TA) establishment / update procedure and / or the LTM cell switch procedure with an LTM candidate cell.
[0050] Some embodiments provide a method for uplink access on a L1 / L2 triggered mobility (LTM) candidate cell performed by a user equipment. The method includes receiving, from a network node, an LTM configuration of at least one LTM candidate cell, receiving, from the network node, a trigger, and receiving a first synchronization signal from the LTM candidate cell. The method further includes, in response to receiving the trigger, transmitting a UL signal to the LTM candidate cell during a UL resource occasion, wherein the UL resource occasion occurs 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 receiving the trigger.
[0051] Some embodiments provide a method, performed by a network node, for L1 / L2 triggered cross cell mobility (LTM) candidate cell on user equipment (UE) access. The method comprises transmitting, from the network node to the UE, an LTM configuration of at least one LTM candidate cell and transmitting, from the network node to the UE, a trigger.
[0052] Some embodiments provide a user equipment for L1 / L2 triggered cross cell mobility (LTM) candidate cell on uplink (UL) access, the user equipment comprising: processing circuitry configured to perform any of the steps of any method performed by the UE; and power supply circuitry configured to supply power to the processing circuitry.
[0053] Some embodiments provide a network node for L1 / L2 triggered cross cell mobility (LTM) candidate cell on uplink (UL) access, the network node comprising: processing circuitry configured to perform any of the steps of any method performed by the network node; and power supply circuitry configured to supply power to the processing circuitry.
[0054] One reason for transmitting the UL signal between receiving the trigger and the first synchronization signal (e.g., SSB) of the LTM candidate cell occurring after the trigger (i.e., before the next synchronization signal (e.g., before the next SSB)) is that it would be unnecessary in the case where the UE is in DL synchronization with the LTM candidate cell so that the UE can transmit in the next available PRACH occasion or assigned / configured PUCCH / PUSCH resource of the LTM candidate cell after the UE receives the trigger from the serving cell. Another possibility is to transmit the UL signal to the LTM candidate cell after receiving the trigger and before the next SSB occurring after receiving the trigger. One benefit is that the UE does not need to receive the SSB of the LTM candidate cell before transmitting the UL signal to the LTM candidate cell.
[0055] According to some embodiments, the trigger can correspond to one or more of:
[0056] a trigger for a TA establishment / update procedure, wherein the trigger is received from the serving cell (e.g., PDCCH order from the primary cell or primary SCG cell) for transmitting an UL signal (e.g., PRACH preamble) for TA establishment / update;
[0057] a trigger for a LTM cell switch procedure, wherein the trigger corresponds to a LTM cell switch command (indicating a LTM candidate cell, e.g., LTM configuration ID) from the serving cell (e.g., MAC CE from the primary cell or primary SCG cell) for accessing the LTM candidate.
[0058] According to some embodiments, the UL signal can correspond to one or more of the following:
[0059] a PRACH preamble sent to a PRACH occasion of an LTM candidate cell in a TA establishment / update procedure;
[0060] a PRACH preamble sent to a PRACH occasion of an LTM candidate cell in a TA establishment / update procedure;
[0061] a sounding reference signal (SRS) sent to an LTM candidate cell in a TA establishment / update procedure;
[0062] control information (e.g., scheduling request) sent on a physical uplink control channel (PUCCH) of an LTM candidate cell in an LTM cell handover procedure; and / or
[0063] UL data (e.g., including RRC reconfiguration complete as payload) sent on a physical uplink shared channel (PUSCH) of an LTM candidate cell in an LTM cell handover procedure.
[0064] According to some embodiments, the UL resource occasion can correspond to one or more of the following:
[0065] a PRACH occasion of an LTM candidate cell;
[0066] a sounding reference signal resource or resource occasion of an LTM candidate cell that has been configured (e.g., in RRC configuration of the LTM candidate cell) and / or assigned (e.g., in an LTM cell handover command);
[0067] a physical uplink control channel (PUCCH) resource or resource occasion of an LTM candidate cell that has been configured (e.g., in RRC configuration of the LTM candidate cell) and / or assigned (e.g., in an LTM cell handover command); and / or
[0068] a physical uplink shared channel (PUSCH) resource or resource occasion of an LTM candidate cell that has been configured (e.g., in RRC configuration of the LTM candidate cell) and / or assigned (e.g., in an LTM cell handover command).
[0069] Figure 8 Some embodiments are shown in which the UE performs a TA establishment / update procedure. Similarly, Figure 9 Examples are depicted when the disclosed subject matter is used for a LTM cell handover procedure that relies on PUCCH and / or PUSCH transmissions on the LTM cell handover. Figure 10 Examples are shown when the disclosed subject matter is used for a LTM cell handover procedure that does not rely on PUCCH and / or PUSCH transmissions on the LTM cell handover.
[0070] According to some embodiments, the UE is configured with multiple LTM candidate cells (i.e., more than one candidate cell) and selects a subset of the LTM candidate cells / at least one LTM candidate cell for transmitting a UL signal to a UL resource occasion (e.g., PRACH occasion) of the LTM candidate cell, where the UL resource occasion that the UE transmits the UL signal occurs between receiving the trigger and a first synchronization signal (e.g., SSB) of the LTM candidate cell after the trigger, where the selection of the subset of the LTM candidate cells is based on one or more rules (or a combination of these rules). In other words, the UE can not know all configured cells perform the actions in this method, so the UE needs to select a subset of cells where the UE performs the actions. Multiple rules that can be combined are presented below for selecting the subset of LTM candidate cells.
[0071] Figure 11 Examples are depicted for the case of TA establishment / update procedure according to some embodiments, based on selecting a subset of LTM candidate cells for performing UL signal transmission (e.g., PRACH preamble).
[0072] Certain embodiments can provide one or more of the following technical advantages. By utilizing the disclosed subject matter, the delay in transmitting a UL signal to a LTM candidate cell in a TA establishment / update procedure for the LTM candidate cell is reduced, preparing for LTM cell handover without a random access procedure.
[0073] When applied to LTM cell handover, the delay in transmitting a UL signal to a LTM candidate cell in a LTM cell handover to the LTM candidate cell is reduced, whether or not a random access procedure is used, due to utilizing the disclosed subject matter.
[0074] The UE can transmit a UL signal (e.g., PRACH preamble) to a LTM candidate cell by transmitting within a PRACH occasion (or PUCCH and / or PUSCH) that occurs before the next synchronization signal (e.g., SSB) after the UE receives a trigger (indicated by the trigger for TA establishment, e.g., PDCCH order, RRC message or MAC from the PCell, or in response to a LTM cell handover). In other words, the UE does not need to first receive a SSB (or any other synchronization signal) of the LTM candidate cell to transmit in the UL. This reduces the time spent on performing UL synchronization to the LTM candidate cell during TA establishment, which can reduce the time the UE needs to be away from the serving cell and thus can improve throughput / data rate.
[0075] This can improve the reliability of the overall UE connection, as the shorter time to perform the TA establishment / update means that the UE returns to the PCell faster after the PRACH preamble transmission, which means that the UE can be ready to receive the LTM cell switch command from the PCell faster.
[0076] Note: The UE is free to implement the standardized functionality in different ways in detail. As one of the examples, for LTM cell switch and TA establishment, when the UE is configured with multiple available UL resources (e.g., multiple PRACH occasions and / or PUCCH and / or PUSCH resources), it is up to the UE implementation to decide the internal actions needed to access the LTM target cell (or to send to it in case of TA establishment) after the network sends the trigger, e.g., how much time the UE needs to complete such actions (unknown to the network) and the reason the network configured multiple available resources is to let the implementation decide how much time can be needed.
[0077] An alternative would be for the network to configure a single resource that occurs much later to ensure there is enough time, but this would also significantly increase the interruption time. Note that the UE can already have its alternative and will not be forced to access the first resource before the next SSB. BRIEF DESCRIPTION OF DRAWINGS
[0078] Figure 1 Time alignment of uplink transmissions is shown without timing advance (a) and with timing advance (b).
[0079] Figure 2 A timeline for L1 / L2 inter-cell mobility is shown.
[0080] Figure 3 An example of a procedure for establishing time alignment (TA) is shown.
[0081] Figure 4 An example of a procedure for establishing time alignment (TA) is shown according to some embodiments.
[0082] Figure 5 A delay for TA establishment with a LTM candidate cell is shown.
[0083] Figure 6 A LTM cell switch procedure based on a random access procedure is shown.
[0084] Figure 7 A LTM cell switch procedure not based on a random access procedure is shown.
[0085] Figure 8 TA establishment with a LTM candidate cell is shown according to some embodiments.
[0086] Figure 9 TA establishment with LTM candidate cells is shown that relies on random access.
[0087] Figure 10 TA establishment with LTM candidate cells is shown that does not rely on PUCCH and / or PUSCH transmissions, according to some embodiments.
[0088] Figure 11 An example of selecting a subset of LTM candidate cells for performing UL signal transmissions is illustrated, according to some embodiments.
[0089] Figure 12 A signaling diagram of TA establishment with LTM candidate cells is shown, according to some embodiments.
[0090] Figure 13 A signaling diagram of LTM cell switching is shown.
[0091] Figure 14 HARQ feedback transmission triggered by PDCCH monitoring in LTM candidate cells is shown.
[0092] Figure 15 A method for performing TA with LTM candidate cells performed by a UE in a wireless communication network is shown, according to some embodiments.
[0093] Figure 16 A method for L1 / L2 based inter-cell mobility of a UE to a candidate cell performed by a network node in a wireless communication network is shown, according to some embodiments.
[0094] Figure 17 An example of a communication system is shown, according to some embodiments.
[0095] Figure 18 An example of a UE is shown, according to some embodiments.
[0096] Figure 19 An example of a network node is shown, according to some embodiments.
[0097] Figure 20 is a block diagram of a host computer.
[0098] Figure 21 is a block diagram illustrating a virtualization environment.
[0099] Figure 22 is a communication diagram of a host computer. DETAILED DESCRIPTION
[0100] Some embodiments as contemplated herein will now be described in greater detail below with reference to the drawings. The embodiments are provided merely as examples to convey the scope of the subject matter to those skilled in the art.
[0101] Scenarios and terminology of embodiments
[0102] Reference is made herein to the term "L1 / L2 based inter-cell mobility" used in the work item description in 3GPP, although the terms L1 / L2 mobility, L1 mobility, L1 based mobility, L1 / L2 centric inter-cell mobility, L1 / L2 inter-cell mobility, or L1 / L2 triggered mobility (LTM) are also used interchangeably.
[0103] The basic principle of LTM is that a UE is first configured with one or more LTM candidate cells (via RRC), and then, e.g., after the UE reports L1 measurement values on one or more LTM candidate cells, the UE receives a low layer signaling from the network which indicates to the UE a change (or handover or activation) of its serving cell (e.g., changing the PCell from a source PCell to a target PCell), where the low layer signaling is a message / signaling of a low layer protocol which can be referred to as an L1 / L2 inter-cell mobility execution command (or LTM cell handover command). The change of the serving cell (e.g., change of the PCell) can also result in a change of SCells of the same cell group, e.g., in case the command triggers the UE to change to another cell group configuration of the same type (e.g., another MCG configuration). The network configures the UE with one or more LTM candidate cells (e.g., receives an RRC reconfiguration message with at least one candidate cell configuration) before the UE receives the LTM cell handover command. The candidate cell configuration can include parameters in the IE CellGroupConfig of each candidate cell and / or an embedded RRC reconfiguration of each candidate cell.
[0104] A lower layer protocol refers to a lower layer protocol in the air interface protocol stack compared to the RRC protocol, e.g., medium access control (MAC) is considered a lower layer protocol as it is located “below” the RRC in the air interface protocol stack, and in this case, the lower layer signaling / message can correspond to a MAC control element (MAC CE). Another example of a lower layer protocol is layer 1 (or physical layer, L1), and in this case, the lower layer signaling / message can correspond to downlink control information (DCI). Signaling information in a protocol layer lower than RRC can reduce the processing time, thus reducing the interruption time during mobility. In addition, it can also improve mobility robustness as the network can respond to faster channel condition changes. Another related aspect of L1 / L2 inter-cell mobility is that in a multi-beam scenario, a cell can be associated to multiple SSBs, and during a half frame, different SSBs can be transmitted in different spatial directions (i.e., using different beams, across the coverage area of the cell). Similar principles can also apply to CSI-RS resources, which can also be transmitted in different spatial directions. Thus, in L1 / L2 inter-cell mobility (LTM), a low layer signaling is received indicating the UE to change from one beam in a serving cell to another beam in a neighboring cell (which is a configured candidate cell), and thus change the serving cell.
[0105] The term LTM cell change procedure (or simply “cell change”) refers to a procedure in which a UE changes its cell from a source cell to a target cell (which can be referred to here as a candidate cell) using L1 / L2 triggered mobility (also referred to here as LTM). In the context of L1 / L2 based inter-cell mobility or L1 / L2 triggered mobility (LTM), the LTM cell change procedure is sometimes also referred to as dynamic change, LTM change, LTM cell change, LTM serving cell change, or LTM cell change. Even though the term change of cell is used, it can include a change of an entire cell group configuration, which includes a change of a SpCell (e.g., a change of a PCell, or a change of a PSCell) and a change of SCells of a cell group (e.g., addition, modification, and / or release of one or more SCells).
[0106] The term“LTM candidate cell” referred to herein refers to a cell that the UE is configured with when configured with L1 / L2 inter-cell mobility. This is a cell that the UE can move to in the L1 / L2 inter-cell mobility procedure when receiving low layer signaling. These cells can also be referred to as candidate cells, candidates, moving candidates, non-serving cells, additional cells, etc. This is a cell that the UE performs measurements (e.g., L1-RSRP measurements or CSI measurements) on as disclosed in the disclosed subject matter, such that the UE reports these measurements and the network can make an informed decision on which beam (e.g., TCI state) and / or cell the UE is to be handed over to. The L1 / L2 inter-cell mobility candidate cell can be a candidate to become a target PCell, PSCell, or SCell (e.g., MCG SCell) of a cell group. In this sense, when referring to resource configuration herein to indicate SS and / or RS for the UE to measure CSI for reporting, it can refer to SS and / or RS of a candidate SCell of the MCG, a candidate SCell of the SCG, a candidate PSCell, and / or a candidate PCell.
[0107] According to the method related to LTM, the UE is able to acquire downlink (DL) and / or uplink (UL) synchronization prior to receiving an LTM cell switch 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 prior to receiving an LTM cell switch command, there can be a limit to the number of cells that the UE can obtain such synchronization prior to receiving the LTM cell switch command. Additionally, to acquire UL synchronization, the UE can need to send UL signals such as PRACH preambles or sounding reference signals (SRS) to the LMT candidate cell (e.g., target gNB and / or candidate DU). Unless the UE has acquired DL synchronization, the UE does not send PRACH or SRS to acquire UL synchronization. Each PRACH preamble can be associated with an SSB and a RACH occasion (RO) in which the preamble can be sent. The RO can be a periodically repeating occasion. For example, if a first RO associated with a PRACH preamble is 10 ms, then a second RO associated with the same preamble can be 10 ms + (160 ms), and a third RO associated with the same preamble can be 10 ms + (2*160 ms), and a fourth RO is 10 ms + (3*160 ms), and so on.
[0108] In one set of embodiments, the disclosed subject matter includes method steps of: a UE receiving a configuration of one or more LTM candidate cells; receiving a trigger; and in response to the trigger, transmitting a UL signal to a UL resource occasion (e.g., a PRACH occasion) of the LTM candidate cell, wherein the UL resource occasion that the UE transmits the UL signal occurs between receiving the trigger and a first synchronization signal (e.g., SSB) of the LTM candidate cell after the trigger.
[0109] The reason for transmitting the UL signal between receiving 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 would be unnecessary in the case that the UE is in DL synchronization with the LTM candidate cell such that the UE can transmit in the next available PRACH occasion or assigned / configured PUCCH / PUSCH resource of the LTM candidate cell after the UE receives the trigger from the serving cell.
[0110] According to the method, the trigger can correspond to one or more of:
[0111] a trigger for a TA establishment / update procedure, wherein the trigger is received from the serving cell (e.g., a PDCCH order from a primary cell or a primary SCG cell) for transmitting a UL signal (e.g., a PRACH preamble) for TA establishment / update;
[0112] a trigger for an LTM cell switch procedure, wherein the trigger corresponds to an LTM cell switch command (indicating an LTM candidate cell, e.g., an LTM configuration ID) from the serving cell (e.g., a MAC CE from a primary cell or a primary SCG cell) for accessing the LTM candidate.
[0113] According to the method, the UL signal can correspond to one or more of:
[0114] a PRACH preamble transmitted to a PRACH occasion of the LTM candidate cell in the LTM cell switch;
[0115] a PRACH preamble transmitted to a PRACH occasion of the LTM candidate cell in the TA establishment / update procedure;
[0116] a sounding reference signal (SRS) of a PUCCH or PUSCH transmitted to the LTM candidate cell in the TA establishment / update procedure;
[0117] control information (e.g., a scheduling request) transmitted on a physical uplink control channel (PUCCH) of the LTM candidate cell in the LTM cell switch procedure; and / or
[0118] UL data (e.g., including RRC reconfiguration complete as payload) sent on a physical uplink shared channel (PUSCH) of the LTM candidate cell in the LTM cell handover procedure.
[0119] According to this method, the UL resource occasion can correspond to one or more of the following:
[0120] a PRACH occasion of the LTM candidate cell;
[0121] a physical uplink control channel (PUCCH) resource or resource occasion of the LTM candidate cell that has been configured (e.g., in RRC configuration of the LTM candidate cell) and / or assigned (e.g., in LTM cell handover command);
[0122] a physical uplink shared channel (PUSCH) resource or resource occasion of the LTM candidate cell that has been configured (e.g., in RRC configuration of the LTM candidate cell) and / or assigned (e.g., in LTM cell handover command).
[0123] According to this method, the UE is configured with multiple LTM candidate cells (i.e., more than one candidate cell) and selects a subset of LTM candidate cells / at least one LTM candidate cell for sending UL signals to the UL resource occasion (e.g., PRACH occasion) of the LTM candidate cell, where the UL resource occasion that the UE sends UL signals occurs between receiving the trigger and the first synchronization signal (e.g., SSB) of the LTM candidate cell after the trigger, where the selection of the subset of LTM candidate cells is based on one or more rules (or a combination of these rules). In other words, the UE can not know all the configured cells perform the actions in this method, so the UE needs to select a subset of cells where the UE performs these actions. Multiple rules that can be combined are proposed below for selecting the subset of LTM candidate cells.
[0124] According to this method, the UE sending UL signals in the configured UL channel resource to the LTM candidate cell in time and frequency (e.g., PRACH occasion that occurs between receiving the trigger and the next synchronization signal (e.g., SSB) occurs in the LTM candidate cell) is based on DL synchronization performed on the LTM candidate cell before receiving the trigger.
[0125] The UE performs DL synchronization (also referred to as DL pre-synchronization, pre-synchronization, pre-sync) with the LTM candidate cell comprises the UE detecting and / or measuring at least one synchronization signal of the LTM candidate cell, e.g., a synchronization signal block (SSB), e.g., an SSB of the LTM candidate cell associated with an SSB index and / or identifier and transmitted on a spatial direction (beam), and / or a channel state information-reference signal (CSI-RS) and / or a tracking reference signal (TRS) and / or a primary synchronization signal (PSS) and / or a secondary synchronization signal (SSS); in this context, measuring comprises determining a measurement quantity, e.g., a synchronization signal based reference signal received power (SS-RSRP) and / or a synchronization signal based reference signal received quality (SS-RSRQ) and / or a synchronization signal based signal to noise and interference ratio (SS-SINR).
[0126] The UE performs DL synchronization with the LTM candidate cell comprises the UE performing fine time tracking and acquiring full timing information of the LTM candidate cell. Timing acquisition comprises obtaining the time boundaries of a time unit of a given LTM candidate cell, e.g., a slot, an OFDM symbol, a subframe, a radio frame. Time acquisition comprises synchronizing a clock to the boundaries of a time unit of a given LTM candidate cell, e.g., a slot, an OFDM symbol, a subframe, a radio frame. The acquired fine timing is used as a reference point for PRACH transmission and UE uplink transmission.
[0127] According to this method, the UE is configured with multiple LTM candidate cells (i.e., more than one candidate cell) and selects a subset of LTM candidate cells / at least one LTM candidate cell for performing DL synchronization before triggering the TA establishment procedure, wherein the selection of the subset of LTM candidate cells is based on one or more rules (or a combination of these rules).
[0128] According to this method, the UE transmits the UL signal to the LTM candidate cell in the 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 the UL signal in the first configured UL channel resources in time and frequency (e.g., the first PRACH occasion) after receiving the trigger.
[0129] The reason for transmitting the UL signal in the first PRACH occasion configured for TA establishment before the next synchronization signal is that it would be unnecessary in case the UE is already in DL synchronization with the LTM candidate cell so that the UE can transmit in the next available PRACH occasion of the LTM candidate cell after the UE receives the trigger for TA establishment from the serving cell (e.g., a PDCCH order from the PCell).
[0130] According to this method, before receiving from the serving cell an LTM cell switch command indicating an LTM candidate cell, the UE receives from the serving cell a configuration with one or more LTM candidate cell configurations to apply at the time of receiving the LTM cell switch command. This is equivalent to the UE being configured with LTM by the network.
[0131] According to this method, before receiving from the serving cell an LTM cell switch command indicating an LTM candidate cell, the UE receives a configuration for TA establishment / update with the LTM candidate cell, which includes one or more UL related parameters: e.g. PRACH preamble configuration, PRACH occasions, PRACH frequency resources, etc. In one option, the configuration for TA establishment / update is included in the same RRC message (e.g. RRC reconfiguration) that configures the UE with LTM. In another option, the configuration for TA establishment / update is included in a second RRC message when the UE receives a first RRC message (e.g. second RRC reconfiguration) that configures the UE with LTM.
[0132] According to this method, the UE is configured with multiple LTM candidate cells, and when the UE receives a trigger to send an uplink signal to an LTM candidate cell in a first subset of the multiple LTM candidate cells, the UE sends the UL signal to the LTM candidate cell in the first subset of the multiple LTM candidate cells in a time and frequency before a next synchronization signal (e.g. SSB) of the LTM candidate cell in configured UL channel resources.
[0133] According to this method, the UE is configured with multiple LTM candidate cells, and when the UE receives a trigger from the serving cell (e.g. PDCCH order from a primary cell or a primary SCG cell) to send an UL signal (e.g. PRACH preamble) for establishing / updating TA to an LTM candidate cell not belonging to a first subset of the multiple LTM candidate cells, the UE sends the UL signal to the LTM candidate cell not belonging to the first subset of the multiple LTM candidate cells in a time and frequency after a next synchronization signal (e.g. SSB) of the LTM candidate cell in configured UL channel resources.
[0134] According to this method, the UE is configured with multiple LTM candidate cells (i.e. more than one candidate cell), and according to this method a subset of the LTM candidate cells / at least one LTM candidate cell is selected for sending UL (e.g. within the UL resource occasion between receiving the trigger and the occurrence of the SSB), where the selection of the subset of the LTM candidate cells is based on one or more rules (or a combination of these rules), as follows:
[0135] 1) The UE selects all LTM candidate cells configured for the UE.
[0136] In one option as one of the examples, the UE reports a capability indicating that the UE is capable of DL synchronization with "K" LTM candidate cells, and the UE receives a message (e.g., RRC reconfiguration) including an LTM configuration of "K*" LTM candidate cells, where K* < K, so the UE performs UL transmission for all LTM candidates (or any LTM candidate as a single LTM candidate can be indicated in LTM cell switch) between receiving the trigger and the next SSB occurrence (e.g., in TA establishment or LTM cell switch).
[0137] Note: there can be a first capability related to TA establishment procedure and a second capability related to LTM cell switch procedure.
[0138] The above capability can be reported when the UE transitions from IDLE to CONNECTED state.
[0139] Testability / measurability of the UE implementation of the steps: as one of the examples, in the test, we can configure multiple LTM candidate cells (e.g., 2 cells) and according to the reported UE capability, we know that the UE is capable of handling these cells. Then, we test that when the network sends a trigger for all or any of these configured LTM candidate cells, the UE indeed sends UL signals (e.g., PRACH preamble) in the UL channel occasion (e.g., PRACH occasion) before the next SSB after receiving the trigger. For this, we also need to configure the LTM candidate cells to send PRACH occasions between receiving the trigger and the next SSB.
[0140] Test scenario as one of the examples. The serving cell SC1 and the neighbor cell NC2 are configured as LTM candidate cells, where the SSBs are configured with known time instances.
[0141] Different timings are configured for the SSBs;
[0142] - a set of time offsets can be added as non-synchronized units from the signal generator in order to move the SSBs of the NCell in known times.
[0143] - alternative is to configure the SSBs in different time occasions for the NCell in a series of tests
[0144] Configure in the test to send LTM cell switch command from SCell 1 at the same time;
[0145] Configure to allow PRACH occasions for NCell 2;
[0146] Check that the time instances of UL PRACH sent to the NCell follow the timing offsets or different SSB occasions.
[0147] 2) The UE selects the strongest LTM candidate cell from the 'N' configured LTM candidate cells based on a measurement quantity, which can correspond to RSRP, RSRQ, SINR, etc.
[0148] In one option as one of the examples, the measurement quantity is RSRP, RSRQ or SINR.
[0149] In one option as one of the examples, the strongest LTM candidate cell is selected based on the cell quality of the LTM candidate cell, e.g., the UE selects the LTM candidate cell whose cell RSRP value is the strongest.
[0150] In one option as one of the examples, the strongest LTM candidate cell is selected based on the beam / SSB / CSI-RS quality of the LTM candidate cell, e.g., the UE selects the LTM candidate cell whose strongest beam level RSRP value (SS-RSRP value) is the strongest.
[0151] Testability / measurability of the UE implementation of the steps: In the test, we can configure the UE to report the measurement quantity of the LTM candidate cell, hence we can observe the value of this measurement quantity (e.g., SS-RSRP of the configured LTM candidate cell, so that we can see when this does not change; based on this observation, we can send a trigger to the UE (e.g., for the TA establishment procedure or LTM cell handover), and see if the UE is selecting the cell whose reported value satisfies rule number 2).
[0152] Test scenario as one of the examples. The serving cell SC1, the neighbor cell NC2 as the first configured LTM candidate cell with a first SSB configured by a known first time instance, and the second neighbor cell NC3 as the second configured LTM candidate cell with a second SSB configured by a known second time instance. NC2 is configured with a first power level 1 corresponding to RSRP 1, and NC3 is configured with a second power level 2 corresponding to RSRP 2.
[0153] - In the test, configure to send the LTM cell handover command from SCell 1 at the same time;
[0154] - Configure to allow PRACH occasions for NC2 and NC3;
[0155] - Check if the time instance of the UL PRACH sent to NC2 or NC3 is the one with the strongest RSRP and if the UL PRACH is sent within the time instance between the handover command and the known SSB time instance from NC2 or NC3.
[0156] 3) UE selects "K" strongest LTM candidate cells from "N" configured LTM candidate cells based on measurement quantity, which can correspond to RSRP, RSRQ, SINR, etc.
[0157] In one example, the UE reports the capability indicating that the UE is capable of DL synchronization (or DL pre-synchronization) with "K" LTM candidate cells, and the UE receives a message (e.g., RRC reconfiguration) including LTM configuration of "N" LTM candidate cells, where N > K, so that the UE upon receiving the LTM candidate cell configuration and after receiving a trigger (e.g., for TA establishment procedure or LTM cell switch), transmits UL signal to any of the K strongest LTM candidate cells within the UL resource occasion between receiving the trigger and the next SSB occurrence to obtain measurement quantity.
[0158] In one option as one of the examples, the measurement quantity is RSRP, RSRQ, or SINR.
[0159] In one option as one of the examples, the K strongest LTM candidate cells are selected based on cell quality of LTM candidate cells, e.g., the UE selects the LTM candidate cell whose cell RSRP value is strongest.
[0160] In one option as one of the examples, the K strongest LTM candidate cells are selected based on beam / SSB / CSI-RS quality of LTM candidate cells, e.g., the UE selects the LTM candidate cell whose strongest beam level RSRP value (SS-RSRP value) is strongest.
[0161] Testability / Measurability of UE implementation of steps: In case of TA establishment, the UE can be triggered to perform the procedure with multiple candidate cells, so that in testing we can trigger TA establishment with N candidate cells and possibly observe that UL transmission in K candidate cells satisfies the condition in the rule. To verify that K cells are strongest, we can configure the UE to periodically send L1 and / or L3 measurement report of N LTM candidate cells. In testing, we can configure the UE to report measurement quantity of LTM candidate cells, so that we can observe the value of the measurement quantity, e.g., SS-RSRP of configured LTM candidate cells, so that we can see when this does not change; based on this observation, we can trigger the TA establishment procedure and see if the UE is selecting the cell whose reported value satisfies rule number 3.
[0162] For LTM cell switch, the test can be conducted by configuring the UE to perform either L1 or L3 measurement to report all N candidate cells, and trigger LTM cell one by one, so that we can observe that when we trigger LTM cell switch for any of the K strongest cells, the UE sends UL signal within the UL resource occasion between the reception of the trigger and the next SSB occurrence. We can also rely on subsequent LTM cell switch to run the test, which includes: UE receives a trigger for LTM, changes to a LTM candidate cell, and when the UE receives a trigger for another LTM cell switch, changes to another LTM candidate cell.
[0163] 4) The UE selects all LTM candidate cells configured for TA establishment / update, e.g., upon reception of an RRC message including TA establishment configuration, when the number of LTM candidate cells configured for TA establishment / update does not exceed the UE capability corresponding to the maximum number of cells the UE is capable of performing DL synchronization before reception of the trigger.
[0164] For example, when the UE reports a capability indicating the UE is capable of performing DL synchronization with “K” LTM candidate cells, and the UE receives a message (e.g., RRC reconfiguration) including LTM configuration, which includes TA establishment configuration for K* LTM candidate cells, where K* < K, then the UE can send UL signal to any of the LTM candidate cells upon reception of the trigger within the UL resource occasion between the reception of the trigger and the next SSB occurrence.
[0165] The above capability can be reported when the UE transitions from IDLE state to CONNECTED state.
[0166] There can be a capability related to LTM cell switch and another capability related to TA establishment / update procedure.
[0167] Testability / measurability of the UE implementation steps: in the test, we can configure TA establishment for a subset of LTM candidate cells (“K”), trigger TA establishment procedure for the K cells, and verify whether the UE is sending UL signal (e.g., PRACH preamble) to the first PRACH occasion after reception of the trigger but before the next SSB.
[0168] 5) The UE selects LTM candidate cells configured for TA establishment / update with sufficient strong measurement quantity (e.g., RSRP), e.g., the UE selects LTM candidate cells configured for TA establishment with sufficient strong RSRP.
[0169] In one option as one of the examples, the measurement quantity can correspond to RSRP, RSRQ, SINR.
[0170] In one option as one of the examples, the measurement quantity can correspond to a cell-based measurement quantity, e.g., cell RSRP of LTM candidate cell.
[0171] In one option as one of the examples, the measurement quantity can correspond to a beam / SSB / CSI-RS based measurement quantity. For example, the UE selects the cell whose strongest SS-RSRP is sufficient / sufficiently.
[0172] Testability / measurability of the UE implementation of the steps: In the test, we can configure TA establishment for a subset of LTM candidate cells (“K”), trigger the TA establishment procedure for the K cells, and verify whether the UE is transmitting UL signals (e.g., PRACH preamble) to the first PRACH occasion after receiving the trigger but before the next SSB.
[0173] 6) The UE selects the “K” strongest LTM candidate cells configured for TA establishment from the “N” configured LTM candidate cells configured for TA establishment according to the measurement quantity, where the measurement quantity can correspond to RSRP, RSRQ, SINR, etc.
[0174] In one option as one of the examples, the UE reports the capability indicating that the UE is capable of DL synchronization before TA establishment or LTM cell switching, where “K” LTM candidate cells are configured for TA establishment, and the UE receives a message (e.g., RRC reconfiguration) including LTM configuration of “N” LTM candidate cells, where N>K, so that the UE transmits UL signals to any of the K strongest LTM candidate cells for measurement within the UL resource occasion between receiving the trigger and the occurrence of the next SSB when receiving the trigger.
[0175] In one option as one of the examples, the measurement quantity can correspond to RSRP, RSRQ, SINR.
[0176] In one option as one of the examples, the K strongest LTM candidate cells are selected based on cell quality of the LTM candidate cells, e.g., the UE selects the LTM candidate cell whose cell RSRP value is strongest.
[0177] In one option as one of the examples, the K strongest LTM candidate cells are selected based on beam / SSB / CSI-RS quality of the LTM candidate cells, e.g., the UE selects the LTM candidate cell whose strongest beam level RSRP value (SS-RSRP value) is strongest.
[0178] 8) UE selects one or more LTM candidate cells based on the latest L1 measurement report (e.g., SS-RSRP of the LTM candidate cells that have been reported).
[0179] In one option as one of the examples, the UE is configured to perform L1 measurement, e.g., CSI measurement, SS-RSRP measurement, etc., on one or more LTM candidate cells. Then, the UE selects the LTM candidate cells as the cells that the UE has sent L1 report. The reason could be that these cells are also the LTM candidate cells that are more likely to be requested by the network (e.g., S-DU) to perform TA establishment and / or LTM cell handover.
[0180] In one option as one of the examples, the UE performs such operation on multiple LTM candidate cells before its capability of the number of cells performing DL synchronization or pre-synchronization is exceeded.
[0181] Testability / measurability of the UE implementation of the steps: In the test, we can configure the UE to send L1 report of LTM candidate cells, and shortly after that, trigger TA establishment (or LTM cell handover), and verify that the UE is sending PRACH preamble at the first PRACH occasion and / or within the PRACH occasions between receiving the trigger for TA establishment and the next SSB of the LTM candidate cell.
[0182] 9) UE selects one or more LTM candidate cells based on L3 measurement (e.g., cell-based RSRP of the LTM candidate cells).
[0183] In one option as one of the examples, the UE is configured to perform L3 measurement, e.g., radio resource management (RRM) measurement, such as L3 filtered cell-based RSRP, RSRQ, SINR, on one or more LTM candidate cells. Then, the UE selects the LTM candidate cells as the cells that the UE has sent L3 measurement report, e.g., the triggering cells that meet the condition of the event (e.g., A3 or A5 event) configured in the reporting configuration. The reason could be that these triggering cells that meet the event could be configured by the network as LTM candidate cells, and are requested by the network (e.g., S-DU) to perform TA establishment.
[0184] In one option as one of the examples, the UE performs such operation on multiple neighboring cells (e.g., the triggering cells) before its capability is exceeded, e.g., the number of cells that the UE reports is up to the number of LTM candidate cells that the UE can perform DL synchronization before TA establishment.
[0185] In one option as one of the examples, the UE updates the neighboring cells (e.g., the triggering cells) on which the UE performs DL synchronization depending on the cells being reported.
[0186] Testability / measurability of the step implementation by the UE: In the test, we can configure the UE to (periodically) send L3 reports for LTM candidate cells and shortly after that trigger the TA establishment and verify that the UE is sending PRACH preamble at the first PRACH occasion and / or within the PRACH occasions between receiving the trigger for TA establishment and the next SSB of the LTM candidate cell.
[0187] 12) The UE selects cells in higher frequencies and / or specific frequency ranges, e.g. FR2 cells, because these cells can take longer time to perform DL synchronization and / or measurements.
[0188] In one option as one of the examples, the UE selects one or more LTM candidate cells (or a subset of LTM candidate cells) whose SSBs are in high frequencies and / or specific frequency ranges (FR2).
[0189] The reason is that for these cells, it can take longer time to obtain DL synchronization, so that if the UE waits for the trigger to send UL signals and first needs to perform DL synchronization, it can take too much time.
[0190] Testability / measurability of the step implementation by the UE: In the test, we can configure the UE with LTM candidate cells in different frequency ranges and observe that for certain frequency ranges (e.g. FR2), the UE sends UL signals (e.g. PRACH preamble) at the trigger and within the PRACH occasions between the trigger and the next SSB of the LTM candidate that occurs after the trigger when the TA establishment is triggered.
[0191] 13) The UE selects cells with “long” SSB periods.
[0192] In one option as one of the examples, the UE performs DL synchronization for LTM candidate cells (or a subset of LTM candidate cells) whose SSBs have long periods (e.g. more than 20 ms).
[0193] In one option as one of the examples, a long period (e.g. a period threshold) is configured so that the UE performs DL synchronization for cells with periods longer than the configured value.
[0194] The reason is that for these cells, it can take longer time to obtain DL synchronization, so that if the UE waits for the trigger to send UL signals and first needs to perform DL synchronization, it can take too much time.
[0195] Testability / measurability of the steps implementation by the UE: In testing, we can configure the UE with LTM candidate cells having different (longer and shorter) periodicities, and we observe that for longer periodicities (e.g., 50 ms and above), the UE transmits UL signals (e.g., PRACH preamble) within the PRACH occasion between the trigger and the next SSB of the LTM candidate that occurs after the trigger when TA establishment is triggered.
[0196] According to the method, the one or more rules can be based on one or more parameters configured for the UE. The UE can receive the configuration of the one or more parameters in an RRC reconfiguration message, wherein the one or more parameters can be set for one or more LTM candidate cells.
[0197] Figure 12 And Figure 13 An example of the signaling flow of the method is shown in FIG. 13, wherein the method applies to the TA establishment procedure. The trigger can correspond to a PDCCH order or LTM cell switch command for the LTM candidate cell, wherein some steps are also performed by the involved network nodes (e.g., source DU (S-DU), central unit (CU), and candidate DU (C-DU)).
[0198] In one set of embodiments, the UE receives the configuration of one or more LTM candidate cells, then the UE receives the LTM cell switch command, and in response to the LTM cell switch command, the UE transmits an UL signal (e.g., HARQ control information) on an UL channel (e.g., PUCCH) to the LTM candidate cell, wherein the UL signal includes a scheduling request for transmitting a hybrid automatic repeat request (HARQ) feedback.
[0199] In one embodiment, the UE receives the LTM cell switch command, and in response to the LTM cell switch command, the UE receives information about a DL control channel (e.g., PDCCH) occasion (e.g., a given frame / subframe / slot / one or more OFDM symbols), e.g., a downlink control indication (DCI) indicating a DL data channel (e.g., PDSCH) with downlink data, such that in response the UE needs to transmit a HARQ feedback. To transmit the HARQ feedback, the UE transmits the scheduling request on the PUCCH. According to the method, the DL control channel occasion occurs between the reception of the LTM cell switch and the first synchronization signal (e.g., SSB) of the LTM candidate cell that occurs after the trigger.
[0200] Figure 14Some embodiments are exemplarily shown where additional delays introduced in the absence of the method are shown. In the absence of the method, which can rely on the UE performing DL pre-synchronization with the SSB of the LTM candidate cell prior to receiving the trigger, the UE has to wait for the SSB of the LTM candidate cell after receiving the trigger, then monitor the PDCCH, search for the DCI, and obtain the downlink data on the PDSCH, before it can send the HARQ feedback on the PUCCH.
[0201] Figure 15 is a flowchart illustrating an exemplary method 1500 of performing UL access (e.g., fast UL access) to an LTM candidate cell. Reference is made to Figure 15 In block 1502, the method includes receiving, from a network node, an LTM configuration of at least one LTM candidate cell. In some embodiments, the UE is configured to receive the LTM configuration from the network node. In block 1504, the method includes receiving, from the network node, a trigger. In some embodiments, the UE is configured to receive the trigger from the network node. In block 1506, the method includes, in response to receiving the trigger, transmitting, with data in the LTM configuration, a UL signal during a UL resource occasion (e.g., a PRACH occasion) corresponding to the LTM candidate cell, wherein the UL resource occasion occurs during a time period between receiving the trigger and a first synchronization signal (e.g., an SSB) of the LTM candidate cell occurring after receiving the trigger. In some embodiments, the UE is configured to transmit the UL signal during the UL resource occasion in response to receiving the trigger.
[0202] Figure 16 is a flowchart illustrating an exemplary method 1600 of a network node enabling fast UL access to an LTM candidate cell by a UE. Reference is made to Figure 16 In block 1602, the method includes transmitting, from a network node to a UE, an LTM configuration of at least one LTM candidate cell. In block 1604, the method includes transmitting, from the network node to the UE, a trigger. In some embodiments, the UE is configured to receive the trigger from the network node. In block 1606, the method can optionally include, in response to the UE receiving the trigger, receiving, by the network node from the UE, a UL signal including data from the LTM configuration during a UL resource occasion (e.g., a PRACH occasion) corresponding to the LTM candidate cell, wherein the UL resource occasion occurs during a time period between the UE receiving the trigger and a first synchronization signal (e.g., an SSB) of the LTM candidate cell occurring after the UE receiving the trigger.
[0203] Figure 17 An example of a communication system QQ100 in accordance with some embodiments is shown.
[0204] In this example, the communication system QQ100 includes a telecommunication network QQ102 comprising an access network QQ104, such as a Radio Access Network (RAN), and a core network QQ106 comprising one or more core network nodes QQ108. The access network QQ104 comprises one or more access network nodes, such as network nodes QQ110a and QQ110b (one or more of which can be referred to as network nodes QQ110 generically), or any other similar Third Generation Partnership Project (3GPP) access node or non-3GPP access point. Moreover, those skilled in the art will appreciate that network nodes are not necessarily limited to implementations provided by a single vendor and that integrated radio and baseband portions of a network node are not necessarily provided by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, the telecommunication network QQ102 includes one or more Open RAN (ORAN) network nodes. ORAN network nodes are nodes in the telecommunication network QQ102 that support ORAN specifications (e.g., specifications published by the O-RAN Alliance or any similar organization) and can operate independently or with other nodes to implement one or more functions of any node in the telecommunication network QQ102, including one or more network nodes QQ110 and / or core network nodes QQ108.
[0205] Examples of ORAN network nodes include open radio units (O-RUs), open distributed units (O-DUs), open central units (O-CUs), including O-CU control plane (O-CU-CP) or O-CU user plane (O-CU-UP), RAN intelligent controllers (near real-time or non-real-time) hosting software or software plug-ins (e.g., near real-time control applications (e.g., xApps) or non-real-time control applications (e.g., rApps)), or any combination thereof (the adjective “open” indicates support for ORAN specifications). The network nodes can support the specifications by, for example, supporting interfaces defined by ORAN specifications (e.g., Al, Fl, Wl, El, E2, X2, Xn interfaces), open fronthaul user plane interfaces, or open fronthaul management plane interfaces. Further, ORAN access nodes can be logical nodes in physical nodes. Further, ORAN network nodes can be implemented in a virtualized environment (further described below) in which one or more network functions are virtualized. For example, the virtualized environment can include an open cloud (O-Cloud) computing platform orchestrated by a service management and orchestration framework via an O-2 interface defined by the O-RAN Alliance or comparable technology. The network nodes QQ110 facilitate direct or indirect connection of user equipment (UE) such as UEs QQ112a, QQ112b, QQ112c, and QQ112d (one or more of which can be generally referred to as UE QQ112), to core network QQ106, e.g., through one or more wireless connections.
[0206] Example wireless communication over a wireless connection includes transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transmitting information over a network without the use of wires, cables, or other material connectors. Further, in different embodiments, communication system QQ100 can include any number of wired or wireless networks, network nodes, UEs, and / or any other component or system that can facilitate or participate in the communication of data and / or signals between and among each other. Communication system QQ100 can include any type of communication, telecommunications, data, cellular, radio, and / or other similar type of system, and / or interface with any type of communication, telecommunications, data, cellular, radio, and / or other similar type of system.
[0207] The UEs QQ112 can be any of various types of wireless devices, including wireless devices that are arranged to communicate wirelessly with network nodes QQ110 and other wireless devices. Similarly, network nodes QQ110 are arranged, enabled, configured and / or operable to communicate directly or indirectly with UEs QQ112 and / or with other network nodes or devices within the telecommunication network QQ102, to enable and / or provide wireless access to the network QQ102 (e.g., via one or more wireless access interfaces) and / or to perform other functions in the telecommunication network QQ102.
[0208] In the depicted example, core network QQ106 connects network nodes QQ110 to one or more hosts (e.g., host QQ116). The connections between the network nodes QQ110 and the hosts can be wired or wireless. In other examples, network nodes can be directly coupled to hosts. Core network QQ106 includes one or more core network nodes, such as core network node QQ108, which together form a core network, with hardware and software components that provide various types of services to the UEs QQ112. These components can be substantially similar to the components described with respect to the UEs, network nodes, and / or hosts, such that their description can generally apply to corresponding components of the core network node QQ108. Example core network nodes include functionality of one or more of a mobile switching center (MSC), a mobility management entity (MME), a home subscriber server (HSS), an access and mobility management function (AMF), a session management function (SMF), an authentication server function (AUSF), a subscription identifier de-concealing function (SIDF), a unified data management (UDM), a security edge protection proxy (SEPP), a network exposure function (NEF), and / or a user plane function (UPF).
[0209] Host QQ116 can be owned and / or under control of a service provider other than the operator or provider of access network QQ104 and / or telecommunication network QQ102, and can be operated by or on behalf of the service provider. Host QQ116 can host a variety of applications to provide one or more services. Examples of such applications include real-time and pre-recorded audio / video content, data collection services (e.g., retrieving and compiling data about various environmental conditions detected by a plurality of UEs), analytics functions, social media, functions for controlling or otherwise interacting with remote devices, functions for alarm and monitoring centers, or any other such functions performed by a server.
[0210] As a whole, Figure 17The communication system QQ100 enables connectivity between UEs, network nodes, and hosts. In this regard, the communication system can be configured to operate according to predefined regulatory or procedural requirements, such as specific standards including, but not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunication System (UMTS); Long Term Evolution (LTE); and / or other suitable 2G, 3G, 4G, 5G standards, or any future generation standard (e.g., 6G) that can be available; Wireless Local Area Network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and / or any other appropriate wireless communication standard, such as Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near-Field Communication (NFC), ZigBee, LiFi, and / or any Low Power Wide Area Network (LPWAN) standard such as LoRa and Sigfox.
[0211] In some examples, the telecommunication network QQ102 is a cellular network implementing 3GPP standardized features. Thus, the telecommunication network QQ102 can support network slicing to provide different logical networks to different devices connected to the telecommunication network QQ102. For example, the telecommunication network QQ102 can provide Ultra-Reliable and Low-Latency Communications (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communications (mMTC) / massive IoT services to yet other UEs.
[0212] In some examples, the UEs QQ112 are configured to transmit and / or receive information without direct human interaction. For example, a UE can be designed to transmit information to the access network QQ104, on a prearranged schedule, when triggered by internal or external events, or in response to requests from the access network QQ104. In addition, UEs can be configured to operate in single-RAT mode or multi-RAT mode or multi-standard mode. For example, UEs can be configured to operate using any 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-UTRA (Evolved-UMTS Terrestrial Radio Access) New Radio-Dual Connectivity (EN-DC).
[0213] In this example, hub QQ114 communicates with access network QQ104 to facilitate indirect communication between one or more UEs (e.g., UEs QQ112c and / or QQ112d) and a network node (e.g., network node QQllOb). In some examples, hub QQ114 can be a controller, router, content source and analyzer, or any other communication device described herein with respect to a UE. For example, hub QQ114 can be a broadband router that enables a UE to access core network QQ106. As another example, hub QQ114 can be a controller that sends commands or instructions to one or more actuators in the UE. The commands or instructions can be received from the UE, network node QQllOb, or by executable code, scripts, processes, or other instructions in hub QQ114. As another example, hub QQ114 can be a data collector that acts as a temporary storage device for UE data, and in some embodiments, can perform analysis or other processing of the data. As another example, hub QQ114 can be a content source. For example, for a UE that is a VR headset, display, speaker, or other media delivery device, hub QQ114 can retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which hub QQ114 then provides directly to the UE after performing local processing and / or after adding additional local content. In yet another example, hub QQ114 acts as a proxy server or coordinator for the UEs, especially if one or more of the UEs are low-energy loT devices.
[0214] Hub QQ114 can have a persistent / permanent or intermittent connection with network node QQllOb. Hub QQ114 can also allow for different communication schemes and / or schedules between hub QQ114 and UEs (e.g., UEs QQ112c and / or QQ112d) and between hub QQ114 and core network QQ106. In other examples, hub QQ114 is connected to core network QQ106 and / or one or more UEs via a wired connection. Further, hub QQ114 can be configured to connect to an M2M service provider through access network QQ104, and / or to another UE through a direct connection. In some scenarios, a UE can establish a wireless connection with network node QQllOb while still connecting through hub QQ114 via a wired or wireless connection. In some embodiments, hub QQ114 can be a dedicated hub - i.e., a hub whose primary function is to route communications from network node QQllOb to a UE / route communications from a UE to network node QQllOb. In other embodiments, hub QQ114 can be a non-dedicated hub - i.e., a device that is capable of operating to route communications between a UE and network node QQllOb but additionally capable of operating as a communication origin and / or endpoint for certain data channels.
[0215] Figure 18 A UE QQ200 is shown according to some embodiments. As used herein, a UE refers to a device that is capable, configured, arranged and / or operable to communicate wirelessly with a network node and / or other UEs. Examples include, but are not limited to, smart phones, mobile phones, cellular phones, IP phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, game consoles or devices, music storage devices, playback devices, wearable terminal devices, wireless endpoints, mobile stations, tablet computers, laptop computers, laptop-mounted embedded equipment (LEE), laptop-mounted installation equipment (LME), smart devices, wireless customer-premise equipment (CPE), vehicles, vehicle-mounted or vehicle-embedded wireless equipment, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP) including Narrow- Band Internet of Things (NB-IoT) UEs, Machine Type Communication (MTC) UEs, and / or Enhanced MTC (eMTC) UEs.
[0216] A UE may, for example, support device-to-device (D2D) communication through implementation of 3GPP standards for sidelink communication, dedicated short-range communications (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-anything (V2X). In other examples, a UE can not necessarily have a user in the sense of a human user that owns and / or operates the relevant device. Instead, a UE can represent a device that is intended for sale to the end user or operation by the end user but can not or can not initially be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE can represent a device that is not intended for sale or operation by an end user but can be associated with or operated for the benefit of a user (e.g., a smart power meter).
[0217] The UE QQ200 includes processing circuitry QQ202, which is operatively coupled to input / output interface QQ206, power source QQ208, memory QQ210, communication interface QQ212, and / or any other component(s) or combination thereof. Some of the components can be grouped into a housing. The grouping is illustrative and other groupings are possible. The grouping of components is not required in all embodiments, and can be grouped differently in other embodiments. Figure 18 All or a subset of the components shown in FIG. 2 can be included in the UE QQ200. The level of integration between the components can vary from embodiment to embodiment. Furthermore, certain UEs can include a plurality of one or more of the components shown in FIG. 2. For instance, a UE can include a plurality of processors, memories, transceivers, transmitters, receivers, etc.
[0218] Processing circuitry QQ202 is configured to process instructions and data, and can be configured as any sequential state machine (e.g., implemented with discrete logic, field programmable gate array (FPGA), application specific integrated circuit (ASIC), etc.) operable to execute instructions stored in memory QQ210 as an ordered listing of processor-readable instructions. Processing circuitry QQ202 can be implemented with one or more hardware-implemented state machines operating in discrete stages as described with respect to the software implementation, a programmable logic combined with appropriate firmware, one or more stored computer programs, a general-purpose processor (e.g., a microprocessor or digital signal processor (DSP)) combined with appropriate software, or any combination thereof. For example, processing circuitry QQ202 can include multiple central processing units (CPUs).
[0219] In this example, input / output interface QQ206 can be configured to provide one or more interfaces to input and output devices. Examples of output devices include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, a transmitter, a smartcard, another output device, or any combination thereof. An input device can allow a user to capture information into the UE QQ200. Examples of input devices include a touch-sensitive display or a presence-sensitive display, a camera (e.g., a digital still or motion camera), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence- sensitive display can include a capacitive or resistive touch sensor to sense input from a user. Examples of sensors include accelerometers, gyroscopes, tilt sensors, force sensors, magnetometers, optical sensors, proximity sensors, biometric sensors, etc., or any combination thereof. An output device can use the same physical
[0220] In some embodiments, power source QQ208 is configured as one or more batteries or battery packs. Other types of power sources, such as an external power supply (e.g., an electricity outlet), photovoltaic devices or power cells, can also be used. Power source QQ208 can further comprise power circuitry for delivering power from power source QQ208 and / or an external power source to the various parts of UE QQ200 via, for example, an input circuitry or interface such as an electrical cable. The power delivered by power source QQ208 can also be used to recharge a rechargeable battery or battery pack. Power circuitry can perform any formatting, converting, or other modification to the power from power source QQ208 necessary to supply appropriate power to the components of UE QQ200.
[0221] Memory QQ210 can be or include memory such as random access memory (RAM), read only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electronically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, hard tissue, removable disk, flash memory devices, or the like. In one example, memory QQ210 includes one or more applications QQ214, such as an operating system, a web browser application, widgets, a widget engine, or other applications, and corresponding data QQ216. Memory QQ210 can store any of a variety of various operating systems used by UE QQ200 or combinations of operating systems.
[0222] Memory QQ210 can be configured to include a number of physical drive units, such as redundant array of independent disks (RAID), flash memory, USB flash drives, external hard drives, thumb drives, pen drives, key drives, high-density digital versatile disks (HD-DVDs), Blu-ray discs, holographic data storage (HDDS) discs, external mini-dual in-line memory modules (DIMMs), synchronous dynamic random access memory (SDRAM), external micro-DIMMs, smart cards, other memory, or any combination thereof. The UICC, for example, can be an embedded UICC (eUICC), an integrated UICC (iUICC), or a removable UICC commonly referred to as a "SIM card." Memory QQ210 can allow UE QQ200 to access instructions, application programs, or the like stored on transitory or non-transitory storage media for off-site downloading or uploading of data. An article of manufacture, such as of a communication system, can be tangibly embodied in or by memory QQ210, which can be or include a device readable storage medium.
[0223] The processing circuitry QQ202 can be configured to perform one or more functions described herein. For example, the processing circuitry QQ202 can be configured to perform functions associated with a node (e.g., a network node, a base station, a relay, a UE, etc.). For example, the processing circuitry QQ202 can be configured to receive, transmit, process and / or store data associated with any of the nodes, devices, and / or functions described herein. The processing circuitry QQ202 can be configured to perform data processing and / or other processing (e.g., of sensor data, interface data, or other data) associated with one or more of the nodes, devices, and / or functions described herein.
[0224] In the illustrated embodiment, the communication functionality of the communication interface QQ212 can include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range
[0225] Regardless of the type of sensor, the UE can provide an output of data captured by its sensors via its communication interface QQ212 over a wireless connection with a network node. Data captured by the sensors of the UE can be transmitted via another UE over a wireless connection with a network node. The output can be periodic (e.g., every 15 minutes if it reports sensed temperature), random (e.g., to balance the load of reports from several sensors), responsive to a triggering event (e.g., sending an alert when moisture is detected), responsive to a request (e.g., a user-initiated request), or a continuous stream (e.g., a real-time video feed of a patient).
[0226] As another example, the UE includes an actuator, motor, or switch related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input, the state of the actuator, motor, or switch can change. For example, the UE can include a motor that adjusts a control surface or rotor of a drone in flight according to the received input, or adjusts a robotic arm performing a medical procedure according to the received input.
[0227] When the UE is in the form of an Internet of Things (IoT) device, the UE can be a device for use in one or more application domains, including but not limited to smart cities, extended industrial applications, and healthcare. Non-limiting examples of such IoT devices are or are embedded in: a networked refrigerator or freezer, a television, a networked lighting device, an electricity meter, a robotic vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a flood / water level sensor, an electronic door lock, a networked doorbell, an air conditioning system (such as a heat pump), an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a head-mounted display for augmented reality (AR) or virtual reality (VR), a wearable device for tactile or sensory augmentation, a sprinkler, an animal tracking or item tracking device, a sensor for monitoring plants or animals, an industrial robot, an unmanned aerial vehicle (UAV), and any kind of medical device (such as a heart rate monitor or a teleoperated surgical robot). In addition to the other components described with respect to the UE QQ200 shown in Figure 18 In addition to the other components described with respect to the UE QQ200 shown in
[0228] As yet another particular example, in an IoT scenario, the UE can represent a machine or other device that performs monitoring and / or measurements, and sends the results of such monitoring and / or measurements to another UE and / or a network node. In this case, the UE can be a M2M device, which in a 3GPP context can be referred to as a MTC device. As one particular example, the UE can implement the 3GPP NB-IoT standard. In other scenarios, the UE can represent a vehicle (e.g., an automobile, a bus, a truck, a boat, and an airplane), or other equipment that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation.
[0229] In practice, any number of UEs can be used together for a single use case. For example, a first UE can be or be integrated in a drone, and provide speed information of the drone (obtained by a speed sensor) to a second UE, which is a remote controller that operates the drone. When a user makes a change from the remote controller, the first UE can adjust the throttle on the drone (e.g., by controlling an actuator) to increase or decrease the speed of the drone. The first UE and / or the second UE can also include more than one of the above-mentioned functions. For example, a UE can include both a sensor and an actuator, and handle data communication for both the speed sensor and the actuator.
[0230] Figure 19 A network node QQ300 according to some embodiments is shown in Figure 3. As used herein, a network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with another network node or equipment within a telecommunications network. 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 Bs, evolved Node Bs (eNBs) and NR Node Bs (gNBs)), O-RAN nodes or components of O-RAN nodes (e.g., O-RUs, O-DUs, O-CUs).
[0231] Base stations can be categorized based on how much power they provide (or in other words, how much coverage area they serve) and thus, depending on the provided coverage, can be referred to as femto base stations, pico base stations, micro base stations or macro base stations. Base stations can be relay nodes or relay donors controlling relays. Network nodes can also include one or more (or all) parts of a distributed radio base station such as centralized, distributed or grid radio base stations, sometimes referred to as access nodes. These parts can be located in the same or different locations. For example, some parts can be located centralized in a centralized base station, some parts can be located distributed in a distributed base station and some parts can be located remote from the operator's network, for example, in a remote radio unit (RRU).
[0232] Other examples of network nodes include multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell / multicast coordination entities (MCEs), operation and maintenance (O&M) nodes, operation support systems (OSSs) nodes, self-organizing network (SON) nodes, positioning nodes such as Evolved Serving Mobile Location Center (E-SMLC), and / or minimizing drive testing (MDT).
[0233] The network node QQ300 includes processing circuitry QQ302, memory QQ304, communication interface QQ306, and power source QQ308. The network node QQ300 can be comprised of multiple physically separate components (e.g., NodeB components and RNC components, BTS components and BSC components, etc.), which can have respective individual
[0234] The processing circuitry QQ302 can comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other processing circuit, as well as any
[0235] In some embodiments, the processing circuitry QQ302 comprises a system on a chip (SOC). In some embodiments, the processing circuitry QQ302 includes one or more of radio frequency (RF) transceiver circuit QQ312 and baseband processing circuitry QQ314. In some embodiments, radio frequency (RF) transceiver circuit QQ312 and baseband processing circuitry QQ314 can be on separate chips (or chipsets), boards, or units (e.g., a radio unit and a digital unit), in alternative embodiments, parts or all of RF transceiver circuit QQ312 and baseband processing circuitry QQ314 can be on the same chip or chipset, board, or unit.
[0236] Memory QQ304 can include any form of volatile or non-volatile computer- readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read only memory (ROM), mass storage media (for example, a hard disk), removable memory media (for example, a flash drive, a Compact Disk (CD), or a Digital Video Disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory devices that store information, data, and / or instructions that can be used with processing circuitry QQ302. Memory QQ304 can store any
[0237] Communication interface QQ306 is used for wired or wireless communication of signaling and / or data between network nodes, access networks, and / or UEs. As illustrated, communication interface QQ306 includes a port / terminal QQ316 for receiving data from and transmitting data to network, for example via a wired connection. Communication interface QQ306 also includes radio front end circuitry QQ318 that can be coupled to, or in some embodiments a part of, antenna QQ310. Radio front end circuitry QQ318 comprises filters QQ320 and amplifiers QQ322. Radio front end circuitry QQ318 can be connected to antenna QQ310 and processing circuitry QQ302. Radio front end circuitry can be configured to condition signals communicated between antenna QQ310 and processing circuitry QQ302. Radio front end circuitry QQ318 can receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. Radio front end circuitry QQ318 can convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters QQ320 and / or amplifiers QQ322. The radio signal can then be transmitted via antenna QQ310. Similarly, when data is being received, antenna QQ310 can collect radio signals, which radio front end circuitry QQ318 converts into digital data. The digital data can be passed to processing circuitry QQ302. In
[0238] In certain alternative embodiments, network node QQ300 does not include separate radio front end circuitry QQ318, instead, processing circuitry QQ302 includes radio front end circuitry and is connected to antenna QQ310. Similarly, in some embodiments, all or some of RF transceiver circuitry QQ312 is a part of communication interface QQ306. In yet another embodiment, communication interface QQ306 includes one or more ports or terminals QQ316 as part of a radio
[0239] Antenna QQ310 can include one or more antennas or antenna arrays configured to send and / or receive wireless signals. Antenna QQ310 can be coupled to radio front-end circuitry QQ318 and can be any type of antenna and / or antenna array capable of
[0240] Antenna QQ310, communication interface QQ306, and / or processing circuitry QQ302 can be configured to perform any of the receiving operations and / or certain obtaining operations described herein as being performed by a network node. Any information, data and / or signals can be received from a UE, another network node and / or any other network equipment. Similarly, antenna QQ310, communication interface QQ306, and / or processing circuitry QQ302 can be configured to perform any of the transmitting operations described herein as being performed by a network node. Any information, data and / or signals can be transmitted to a UE, another network node and / or any other network equipment.
[0241] Power source QQ308 provides power to various components of network node QQ300 in a form suitable for use by each respective component (e.g., at a voltage and current level that each respective component needs and / or is compatible with). Power source QQ308 can include or be coupled to power management circuits to supply or control power supplied to the components of network node QQ300 for performing the functions described herein. For example, network node QQ300 can be connected to an external power source (e.g., an electricity outlet via an input circuit or interface) via which power source QQ308 receives power from. As another example, power source QQ308 can include one or more batteries or power cells coupled to or integrated with power source circuitry to provide power to network node QQ300 for off -network operation.
[0242] Embodiments of network node QQ300 can include additional components not shown in FIG. 3 that can be useful for particular applications of network node QQ300. For example, network node QQ300 can include various processing components, including one or more processors (e.g., CPUs, application-specific processors, or other processing devices) operating in conjunction with one or more storage media (e.g., disk storage, solid state memory, or other storage media) to provide processing onboarding, management, and / or other operations described herein.Figure 19 Additional components, not shown, can be included in the assembly to provide certain aspects of functionality of the network node, including any functionality described herein and / or any functionality required to support the subject matter described herein. For example, the network node QQ300 can include user interface equipment to allow input of information into the network node QQ300 and to allow output of information from the network node QQ300. This can allow a user to perform diagnostic, maintenance, repair, and other management functions in relation to the network node QQ300.
[0243] Figure 20 is a block diagram of a host QQ400 in accordance with various aspects described herein, which can be a host QQ400 of the host QQ400 Figure 17 embodiments of the host QQ400. As used herein, the host QQ400 can be or include various combinations of hardware and / or software, including processing resources in a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, a container, or a group of servers. The host QQ400 can provide one or more services to one or more UEs.
[0244] The host QQ400 includes processing circuitry QQ402 operably coupled to an input / output interface QQ406, a network interface QQ408, a power supply QQ410, and a memory QQ412 via a bus QQ404. Other components can be included in other embodiments. Features of these components can be substantially similar to features of the corresponding components described with reference to the devices of the previous figures (e.g., the host QQ400 of Figure 18 and Figure 19 the host QQ400 of FIG. 17), such that their description can generally apply to the corresponding components of the host QQ400.
[0245] Memory QQ412 can include one or more computer programs, including data QQ416, which can include user data, e.g., data generated by a UE for the host QQ400 or data generated by the host QQ400 for a UE, and one or more host applications QQ414. Embodiments of the host QQ400 can utilize only a subset of the shown components or all of them. The host applications QQ414 can be implemented in a container-based architecture and can provide support for video codecs (e.g., Versatile 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 a variety of different classes, types, or implementations of UEs (e.g., cellphones, desktop computers, wearable display systems, heads-up display systems). The host applications QQ414 can also provide user authentication and permission checks and can periodically report health, routing, and content availability to a central node (e.g., a device in the core network or on the edge of the core network). Thus, the host QQ400 can select and / or instruct different hosts for over-the-top services for UEs. The host applications QQ414 can support various protocols, e.g., HTTP Live Streaming (HLS) protocol, Real Time Messaging Protocol (RTMP), Real Time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), etc.
[0246] Figure 21 is a block diagram illustrating a virtualization environment QQ500 in which functions implemented by some embodiments can be virtualized. In this context, virtualization means the creation of virtual versions of apparatuses or devices, which can include virtualization of hardware platforms, storage devices, and network resources. As used herein, virtualization can apply to any device or component described herein and involves the implementation of at least a portion of the functionally described herein as a virtual component or components. Some or all of the functionality described herein can be implemented as virtual components executed by one or more Virtual Machines (VMs) implemented in one or more virtual environments QQ500 hosted by one or more of the hardware nodes (e.g., a hardware computing device operating as a network node, UE, core network node, or host). Further, in embodiments where the virtual node does not require radio connectivity (e.g., a core network node or a host), then the node can be entirely virtualized. In some embodiments, the virtualization environment QQ500 includes components defined by the O-RAN Alliance, e.g., an open cloud environment orchestrated by a service management and orchestration framework via an O-2 interface.
[0247] The application QQ 502, which can alternatively be referred to as a software instance, virtual apparatus, network function, virtual node, virtual network function, and / or the like, runs in the virtualization environment Q400 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.
[0248] The hardware QQ504 includes processing circuitry, memory storing software and / or instructions executable by the processing circuitry, and / or other hardware
[0249] The VMs QQ 508 include virtual processing, virtual memory, virtual networking or interface, and virtual storage, and can be run by a corresponding virtualization layer QQ506. Different embodiments of the instance of virtual apparatus QQ502 can be implemented on one or more of the VMs QQ 508, and can be made available to other virtual apparatuses, networks, and / or networks functions run on the same or different VMs QQ 508. In some contexts, virtualization of the hardware is referred to as network function virtualization (NFV). NFV can be used to consolidate many network equipment types onto industry-standard high-volume server hardware, physical switches, and physical storage, which can be located in
[0250] In the context of NFV, the VMs QQ 508 can be software implementations of physical machines that run programs just as if they were executing on physical, non-virtualized machines. Each VM QQ 508, along with that portion of the hardware QQ504 that executes that VM, forms a separate virtual network element. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more of the VMs QQ 508 on top of the hardware QQ504 and correspond to an application QQ502.
[0251] Hardware QQ504 can be implemented in a standalone network node with generic or specific components. Hardware QQ504 can implement some functions via virtualization. Alternatively, hardware QQ504 can be part of a larger cluster of hardware (e.g., in a data center or CPE), where many hardware nodes work together and are managed by management and orchestration QQ510, which among others oversees lifecycle management of applications QQ502. In some embodiments, hardware QQ504 is coupled to one or more radio units, each of which can include one or more transmitters and one or more receivers that can be coupled to one or more antennas. Radio units can communicate with other hardware nodes directly via one or more appropriate network interfaces and can be used in combination with virtual components to provide a virtual node (e.g., a radio access node or a base station) with radio capabilities. In some embodiments, some signaling can be provided using control system QQ512, which can alternatively be used for communication between the hardware nodes and the radio units.
[0252] Figure 22 A communication diagram illustrating a host QQ602 communicating via a network node QQ604 with a UE QQ606 over a partial wireless connection in accordance with some embodiments is shown. Example implementations of the UE (e.g., UE QQ112a and / or UE QQ200 of Figure 22 Figure 17 Figure 18 Figure 17 Figure 19 Figure 17 Figure 20
[0253] Similar to host QQ400, embodiments of host QQ602 include hardware, such as communication interface, processing circuitry, and memory. Host QQ602 also includes software, which is stored in or accessible by the host QQ602 and executable by the processing circuitry. The software includes a host application, which is operable to provide a service to a remote user, such as UE QQ606, connecting via an over-the-top (OTT) connection QQ650 extending over, and terminated by, the UE QQ606 and the host QQ602. In providing the service to the remote user, the host application can provide user data, which is transmitted using the OTT connection QQ650.
[0254] Network node QQ604 includes hardware enabling it to communicate with host QQ602 and UE QQ606. Connection QQ660 can be a direct connection or a connection via a core network (like core network QQ120 of FIGURE 1).Figure 17 The network QQ600 can include a core network QQ106) and / or one or more other intermediate networks (e.g., one or more public, private, or hosted networks). For example, the intermediate network can be a backbone network or the Internet.
[0255] The UE QQ606 includes hardware and software, which store in or are accessible to the UE QQ606 and executable by the processing circuitry of the UE. The software includes a client application (e.g., a web browser or a special purpose application for a particular industry or enterprise) operable to provide a service to a human or non-human user via the UE QQ606 with the support of the host QQ602. In the host QQ602, the executing host application can communicate with the executing client application via the OTT connection QQ650 terminating at the UE QQ606 and the host QQ602. In providing the service to the user, the client application of the UE can receive request data from the host application and provide user data in response to the request data. The OTT connection QQ650 can carry both the request data and the user data. The client application of the UE can interact with the user to generate user data to be provided by the host application.
[0256] The OTT connection QQ650 can be established using a connection QQ660 between the host QQ602 and a network node QQ604 and a wireless connection QQ670 between the network node QQ604 and the UE QQ606 to provide a connection between the host QQ602 and the UE QQ606. The connection QQ660 and the wireless connection QQ670 over which the OTT connection QQ650 is provided can be implemented as physical
[0257] As an example of transmitting data via the OTT connection QQ650, in step QQ608, the host computer QQ602 provides user data, which can be performed by executing a host application. In some embodiments, the user data is associated with a specific human user interacting with the UE QQ606. In other embodiments, the user data is associated with the UE QQ606, such as when the UE QQ606 is engaged in a machine -to-machine interaction. In step QQ610, the host computer QQ602 initiates a transmission carrying the user data to the UE QQ606. The host computer QQ602 can initiate the transmission in response to a request from the UE QQ606. The request can be caused by a human user interacting with the UE QQ606 or by the execution of a client application executed on the UE QQ606. The transmission can be delivered via the network node QQ604, upon which the teachings of the embodiments described throughout this disclosure can be used. Thus, in step QQ612, the network node QQ604 transmits the user data carried in the transmission originating from the host computer QQ602 to the UE QQ606, according to the teachings of the embodiments described throughout this disclosure. In step QQ614, the UE QQ606 receives the user data carried in the transmission, which can be performed by the client application executed on the UE QQ606 associated with the host application executed by the host computer QQ602.
[0258] In some examples, the UE QQ606 executes a client application that provides user data to the host computer QQ602. The user data can be provided in reaction to the data received by the UE QQ606 from the host computer QQ602. Thus, in step QQ616, the UE QQ606 can provide user data, which can be performed by executing the client application. When providing user data, the client application can further consider user input received from a user via an input / output interface of the UE QQ606. Regardless of the specific manner in which the user data is provided, the UE QQ606 initiates a transmission of the user data to the host computer QQ602 via the network node QQ604, in step QQ618. In step QQ620, the network node QQ604 receives the user data from the UE QQ606 and initiates a transmission of the received user data to the host computer QQ602, according to the teachings of the embodiments described throughout this disclosure. In step QQ622, the host computer QQ602 receives the user data carried in the transmission originating from the UE QQ606.
[0259] One or more of the various embodiments improve performance of OTT services provided to the UE QQ606 using an OTT connection QQ650 in which the wireless connection QQ670 forms the last segment. More specifically, the teachings of these embodiments can reduce latency when sending UL signals to LTM candidate cells during TA establishment / update procedures, thereby providing benefits such as reduced user wait / connect time, better responsiveness, and increased reliability of overall UE connectivity.
[0260] In an example scenario, the host QQ602 can collect and analyze factory status information. As another example, the host QQ602 can process audio and video data that can have been retrieved from UEs for use in creating a map. As another example, the host QQ602 can collect and analyze real-time data to assist in controlling vehicular congestion (e.g., controlling traffic lights). As another example, the host QQ602 can store surveillance videos uploaded by UEs. As another example, the host QQ602 can store or control access to media content such as video, audio, VR, or AR, which can be broadcast, multicast, or unicast to UEs. As yet other examples, the host QQ602 can be used for energy pricing, remote control of non-time critical power loads to balance electricity demand, positioning services, rendering services (e.g., compiling graphs from data collected from remote devices, etc.), or any other functionality that collects, retrieves, stores, analyzes, and / or transmits data.
[0261] In some embodiments, a measurement procedure can be implemented for the purpose of monitoring the improved data rate, latency and other factors of one or more embodiments. There can also be an optional network functionality to reconfigure the OTT connection QQ650 between the host computer QQ602 and the UE QQ606, in response to variations in the measurement results. The measurement procedure and / or the network functionality to reconfigure the OTT connection can be implemented in the software and hardware of the host computer QQ602 and / or the UE QQ606. In some embodiments, sensors (not shown) can be deployed in or in association with other devices through which the OTT connection QQ650 passes; the sensors can participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software can compute or estimate the monitored quantities. The reconfiguring of the OTT connection QQ650 can include message format, retransmission settings, preferred routing, etc.; the reconfiguring need not directly involve the network nodes QQ604, but can simply consist in the host computer QQ602 or UE QQ606 changing its message retransmission policy. Such procedures and functionalities can be known and practiced in the art. In certain embodiments, measurements can involve proprietary UE signaling facilitating the host computer’s 602 measurements of throughput, propagation times, latency, etc. The measurements can be implemented through the software using the OTT connection QQ650 by sending messages (specifically crafted for the purpose of this procedure, or ordinary messages that are then processed by the software to extract relevant information) and concurrently monitoring the propagation times, errors, etc.
[0262] Although the computing devices described herein (e.g., UEs, network nodes, host computers) can include a combination of one or more hardware components, other embodiments can include computing devices with different combinations of components. It is to be understood that these computing devices can include any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determinations, calculations, or similar operations described herein can be performed by processing circuitry, which can process information by, for example, transforming the obtained information, comparing the obtained information or transformed information to information stored in the network node, and / or executing one or more operations based on the obtained information or transformed information, and making a determination based on a result of the processing. Moreover, while components are depicted as single boxes and / or nested within multiple boxes, in practice, computing devices can include multiple different physical components that make up a single depicted component, and functions can be partitioned between the single components in different ways. For example, a communication interface can be configured to include any of the components described herein, and / or functions of components can be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components can be implemented in software or firmware and computationally intensive functions can be implemented in hardware.
[0263] In certain embodiments, some or all of the functionality described herein can be provided by a processing circuit executing instructions stored in a memory, which in certain embodiments can be a computer program product in the form of a non-transitory computer readable storage medium. In alternative embodiments, some or all of the functionality, for example, can be provided in hard-wired form by a processing circuit without executing instructions stored on a separate or discrete device readable storage medium. In any of these particular embodiments, whether executing instructions stored on a non-transitory computer readable storage medium or not, the processing circuit can be configured to perform the described functions. The benefits provided by such functionality are not limited to a particular implementation or set of components, and can be enjoyed across a broad variety of computing device implementations and wireless network implementations.
[0264] Further embodiments
[0265] Group A embodiments
[0266] A1. A method performed by a user equipment (UE) for fast uplink (UL) access on a L1 / L2 triggered inter-cell mobility (LTM) candidate cell, the method comprising:
[0267] receiving (1502), from a network node, an LTM configuration of at least one LTM candidate cell;
[0268] receiving (1504), from the network node, a trigger; and
[0269] responsive to receiving the trigger, transmitting (1506) an UL signal during an UL resource occasion (e.g., a PRACH occasion) corresponding to the LTM candidate cell with data in the LTM configuration, wherein the UL resource occasion occurs during a time period between receiving the trigger and a first synchronization signal (e.g., SSB) of the LTM candidate cell occurring after receiving the trigger.
[0270] A2. The method of embodiment A1, wherein the trigger comprises at least one of an RRC message, an IE, a field, a parameter, a MAC control element (MAC CE), or a PDCCH order, wherein the trigger corresponds to one or more of:
[0271] 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 a primary SCG cell) instructing the UE to transmit an UL signal (e.g., a PRACH preamble) for the TA establishment / update procedure; and / or
[0272] A trigger for a LTM cell change procedure from a network node in a serving cell (e.g., from a MAC CE of a primary cell or a primary SCG cell), wherein the trigger corresponds to a LTM cell change command, the LTM cell change command indicating a LTM candidate cell (e.g., a LTM configuration ID) for the UE to access.
[0273] A3. The method of any of embodiments A1 or A2, wherein the trigger corresponds to a MAC control element (MAC CE), a downlink control indication (DCI), a layer 1 (L1) signaling, a layer 2 (L2) signaling, a L1 / L2 signaling, and indicates at least one of the configured LTM candidate cells (e.g., a LTM candidate ID or a LTM configuration ID).
[0274] A4. The method of any of embodiments A1 to A3, wherein the UL signal comprises one or more of:
[0275] a PRACH preamble sent to a PRACH occasion of a LTM candidate cell in a LTM cell change;
[0276] a PRACH preamble sent to a PRACH occasion of a LTM candidate cell in a time alignment (TA) establishment / update procedure;
[0277] a sounding reference signal (SRS) sent to a LTM candidate cell in a TA establishment / update procedure;
[0278] control information (e.g., a scheduling request) sent on a physical uplink control channel (PUCCH) of a LTM candidate cell in a LTM cell change procedure; and / or
[0279] UL data (e.g., including an RRC reconfiguration complete as a payload) sent on a physical uplink shared channel (PUSCH) of a LTM candidate cell in a LTM cell change procedure.
[0280] A5. The method of any of embodiments A1 to A4, wherein the UL resource occasion comprises one or more of:
[0281] a PRACH occasion of a LTM candidate cell;
[0282] a sounding reference signal resource or resource occasion of a LTM candidate cell that has been configured (e.g., in an RRC configuration of the LTM candidate cell) and / or assigned (e.g., in a LTM cell change command);
[0283] a physical uplink control channel (PUCCH) resource or resource occasion of the LTM candidate cell that has been configured (e.g., in RRC configuration of the LTM candidate cell) and / or assigned (e.g., in LTM cell handover command); and / or
[0284] a physical uplink shared channel (PUSCH) resource or resource occasion of the LTM candidate cell that has been configured (e.g., in RRC configuration of the LTM candidate cell) and / or assigned (e.g., in LTM cell handover command).
[0285] A6. The method of any of embodiments A1-A5, wherein the UE transmitting the UL signal in the configured UL channel resource in time and frequency before the next synchronization signal (e.g., SSB) of the LTM candidate cell to the LTM candidate cell comprises the UE transmitting the UL signal in the first configured UL channel resource in time and frequency (e.g., first PRACH occasion) after receiving the trigger.
[0286] A7. The method of any of embodiments A1-A6, wherein, prior to receiving the trigger, the UE receives a configuration from the serving cell with one or more LTM candidate cell configurations to apply at the time of receiving the LTM cell handover command.
[0287] A8. The method of any of embodiments A1-A7, wherein, prior to receiving the trigger, the UE receives a configuration for time alignment establishment / update with the LTM candidate cell, wherein the configuration comprises one or more UL related parameters: e.g., PRACH preamble configuration, PRACH occasion, PRACH frequency resource, etc.
[0288] A9. The method of any of embodiments A1-A8, wherein the UE is configured with multiple LTM candidate cells, and when the UE receives the trigger to transmit the UL signal to an LTM candidate cell that does not belong to a first subset of the multiple LTM candidate cells, the UE transmits the UL signal in the configured UL channel resource in time and frequency after the next synchronization signal (e.g., SSB) of the LTM candidate cell to the LTM candidate cell that does not belong to the first subset.
[0289] A10. The method of any of embodiments A1-A9, wherein, prior to receiving the trigger, the UE performs downlink (DL) synchronization (or pre-synchronization) with at least one of the LTM candidate cells, wherein the DL synchronization comprises one or more of:
[0290] i) detecting and / or measuring at least one synchronization signal of the LTM candidate cell, wherein the at least one synchronization signal comprises a SSB of the LTM candidate cell associated with a SSB index and / or identifier and transmitted in a spatial direction (beam), and / or a CSI-RS and / or a TRS and / or a PSS and / or a SSS;
[0291] ii) performing fine time tracking and obtaining full timing information of the LTM candidate cell;
[0292] iii) obtaining time boundaries of time units such as slots, OFDM symbols, subframes and / or radio frames of the given LTM candidate cell; and / or
[0293] iv) synchronizing the clock with the time boundaries of time units such as slots, OFDM symbols, subframes and / or radio frames of the given LTM candidate cell.
[0294] A11. The method of any of the preceding embodiments, further comprising:
[0295] providing user data; and
[0296] forwarding the user data to the host via a transmission to the network node.
[0297] Group B embodiments
[0298] B1. A method performed by a network node for enabling a user equipment, UE, to perform fast uplink (UL) access on a L1 / L2 triggered cell mobility (LTM) candidate cell, the method comprising:
[0299] transmitting (1602), from the network node to the UE, an LTM configuration of at least one LTM candidate cell; and
[0300] transmitting (1604), from the network node to the UE, a trigger.
[0301] B1A. The method of embodiment B1, further comprising, after transmitting the trigger, receiving (1606), from the UE, an UL signal comprising data from the LTM configuration during an UL resource occasion (e.g., a PRACH occasion) corresponding to the LTM candidate cell, wherein the UL resource occasion occurs during a time period between the UE receiving the trigger and a first synchronization signal (e.g., a SSB) of the LTM candidate cell occurring after the UE receiving the trigger.
[0302] B2. The method of embodiment B1 or B1A, wherein the trigger comprises at least one of an RRC message, an IE, a field, a parameter, a MAC control element (MAC CE), or a PDCCH order, wherein the trigger corresponds to one or more of:
[0303] 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 a primary SCG cell) instructing the UE to transmit an UL signal (e.g., a PRACH preamble) for the TA establishment / update procedure; and / or
[0304] a trigger from a network node in a serving cell (e.g., a MAC CE from a primary cell or a primary SCG cell) for an LTM cell switch procedure, wherein the trigger corresponds to an LTM cell switch command instructing an LTM candidate cell (e.g., an LTM configuration ID) for the UE to access.
[0305] B3. The method of any of embodiments B1 or B2, wherein the trigger corresponds to at least one of a MAC control element (MAC CE), a downlink control indication (DCI), layer 1 (L1) signaling, layer 2 (L2) signaling, L1 / L2 signaling, and instructs at least one of a configured LTM candidate cell (e.g., an LTM candidate ID or an LTM configuration ID).
[0306] B4. The method of any of embodiments B1-B3, wherein the UL signal comprises one or more of:
[0307] a PRACH preamble transmitted to a PRACH occasion of an LTM candidate cell in an LTM cell switch;
[0308] a PRACH preamble transmitted to a PRACH occasion of an LTM candidate cell in a time alignment (TA) establishment / update procedure;
[0309] a sounding reference signal (SRS) transmitted to an LTM candidate cell in a TA establishment / update procedure;
[0310] control information (e.g., a scheduling request) transmitted on a physical uplink control channel (PUCCH) of an LTM candidate cell in an LTM cell switch procedure; and / or
[0311] UL data (e.g., including an RRC reconfiguration complete as a payload) transmitted on a physical uplink shared channel (PUSCH) of an LTM candidate cell in an LTM cell switch procedure.
[0312] B5. The method of any of embodiments B1-B4, wherein the UL resource occasion comprises one or more of:
[0313] a PRACH occasion of the LTM candidate cell;
[0314] a sounding reference signal resource or resource occasion of the LTM candidate cell that has been configured (e.g., in RRC configuration of the LTM candidate cell) and / or assigned (e.g., in the LTM cell handover command);
[0315] a physical uplink control channel (PUCCH) resource or resource occasion of the LTM candidate cell that has been configured (e.g., in RRC configuration of the LTM candidate cell) and / or assigned (e.g., in the LTM cell handover command); and / or
[0316] a physical uplink shared channel (PUSCH) resource or resource occasion of the LTM candidate cell that has been configured (e.g., in RRC configuration of the LTM candidate cell) and / or assigned (e.g., in the LTM cell handover command).
[0317] B6. The method of any of embodiments B1-B5, wherein the UE transmitting the UL signal to the LTM candidate cell in the configured UL channel resource in time and frequency before a next synchronization signal (e.g., SSB) of the LTM candidate cell comprises the UE transmitting the UL signal in the first configured UL channel resource in time and frequency (e.g., first PRACH occasion) after receiving the trigger.
[0318] B7. The method of any of embodiments B1-B6, wherein, prior to the UE receiving the trigger, the UE receives a configuration from a network node in the serving cell with one or more LTM candidate cell configurations to apply at the time of receiving the LTM cell handover command.
[0319] B8. The method of any of embodiments B1-B7, wherein, prior to receiving the trigger, the UE receives a configuration with the LTM candidate cell for time alignment establishment / update, wherein the configuration comprises one or more UL related parameters: e.g., PRACH preamble configuration, PRACH occasion, PRACH frequency resource, etc.
[0320] B9. The method of any of embodiments B1-B8, wherein the UE is configured with a plurality of LTM candidate cells, and when the UE receives a trigger to transmit a UL signal to an LTM candidate cell that does not belong to a first subset of the plurality of LTM candidate cells, the UL signal is transmitted in a configured UL channel resource in time and frequency after a next synchronization signal (e.g., SSB) of the LTM candidate cell to the LTM candidate cell that does not belong to the first subset.
[0321] B10. The method of any of embodiments B1-B9, wherein, prior to receiving the trigger, the UE performs downlink (DL) synchronization (or pre-synchronization) with at least one of the LTM candidate cells, wherein the DL synchronization comprises one or more of:
[0322] i) detecting and / or measuring at least one synchronization signal of the LTM candidate cell, wherein the at least one synchronization signal comprises an SSB of the LTM candidate cell that is associated with an SSB index and / or identifier and transmitted in a spatial direction (beam), and / or a CSI-RS and / or TRS and / or PSS and / or SSS;
[0323] ii) performing fine time tracking and obtaining full timing information of the LTM candidate cell;
[0324] iii) obtaining time boundaries of time units such as slots, OFDM symbols, subframes, and / or radio frames of a given LTM candidate cell; and / or
[0325] iv) synchronizing a clock with the time boundaries of time units such as slots, OFDM symbols, subframes, and / or radio frames of a given LTM candidate cell.
[0326] B11. The method of any of the preceding embodiments, further comprising:
[0327] obtaining user data; and
[0328] forwarding the user data to a host or user equipment.
[0329] Group C embodiments
[0330] C1. A user equipment for fast uplink (UL) access on an L1 / L2 triggered cell- inter mobility (LTM) candidate cell, comprising:
[0331] processing circuitry configured to perform any of the steps recited in any of the A-Group embodiments; and
[0332] power supply circuitry configured to supply power to the processing circuitry.
[0333] C2. A network node for fast uplink (UL) access on a L1 / L2 triggered mobility (LTM) candidate cell, the network node comprising:
[0334] processing circuitry configured to perform any of the steps recited in any of the Group B embodiments;
[0335] power supply circuitry configured to supply power to the processing circuitry.
[0336] C3. A user equipment (UE) for fast uplink (UL) access on a L1 / L2 triggered mobility (LTM) candidate cell, the UE comprising:
[0337] an antenna configured to transmit and receive wireless signals;
[0338] radio front end circuitry connected to the antenna and the processing circuitry, and configured to condition signals communicated between the antenna and the processing circuitry;
[0339] processing circuitry configured to perform any of the steps recited in any of the Group A embodiments;
[0340] an input interface connected to the processing circuitry, and configured to allow input of information into the UE to be processed by the processing circuitry;
[0341] an output interface connected to the processing circuitry, and configured to output information from the UE that has been processed by the processing circuitry; and
[0342] a battery connected to the processing circuitry, and configured to supply power to the UE.
[0343] C4. A host configured to operate in a communication system to provide an over-the-top (OTT) service, the host comprising:
[0344] processing circuitry configured to provide user data; and
[0345] a network interface configured to initiate transmission of the user data to a network node in a cellular network for transmission to a user equipment (UE), the network node having a communication interface and processing circuitry, the network node's processing circuitry configured to perform any of the operations recited in any of the Group B embodiments to transmit the user data from the host to the UE.
[0346] C5. The host of the preceding embodiment, wherein:
[0347] the host's processing circuitry is configured to execute a host application that provides the user data; and
[0348] The UE comprises processing circuitry configured to execute a client application associated with a host application to receive a transmission of user data from the host.
[0349] C6. A method implemented in a host configured to operate in a communication system that also includes a network node and a user equipment (UE), the method comprising:
[0350] providing user data for the UE; and
[0351] initiating a transmission to the UE via a cellular network that includes the network node, the transmission carrying the user data, wherein the network node performs any of the operations described in any of the Group B embodiments to send the user data from the host to the UE.
[0352] C7. The method of the preceding embodiment, further comprising, at the network node, sending the user data provided by the host for the UE.
[0353] C8. The method of any of the preceding 2 embodiments, wherein the user data is provided at the host by executing a host application that interacts with a client application executed on the UE, the client application being associated with the host application.
[0354] C9. A communication system configured to provide an over-the-top (OTT) service, the communication system comprising:
[0355] a host comprising:
[0356] processing circuitry configured to provide user data for a user equipment (UE), the user data being associated with the over-the-top service; and
[0357] a network interface configured to initiate a transmission of the user data to a cellular network node for sending to the UE, the network node having a communication interface and processing circuitry configured to perform any of the operations described in any of the Group B embodiments to send the user data from the host to the UE.
[0358] C10. The communication system of the preceding embodiment, further comprising:
[0359] a network node; and / or
[0360] a UE.
[0361] C11. A host configured to operate in a communication system to provide an over-the-top (OTT) service, the host comprising:
[0362] processing circuitry configured to initiate reception of user data; and
[0363] a network interface configured to receive the user data from a network node in a cellular network, the network node having a communication interface and processing circuitry, the network node's processing circuitry configured to perform any of the operations of any of the Group B embodiments to receive the user data from the user equipment (UE) for the host.
[0364] C12. The host of the previous 2 embodiments, wherein:
[0365] the host's processing circuitry is configured to execute a host application that receives the user data; and
[0366] the host application is configured to interact with a client application executing on the UE, the client application associated with the host application.
[0367] C13. The host of any of the previous 2 embodiments, wherein initiating the receiving of the user data comprises requesting the user data.
[0368] C14. A method implemented by a host configured to operate in a communication system that also includes a network node and a user equipment (UE), the method comprising:
[0369] at the host, initiating the receiving of user data from the UE, the user data originating from a transmission that the network node has received from the UE, wherein the network node performs any of the steps of any of the Group B embodiments to receive the user data from the UE for the host.
[0370] C15. The method of the previous embodiment, further comprising, at the network node, sending the received user data to the host.
[0371] C16. A host configured to operate in a communication system to provide an over-the-top (OTT) service, the host comprising:
[0372] processing circuitry configured to provide user data; and
[0373] a network interface configured to initiate a transmission of the user data to a cellular network for sending to a user equipment (UE), wherein the UE includes a communication interface and processing circuitry, the UE's communication interface and processing circuitry configured to perform any of the operations of any of the Group A embodiments to receive the user data from the host.
[0374] C17. The host of the previous embodiment, wherein the cellular network further includes a network node configured to communicate with the UE to send the user data from the host to the UE.
[0375] C18. The host of the previous 2 embodiments, wherein:
[0376] the processing circuitry of the host is configured to execute a host application, thereby providing the user data; and
[0377] the host application is configured to interact with a client application executing on the UE, the client application being associated with the host application.
[0378] C19. A method implemented by a host operating in a communication system, the communication system further including a network node and a user equipment, UE, the method comprising:
[0379] providing user data for the UE; and
[0380] initiating a transmission to the UE via a cellular network including the network node, the transmission carrying the user data, wherein the UE performs any of the operations recited in any of the Group A embodiments to receive the user data from the host.
[0381] C20. The method of the preceding embodiment, further comprising:
[0382] at the host, executing a host application associated with a client application executing on the UE to receive the user data from the host application.
[0383] C21. The method of the preceding embodiment, further comprising:
[0384] at the host, sending input data provided by executing the host application to the client application executing on the UE,
[0385] wherein the user data is provided by the client application in response to the input data from the host application.
[0386] C22. A host configured to operate in a communication system to provide an over-the-top (OTT) service, the host comprising:
[0387] processing circuitry configured to provide user data; and
[0388] a network interface configured to initiate a transmission of the user data to a cellular network for sending to a user equipment (UE), wherein the UE includes a communication interface and processing circuitry, the communication interface and processing circuitry of the UE being configured to perform any of the steps recited in any of the Group A embodiments to send the user data to the host.
[0389] C23. The host of the preceding embodiment, wherein the cellular network further includes a network node configured to communicate with the UE to send the user data from the UE to the host.
[0390] C24. The host of the preceding 2 embodiments, wherein:
[0391] The processing circuitry of the host is configured to execute a host application, thereby providing the user data; and
[0392] The host application is configured to interact with a client application executing on the UE, the client application being associated with the host application.
[0393] C25. A method implemented by a host configured to operate in a communication system, the communication system further including a network node and a user equipment (UE), the method comprising:
[0394] At the host, receiving user data transmitted by the UE to the host via the network node, wherein the UE performs any of the steps recited in any of the A group embodiments to transmit the user data to the host.
[0395] C26. The method of the preceding embodiment, further comprising:
[0396] At the host, executing a host application associated with a client application executing on the UE to receive the user data from the UE.
[0397] C27. The method of the preceding 2 embodiments, further comprising:
[0398] At the host, transmitting input data provided by executing the host application to the client application executing on the UE,
[0399] wherein the user data is provided by the client application in response to the input data from the host application.
[0400] References
[0401] [1] 3GPP TS 38.331 v17.1.0, Radio Resource Control (RRC) Protocol Specification
[0402] [2] 3GPP TS 38.133, v18.0.0, Requirements for support of radio resource management
[0403] [3] 3GPP TS 38.213, v17.4.0, Physical Layer Procedures for Control
[0404] Abbreviations
[0405] At least some of the following abbreviations can be used in the present disclosure. If there is an inconsistency in the use of a term between the above and the following, the above should be preferred. If listed multiple times below, the first listing should be preferred over any subsequent listing.
[0406] 1xRTT: CDMA2000 lx Radio Transmission Technology
[0407] 3GPP: Third Generation Partnership Project
[0408] 5G: Fifth Generation
[0409] 6G: Sixth Generation
[0410] ABS: Almost Blank Subframe
[0411] ARQ: Automatic Repeat reQuest
[0412] AWGN: Additive White Gaussian Noise
[0413] BCCH: Broadcast Control Channel
[0414] BCH: Broadcast Channel
[0415] CA: Carrier Aggregation
[0416] CC: Carrier Component
[0417] CCCH SDU: Common Control Channel SDU
[0418] CDMA: Code Division Multiple Access
[0419] CGI: Cell Global Identifier
[0420] CIR: Channel Impulse Response
[0421] CP: Cyclic Prefix
[0422] CPICH: Common Pilot Channel
[0423] CPICH: Ec / No CPICH received energy per chip divided by power density in the band
[0424] CQI: Channel Quality Information
[0425] C-RNTI: Cell RNTI
[0426] CSI: Channel State Information
[0427] DCCH: Dedicated Control Channel
[0428] DL: Downlink
[0429] DM: Demodulation
[0430] DMRS: Demodulation Reference Signal
[0431] DRX: Discontinuous Reception
[0432] DTX: Discontinuous Transmission
[0433] DTCH: Dedicated Traffic Channel
[0434] DUT: Device Under Test
[0435] E-CID: Enhanced Cell ID (positioning method)
[0436] eMBMS: evolved Multimedia Broadcast / Multicast Service
[0437] E-SMLC: Evolved Serving Mobile Location Center
[0438] ECGI: Evolved CGI
[0439] eNB: E-UTRAN Node B
[0440] ePDCCH: Enhanced Physical Downlink Control Channel
[0441] E-SMLC: Evolved Serving Mobile Location Center
[0442] E-UTRA: Evolved UTRA
[0443] E-UTRAN: Evolved UTRAN
[0444] FDD: Frequency Division Duplex
[0445] FFS: Further Study
[0446] gNB: Base station in NR
[0447] GNSS: Global Navigation Satellite System
[0448] HARQ: Hybrid Automatic Repeat Request
[0449] HO: Handover
[0450] HSPA: High Speed Packet Access
[0451] HRPD: High Rate Packet Data
[0452] LOS: Line of Sight
[0453] LPP: LTE Positioning Protocol
[0454] LTE: Long Term Evolution
[0455] MAC: Medium Access Control
[0456] MAC: Message Authentication Code
[0457] MBSFN: Multimedia Broadcast Multicast Service Single Frequency Network
[0458] MBSFN ABS: MBSFN Almost Blank Subframe
[0459] MDT: Drive Test Minimization
[0460] MIB: Master Information Block
[0461] MME: mobility management entity
[0462] MSC: mobile switching center
[0463] NPDCCH: narrowband physical downlink control channel
[0464] NR: new radio
[0465] OCNG: OFDMA channel noise generator
[0466] OFDM: orthogonal frequency division multiplexing
[0467] OFDMA: orthogonal frequency division multiple access
[0468] OSS: operation support system
[0469] OTDOA: observed time difference of arrival
[0470] O&M: operation and maintenance
[0471] PBCH: physical broadcast channel
[0472] P-CCPCH: primary common control physical channel
[0473] PCell: primary cell
[0474] PCFICH: physical control format indicator channel
[0475] PDCCH: physical downlink control channel
[0476] PDCP: packet data convergence protocol
[0477] PDP: probability delay profile
[0478] PDSCH: physical downlink shared channel
[0479] PGW: packet gateway
[0480] PHICH: physical hybrid ARQ indicator channel
[0481] PLMN: public land mobile network
[0482] PMI: precoding matrix indicator
[0483] PRACH: physical random access channel
[0484] PRS: positioning reference signal
[0485] PSS: primary synchronization signal
[0486] PUCCH: physical uplink control channel
[0487] PUSCH: Physical Uplink Shared Channel
[0488] RACH: Random Access Channel
[0489] QAM: Quadrature Amplitude Modulation
[0490] RAN: Radio Access Network
[0491] RAT: Radio Access Technology
[0492] RLC: Radio Link Control
[0493] RLM: Radio Link Management
[0494] RNC: Radio Network Controller
[0495] RNTI: Radio Network Temporary Identifier
[0496] RRC: Radio Resource Control
[0497] RRM: Radio Resource Management
[0498] RS: Reference Signal
[0499] RSCP: Received Signal Code Power
[0500] RSRP: Reference Symbol Received Power or Reference Signal Received Power
[0501] RSRQ: Reference Signal Received Quality or Reference Symbol Received Quality
[0502] RSSI: Received Signal Strength Indicator
[0503] RSTD: Reference Signal Time Difference
[0504] SCH: Synchronization Channel
[0505] SCell: Secondary Cell
[0506] SDAP: Service Data Adaptation Protocol
[0507] SDU: Service Data Unit
[0508] SFN: System Frame Number
[0509] SGW: Serving Gateway
[0510] SI: System Information
[0511] SIB: System Information Block
[0512] SNR: Signal to Noise Ratio
[0513] SON: Self-Optimizing Network
[0514] SS: Synchronization signal
[0515] SSS: Secondary synchronization signal
[0516] TDD: Time division duplex
[0517] TDOA: Time difference of arrival
[0518] TOA: Time of arrival
[0519] TSS: Tertiary synchronization signal
[0520] TTI: Transmission time interval
[0521] UE: User equipment
[0522] UL: Uplink
[0523] USIM: Universal Subscriber Identity Module
[0524] UTDOA: Uplink time difference of arrival
[0525] WCDMA: Wide CDMA
[0526] WLAN: Wide Local Area Network.
Claims
1. ( UE method A method (1500) for uplink UL access on an L1 / L2 triggered inter-cell mobility LTM candidate cell, performed by a user equipment (UE), the method comprising: Receive (1502) LTM configuration of at least one LTM candidate cell from the network node; Receive trigger (1504) from the network node; Receive the first synchronization signal (1505) from the LTM candidate cell; as well as In response to receiving the trigger, a (1506) UL signal is sent to the LTM candidate cell during a UL resource opportunity, 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, wherein the first synchronization signal is received after receiving the trigger.
2. The method according to claim 1, wherein, The trigger includes at least one of RRC messages, IE, fields, parameters, MAC control elements (MAC CE), or PDCCH commands, wherein the trigger corresponds to one or more of the following: A trigger for the time alignment TA establishment / update procedure, wherein the trigger is received from a network node in the serving cell, instructing the UE to send a UL signal for the TA establishment / update procedure; and / or A trigger from a network node in the serving cell for an LTM cell handover process, wherein the trigger corresponds to an LTM cell handover command that indicates the LTM candidate cell to which the UE wants to access.
3. The method according to any one of claims 1 or 2, wherein, The trigger corresponds to the MAC control element MACCE, downlink control information DCI, layer 1 "L1" signaling, layer 2 "L2" signaling, L1 / L2 signaling, and indicates at least one of the configured LTM candidate cells.
4. The method according to any one of claims 1 to 3, wherein, The UL signal includes one or more of the following: Physical random access channel PRACH preamble transmitted during the PRACH timing of the LTM candidate cell in LTM cell handover; The PRACH preamble sent during the PRACH timing of the LTM candidate cell during TA establishment / update process; The detection reference signal (SRS) sent to the LTM candidate cell during the TA establishment / update process; Control information sent on the Physical Uplink Control Channel (PUCCH) of the LTM candidate cell during LTM cell handover; and / or UL data transmitted on the Physical Uplink Shared Channel (PUSCH) of the LTM candidate cell during LTM cell handover.
5. The method according to any one of claims 1 to 4, wherein, The UL resource timing includes one or more of the following: The PRACH timing for the LTM candidate cells; The already configured and / or assigned detection reference signal resources or resource timings of the LTM candidate cells; The configured and / or assigned Physical Uplink Control Channel (PUCCH) resources or resource timing of the LTM candidate cells; and / or The physical uplink shared channel (PUSCH) resources or resource timings already configured and / or assigned to the LTM candidate cells.
6. The method according to any one of claims 1 to 5, wherein, The UE sending the UL signal to the LTM candidate cell in the configured UL channel resources at the time and frequency before the next synchronization signal of the LTM candidate cell includes: the UE sending the UL signal in the first configured UL channel resources at the time and frequency after receiving the trigger.
7. The method according to any one of claims 1 to 6, wherein, Before receiving the trigger, the UE receives from the serving cell a configuration containing one or more LTM candidate cell configurations to be applied when an LTM cell handover command is received.
8. The method according to any one of claims 1 to 7, wherein, Before receiving the trigger, the UE receives a configuration for establishing / updating time alignment with the LTM candidate cell, wherein the configuration includes one or more UL-related parameters, such as PRACH preamble configuration, PRACH timing, and PRACH frequency resources.
9. The method according to any one of claims 1 to 8, wherein, The UE is configured with multiple LTM candidate cells, and when the UE receives a trigger to send a UL signal to an LTM candidate cell that does not belong to a first subset of the multiple LTM candidate cells, the UE sends the UL signal to the LTM candidate cell that does not belong to the first subset in the configured UL channel resources at the time and frequency following the next synchronization signal of the LTM candidate cell.
10. The method according to any one of claims 1 to 9, wherein, Before receiving the trigger, the UE performs downlink DL synchronization with at least one of the LTM candidate cells, wherein the DL synchronization includes one or more of the following: i) Detect and / or measure at least one synchronization signal of the LTM candidate cell, wherein the at least one synchronization signal includes the SSB, and / or CSI-RS and / or TRS and / or PSS and / or SSS of the LTM candidate cell that are associated with the SSB index and / or identifier and transmitted in the spatial direction. ii) Perform fine-grained time tracking and obtain complete timing information for the LTM candidate cells; iii) Obtain the time boundaries of time units such as time slots, OFDM symbols, subframes, and / or radio frames for a given LTM candidate cell; and / or iv) Synchronize the clock with the time boundaries of time units such as time slots, OFDM symbols, subframes and / or radio frames of a given LTM candidate cell.
11. The method according to any one of claims 1 to 10, further comprising: Provide user data; as well as User data is forwarded to the host via transmission to network nodes.
12. Network node methods A method (1600) for User Equipment (UE) uplink UL access on an L1 / L2-triggered inter-cell mobility LTM candidate cell, executed by a network node, the method comprising: The network node sends (1602) the LTM configuration of at least one LTM candidate cell to the UE; as well as The network node sends a (1604) trigger to the UE.
13. The method of claim 12, further comprising: After sending the trigger During a UL resource timing period corresponding to the LTM candidate cell, the UE receives (1606) a UL signal including data from the LTM configuration, wherein the UL resource timing occurs during a time period between the UE receiving the trigger and receiving a first synchronization signal from the LTM candidate cell, wherein the first synchronization signal is received after the UE receives the trigger.
14. The method according to claim 12 or 13, wherein, The trigger includes at least one of RRC messages, IE, fields, parameters, MAC control elements (MAC CE), or PDCCH commands, wherein the trigger corresponds to one or more of the following: A trigger for the time alignment TA establishment / update procedure, wherein the trigger is received from a network node in the serving cell, instructing the UE to send a UL signal for the TA establishment / update procedure; and / or A trigger received from a network node in the serving cell for the LTM cell handover process, wherein the trigger corresponds to an LTM cell handover command, which indicates the LTM candidate cell to which the UE wants to access.
15. The method according to any one of claims 12 to 14, wherein, The trigger corresponds to the MAC control element MAC CE, downlink control information DCI, layer 1 "L1" signaling, layer 2 "L2" signaling, L1 / L2 signaling, and indicates at least one of the configured LTM candidate cells.
16. The method according to any one of claims 12 to 15, wherein, The UL signal includes one or more of the following: The Physical Random Access Channel (PRACH) preamble transmitted during the PRACH timing of the LTM candidate cell in an LTM cell handover. The PRACH preamble sent during the PRACH timing of the LTM candidate cell during the time alignment TA establishment / update process; The detection reference signal (SRS) sent to the LTM candidate cell during the TA establishment / update process; Control information sent on the Physical Uplink Control Channel (PUCCH) of the LTM candidate cell during LTM cell handover; and / or UL data transmitted on the Physical Uplink Shared Channel (PUSCH) of the LTM candidate cell during LTM cell handover.
17. The method according to any one of claims 12 to 16, wherein, The UL resource timing includes one or more of the following: The PRACH timing for the LTM candidate cells; The already configured detection reference signal resources or resource timings of the LTM candidate cells; The configured and / or assigned Physical Uplink Control Channel (PUCCH) resources or resource timing of the LTM candidate cells; and / or The physical uplink shared channel (PUSCH) resources or resource timings already configured and / or assigned to the LTM candidate cells.
18. The method according to any one of claims 12 to 17, wherein, The UE sending the UL signal to the LTM candidate cell in the configured UL channel resources at the time and frequency before the next synchronization signal of the LTM candidate cell includes: the UE sending the UL signal in the first configured UL channel resources at the time and frequency after receiving the trigger.
19. The method according to any one of claims 12 to 18, wherein, Before the UE receives the 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 handover command is received.
20. The method according to any one of claims 12 to 19, wherein, Before receiving the trigger, the UE receives a configuration for establishing / updating time alignment with the LTM candidate cell, wherein the configuration includes one or more UL-related parameters, such as PRACH preamble configuration, PRACH timing, and PRACH frequency resources.
21. The method according to any one of claims 12 to 20, wherein, The UE is configured with multiple LTM candidate cells, and when the UE receives a trigger to send a UL signal to an LTM candidate cell that does not belong to a first subset of the multiple LTM candidate cells, the UE sends the UL signal to the LTM candidate cell that does not belong to the first subset in the configured UL channel resources at the time and frequency following the next synchronization signal of the LTM candidate cell.
22. The method according to any one of claims 12 to 21, wherein, Before receiving the trigger, the UE performs downlink DL synchronization with at least one of the LTM candidate cells, wherein the DL synchronization includes one or more of the following: i) Detect and / or measure at least one synchronization signal of the LTM candidate cell, wherein the at least one synchronization signal includes the SSB, and / or CSI-RS and / or TRS and / or PSS and / or SSS of the LTM candidate cell that are associated with the SSB index and / or identifier and transmitted in the spatial direction (beam). ii) Perform fine-grained time tracking and obtain complete timing information for the LTM candidate cells; iii) Obtain the time boundaries of time units such as time slots, OFDM symbols, subframes, and / or radio frames for a given LTM candidate cell; and / or iv) Synchronize the clock with the time boundaries of time units such as time slots, OFDM symbols, subframes and / or radio frames of a given LTM candidate cell.
23. The method according to any one of claims 12 to 22, further comprising: Obtain user data; as well as Forward the user data to the host or user equipment. twenty four.( UE A user equipment for uplink UL access on L1 / L2 triggered inter-cell mobility LTM candidate cells, comprising: The processing circuitry is configured to perform any of the steps claimed in any one of claims 1 to 11; as well as A power supply circuit is configured to supply power to the processing circuit.
25. Network Nodes A network node for uplink UL access on L1 / L2 triggered inter-cell mobility LTM candidate cells, the network node comprising: The processing circuitry is configured to perform any of the steps claimed in any one of claims 12 to 23; as well as A power supply circuit is configured to supply power to the processing circuit.