TW202123765A - Handling timing conflicts involving random access procedure messages - Google Patents

Abstract

A method for handling timing conflicts associated with a random channel access procedure is implemented in a user device, and includes determining (314) that a first time span for the user device to transmit at least a data portion of a random-access procedure message to a base station overlaps a second time span for the user device to transmit another signal to the base station. The method also includes determining (320), based at least on a type of the other signal, a transmission precedence indicative of whether to modify transmission timing for the random-access procedure message or to instead modify transmission timing for the other signal, and, based on the determined transmission precedence, either transmitting (340) at least the data portion of the random-access procedure message to the base station during the first time span or transmitting (340) the other signal to the base station during the second time span.

Description

Handling of timing conflicts involving random access procedure messages

The present invention relates generally to wireless communication, and more particularly relates to procedures for obtaining access to a communication channel.

In order to communicate synchronously via a radio interface, a user equipment ("UE") and a base station can use a random access channel when the UE needs to transmit a signal (for example, data or control information) to the base station ( RACH) program. Generally speaking, when the UE sends a random access preamble to the base station, a RACH procedure starts. In the contention-based RACH procedure of a specific radio access network (RAN), the UE randomly selects a preamble from a set of predefined patterns or signatures. Since this selection is random, it is possible for a base station to receive exactly the same preamble from two or more UEs during the same physical layer random access channel (PRACH) timing, where the "PRACH timing" is used A time-frequency resource is used to transmit information to the base station in the uplink direction. The base station can use additional messaging to resolve the contention for the exact same PRACH opportunity between UEs transmitting the same preamble.

During a "four-step" contention-based RACH procedure, (1) a UE sends the preamble to a base station at a PRACH timing associated with a random access preamble ("Msg1"); (2) The base station sends a Random Access Response (RAR) ("Msg2") to the UE; (3) The UE shares a physical layer uplink with the preamble and the PRACH timing Channel (PUSCH) timing (ie, another time-frequency resource) sends a scheduled transmission ("Msg3") to the base station; and (4) the base station sends a contention resolution ("Msg4") to The UE. Recently, for fifth-generation (5G) radio access ("NR") networks, a "two-step" contention-based RACH procedure has been proposed. A contention-based two-step procedure condenses steps (1) and (3) of the four-step procedure into a first step, and condenses steps (2) and (4) of the four-step procedure into a second step . Therefore, in the two-step procedure, (1) a UE sends the preamble and a scheduled transmission ("MsgA") to the base at the PRACH and PUSCH timings associated with a random access preamble, respectively Station; and (2) the base station sends a RAR and contention resolution ("MsgB") to the UE. If the base station successfully receives and decodes the MsgA preamble during the two-step RACH procedure, but fails to receive and decode the information about the timing of the MsgA PUSCH, the base station will respond with a "back-off" response (or "back-off RAR ") to the UE, requesting the UE to fall back to the four-step random access procedure.

In some scenarios, the base station requests (eg, configures, schedules, or grants an opportunity to) the UE to be during a time span that overlaps with the time span in which the UE intends to transmit the MsgA of the two-step RACH procedure Transmit other signals. For example, if the base station does not know that the UE is performing a two-step RACH procedure, the base station may grant the UE a PUSCH opportunity to perform an uplink transmission or retransmission of data. The PUSCH opportunity includes A time span overlaps with the time span in which the UE intends to transmit MsgA. As another example, the base station may request the UE to periodically or aperiodically transmit a message or another signal to the base station, such as a sounding reference signal (SRS), including a channel quality indicator (CQI) Either a channel status information (CSI) message or a schedule request (SR) message. The configured or expected transmission time of these signals may overlap with the time span of MsgA in which the UE intends to transmit a specific RACH procedure.

However, in some RANs such as 5G NR, a UE may only transmit one signal at a time. In addition, there is currently no mechanism suitable for resolving timing conflicts in UE transmission during a contention-based two-step RACH procedure. Therefore, a UE may degrade network efficiency due to failure to transmit both expected messages/signals or failure to transmit a specific signal in a timely manner.

A UE to follow one of the present invention help to maintain the efficiency of the web directed to a solution to the random access procedure messages (e.g., based on a two-step MsgA of contention RACH procedure of) the timing conflict. Specifically, the UE determines a specific transmission priority order when the expected timing of the random access procedure message conflicts with the expected timing of another signal. If a base station configures or schedules the UE with a specific timing of signal transmission, if the UE itself has scheduled signal transmission, or if the UE or a base station triggers a signal, "immediately" (eg , At the earliest opportunity) transmit, then the UE can "anticipate" the other timing of the signal, for example. The UE determines the transmission priority based on the type of another signal (e.g., uplink data signal, SRS, etc.) and (in some implementations) one or more additional factors. Based on the determined priority order, the UE modifies the transmission timing of the following items: (1) at least one data part of the random access procedure message, or (2) another signal. As used herein, the "modification" of the transmission timing can refer to a finite time shift (for example, a finite delay), or an infinite time shift (that is, to suspend or cancel a transmission).

In one such implementation, the UE determines a transmission priority order between: (1) at least one data portion of the random access procedure message, and (2) the UE intends to grant An opportunity to transmit an uplink data signal. The UE may determine the transmission priority based at least in part on the timing of whether the base station has granted new data transmission or data retransmission. If the granted opportunity is for new data, the UE transmits the new data at the granted opportunity and modifies (for example, suspends or selects a new preamble associated with at least one PUSCH opportunity with a non-conflicting transmission time) Code or PRACH timing) the transmission of the random access procedure message. For example, if the granted opportunity is a PUSCH opportunity, and the random access procedure message is a contention-based two-step RACH procedure MsgA, this method can advantageously allow the UE to use a contention-free Instead of making the new data go through a contention-based procedure unnecessarily (that is, by transmitting the new data at the MsgA PUSCH instead).

However, if the granted opportunity is for data retransmission, the UE can also determine the transmission priority based on other factors, including the priority of the retransmitted data and the priority of the new data. If the priority of the retransmitted data is lower than the priority of the new data, for example, the UE can transmit the random access procedure message at the original timing and modify the retransmission timing (for example, abort The retransmission). For example, this may be acceptable in implementations where the base station is configured to send additional retransmission requests to the UE. Conversely, if the priority of the retransmitted data is at least as high as the priority of the new data, the UE can retransmit the data at the granted opportunity and modify at least the random access procedure message The timing of the transmission of the data portion (for example, delay or suspend the transmission). However, in some implementations, the UE may transmit one of the preambles of the random access procedure message within the initially expected time span (for example, at the original MsgA PRACH timing), as long as the time span is suitable for data renewal. The expected time span of transmission does not overlap. Transmitting the preamble but not the data portion of the random access procedure message can cause the base station to request the UE to fall back to a four-step random access procedure (for example, as described above in the prior art and with reference to FIG. 2C below) Discussed). Therefore, the UE can successfully retransmit data without causing the random access procedure to fail completely.

