Method and apparatus for random access reporting in wireless communication system

Abstract

Methods, systems, and devices for handling random access reports in a wireless communication system are provided, wherein the method of a user equipment comprises: receiving a first physical downlink control channel command; in response to receiving the first physical downlink control channel command, initiating a first random access procedure to the candidate cell for early timing advance acquisition; storing first random access information associated with the first random access procedure; and reporting the first random access information to the network in response to a request from the network.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to and the benefit of U.S. Provisional Patent Application No. 63 / 529,648 filed on July 28, 2023 and U.S. Provisional Patent Application No. 63 / 536,655 filed on September 5, 2023; each of the cited applications and disclosures are incorporated herein by reference in their entirety. Technical Field

[0003] The present disclosure relates generally to wireless communication networks, and more particularly, to methods and apparatus for handling random access reports in a wireless communication system. Background Art

[0004] With the rapid growth of the demand for transmitting large amounts of data to and from mobile communication devices, traditional mobile voice communication networks have evolved into networks with Internet Protocol (IP) data packet communications, which can provide IP-bearing voice, multimedia, multicast and on-demand communication services to users of mobile communication devices.

[0005] An exemplary network structure is an Evolved Universal Terrestrial Radio Access Network (E-UTRAN). The E-UTRAN system can provide high data throughput to enable the above-mentioned IP-borne voice and multimedia services. Currently, the 3GPP standards organization is discussing new next-generation (e.g., 5G) radio technologies. Therefore, changes to the current body of 3GPP standards are currently being submitted and considered to evolve and complete the 3GPP standards. Summary of the invention

[0006] The present invention provides a method, system and apparatus for handling random access reports in a wireless communication system. Embodiments provide reports of random access procedures for candidate cells associated with L1 / L2 triggered mobility (LTM) and / or reports of random access procedures for cells associated with inter-cell multiple transmission / reception points (TRP).

[0007] In various embodiments, a method of a user equipment (UE) includes: receiving a first physical downlink control channel (PDCCH) command; in response to receiving the first PDCCH command, initiating a first random access (RA) procedure to a candidate cell for early timing advance (TA) acquisition; storing first RA information associated with the first RA procedure; and reporting the first RA information to the network in response to a request from the network. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1The drawings show a wireless communication system according to an embodiment of the present invention.

[0009] Figure 2 is a block diagram of a transmitter system (also referred to as an access network) and a receiver system (also referred to as a user equipment or UE) according to an embodiment of the present invention.

[0010] Figure 3 is a functional block diagram of a communication system according to an embodiment of the present invention.

[0011] Figure 4 According to an embodiment of the present invention Figure 3 Functional block diagram of the program code.

[0012] Figure 5 It is in 3GPP 38.321v17.4.0 Figure 6 .1.3.4-1: Reappearance of the Timing Advance Command MAC CE.

[0013] Figure 6 This is a reproduction of Figure x in R2-2213332 38.300: Signaling procedure for LTM.

[0014] Figure 7 It is in 3GPP 38.211v17.1.0 Figure 4 .3.1-1: Reproduction of uplink-downlink timing relationship.

[0015] Figure 8 2 is an exemplary figure according to an embodiment of the present invention, showing that for RACH-based LTM, a UE initiates / performs a random access procedure to a target cell in an LTM procedure.

[0016] Fig. 9 2 is an exemplary figure according to an embodiment of the present invention, showing that the type of the random access procedure may be a (LTM) random access procedure initiated by a UE for a candidate cell.

[0017] Fig.10 It is a flowchart of a method of a UE according to an embodiment of the present invention, comprising: initiating an RA procedure to a candidate cell, and in response to the completion of the RA procedure, determining whether to include or how to set the value of a parameter in the RA information based at least on the type of the RA procedure.

[0018] Fig.11 It is a flowchart of a method of a UE according to an embodiment of the present invention, comprising: initiating an RA procedure to a non-serving cell, and in response to the completion of the RA procedure, determining whether to include or how to set the value of a parameter in the RA information based at least on the type of the RA procedure.

[0019] Fig.12It is a flowchart of a method of a UE according to an embodiment of the present invention, comprising: receiving a first PDCCH command; in response to receiving the first PDCCH command, initiating a first RA procedure to a candidate cell for early TA acquisition; storing first RA information associated with the first RA procedure; and reporting the first RA information to the network in response to a request from the network. DETAILED DESCRIPTION

[0020] The present invention described herein may be applied to or implemented in the exemplary wireless communication systems and devices described below. In addition, the present invention is primarily described in the context of the 3GPP architecture reference model. However, it should be understood that with the disclosed information, those skilled in the art can easily make adjustments to use and implement aspects of the present invention in the 3GPP2 network architecture as well as other network architectures.

[0021] The exemplary wireless communication systems and devices described below employ wireless communication systems that support broadcast services. Wireless communication systems are widely deployed to provide various types of communications, such as voice, data, etc. These systems can be based on code division multiple access (CDMA), time division multiple access (TDMA), orthogonal frequency division multiple access (OFDMA), 3GPP Long Term Evolution (LTE) wireless access, 3GPP Long Term Evolution Advanced (LTE-A) wireless access, 3GPP2 Ultra Mobile Broadband (UMB), WiMax, 3GPP New Radio (NR), or some other modulation technology.

[0022] Specifically, the exemplary wireless communication system apparatus described below may be designed to support one or more standards, such as standards provided by an association named "3rd Generation Partnership Project" (referred to herein as 3GPP), including: [1] 3GPP 38.321v17.4.0; [2] 3GPP 38.331v17.4.0; [3] RP-212710 New WID for NR Further Mobility Enhancement; [4] R2-2213332 38.300 Operational CR for Introducing NR Further Mobility Enhancement; [5] 3GPP RAN1#110b report; [6] 3GPP RAN1#112 report; [7] 3GPP RAN2#121bis report; [8] 3GPP RAN2#122 report; [9] RP-223276 WID update: MIMO evolution for downlink and uplink;

[10] 3GPP38.211v17.1.0; and

[11] R2-2308972 report on NR MIMO evolution session. The standards and documents listed above are expressly and completely incorporated herein by reference in their entirety.

[0023] Figure 1 A multiple access wireless communication system according to an embodiment of the present invention is shown. An access network 100 (AN) includes multiple antenna groups, one antenna group includes 104 and 106, another antenna group includes 108 and 110, and another antenna group includes 112 and 114. Figure 1 , only two antennas are shown for each antenna group, but each antenna group may utilize more or fewer antennas. Access terminal (AT) 116 communicates with antennas 112 and 114, where antennas 112 and 114 transmit information to access terminal 116 via forward link 120 and receive information from AT 116 via reverse link 118. AT 122 communicates with antennas 106 and 108, where antennas 106 and 108 transmit information to AT 122 via forward link 126 and receive information from AT 122 via reverse link 124. In an FDD system, communication links 118, 120, 124, and 126 may use different frequencies for communication. For example, forward link 120 may use a different frequency than the frequency used by reverse link 118.

[0024] Each antenna group and / or the area in which they are designed to communicate is often referred to as a sector of the access network. In an embodiment, the antenna groups are each designed to communicate with access terminals in a sector of the area covered by the access network 100.

[0025] In communicating via forward links 120 and 126, the transmit antennas of access network 100 may utilize beamforming in order to improve the signal-to-noise ratio of the forward links for the different access terminals 116 and 122. Also, an access network that uses beamforming to transmit to access terminals that are randomly dispersed throughout the coverage area of ​​the access network will generally cause less interference to access terminals in neighboring cells than an access network that transmits to all of its access terminals via a single antenna.

[0026] AN can be a fixed station or base station for communicating with a terminal, and can also be referred to as an access point, Node B, base station, enhanced base station, eNodeB, or some other term. AT can also be referred to as user equipment (UE), a wireless communication device, a terminal, an access terminal, or some other term.

[0027] Figure 2 2 is a simplified block diagram of an embodiment of a transmitter system 210 (also referred to as an access network) and a receiver system 250 (also referred to as an access terminal (AT) or user equipment (UE)) in a MIMO system 200. At the transmitter system 210, traffic data for a number of data streams is provided from a data source 212 to a transmit (TX) data processor 214.

[0028] In one embodiment, each data stream is transmitted via a respective transmit antenna.TX data processor 214 formats, codes, and interleaves the traffic data for each data stream based on a particular coding scheme selected for that data stream to provide coded data.

[0029] The coded data for each data stream may be multiplexed with pilot data using OFDM techniques. The pilot data is typically a known data pattern that is processed in a known manner and may be used at the receiver system to estimate the channel response. The multiplexed pilot and coded data for each data stream are then modulated (e.g., symbol mapped) based on a particular modulation scheme (e.g., BPSK, QPSK, M-PSK, or M-QAM) selected for that data stream to provide modulation symbols. The data rate, coding, and modulation for each data stream may be determined by instructions executed by the processor 230. The memory 232 is coupled to the processor 230.

[0030] The modulation symbols for all data streams are then provided to a TX MIMO processor 220, which may further process the modulation symbols (e.g., for OFDM). The TX MIMO processor 220 then converts the N T The modulation symbol stream is provided to N Ttransmitters (TMTR) 222a through 222t. In certain embodiments, TX MIMO processor 220 applies beamforming weights to the symbols of the data streams and to the antenna from which the symbol is being transmitted.

[0031] Each transmitter 222 receives and processes a respective symbol stream to provide one or more analog signals, and further conditions (eg, amplifies, filters, and upconverts) the analog signals to provide a modulated signal suitable for transmission via the MIMO channel. T The antennas 224a to 224t transmit the N signals from the transmitters 222a to 222t. T a modulated signal.

[0032] At the receiver system 250, N R The transmitted modulated signals are received by each antenna 252a through 252r and the received signal from each antenna 252 is provided to a respective receiver (RCVR) 254a through 254r. Each receiver 254 conditions (e.g., filters, amplifies, and downconverts) a respective received signal, digitizes the conditioned signal to provide samples, and further processes the samples to provide a corresponding "received" symbol stream.

[0033] RX data processor 260 then extracts the N R The receiver 254 receives and processes N R receive symbol streams to provide N T The RX data processor 260 then demodulates, deinterleaves, and decodes each detected symbol stream to recover the traffic data for the data stream. The processing by the RX processor 260 is complementary to that performed by the TX MIMO processor 220 and the TX data processor 214 at the transmitter system 210.

[0034] Processor 270 periodically determines which pre-coding matrix to use (discussed below). Processor 270 formulates a reverse link message comprising a matrix index portion and a rank value portion.

[0035] The reverse link message may include various types of information related to the communication link and / or the received data stream. The reverse link message is then processed by the TX data processor 238 (which also receives traffic data for a number of data streams from the data source 236), modulated by the modulator 280, conditioned by the transmitters 254a to 254r, and transmitted back to the transmitter system 210.

[0036] At the transmitter system 210, the modulated signal from the receiver system 250 is received by the antenna 224, conditioned by the receiver 222, demodulated by the demodulator 240, and processed by the RX data processor 242 to extract the reverse link message transmitted by the receiver system 250. The processor 230 then determines which precoding matrix to use to determine the beamforming weights and then processes the extracted message.

[0037] The memory 232 may be used to temporarily store some buffer / calculated data from 240 or 242 through the processor 230, store some buffer data from 212, or store some specific program codes. Also, the memory 272 may be used to temporarily store some buffer / calculated data from 260 through the processor 270, store some buffer data from 236, or store some specific program codes.

[0038] Steering Figure 3 , this figure shows an alternative simplified functional block diagram of a communication device according to one embodiment of the present invention. Figure 3 As shown in FIG. , the communication device 300 in the wireless communication system can be used to implement Figure 1 UE (or AT) 116 and 122 in, and the wireless communication system is preferably an NR system. The communication device 300 may include an input device 302, an output device 304, a control circuit 306, a central processing unit (CPU) 308, a memory 310, a program code 312, and a transceiver 314. The control circuit 306 executes the program code 312 in the memory 310 through the CPU 308, thereby controlling the operation of the communication device 300. The communication device 300 can receive a signal input by a user through the input device 302 (for example, a keyboard or a keypad), and can output images and sounds through the output device 304 (for example, a display or a speaker). The transceiver 314 is used to receive and transmit wireless signals to pass the received signal to the control circuit 306 and wirelessly output the signal generated by the control circuit 306.

[0039] Figure 4 According to one embodiment of the present invention, Figure 3 4. In this embodiment, program code 312 includes application layer 400, layer 3 portion 402, and layer 2 portion 404, and is coupled to layer 1 portion 406. Layer 3 portion 402 generally performs radio resource control. Layer 2 portion 404 generally performs link control. Layer 1 portion 406 generally performs physical connectivity.

[0040] For LTE, LTE-A or NR systems, the layer 2 portion 404 may include a radio link control (RLC) layer and a medium access control (MAC) layer. The layer 3 portion 402 may include a radio resource control (RRC) layer.

[0041] Any two or more of the following paragraphs, (sub) bullet points, points, actions or claims described in each invention paragraph or section may be logically, reasonably and appropriately combined to form a specific method.

[0042] Any sentence, paragraph, (sub) bullet point, key point, action or claim described in each invention paragraph or section below can be implemented independently and individually to form a specific method or device. The dependency in the following invention disclosure (e.g., "based on", "more specifically", "example", etc.) is only a possible embodiment that does not limit a specific method or device.

[0043] In 38.321 ([1] 3GPP 38.321v17.4.0), the random access procedure and TA maintenance are introduced:

[0044] 5.1 Random Access Procedure

[0045] 5.1.1 Random Access Procedure Initialization

[0046] According to TS 38.300 [2], the random access procedure described in this clause is initiated by a PDCCH command, the MAC entity itself, or an RRC event. In the MAC entity, there is only one ongoing random access procedure at any point in time. The random access procedure on the SCell will only be initiated by a PDCCH command where the ra-PreambleIndex is different from 0b000000.

[0047] […]

[0048] When initiating a random access procedure, the UE selects a set of random access resources as specified in clause 5.1.1b and initializes the following parameters for the random access procedure according to the values ​​configured by the RRC for the selected set of random access resources:

[0049] -prach-ConfigurationIndex: A set of PRACH opportunities that can be used for random access preamble transmission of Msg1. If PRACH opportunities are shared between 2-step and 4-step RA types, then these also apply to MSGA PRACH;

[0050] -prach-ConfigurationPeriodScaling-IAB: A scaling factor defined in TS 38.211 [8] and applicable to IAB-MT, which extends the periodicity of the PRACH opportunity baseline configuration indicated by prach-ConfigurationIndex;

[0051] -prach-ConfigurationFrameOffset-IAB: A frame offset defined in TS 38.211 [8] and applicable to the IAB-MT, which changes the RO frame defined in the baseline configuration indicated by prach-ConfigurationIndex;

[0052] -prach-ConfigurationSOffset-IAB: a subframe / timeslot offset defined in TS 38.211 [8] and applicable to IAB-MT, which changes the RO subframe or time slot defined in the baseline configuration indicated by prach-ConfigurationIndex;

[0053] -msgA-PRACH-ConfigurationIndex: a set of available PRACH opportunities for transmitting the random access preamble of MSGA in a 2-step RA type;

[0054] -preambleReceivedTargetPower: initial random access preamble power for 4-step RA type;

[0055] -msgA-PreambleReceivedTargetPower: initial random access preamble power for 2-step RA type;

[0056] -rsrp-ThresholdSSB: RSRP threshold used to select SSB for 4-step RA type. If the random access procedure is initiated for beam failure recovery, the rsrp-ThresholdSSB used to select SSB in candidateBeamRSList refers to the rsrp-ThresholdSSB in BeamFailureRecoveryConfig IE;

[0057] -rsrp-ThresholdCSI-RS: RSRP threshold used to select CSI-RS for 4-step RA type. If the random access procedure is initiated for beam failure recovery, then rsrp-ThresholdCSI-RS is equal to rsrp-ThresholdSSB in BeamFailureRecoveryConfig IE;

[0058] -msgA-RSRP-ThresholdSSB: RSRP threshold for selecting SSB for 2-step RA type;

[0059] -rsrp-ThresholdSSB-SUL: RSRP threshold for selecting between NUL carrier and SUL carrier;

[0060] -msgA-RSRP-Threshold: RSRP threshold used to select between 2-step RA type and 4-step RA type when both 2-step and 4-step RA type random access resources are configured in the UL BWP;

[0061] -rsrp-ThresholdMsg3: RSRP threshold for MSG3 repetition (see clause 5.1.1b);

[0062] -featurePriorities: the priority of the feature, such as RedCap, NSAG, etc. (see clause 5.1.1d);

[0063] -msgA-TransMax: Maximum number of MSGA transmissions when 4-step and 2-step RA type random access resources are configured;

[0064] - candidateBeamRSList: a list of reference signals (CSI-RS and / or SSB) identifying candidate beams for recovery and associated random access parameters;

[0065] -recoverySearchSpaceId: the search space identity used to listen for responses to beam failure recovery requests;

[0066] -powerRampingStep: power ramping factor;

[0067] -msgA-PreamblePowerRampingStep: power ramp factor for MSGA preamble;

[0068] -powerRampingStepHighPriority: power ramping factor in case of prioritized random access procedure;

[0069] -scalingFactorBI: scaling factor for prioritized random access procedures;

[0070] -ra-PreambleIndex: random access preamble;

[0071] -ra-ssb-OccasionMaskIndex: defines the PRACH occasions associated with the SSB where the MAC entity may transmit the random access preamble (see clause 7.4);

[0072] -msgA-SSB-SharedRO-MaskIndex: indicates the subset of 4-step RA type PRACH opportunities shared with 2-step RA type PRACH opportunities for each SSB. If 2-step RA type PRACH opportunities are shared with 4-step RA type PRACH opportunities and msgA-SSB-SharedRO-MaskIndex is not configured, then all 4-step RA type PRACH opportunities are available for 2-step RA type (see clause 7.4);

[0073] -ra-OccasionList: defines the PRACH occasions associated with the CSI-RS, where the MAC entity can transmit the random access preamble;

[0074] -ra-PreambleStartIndex: the starting index of the random access preamble for on-demand SI request;

[0075] -startPreambleForThisPartition: the first preamble associated with a set of random access resources applicable for a random access procedure;

[0076] -preambleTransMax: Maximum number of random access preamble transmissions;

[0077] -ssb-perRACH-OccasionAndCB-PreamblesPerSSB: defines the number of SSBs mapped to each PRACH opportunity of 4-step RA type and the number of contention-based random access preambles mapped to each SSB;

[0078] -msgA-CB-PreamblesPerSSB-PerSharedRO: defines the number of contention-based random access preambles of 2-step RA type mapped to each SSB when PRACH opportunities are shared between 2-step and 4-step RA types;

[0079] -msgA-SSB-PerRACH-OccasionAndCB-PreamblesPerSSB: defines the number of SSBs per PRACH opportunity mapped to a 2-step RA type and the number of contention-based random access preambles mapped to each SSB;

[0080] - numberOfPreamblesForThisPartition: the number of consecutive preambles associated with a set of random access resources applicable for the random access procedure;

[0081] -msgA-PUSCH-ResourceGroupA: defines the MSGAPUSCH resources that the UE will use when performing MSG A transmission using random access preamble group A;