In other implementations and/or scenarios, the UE determines a transmission priority order between: (1) at least one data portion of the random access procedure message, and (2) the number of signals requested by the base station A different type. For example, the other signal may be that the base station configures the UE to transmit a signal on a periodic basis, or it may be that the base station dynamically configures the UE to aperiodically (for example, only One signal is transmitted once or irregularly.

In one such implementation/scenario, if the other signal is an SRS, the UE always maintains the original timing of the random access procedure message and modifies the timing of the SRS (for example, suspends the SRS). For example, this may be acceptable in an implementation in which the base station transmits another request for an SRS to the UE when a requested SRS is not received.

As another exemplary implementation/scenario, if the another signal includes a CQI and/or CSI, the UE may determine the transmission priority based on the quality of the communication channel between the base station and the UE order. For example, if the CQI and/or CSI includes one or more channel quality metrics that have not degraded beyond a predefined threshold (or thresholds), the UE can transmit the random access procedure at the original timing Message, and modify the timing of the CQI and/or CSI message (for example, stop the CQI and/or CSI message). The base station can configure the UE with the threshold value(s), or the base station can know the threshold value(s) in other ways, so that the base station can assume the channel quality in which the base station has not received from the UE It is still acceptable in a scenario where CQI and/or CSI are expected. Conversely, if the metric(s) indicate that the channel has degraded beyond the threshold(s), the UE can transmit the CQI and/or CSI messages at the originally expected timing, and modify at least the random access procedure message The timing of the data part (for example, delay or stop at least the data part of the random access procedure message). Similar to the implementation described above, if the original time span does not overlap with the expected transmission time of the CQI and/or CSI message, the UE can still transmit the CQI and/or CSI message within that time span (for example, at the original MsgA PRACH timing) The preamble of the random access procedure message triggers a rollback to one of the four-step random access procedure.

In other embodiments, if the other signal is one of a set of specific signal types (for example, SRS, CQI, CSI, PUSCH, or SR), the UE may determine that the other signal always has better performance than the random signal. The priority order of the access procedure message, and therefore the transmission of the other signal within its initially expected time span. In one such implementation, the UE decides to transmit a new non-conflicting time span of the random access procedure message. In an implementation in which the random access procedure message is a contention-based two-step RACH procedure, MsgA, for example, the UE selects a new preamble and a new preamble of the MsgA in response to detecting a timing conflict /Or a new PRACH timing (for example, a PRACH timing that is closest in time to the original PRACH timing but after the original PRACH timing without still causing a timing overlap). Since each different preamble and PRACH timing is associated with a different PUSCH timing (or several PUSCH timings), the UE actually selects a new MsgA PUSCH timing. In implementations and/or scenarios in which the base station associates multiple PUSCH occasions with each preamble/PRACH occasion, the UE can select a new preamble and/or PRACH occasion of the MsgA (e.g., (PRACH timing that is closest in time to the original PRACH timing but after the original PRACH timing without still causing a timing overlap), so that at least one of the associated PUSCH timings does not have a timing with the other signal Order conflict.

An example embodiment of these techniques is a method for handling timing conflicts associated with a random access procedure for gaining access to a communication channel in a user device. The method includes: determining, by the processing hardware of the user device, that the user device is used to transmit at least one data portion of a random access procedure message to a base station, a first time span and the user device are used A second time span of transmitting another signal to the base station overlaps; and the processing hardware determines whether to instruct to modify the transmission timing of the random access procedure message or to modify it instead based on at least a type of the other signal One of the transmission priorities of the transmission timing of the other signal. The method also includes: based on the determined transmission priority order, only one of the following situations occurs: (i) transmitting at least the data portion of the random access procedure message to the base station during the first time span, Or (ii) transmit the other signal to the base station during the second time span.

Another exemplary embodiment of these technologies is a user device that includes hardware and is configured to implement one of the above methods.

FIG. 1 shows an example wireless communication network 100 in which a UE 102 communicates with a base station 104 synchronously and uses a RACH procedure to gain access to a channel used for communication with the base station 104. The UE 102 and the base station 104 support one or more types of RACH procedures. In one implementation, for example, the UE 102 and the base station 104 support at least one contention-based four-step RACH procedure, one contention-based two-step RACH procedure, and for changing from a two-step RACH procedure to one One of the four-step RACH procedures is a "rollback" procedure (for example, as discussed below with reference to FIG. 2A, FIG. 2B, and FIG. 2C respectively). In another exemplary implementation, the UE 102 and the base station 104 only support a contention-based two-step RACH procedure.

The UE 102 may be any suitable device capable of wireless communication (e.g., any of the exemplary user devices discussed below after each figure is described). The base station 104 operates as a gNodeB (gNB) in this example, supports 5G New Radio (NR) radio access technology (RAT), and is connected to a core network (CN) 100 of CN type 5GC. However, in other embodiments, the base station 104 and/or one or more of the other base stations of the wireless communication network 100 may alternatively (or also) operate according to a type of RAT (e.g., EUTRA) other than NR, And these base stations can alternatively (or also) be connected to CN types other than 5GC (for example, an evolved packet core (EPC) network).

In the exemplary embodiment of FIG. 1, the base station 104 covers a 5G NR cell 120. In the 5G NR cell 120, other devices such as UE 122 and 124 (for example) are operable and sometimes try to obtain a pair of UEs. 102 is the same as the access to the uplink channel (for example, time-frequency resource). UE 122 and 124 may be similar to UE 102 (for example) or may be other types of devices capable of communicating with base station 104 via cell 120 by using the same RACH procedure as UE 102 in a similar manner.

As illustrated in FIG. 1, the base station 104 is equipped with processing hardware 130, which may include one or more general-purpose processors (eg, central processing unit (CPU)) and non-transitory computer-readable memory The non-transitory computer-readable memory stores machine-readable instructions that can be executed on one or more general-purpose processors and/or special-purpose processing units. The processing hardware 130 includes a RACH controller 132. The RACH controller 132 generally supports one or more RACH procedures of the base station 104. For example, the RACH controller 132 can support both a two-step RACH procedure and a contention-based four-step RACH procedure (for example, as discussed below with reference to FIGS. 2A and 2B), and can be used to "return to a two-step procedure" Exit" to one of the four-step procedure (for example, as discussed below with reference to Figure 2C).

The RACH controller 132 can configure the UE 102 with a set of available time-frequency resources, and the UE 102 can select a specific time-frequency resource from the set of available time-frequency resources to transmit a first message (for example, MsgA or Msg1) of the RACH procedure. The set of time-frequency resources may be a set of PRACH occasions each associated with a different preamble. For example, any UE (for example, UE 102, 122, or 124) that uses a specific PRACH occasion of a RACH procedure includes The corresponding preamble (for example, MsgA or Msg1) in the first RACH message. In one such implementation, the RACH controller 132 may also make each preamble/PRACH timing be a different PUSCH timing (ie, the time-frequency resource used for uplink data transmission) or may be different from a PUSCH timing. Multiple PUSCH occasions of the group are associated, and use a specific preamble and one of the PRACH occasions. The UE (for example, UE 102, 122 or 124) uses the corresponding PUSCH occasion or the corresponding PUSCH time for transmission or retransmission in the group Data (for example, in MsgA or Msg3).

The UE 102 is equipped with processing hardware 140. The processing hardware 140 may include one or more general-purpose processors (for example, CPU) and non-transitory computer-readable memory. The non-transitory computer-readable memory may be stored in a Or machine-readable instructions executed on multiple general-purpose processors and/or special-purpose processing units. The processing hardware 140 includes a RACH controller 142, a collision detection unit 144, a transmission (TX) priority unit 146, and a data buffer 150.

The RACH controller 142 generally supports one or more RACH procedures of the UE 102. For example, the RACH controller 142 can support both a two-step RACH procedure and a contention-based four-step RACH procedure (for example, as discussed below with reference to FIGS. 2A and 2B), and can be used to "return to a two-step procedure" Exit" to one of the four-step procedure (for example, as discussed below with reference to Figure 2C).

The conflict detection unit 144 generally detects timing conflicts between expected (eg, scheduled or triggered) communications. In some implementations, the UE 102 may only transmit one signal at a time. In this case, the collision detection unit 144 is used to detect a future condition that is not allowed or otherwise impossible (that is, at least two Simultaneous transmission). At a minimum, the conflict detection unit 144 can detect a timing conflict between a RACH procedure message that the UE 102 intends to transmit (for example, a message generated or triggered by the RACH controller 142) and another signal that the UE 102 intends to transmit. , Discussed further below. In some implementations, the conflict detection unit 144 is dedicated to detecting these timing conflicts involving a RACH message, and/or the conflict detection unit 144 resides in the RACH controller 142. In other embodiments, the collision detection unit 144 is a unit that more generally detects timing collisions of the expected transmission of the UE 102, and/or the collision detection unit 144 is external to the RACH controller 142.

In a scenario where the conflict detection unit 144 determines that there is a timing conflict between two expected signal transmissions (for example, a RACH program message and another signal), the transmission priority order unit 146 determines which signal transmission is superior to the other signal transmission. Priority of signal transmission. Generally speaking, when a first signal transmission has a "priority order" superior to a second signal transmission, the UE 102 modifies the timing of the second signal transmission without modifying the timing of the first signal transmission. However, in some implementations and/or scenarios, the UE 102 modifies the timing of only a portion of the second transmission signal (for example, by maintaining the original timing of a preamble of a message, but modifying a data of the message Part of the timing, discussed further below). Depending on the implementation and/or scenario, the transmission prioritization unit 146 may be based on the type of at least one conflicting signal (for example, whether a signal that conflicts with an MsgA is a PUSCH data transmission or a PUSCH data retransmission, or whether the conflicting signal is a SRS, etc.), based on data priority, based on channel quality information, and/or based on other factors to determine the priority order, as discussed in further detail below.

The data buffer 150 resides in a memory of the UE 102 and stores data for transmission by the UE 102 (for example, to the base station 104). The data buffer 150 may be or include a hybrid automatic repeat request (HARQ) buffer, for example. In some implementations, when the UE 102 has new data ready for transmission (for example, data generated at an application layer, etc.), the processing hardware 130 generates a media access control (MAC) protocol data unit ( PDU), encode the MAC PDU, and store the encoded MAC PDU in the data buffer 150. The UE 102 transmits the encoded MAC PDU to the base station 104 (for example, in MsgA or Msg3) via a PUSCH occasion granted by the base station 104 or a PUSCH occasion obtained via a RACH procedure. If the base station 104 is granted a PUSCH opportunity but then fails to properly receive or decode the data, the base station 104 may request retransmission of the data (ie, grant the UE 102 a PUSCH opportunity to retransmit the data). In this case, the UE 102 retransmits the encoded MAC PDU (still stored in the data buffer 150) to the base station 104. In some implementations, the data buffer 150 represents multiple buffers (for example, a HARQ buffer, and another buffer that can store data of a logical channel that is not used to generate a MAC PDU).

In some implementations, FIGS. 2A-2C illustrate examples of known RACH procedures that the UE 102 and the base station 104 can perform. The operations of FIGS. 2A to 2C performed by the UE 102 may be performed by the RACH controller 142, and the operations of FIGS. 2A to 2C performed by the base station 104 may be performed by the RACH controller 132, for example.

Referring first to FIG. 2A, a contention-based four-step RACH procedure 200 starts when the UE 102 selects a PRACH opportunity, and transmits a random access preamble ("Msg1") associated with the selected PRACH opportunity at the selected PRACH opportunity. ") and transmit 202 the random access preamble to the base station 104. The UE 102 may select the PRACH occasion from a set of available PRACH occasions that the base station 104 has configured or indicated to the UE 102 at an earlier time, for example. UE 102 then uses the following formula to calculate a random access radio network temporary identification number (RA-RNTI): RA_RNTI = 1 + s_id + (14 * t_id ) + (14 * 80 * f_id ) + (14 * 80 * 8 * ul_carrier_id ), where s_id is the index of the first Orthogonal Frequency Division Multiplexing (OFDM) symbol that appears in the PRACH opportunity (0 ≤ s_id ＜ 14), and t_id is the index of the first time slot of the PRACH opportunity in a system frame (0 ≤ t_id ＜ 80), f_id is the index of PRACH opportunity in the frequency domain (0 ≤ f_id ＜ 8), and ul_carrier_id is the uplink (UL) carrier through which UE 102 transmits the random access preamble (specifically In other words, "0" is used for the normal uplink (NUL) carrier and "1" is used for the supplementary uplink (SUL) carrier).

After the base station 104 receives the random access preamble transmitted 202 by the UE 102, the base station 104 responds by transmitting 204 a random access response (RAR) ("Msg2") to the UE 102. Before transmission 204, the base station 104 encodes the RAR so that the UE 102 can use the calculated RA-RNTI to decode the RAR. The UE 102 then transmits 206 a scheduled transmission ("Msg3") to the base station 104, and the base station 104 responds by transmitting 208 a contention resolution solution ("Msg4") to the user device. UE 102 transmits Msg1 and Msg3 at different times and possibly at different frequencies (that is, Msg1 is in a PRACH timing and Msg3 is in a corresponding PUSCH timing), where base station 104 has configured UE 102 at an earlier time to enable Choose/use their respective time-frequency resources/opportunities.

In the contention-based two-step RACH procedure 230, in order to illustrate the timing limitation more clearly, FIG. 2B illustrates the propagation delay of a message traveling on a radio interface using a slanted line. In procedure 230, the UE 102 transmits 232A to the base station 104 during a PRACH occasion associated with a random access preamble, and is also related to both the preamble and the PRACH occasion. A payload (for example, data) is transmitted 232B to the base station 104 during the PUSCH timing. The preamble and the payload jointly define "MsgA". In other words, the preamble and the payload respectively correspond to Msg1 and Msg3 of the contention-based four-step RACH procedure 200 in FIG. 2A.

As illustrated in FIG. 2B, the UE 102 calculates an MsgB-RNTI based on the PRACH timing during which the UE 102 transmits 232A MsgA preamble. The base station 104 processes the MsgA and generates MsgB in respective time intervals, and transmits 234 the MsgB to the UE 102. If the UE 102 receives the MsgB within the MsgB receiving window, the UE 102 uses the calculated MsgB-RNTI to decode the MsgB.

FIG. 2C illustrates that the UE 102 and the base station 104 can implement a "fallback" RACH procedure 250 if a contention-based two-step RACH procedure is unsuccessful. In the RACH procedure 250, the UE 102 transmits 252 an MsgA to the base station 104. Although the transmission 252 of MsgA is shown as a single line/arrow in FIG. 2C for clarity, it should be understood that transmission 252 includes preamble transmission 232A (at the PRACH timing) and payload transmission 232B (at the associated PUSCH timing) ) Both. However, in the scenario represented by FIG. 2C, the base station 104 only successfully receives the MsgA preamble at the PRACH timing, and fails to receive or decode the MsgA payload at the associated PUSCH timing. In response to this, the base station 104 includes a special RAR ("fallback RAR") in the MsgB, and transmits 254 the MsgB with the fallback RAR to the UE 102. The fallback RAR causes the UE 102 to fallback to a contention-based four-step RACH procedure. Therefore, in response to receiving the fallback RAR, the UE 102 uses an uplink grant/opportunity indicated by the base station 104 in the fallback RAR to retransmit 256 data from the MsgA payload to the base station 104. Therefore, the transmission 256 can be regarded as Msg3, one of the contention-based four-step RACH procedures 200. In response to receiving the Msg3, the base station 104 transmits 258 a contention resolution solution (ie, Msg4 of the contention-based four-step RACH procedure 200) to the UE 102.

Next, referring to FIGS. 3 to 7, various techniques that can be implemented by the UE 102 and the base station 104 to resolve/handle the timing conflict between a RACH procedure message and another signal are discussed. Generally speaking, the timing conflict resolution technique discussed with reference to FIGS. 3 to 7 is implemented at the UE 102 by determining an appropriate priority order between conflicting transmissions. Fig. 3 shows a generalized implementation, while Figs. 4 and 5 correspond to a first more specific implementation and Figs. 6 and 7 correspond to a second, more specific implementation.

Although FIGS. 3 to 7 and/or the accompanying description specifically refer to UE 102 and "base station" (gNB) 104 in FIG. 1, it should be understood that other user devices and/or base stations and/or in addition to the figure The following technologies are implemented in systems other than the wireless communication network 100 of 1.

Referring first to FIG. 3, in an example scenario 300, the base station 104 configures 302 the UE 102 with RACH information to try to access the base station 104 via the cell 120. The configuration 302 includes the base station 104 configuring 304 UE 102 with the preamble, PRACH timing, and PUSCH timing, and also configuring 306 the UE 102 with the correlation between various preambles, PRACH timing and PUSCH timing. In some implementations, for example, the base station 104 associates each preamble with a different PRACH timing, and associates each preamble/PRACH timing pair with a different PUSCH timing (or with a different set of PUSCH timings). In some scenarios and/or implementations, two or more PUSCH occasions are associated. The base station 104 is used to configure 304 UE 102 preamble, PRACH timing, and PUSCH timing. A UE (e.g., UE 102, 122, or 124) can be used when trying to gain access to the base station 104 through the cell 120 ( For example, when using the RACH program 200, 230 or 250) the entire set of available preambles and timings selected and used, for example. Since the base station 104 informs the UE 102 of the association, the UE 102 only needs to select a PRACH timing or a preamble to effectively select the corresponding PUSCH timing (or corresponding PUSCH timing subgroup, if more than one PUSCH timing is consistent with each previous Encoding/PRACH timing pair is associated).

The configurations 304 and 306 can occur by means of the base station 104 sending a single message to the UE 102. In different implementations and/or scenarios, for example, the configuration 302 may include the base station 104: (1) As part of an RRC reconfiguration procedure, an RRC Reconfiguration message is transmitted to the UE 102 (e.g., as 3GPP TS 38.331 section 5.3.5); (2) As part of an RRC connection establishment procedure, an RRCSetup message is transmitted to the UE 102 (for example, as defined in 3GPP TS 38.331 section 5.3.3); (3) as A RRC Reestablishment message is transmitted to the UE 102 as part of an RRC reestablishment procedure (for example, as defined in section 5.3.7 of 3GPP TS 38.331); (4) An RRCReestablishment or RRCSetup message is sent as part of an RRC connection continuation procedure Transmit to UE 102 (for example, as defined in section 5.3.13 of 3GPP TS 38.331); or (5) Transmit a system information block (SIB), such as a master information block (MIB) or SIB1. In each of these implementations or scenarios, the message (or SIB) includes an indication of one of the pre-coding and timely groups that can be used by the UE 102 for use in a RACH procedure. In other implementations, the configurations 304 and 306 occur by means of the base station 104 sending different individual messages to the UE 102. In some implementations, the configuration 302 also includes the base station 104 configuring 302 the UE 102 in other ways (for example, configuring 602 the UE 102 to periodically transmit CQI, CSI and/or SR information and/or periodically Transmit an SRS, etc.).

At some point after the base station 104 configures 302 the UE 102, the UE 102 starts 310 a contention-based two-step RACH procedure, such as the RACH procedure 230 of FIG. 2B. In other embodiments, the RACH procedure is not the two-step procedure discussed above. Depending on the implementation and/or scenario, the UE 102 may decide to start 310 the RACH procedure for various reasons. For example, the UE 102 may decide to start 310 the RACH procedure in response to detecting that the UE 102 has new data arriving at the data buffer 150 when the buffer 150 is empty. As another example, the UE 102 may determine in response to detecting that the UE 102 has new data arriving at the data buffer 150 (a time when the data buffer 150 stores data with a lower priority level than the new data) Start 310 the RACH procedure. As yet another example, the UE 102 may decide to start 310 the RACH procedure when the UE 102 decides to request the base station 104 to transmit system information to the UE 102.

Starting 310 the RACH procedure may include the UE 102 instructing the preamble from the base station 104 when configuring 302 the UE 102 and the PRACH timing group to select a specific preamble and a corresponding PRACH timing. It should be understood that since the UE 102 knows the correlation between the preamble and the PRACH occasion, the UE 102 inherently selects a preamble by selecting a PRACH occasion, and vice versa. In addition, if a specific preamble/PRACH opportunity pair is only associated with a single PUSCH opportunity, the UE 102 inherently selects that PUSCH opportunity by selecting the corresponding preamble or PRACH opportunity.

At some point before or after the UE 102 starts 310 the RACH procedure (and possibly while the base station 104 configures 302 UE 102, or even before the base station 104 configures 302 UE 102), the base station 104 requests 312 The UE 102 transmits some other signal (that is, a signal that is not part of the RACH procedure 310 started by the UE 102). As used herein, the term "request" may mean that the recipient (eg, UE 102) may obey a request (eg, a grant at an opportunity to transmit uplink data) as appropriate, or the UE 102 must try to obey it. A request (for example, a command or configuration). Several specific examples are discussed in further detail below.

In some implementations and/or scenarios, the base station 104 requests 312 the UE 102 to transmit another signal by granting the UE 102 a PUSCH opportunity. The UE 102 can transmit data to the base station 104 at the PUSCH opportunity while the UE 102 does not A RACH procedure must be executed first. These implementations and scenarios are discussed in further detail below with reference to FIGS. 4 and 5. In other implementations and/or scenarios, the base station 104 requests 312 the UE 102 to transmit another signal during the configuration 302 of the UE 102. For example, the base station 104 can configure 302 the UE 102 to transmit a specific type of signal to the base station 104 on a periodic basis. As a more specific example, in addition to configuring 302 UE 102 with RACH information, base station 104 can also configure 302 UE 102 to periodically transmit a sounding reference signal (SRS), include a channel quality indicator (CQI), or A message of channel status information (CSI) may include a message of a scheduling request (SR) or a PUSCH. These implementations or scenarios are discussed in further detail below with reference to FIGS. 6 and 7. In still other implementations and/or scenarios, the base station 312 requests the UE 102 to dynamically configure (separately from the configuration 302) a signal (e.g., a CQI and/or CSI) one aperiodic (e.g., , Single or irregular) transmission while transmitting another signal.

After the UE 102 has started 310 RACH procedure and the base station 104 has requested 312 another signal (for example, granting a PUSCH opportunity of another signal, or configuring periodic or aperiodic transmission of another signal), the UE 102 detects It is detected 314 that there is a conflict between the expected timing of one of the messages of the RACH procedure and the expected timing of the transmission of another/requested signal. The UE 102 can detect 314 that there is a timing conflict when the transmission of at least a part of the RACH procedure message will overlap with the transmission of at least a part of another signal, for example. In other implementations, the UE 102 only detects 314 that there is a timing conflict if one or more additional and/or more stringent criteria are met (eg, overlap of at least a specific portion of one of the signals).

In response to detecting 314 the timing conflict, the UE 102 determines 320 a transmission priority order between the two signals with conflicting timing (ie, the RACH procedure message and the other/requested signal). UE 102 is based on the type of at least one of the signals with conflicting timing (for example, based on whether a signal that conflicts with MsgA based on its expected timing is a PUSCH data transmission or a PUSCH data retransmission, or whether the conflicting signal is an SRS, etc.) and The transmission priority order may be determined 320 based on the implementation scheme and/or scenario, based on data priority, channel quality information, and/or other factors. Various more specific examples are discussed below with reference to FIGS. 4-7.

In the example shown in FIG. 3, the RACH procedure message is based on MsgA, one of the contention-based two-step RACH procedures (eg, procedure 200). Therefore, after the UE 102 determines 320 the transmission priority order, the UE 102 transmits 340 the MsgA and/or another/requested signal to the base station 104 according to the determined 320 transmission priority order. As described above, when a first signal transmission (for example, MsgA or another/requested signal) has a "priority" over a second signal transmission (for example, another/requested signal or MsgA), the UE 102 modifies the latter's timing (by delaying or suspending at least part of the transmission) without modifying the former's timing. If the UE 102 determines that 320 MsgA has a transmission priority order over another signal (for example), the UE 102 may transmit 340 MsgA at the originally expected time, and delay or suspend the transmission of the other signal. Conversely, if the UE 102 determines 320 that the other/requested signal has a priority order of transmission over MsgA, the UE 102 can transmit 340 the other/requested signal at the originally expected time, and delay or suspend the transmission of MsgA (eg , Delayed by selecting a new preamble/PRACH opportunity associated with at least one PUSCH opportunity with a non-collision transmission time). As mentioned above, in some implementations and/or scenarios, the UE 102 can modify the timing of only a part of the message that does not have a transmission priority order (for example, if MsgA does not have a transmission priority order, by maintaining one of the MsgA precedence The original timing of the code but the timing of a data part of MsgA is modified).

Although not shown in FIG. 3, in some implementations and/or scenarios, the base station 104 responds to the transmission 340. For example, if the base station 104 has requested/scheduled a retransmission but instead or also received a RACH message from the UE 102, the base station 104 may respond to the UE 102 in a specific way (for example, refer to the figure below) 4 and Figure 5).

As described above, FIG. 4 shows a more specific example in which the base station 104 requests another signal (ie, a signal other than a RACH procedure message) by granting the UE 102 a PUSCH opportunity for data transmission or retransmission. Sex scene 400. In scenario 400, base station 104 configures 402 UE 102 with RACH information (for example, preamble, PRACH timing, PUSCH timing, and the association between PUSCH timing and the corresponding preamble/PRACH timing pair) to try to pass the cell 120 accesses the base station 104. The configuration 402 may be the same as the configuration 302 of FIG. 3.

At some point after the base station 104 configures 402 the UE 102, the UE 102 starts 410 a contention-based two-step RACH procedure, such as the RACH procedure 230 in FIG. 2B. In other embodiments, the RACH procedure is not the two-step procedure discussed above. The start 410 of the RACH procedure (including the trigger of the start 410 of the RACH procedure) can be the same as the start 310 of FIG. 3, for example. For example, starting 410 the RACH procedure may include the UE 102 from the base station 104 instructing the preamble and the PRACH timing group to select a specific preamble and a corresponding PRACH timing when configuring 402 the UE 102.

At some point before or after the UE 102 starts 410 the RACH procedure, it may not know that the UE 102 has started 410 (or is about to start 410) the RACH procedure. The base station 104 of the RACH procedure grants it a PUSCH opportunity to transmit to the UE. 102 requests 412 an uplink data transmission. That is, the base station 104 grants the UE 102 a time-frequency resource, and the UE 102 can transmit uplink data on the time-frequency resource without first having to perform a RACH procedure to obtain channel access. In some embodiments, the base station 104 uses a downlink control indicator (DCI) to grant the PUSCH opportunity via a physical downlink control channel (PDCCH). The UE 102 can use the unique RNTI of the UE 102 to scramble the cyclic redundancy check (CRC) of the DCI, for example, so that the UE 102 can use the RNTI to determine whether to address the DCI to the UE 102. The RNTI can be the cell RNTI (C-RNTI) of the UE 102 or the configured scheduled RNTI (CS-RNTI).