[0082] -msgA-PUSCH-ResourceGroupB: defines the MSGAPUSCH resources that the UE will use when performing MSG A transmission using random access preamble group B;

[0083] -msgA-PUSCH-Resource-Index: identifies the index of the PUSCH resource used for MSGA in case of contention-free random access of 2-step RA type;

[0084] […]

[0085] - The set of random access preambles and / or PRACH opportunities used for SI request (if any);

[0086] - A set of random access preambles and / or PRACH opportunities (if any) for beam failure recovery request;

[0087] - A set of random access preambles and / or PRACH opportunities (if any) for synchronization reconfiguration;

[0088] -ra-ResponseWindow: The time window for monitoring RA responses (SpCell only);

[0089] -ra-ContentionResolutionTimer: Contention resolution timer (SpCell only);

[0090] -msgB-ResponseWindow: Time window for listening to RA responses of 2-step RA type (SpCell only).

[0091] […]

[0092] When a random access procedure is initiated on a serving cell, the MAC entity shall:

[0093] 1> Clear the Msg3 buffer;

[0094] 1> Clear the MSGA buffer;

[0095] 1> Set PREAMBLE_TRANSMISSION_COUNTER to 1;

[0096] 1> Set PREAMBLE_POWER_RAMPING_COUNTER to 1;

[0097] 1> Set PREAMBLE_BACKOFF to 0ms;

[0098] 1>Set POWER_OFFSET_2STEP_RA to 0dB;

[0099] 1> If the carrier to be used for the random access procedure is explicitly transmitted:

[0100] 2> Select the transmitted carrier to perform the random access procedure;

[0101] 2> Set PCMAX to the P value of the transmitted carrier. CMAX，f，c .

[0102] 1> Otherwise, if the carrier to be used for the random access procedure is not explicitly signaled; and

[0103] 1> if the serving cell for the random access procedure is configured to use the supplementary uplink as specified in TS 38.331 [5]; and

[0104] 1> If the RSRP referenced by the downlink path loss is less than rsrp-ThresholdSSB-SUL:

[0105] 2> Select the SUL carrier to perform the random access procedure;

[0106] 2> Set PCMAX to the P value of SUL carrier. CMAX，f，c .

[0107] 1> Otherwise:

[0108] 2> Select NUL carrier to perform random access procedure;

[0109] 2> Set PCMAX to the P of NUL carrier CMAX，f，c .

[0110] 1>Perform the BWP operation as specified in clause 5.15;

[0111] 1> According to clause 5.1.1b, select a set of random access resources applicable to the current random access procedure;

[0112] 1> if the random access procedure is initiated by a PDCCH command and if the ra-PreambleIndex explicitly provided by the PDCCH is not 0b000000; or

[0113] 1> if a random access procedure is initiated for an SI request (as specified in TS 38.331 [5]) and the random access resources for the SI request have been explicitly provided by RRC; or

[0114] 1> if a Random Access procedure is initiated for Beam Failure Recovery (as specified in clause 5.17) and if contention-free Random Access resources for a Beam Failure Recovery request of type 4-step RA have been explicitly provided by the RRC for the BWP selected for the Random Access procedure; or

[0115] 1> If the random access procedure is initiated for synchronous reconfiguration and if contention-free random access resources for 4-step RA type have been explicitly provided in rach-ConfigDedicated for the BWP selected for the random access procedure:

[0116] 2>Set RA_TYPE to 4-stepRA.

[0117] 1> Otherwise if the BWP selected for the random access procedure is configured to use 2-step and 4-step RA type random access resources within the selected set of random access resources (as specified in clause 5.1.1b) and the RSRP referenced by the downlink path loss is higher than msgA-RSRP-Threshold; or

[0118] 1> if the BWP selected for the random access procedure is configured to use only 2-step RA type random access resources within the selected set of random access resources according to clause 5.1.1b; or

[0119] 1> If the random access procedure is initiated for synchronous reconfiguration and if contention-free random access resources for 2-step RA type have been explicitly provided in rach-ConfigDedicated for the BWP selected for the random access procedure:

[0120] 2> Set RA_TYPE to 2-stepRA.

[0121] 1> Otherwise:

[0122] 2>Set RA_TYPE to 4-stepRA.

[0123] 1> Perform initialization of variables specific to the random access type as specified in clause 5.1.1a;

[0124] 1> If RA_TYPE is set to 2-stepRA:

[0125] 2> Perform the random access resource selection procedure for 2-step RA type (see clause 5.1.2a).

[0126] 1> Otherwise:

[0127] 2> Perform random access resource selection procedure (see clause 5.1.2).

[0128] 5.1.2 Random Access Resource Selection

[0129] If the selected RA_TYPE is set to 4-stepRA, the MAC entity shall:

[0130] 1> If a random access procedure is initiated for SpCell beam failure recovery (as specified in clause 5.17); and

[0131] 1> if beamFailureRecoveryTimer (Section 5.17) is running or not configured; and

[0132] 1> if contention-free random access resources for beam failure recovery request associated with any of the SSB and / or CSI-RS have been explicitly provided by RRC; and

[0133] 1> If at least one of an SSB with an SS-RSRP higher than rsrp-ThresholdSSB among the SSBs in candidateBeamRSList or a CSI-RS with a CSI-RSRP higher than rsrp-ThresholdCSI-RS among the CSI-RSs in candidateBeamRSList is available:

[0134] 2> Select an SSB with an SS-RSRP higher than rsrp-ThresholdSSB among the SSBs in candidateBeamRSList or a CSI-RS with a CSI-RSRP higher than rsrp-ThresholdCSI-RS among the CSI-RSs in candidateBeamRSList;

[0135] 2> If CSI-RS is selected and there is no ra-PreambleIndex associated with the selected CSI-RS:

[0136] 3> Set PREAMBLE_INDEX to the ra-PreambleIndex corresponding to the SSB in candidateBeamRSList that is quasi-co-located with the selected CSI-RS as specified in TS 38.214 [7].

[0137] 2> Otherwise:

[0138] 3> Set PREAMBLE_INDEX to the ra-PreambleIndex corresponding to the SSB or CSI-RS selected from a set of random access preambles for beam failure recovery request.

[0139] 1> Otherwise, if ra-PreambleIndex has been explicitly provided by PDCCH; and

[0140] 1> If ra-PreambleIndex is not 0b000000:

[0141] 2> Set PREAMBLE_INDEX to the transmitted ra-PreambleIndex;

[0142] 2> Select the SSB transmitted by PDCCH.

[0143] 1> Otherwise, if the contention-free random access resource associated with the SSB has been explicitly provided in rach-ConfigDedicated and at least one SSB among the associated SSBs with an SS-RSRP higher than rsrp-ThresholdSSB is available:

[0144] 2> Select the SSB with SS-RSRP higher than rsrp-ThresholdSSB among the associated SSBs;

[0145] 2> Set PREAMBLE_INDEX to the ra-PreambleIndex corresponding to the selected SSB.

[0146] 1> Otherwise, if the contention-free random access resource associated with the CSI-RS has been explicitly provided in rach-ConfigDedicated, and at least one CSI-RS among the associated CSI-RSs with a CSI-RSRP higher than rsrp-ThresholdCSI-RS is available:

[0147] 2> Select a CSI-RS with a CSI-RSRP higher than rsrp-ThresholdCSI-RS among the associated CSI-RS;

[0148] 2> Set PREAMBLE_INDEX to the ra-PreambleIndex corresponding to the selected CSI-RS.

[0149] 1> Otherwise, if a random access procedure is initiated for an SI request (as specified in TS 38.331 [5]); and

[0150] 1> If the random access resources for the SI request have been explicitly provided by RRC:

[0151] 2> If at least one of the SSBs with SS-RSRP higher than rsrp-ThresholdSSB is available:

[0152] 3> Select an SSB with SS-RSRP higher than rsrp-ThresholdSSB.

[0153] 2> Otherwise:

[0154] 3>Select Any SSB.

[0155] 2> Select the random access preamble corresponding to the selected SSB from the random access preambles determined according to ra-PreambleStartIndex as specified in TS 38.331 [5];

[0156] 2> Set PREAMBLE_INDEX to the selected random access preamble.

[0157] 1> Otherwise (i.e., for contention-based random access preamble selection):

[0158] 2> If at least one of the SSBs with SS-RSRP higher than rsrp-ThresholdSSB is available:

[0159] 3> Select an SSB with SS-RSRP higher than rsrp-ThresholdSSB.

[0160] 2> Otherwise:

[0161] 3>Select Any SSB.

[0162] 2> If RA_TYPE is switched from 2-stepRA to 4-stepRA:

[0163] 3> If the random access preamble group is selected during the current random access procedure:

[0164] 4> Select the same random access preamble group as selected for the 2-step RA type.

[0165] 3> Otherwise:

[0166] 4> If random access preamble group B is configured; and

[0167] 4> If the transport block size of the MSGA payload configured in rach-ConfigDedicated corresponds to the transport block size of the MSGA payload associated with random access preamble group B:

[0168] 5> Select random access preamble group B.

[0169] 4> Otherwise:

[0170] 5> Select random access preamble group A.

[0171] 2> Otherwise, if the Msg3 buffer is empty:

[0172] 3> If random access preamble group B is configured:

[0173] 4> If the potential Msg3 size (e.g., UL data available for transmission plus MAC subheader and MAC CE if necessary) is greater than ra-Msg3SizeGroupA and the path loss is less than PCMAX-preambleReceivedTargetPower-msg3-DeltaPreamble-messagePowerOffsetGroupB (of the serving cell performing the random access procedure); or

[0174] 4> If a random access procedure is initiated for the CCCH logical channel and the CCCH SDU size plus the MAC subheader is greater than ra-Msg3SizeGroupA:

[0175] 5> Select random access preamble group B.

[0176] 4> Otherwise:

[0177] 5> Select random access preamble group A.

[0178] 3> Otherwise:

[0179] 4> Select random access preamble group A.

[0180] 2> Otherwise (i.e., Msg3 is retransmitted):

[0181] 3> Select a random access preamble group that is the same as the group used for the random access preamble transmission attempt corresponding to the first transmission of Msg3.

[0182] 2> randomly select a random access preamble from the random access preambles associated with the selected SSB and the selected random access preamble group with equal probability;

[0183] 2> Set PREAMBLE_INDEX to the selected random access preamble.

[0184] 1> if a random access procedure is initiated for an SI request (as specified in TS 38.331 [5]); and

[0185] 1> If ra-AssociationPeriodIndex and si-RequestPeriod are configured:

[0186] 2> Determine the next available PRACH opportunity from the PRACH opportunity corresponding to the selected SSB in the association period given by ra-AssociationPeriodIndex in si-RequestPeriod permitted by the restrictions given by ra-ssb-OccasionMaskIndex (if configured) (the MAC entity shall randomly select the PRACH opportunity among consecutive PRACH opportunities with equal probability according to clause 8.1 of TS 38.213 [6] corresponding to the selected SSB).

[0187] 1> Otherwise, if SSB is selected as above:

[0188] 2> Determine the next available PRACH opportunity from the PRACH opportunities, corresponding to the selected SSB given by ra-ssb-OccasionMaskIndex (if configured) or ssb-SharedRO-MaskIndex (if configured) or permitted by the restrictions indicated by the PDCCH (according to clause 8.1 of TS 38.213 [6], the MAC entity shall randomly select a PRACH opportunity among consecutive PRACH opportunities with equal probability, regardless of the FR2 UL gap corresponding to the selected SSB; the MAC entity may take into account the possible occurrence of measurement gaps and MUSIM gaps when determining the next available PRACH opportunity corresponding to the selected SSB).

[0189] 1> Otherwise, if CSI-RS is selected as above:

[0190] 2> If there is no contention-free random access resource associated with the selected CSI-RS:

[0191] 3> Determine the next available PRACH opportunity from the PRACH opportunities, permitted by the restrictions given by ra-ssb-OccasionMaskIndex (if configured) and corresponding to the SSB in candidateBeamRSList that is quasi-co-located with the selected CSI-RS as specified in TS 38.214[7] (according to clause 8.1 of TS 38.213[6], the MAC entity shall randomly select a PRACH opportunity among consecutive PRACH opportunities with equal probability, regardless of the FR2 UL gap corresponding to the SSB that is quasi-co-located with the selected CSI-RS; the MAC entity may take into account the possible occurrence of measurement gaps and MUSIM gaps when determining the next available PRACH opportunity corresponding to the SSB that is quasi-co-located with the selected CSI-RS).

[0192] 2> Otherwise:

[0193] 3> Determine the next available PRACH opportunity from the PRACH opportunities in the ra-OccasionList, corresponding to the selected CSI-RS (the MAC entity will randomly select a PRACH opportunity among the PRACH opportunities that occur simultaneously but on different subcarriers with equal probability, regardless of the FR2 UL gap corresponding to the selected CSI-RS; the MAC entity may consider the possible occurrence of measurement gaps and MUSIM gaps when determining the next available PRACH opportunity corresponding to the selected CSI-RS).

[0194] 1> Perform the random access preamble transmission procedure (see clause 5.1.3).

[0195] […]

[0196] 5.1.3 Random Access Preamble Transmission

[0197] For each random access preamble, the MAC entity shall:

[0198] 1> If PREAMBLE_TRANSMISSION_COUNTER is greater than one; and

[0199] 1> If the notification to suspend the power ramp counter has not been received from the lower layer; and

[0200] 1> if no LBT failure indication is received from lower layers for the last random access preamble transmission; and

[0201] 1> If the selected SSB or CSI-RS has not changed from the selection in the last random access preamble transmission:

[0202] 2>Increase PREAMBLE_POWER_RAMPING_COUNTER by 1.

[0203] 1> Select the value of DELTA_PREAMBLE according to clause 7.3;

[0204] 1> Set PREAMBLE_RECEIVED_TARGET_POWER to preambleReceivedTargetPower+

[0205] DELTA_PREAMBLE+(PREAMBLE_POWER_RAMPING_COUNTER-1)×PREAMBLE_POWER_RAMPING_STEP+POWER_OFFSET_2STEP_RA;

[0206] 1> Calculate the RA-RNTI associated with the PRACH opportunity in which the random access preamble is transmitted, except for the contention-free random access preamble used for beam failure recovery request;

[0207] 1> Instructs the physical layer to transmit a random access preamble using the selected PRACH opportunity, the corresponding RA-RNTI (if available), PREAMBLE_INDEX and PREAMBLE_RECEIVED_TARGET_POWER.

[0208] […]

[0209] 5.1.4 Random Access Response Reception

[0210] Once the random access preamble is transmitted, and regardless of whether measurement gaps may occur, the MAC entity shall:

[0211] 1> If the contention-free random access preamble for beam failure recovery request is transmitted by the MAC entity:

[0212] 2> If the contention-free random access preamble for beam failure recovery request is transmitted on a non-terrestrial network:

[0213] 3> Start the ra-ResponseWindow configured in BeamFailureRecoveryConfig in the PDCCH opportunity as specified in TS 38.213 [6].

[0214] 2> Otherwise:

[0215] 3> Starting from the end of the random access preamble transmission, the ra-ResponseWindow configured in BeamFailureRecoveryConfig is started at the first PDCCH opportunity as specified in TS 38.213 [6].

[0216] 2> When ra-ResponseWindow is in operation, listen to PDCCH transmission on the search space indicated by recoverySearchSpaceId of the SpCell identified by C-RNTI.

[0217] 1> Otherwise:

[0218] 2> If the random access preamble is transmitted on a non-terrestrial network:

[0219] 3> Start the ra-ResponseWindow configured in RACH-ConfigCommon at the PDCCH opportunity as specified in TS 38.213 [6].

[0220] 2> Otherwise:

[0221] 3> Starting from the end of the random access preamble transmission, the ra-ResponseWindow configured in RACH-ConfigCommon is started at the first PDCCH opportunity as specified in TS 38.213 [6].

[0222] 2> When ra-ResponseWindow is in operation, monitor the PDCCH of the SpCell of the random access response identified by RA-RNTI.

[0223] 1> If a notification of a PDCCH transmission is received on the search space indicated by recoverySearchSpaceId is received from a lower layer on the serving cell where the preamble is transmitted; and

[0224] 1> if the PDCCH transmission is addressed to the C-RNTI; and

[0225] 1> If the contention-free random access preamble for beam failure recovery request is transmitted by the MAC entity:

[0226] 2> The random access procedure is considered to be completed successfully.

[0227] 1> Otherwise, if a valid (as specified in TS 38.213 [6]) downlink assignment has been received on the PDCCH for the RA-RNTI and the received TB was successfully decoded:

[0228] 2> If the random access response contains a MAC sub-PDU with a backoff indicator:

[0229] 3> Using Table 7.2-1, set PREAMBLE_BACKOFF to the value of the BI field of the MAC sub-PDU multiplied by SCALING_FACTOR_BI.

[0230] 2> Otherwise:

[0231] 3>Set PREAMBLE_BACKOFF to 0ms.

[0232] 2> If the Random Access Response contains a MAC sub-PDU with a Random Access Preamble identifier corresponding to the transmitted PREAMBLE_INDEX (see clause 5.1.3):

[0233] 3> This random access response is considered to be received successfully.

[0234] 2> If the random access response is considered to be received successfully:

[0235] 3> If the Random Access Response contains a MAC sub-PDU with only RAPID:

[0236] 4> The random access procedure is considered to be successfully completed;

[0237] 4>Indicate to the upper layer that confirmation of SI request has been received.

[0238] 3> Otherwise:

[0239] 4> Apply the following actions for the serving cell in which the random access preamble is transmitted:

[0240] 5> Process the received timing advance command (see clause 5.2);

[0241] 5> Indicates to the lower layer the preambleReceivedTargetPower and the power ramp variable (i.e. (PREAMBLE_POWER_RAMPING_COUNTER-1)×PREAMBLE_POWER_RAMPING_STEP) applied to the latest random access preamble transmission;

[0242] 5> If the random access procedure for SCell is performed on an uplink carrier in which pusch-Config is not configured:

[0243] 6> Ignore the received UL grant.

[0244] 5> Otherwise:

[0245] 6> Process the received UL grant value and indicate the value to lower layers.

[0246] 4> If the MAC entity does not select a random access preamble among the contention-based random access preambles:

[0247] 5> The random access procedure is considered to be completed successfully.

[0248] 4> Otherwise:

[0249] 5> Set TEMPORARY_C-RNTI to the value received in the random access response;

[0250] 5> If this is the first successfully received random access response within this random access procedure:

[0251] 6> If no transmission is performed for the CCCH logical channel:

[0252] 7> Indicate to the multiplexing and aggregation entity to include the C-RNTI MAC CE in subsequent uplink transmissions.

[0253] 6> If the random access procedure is initiated for SpCell beam failure recovery and spCell-BFR-CBRA with value true is configured:

[0254] 7> If there is at least one serving cell of this MAC entity configured with two BFD-RS sets:

[0255] 8> Indicate to the multiplexing and aggregation entity to include the enhanced BFR MAC CE or the truncated enhanced BFR MAC CE in subsequent uplink transmissions.

[0256] 7> Otherwise:

[0257] 8> Indicate to the multiplexing and aggregation entity to include the BFR MAC CE or the truncated BFR MAC CE in subsequent uplink transmissions.

[0258] 6> Otherwise, if the beam failure recovery for the two BFD-RS sets of SpCell initiates a random access procedure:

[0259] 7> Indicate to the multiplexing and aggregation entity to include the enhanced BFR MAC CE or the truncated enhanced BFR MAC CE in subsequent uplink transmissions.

[0260] 6> Get the MAC PDU for transmission from the multiplexing and aggregation entity and store it in the Msg3 buffer.

[0261] NOTE: If within the random access procedure, the uplink grant provided in the random access response for the same group of contention based random access preambles has a different size than the first uplink grant allocated during the random access procedure, the UE behavior is not restricted.

[0262] 1> if the ra-ResponseWindow configured in BeamFailureRecoveryConfig expires and if a PDCCH transmission on the search space indicated by recoverySearchSpaceId addressed to the C-RNTI has not been received on the serving cell that transmitted the preamble; or

[0263] 1> If the ra-ResponseWindow configured in RACH-ConfigCommon expires and if a Random Access Response containing a Random Access Preamble identifier matching the transmitted PREAMBLE_INDEX has not been received:

[0264] 2> The random access response reception is considered unsuccessful;

[0265] 2>Increase PREAMBLE_TRANSMISSION_COUNTER by 1;

[0266] 2>If PREAMBLE_TRANSMISSION_COUNTER=preambleTransMax+1:

[0267] 3> If the random access preamble is transmitted on SpCell:

[0268] 4>Indicate random access problems to the upper layer;

[0269] 4> If this random access procedure is triggered for an SI request:

[0270] 5> The random access procedure is considered to have not been completed successfully.

[0271] 3> Otherwise, if the random access preamble is transmitted on the SCell:

[0272] 4> The random access procedure is considered to have not been completed successfully.

[0273] 2> If the random access procedure is not completed:

[0274] 3> Select a random backoff time based on a uniform distribution between 0 and PREAMBLE_BACKOFF;

[0275] 3> If the criteria for selecting a contention-free random access resource (as defined in clause 5.1.2) are met during the backoff time:

[0276] 4> Perform random access resource selection procedure (see clause 5.1.2).

[0277] 3> Otherwise, if the random access procedure for the SCell is performed on an uplink carrier in which pusch-Config is not configured:

[0278] 4> Delay subsequent random access transmission until the random access procedure is triggered by a PDCCH command with the same ra-PreambleIndex, ra-ssb-OccasionMaskIndex and UL / SUL indicator TS 38.212 [9].

[0279] 3> Otherwise:

[0280] 4> Perform the random access resource selection procedure after the backoff time (see clause 5.1.2).

[0281] 5.1.5 Contention Resolution

[0282] Once Msg3 is transmitted, the MAC entity shall:

[0283] 1> If Msg3 transmission (i.e., initial transmission or HARQ retransmission) is scheduled with type APUSCH repetition:

[0284] 2> If Msg3 is sent on a non-terrestrial network:

[0285] 3> Start or restart ra-ContentionResolutionTimer in the first symbol after all repetitions of Msg3 transmission end plus UE-gNB RTT.

[0286] 2> Otherwise:

[0287] 3> Start or restart ra-ContentionResolutionTimer in the first symbol after all repetitions of Msg3 transmission are completed.

[0288] 1> Otherwise, if the Msg3 transmission (i.e., initial transmission or HARQ retransmission) is transmitted on a non-terrestrial network:

[0289] 2> Start or restart ra-ContentionResolutionTimer in the first symbol after the end of Msg3 transmission plus UE-gNB RTT.

[0290] 1> Otherwise:

[0291] 2> Start or restart ra-ContentionResolutionTimer in the first symbol after the transmission of Msg3 is completed.

[0292] 1> Regardless of whether measurement gaps may occur, PDCCH is monitored when ra-ContentionResolutionTimer is running;

[0293] 1> If a notification of receiving a PDCCH transmission from SpCell is received from the lower layer:

[0294] 2> If C-RNTI MAC CE is included in Msg3:

[0295] 3> If a random access procedure is initiated for SpCell beam failure recovery or for both SpCell's BFD-RS set beam failure recovery (as specified in clause 5.17) and the PDCCH transmission is addressed to the C-RNTI; or

[0296] 3> If the random access procedure is initiated by a PDCCH command and the PDCCH transmission is addressed to the C-RNTI; or

[0297] 3> If the random access procedure is initiated by the MAC sublayer itself or by the RRC sublayer and the PDCCH transmission is addressed to the C-RNTI and contains an UL grant for a new transmission:

[0298] 4> Consider this contention resolution as a success;

[0299] 4>Stop ra-ContentionResolutionTimer;

[0300] 4>Discard TEMPORARY_C-RNTI;

[0301] 4> This random access procedure is considered to be completed successfully.

[0302] 2> Otherwise, if the CCCH SDU is contained in Msg3 and the PDCCH transmission is addressed to its TEMPORARY_C-RNTI:

[0303] 3> If the MAC PDU is decoded successfully:

[0304] 4>Stop ra-ContentionResolutionTimer;

[0305] 4> If the MAC PDU contains the UE contention resolution identity MAC CE; and

[0306] 4> If the UE contention resolution identity in the MAC CE matches the CCCH SDU transmitted in Msg3:

[0307] 5> Consider this contention resolution as successful and end the decomposition and demultiplexing of MAC PDU;

[0308] 5> If this random access procedure is initiated for SI request:

[0309] 6>Indicate to the upper layer that confirmation of SI request has been received.

[0310] 5> Otherwise:

[0311] 6> Set C-RNTI to the value of TEMPORARY_C-RNTI;

[0312] 5>Discard TEMPORARY_C-RNTI;

[0313] 5> This random access procedure is considered to be completed successfully.

[0314] 4> Otherwise:

[0315] 5>Discard TEMPORARY_C-RNTI;

[0316] 5> Consider this contention resolution unsuccessful and discard the successfully decoded MAC PDU.

[0317] 1> If ra-ContentionResolutionTimer expires:

[0318] 2> If Msg3 is sent on a non-terrestrial network:

[0319] 3> If no PDCCH addressed to the TC-RNTI indicating the uplink grant for Msg3 retransmission is received after the ra-ContentionResolutionTimer is started:

[0320] 4>Discard TEMPORARY_C-RNTI;

[0321] 4>Content resolution is considered unsuccessful.

[0322] 2> Otherwise:

[0323] 3>Discard TEMPORARY_C-RNTI;

[0324] 3>Content resolution is considered unsuccessful.

[0325] 1> If contention resolution is deemed unsuccessful:

[0326] 2> Clear the HARQ buffer in the Msg3 buffer used to transmit MAC PDU;

[0327] 2>Increase PREAMBLE_TRANSMISSION_COUNTER by 1;

[0328] 2>If PREAMBLE_TRANSMISSION_COUNTER=preambleTransMax+1:

[0329] 3>Indicate random access problems to upper layers.

[0330] 3> If this random access procedure is triggered for an SI request:

[0331] 4> The random access procedure is considered to have not been completed successfully.

[0332] 2> If the random access procedure is not completed:

[0333] 3> If RA_TYPE is set to 4-stepRA:

[0334] 4> Select a random backoff time based on a uniform distribution between 0 and PREAMBLE_BACKOFF;

[0335] 4> If the criteria for selecting a contention-free random access resource (as defined in clause 5.1.2) are met during the backoff time:

[0336] 5>Perform the random access resource selection procedure (see clause 5.1.2);

[0337] 4> Otherwise:

[0338] 5> Perform the random access resource selection procedure after the backoff time (see clause 5.1.2).

[0339] 3> Otherwise (i.e., RA_TYPE is set to 2-stepRA):

[0340] 4> If msgA-TransMax applies (see clause 5.1.1a) and PREAMBLE_TRANSMISSION_COUNTER = msgA-TransMax+1:

[0341] 5> Set RA_TYPE to 4-stepRA;

[0342] 5> Perform initialization of variables specific to the random access type as specified in clause 5.1.1a;

[0343] 5> Clear the HARQ buffer in the MSGA buffer used to transmit MAC PDU;

[0344] 5> Abandon the explicitly transmitted contention-free 2-step RA type random access resources (if any);

[0345] 5> Perform random access resource selection as specified in clause 5.1.2.

[0346] 4> Otherwise:

[0347] 5> Select a random backoff time based on a uniform distribution between 0 and PREAMBLE_BACKOFF;

[0348] 5> If the criteria for selecting a contention-free random access resource (as defined in clause 5.1.2a) are met during the backoff time:

[0349] 6> Perform the random access resource selection procedure for 2-step RA type as specified in clause 5.1.2a.

[0350] 5> Otherwise:

[0351] 6> Perform random access resource selection for a 2-step RA type procedure after the backoff time (see clause 5.1.2a).

[0352] 5.2 Maintenance of uplink time alignment

[0353] RRC configures the following parameters to maintain UL time alignment:

[0354] - timeAlignmentTimer (per TAG), which controls how long the MAC entity considers the uplink time alignment of the serving cells belonging to the associated TAG;

[0355] - inactivePosSRS-TimeAlignmentTimer, which controls how long the MAC entity considers the positioning SRS transmission uplink time alignment in RRC_INACTIVE in clause 5.26;

[0356] -cg-SDT-TimeAlignmentTimer, which controls how long the MAC entity considers the uplink transmissions for CG-SDT to be uplink time aligned.

[0357] The MAC entity will:

[0358] 1> When a timing advance command MAC CE is received, and if N has been maintained with the indicated TAG TA (as defined in TS 38.211[8]):

[0359] 2> Apply timing advance command for the indicated TAG;

[0360] 2> If inactivePosSRS-TimeAlignmentTimer is configured and there is an ongoing positioning SRS transmission that is RRC_INACTIVE as in clause 5.26:

[0361] 3> Start or restart the inactivePosSRS-TimeAlignmentTimer associated with the indicated TAG.

[0362] 2> If the CG-SDT procedure triggered as in clause 5.27 is in progress:

[0363] 3> Start or restart the cg-SDT-TimeAlignmentTimer associated with the indicated TAG.

[0364] 2> Otherwise:

[0365] 3> Start or restart the timeAlignmentTimer associated with the indicated TAG.

[0366] 1> When a timing advance command is received in a random access response message for a serving cell belonging to a TAG or in a MSGB for a SpCell:

[0367] 2> If the MAC entity does not select a random access preamble among the contention-based random access preambles:

[0368] 3> Apply timing advance command for this TAG;

[0369] 3> Start or restart the timeAlignmentTimer associated with this TAG.

[0370] 2> Otherwise, if the time alignment timer associated with this TAG is not running:

[0371] 3> Apply timing advance command for this TAG;

[0372] 3>Start the timeAlignmentTimer associated with this TAG;

[0373] 3> when contention resolution as described in clause 5.1.5 is deemed unsuccessful; or

[0374] 3> When contention resolution is deemed successful for the SI request as described in clause 5.1.5 after transmitting the HARQ feedback containing the UE contention resolution identity MAC CE for the MAC PDU:

[0375] 4> Stop the timeAlignmentTimer associated with this TAG.

[0376] 3> When contention resolution is deemed unsuccessful as described in clause 5.1.5:

[0377] 4> If the CG-SDT procedure triggered as in clause 5.27 is in progress:

[0378] 5>N TA The value is set to the value before applying the received timing advance command as in TS 38.211 [8].

[0379] 3> When contention resolution is considered successful for the random access procedure while the CG-SDT procedure is in progress:

[0380] 4> Stop the timeAlignmentTimer associated with this TAG;

[0381] 4> Start or restart the cg-SDT-TimeAlignmentTimer associated with this TAG.

[0382] 3> When contention resolution is considered successful for the random access procedure while SRS transmission in RRC_INACTIVE is in progress:

[0383] 4> Start or restart the inactivePosSRS-TimeAlignmentTimer associated with this TAG.

[0384] 2> Otherwise:

[0385] 3> Ignore the received timing advance command.

[0386] 1> When an Absolute Timing Advance Command is received in response to an MSGA transmission containing a C-RNTI MAC CE as specified in clause 5.1.4a:

[0387] 2> Apply PTAG's timing advance command;

[0388] 2> If the CG-SDT procedure is in progress:

[0389] 3> Start or restart the cg-SDT-TimeAlignmentTimer associated with PTAG.

[0390] 2> Otherwise:

[0391] 3> Start or restart the timeAlignmentTimer associated with PTAG.

[0392] 1> When receiving an indication from the upper layer to stop the inactivePosSRS-TimeAlignmentTimer:

[0393] 2>Stop inactivePosSRS-TimeAlignmentTimer.

[0394] 1> When receiving an indication from the upper layer to start the inactivePosSRS-TimeAlignmentTimer:

[0395] 2>Start or restart inactivePosSRS-TimeAlignmentTimer.

[0396] 1> When the instruction to start cg-SDT-TimeAlignmentTimer has been received from the upper layer:

[0397] 2>Start cg-SDT-TimeAlignmentTimer.

[0398] 1> When the instruction to stop cg-SDT-TimeAlignmentTimer has been received from the upper layer:

[0399] 2> cg-SDT-TimeAlignmentTimer is considered expired.

[0400] 1> When an instruction to start the TimeAlignmentTimer associated with PTAG has been received from the upper layer:

[0401] 2>Start the TimeAlignmentTimer associated with PTAG.

[0402] 1>When timeAlignmentTimer expires:

[0403] 2> If timeAlignmentTimer is associated with PTAG:

[0404] 3> Clear all HARQ buffers for all serving cells;

[0405] 3> Notify RRC to release PUCCH for all serving cells (if configured);

[0406] 3> Notify RRC to release SRS for all serving cells (if configured);

[0407] 3> Clear any configured downlink assignments and configured uplink grants;

[0408] 3> Clear any PUSCH resources used for semi-static CSI reporting;

[0409] 3> All timeAlignmentTimers in operation are considered to have expired;

[0410] 3> Maintain N of all tags TA (Defined in TS 38.211[8]).

[0411] 2> Otherwise, if timeAlignmentTimer is associated with a STAG, then all serving cells belong to this TAG:

[0412] 3> Clear all HARQ buffers;

[0413] 3> Notify RRC to release PUCCH (if configured);

[0414] 3> Notify RRC to release SRS (if configured);

[0415] 3> Clear any configured downlink assignments and configured uplink grants;

[0416] 3> Clear any PUSCH resources used for semi-static CSI reporting;

[0417] 3> Maintain the N of this TAG TA (Defined in TS 38.211[8]).

[0418] 1>When inactivePosSRS-TimeAlignmentTimer expires:

[0419] 2> Notify RRC to release the positioning SRS configured for RRC_INACTIVE.

[0420] 1>When cg-SDT-TimeAlignmentTimer expires:

[0421] 2> Clear any configured uplink grants;

[0422] 2> If a PDCCH addressed to the C-RNTI of the MAC entity has not been received after the initial transmission of the CG-SDT with a CCCH message:

[0423] 3> The ongoing CG-SDT program will be deemed terminated;

[0424] 3>Indicate to the upper layer that cg-SDT-TimeAlignmentTimer has expired.

[0425] 2> Clear all HARQ buffers;

[0426] 2> Maintain the N of this TAG TA (Defined in TS 38.211[8]).

[0427] 6.1.3.4 Timing Advance Command MAC CE

[0428] The Timing Advance Command MAC CE is identified by a MAC subheader with an LCID as specified in Table 6.2.1-1.

[0429] It has a fixed size and consists of a single octet as defined below ( Figure 6 .1.3.4-1):

[0430] -TAG ID: This field indicates the TAG ID of the addressed TAG. The TAG containing the SpCell has TAG ID 0. The length of the field is 2 bits;

[0431] - Timing Advance Command: This field indicates the index value T used to control the amount of timing adjustment that the MAC entity (as specified in TS 38.213 [6]) must apply. A (0, 1, 2, ..., 63). The length of the field is 6 bits.

[0432] Figure 5 It is in 3GPP 38.321v17.4.0 Figure 6 .1.3.4-1: Reappearance of Timing Advance Command MAC CE

[0433] 3.1 Definition

[0434] Primary cell: An MCG cell operating on a primary frequency, where the UE performs an initial connection establishment procedure or initiates a connection re-establishment procedure.

[0435] Primary SCG cell: For dual connectivity operation, the SCG cell to which the UE performs random access when performing reconfiguration with synchronization procedure.

[0436] Secondary cell: A cell that provides additional radio resources on top of a special cell for UEs configured to use CA.

[0437] Secondary Cell Group: For a UE configured to use dual connectivity, a subset of serving cells including a PSCell and zero or more secondary cells.

[0438] Serving cell: For a UE in RRC_CONNECTED and not configured to use CA / DC, there is only one serving cell including the primary cell. For a UE in RRC_CONNECTED and configured to use CA / DC, the term 'serving cell' is used to refer to a set of cells including a special cell and all secondary cells.

[0439] Special cell: For dual connectivity operation, the term special cell refers to the PCell of the MCG or the PSCell of the SCG. In other cases, the term special cell refers to the PCell.

[0440] Timing Advance Group: A group of serving cells configured by RRC and using the same timing reference cell and the same timing advance value for UL configured cells. The timing advance group of the SpCell containing the MAC entity is called the primary timing advance group (PTAG), while the term secondary timing advance group (STAG) refers to other TAGs.

[0441] In 38.331 ([2] 3GPP 38.331v17.4.0), random access information reporting and additional PCI configuration are introduced:

[0442] 5.7.10.3 Receipt of UEInformationRequest message

[0443] After receiving the UEInformationRequest message, the UE shall, only after successful security activation:

[0444] […]

[0445] 1> If ra-ReportReq is set to true and the UE has random access related information available in the VarRA-Report and if the RPLMN is contained in the plmn-IdentityList stored in the VarRA-Report:

[0446] 2> Set the ra-ReportList in the UEInformationResponse message to the value of ra-ReportList in VarRA-Report;

[0447] 2> When the lower layer confirms the successful delivery of the UEInformationResponse message, the ra-ReportList is discarded from the VarRA-Report;

[0448] 1>If rlf-ReportReq is set to true:

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

[0450] 3> Set timeSinceFailure in VarRLF-Report to the time since the last radio link failure or handover failure in NR;

[0451] 3> Set the rlf-Report in the UEInformationResponse message to the value of rlf-Report in VarRLF-Report;

[0452] 3> When the lower layer confirms the successful delivery of the UEInformationResponse message, the rlf-Report is discarded from the VarRLF-Report;

[0453] 2> Otherwise, if the UE is capable of inter-RAT RLF reporting as defined in TS 38.306

[26] and has radio link failure information or handover failure information available in the VarRLF-Report of TS 36.331

[10] , and if the RPLMN is contained in the plmn-IdentityList stored in the VarRLF-Report of TS 36.331

[10] :

[0454] 3> Set timeSinceFailure in VarRLF-Report of TS 36.331

[10] to the time since the last radio link failure or handover failure in EUTRA;

[0455] 3> Set failedPCellId-EUTRA in the rlf-Report in the UEInformationResponse message to indicate the PCell in which the RLF is detected or the source PCell of the failed handover in the VarRLF-Report of TS 36.331

[10] ;