After the UE 102 has started 410 the RACH procedure and the base station 104 has requested 412 uplink data transmission (ie, a PUSCH opportunity is granted for uplink data transmission), the UE 102 detects 414 a message of the RACH procedure There is a conflict between the expected timing and the expected timing of uplink data transmission (that is, the timing corresponding to the granted PUSCH timing). In the exemplary implementation of FIG. 4, the RACH message with a timing conflict is based on MsgA, one of the contention-based two-step RACH procedures. In various implementations and scenarios, the UE 102 may specifically detect that the payload portion of 414 MsgA (that is, the portion of the PUSCH timing transmission associated with the preamble/PRACH timing pair) has a timing conflict, or It can be more generally detected that 414 as a whole has a timing conflict with MsgA.

In response to detecting 414 the timing conflict, the UE 102 determines 420 a transmission priority order between the two signals with conflicting timing (ie, the RACH procedure message and the uplink data transmission in the granted PUSCH timing). After the UE 102 determines 420 the transmission priority order, the UE 102 transmits 440 the MsgA and/or uplink data to the base station 104 according to the determined 420 transmission priority order at the granted PUSCH timing.

The decision 420 depends at least on the type of signal whose expected transmission time overlaps with the expected transmission time of MsgA. In one implementation, for example, an MsgA transmission always has a priority order over any uplink data transmission for a PUSCH opportunity granted by the base station 104, and therefore the UE 102 determines 420 that the 410 RACH procedure started MsgA has a higher transmission priority than the requested 412 uplink data transmission.

However, in other embodiments, the UE 102 also considers other factors for determining 420 the transmission priority. For example, if a requested transmission is an uplink data transmission at one of the granted PUSCH occasions, the UE 102 may additionally grant new data based on the base station 104 (for example, the UE 102 must generate one or more The transmission of a MAC PDU, encoding the MAC PDU(s) and storing the MAC PDU(s) in one of the HARQ buffers of the data buffer 150) is to replace the data previously requested by the base station 104 (for example, The PUSCH timing of the retransmission that has been transmitted and is still stored as one or more encoded MAC PDUs stored in the HARQ buffer) determines 420 the transmission priority.

In one scenario, if the base station 104 grants a PUSCH opportunity for new data transmission, the UE 102 determines 420 that the granted uplink (new) data transmission has a higher priority than MsgA transmission. This technique allows the UE 102 to avoid RACH procedures that may be unnecessary in view of the uplink grant. For example, the UE 102 may have started 410 the RACH procedure in order to request the base station 104 to schedule/grant an uplink transmission, specifically so that the UE 102 may transmit new data (or a buffer status report) to the base station 104. If the base station 104 has granted it a PUSCH opportunity to transmit new data (or a buffer status report), there is no reason for the UE 102 to rely on a contention-based procedure to send the new data (or report) to the base station 104.

In other scenarios, if the base station 104 instead grants the PUSCH opportunity for data retransmission, the UE 102 determines 420 the transmission priority order based on the following two: (1) the priority of the data to be retransmitted, and (2) The priority of data in a specific buffer of the data buffer 150 (for example, a buffer that stores data of a logical channel that is not used to generate a MAC PDU instead of data to be retransmitted). For example, if the data to be retransmitted has a lower priority level than the data in the specific buffer, the UE 102 may determine that 420 MsgA transmission has a priority over retransmission. The UE 102 may then transmit 440 a buffer status report to the base station 104 in the MsgA PUSCH occasion to indicate to the base station 104 that there is data in the particular buffer that has a higher priority than the retransmitted data. In this scenario, after the base station 104 receives the MsgA, the base station 104 may send an uplink grant to the UE 102 to perform a new transmission of higher priority data. After the base station 104 receives the higher priority data, the base station 104 can continue to send an uplink grant to the UE 102 to request the UE 102 to perform the retransmission originally requested.

Alternatively, the UE 102 may determine 420: If the data to be retransmitted has a specific buffer equal to or higher than the data buffer 150 (for example, storing data of a logical channel not used to generate a MAC PDU instead of waiting If the priority of the data in the buffer) is the retransmitted data, the retransmission has a higher priority than the MsgA transmission. In addition, if the retransmission timing does not overlap with the MsgA preamble (that is, it does not overlap with the PRACH timing at which the preamble is to be sent), the UE 102 can use its originally expected timing (that is, the preamble and then retransmit ) Both the retransmission and the MsgA preamble are transmitted, so that only the MsgA payload is delayed or suspended. This method may allow the RACH procedure to succeed, despite the fact that the UE 102 does not transmit a payload (e.g., buffer status report) at the MsgA PUSCH occasion. Specifically, if the base station 104 successfully receives and decodes the MsgA preamble instead of the MsgA payload, the base station 104 can send a fallback RAR to the UE 102 to request the UE 102 to fall back to a four-step RACH procedure ( For example, as in procedure 250), thereby causing the UE 102 to have another opportunity to transmit the MsgA payload.

In some implementations, different data may be associated with different priority levels, and/or different protocol control elements (ie, non-data control information exchanged between UE 102 and base station 104) may be associated with different priority levels United. In one such implementation, if a particular retransmission includes more than one data and/or control element, the UE 102 uses the highest priority among the multiple data and/or control elements to determine 420 the transmission priority order (as described above). Discuss).

Although not shown in FIG. 4, in some implementations and/or scenarios, the base station 104 responds to the transmission 440. For example, if the base station 104 schedules a retransmission but the UE 102 instead only transmits 440 MsgA to the base station 104, the base station 104 can send a MsgB to the UE 102 or address it to the UE 102. RNTI (for example, C-RNTI) is assigned in response to one of the downlinks. The base station 104 may also send an uplink grant to the UE 102 to request the UE 102 to perform the retransmission originally requested. As another example, if the base station 104 schedules a retransmission and the UE 102 then transmits both the 440 MsgA preamble and retransmission, then the base station 104 (after failing to receive the MsgA payload at the corresponding PUSCH timing) The MsgB containing a fallback RAR may be transmitted to the UE 102 (for example, as in the procedure 250). When the UE 102 receives the fallback RAR, the UE 102 transmits the MsgA payload to the base station 104 at the PUSCH timing. When the base station 104 successfully receives the MsgA payload, the base station 104 transmits an Msg4 to the UE 102. The base station 104 can address the Msg4 to the unique RNTI (e.g., C-RNTI) of the UE 102, for example.

FIG. 5 is a process of an exemplary algorithm 500 that UE 102 can implement when it detects a timing conflict between an uplink data transmission granted timing and a contention-based two-step RACH procedure message. Figure. The UE 102 may implement the algorithm 500 to perform the UE-side operations of the messaging diagram shown in FIG. 4.

In algorithm 500, at block 520, UE 102 detects a timing conflict between a MsgA and a granted PUSCH opportunity. Block 520 may correspond to event 414 of FIG. 4, for example. UE 102 then determines at block 522 whether the granted PUSCH opportunity is for new data or retransmitted data. If the granted PUSCH opportunity is for new data, the UE 102 transmits the new data at the granted PUSCH opportunity at block 524 and does not transmit MsgA at its original timing (eg, delay or suspend MsgA transmission). If the granted PUSCH opportunity is instead for a retransmission, the UE 102 determines at block 526 whether the priority of the new data in a buffer is higher than the data to be retransmitted, as discussed above. If the new data is not of higher priority, the UE 102 retransmits the data at the granted PUSCH timing at block 524, and does not transmit MsgA at its original timing (or at least does not transmit the payload/data portion of MsgA). However, if the new data is of higher priority, the UE 102 transmits MsgA at its original timing at block 534 and does not retransmit the data at the granted PUSCH opportunity. Blocks 522 and/or 526 may correspond to event 420 of FIG. 4, and block 524 or block 534 may correspond to event 440, for example.

6 shows that the base station 104 requests one of the signals by configuring the UE 102 to send another signal (ie, a signal other than a RACH program message) to the base station 104 on a periodic basis Example scenario 600. In scenario 600, base station 104 configures 602 UE 102 with RACH information (for example, the preamble, PRACH timing, PUSCH timing, and the association between PUSCH timing and the corresponding preamble/PRACH timing pair) to try to pass the cell 120 accesses the base station 104. The configuration 602 also includes the base station 104 configuring 602 the UE 102 to periodically transmit a message including a CQI, CSI, or SR, or periodically transmit an SRS or PUSCH. The configuration 602 can be the same as the configuration 302 of FIG. 3.

At some point after the base station 104 configures 602 the UE 102, the UE 102 starts 610 a contention-based two-step RACH procedure, such as the RACH procedure 230 of FIG. 2B. In other embodiments, the RACH procedure is not the two-step procedure discussed above. The start 610 of the RACH procedure (including the start 610 of the trigger of the RACH procedure) can be the same as the start 310 of FIG. 3, for example. For example, starting 610 the RACH procedure may include the UE 102 from the base station 104 instructing the preamble and PRACH timing group to select a specific preamble and a corresponding PRACH timing when configuring 602 the UE 102.