[0456] 3> Set measResult-RLF-Report-EUTRA in the rlf-Report in the UEInformationResponse message to the value of rlf-Report in the VarRLF-Report of TS 36.331

[10] ;

[0457] 3> When the lower layer confirms the successful delivery of the UEInformationResponse message, the rlf-Report is discarded from the VarRLF-Report of TS 36.331

[10] ;

[0458] 1> If connEstFailReportReq is set to true and the UE has connection establishment failure or connection recovery failure information in VarConnEstFailReport or VarConnEstFailReportList, and if RPLMN is equal to the plmn-Identity stored in at least one entry in VarConnEstFailReport or VarConnEstFailReportList:

[0459] 2> Set timeSinceFailure in VarConnEstFailReport to the time since the last connection establishment failure or connection recovery failure in NR;

[0460] 2> Set the connEstFailReport in the UEInformationResponse message to the value of connEstFailReport in VarConnEstFailReport;

[0461] 2> If the UE supports multiple CEF reports:

[0462] 3>For each connEstFailReport in connEstFailReportList in VarConnEstFailReportList:

[0463] 4> timeSinceFailure is set to the time that has passed since the associated connection establishment failure or connection recovery failure in NR;

[0464] 2> For each connEstFailReport in the connEstFailReportList in the UEInformationResponse message, set the value to the value of the connEstFailReport in the VarConnEstFailReport in the VarConnEstFailReportList;

[0465] 2> When the lower layer confirms the successful delivery of the UEInformationResponse message, the connEstFailReport is discarded from VarConnEstFailReport and VarConnEstFailReportList;

[0466] […]

[0467] 1> If successHO-ReportReq is set to true, and if the UE has successful handover related information available in VarSuccessHO-Report, and if the RPLMN is contained in the plmn-IdentityList stored in VarSuccessHO-Report:

[0468] 2> If the successHO-Report in VarSuccessHO-Report relates to a DAPS handover and if the PDCP PDU has been received from the source cell of the relevant HO and the non-duplicate PDCP PDU has been received from the target cell of the relevant HO:

[0469] 3> set upInterruptionTimeAtHO in VarSuccessHO-Report to contain the time elapsed between the arrival time of the last PDCP PDU received from the source cell of the relevant handover and the arrival time of the first non-duplicate PDCP PDU received from the target cell of the relevant handover (as measured at the arrival time of the first non-duplicate PDCP PDU received from the target cell);

[0470] 2> Set the successHO-Report in the UEInformationResponse message to the value of the successHO-Report in VarSuccessHO-Report (if available);

[0471] 2> When the lower layer confirms the successful delivery of the UEInformationResponse message, the VarSuccessHO-Report is discarded;

[0472] 1> If coarseLocationRequest is set to true:

[0473] 2> Include coarseLocationInfo (if available);

[0474] 1> If logMeasReport is included in UEInformationResponse:

[0475] 2> Submit UEInformationResponse message to the lower layer for transmission via SRB2;

[0476] 2> When the lower layer confirms the successful delivery of the UEInformationResponse message, the recorded measurement entries contained in the logMeasInfoList are discarded from the VarLogMeasReport;

[0477] 1> Otherwise:

[0478] 2> Submit the UEInformationResponse message to the lower layer for transmission via SRB1.

[0479] 5.7.10.4 Actions upon successful completion of the random access procedure or upon completion of the request for on-demand system information

[0480] Upon successful execution of a Random Access procedure initiated with a 4-step or 2-step RA type, or a failed or successfully completed On-demand System Information Acquisition procedure in RRC_IDLE or RRC_INACTIVE state, the UE shall:

[0481] 1> If the RPLMN or PLMN selected by the upper layer from the PLMNs in the plmn-IdentityList contained in SIB1 (see TS 24.501

[23] ) is not contained in the plmn-IdentityList stored in a non-empty VarRA-Report:

[0482] 2> Clear the information contained in VarRA-Report;

[0483] 1> If the number of RA-Report entries in ra-ReportList stored in VarRA-Report is less than maxRAReport:

[0484] 2> If the number of PLMN entries in the plmn-IdentityList stored in the VarRA-Report is less than maxPLMN; or

[0485] 2> If the number of PLMN entries in the plmn-IdentityList stored in the VarRA-Report is equal to maxPLMN, and the list of EPLMNs is a subset of or equal to the plmn-IdentityList stored in the VarRA-Report:

[0486] 3> Append the following associated with a successfully completed random access procedure or a failed or successfully completed on-demand system information acquisition procedure as a new entry in the VarRA-Report:

[0487] 4> If the list of EPLMNs is already stored by the UE:

[0488] 5> Set plmn-IdentityList to a list of EPLMNs stored by the UE (i.e. including RPLMNs), but not exceeding the limit of maxPLMN;

[0489] 4> Otherwise:

[0490] 5> Set the plmn-Identity in plmn-IdentityList to the PLMN selected by the upper layer from the PLMN in the plmn-IdentityInfoList contained in SIB1 (see TS24.501

[23] );

[0491] 4> Set cellId to the global cell identity and tracking area code (if available), otherwise set it to the physical cell identity and carrier frequency of the cell that transmitted the corresponding random access preamble;

[0492] 4> If the UE supports spCell ID indication:

[0493] 5> If the corresponding random access procedure has been executed on the SCell of the MCG:

[0494] 6> Set spCellId to the global cell identity of PCell;

[0495] 5> If the corresponding random access procedure has been executed on the SCell of the SCG; or

[0496] 5> If the corresponding random access procedure has been executed on the PSCell:

[0497] 6> Set spCellId to the global cell identity of PSCell (if available), otherwise set spCellId to the global cell identity of PCell;

[0498] 4> Set raPurpose to include the purpose of triggering the random access procedure;

[0499] 4> Set ra-InformationCommon as specified in clause 5.7.10.5.

[0500] The UE may discard the random access report information 48 hours after the last successful random access procedure or the failed or successfully completed on-demand system information acquisition procedure related information is added to the VarRA-Report, that is, release the UE variable VarRA-Report.

[0501] NOTE 1: If the triggering event for random access is consistent UL LBT on the SpCell, as specified in TS 38.321 [6], the UE does not record the RA information in the RA report.

[0502] 5.7.10.5 RA information confirmation

[0503] The content of ra-InformationCommon set by the UE is as follows:

[0504] 1> set absoluteFrequencyPointA to indicate the absolute frequency of the reference resource block associated with the random access resource used for the random access procedure;

[0505] 1>Set the locationAndBandwidth and subcarrierSpacing associated with the UL BWP of the random access resource used for the random access procedure;

[0506] 1> If contention-based random access resources are used for random access procedure:

[0507] 2> Set msgA_RO-FrequencyStart and msgA-RO-FDM and msgA-SubcarrierSpacing associated with 2-step random access resources (if used for random access procedure);

[0508] 2> If msgA-SubcarrierSpacing associated with the 2-step random access resource for the random access procedure is available:

[0509] 3> Set the msgA-SubcarrierSpacing associated with the 2-step random access resource used for the random access procedure;

[0510] 2> Otherwise, if only 2-step random access resources are available in the UL BWP for the random access procedure:

[0511] 3> Set msgA-SCS-From-prach-ConfigurationIndex to the subcarrier spacing derived from msgA-PRACH-ConfigurationIndex for the 2-step random access procedure;

[0512] 2> Otherwise:

[0513] 3> Set the msg1-SubcarrierSpacing associated with the 4-step random access resource used for the random access procedure;

[0514] 2> Set msg1-FrequencyStart associated with the 4-step random access resource if the 4-step random access resource is used for the random access procedure and if its value is different from the value of msgA-RO-FrequencyStart contained in ra-InformationCommon;

[0515] 2> if 4-step random access resources are used for the random access procedure and if its value is different from the value of msgA-RO-FDMCFRA contained in ra-InformationCommon, set msg1-FDM associated with the 4-step random access resources;

[0516] 2> If msg1-SubcarrierSpacing associated with the 4-step random access resource used for the random access procedure is available and if its value is different from the value of msgA-SubcarrierSpacing contained in ra-InformationCommon:

[0517] 3> Set the msg1-SubcarrierSpacing associated with the 4-step random access resource used for the random access procedure;

[0518] 2> Otherwise:

[0519] 3> If its value is different from the value of msgA-SCS-From-prach-ConfigurationIndex contained in ra-InformationCommon, set msg1-SCS-From-prach-ConfigurationIndex to the subcarrier spacing derived from prach-ConfigurationIndex for the 4-step random access procedure;

[0520] 1> If non-contention random access resources are used for random access procedure:

[0521] 2> Set msg1-FrequencyStartCFRA and msg1-FDMCFRA associated with 4-step random access resources (if used for random access procedure);

[0522] 2> If msg1-SubcarrierSpacing associated with the 4-step random access resource for the random access procedure is available:

[0523] 3> Set msg1-SubcarrierSpacingCFRA associated with the 4-step random access resource for the random access procedure;

[0524] 2> Otherwise:

[0525] 3> Set msg1-SCS-From-prach-ConfigurationIndexCFRA to the subcarrier spacing derived from prach-ConfigurationIndex for the 4-step random access procedure;

[0526] 2> Set msgA-RO-FrequencyStartCFRA and msgA-RO-FDMCFRA associated with 2-step contention-free random access resources (if used for random access procedure);

[0527] 2> Set msgA-MCS, nrofPRBs-PerMsgA-PO, msgA-PUSCH-TimeDomainAllocation, frequencyStartMsgA-PUSCH, nrofMsgA-PO-FDM associated with 2-step random access resources (if used for random access procedure);

[0528] 2> If msgA-SubcarrierSpacing associated with the 2-step random access resource for the random access procedure is available:

[0529] 3> Set the msgA-SubcarrierSpacing associated with the 2-step random access resource used for the random access procedure;

[0530] 2> Otherwise, if only 2-step random access resources are available in the UL BWP for the random access procedure:

[0531] 3> Set msgA-SCS-From-prach-ConfigurationIndex to the subcarrier spacing derived from msgA-PRACH-ConfigurationIndex for the 2-step random access procedure;

[0532] 2> Otherwise:

[0533] 3> Set the msg1-SubcarrierSpacing associated with the 4-step random access resource used for the random access procedure;

[0534] 1> If the random access procedure is initiated with RA_TYPE set to 2-stepRA, as described in TS 38.321 [3]:

[0535] 2> Set dlPathlossRSRP to the measured RSRP of the DL path loss reference obtained during the initialization of the RA_Type selection phase of the RA procedure, as captured in TS 38.321 [3];

[0536] 2> If the configuration for random access msgA-TransMax has been configured in RACH-ConfigDedicated for this random access procedure, and ra-Purpose is set to reconfigurationWithSync:

[0537] 3> Set msgA-TransMax to the value of msgA-TransMax in RACH-ConfigDedicated;

[0538] 2> Otherwise, if msgA-TransMax has been configured in RACH-ConfigCommonTwoStepRA:

[0539] 3> Set msgA-TransMax to the value of msgA-TransMax in RACH-ConfigCommonTwoStepRA;

[0540] 2> Set msgA-PUSCH-PayloadSize to the size of the total payload available in the UE buffer when initiating the 2-step RA procedure;

[0541] 1> If the purpose of the random access procedure is to request on-demand system information (i.e., if raPurpose is set to requestForOtherSI or msg3RequestForOtherSI):

[0542] 2> Set intendedSIBs to indicate the SIBs that the UE wants to receive as a result of the SI request;

[0543] 2> Set ssbsForSI-Acquisition to indicate the SSB for receiving SI messages;

[0544] 2> If the on-demand system information is obtained successfully:

[0545] 3>Set onDemandSISuccess to true;

[0546] 1> Set the parameters associated with each random access attempt in the chronological order of the attempts in perRAInfoList as follows:

[0547] 2> If the random access resource used is associated with an SS / PBCH block, the associated random access parameters for consecutive random access attempts associated with the same SS / PBCH block for one or more random access attempts are set as follows:

[0548] 3> Set ssb-Index to contain the SS / PBCH block index associated with the random access resource used;

[0549] 3> Set numberOfPreamblesSentOnSSB to indicate the number of consecutive random access attempts associated with the SS / PBCH block;

[0550] 3> For each random access attempt performed on the random access resource, the following parameters are included in the chronological order of the random access attempts:

[0551] 4> If the random access attempt is performed on contention-based random access resources, and if raPurpose is not equal to 'requestForOtherSI', contentionDetected is included as follows:

[0552] 5> If contention resolution is unsuccessful for the transmitted preamble as specified in TS 38.321 [6]:

[0553] 6> Set contentionDetected to true;

[0554] 5> Otherwise:

[0555] 6>Set contentionDetected to false;

[0556] 4> If the random access attempt is a 2-step random access attempt:

[0557] 5> If fallback from 2-step random access to 4-step random access occurs during a random access attempt:

[0558] 6>Set fallbackToFourStepRA to true;

[0559] 4> if the random access attempt is performed on a contention-based random access resource; or

[0560] 4> If the random access attempt is performed on a contention-free random access resource and if the random access procedure is initiated due to PDCCH sorting:

[0561] 5> if the random access attempt is a 4-step random access attempt and the SS / PBCH block RSRP corresponding to the SS / PBCH block of the random access resources used for the random access attempt is higher than rsrp-ThresholdSSB; or

[0562] 5> If the random access attempt is a 2-step random access attempt and the SS / PBCH block RSRP of the SS / PBCH block corresponding to the random access resources used for the random access attempt is higher than msgA-RSRP-ThresholdSSB:

[0563] 6>Set dlRSRPAboveThreshold to true;

[0564] 5> Otherwise:

[0565] 6>Set dlRSRPAboveThreshold to false;

[0566] 2> Otherwise, if the used random access resource is associated with a CSI-RS, the associated random access parameters for consecutive random access attempts associated with the same CSI-RS for one or more random access attempts are set as follows:

[0567] 3> Set csi-RS-Index to contain the CSI-RS index associated with the random access resource used;

[0568] 3> Set numberOfPreamblesSentOnCSI-RS to indicate the number of consecutive random access attempts associated with CSI-RS.

[0569] 5.7.10.6 Actions for Successful Handover Report Determination

[0570] For PCell, the UE will:

[0571] 1> if the ratio between the value of the elapsed time of timer T304 and the configured value of timer T304 (contained in the RRCReconfiguration message of the last application containing reconfigurationWithSync) is greater than thresholdPercentageT304 (if contained in the successHO-Config received before the last reconfiguration with synchronization was performed); or

[0572] 1> if the ratio between the value of the elapsed time of timer T310 and the configured value of timer T310 (configured when the UE was connected to the source PCell before performing the last reconfiguration with synchronization) is greater than the thresholdPercentageT310 contained in successHO-Config (if configured by the source PCell before performing the last reconfiguration with synchronization); or

[0573] 1> if T312 associated with the measurement identity of the target cell is running when the reconfiguration with synchronization procedure is initiated, and if the ratio between the value of the elapsed time of timer T312 and the configured value of timer T312 (configured when the UE was connected to the source PCell before the last reconfiguration with synchronization was performed) is greater than the thresholdPercentageT312 contained in successHO-Config (if configured by the source PCell before the last reconfiguration with synchronization was performed); or

[0574] 1> If sourceDAPS-FailureReporting was included in successHO-Config and set to true before the last reconfiguration with synchronization was performed, and if the last handover performed was a DAPS handover, and if RLF occurs at the source PCell during a DAPS handover while T304 is running:

[0575] 2>Store the successful handover information in VarSuccessHO-Report, and confirm that the content in VarSuccessHO-Report is as follows:

[0576] 3> Clear the information contained in VarSuccessHO-Report (if it exists);

[0577] 3> Set plmn-IdentityList to contain the list of EPLMNs stored by the UE (i.e. including RPLMN);

[0578] 3> Set c-RNTI to the C-RNTI assigned by the target PCell of the handover;

[0579] 3> For the source PCell to which the last RRCReconfiguration message containing reconfigurationWithSync was applied:

[0580] 4> Set sourceCellID in sourceCellInfo to the global cell identity and tracking area code of the source PCell (if available);

[0581] 4> Based on the available SSB and CSI-RS measurements collected before the UE sends the RRCReconfigurationComplete message, set sourceCellMeas in sourceCellInfo to contain the cell-level RSRP, RSRQ and available SINR of the source PCell;

[0582] 4> Set rsIndexResults in sourceCellMeas to contain all available SSB and CSI-RS measurement quantities of the source PCell collected before the moment the UE sends the RRCReconfigurationComplete message;

[0583] 4> If the last performed handover was a DAPS handover, and if RLF occurs at the source PCell during the DAPS handover while T304 is running:

[0584] 5>Set rlf-InSourceDAPS in sourceCellInfo to true;

[0585] 3> For the target PCell indicated in the last applied RRCReconfiguration message containing reconfigurationWithSync:

[0586] 4> Set the targetCellID in targetCellInfo to the global cell identity and tracking area code of the target PCell (if available);

[0587] 4> Based on the available SSB and CSI-RS measurements collected before the UE sends the RRCReconfigurationComplete message, set the targetCellMeas in targetCellInfo to contain the cell-level RSRP, RSRQ and available SINR of the target PCell;

[0588] 4> Set rsIndexResults in targetCellMeas to contain all available SSB and CSI-RS measurement quantities of the target PCell collected before the moment the UE sends the RRCReconfigurationComplete message;

[0589] 4> If the last applied RRCReconfiguration message containing reconfigurationWithSync is included in the stored condRRCReconfig:

[0590] 5> timeSinceCHO-Reconfig is set to the time that has passed between initiating the conditional reconfiguration of the target PCell and receiving the last conditionalReconfiguration of the target PCell containing condRRCReconfig in the source PCell;

[0591] 3> If the ratio between the value of the elapsed time of timer T304 and the configured value of the T304 timer (contained in the RRCReconfiguration message of the last application containing reconfigurationWithSync) is greater than thresholdPercentageT304 (if contained in the successHO-Config received before the last reconfiguration with synchronization was performed):

[0592] 4> Set t304-cause in shr-Cause to true;

[0593] 4> set ra-InformationCommon to contain random access related information associated with the random access procedure in the target PCell, as specified in clause 5.7.10.5;

[0594] […]

[0595] 3> If available, set locationInfo as in 5.3.3.7;

[0596] 1> Release the successHO-Config and thresholdPercentageT304 configured by the source PCell (if configured by the target PCell).

[0597] The UE may discard the successful handover information 48 hours after the last successful handover information is added to VarSuccessHO-Report, that is, release the UE variable VarSuccessHO-Report.

[0598] -VarRA-Report

[0599] The UE variable VarRA-Report contains random access related information.

[0600] VarRA - Report UE variables

[0601] VarRA-Report-r16::= SEQUENCE{

[0602] ra-ReportList-r16 RA-ReportList-r16,

[0603] plmn-IdentityList-r16 PLMN-IdentityList-r16

[0604] }

[0605] PLMN-IdentityList-r16::=SEQUENCE(SIZE(1..maxPLMN))OF PLMN-Identity

[0606] -UEInformationResponse

[0607] The UEInformationResponse message is used by the UE to deliver information requested by the network.

[0608] Signalling Radio Bearer: SRB1 or SRB2 (when containing logged measurement information)