At some point after the UE 102 starts 610 the RACH procedure, the UE 102 detects 614 that there is a conflict between the expected timing of a message of the RACH procedure and the expected timing of the SRS, CQI, CSI, PUSCH, or SR signal. In the exemplary implementation of FIG. 6, the RACH message with a timing conflict is based on MsgA, one of the two-step RACH procedures of contention. In various implementations and scenarios, the UE 102 may specifically detect that the payload portion of 614 MsgA (that is, the portion of the PUSCH timing transmission associated with the preamble/PRACH timing pair) has a timing conflict, or It can be more generally detected that 614 MsgA as a whole has a timing conflict.

In response to detecting 614 the timing conflict, the UE 102 determines 620 a transmission priority order between the two signals (ie, the RACH procedure message and the SRS, CQI, CSI, PUSCH, or SR signal) with conflicting timing. After the UE 102 determines 620 the transmission priority order, the UE 102 transmits 640 the MsgA and/or SRS, CQI, CSI or SR signal to the base station 104 according to the determined 620 transmission priority order.

The decision 620 depends at least on the type of signal whose expected transmission time overlaps the expected transmission time of MsgA. In some implementations, for example, a SRS, CQI, PUSCH, or CSI signal transmission always has a priority order over a MsgA transmission, and therefore the UE 102 determines 620 that the SRS, CQI, PUSCH, or CSI has better priority. Transmission priority order of MsgA in RACH program. In these implementations, the UE 102 selects another preamble or PRACH opportunity in response to detecting 614 the timing conflict. For example, the UE 102 may select the following PRACH timings: (1) the closest in time to the original PRACH timing (and after the original PRACH timing), and (2) the timing associated with the original SRS, CQI, PUSCH or CSI The transmission time does not have at least one PUSCH opportunity with a timing conflict. Therefore, event 640 may include transmitting the SRS, CQI, PUSCH, or CSI signal at the originally expected timing, and then at a time later than its originally expected timing (that is, at a time corresponding to the newly selected PRACH opportunity, And corresponding to PUSCH timing) transmit MsgA of RACH program.

In an alternative implementation, MsgA always has a priority order of transmission over an SRS signal. Therefore, when the UE 102 detects 614 a timing conflict between the MsgA and an SRS signal, the UE 102 determines 620 that the MsgA has a transmission priority and transmits 640 MsgA, but does not transmit the SRS signal at the originally expected timing. For example, the UE 102 may suspend the transmission of the SRS signal. In this embodiment, since the base station 104 does not receive the SRS according to the programmed/configured timing, the base station 104 sends a command to request the UE 102 to transmit an SRS (for example, a request for a non-periodic SRS transmission) ).

In another alternative implementation, depending on the measured state or quality of one of the communication channels (e.g., uplink channel) between the UE 102 and the base station 104, a CQI and/or CSI message may or may not have superiority. Priority order of transmission in MsgA. In this implementation, if the UE 102 determines that one or more channel quality metrics have not degraded beyond a certain acceptable threshold value(s), the UE 102 may determine 620 that the MsgA is better than scheduled CQI/CSI transmission. /Report the transmission priority order, and stop CQI/CSI transmission. Conversely, if the UE 102 determines that the metric(s) has degraded beyond the threshold(s), the UE 102 may determine that the scheduled CQI/CSI transmission/report has a priority over MsgA transmission. In both of these implementations, the base station 104 can use the applicable threshold configuration (e.g., at event 602) UE 102. Therefore, if the base station 104 does not receive the scheduled CQI/CSI transmission, the base station 104 can assume that the (equivalent) CQI/CSI metric has not degraded beyond the (equivalent) configured threshold.

In other implementations and/or scenarios, an SR signal has a transmission priority order that is superior to that of an MsgA. If the UE 102 has new data to send, for example, the UE 102 can transmit an SR to the base station 104 to request the base station 104 to schedule an uplink transmission. In this implementation and scenario, if the UE 102 detects 614 that the expected transmission time of MsgA (for example, the PUSCH timing of MsgA) overlaps the expected transmission time of SR, the UE 102 determines 620 that the SR has a transmission priority and transmits 640 SR, but does not transmit MsgA at the originally expected timing. The UE 102 also selects another preamble or PRACH opportunity in response to detecting 614 the timing conflict. For example, the UE 102 may select the following PRACH timings: (1) the timing closest to the original PRACH timing (and after the timing of the original PRACH), and (2) the timing associated with the original SR transmission time that does not have a timing At least one PUSCH opportunity for conflict.

Figure 7 is an exemplary algorithm that UE 102 can implement when it detects a timing conflict between an expected (eg, configured/scheduled) CQI and/or CSI transmission and a two-step RACH procedure message Flow chart of one of 700. The UE 102 may implement the algorithm 700 to perform the UE-side operations of the messaging diagram shown in FIG. 6, for example.

In algorithm 700, at block 720, UE 102 detects a timing conflict between MsgA and an expected CQI/CSI transmission. Block 720 may correspond to event 614 of FIG. 6, for example. The UE 102 then determines at block 730 whether one or more channel quality metrics have degraded beyond one or more predefined (e.g., configured or fixed) thresholds. If the channel quality metric(s) has degraded beyond the threshold(s), the UE 102 transmits the CQI/CSI to the base station 104 at the requested (eg, configured/scheduled) timing at block 732 , And does not transmit MsgA (or at least its data/payload part) at the originally expected timing. Conversely, if the channel quality metric has not degraded beyond the threshold (etc.), the UE 102 transmits MsgA to the base station 104 at the original timing at block 734, and does not transmit the MsgA to the base station 104 at the original/requested timing. The CQI/CSI is transmitted to the base station 104. Block 730 may correspond to event 620 of FIG. 6, and block 732 or block 734 may correspond to event 640, for example.

Other variations of the implementation shown in Figure 3 (ie, in addition to those shown in Figures 4 to 7) are also possible. In some implementations, for example, the base station 104 may dynamically request (e.g., at event 412) the UE 102 to transmit a command to the UE 102 (e.g., in a DCI or MAC control element). Perform an aperiodic (single or irregular) CQI or CSI transmission. If the UE 102 determines (for example, within the decision 420) that one or more channel quality metrics have not degraded beyond a certain acceptable threshold value(s), the UE 102 may determine that MsgA is superior to aperiodic CQI/CSI transmission The transmission priority order.

Conversely, if the UE 102 determines that the metric (e.g.) has degraded beyond the threshold value (e.g.), the UE 102 can determine that the aperiodic CQI/CSI transmission/report has a priority over MsgA transmission. However, if the expected timing of the aperiodic CQI/CSI transmission and the expected timing of the MsgA preamble do not overlap, the UE 102 may also determine to transmit the MsgA preamble at its original timing. In such implementations, the base station 104 can use the applicable threshold configuration (e.g., at event 402) UE 102. Therefore, if the base station 104 does not receive the aperiodic CQI/CSI transmission, the base station 104 can assume that the channel quality metric(s) has not degraded beyond the configured threshold(s).

In any of the implementations discussed above, the UE 102 may use one of the techniques described herein to handle the failure in different ways depending on whether the failure of the RACH procedure is due to a timing conflict resolution solution. RACH procedure. For example, whenever UE 102 fails to receive a desired RACH procedure message (for example, MsgB in procedure 230, or Msg2 and/or Msg4 in procedure 200) from a base station, UE 102 can usually increase A preamble transmission power also increases a preamble transmission counter by 1 in response. UE 102 can then use the counter value to detect transmission problems. For example, if the counter exceeds a threshold value, the UE 102 can take an action to solve or deal with the problem, such as performing a radio link failure procedure to select another cell. However, in some implementations, when the UE 102 performs a contention-based two-step procedure and determines (for example, at events 320, 420, or 620) that the non-RACH signal has a transmission priority and therefore selects a new preamble /PRACH timing, the UE 102 alternatively: (1) maintain (do not increase) the preamble transmission power, and (2) maintain the preamble transmission counter (do not increment the preamble transmission counter).

FIG. 8 is a flowchart of an exemplary method 800 for handling timing conflicts associated with a random access procedure (eg, RACH procedure 230 or 250) used to obtain access to a communication channel. This exemplary method is implemented in a user device such as UE 102 in FIG. 1, for example.

At block 802, the user device determines (for example, at event 314, 414, or 614, or at block 520 or 720) that a first time span overlaps with a second time span, where the first time span is used The device is used to transmit at least one data part of a random access procedure message (for example, at least the payload part of the MsgA of procedure 230 or 250) to a base station for a time span, and wherein the second time span is used The device is used to transmit another signal (e.g., an uplink data transmission of an granted PUSCH occasion, a configured periodic CQI, CSI, SR, PUSCH or SRS, or a dynamically configured/aperiodic CQI or CSI, etc.) is transmitted to the base station in a time span.

At block 804, the user device determines based on at least one type of another signal (for example, at events 320, 420, or 620, or at blocks 522 and 526, or at block 730) instructing (1) to modify random The transmission sequence of the access program message is also alternatively (2) Modify one of the transmission priority order of the transmission sequence of another signal. As mentioned above, "modifying" a transmission timing can include delaying transmission, or completely suspending/cancelling transmission.

At block 806, based on the determined transmission priority order, the user device transmits at least the data portion of the random access procedure message during the first time span (for example, at event 340, 440 or 640, at block 534 At, or at block 734) to the base station, or alternatively transmit another signal during the second time span (e.g., at event 340, 440, or 640, at block 524, or at block 732) To the base station.

By way of example rather than limitation, the content disclosed in this article at least covers the following aspects:

Aspect 1-A method for handling timing conflicts associated with a random access procedure for obtaining access to a communication channel in a user device, the method comprising: processing by the user device The hardware determines that the user device is used to transmit at least one data portion of a random access procedure message to a first time span of a base station and the user device is used to transmit another signal to one of the base stations The second time span overlaps; it is determined by the processing hardware and based on at least one type of the other signal to indicate whether to modify the transmission timing of the random access program message or to modify the transmission timing of the other signal instead. ; And based on the determined transmission priority order, only one of the following occurs: (i) at least the data portion of the random access procedure message is transmitted to the base station during the first time span, or (ii ) Transmit the other signal to the base station during the second time span.

Aspect 2-The method of aspect 1, wherein the method further comprises: before determining that the first time span overlaps with the second time span, receiving one of the uplink data granted to the user device from the base station One of the timing messages, the granted timing includes the second time span.

Aspect 3-The method of aspect 2, wherein: the message that grants the opportunity for the user device to transmit uplink data indicates that the granted opportunity is for the user device to transmit new data to the base station A timing; determining that the transmission priority order is based at least on (i) the other signal is an uplink data signal, and (ii) the granted timing is a timing for the user device to transmit new data; and the method The method includes: transmitting the uplink data signal to the base station during the second time span based on the determined transmission priority order.

Aspect 4-The method of aspect 2, wherein: the message that grants the opportunity for the user device to transmit uplink data indicates that the granted opportunity is for the user device to retransmit that the base station fails to receive or A timing for decoding the data; and determining the transmission priority order is based at least on (i) the other signal is an uplink data signal, (ii) the granted timing is a timing for the user device to retransmit data , (Iii) a priority level of the data to be transmitted in the data portion of the random access procedure message, and (iv) a priority level of the data to be retransmitted.

Aspect 5-The method of aspect 2, wherein: determining the transmission priority order includes determining the priority based on the data to be retransmitted during the second time span and the data to be in the random access procedure message The priority of the data transmitted in the portion is at least as high to transmit the uplink data signal; and the method includes transmitting the uplink data signal to the base station during the second time span.

Aspect 6-The method of any one of aspects 1 to 5, further comprising: determining, by the processing hardware, that the user device is used to transmit a preamble of the random access procedure message to the base station A third time span does not overlap with the second time span; and in response to determining that the third time span does not overlap with the second time span, the preamble is transmitted to the base station during the third time span .

Aspect 7-The method of aspect 4, wherein: determining the transmission priority sequence includes that the priority level of the data to be retransmitted during the first time span is lower than the data to be in the random access procedure message The priority level of the data transmitted in the part is determined to transmit at least the data part of the random access procedure message; and the method includes transmitting at least the data part of the random access procedure message to The base station.

Aspect 8-The method of any one of aspects 2 to 7, further comprising: before determining that the first time span overlaps with the second time span, selecting the processing hardware to be related to the first time span Linking a preamble or a physical layer random access channel (PRACH) timing; and determining by the processing hardware that the first time span overlaps with the second time span includes determining the selected preamble or the selected PRACH timing Is associated with a first physical layer uplink channel (PUSCH) opportunity that includes the first time span, wherein receiving the message that grants the user device the opportunity to transmit uplink data includes receiving the user device A message including a second PUSCH opportunity of the second time span to transmit uplink data.

Aspect 9-The method of aspect 1, including: transmitting the another signal during the second time span based on the determined transmission priority order, and further including: selecting the random access by the processing hardware to transmit A third time span of the program message; and at least the data part of the random access program message is transmitted during the third time span.

Aspect 10-The method of aspect 9, further comprising: before determining that the first time span overlaps with the second time span, the processing hardware selects a first time span associated with the first time span Encoding or a first physical layer random access channel (PRACH) opportunity, where selecting the third time span includes selecting a second preamble or a second PRACH opportunity associated with the third time span, and wherein At least the data part of transmitting the random access procedure message includes transmitting the second preamble at the second PRACH timing.

Aspect 11-The method of aspect 10, wherein: determining that the first time span overlaps with the second time span includes: determining the selected first preamble or the selected first PRACH timing and includes the first time span A first physical layer uplink channel (PUSCH) timing is associated; determining that the selected second preamble or second PRACH timing is associated with a second PUSCH timing that includes the third time span; and transmitting the random At least the data part of the access procedure message includes: transmitting the second preamble at the second PRACH occasion; and transmitting the data part of the random access procedure message at the second PUSCH occasion.

Aspect 12-The method of aspect 10 or 11, which includes: before selecting the first preamble or the first PRACH timing, receiving one of the following indications from the base station: (i) a set of available preambles The code includes the first preamble and the second preamble, and (ii) a set of available PRACH opportunities, which includes the first PRACH opportunity and the second PRACH opportunity.

Aspect 13-The method of any one of aspects 9 to 12, further comprising: before determining that the first time span overlaps the second time span, receiving from the base station the transmission during the second time span One of the other signals requested.

Aspect 14-The method of aspect 13, wherein determining the transmission priority is based at least on the other signal being a sounding reference signal.

Aspect 15-The method of aspect 13, wherein the determination of the transmission priority is based at least on that the another signal includes a message indicating one or more metrics of a quality or state of the communication channel.

Aspect 16-The method of aspect 13, wherein the determination of the transmission priority is based at least on a message that the other signal contains a scheduling request.

Aspect 17-The method of aspect 1, wherein: determining the transmission priority order is at least based on the another signal being a sounding reference signal; and the method includes: based on the determined transmission priority order, during the first time span At least the data part of the random access program message is transmitted.

Aspect 18-The method of aspect 1, wherein the determination of the transmission priority is based at least on (i) the other signal includes a message indicating one or more metrics of a quality or state of the communication channel, and (ii ) The one or more metrics.

Aspect 19-The method of aspect 18, wherein determining the transmission priority order includes comparing at least one of the one or more metrics with a predefined threshold.

Aspect 20-The method of any one of aspects 17 to 19, wherein: the method further comprises selecting one associated with the first time span before determining that the first time span overlaps the second time span Encoding or a physical layer random access channel (PRACH) timing; the PRACH timing includes a third time span before the first time span; and determining that the first time span overlaps with the second time span includes determining the The selected preamble or the selected PRACH timing is associated with a physical layer uplink channel (PUSCH) timing that includes the first time span.

Aspect 21-The method of aspect 20, further comprising: determining by the processing hardware that the third time span does not overlap with the second time span, wherein the method includes: based on the determined transmission priority order, in the PRACH timing transmits the preamble to the base station; does not transmit the data portion of the random access procedure message to the base station at the PUSCH timing; and transmits the other signal to the base station during the second time span Base station.

Aspect 22-The method of aspect 1, wherein: the method includes: based on the determined transmission priority order, (i) transmitting the another signal during the second time span, (ii) not in the first time span During the transmission of the data part of the random access procedure message, and (iii) not transmitting a preamble of the random access procedure message before the first time span; and the method further includes: being changed and controlled by the processing hardware One or more actions associated with the unsuccessful repetition of the random access procedure, the one or more actions include one or both of the following: (i) increase a preamble transmission power; and (ii) Increment a message transmission counter.

Aspect 23-The method of any one of aspects 1 to 22, wherein: the random access procedure is a contention-based two-step random access channel (RACH) procedure; and the random access procedure message is the same as The first step of one of the contention-based two-step RACH procedures is associated with a message.

Aspect 24-A user device that includes hardware and is configured to implement the method of any one of aspects 1 to 23.

The following additional considerations apply to the previous discussion.