[0609] RLC-SAP:AM

[0610] Logical channel: DCCH

[0611] Direction: UE to network

[0612] UEInformationResponse message

[0613]

[0614]

[0615]

[0616]

[0617]

[0618]

[0619]

[0620]

[0621]

[0622]

[0623]

[0624]

[0625]

[0626]

[0627]

[0628]

[0629]

[0630]

[0631] -PCI-ARFCN-NRIPCI-ARFCN-NR is used to encode NR PCI and ARFCN.

[0632] PCI-ARFCN-NR Information Elements

[0633] PCI-ARFCN-NR-r16::= SEQUENCE{

[0634] physCellId-r16 PhysCellId,

[0635] carrierFreq-r16 ARFCN-ValueNR

[0636] }

[0637] -CGI-Info-Logging

[0638] The IE CGI-Info-Logging indicates the NR Cell Global Identifier (NCGI), the globally unique identity and the TAC information of the cell in NR for logging purposes (e.g., RLF reporting).

[0639] CGI-Info-Logging Information Element

[0640]

[0641]

[0642] -CSI-SSB-ResourceSet

[0643] IE CSI-SSB-ResourceSet is used to configure a SS / PBCH block resource set referring to the SS / PBCH as indicated in ServingCellConfigCommon and ServingCellConfig.

[0644] CSI-SSB-ResourceSet information element

[0645]

[0646]

[0647] -ServingCellConfig

[0648] IE ServingCellConfig is used to configure (add or modify) a UE with a serving cell, which can be a SpCell or an SCell of an MCG or SCG. Most of the parameters in this document are UE-specific, but some are also cell-specific (e.g., in an additionally configured bandwidth part). Reconfiguration between PUCCH and PUCCH-less SCell is supported only using SCell release and addition.

[0649] ServingCellConfig Information Elements

[0650] …

[0651]

[0652]

[0653] -SSB-MTC

[0654] IE SSB-MTC is used to configure the measurement timing configuration, that is, the timing when the UE measures SSB.

[0655] SSB-MTC information elements

[0656] …

[0657]

[0658]

[0659]

[0660] …

[0661] -TCI-State

[0662] IE TCI-State associates one or two DL reference signals with the corresponding quasi-colocation (QCL) type.

[0663] TCI-State Information Element

[0664]

[0665]

[0666] -TCI-UL-State IE TCI-UL-State indicates TCI state information for UL transmission.

[0667] TCI-UL-State Information Element

[0668]

[0669]

[0670] In the New WID for Further Mobility Enhancement of NR ([3] RP-212710 New WID for Further Mobility Enhancement of NR), the goals of mobility enhancement of NR are discussed:

[0671] 3 Argument

[0672] When a UE moves from the coverage area of ​​one cell to another, at some point a serving cell change needs to be performed. Currently serving cell changes are triggered by L3 measurements and are done through a reconfiguration triggered by RRC signaling with synchronization for PCell and PSCell changes and release-addition for SCell where applicable, all with a full L2 (and L1) reset, all involving more latency, more overhead and more disruption time than beam switching mobility. The goal of L1 / L2 mobility enhancements is to be able to do serving cell changes via L1 / L2 signaling with such low latency, low overhead and low disruption time.

[0673] 4. Goals

[0674] 4.1 Objectives of the Core WI

[0675] The detailed objectives of this work item are:

[0676] ○ Specify mechanisms and procedures for L1 / L2 based inter-cell mobility to reduce mobility latency:

[0677] -Configure and maintain multiple candidate cells to allow rapid application of candidate cell configuration [RAN2, RAN3]

[0678] - Dynamic switching mechanism between candidate serving cells (including SpCell and SCell) for potential applicable scenarios based on L1 / L2 signaling [RAN2, RAN1]

[0679] - L1 enhancements, including inter-cell beam management, L1 measurement and reporting, beam indication, and handling of asynchronous scenarios for TA management [RAN1, RAN2]

[0680] - CU-DU interface signalling to support L1 / L2 mobility (if required) [RAN3]

[0681] In the 3GPP specification 38.300 Operational CR for introducing further mobility enhancements for NR ([4] R2-2213332 38.300 Operational CR for introducing further mobility enhancements for NR), L1 / L2 Triggered Mobility (LTM) is introduced:

[0682] 9.2.3.x L1 / L2 Triggered Mobility

[0683] 9.2.3.x.1 Overview

[0684] LTM is a procedure where the gNB receives L1 measurement reports from the UE and based on them, the gNB changes the serving cell of the UE via MAC CE. The gNB prepares one or more candidate cells and provides the candidate cell configurations to the UE via RRC messages. Then, LTM cell switching is triggered by the gNB selecting one of the candidate configurations as the target configuration for LTM. Candidate cell configurations can only be added, modified and released by the network via RRC signaling.

[0685] Editor's note: Whether some optimizations such as release should be applied later is for further study.

[0686] Editor's Note: Current options for configuring LTM candidate cells:

[0687] a. An RRCReconfiguration message for a candidate target cell

[0688] b. One CellGroupConfig IE for each candidate target cell

[0689] The following principles apply to LTM:

[0690] -Candidate cell configurations may be provided as delta configurations on top of the reference configuration. The reference configuration is managed separately and the UE stores the reference configuration as a separate configuration.

[0691] - The user plane is continuous whenever possible (e.g., within a DU) without the need for reset to avoid data loss and additional delays in data recovery.

[0692] - Security is not updated in LTM.

[0693] - Subsequent LTM between candidates can be performed (ie, the UE does not release other candidate cell configurations after LTM triggering) without RRC reconfiguration.

[0694] LTM supports both intra-gNB-DU and intra-gNB-CU inter-gNB-DU mobility. LTM also supports inter-frequency mobility, including mobility to an inter-frequency cell other than the current serving cell. The following scenarios are supported:

[0695] - PCell change in non-CA scenario,

[0696] - PCell change in CA scenario without SCell change,

[0697] -PCell change and SCell change in CA scenario, including the following cases:

[0698] a) Target PCell / target SCell is not the current serving cell (CA to CA scenario with PCell change)

[0699] b) The target PCell is the current SCell

[0700] c) The target SCell is the current PCell.

[0701] - Dual connectivity scenarios, at least for PSCell change cases without MN participation, ie intra-SN.

[0702] Inter-cell beam management is also supported, but it is not considered a prerequisite for using LTM.

[0703] Editor's note: The design based on intra-DU and inter-DU L1 / L2 mobility should share as much commonality as possible. Which aspects need to be different is for further study.

[0704] Editor's note: Whether ASN.1 decoding and validity / compliance checking of the candidate cell configuration is performed after receiving it and whether this needs to be specified is for further study.

[0705] 9.2.3.x.2C Plane Disposal

[0706] The cell handover trigger information containing at least the candidate configuration index is transmitted in the MAC CE. The cell specific, radio bearer and measurement configurations may be part of the LTM candidate cell configuration.

[0707] Editor's note: Whether the MAC CE can indicate the TCI status (or other beam information) to be activated for the target cell is for further study.

[0708] Editor's note: Whether it should be possible to perform SCell activation / deactivation (in SC cells associated with the candidate configuration) at the same time as LTM triggers MAC CE is for further study.

[0709] The UE may perform CBRA or CFRA at cell handover. If the UE does not need to acquire the TA of the target cell during cell handover, the UE may also skip the random access procedure. RACH resources for CFRA are provided in the RRC configuration.

[0710] Editor's Note: Whether CFRA resources can be provided via MAC CE is for further study.

[0711] The overall procedure of LTM is shown in Figure x below. Subsequent LTMs are completed by repeating the early synchronization, LTM execution, and LTM completion steps without releasing other candidates after each LTM is completed.

[0712] Figure 6 This is a reproduction of Figure x in R2-2213332 38.300: Signaling procedure for LTM.

[0713] The LTM procedure is as follows.

[0714] 1.UE sends a MeasurementReport message to the gNB. The gNB decides to use LTM and initiates LTM candidate preparation.

[0715] The gNB transmits an RRCReconfiguration message containing the configuration of one or more LTM candidate target cells to the UE.

[0716] 3. The UE stores the configuration of the LTM candidate target cell and sends an RRCReconfigurationComplete message to the gNB.

[0717] 4. The UE may perform DL synchronization and TA acquisition of candidate target cells before receiving the LTM cell handover command.

[0718] Editor's note: Support for DL ​​synchronization of candidate cells prior to cell handover command, at least based on SSB. The required mechanisms are for further study.

[0719] Editor's note: At least based on PDCCH ordered RACH, support for TA acquisition of candidate cells before LTM cell handover command, where PDCCH command is only triggered by the source cell. The detailed mechanism is for further study.

[0720] 5. The UE performs L1 measurements on the configured LTM candidate target cells and transmits a lower layer measurement report to the gNB.

[0721] 6. The gNB decides to perform LTM cell handover to the target cell and transmits a MAC CE triggering LTM cell handover with a candidate configuration index of the target cell. The UE switches to the configuration of the LTM candidate target cell.

[0722] Editor's Note: How beam pointing is accomplished is for further study.

[0723] 7. If TA is not available, the UE performs a random access procedure towards the target cell.

[0724] 8. The UE indicates successful completion of the LTM cell handover towards the target cell.

[0725] An uplink signal or message after the UE has switched to the target cell is used to indicate the successful completion of the LTM cell handover.

[0726] 9.2.3.x.3U plane handling

[0727] In LTM, whether the UE performs a partial or full MAC reset, re-establishes RLC, and performs data recovery of PDCP during cell handover is explicitly controlled by the network.

[0728] Editor's Note: Regarding determining whether to reset L2: Two options on the table:

[0729] 1) The UE determines whether the handover is an intra-DU handover or an inter-DU handover, and follows different rules or configurations for the two cases to control whether to reset. The determination may be based on the configuration (e.g., DU ID, cell group id, etc.)

[0730] 2) The UE receives a command to reset or not reset via MAC CE.

[0731] Editor's note: Some of the reset content is subject to further research.

[0732] Editor's note: For UE processing, assume that the following (non-exhaustive) is performed after receiving the cell handover command:

[0733] 1.MAC / RLC reset (when configured)

[0734] 2.RF re-tuning (e.g., frequency switching required), baseband re-tuning

[0735] Editor's note: How the UE determines the BWP (for DL ​​and UL) to use after the execution of L1 / L2 inter-cell mobility is for further study.

[0736] In the 3GPP RAN1#110b-e meeting ([5] 3GPP RAN1#110b report), the following agreement was reached on obtaining the TA of candidate cells before LTM:

[0737] protocol

[0738] Candidate cell TA acquisition before receiving a cell handover command is supported in L1 / L2 based mobility.

[0739] • For further study: whether this can be applied to the candidate cell when the candidate cell is a deactivated SCell (if defined in RAN2).

[0740] From the GTW session on October 19th

[0741] protocol

[0742] Regarding the mechanism of obtaining the TA of the candidate cell, the following solutions can be further studied:

[0743] ●RACH-based solution

[0744] ○ For example, PDCCH ordered RACH, UE triggered RACH, higher layer triggered RACH from NW other than L3 HO cmd

[0745] ● RACH-free solution

[0746] ○ For example, SRS-based TA acquisition, Rx timing difference-based, RACH-free mechanism in LTE, UE-based TA measurement (including UE-based TA measurement where one of the TACs is from the serving cell)

[0747] protocol

[0748] For candidate cell TA acquisition before receiving a cell handover command, at least the following alternatives for associating TA / TAG with candidate cells are studied:

[0749] ●Alternative 1: implicitly associate TA / TAG with candidate cells, e.g.

[0750] ○The association between TA / TAG and TCI status can be configured

[0751] ●Alternative 2: Explicitly associate TA / TAG with candidate cells, e.g.

[0752] ○ Provide association as part of candidate cell configuration

[0753] ○ Provides the association between TA / TAG and SSB / TRS as part of candidate cell configuration

[0754] In the 3GPP RAN1#112 meeting ([6] 3GPP RAN1#112 report), the following agreement was reached regarding the PDCCH ordered RACH of candidate cells:

[0755] protocol

[0756] For PDCCH ordered RACH of candidate cells, RAR reception can be configured / indicated

[0757] ● If RAR reception is not configured / indicated (no RAR)

[0758] ○The TA value of the candidate cell is indicated in the cell handover command

[0759] ○ For further study: Should the UE retransmit PRACH when RAR reception is not configured / indicated?

[0760] ○ For further study: How does the UE determine the transmission power of the subsequent PRACH triggered by the PDCCH command?

[0761] If reception of RAR is configured / indicated (with RAR), then the following is for further study

[0762] ○ Is the RAR received from the serving cell or the candidate cell?

[0763] ■If the RAR is received from a candidate cell, is the Type1-PDCCH CSS of the candidate cell configured for the UE?

[0764] ○RAR content

[0765] ●For further study: Signaling for whether to receive RAR configuration / indication

[0766] ●UE can report support combination of using RAR only and without RAR, where support for one preset scheme is the baseline UE method for LTM

[0767] ● Send LS to RAN2 and RAN3 to check the feasibility of this protocol

[0768] ●Note: The definition of candidate cells depends on RAN2

[0769] protocol

[0770] ● For PDCCH command-based RACH for TA measurement of candidate cells, traditional CBRA is not supported

[0771] protocol

[0772] Select one of the following alternatives as to whether the UE should initiate PRACH retransmission when reception of RAR is not configured / indicated.

[0773] ● Alternative 1: Do not allow UE autonomous retransmissions of PRACH (e.g., by setting the number of allowed PRACH transmissions to PreambleTransMax minimum = 1)

[0774] ●Alternative 2: Allow UE autonomous retransmission of PRACH,

[0775] ○ The number of PRACH transmissions will be defined, for example, the number of RACH transmissions will be set to the minimum value of PreambleTransMax

[0776] protocol

[0777] If reception of a RAR is configured / indicated, the RAR contains at least the TA of the candidate cell.

[0778] The maximum number of TA values ​​that a UE can store is the UE's capability

[0779] ● To be further studied: whether RAR contains other parameters such as UE ID, candidate cell ID, etc.

[0780] protocol

[0781] Whether to receive RAR is configured by RRC.

[0782] In the RAN2#121bis meeting ([7] 3GPP RAN2#121bis report), an agreement was reached on LTM:

[0783] From the RAN2 perspective, in order to achieve shared preamble resources among multiple UEs, it is beneficial that information identifying the allocated CFRA resources (i.e., SS / PBCH index, RACH opportunity and random access preamble index) can be indicated in the PDCCH order (as a traditional intra-cell PDCCH order).

[0784] The RRC RACH configuration for early TA acquisition (eg, including whether RAR needs to be received) is specific to each target cell and is transmitted separately (separate IE) from the candidate cell configuration (the part that needs to be applied at cell handover).

[0785] R2 assumes that Early TA RACH option 3 (with RAR from candidate cells) is not needed in Rel-18.

[0786] R2 assumes that the RRCReconfigurationComplete message is always sent at every LTM execution.

[0787] In RACH-based LTM, the target cell is aware of the arrival of the UE based on the reception of the preamble in CFRA and based on the reception of Msg3 / MsgA in CBRA, similar to conventional HO.

[0788] In RACH-less LTM, the target cell is aware of the arrival of the UE based on receiving the first UL transmission from this UE.

[0789] In RACH-free LTM, RRCReconfigurationComplete can be the content of the first UL MAC PDU / transmission to indicate the UE arrival, i.e. no new signaling needs to be introduced to indicate the UE arrival (for MCG handover case)

[0790] For RACH-based LTM, the UE considers the LTM execution procedure to be successfully completed when RACH is successfully completed.

[0791] For RACH-free LTM, the UE considers the LTM execution procedure to be successfully completed when the UE determines that the NW has successfully received its first UL data.

[0792] The following behavior of the LTM monitoring timer is agreed upon:

[0793] -1: After receiving the LTM cell switching MAC CE, the UE immediately starts the LTM monitoring timer;

[0794] -2: After the LTM cell handover is successfully completed, the UE immediately stops the LTM monitoring timer;

[0795] -3: If the LTM monitoring timer of the MCG expires, then as a baseline, the UE considers LTM failure and initiates RRC re-establishment. (SCG handover is for further study).

[0796] The LTM monitoring timer is an RRC layer timer.

[0797] In case of RLF or LTM execution failure (for MCG), RAN2 intends to support fast recovery to candidate cells through LTM execution.

[0798] Although configured with LTM candidate cells, the UE may also execute any L3 handover command sent by the network. R2 assumes that any problems due to race conditions between LTM execution and RRC reconfiguration (e.g., L3 HO command) can be avoided by the network, for example, by avoiding sending LTM handover command and L3 HO command in the same TB.

[0799] In the 3GPP RAN2#122 meeting ([8] 3GPP RAN2#122 report), an agreement was reached on TA maintenance of candidate cells for LTM:

[0800] Dynamic grant can be used without RACH LTM for the first UL data transmission to the target cell:

[0801] -After LTM cell switching, the UE immediately monitors PDCCH to see if there is dynamic scheduling from the target cell.

[0802] -After the cell switching decision, R2 immediately assumes that the source DU informs the target DU of the selected beam so that the target DU can start scheduling dynamic UL grants.

[0803] Configured grants are available for RACH-free LTM for the first UL data transmission to the target cell, the UE selects the configured grant opportunity, which is associated with the beam indicated in the LTM MAC CE (set by the source cell). Additional optimizations are for further study.

[0804] If TA maintenance etc. for candidate cells in the UE is required, the TAs associated with the candidate cells may be maintained during LTM (exactly which cells decision phase 3 is pending).

[0805] In the work item MIMO evolution for downlink and uplink ([9] RP-223276 WID Update: MIMO evolution for downlink and uplink), multi-panel UL transmission for dual-TA multi-TRP operation is introduced:

[0806] 4. Goals

[0807] 4.1 Objectives of SI or core WI or test WI

[0808] The detailed objectives are as follows:

[0809] RAN1:

[0810] […]

[0811] 2. Specify extensions to the Rel-17 unified TCI framework for indicating multiple DL and UL TCI states, focusing on multi-TRP use cases, using the Rel-17 unified TCI framework.

[0812] […]

[0813] 6. Study and specify (if needed) the following items to facilitate simultaneous multi-panel UL transmissions for higher UL throughput / reliability, focusing on FR2 and multi-TRP, assuming up to 2 TRPs and up to 2 panels, targeting CPE / FWA / vehicles / industrial installations (if applicable)

[0814] - UL pre-coding indication for PUSCH, where no new codebook is introduced for simultaneous transmission of multiple panels

[0815] ● Considering multi-TRP operation based on single DCI and multi-DCI, the total number of layers for all panels is at most four, and the total number of codewords for all panels is at most two.

[0816] -UL beam indication for PUCCH / PUSCH, where multi-TRP operation based on single DCI and multi-DCI is considered, assuming the unified TCI framework extension in Objective 2

[0817] ●For the case of multi-TRP operation based on multi-DCI, only PUSCH+PUSCH or PUCCH+PUCCH is transmitted across two panels in the same CC.

[0818] 7. Study and specify (if reasonable) the following

[0819] - Two TAs for UL multi-DCI for multi-TRP operation

[0820] -Power control of UL single DCI for multi-TRP operation, assuming the unified TCI framework extension in Objective 2.

[0821] For the case of simultaneous UL transmissions from multiple panels, operation will be limited to Target 6 scenarios only.

[0822] In 3GPP specification 38.211 (

[10] 3GPP 38.211 v17.1.0), timing advance is introduced:

[0823] N TA Timing advance between downlink and uplink; see clause 4.3.1

[0824] N TA，offset Fixed offset used to calculate timing advance; see clause 4.3.1

[0825] 4.3.1 Frame and Subframe

[0826] Downlink, uplink and sidelink transmissions are organized into f =(Δf max N f / 100)·T c = 10ms duration frame, each frame consists of T sf=(Δf max N f / 1000)·T c =10 subframes of 1ms duration. The number of consecutive OFDM symbols per subframe is Each frame is divided into two equally sized half-frames of five sub-frames, each with half-frame 0 consisting of sub-frames 0-4 and half-frame 1 consisting of sub-frames 5-9.

[0827] On a carrier, there is a set of frames in the uplink and a set of frames in the downlink.

[0828] The uplink frame number i for transmission from the UE should precede the start of the corresponding downlink frame at the UE Start, where

[0829] -N TA and N TA，offset Given in clause 4.2 of [5, TS 38.213], except for msgA transmission on PUSCH, where N TA =0;

[0830] - is derived from the high-level parameters TACommon, TACommonDrift, and TACommonDriftVariation (if configured), otherwise

[0831] - is calculated by the UE based on the UE position and the serving satellite ephemeris related higher layer parameters (if configured), otherwise

[0832] Figure 7 It is in 3GPP 38.211v17.1.0 Figure 4 .3.1-1: Reproduction of uplink-downlink timing relationship.

[0833] In the RAN2#123 meeting (

[11] Report R2-2308972 from the NR MIMO Evolution Session), the protocol for the random access procedure with additionalPCI was introduced:

[0834] Working hypothesis:

[0835] We will use the 2-PTAG model, that is, both TAGs of SpCell are PTAGs;

[0836] ■When the TAT of the STAG expires and another TAT is in operation for the serving cell (i.e., SCell), the running TAT has no effect on the TRP; 1 and 7 are applied to the TRP of TAT expiration, and whether 2-6 are applied to the TRP of STAT expiration is for further study.

[0837] ■When the TAT of PTAG expires and another TAT is in operation for the serving cell (SpCell or SCell), the running TAT has no effect on TRP; 1 and 7 are applied to TRP with expired TAT, and whether 2-6 are applied to TRP with expired TAT needs further study.

[0838] For the inter-cell PDCCH command CFRA for additionalPCI,

[0839] ■The PDCCH command indicates which additionalPCI PRACH configuration to use (according to the RAN1 protocol),

[0840] In New Radio (NR), a user equipment (UE) performs a handover procedure to switch from one cell (e.g., a source cell) to another cell (e.g., a target cell). The UE performs the handover procedure in response to radio resource control (RRC) signaling transmitted by the network. The RRC signaling contains cell information of the target cell. The network determines to initiate the handover procedure based on the UE's measurement report. Changes to the primary cell (PCell) and the primary secondary cell (PSCell) (primary cell in a secondary cell group (SCG)) via reconfiguration with synchronization (e.g., involving layer 3 RRC messages) involve high latency and more overhead than L1 / L2 signaling (e.g., beam switching mobility). In addition, when operating on FR2, frequent SCG changes will occur, which will also result in high latency in UE-network (NW) communications if L3 handover is used. Therefore, in the work item description (WID) for NR mobility enhancement ([3] RP-212710 New WID for NR Further Mobility Enhancement), the goal of the work item is to specify mechanisms and procedures (e.g., L1 / L2 triggered mobility (LTM) procedures) for a dynamic switching mechanism based on L1 / L2 signaling among a serving cell including a special cell (SpCell) and / or a secondary cell (SCell). The serving cell may include a target cell for the LTM procedure and one or more SCells (to be added or released) in the LTM procedure. The LTM procedure may include a next generation NodeB (gNB) of the source cell providing first information and second information. The first information may contain or indicate candidate cell information (e.g., candidate cell configuration) (via RRC messages). The first information may contain or indicate one or more RRC reconfiguration messages associated with one or more candidate cells (or candidate cell groups). For example, the first information may contain or indicate a cell configuration and / or a random access channel (RACH) configuration of one or more candidate cells. The first information may contain one or more RRCreconfiguration messages, each RRCreconfiguration message being configured for a candidate (cell) associated with a candidate cell. The second information may not be an RRC or L3 message (e.g., may contain a physical downlink control channel (PDCCH) and / or a media access control (MAC) control element (CE)), and may instruct the UE to perform an LTM procedure on a candidate cell (group) (in one or more candidate cells in the first information). The second information may be an LTM switching command or a cell switching command (e.g., a downlink control indicator / indication (DCI) and / or a MAC CE). The candidate cell may be a target cell for the LTM procedure. Each of the one or more candidate cells may be associated with an identity or index (e.g., a candidate index). The second information may indicate a candidate index of the candidate cell.

[0841] For LTM, both RACH-based LTM and RACH-less LTM will be supported.For RACH-based LTM, the UE initiates / performs a random access procedure to a target cell in the LTM procedure (in response to receiving a cell handover command to handover to the target cell). Figure 8 The right part of is an example.

[0842] For RACH-free LTM, the UE may not initiate or perform a random access procedure to the target cell in response to receiving a cell handover command (MACCE) to handover to the target cell. The UE may obtain the TA associated with the target cell via an early TA acquisition procedure on a candidate cell including the target cell. The early TA acquisition may include or contain the UE initiating a random access procedure or performing a random access preamble transmission on the target cell (before receiving a cell handover command for the target cell). Figure 8 The left part of is an example. The UE may obtain the TA associated with the target cell in response to the completion of the early TA acquisition. Alternatively, the UE may not obtain the TA associated with the target cell, and the network may store the TA (and indicate it to the UE in the cell handover command). In this case, the UE does not know whether the random access procedure for early TA acquisition is successful due to the absence of random access response (RAR) reception.

[0843] Additionally and / or alternatively, the network may not provide or transmit a cell switching command to the UE to initiate LTM to the candidate cell.The UE may determine to initiate an LTM procedure switch to the candidate cell based on a condition (eg, conditional LTM).

[0844] In NR, multiple transmission / reception point (mTRP) operation is introduced. The UE can perform downlink (DL) and / or uplink (UL) transmissions on different TRPs in the same cell (intra-cell mTRP) or different TRPs in different cells (inter-cell mTRP) (via different panels). For inter-cell mTRP, the UE can be configured to use one or more non-serving cells associated with the serving cell. The non-serving cells may be associated with an additional physical cell identity (PCI) that is different from the PCI associated with any serving cell. In Rel-18 NR, two TAs for UL multi-DCI for multi-TRP operation are introduced. The UE can perform downlink (DL) and / or uplink (UL) transmissions on different TRPs in the same cell (intra-cell mTRP) or different TRPs in different cells (inter-cell mTRP). For inter-cell mTRP, the UE can be configured to use one or more non-serving cells associated with the serving cell. The non-serving cells may be associated with an additional physical cell identity (PCI) that is different from the PCI associated with any serving cell. In Rel-18 NR, two TAs for UL multi-DCI for multi-TRP operation are introduced. The UE can perform multi-TRP operation by applying different TA values ​​or N TAUL transmission is performed on two different TRPs. The UE may perform inter-cell or intra-cell multi-TA mTRP operation. For inter-cell mTRP, the UE may perform UL transmission on a first TRP associated with / on a serving cell and a second TRP associated with / on a non-serving cell, the non-serving cell being associated with / configured in the serving cell. When the UE does not have valid TA information or a valid TA value for the TRP / UL, the UE may initiate a random access procedure on the TRP. Additionally and / or alternatively, the UE may be instructed by the network (e.g., via a PDCCH command) to perform / initiate a random access procedure on the TRP. The TRP may be associated with a non-serving cell. The non-serving cell may be indicated by a PDCCH command, and / or may be an active non-serving cell.

[0845] In NR Rel-16, random access (RA) information request and response were introduced. The UE can be instructed / requested by the network to report a RA report indicating random access information associated with a random access procedure initiated by the UE. In Rel-17, in order for the network to forward the RA report to correct other networks, the UE includes the Master Cell Group (MCG) / SCG SpCell information in the RA-report.

[0846] In response to a successfully executed random access procedure, the UE may store or append a RA report containing random access information in a list of RA-reports (e.g., ra-ReportList). The RA report may contain a cell identity (Id) associated with the random access procedure. The RA report may contain the purpose of the associated random access procedure. The RA report may contain ra-InformationCommon. ra-InformationCommon may contain subcarrier spacing, frequency and / or channel state information reference signal (CSI-RS) associated with the random access procedure. For random access procedures initiated for candidate cells and / or LTM and / or non-serving cells, how to perform UE information reporting on the random access procedure is not specified. According to [2] 3GPP38.331v17.4.0, information for the random access procedure for early TA acquisition is not stored / recorded because the UE cannot know whether the random access procedure for early TA acquisition is successful due to the absence of RAR reception. In addition, the existing raPurpose (without modification) does not apply to this case.

[0847] Through the present invention, a method for handling RA reports of random access procedures associated with L1 / L2 triggered mobility and random access procedures associated with inter-cell multi-TRP operations is introduced, as described in detail below.

[0848] RA-report

[0849] - Case 1: RA for early TA acquisition.

[0850] - Case 2: RA-based LTM (triggered by NW).

[0851] - Case 3: RA-based conditional LTM.

[0852] - For each case, whether to use an existing purpose or introduce a new one.

[0853] - For each case, whether to indicate spCellID.

[0854] - For each case, the content of RA-InformationCommon, e.g., whether case 1 requires perRAInfoList.

[0855] -Successful switch reporting of LTM.

[0856] - Case 4: Inter-cell mTRP RACH on additionalPCI

[0857] Purpose: Unsynchronized UL or other

[0858] information:

[0859] 1. Indicate additionalPCI in cellID-r16 / pci-arfcn and indicate serving cell in SpCell ID or in another information element (IE).

[0860] How to determine the frequency in IE PCIarFcN for additionalPCI.

[0861] 2. Indicate the serving cell in cellID-r16 and indicate additionalPCI in another IE (eg, indicating options / conditions).

[0862] Indicates the index or phyid used for additionalPCI.

[0863] For each case, whether to use an existing purpose or introduce a new one

[0864] One concept of the present invention is that the UE may store random access information (or random access information, or RA information) associated with a random access procedure (or Random Access procedure, or RA procedure) for a candidate cell. The UE may store random access information associated with early TA acquisition (before an LTM cell handover command) on a candidate cell.

[0865] Additionally and / or alternatively, for a random access procedure for a candidate cell, the UE may set / indicate a purpose associated with the random access procedure in the random access information. The UE may determine which / what purpose to set / indicate based at least on the type of the random access procedure. The random access procedure may be initiated to be performed on the RACH.

[0866] The candidate cell may be a target cell in an LTM procedure (either in response to a cell handover command to a candidate cell or in response to a UE initiated condition).

[0867] The candidate cell may be associated with a candidate configuration in the LTM configuration. The candidate cell may be a SpCell (eg, PCell) of the candidate configuration.

[0868] The random access information may be a RA report (eg, RA-report-r16).

[0869] The UE may attach random access information associated with the random access procedure in response to successful completion or successful execution of the random access procedure.

[0870] The UE may be instructed / requested by the network to report random access information to the network. The UE may report a list of random access information (e.g., ra-ReportList) in response to the request. The network may transmit a UE information request (e.g., UEInformationRequest) to the UE to request the UE to report random access information to the network.

[0871] Case 1: RA for early TA acquisition

[0872] The type of random access procedure for the candidate cell may be (associated with) early TA acquisition for the candidate cell. The random access procedure may be initiated by a PDCCH order. The random access procedure may not contain (monitor or receive) RAR.

[0873] For the random access procedure for candidate cells for early TA acquisition of candidate cells, the UE may set / indicate the purpose as the first new purpose (e.g., 'early TA acquisition'). The first new purpose may not be any of 'accessRelated', 'beamFailureRecovery', 'reconfigurationWithSync', 'ulUnSynchronized', 'schedulingRequestFailure', 'noPUCCHResourceAvailable', 'requestForOtherSI', or 'msg3RequestForOtherSI-r17'.

[0874] Additionally and / or alternatively, for a random access procedure to a candidate cell for early TA acquisition of the candidate cell, the UE may set / indicate the purpose to 'LTMRelated'.

[0875] The purpose 'LTMRelated' may apply to (all) random access procedures associated with a candidate cell. The purpose 'LTMRelated' may indicate that the random access procedure is associated with a candidate cell and / or is associated with an LTM procedure.

[0876] Additionally and / or alternatively, for a random access procedure to a candidate cell for early TA acquisition of the candidate cell, the UE may set / indicate the purpose as 'accessRelated'.

[0877] Additionally and / or alternatively, for the random access procedure to the candidate cell for early TA acquisition of the candidate cell, the UE may set / indicate the purpose as 'reconfigurationWithSync'.

[0878] Additionally and / or alternatively, for the random access procedure to a candidate cell for early TA acquisition of the candidate cell, the UE may set / indicate the purpose as 'ulUnSynchronized'.

[0879] Without storing the random access information associated with the random access procedure for early TA acquisition, the network cannot distinguish between RACH failure caused by the UE not receiving the PDCCH order or RACH failure caused by the network not receiving the preamble. The network can accurately know whether to optimize the candidate cell RACH configuration (e.g., failure caused by serving cell beam management) based on the random access information.

[0880] Case 2: RA-based LTM (triggered by NW)

[0881] Additionally and / or alternatively, the type of random access procedure for the candidate cell may be a (LTM) random access procedure for the candidate cell in response to receiving a (LTM) cell switching command from the network. The UE may determine whether to initiate a random access procedure to the candidate cell in response to receiving the (LTM) cell switching command, based at least on whether the UE has / maintains / stores valid TA information associated with the candidate cell. If or when the UE does not have / maintains / stores valid TA information associated with the candidate cell, the UE may determine to initiate a random access procedure to the candidate cell in response to receiving the (LTM) cell switching command. If or when the UE has / maintains / stores valid TA information associated with the candidate cell, the UE may not initiate a random access procedure to the candidate cell in response to receiving the (LTM) cell switching command.

[0882] For the random access procedure for the candidate cell in response to receiving a (LTM) cell handover command, the UE may set / indicate the purpose to a second new purpose (e.g., 'NWtriggeredLTM'). The second new purpose may not be any of 'accessRelated', 'beamFailureRecovery', 'reconfigurationWithSync', ulUnSynchronized', schedulingRequestFailure', 'noPUCCHResourceAvailable', 'requestForOtherSI', or 'msg3RequestForOtherSI-r17'.

[0883] For a (LTM) random access procedure for a candidate cell in response to receiving a (LTM) cell handover command from the network, the UE may set / indicate the purpose as 'NWtriggeredLTM'. The purpose set for the LTM random access procedure in response to receiving a (LTM) cell handover command may be different from the purpose set for the LTM random access procedure initiated by the UE (itself, based on a condition).

[0884] Additionally and / or alternatively, for a (LTM) random access procedure to a candidate cell in response to receiving a LTM cell handover command from the network, the UE may set / indicate the purpose to 'LTMRelated'.

[0885] The purpose 'LTMRelated' may apply to (all) random access procedures associated with a candidate cell.

[0886] Additionally and / or alternatively, for a random access procedure to a candidate cell in response to receiving a (LTM) cell handover command from the network, the UE may set / indicate the purpose as 'accessRelated'.

[0887] Additionally and / or alternatively, for a random access procedure to a candidate cell in response to receiving a (LTM) cell handover command from the network, the UE may set / indicate the purpose as 'reconfigurationWithSync'.

[0888] Additionally and / or alternatively, for a random access procedure to a candidate cell in response to receiving a (LTM) cell handover command from the network, the UE may set / indicate the purpose to 'ulUnSynchronized'.

[0889] Case 3: RA-based conditional LTM

[0890] Additionally and / or alternatively, the type of the random access procedure may be a (LTM) random access procedure initiated by the UE (itself, based on a condition) to a candidate cell. Fig. 9 is an example. The UE may not receive a (LTM) cell switching command associated with or indicating a candidate cell from the network (before initiating a random access procedure to the candidate cell). The UE may determine whether to initiate a random access procedure to the candidate cell in response to a condition being met, based at least on whether the UE has / maintains / stores valid TA information associated with the candidate cell. If or when the UE does not have / maintains / stores valid TA information associated with the candidate cell, the UE may determine to initiate a random access procedure to the candidate cell in response to the condition being met. If or when the UE has / maintains / stores valid TA information associated with the candidate cell, the UE may not initiate a random access procedure to the candidate cell in response to the condition being met.

[0891] For the random access procedure initiated by the UE (itself, based on a condition) for the candidate cell, the UE may set / indicate the purpose as the third new purpose (e.g., 'UEtriggeredLTM'). The third new purpose may not be any of 'accessRelated', 'beamFailureRecovery', 'reconfigurationWithSync', 'ulUnSynchronized', 'schedulingRequestFailure', 'noPUCCHResourceAvailable', 'requestForOtherSI', or 'msg3RequestForOtherSI-r17'.

[0892] Additionally and / or alternatively, for a UE initiated (LTM) random access procedure to a candidate cell, the UE may set / indicate the purpose as 'LTMRelated'.

[0893] The purpose 'LTMRelated' may apply to (all) random access procedures associated with / for a candidate cell.

[0894] Additionally and / or alternatively, the first, second and third new purposes are the same.

[0895] Additionally and / or alternatively, the second and third new purposes are the same.The second and third new purposes may be different from the first new purpose.

[0896] Additionally and / or alternatively, for a random access procedure initiated by the UE (by itself, based on a condition) to a candidate cell, the UE may set / indicate the purpose as 'accessRelated'.

[0897] Additionally and / or alternatively, for a random access procedure initiated by the UE (by itself, based on a condition) to a candidate cell, the UE may set / indicate the purpose as 'reconfigurationWithSync'.

[0898] Additionally and / or alternatively, for a random access procedure initiated by the UE (by itself, based on a condition) to a candidate cell, the UE may set / indicate the purpose as 'ulUnSynchronized'.

[0899] Additionally and / or alternatively, the UE may set / indicate the same purpose for a UE-initiated random access procedure to a candidate cell and a random access procedure to a candidate cell in response to a (LTM) cell handover command received from the network.

[0900] Whether to indicate SpCell ID

[0901] The UE may indicate the SpCell identity in the random access information. Additionally and / or alternatively, the UE may determine whether to indicate the SpCell identity (in the random access information) based at least on the type of random access procedure.

[0902] If or when the candidate cell is configured in a candidate configuration associated with an MCG, the SpCell identity may be the (physical cell or global cell) id of the (MCG's) PCell (before the LTM procedure is completed). If or when the candidate cell is configured in a candidate configuration associated with an SCG, the SpCell identity may be the (physical cell or global cell) id of the SpCell (e.g., the SCG's PSCell) (before the LTM procedure is completed).