Wherein a user device may implement techniques of the present invention (e.g., UE 102) may be any wireless communication system capable of appropriate means, such as a smart phone, a tablet computer, a laptop computer, a mobile game console, A point of sale (POS) terminal, a health monitoring device, a drone, a camera, a media streaming server key or another personal media device, a wearable device (such as a smart watch), a wireless hotspot , A femtocell or a broadband router. In addition, the user device may be embedded in an electronic system (such as a head unit of a vehicle or an advanced driving assistance system (ADAS)) in some cases. Furthermore, the user device can be operated as an Internet of Things (IoT) device or a mobile Internet device (MID). Depending on the type, the user device may include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

Specific embodiments are described in the present invention as including logic or several components or modules. The module can be a software module ( for example , program code, or machine-readable instructions stored on a non-transitory machine-readable medium) or a hardware module. A hardware module is a tangible unit capable of performing specific operations and can be configured or configured in a specific manner. A hardware module may include permanently configured ( for example , as a special purpose processor (such as a field programmable gate array (FPGA) or a special application integrated circuit (ASIC)), a digital signal processor ( DSP), etc.) in order to perform a specific operation dedicated circuit system or logic. A hardware module may also include programmable logic or circuitry that is temporarily configured by software to perform specific operations ( for example , if it is included in a general-purpose processor or other programmable processors). The decision to implement a hardware module in a dedicated and permanently configured circuit system or in a temporarily configured circuit system ( eg , configured by software) can be driven by cost and time considerations.

When implemented in software, technology can be provided as part of an operating system, a library used by multiple applications, a specific software application, etc. The software can be executed by one or more general purpose processors or one or more special purpose processors.

Based on reading the present invention, those who are familiar with the technology will understand the additional and alternative structure and function design for handling timing conflicts involving RACH program messages through the principles disclosed in this article. Therefore, although specific embodiments and applications have been illustrated and described, it should be understood that the disclosed embodiments are not limited to the precise configurations and components disclosed herein. Without departing from the spirit and scope as defined in the scope of the attached patent application, various modifications, changes, and changes that will be clear to those familiar with the technology can be made to the configuration, operation and details of the methods and equipment disclosed in this article without departing from the scope of the patent application. Variety.

100: wireless communication network 102: user equipment 104: base station 110: core network 120: 5G new radio cell/cell 122: user equipment 124: user equipment 130: processing hardware 132: Random Access Channel Controller 140: Processing hardware 142: Random Access Channel Controller 144: Conflict Detection Unit 146: Transmission Priority Unit 150: data buffer/buffer 200: Four-step random access channel program/random access channel program/program 202: step 204: Step 206: Step 208: Step 230: random access channel program/program 232A: Operation 232B: Operation 234: Operation 250: "Rollback" random access channel program/random access channel program/program 252: Operation 254: Operation 256: Operation 258: Operation 300: Scene 302: Event 304: Event 306: Event 310: event 312: Event 314: Event 320: event 340: Event 400: Scene 402: event 410: Event 412: event 414: event 420: event 440: event 500: Algorithm 520: Block 522: Cube 524: Block 526: Block 534: Block 600: Scene 602: event 610: event 614: event 620: event 640: event 700: Algorithm 720: Block 730: Block 732: Cube 734: Block 800: method 802: Block 804: Cube 806: Block

Figure 1 illustrates an example communication system in which a UE can implement the techniques of the present invention for handling timing conflicts associated with a random access procedure for gaining access to a communication channel;

Figures 2A to 2C are diagrams of message sending and receiving of known contention-based RACH procedures;

FIG. 3 is a message sending and receiving diagram of an example scenario in which a UE detects a timing conflict associated with a two-step RACH procedure message;

FIG. 4 is a message sending and receiving diagram of an example scenario in which a UE detects a timing conflict between an granted timing of an uplink data transmission and a two-step RACH procedure message;

FIG. 5 is a flowchart of an exemplary algorithm that the UE can implement when detecting a timing conflict between an granted timing of an uplink data transmission and a two-step RACH procedure message;

FIG. 6 is a message sending and receiving diagram of an example scenario in which a UE detects a timing conflict between a requested SRS, CQI, SCI or SR signal and a two-step RACH procedure message;

FIG. 7 is a flowchart of an exemplary algorithm that the UE can implement when detecting a timing conflict between a requested SRS, CQI, SCI or SR signal and a two-step RACH procedure message; and

FIG. 8 is a flowchart of an exemplary method for handling timing conflicts associated with a random access procedure for obtaining access to a communication channel. The exemplary method may be implemented in a UE.

800: method

802: Block

804: Cube

806: Block

Claims (15)

A method for handling timing conflicts associated with a random access procedure for obtaining access to a communication channel in a user device, the method comprising: The processing hardware of the user device determines that the user device is used to transmit at least one data portion of a random access procedure message to a base station with a first time span and configured to the user device to use An uplink signal is transmitted to the base station for a second time span overlap; The processing hardware determines whether to instruct to modify the transmission timing of the random access procedure message or to modify the transmission timing of the uplink signal instead of a transmission priority order based on at least one type of the uplink signal; and Based on the determined transmission priority order, only one of the following situations occurs: (i) at least the data portion of the random access procedure message is transmitted to the base station during the first time span, or (ii) at The uplink signal is transmitted to the base station during the second time span. Such as the method of claim 1, which further includes: Before determining that the first time span overlaps with the second time span, receive a message from the base station to configure one of the resources used by the user device to transmit uplink communications, where the resources include the second time span . Such as the method of claim 2, where: The message configuring the resource for the user device to transmit uplink communication is a message that grants the user device an opportunity to transmit uplink data; The timing of transmitting uplink data includes the second time span; and Determining the transmission priority is based at least on the granted timing being a timing for the user device to transmit uplink data. Such as the method of claim 3, where: The message that grants the user device the opportunity to transmit uplink data is a message that grants the user device an opportunity to retransmit data that the base station failed to receive or decode; and Determining the transmission priority is based at least on the granted time being a time for the user device to retransmit the uplink data. Such as the method of claim 4, which includes: Based on the determined transmission priority order, at least the data part of the random access procedure message is transmitted to the base station during the first time span. Such as the method of claim 3, where: The message that grants the user device the opportunity to transmit uplink data is a message that grants the user device an opportunity to transmit new data to the base station; and Determining the transmission priority order is based at least on the granted time being a time for the user device to transmit new data. Such as the method of claim 6, where: The random access procedure message is an MsgA; and Determining the transmission priority order includes determining that the MsgA has a higher priority order than the new data. Such as the method of any one of claims 3 to 7, which further includes: Before determining that the first time span overlaps the second time span, the processing hardware selects a preamble or a physical layer random access channel (PRACH) timing associated with the first time span; and Determining by the processing hardware that the first time span overlaps with the second time span includes determining the selected preamble or the selected PRACH timing and a first physical layer uplink channel (PUSCH) that includes the first time span Timing is related, Wherein receiving the message that grants the user device the opportunity to transmit uplink data includes receiving a message that grants the user device an opportunity to transmit the uplink data at a second PUSCH timing that includes the second time span. Such as the method of claim 8, where: Selecting the preamble or the PRACH timing associated with the first time span includes selecting the preamble associated with the first time span; and Determining that the first time span overlaps with the second time span includes determining that the selected preamble is associated with the first PUSCH opportunity that includes the first time span. Such as the method of claim 8, which includes: Before selecting the preamble or the PRACH timing, receive one of the following indications from the base station: (i) a set of available preambles containing the preamble, and (ii) a set of available preambles containing the PRACH timing PRACH timing. Such as the method of claim 3, where: The method includes, based on the determined transmission priority order, (i) transmitting the uplink data signal during the second time span, (ii) not transmitting the data of the random access procedure message during the first time span Part, and (iii) not transmitting a preamble of the random access procedure message before the first time span; and The method further includes changing the processing hardware to control one or more actions associated with the unsuccessful repetition of the random access procedure, and the one or more actions include one or both of the following: (i) increase A preamble transmission power, and (ii) increment a message transmission counter. Such as the method of any one of claims 3 to 7, wherein: The random access procedure is a contention-based two-step Random Access Channel (RACH) procedure; and The random access procedure message is a message associated with the first step of one of the contention-based two-step RACH procedures. Such as the method of claim 12, wherein the data portion of the random access procedure message includes a physical layer uplink channel (PUSCH) of the message associated with the first step of the contention-based two-step RACH procedure Information in timing. Such as the method of claim 2, where: The message that configures the user device to transmit uplink communication resources is to request a sounding reference signal to transmit a message on the uplink, a message including a channel quality indicator, and a message including a channel status information. Or contains a message for a scheduled request; and Determining the transmission priority is based at least on whether the uplink signal is a sounding reference signal, a message including a channel quality indicator, a message including a channel status information, or a message including a scheduling request. A user device that includes hardware and is configured to implement the method according to any one of claims 1-14.

Images