[0903] For example, the UE may indicate the SpCell identity if or when the type of random access procedure is as follows:

[0904] - Early TA acquisition for candidate cells; and / or

[0905] - a (LTM) random access procedure for a candidate cell in response to receiving a (LTM) cell handover command from the network; and / or

[0906] - A random access procedure initiated by the UE (itself, based on a condition) to a candidate cell.

[0907] Additionally and / or alternatively, the UE may not indicate the SpCell identity if or when the type of random access procedure is as follows:

[0908] - Early TA acquisition for candidate cells; and / or

[0909] - a (LTM) random access procedure for a candidate cell in response to receiving a (LTM) cell handover command from the network; and / or

[0910] - A random access procedure initiated by the UE (itself, based on a condition) to a candidate cell.

[0911] For example, if or when the random access procedure is for early TA acquisition of a candidate cell, the UE may indicate the SpCell identity (associated with the candidate cell) in the random access information. If or when the random access procedure is an LTM random access procedure for a candidate cell (in response to receiving a (LTM) cell handover command from the network or initiated by the UE itself based on a condition), the UE may not indicate the SpCell identity (associated with the candidate cell) in the random access information.

[0912] For each case, the content of RA-InformationCommon, for example, whether case 1 requires perRAInfoList

[0913] Additionally and / or alternatively, the UE may determine whether to indicate or include one or more parameters in the random access information based at least on the type of random access procedure. Additionally and / or alternatively, for a random access procedure for early TA acquisition of a candidate cell, the UE may not indicate or include one or more parameters in the random access information. Additionally and / or alternatively, for (initiated) (any) random access procedure other than early TA acquisition for a candidate cell, the UE may indicate or include one or more parameters in the random access information.

[0914] One or more parameters may be perRAInfoList. For example, if or when the random access procedure is an early TA acquisition of a candidate cell, the UE may not include perRAInfoList. If or when the random access procedure is a (LTM) random access procedure for a candidate cell (in response to a (LTM) cell handover command or initiated by the UE), the UE may include perRAInfoList.

[0915] Additionally and / or alternatively, one or more parameters may be RA-InformationCommon.

[0916] Additionally and / or alternatively, one or more parameters may be contentionDetected.

[0917] Additionally and / or alternatively, one or more parameters may be dlRSRPAboveThreshold.

[0918] Additionally and / or alternatively, one or more parameters may be fallbackToFourStepRA.

[0919] Additionally and / or alternatively, if or when the random access procedure is for early TA acquisition of a candidate cell, there may be (only) one entry in perRAInfoList.

[0920] Additionally and / or alternatively, the one or more parameters may be numberOfPreamblesSentOnSSB.

[0921] If or when the random access procedure is for early TA acquisition, the UE may (only) set the value of one or more parameters to '1'. The value may be indicated in the PDCCH order initiating / triggering the random access procedure.

[0922] Additionally and / or alternatively, the UE may not include, append or store information associated with the random access procedure for early TA acquisition in the random access information. The UE may not report information associated with the random access procedure for early TA acquisition in the RA-report.

[0923] Additionally and / or alternatively, the UE may include, append or store information associated with a random access procedure for early TA acquisition in the random access information.

[0924] The UE may include or append or store in (the same entry of) the (same) random access information information information associated with one or more random access procedures for early TA acquisition for the same candidate cell. The UE may add or update the random access information (of the same candidate cell) in response to or for each random access procedure of the candidate cell. For example, information on retransmissions (or the number of preamble transmissions) of a random access preamble to a candidate cell triggered by a subsequent PDCCH command is stored in the same random access information (which is the same random access information storing information associated with a random access procedure with an initial preamble transmission on the candidate cell).

[0925] The information may include IEs and / or parameters in RA-Report and / or in ra-InformationCommon.

[0926] Additionally and / or alternatively, the UE may include, append or store information of each random access procedure for early TA acquisition for the same candidate cell in different random access information (or in different entries of the random access information).

[0927] The entry may be an entry in VarRA-Report or ra-ReportList.

[0928] For example, the UE may receive a first PDCCH command (for early TA acquisition) indicating a first random access preamble transmission to a candidate cell. The UE may receive a second PDCCH command (for early TA acquisition) indicating a second random access preamble transmission (e.g., a retransmission) to the candidate cell. The UE may include information about the first random access preamble transmission and information about the second random access preamble transmission in the same entry (e.g., the same RA-report or the same ra-InformationCommon (of the same RA-report)) or in different entries in the random access information. The first PDCCH command may indicate that a power ramp is not required for the first random access preamble transmission. The second PDCCH command may indicate that a power ramp is required for the second random access preamble transmission.

[0929] Indicate LTM success in successHO-Report

[0930] Additionally and / or alternatively, the UE may store LTM procedure information associated with the LTM procedure in a report (in response to successful completion of the LTM procedure). For example, the UE may store LTM procedure information associated with the LTM procedure (e.g., random access information) in a report in response to successful completion of a random access procedure associated with the LTM procedure. The LTM procedure may contain the UE switching its SpCell (e.g., PCell) to a candidate cell (without RRC reconfiguration with synchronization).

[0931] The report may be a VarSuccessHO-Report. Alternatively, the report may be a report different from the VarSuccessHO-Report (eg, a successLTM report).

[0932] The UE may be requested to transmit a report to the network in response to a request by the network.

[0933] The LTM procedure information may indicate a cell radio network temporary identifier (C-RNTI) associated with the candidate cell.

[0934] The LTM procedure information may indicate a C-RNTI associated with a source cell (eg, SpCell before the LTM procedure).

[0935] The LTM program information may indicate an LTM candidate configuration index.

[0936] The LTM procedure information may not indicate the PCell associated with Reconfigurationwithsync.

[0937] The LTM procedure information may indicate a purpose or reason associated with the LTM procedure. For example, the purpose or reason may be 'NW initiated' or 'UE initiated'.

[0938] The random access procedure may not be a random access procedure for early TA acquisition.

[0939] A report can be a list of LTM program information (or one LTM program information).

[0940] Situation: Inter-cell mTRP RACH on additionalPCI

[0941] Additionally and / or alternatively, the type of the random access procedure may be a random access procedure on a non-serving cell.For the random access procedure on a non-serving cell, the UE may indicate parameters and / or purpose associated with the random access procedure in the random access information.

[0942] The random access procedure may be initiated by a PDCCH command. The PDCCH command may indicate a RACH configuration and / or RACH resources associated with a non-serving cell. The PDCCH command may instruct the UE to perform a random access procedure on a non-serving cell (e.g., via a bit field or via a non-serving cell index). The non-serving cell may be associated with an additional PCI of the serving cell and / or associated with an additional PCI index of the serving cell.

[0943] Additionally and / or alternatively, the random access procedure may be initiated by the UE (itself). The UE may determine to initiate the random access procedure based on whether the TA is valid for the (activated) non-serving cell (when or if the UE is activated for the non-serving cell or the UE is instructed to perform inter-cell mTRP operation with the non-serving cell).

[0944] A non-serving cell may be a cell associated with a different PCI than (any) serving cell configured for / associated with the UE. A non-serving cell may be associated with an additional PCI than a serving cell configured for / associated with the UE.

[0945] A non-serving cell may be associated with a TRP. A non-serving cell may be an activated non-serving cell. A UE may perform inter-cell multi-TRP (mTRP) operations on a non-serving cell (via a TRP) and a serving cell (associated with a non-serving cell).

[0946] The UE may maintain two (uplink) TAs, one for the non-serving cell and one for the serving cell.

[0947] For the random access procedure on the non-serving cell, the UE may set / indicate the purpose (in the random access information) to the first new purpose (e.g., 'inter-cell mTRP related' or 'inter-cell multi-TA mTRP related'). The first new purpose may not be any of 'accessRelated', 'beamFailureRecovery', 'reconfigurationWithSync', ulUnSynchronized', 'schedulingRequestFailure', 'noPUCCHResourceAvailable', 'requestForOtherSI', or 'msg3RequestForOtherSI-r17'.

[0948] Additionally and / or alternatively, for the random access procedure on a non-serving cell, the UE may set / indicate the purpose as 'mTRP related or 'inter-cell mTRP related'.

[0949] The purpose 'mTRP-related' or 'inter-cell mTRP-related' may apply to (all) random access procedures associated with non-serving cells. The purpose 'mTRP-related' or 'inter-cell mTRP-related' may indicate that the random access procedure is associated with an inter-cell multi-TRP operation.

[0950] Additionally and / or alternatively, for the random access procedure on a non-serving cell, the UE may set / indicate the purpose as 'accessRelated'.

[0951] Additionally and / or alternatively, for the random access procedure on a non-serving cell, the UE may set / indicate the purpose to 'ulUnSynchronized'.

[0952] The random access information may be a RA report (eg, RA-report-r16).

[0953] The UE may attach random access information associated with the random access procedure in response to successful completion or successful execution of the random access procedure.

[0954] The UE may be instructed / requested by the network to report random access information to the network. The UE may report a list of random access information (e.g., ra-ReportList) in response to the request. The network may transmit a UE information request (e.g., UEInformationRequest) to the UE to request the UE to report random access information to the network.

[0955] Indicate additional PCI in cellID (and indicate serving cell in SpCell ID or in another IE)

[0956] Additionally and / or alternatively, the UE may determine how to set the content associated with the cell id in the random access information based on the type of the random access procedure.

[0957] If or when the random access procedure is a random access procedure on a non-serving cell, the UE may set one or more IDs associated with the non-serving cell. The UE may set the value of the additional PCI associated with the non-serving cell in a parameter or IE (e.g., cellId-r16 or cellGlobalId-r16 or pci-arfcn-r16 or physCellId-r16 in PCI-ARFCN-NR-r16) in the random access information. Additionally and / or alternatively, the UE may indicate in the random access information that the random access procedure is performed on a non-serving cell (e.g., via an optional parameter).

[0958] The UE may set the value of the frequency information in the random access information (e.g., pci-arfcn-r16 or carrierFreq-r16 in PCI-ARFCN-NR-r16) to the frequency of the non-serving cell or the frequency of the serving cell associated with the non-serving cell. The UE may perform inter-cell mTRP operations with the serving cell (the first TRP on) and the non-serving cell (the second TRP on). Additionally and / or alternatively, the UE may indicate an index associated with the non-serving cell (e.g., AdditionalPCIIndex) in the random access information. The UE may not indicate the PCI associated with the non-serving cell.

[0959] Additionally and / or alternatively, the UE may indicate or include one or more IDs (e.g., PCI, or CGI-Info-Logging-r16 or identity in CGI-Info-Logging) or indexes (e.g., serving cell index) associated with the serving cell in the random access information (as a supplement to the parameter or IE indicating the additional PCI). Additionally and / or alternatively, for a random access procedure on a non-serving cell (configured for the serving cell), the UE may include or indicate the serving cell in spCellID-r17.

[0960] If the serving cell is a SpCell, the UE may include or indicate the serving cell in the spCellID-r17 of the random access information.

[0961] If the serving cell is an SCell, the UE may include or indicate the serving cell in a new ID or parameter (in addition to spCellID-r17) in the random access information. The SpCell of the SCell may be indicated in the spCellID-r17 of the random access information. Alternatively, the SpCell of the SCell may not be indicated in the random access information (spCellID-r17).

[0962] Indicate the serving cell in cellID-r16 and additionalPCI in another IE (e.g. with options / conditions)

[0963] Additionally and / or alternatively, if or when the random access procedure is a random access procedure on a non-serving cell, the UE may set one or more IDs associated with the serving cell (associated with the non-serving cell). The UE may set the value of one or more IDs associated with the serving cell in a parameter or IE (e.g., cellId-r16 or cellGlobalId-r16 or physCellId-r16 in PCI-ARFCN-NR-r16) in the random access information. The UE may set the value of the frequency information (e.g., pci-arfcn-r16 or carrierFreq-r16 in PCI-ARFCN-NR-r16) in the random access information to the frequency of the serving cell associated with the non-serving cell. The UE may perform inter-cell mTRP operations with the serving cell (the first TRP on) and the non-serving cell (the second TRP on). Additionally and / or alternatively, the UE may indicate an index associated with the serving cell (e.g., ServingCellIndex or ServCellIndex) in the random access information. The UE may not indicate the PCI associated with the serving cell.

[0964] Additionally and / or alternatively, the UE may indicate or include information associated with the non-serving cell (e.g., one or more IDs or indices) in the random access information (as a supplement to the parameter or IE indicating the cell ID (of the serving cell). The UE may determine whether to include an IE or parameter in the random access information for the random access procedure based on whether the random access procedure is on a non-serving cell. The IE or parameter may indicate information associated with the non-serving cell. For example, the IE or parameter may indicate the frequency and / or additional PCI of the non-serving cell. For another example, the IE or parameter may indicate a serving cell associated with the non-serving cell. If or when the random access procedure is not performed on a non-serving cell, the UE may not indicate the IE or parameter.

[0965] Additionally and / or alternatively, for a random access procedure on a non-serving cell (configured for the serving cell), the UE may include or indicate the non-serving cell in spCellID-r17.

[0966] Additionally and / or alternatively, if or when the random access procedure is on a non-serving cell, the UE may indicate the SpCell identity (associated with the serving cell or the non-serving cell) in the random access information. Alternatively, if or when the random access procedure is on a non-serving cell, the UE may not indicate the SpCell identity (associated with the serving cell or the non-serving cell) in the random access information.

[0967] If the serving cell is an SCell, the SpCell of the SCell may be indicated in the spCellID-r17 of the random access information. Alternatively, the SpCell of the SCell may not be indicated in (the spCellID-r17 of) the random access information.

[0968] Additionally and / or alternatively, the UE may indicate or include information (e.g., one or more IDs or indices) associated with the non-serving cell in RA-InformationCommon (in the random access information). The one or more IDs or indices may indicate (in RA-InformationCommon) the non-serving cell associated with one or more beams (e.g., synchronization signal blocks (SSBs) or CSI-RS) used for the random access procedure.

[0969] For each case, the content of RA-InformationCommon, e.g., whether perRAInfoList is required

[0970] Additionally and / or alternatively, the UE may determine whether to indicate or include one or more parameters in the random access information based at least on the type of the random access procedure. Additionally and / or alternatively, for a random access procedure on a non-serving cell, the UE may not indicate or include one or more parameters in the random access information.

[0971] One or more parameters may be perRAInfoList. For example, if or when the random access procedure is on a non-serving cell, the UE may not include perRAInfoList.

[0972] Additionally and / or alternatively, one or more parameters may be RA-InformationCommon.

[0973] Additionally and / or alternatively, one or more parameters may be contentionDetected.

[0974] Additionally and / or alternatively, one or more parameters may be dlRSRPAboveThreshold.

[0975] Additionally and / or alternatively, one or more parameters may be fallbackToFourStepRA.

[0976] Additionally and / or alternatively, if or when the random access procedure is on a non-serving cell, there may be (only) one entry in perRAInfoList.

[0977] Additionally and / or alternatively, the UE may include, append or store information associated with a non-serving cell in the random access information.

[0978] For the random access procedure on the non-serving cell, the UE may include, append or store information associated with one or more random access procedures in (the same entry of) the random access information.

[0979] The information may include IEs and / or parameters in RA-Report and / or in ra-InformationCommon.

[0980] Additionally and / or alternatively, the UE may include, append or store information of each random access procedure on the same non-serving cell in different random access information (or in different entries of the random access information).

[0981] The entry may be an entry in VarRA-Report or ra-ReportList.

[0982] For example, the UE may receive a first PDCCH command indicating a first random access preamble transmission to a non-serving cell. The UE may receive a second PDCCH command indicating a second random access preamble transmission to a non-serving cell (for early TA acquisition). The UE may include information about the first random access preamble transmission and information about the second random access preamble transmission in the same entry or in different entries in the random access information.

[0983] Based on the concepts and examples above and herein, the following aspects and embodiments are possible.

[0984] The random access information may be ra-ReportList, RA-report-r16, or VarRA-Report or may be included therein.

[0985] The UE may indicate / generate random access information in response to a request from the network. The request may be successHO-ReportReq or mobilityHistoryReportReq or ra-ReportReq.

[0986] The random access procedure associated with the candidate cell may contain a random access procedure for early TA acquisition and / or an LTM random access procedure triggered by the network and / or an LTM random access procedure initiated by the UE (based on a condition). (Part of) the random access procedure associated with the candidate cell may be provided / configured as a candidate configuration or an LTM configuration associated with the candidate cell.

[0987] The LTM random access procedure for the candidate cell may be a random access procedure for switching the SpCell / PCell of the UE to the candidate cell (associated with the LTM candidate configuration). The LTM random access procedure for the candidate cell may be associated with or in the LTM procedure for the candidate cell. The LTM random access procedure may be initiated by the network (e.g., via a cell handover command) or by the UE (e.g., via a condition).

[0988] The candidate cell may be a (primary) cell in a candidate cell group configuration. The candidate cell may be a target cell in a LTM procedure or (random access procedure of) early TA acquisition. The candidate cell may not be a serving cell.

[0989] The candidate cell group configuration may be an RRC reconfiguration message. The candidate cell group configuration may be a candidate configuration.

[0990] The candidate configuration may not contain IEreconfigurationWithSync. The UE may not perform or proceed with reconfiguration with synchronization in response to, during or for an LTM procedure (associated with the candidate configuration).

[0991] The UE may perform TA acquisition (e.g., for a candidate cell) indicated by the network or initiated by the UE (itself). TA acquisition may be an early TA acquisition of a candidate cell before receiving a cell handover command for an LTM procedure. TA acquisition may contain a RAR-based RACH or a RAR-free RACH. The RAR may indicate TA information associated with the candidate cell (e.g., TA or Tracking Area Code (TAC)). The (RAR-free) random access procedure for the candidate cell for early TA acquisition of the candidate cell may contain transmitting a random access preamble (once) to the candidate cell. The (RAR-free) random access procedure for the candidate cell for early TA acquisition of the candidate cell may not contain the (PDCCH) (common) search space that the UE monitors for receiving a random access response. The (RAR-free) random access procedure for the candidate cell for early TA acquisition of the candidate cell may contain (only) one random access preamble transmission for the candidate cell for each PDCCH command reception of the candidate cell from the network. The PDCCH command may instruct the UE to initiate a (RAR-free) random access procedure to the candidate cell for early TA acquisition.

[0992] A RACH without RAR may contain a random access response. A random access response may not contain a RAR. A RAR may be the MAC payload of a random access response. A RACH without RAR may contain (only) the MAC subheader of a random access response.

[0993] The UE may be configured to use RAR-less RACH for candidate cells. RAR-less RACH may contain RAR-less TA acquisition mechanism.

[0994] In response to (one) preamble transmission associated with the random access procedure for the candidate cell for early TA acquisition, the UE may consider that the random access procedure is successfully performed.

[0995] The serving cell / candidate cell configuration may be / include a RACH configuration for a random access procedure on the candidate cell. The RACH configuration may indicate a search space id and / or a RACH opportunity and / or a preamble index.

[0996] The TA information associated with the candidate cell may be a TA command (timing advance command) or an NTA or a TA group (TAG) associated with the candidate cell.

[0997] The TA information of the candidate cell may be the timing difference between the uplink and downlink associated with the candidate cell.

[0998] The PDCCH order initiating the random access procedure on the candidate cell may contain or indicate the bandwidth part (BWP) (of the candidate cell).

[0999] The PDCCH order initiating the random access procedure on the candidate cell may contain or indicate a cell / candidate index (of the candidate cell or candidate cell configuration).

[1000] The PDCCH order initiating a random access procedure on a candidate cell may contain or indicate a RACH configuration (associated with the candidate cell or candidate cell configuration).

[1001] The first PDCCH opportunity (at which the UE starts the window) may be the first PDCCH opportunity associated with a C-RNTI or RA-RNTI (after preamble transmission or after an offset after preamble transmission). The first PDCCH opportunity may be the first PDCCH opportunity associated with a (type 1) common search space or a UE-specific search space.

[1002] The LTM may be an intra-distributed unit (DU) LTM. Alternatively, the LTM may be an inter-DU or inter-centralized unit (CU) LTM.

[1003] LTM may include the network transmitting first information and second information to the UE. The first information may be an RRC message indicating one or more candidate cells (or cell groups or one or more RRC reconfigurations indicating one or more candidate configurations). The one or more candidate configurations may contain or may be one or more RRC reconfigurations. The first information may contain one or more Cellgroupconfigs or one or more RRCreconfiguration messages. The second information may be nL1 or L2 signaling and / or (LTM) cell switching commands (e.g., PDCCH and / or MAC CE). The UE may initiate an LTM random access procedure or start a cell switch (to one or more candidate cells) in response to the second information (e.g., a cell switching command or an LTM cell switching MAC CE).

[1004] The first information may contain RACH configuration and / or cell configuration for one or more candidate cells. The network may indicate the RACH configuration of the corresponding candidate cell in the PDCCH order for TA acquisition of the candidate cell.

[1005] The candidate cell list may contain a list of candidate cells (eg, a list of candidate cell configurations indicating the list of candidate cells).

[1006] The candidate cell configuration may be (part of) the RRC reconfiguration message.

[1007] The RRC message may be RRCReconfiguration.

[1008] The UE may consider the LTM to be successfully completed when an acknowledgement is received from the network (e.g., the target gNB). The acknowledgement may be in response to a completion message associated with the LTM transmitted by the UE. Additionally and / or alternatively, the UE may consider the LTM to be successfully completed when a random access procedure associated with (or initiated for) the LTM is successfully completed.

[1009] The UE may apply the stored TA associated with the candidate cell to the candidate cell during the LTM procedure for the candidate cell or at the start of the LTM procedure.

[1010] The random access procedure associated with the non-serving cell may contain a random access procedure for inter-cell multi-TRP (mTRP) operation.

[1011] For a serving cell associated with a non-serving cell, the UE may perform inter-cell multi-TRP (mTRP) operations on the serving cell and the non-serving cell.

[1012] For a serving cell associated with a non-serving cell, the configuration of the serving cell may include the configuration of the non-serving cell. The configuration of the non-serving cell may be an additional PCI.

[1013] The serving cell may contain a list of non-serving cells including at least the non-serving cells.

[1014] Non-serving cells can be replaced by additionalPCI.

[1015] It should be noted that any of the methods, alternatives, concepts, examples and embodiments described above and herein may be combined in whole or in part, or applied simultaneously or separately.

[1016] Exemplary embodiments of the present invention are described below.

[1017] refer to Fig.10 Through this and other concepts, systems and methods of the present invention, the method 1000 of the UE includes: initiating an RA procedure to a candidate cell (step 1002), and in response to the completion of the RA procedure, determining whether to include or how to set the value of a parameter in the RA information based at least on the type of the RA procedure (step 1004).

[1018] In various embodiments, the RA information is ra-ReportList or RA-report-r16 or VarRA-Report.

[1019] In various embodiments, the type of RA procedure is early TA acquisition for candidate cells.

[1020] In various embodiments, the UE does not include parameters if or when the RA procedure is for early TA acquisition of a candidate cell.

[1021] In various embodiments, if or when the RA procedure is for early TA acquisition of a candidate cell, the UE sets the value of the parameter to 'LTM related'.

[1022] In various embodiments, if or when the RA procedure is for early TA acquisition of a candidate cell, the UE sets the value of the parameter to 'accessRelated'.

[1023] In various embodiments, if or when the RA procedure is for early TA acquisition of a candidate cell, the UE sets the value of the parameter to 'Early TA'.

[1024] In various embodiments, the type of RA procedure is a network initiated LTM RA procedure.

[1025] In various embodiments, if or when the RA procedure is a LTM RA procedure initiated by the network, the UE sets the value of the parameter to 'LTM related'.

[1026] In various embodiments, if or when the RA procedure is a LTM RA procedure initiated by the network, the UE sets the value of the parameter to 'accessRelated'.

[1027] In various embodiments, if or when the RA procedure is a LTM RA procedure initiated by the network, the UE sets the value of the parameter to 'NW initiated LTM'.

[1028] In various embodiments, the type of RA procedure is a LTM RA procedure initiated by the UE (in response to a condition being met).

[1029] In various embodiments, if or when the RA procedure is a LTM RA procedure initiated by the UE, the UE sets the value of the parameter to 'LTM related'.

[1030] In various embodiments, if or when the RA procedure is a LTM RA procedure initiated by the UE, the UE sets the value of the parameter to 'accessRelated'.

[1031] In various embodiments, if or when the RA procedure is a LTM RA procedure initiated by the UE, the UE sets the value of the parameter to 'UE initiated LTM'.

[1032] In various embodiments, the candidate cell configuration is a candidate configuration.

[1033] In various embodiments, the network initiates the LTM RA procedure via a LTM cell handover command.

[1034] In various embodiments, the parameter is perRAInfoList.

[1035] In various embodiments, the parameter is raPurpose.

[1036] Return to reference Figure 3 and 4 In one or more embodiments from the perspective of the UE, the apparatus 300 includes a program code 312 stored in a memory 310 of the transmitter. The CPU 308 can execute the program code 312 to perform the following operations: (i) initiate an RA procedure to a candidate cell; and (ii) in response to the completion of the RA procedure, determine whether to include or how to set the value of a parameter in the RA information based at least on the type of the RA procedure. In addition, the CPU 308 can execute the program code 312 to perform all the actions, steps, and methods described above, below, or otherwise herein.

[1037] refer to Fig.11 , through this and other concepts, systems and methods of the present invention, the method 1010 of the UE includes: initiating a RA procedure to a non-serving cell (step 1012), and

[1038] In response to the completion of the RA procedure, a determination is made as to whether to include or how to set the values ​​of parameters in the RA information based at least on the type of RA procedure (step 1014).

[1039] In various embodiments, the RA information is ra-ReportList or RA-report-r16 or VarRA-Report.

[1040] In various embodiments, the type of RA procedure is a RA procedure on a non-serving cell.

[1041] In various embodiments, the UE does not include parameters if or when the RA procedure is performed on a non-serving cell.

[1042] In various embodiments, if or when the RA procedure is performed on a non-serving cell, the UE sets the value of the parameter to 'inter-cell mTRP related'.

[1043] In various embodiments, if or when the RA procedure is performed on a non-serving cell, the UE sets the value of the parameter to the additional PCI associated with the non-serving cell.

[1044] In various embodiments, the parameter is additionalPCI.

[1045] In various embodiments, if or when the RA procedure is performed on a non-serving cell associated with the serving cell, the UE sets the value of the parameter to the index or id of the serving cell.

[1046] In various embodiments, if or when the RA procedure is performed on a non-serving cell, the UE sets the value of the parameter to the additional PCI associated with the non-serving cell.

[1047] In various embodiments, the parameter is cellld.

[1048] In various embodiments, the parameter is servingCellId.

[1049] In various embodiments, the parameter is SpCellID.

[1050] In various embodiments, the UE does not set the value of the parameter if or when the RA procedure is not performed on the non-serving cell.

[1051] In various embodiments, the parameter is perRAInfoList.

[1052] In various embodiments, the parameter is raPurpose.

[1053] Return to reference Figure 3 and 4 In one or more embodiments from the perspective of the UE, the apparatus 300 includes a program code 312 stored in a memory 310 of the transmitter. The CPU 308 may execute the program code 312 to perform the following operations: (i) initiate an RA procedure to a non-serving cell; and (ii) in response to the completion of the random access procedure, determine whether to include or how to set the value of a parameter in the RA information based at least on the type of the RA procedure. In addition, the CPU 308 may execute the program code 312 to perform all of the actions, steps, and methods described above, below, or otherwise herein.

[1054] An example of a text change based on 38.331 is shown below:

[1055]

[1056]

[1057]

[1058]

[1059]

[1060]

[1061]

[1062]

[1063]

[1064]

[1065]

[1066]

[1067]

[1068]

[1069] refer to Fig.12, through this and other concepts, systems and methods of the present invention, the method 1020 of the UE includes: receiving a first PDCCH command (step 1022); in response to receiving the first PDCCH command, initiating a first RA procedure to a candidate cell for early TA acquisition (step 1024); storing first RA information associated with the first RA procedure (step 1026); and in response to a request from the network, reporting the first RA information to the network (step 1028).

[1070] In various embodiments, the purpose of the first RA information is set to the first purpose or the second purpose.

[1071] In various embodiments, the first purpose is 'Early TA Acquisition', 'Early TA' or 'LTMRelated'.

[1072] In various embodiments, the second destination is 'ulUnSynchronized'.

[1073] In various embodiments, the method further includes receiving a second PDCCH command, initiating a second RA procedure to the serving cell in response to receiving the second PDCCH command, and storing second RA information associated with the second RA procedure, wherein the purpose of the second RA information is set to the second purpose.

[1074] In various embodiments, the method further includes receiving an LTM cell switching command, initiating a third RA procedure to the candidate cell in response to receiving the LTM cell switching command, and storing third RA information associated with the third RA procedure, wherein a purpose of the third RA information is set to the first purpose.

[1075] In various embodiments, the UE indicates the identity of the SpCell in the first RA information.

[1076] In various embodiments, if or when the candidate cell is configured in a candidate configuration associated with an MCG, the identity of the SpCell is the identity of the PCell, and / or if or when the candidate cell is configured in a candidate configuration associated with an SCG, the identity of the SpCell is the identity of the PSCell.

[1077] In various embodiments, the method further includes receiving a third PDCCH command, and initiating a fourth RA procedure to the candidate cell for early TA acquisition in response to receiving the third PDCCH command, wherein the first RA information includes information transmitted by the second RA preamble of the fourth RA procedure.

[1078] In various embodiments, information transmitted by a first RA preamble of a first RA procedure for a candidate cell and information transmitted by a second RA preamble of a fourth RA procedure for early TA acquisition are indicated or stored by the same RA-Report.

[1079] In various embodiments, the first RA information is included in a RA-Report, or is a RA-Report.

[1080] In various embodiments, the first RA procedure is RAR-free.

[1081] In various embodiments, the first RA information includes information transmitted by a first RA preamble of a first RA procedure and / or includes ra-InformationCommon.

[1082] In various embodiments, the request is a successHO-ReportReq or a ra-ReportReq.

[1083] Return to reference Figure 3 and 4 In one or more embodiments from the perspective of the UE, the apparatus 300 includes a program code 312 stored in a memory 310 of the transmitter. The CPU 308 may execute the program code 312 to perform the following operations: (i) receive a first PDCCH order; (ii) in response to receiving the first PDCCH order, initiate a first RA procedure to a candidate cell for early TA acquisition; (iii) store first RA information associated with the first RA procedure; and (iv) in response to a request from the network, report the first RA information to the network. In addition, the CPU 308 may execute the program code 312 to perform all of the actions, steps, and methods described above, below, or otherwise herein.

[1084] Any combination of the concepts or teachings above or here can be combined or formed into new embodiments in whole or in part. The disclosed details and embodiments can be used to solve at least (but not limited to) the problems mentioned above and here.

[1085] It should be noted that any of the methods, alternatives, steps, examples and embodiments presented herein may be applied independently, individually and / or in combination with multiple methods, alternatives, steps, examples and embodiments.

[1086] Various aspects of the present disclosure have been described above. It should be clear that the teachings herein can be implemented in a wide variety of forms, and any specific structure, function, or both disclosed herein are only representative. Based on the teachings herein, it should be understood by those skilled in the art that the aspects disclosed herein can be implemented independently of any other aspects, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement a device or practice method. In addition, by using other structures, functionality, or structures and functionality other than one or more aspects of the aspects set forth herein or different from one or more aspects of the aspects set forth herein, this device can be implemented or this method can be practiced. As an example of some of the above concepts, in some aspects, parallel channels can be established based on pulse repetition frequency. In some aspects, parallel channels can be established based on pulse position or offset. In some aspects, parallel channels can be established based on time hopping sequences. In some aspects, parallel channels can be established based on pulse repetition frequency, pulse position or offset, and time hopping sequences.

[1087] Those skilled in the art will understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltage, current, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[1088] Those of ordinary skill in the art will further appreciate that the various illustrative logical blocks, modules, processors, components, circuits, and algorithm steps described in conjunction with the various aspects disclosed herein may be implemented as electronic hardware (e.g., a digital implementation, an analog implementation, or a combination of the two, which may be designed using source decoding or some other technique), and various forms of programs or design code with instructions (which may be referred to herein as "software" or "software modules" for convenience), or a combination of the two. To clearly illustrate this interchangeability of hardware and software, the various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether this functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. Those of ordinary skill in the art may implement the described functionality in different ways for each specific application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

[1089] In addition, the various illustrative logical blocks, modules, and circuits described in conjunction with the aspects disclosed herein may be implemented within or performed by an integrated circuit ("IC"), an access terminal, or an access point. An IC may include a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, electrical components, optical components, mechanical components, or any combination thereof designed to perform the functions described herein, and may execute code or instructions residing within the IC, outside the IC, or both. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, a combination of multiple microprocessors, one or more microprocessors in combination with a DSP core, or any other such configuration.

[1090] It should be understood that any specific order or hierarchy of steps in any disclosed process is an example of an example method. It should be understood that based on design preferences, the specific order or hierarchy of steps in a process can be rearranged while remaining within the scope of the present disclosure. The accompanying method claims present elements of the various steps in an example order, but are not meant to be limited to the specific order or hierarchy presented.

[1091] The steps of the method or algorithm described in conjunction with the various aspects disclosed herein can be implemented directly with hardware, with a software module executed by a processor, or with a combination of the two. Software modules (e.g., including executable instructions and related data) and other data may reside in a data memory, such as a RAM memory, a flash memory, a ROM memory, an EPROM memory, an EEPROM memory, a register, a hard disk, a removable disk, a CD-ROM, or any other form of computer-readable storage medium known in the art. An example storage medium may be coupled to a machine such as a computer / processor (for convenience, the machine may be referred to as a "processor" in this article) so that the processor can read information (e.g., code) from the storage medium and write information to the storage medium. An example storage medium may be integrated with the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user device. In an alternative, the processor and the storage medium may reside in a user device as discrete components. In addition, in some aspects, any suitable computer program product may include a computer-readable medium, and the computer-readable medium includes a code related to one or more aspects of the present disclosure. In some aspects, a computer program product may include packaging materials.

[1092] Although the present invention has been described in conjunction with various aspects and examples, it will be appreciated that the present invention is capable of further modifications. This application is intended to cover any changes, uses or adaptations of the present invention, which generally follow the principles of the present invention and include such deviations from the present disclosure, which are within the scope of known and customary practice in the technical field to which the present invention belongs.

Claims

1. A method for a user equipment, characterized in that: include: receiving a first physical downlink control channel command; in response to receiving the first physical downlink control channel command, initiating a first random access procedure to a candidate cell for early timing advance acquisition; storing first random access information associated with the first random access procedure; as well as In response to a request from a network, the first random access information is reported to the network.

2. The method according to claim 1, characterized in that The purpose of the first random access information is set to the first purpose or the second purpose.

3. The method according to claim 2, characterized in that The first purpose is 'Early Timing Advance Acquisition', 'Early Timing Advance' or 'LTMRelated'.

4. The method according to claim 2, characterized in that: The second purpose is 'ulUnSynchronized'.

5. The method according to claim 2, characterized in that: Further including: receiving a second physical downlink control channel command, and in response to receiving the second physical downlink control channel command, initiating a second random access procedure to the serving cell; as well as Second random access information associated with the second random access procedure is stored, wherein a purpose of the second random access information is set to the second purpose.

6. The method according to claim 2, characterized in that Further including: receiving an L1 / L2 triggered mobility cell handover command, and in response to receiving the L1 / L2 triggered mobility cell handover command, initiating a third random access procedure to the candidate cell; as well as Third random access information associated with the third random access procedure is stored, wherein a purpose of the third random access information is set to the first purpose.

7. The method according to claim 1, characterized in that The user equipment indicates an identity of a special cell in the first random access information.

8. The method according to claim 7, characterized in that If or when the candidate cell is configured in a candidate configuration associated with a primary cell group, the identity of the special cell is the identity of the primary cell, and / or if or when the candidate cell is configured in a candidate configuration associated with a secondary cell group, the identity of the special cell is the identity of the primary and secondary cells.

9. The method according to claim 1, characterized in that: Further including: receiving a third physical downlink control channel command, and in response to receiving the third physical downlink control channel command, initiating a fourth random access procedure to the candidate cell for early timing advance acquisition, wherein the first random access information includes information transmitted by a second random access preamble code of the fourth random access procedure.

10. The method according to claim 1, characterized in that The information transmitted by the first random access preamble code of the first random access procedure for the candidate cell and the information transmitted by the second random access preamble code of the fourth random access procedure for early timing advance acquisition are indicated or stored by the same RA-Report.

11. The method according to claim 1, characterized in that: The first random access information is included in the RA-Report, or is the RA-Report.

12. The method according to claim 1, characterized in that The first random access procedure is without random access response.

13. The method according to claim 1, characterized in that The first random access information includes information transmitted by a first random access preamble code of the first random access procedure and / or includes ra-InformationCommon.

14. The method according to claim 1, characterized in that The request is a successHO-ReportReq or a ra-ReportReq.

15. A user equipment, characterized in that: include: Memory; as well as a processor operatively coupled to the memory, wherein the processor is configured to execute program code to: receiving a first physical downlink control channel command; in response to receiving the first physical downlink control channel command, initiating a first random access procedure to a candidate cell for early timing advance acquisition; storing first random access information associated with the first random access procedure; as well as In response to a request from a network, the first random access information is reported to the network.

16. The user equipment according to claim 15, characterized in that The purpose of the first random access information is set to the first purpose or the second purpose.

17. The user equipment according to claim 16, characterized in that The first purpose is 'Early Timing Advance Acquisition', 'Early Timing Advance' or 'LTMRelated'.

18. The user equipment according to claim 16, characterized in that The second purpose is 'ulUnSynchronized'.

19. The user equipment according to claim 15, characterized in that The user equipment indicates an identity of a special cell in the first random access information.

20. The user equipment according to claim 15, characterized in that The information transmitted by the first random access preamble code of the first random access procedure for the candidate cell and the information transmitted by the second random access preamble code of the fourth random access procedure for early timing advance acquisition are indicated or stored by the same RA-Report.

Images