Switching to RACH transmission in sbfd

Abstract

Example embodiments of the present disclosure are directed to switching to RACH transmission in SBFD. A method comprises determining at least one first random access channel, RACH, occasion and at least one second RACH occasion based on configuration information from a network device, the at least one first RACH occasion comprising uplink resources in a time period comprising uplink resources only, and the at least one second RACH occasion comprising uplink resources in a time period comprising uplink resources and downlink resources; initiating a RACH procedure by using the at least one first RACH occasion; and responsive to a failure in the RACH procedure, determining whether to re-attempt the RACH procedure using the at least one second RACH occasion based on at least one condition.

Description

SWITCHING TO RACH TRANSMISSION IN SBFDFIELD

[0001] Various example embodiments of the present disclosure generally relate to the field of telecommunication and in particular, to methods, devices, apparatuses and computer readable storage medium for switching to random access channel (RACH) transmission in subband non-overlapping full duplex (SBFD) .BACKGROUND

[0002] Currently, the new radio (NR) supports two duplexing modes: Frequency Division Duplex (FDD) for paired bands and Time Division Duplex (TDD) for unpaired bands. In TDD, the time domain resource is split between downlink and uplink. Consequently, the allocation time duration is limited for the uplink in TDD, resulting in reduced coverage, increased latency, and reduced capacity.

[0003] To address the challenges above, a study on the evolution of duplexing operation in NR has been initiated. Subband non-overlapping full duplex (SBFD) has been proposed as a scheme of an enhanced duplex operation. In the SBFD, simultaneous downlink (DL) transmission and uplink (UL) reception at a new radio (NR) NodeB (also referred to as a gNB) on different physical resource blocks (PRBs) within an unpaired wideband NR cell is allowed. This duplexing scheme is also referred to as cross-division duplexing (xDD) or Flexible Duplexing (FDU) .SUMMARY

[0004] In a first aspect of the present disclosure, there is provided a terminal device. The terminal device comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the terminal device at least to: determine at least one first random access channel, RACH, occasion and at least one second RACH occasion based on configuration information from a network device, the at least one first RACH occasion comprising uplink resources in a time period comprising uplink resources only, and the at least one second RACH occasion comprising uplink resources in a time period comprising uplink resources and downlink resources; initiate a RACH procedure by using the at least one first RACH occasion; and responsive to a failure in the RACH procedure, determine whether to re-attempt the RACH procedure using the at least one second RACH occasion based on at least one condition.

[0005] In a second aspect of the present disclosure, there is provided a network device. The network device comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the network device at least to: transmit, to a terminal device, configuration information for a random access channel, RACH, uplink resources and downlink resources, the configuration information indicating at least one first RACH occasion and at least one second RACH occasion, the at least one first RACH occasion comprising uplink resources in a time period comprising uplink resources only, and the at least one second RACH occasion comprising uplink resources in a time period comprising uplink resources and downlink resources; and transmit, to the terminal device, information about at least one condition, wherein the at least one condition is for use by the terminal device in determining whether to re-attempt the RACH procedure using the at least one second RACH occasion responsive to a failure in a RACH procedure initiated by using the at least one first RACH occasion.

[0006] In a third aspect of the present disclosure, there is provided a method. The method comprises: determining, by a terminal device, at least one first random access channel, RACH, occasion and at least one second RACH occasion based on configuration information from a network device, the at least one first RACH occasion comprising uplink resources in a time period comprising uplink resources only, and the at least one second RACH occasion comprising uplink resources in a time period comprising uplink resources and downlink resources; initiating, by the terminal device, a RACH procedure by using the at least one first RACH occasion; and responsive to a failure in the RACH procedure, determining, by the terminal device, whether to re-attempt the RACH procedure using the at least one second RACH occasion based on at least one condition.

[0007] In a fourth aspect of the present disclosure, there is provided a method. The method comprises: transmitting, by a network device to a terminal device, configuration information for a random access channel, RACH, uplink resources and downlink resources, the configuration information indicating at least one first RACH occasion and at least one second RACH occasion, the at least one first RACH occasion comprising uplink resources in a time period comprising uplink resources only, and the at least one second RACH occasion comprising uplink resources in a time period comprising uplink resources and downlink resources; and transmitting, by the network device to the terminal device, information about at least one condition, wherein the at least one condition is for use by the terminal device in determining whether to re-attempt the RACH procedure using the at least one second RACH occasion responsive to a failure in a RACH procedure initiated by using the at least one first RACH occasion.

[0008] In a fifth aspect of the present disclosure, there is provided a first apparatus. The terminal device comprises means for determining at least one first random access channel, RACH, occasion and at least one second RACH occasion based on configuration information from a network device, the at least one first RACH occasion comprising uplink resources in a time period comprising uplink resources only, and the at least one second RACH occasion comprising uplink resources in a time period comprising uplink resources and downlink resources; means for initiating a RACH procedure by using the at least one first RACH occasion; and means for responsive to a failure in the RACH procedure, determine whether to re-attempt the RACH procedure using the at least one second RACH occasion based on at least one condition.

[0009] In a sixth aspect of the present disclosure, there is provided a second apparatus. The network device comprises means for transmitting, to a terminal device, configuration information for a random access channel, RACH, uplink resources and downlink resources, the configuration information indicating at least one first RACH occasion and at least one second RACH occasion, the at least one first RACH occasion comprising uplink resources in a time period comprising uplink resources only, and the at least one second RACH occasion comprising uplink resources in a time period comprising uplink resources and downlink resources; and means for transmitting, to the terminal device, information about at least one condition, wherein the at least one condition is for use by the terminal device in determining whether to re-attempt the RACH procedure using the at least one second RACH occasion responsive to a failure in a RACH procedure initiated by using the at least one first RACH occasion.

[0010] In a seventh aspect of the present disclosure, there is provided a computer readable medium. The computer readable medium comprises instructions stored thereon for causing an apparatus to perform at least the method according to the third aspect.

[0011] In an eighth aspect of the present disclosure, there is provided a computer readable medium. The computer readable medium comprises instructions stored thereon for causing an apparatus to perform at least the method according to the fourth aspect.

[0012] It is to be understood that the Summary section is not intended to identify key or essential features of embodiments of the present disclosure, nor is it intended to be used to limit the scope of the present disclosure. Other features of the present disclosure will become easily comprehensible through the following description.BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Some example embodiments will now be described with reference to the accompanying drawings, where:

[0014] FIG. 1A illustrates an example communication environment in which example embodiments of the present disclosure can be implemented;

[0015] FIG. 1B illustrates a block of SBFD resources and non-SBFD resources;

[0016] FIG. 2A illustrates a 4-step RACH procedure;

[0017] FIG. 2B illustrates a 2-step RACH procedure;

[0018] FIG. 3 illustrates a signaling chart of RACH transmissions according to some example embodiments of the present disclosure;

[0019] FIG. 4 illustrates a signaling chart of an example of RACH transmissions with a failure due to a bad coverage according to some example embodiments of the present disclosure;

[0020] FIG. 5A illustrates a signaling chart of an example of RACH transmissions with a failure due to a bad coverage according to some example embodiments of the present disclosure;

[0021] FIG. 5B illustrates a signaling chart of an example of RACH transmissions with a failure due to a collision according to some example embodiments of the present disclosure;

[0022] FIG. 6 illustrates a signaling chart of an example of RACH transmissions with a failure due to a bad coverage according to some example embodiments of the present disclosure;

[0023] FIG. 7A illustrates a signaling chart of an example of RACH transmissions with a failure due to a bad coverage according to some example embodiments of the present disclosure;

[0024] FIG. 7B illustrates a signaling chart of an example of RACH transmissions with a failure due to a collision according to some example embodiments of the present disclosure;

[0025] FIG. 8 illustrates a flow chart of a procedure of a terminal device according to some example embodiments of the present disclosure;

[0026] FIG. 9A illustrates a flowchart of a method implemented at a terminal device in accordance with some example embodiments of the present disclosure;

[0027] FIG. 9B illustrates a flowchart of a method implemented at a network device in accordance with some example embodiments of the present disclosure;

[0028] FIG. 10 illustrates a simplified block diagram of a device that is suitable for implementing example embodiments of the present disclosure; and

[0029] FIG. 11 illustrates a block diagram of an example computer readable medium in accordance with some example embodiments of the present disclosure.

[0030] Throughout the drawings, the same or similar reference numerals represent the same or similar element.DETAILED DESCRIPTION

[0031] Principle of the present disclosure will now be described with reference to some example embodiments. It is to be understood that these embodiments are described only for the purpose of illustration and help those skilled in the art to understand and implement the present disclosure, without suggesting any limitation as to the scope of the disclosure. Embodiments described herein can be implemented in various manners other than the ones described below.

[0032] In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.

[0033] References in the present disclosure to “one embodiment, ” “an embodiment, ” “an example embodiment, ” and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0034] It shall be understood that although the terms “first, ” “second, ” ..., etc. in front of noun (s) and the like may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another and they do not limit the order of the noun (s) . For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term “and / or” includes any and all combinations of one or more of the listed terms.

[0035] As used herein, “at least one of the following: <a list of two or more elements>” and “at least one of <a list of two or more elements>” and similar wording, where the list of two or more elements are joined by “and” or “or” , mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.

[0036] As used herein, unless stated explicitly, performing a step “in response to A” does not indicate that the step is performed immediately after “A” occurs and one or more intervening steps may be included.

[0037] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms “a” , “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” , “comprising” , “has” , “having” , “includes” and / or “including” , when used herein, specify the presence of stated features, elements, and / or components etc., but do not preclude the presence or addition of one or more other features, elements, components and / or combinations thereof.

[0038] As used in this application, the term “circuitry” may refer to one or more or all of the following: (a) hardware-only circuit implementations (such as implementations in only  analog and / or digital circuitry) and (b) combinations of hardware circuits and software, such as (as applicable) : (i) a combination of analog and / or digital hardware circuit (s) with  software / firmware and (ii) any portions of hardware processor (s) with software (including digital  signal processor (s) ) , software, and memory (ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and (c) hardware circuit (s) and or processor (s) , such as a microprocessor (s) or a  portion of a microprocessor (s) , that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.

[0039] This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

[0040] As used herein, the term “communication network” refers to a network following any suitable communication standards, such as New Radio (NR) , Long Term Evolution (LTE) , LTE-Advanced (LTE-A) , Wideband Code Division Multiple Access (WCDMA) , High-Speed Packet Access (HSPA) , Narrow Band Internet of Things (NB-IoT) and so on. Furthermore, the communications between a terminal device and a network device in the communication network may be performed according to any suitable generation communication protocols, including, but not limited to, the first generation (1G) , the second generation (2G) , 2.5G, 2.75G, the third generation (3G) , the fourth generation (4G) , 4.5G, the fifth generation (5G) , 5.5G, the sixth generation (6G) communication protocols, and / or any other protocols either currently known or to be developed in the future. Embodiments of the present disclosure may be applied in various communication systems. Given the rapid development in communications, there will of course also be future type communication technologies and systems with which the present disclosure may be embodied. It should not be seen as limiting the scope of the present disclosure to only the aforementioned system.

[0041] As used herein, the term “network device” refers to a node in a communication network via which a terminal device accesses the network and receives services therefrom. The network device may refer to a base station (BS) or an access point (AP) , for example, a node B (NodeB or NB) , an evolved NodeB (eNodeB or eNB) , an NR NB (also referred to as a gNB) , a Remote Radio Unit (RRU) , a radio header (RH) , a remote radio head (RRH) , a relay, an Integrated Access and Backhaul (IAB) node, a low power node such as a femto, a pico, a non-terrestrial network (NTN) or non-ground network device such as a satellite network device, a low earth orbit (LEO) satellite and a geosynchronous earth orbit (GEO) satellite, an aircraft network device, and so forth, depending on the applied terminology and technology. In some example embodiments, radio access network (RAN) split architecture comprises a Centralized Unit (CU) and a Distributed Unit (DU) at an IAB donor node. An IAB node comprises a Mobile Terminal (IAB-MT) part that behaves like a UE toward the parent node, and a DU part of an IAB node behaves like a base station toward the next-hop IAB node.

[0042] The term “terminal device” refers to any end device that may be capable of wireless communication. By way of example rather than limitation, a terminal device may also be referred to as a communication device, user equipment (UE) , a Subscriber Station (SS) , a Portable Subscriber Station, a Mobile Station (MS) , or an Access Terminal (AT) . The terminal device may include, but not limited to, a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones, a tablet, a wearable terminal device, a personal digital assistant (PDA) , portable computers, desktop computer, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, vehicle-mounted wireless terminal devices, wireless endpoints, mobile stations, laptop-embedded equipment (LEE) , laptop-mounted equipment (LME) , USB dongles, smart devices, wireless customer-premises equipment (CPE) , an Internet of Things (IoT) device, a watch or other wearable, a head-mounted display (HMD) , a vehicle, a drone, a medical device and applications (e.g., remote surgery) , an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts) , a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. The terminal device may also correspond to a Mobile Termination (MT) part of an IAB node (e.g., a relay node) . In the following description, the terms “terminal device” , “communication device” , “terminal” , “user equipment” and “UE” may be used interchangeably.

[0043] As used herein, the term “resource, ” “transmission resource, ” “resource block, ” “physical resource block” (PRB) , “uplink resource, ” or “downlink resource” may refer to any resource for performing a communication, for example, a communication between a terminal device and a network device, such as a resource in time domain, a resource in frequency domain, a resource in space domain, a resource in code domain, or any other combination of the time, frequency, space and / or code domain resource enabling a communication, and the like. In the following, unless explicitly stated, a resource in both frequency domain and time domain will be used as an example of a transmission resource for describing some example embodiments of the present disclosure. It is noted that example embodiments of the present disclosure are equally applicable to other resources in other domains.

[0044] As used herein, the term “SBFD-aware UE” refers to a UE which is capable of understanding and applying a SBFD-related configuration.

[0045] In the context of the present disclosure, a preamble transmission duration may be referred to as a length in time domain for transmitting a random access preamble. For example, the preamble transmission duration may refer to a time duration (such as, a number of symbols) occupied by transmission of a preamble. Different preamble transmission durations may be associated with different preamble lengths, and / or different preamble formats. In the following, for purpose of illustration without any limitation, if a preamble transmission duration is longer than another preamble transmission duration, the preamble transmission duration may be also referred to as a long PRACH format or a long format or a first format and the other preamble transmission duration may be also referred to as a short PRACH format or a short format or a second format. For example, the preamble transmission duration of a first format may be longer than the preamble transmission duration of a second format. It is noted that for physical random access channel (PRACH) , a sequence of a preamble may be transmitted repetitively for more than one time. Thus, the preamble transmission duration may refer to a time duration of repetitive transmission of the sequence of the preamble. For example, a first format and a second format may have a same preamble length but the first format corresponds to a first number of repetitions of the sequence of the preamble and the second format corresponds to a second number of repetitions of the sequence of the preamble. In this example, if the first number is larger than the second number, the preamble transmission duration of the first format may be longer than the preamble transmission duration of the second format. FIG. 1A illustrates an example communication environment 100A in which example embodiments of the present disclosure can be implemented. In the communication environment 100A, a plurality of communication devices, including a terminal device 110 and a network device 120, can communicate with each other. In the example of FIG. 1A, the terminal device 110 may be a UE and the network device 120 may be a base station serving the UE. The serving area of the network device 120 may be called a cell 102.

[0046] It is to be understood that the number of devices and their connections shown in FIG. 1 are only for the purpose of illustration without suggesting any limitation. The communication environment 100 may include any suitable number of devices configured to implementing example embodiments of the present disclosure. Although not shown, it would be appreciated that one or more additional devices may be located in the cell 102, and one or more additional cells may be deployed in the communication environment 100. It is noted that although illustrated as a network device, the network device 120 may be another device than a network device. Although illustrated as a terminal device, the terminal device 110 may be another device than a terminal device.

[0047] In the following, for the purpose of illustration, some example embodiments are described with the terminal device 110 operating as a UE and the network device 120 operating as a base station. However, in some example embodiments, operations described in connection with a terminal device may be implemented at a network device or other device, and operations described in connection with a network device may be implemented at a terminal device or other device.

[0048] In some example embodiments, a transmission direction from the network device 120 to the terminal device 110 is referred to as a downlink (DL) , while a transmission direction from the terminal device 110 to the network device 120 is referred to as an uplink (UL) . In DL, the network device 120 is a transmitting (TX) device (or a transmitter) and the terminal device 110 is a receiving (RX) device (or a receiver) . In UL, the terminal device 110 is a TX device (or a transmitter) and the network device 120 is a RX device (or a receiver) .

[0049] Communications in the communication environment 100 may be implemented according to any proper communication protocol (s) , comprising, but not limited to, cellular communication protocols, wireless local network communication protocols such as Institute for Electrical and Electronics Engineers (IEEE) 802.11 and the like, and / or any other protocols currently known or to be developed in the future. Moreover, the communication may utilize any proper wireless communication technology, comprising but not limited to: Code Division Multiple Access (CDMA) , Frequency Division Multiple Access (FDMA) , Time Division Multiple Access (TDMA) , Frequency Division Duplex (FDD) , Time Division Duplex (TDD) , Multiple-Input Multiple-Output (MIMO) , Orthogonal Frequency Division Multiple (OFDM) , Discrete Fourier Transform spread OFDM (DFT-s-OFDM) and / or any other technologies currently known or to be developed in the future.

[0050] As briefly mentioned above, SBFD, which is also referred to as xDD or FDU, has been proposed. Reference is now made to FIG. 1B, which illustrates a block 100B of SBFD resources and non-SBFD resources. As can be seen in FIG. 1B, there are two types of slots, i.e., SBFD slots 151 and non-SBFD slots 152 and 153, for both UL and DL transmissions. In the SBFD slots 151, the non-overlapping DL subbands and UL subbands both exist which enable UL and DL transmission simultaneously within a wideband NR cell. In non-SBFD slots 152 and 153, the entire band is used for either DL or UL transmission. It is noted that in the context of the present disclosure, non-SBFD slots are also referred to as legacy slots, full DL slots, and UL slots.

[0051] In SBFD slots, a guard band is expected to be placed between DL and UL subbands. In the guard band the time and frequency resources are reserved that there is no UL or DL transmission. Guard resources 155 may extend to the non-SBFD slots 152. The guard band provides better isolation between UL and DL transmission and may reduce the impact of the self-interference between DL transmissions and UL reception at the gNB as well as cross-link interference (CLI) between UE to UE links, and gNB to gNB links. By enabling simultaneous uplink and downlink transmission, SBFD may improve spectrum efficiently and reduce latency.

[0052] Currently, two contention based random access (CBRA) procedures, i.e. 4-step RACH and 2-step RACH (Rel-16) , and two contention-free random access procedures (CFRA) (that is, 2-step CFRA and 4 step CFRA) are supported in 5G NR. A common step in all these procedures is the transmission of a suitable message by the UE to NW (the nature of the message changes depending on which procedure is executed, but the first action is always for the UE) .

[0053] Reference is now made to FIG. 2A. As shown in FIG. 2A, the 4-step RACH procedure 200A may be summarized as follows below. Message 1 (shorted as Msg1 and also known as PRACH or PRACH preamble) indicates that the UE (as an example of the terminal device 110) sends a specific preamble to the gNB (as an example of the network device 120) via PRACH using a specific resource called a RACH occasion (RO) . The RO may be mapped to one or more synchronization signal block (SSB) beams according to a certain pattern. Message 2 (shorted as Msg2 and also known as Random access response, RAR) indicates that the gNB replies with an RAR message, which includes the detected preamble ID, the time-advance command, a temporary cell (TC) -radio network temporary identifier (RNTI) , and UL grant for the transmission on physical uplink shared channel (PUSCH) . Message 3 (shorted as Msg3 and also known as radio resource control (RRC) request) indicates that the UE responds to Msg2 over the scheduled PUSCH with an ID for contention resolution. Further, Message 4 (shorted as Msg4 and also known as RRC setup) indicates that the gNB transmits the contention resolution message with the contention-resolution ID.

[0054] Upon reception of Msg4, the UE sends an acknowledgement (ACK) on a physical uplink control channel (PUCCH) if its contention-resolution ID is carried by Msg4. This completes the 4-step RACH. It is worth noting that prior to Msg1, there is also a preliminary step of sending and receiving the SSB, i.e., DL beam sweeping, which is not formally part of the RACH procedure. As a result of this preliminary step, the UE selects the index of the preferred SSB beam and decodes the associated PBCH for master information block (MIB) , system information block (SIB) and so on. This index is also used by UE to identify a suitable RO for the preamble transmission (Msg1) , according to the SSB-to-RO mapping conveyed by SIB 1.

[0055] Reference is now made to FIG. 2B. FIG. 2B illustrates a 2-step RACH procedure 200B which is similar to 4-step RACH presented above. Specifically, Msg1 and Msg3 in the 4-step RACH are combined in a message A (shorted as MsgA) and sent out without waiting for feedback from the gNB in between (i.e., Msg2 in the 4-step RACH) . Similarly, the gNB combines Msg2 and Msg4 in the 4-step RACH into a message B (shorted as MsgB) .

[0056] The gNB may configure the RACH procedure to the UE. For example, the information element (IE) RACH-ConfigGeneric may be used to specify the random-access parameters both for regular random access as well as for beam failure recovery. An example of the IE RACH-ConfigGeneric is shown as below:

[0057] Some fields are highlighted in bold in the IE RACH-ConfigGeneric. The parameter preambleTransMax indicates the maximum number of initial accesses retry in case of the failure of the transmission of the preamble. The parameter powerRampingStep indicates the power ramping step in PRACH transmission for each initial access retry in case of the failure. The parameter ra-ResponseWindow indicates the time a UE is required to wait to re-transmit PRACH in case of RAR failure, which may mean that Msg2 is not received due to downlink control information (DCI) not detected or PDSCH being invalid.

[0058] Normative works are being performed to support random access in SBFD symbols. These normative works consider UEs in RRC_CONNECTED mode and in RRC_IDLE / INACTIVE mode. With UL subbands signaled in SBFD, these normative works intend to make use of the ROs in UL subbands of SBFD symbols (i.e., consider them to be valid) , which are referred to as additional ROs. Meanwhile the ROs in UL symbols in non-SBFD slots are referred to as UL ROs.

[0059] For SBFD-aware UEs in RRC_CONNECTED state, both RACH configuration Option 1 and RACH configuration Option 2 are supported. In RACH configuration Option 1, one single RACH configuration is used for both the UL ROs and additional ROs, and the UL ROs and additional ROs are only based on the existing parameters of the single RACH configuration. In RACH configuration Option 2, two separate RACH configurations, including one legacy RACH configuration for the UL ROs and one additional RACH configuration for the additional ROs are used.

[0060] Currently in 5G NR, upon initiation of CBRA RACH procedure, a SBFD-aware UE may select one type of ROs among the UL ROs and additional ROs based on certain specified / configured conditions / prioritizations. In a case that UE selects additional ROs and performs a RACH procedure, the UE is allowed to switch to UL ROs for the PRACH transmission re-attempt after a certain (configured) number of RACH attempts in additional ROs. However, in a case the UE selects the UL ROs first, it has not been defined whether the UE is allowed to switch or fall back to additional ROs.

[0061] In general, interference conditions in UL ROs are better compared to the additional ROs. However, successful initial access might not only depend on the interference conditions in the ROs. Indeed, an SBFD-aware UE could fail to achieve the initial access using the UL ROs due to two main reasons: the SBFD-aware UE does not receive an RAR response (Msg2) from the network device (i.e., the network device fails to receive Msg1) , or the SBFD-aware UE does not receive the contention resolution message (Msg4) . A failure in the reception of the RAR response (Msg2) indicates a bad coverage of PRACH. A failure in the reception of the contention resolution message (Msg4) indicates a collision between different UEs performing random access to the network.

[0062] It is noted that the probability of collision in the RACH procedure may depend at least on the number of UEs trying to perform a random access on the same RACH resources. For SBFD, collision probability may vary between SBFD ROs and UL ROs considering that only SBFD-aware UEs may be capable of transmitting on the SBFD ROs. Since there are less UEs using the additional ROs, the probability of collision is reduced.

[0063] It can be observed that UE may distinguish between the two reasons of failure according to the failure of reception of the Msg2 and Msg4. For each reason of failure, UE may determine whether to switch (from UL RO) to SBFD RO or not, based on certain (configured) conditions. The solution of conditions and rules for UE to determine whether to switch from UL RO to SBFD RO is proposed in the present disclosure.

[0064] In accordance with some example embodiments of the present disclosure, there is provided a solution for switching to RACH transmission in SBFD. According to the present disclosure, a terminal device determines at least one first RO and at least one second RO based on configuration information from a network device. The at least one first RO comprises uplink resources in a time period comprising uplink resources only, and the at least one second RO comprises uplink resources in a time period comprising uplink resources and downlink resources. The terminal device initiates a RACH procedure by using the at least one first RO. If the RACH procedure is failed, the terminal device determines whether to re-attempt the RACH procedure using the at least one second RO based on at least one condition.

[0065] In embodiments of the present disclosure, if the RACH procedure on UL ROs is failed, the terminal device may determine whether to re-attempt the RACH procedure using SBFD ROs based on at least one condition or rule. The solution of the present disclosure may enable a more reliable and efficient random access procedure.

[0066] Example embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings.

[0067] FIG. 3 illustrates a signaling flow 300 of RACH transmissions according to some example embodiments of the present disclosure. For the purpose of illustration, the signaling flow 300 is described with respect to FIG. 1. The signaling flow 300 involves the terminal device 110 and the network device 120. The terminal device 110 may be an SBFD aware terminal device, for example, an SBFD aware UE.

[0068] The network device 120 may transmit (302) , to the terminal device 110, configuration information for RACH, UL resources and DL resources. Correspondingly, the terminal device 110 may receive (304) the configuration information. The configuration information may indicate an SBFD configuration and at least one RACH configuration. In some example embodiments, the RACH configuration Option 1 may be employed, and thus one single RACH configuration may be indicated. In some example embodiments, the RACH configuration Option 2 may be employed and thus two separate RACH configurations may be indicated. RACH configuration may be referred to as PRACH configuration in some examples.

[0069] The terminal device 110 determines (310) at least one first RO and at least one second RO based on the configuration information. The at least one first RO includes uplink resources in a time period including uplink resources only, and the at least one second RO includes uplink resources in a time period including uplink resources and downlink resources. For example, the at least one first RO may include UL resources in an UL slot (non-SBFD slot) , and the at least one second RO may include UL resources in an SBFD slot. As used herein, the first RO may be referred to as the UL RO or the legacy RO or non-SBFD RO, and the second RO may be referred to as the additional RO or the SBFD RO.

[0070] The terminal device 110 initiates (312) a RACH procedure by using the at least one first RO. For example, the terminal device 110 may select one or more first ROs form the at least one first RO, and transmit a PRACH preamble on the one or more first ROs. The RACH procedure may be a 4-step RACH procedure, a 2-step RACH procedure, or any other suitable RACH procedure. In some example embodiments, the terminal device 110 may determine to use the first RO based on certain specified / configured conditions / prioritizations. For example, the terminal device 110 may determine to use the first RO based on SSB-RSRP thresholds.

[0071] In some example embodiments, the terminal device may determine to use the first RO based on an indication received from the network device. As shown in FIG. 3, the network device 120 may transmit (306) , to the terminal device 110, an indication to use the at least one first RO. Correspondingly, the terminal device 110 may receive (308) the indication form the network device 120. For example, the indication indicating the selection of the first RO may be transmitted via at least one of DCI, SIB or an RRC parameter. Based on the indication from the network device 120, the terminal device 110 may determine to use the first RO and thus initiate (312) the RACH procedure.

[0072] The terminal device 110 may detect a RACH failure, for example, based on not receiving a message of the RACH procedure. For example, based on not receiving Msg2, the terminal device may detect a RACH failure. For example, based on not receiving Msg4, the terminal device may detect a RACH failure. If the RACH procedure is failed, the terminal device 110 determines (322) whether to re-attempt the RACH procedure using the at least one second RO based on at least one condition. The at least one condition may be associated with one or more message in the RACH procedure that cause the failure in the procedure. Alternatively, or in addition, the at least one condition may be associated with a RACH configuration for the first RO and second RO. The at least one condition may be associated with a reason of the RACH failure.

[0073] In some example embodiments, the network device 120 may transmit information about the at least one condition to the terminal device 110. For example, the information may define or specify each of the at least one condition to be used by the terminal device 110. For another example, the information may indicate or instruct the terminal device 110 to select the at least one condition to use from a plurality of predefined or preconfigured conditions.

[0074] In some example embodiments, the at least one condition may be predefined or preconfigured to the terminal device 110. The information about the at least one condition may include an indication to apply the at least one condition. That is, the indication may be used to activate the at least one condition. For example, if the failure is detected in the RACH procedure, the terminal device 110 may check whether such an indication is received. If the indication is received, the terminal device 110 may determine whether to re-attempt the RACH procedure using the at least one second RO based on at least one condition.

[0075] In some example embodiments, the at least one condition is always activated without a separate indication from the network.

[0076] In some example embodiments, the at least one condition may include whether the failure in the RACH procedure is related to a random access request. As shown in FIG. 3, the terminal device 110 may determine (314) whether the failure in the RACH procedure is related to the random access request, for example, related to Msg1 in case of the 4-step RACH procedure or MsgA in case of the 2-step RACH procedure.

[0077] Alternatively, or in addition, in some example embodiments, the at least one condition may include whether the failure in the RACH procedure is related to a data carrying message (for example, Msg3) . As shown in FIG. 3, the terminal device 110 may determine (316) whether the failure in the RACH procedure is related to the data carrying message, for example related to Msg3 in case of 4-step RACH procedure.

[0078] Alternatively, or in addition, in some example embodiments, the at least one condition may include whether the failure in the RACH procedure is related to a contention resolution message. As shown in FIG. 3, the terminal device 110 may determine (318) whether the failure in the RACH procedure is related to a contention resolution message, for example, related to Msg4 in case of the 4-step RACH procedure or MsgB in case of the 2-step RACH procedure.

[0079] Alternatively, or in addition, in some example embodiments, the at least one condition may include whether a second preamble transmission duration associated with the at least one second RO is greater than a first preamble transmission duration associated with the at least one first RO. For example, the preamble transmission duration may be the time length related to the PRACH format. A longer PRACH format may support a greater preamble transmission duration. As shown in FIG. 3, the terminal device 110 may determine (320) whether the second preamble transmission duration is greater than the first preamble transmission duration. For example, the terminal device 110 may determine whether the second RO has a PRACH format longer than the first RO.

[0080] In some example embodiments, if the second preamble transmission duration is greater than the first preamble transmission duration, the terminal device 110 may determine to re-attempt the RACH procedure by using the at least one second RO. For example, if the at least one second RO has a PRACH format longer than the at least one first RO, the terminal device 110 may switch to the at least one second RO for re-attempting the random access to the network device 120. If the second preamble transmission duration is not greater than the first preamble transmission duration, the terminal device 110 may determine not to re-attempt the RACH procedure by using the at least one second RO. In this case, the terminal device 110 may initiate a new RACH procedure, e.g. using the at least one first RO. For example, if the at least one second RO has a PRACH format shorter than or the same as the at least one first RO, the terminal device 110 may not switch to the at least one second RO. In this case, the terminal device 110 may initiate a new RACH procedure, e.g. using the at least one first RO.

[0081] In some example embodiments, a cause of the failure in the RACH procedure may be determined based on the at least one condition. For example, the terminal device 110 may determine the cause of the failure of the previous RACH attempt based on one or more message in the RACH procedure that related to the failure or based on a progress on the RACH procedure when the failure occurs.

[0082] For example, the UE may determine the cause of the failure based on the reception (or based on a failed reception or non-reception) of the Msg2 and Msg4. The SBFD-aware UE may determine whether to switch to additional ROs based on the cause of the failure. The cause of the failure is one of: abad coverage; or collision. For example, if Msg2 is not received by the UE, the UE may determine that the failure may be due to a bad coverage of PRACH. For another example, if Msg4 is not received by the UE, the UE may determine that the failure may be due to collision. For yet another example, if Msg4 is not received by the UE, the UE may determine that the failure may be due to a bad coverage of Msg3 channel, which leads to Msg3 reception failure at the network (NW) .

[0083] Based on the cause of the failure, the terminal device 110 may determine whether to switch to the second RO or not. In some example embodiments, the terminal device 110 may determine whether to switch to the second RO based on rules and conditions described below with examples.

[0084] In some example embodiments, the terminal device 110 may determine whether the failure is caused by collision of the terminal device with at least one other terminal device based on one or more messages in the RACH procedure that are related to the failure.

[0085] In some example embodiments, if the terminal device 110 does not receive DCI for scheduling retransmission of a data carrying message, the terminal device 110 may determine that the failure is caused by the collision. For example, if the terminal device 110 does not receive a content resolution message with an identity of the terminal device 110, the terminal device 110 may determine that the failure is caused by the collision. For example, if the terminal device 110 does not receive DCI for scheduling retransmission of Msg3, the terminal device 110 may determine that the failure is due to collision with other terminal devices. For example, if the terminal device 110 does not receive Msg4 with a contention resolution identity of the terminal device 110, the terminal device 110 may determine that the failure is due to collision with other terminal devices. If the terminal device 110 receives a content resolution message with an identity of another terminal device, the terminal device 110 may determine that the failure is caused by the collision. For example, if the terminal device 110 receives Msg4 with a wrong contention resolution identity, the terminal device 110 may determine that the failure is due to collision with other terminal devices.

[0086] If the failure is caused by the collision, the terminal device 110 may determine to re-attempt the RACH procedure by using the at least one second RO. For example, a high number of UE, including SBFD-aware UEs and legacy UEs (i.e., UE that not capable of using SBFD ROs) , may be using the UL ROs. Therefore, there is a high probability of a collision between UEs. Considering that only the SBFD-aware UEs are capable of using the additional ROs, switching to the additional ROs may provide a better probability of non-collision since fewer UEs are using the additional ROs. Therefore, the SBFD-aware UE may switch to additional ROs for a better chance to achieve initial access.

[0087] In some example embodiments, the terminal device 110 may determine whether the failure is caused by a coverage state of the terminal device based on one or more messages in the RACH procedure that are related to the failure. For example, the terminal device 110 may determine whether the cause of the failure is a bad coverage of the terminal device 110. For another example, the terminal device 110 may determine whether the cause of the failure is a coverage issue of the terminal device 110. The coverage issue may include that the terminal device 110 is located at an edge of the coverage of the network device 120, or is out of the coverage of the network device 120. As a result of the coverage issue, a signal from the terminal device 110 to the network device 120 may be weak at the network device 120. There may be a threshold for defining when the signal is considered weak. A coverage state as used herein may refer to a coverage issue, or a bad coverage, or a signal issue, or a weak signal.

[0088] In some example embodiments, if the terminal device 110 does not receive, from the network device 120, a RAR to a random access request, the terminal device 110 may determine that the failure is caused by the coverage state. For example, if the terminal device 110 does not receive Msg2 from the network device 120, the terminal device 110 may determine that the cause of the failure is the bad coverage of the terminal device 110. If the terminal device 110 receives DCI for scheduling retransmission of a data carrying message and / but does not receive a content resolution message with an identity of the terminal device 110, the terminal device 110 may determine that the failure is caused by the coverage state. For example, if the terminal device 110 receives DCI for scheduling retransmission of MSg3 and / but does not receive Msg4 with a contention resolution identity of the terminal device 110, the terminal device 110 may determine that the cause of the failure is the bad coverage of the terminal device 110.

[0089] For example, if the RAR (Msg2) is not received by the UE, the UE may determine that the failure may be due to bad coverage of PRACH channel. For another example, if the UE receives DCI for scheduling retransmission of data carrying message (Msg3) , the UE may determine that the failure may be due to bad coverage of PRACH channel.

[0090] If the failure is caused by the coverage state of the terminal device 110, the terminal device 110 may determine whether to re-attempt the RACH procedure using the at least one second RO based on whether the second preamble transmission duration is greater than the first preamble transmission duration.

[0091] If the second preamble transmission duration is greater than the first preamble transmission duration, the terminal device 110 may determine to re-attempt the RACH procedure by using the at least one second RO. For example, in a case that the additional ROs are configured with a longer PRACH format than the UL ROs, the UE may determine to re-attempt the RACH procedure using the additional ROs since the additional ROs have a better coverage state.

[0092] If the second preamble transmission duration is not greater than the first preamble transmission duration, the terminal device 110 may determine not to re-attempt the RACH procedure by using the at least one second RO. For example, in a case that the additional ROs and the legacy ROs have the same PRACH configuration index (PCI) , the UE may determine not to re-attempt the RACH procedure using the additional ROs. That is because that the additional ROs have the same coverage state with the UL RO and the interference conditions of the additional RO s are worse than the UL RO s due to the DL subbands available alongside the UL subband in SBFD slots.

[0093] In some example embodiments, if the failure is related to a random access request transmitted to the network device 120, the terminal device 110 may determine whether he second preamble transmission duration is greater than the first preamble transmission duration.

[0094] In some example embodiments, if the second preamble transmission duration is not greater than the first preamble transmission duration, the terminal device 110 may determine not to re-attempt the RACH procedure by using the at least one second RO. For example, if the failure is related to Msg1 and the second RO has a PRACH format shorter than or equal to the first RO, the terminal device 110 may not switch to the second RO. An example of such example embodiments is described hereinafter with reference to FIG. 4.

[0095] In some example embodiments, if the second preamble transmission duration is greater than the first preamble transmission duration, the terminal device 110 may determine to re-attempt the RACH procedure by using the at least one second RO. For example, if the failure is related to Msg1 and the second RO has a PRACH format longer than the first RO, the terminal device 110 may switch to the second RO. An example of such example embodiments is described hereinafter with reference to FIG. 6.

[0096] In some example embodiments, if the failure is related to a contention resolution message from the network device 120, the terminal device 110 may determine whether DCI for scheduling retransmission of a data carrying message is received by the terminal device.

[0097] In some example embodiments, if the DCI is not received, the terminal device 110 may determine to re-attempt the RACH procedure by using the at least one second RO. For example, if DCI scheduling retransmission of Msg3 is not received, the terminal device 110 may switch to the second RO regardless of the preamble transmission duration. An example of such example embodiments is described hereinafter with reference to FIG. 5B and FIG. 7B.

[0098] In some example embodiments, if the DCI is received, the terminal device 110 may determine whether the second preamble transmission duration is greater than the first preamble transmission duration.

[0099] In some example embodiments, if the second preamble transmission duration is not greater than the first preamble transmission duration, the terminal device 110 may determine not to re-attempt the RACH procedure by using the at least one second RO. An example of such example embodiments is described hereinafter with reference to FIG. 5A.

[0100] In some example embodiments, if the second preamble transmission duration is greater than the first preamble transmission duration, the terminal device 110 may determine to re-attempt the RACH procedure by using the at least one second RO. An example of the example embodiments is described hereinafter with reference to FIG. 7A.

[0101] To better understand the example embodiments, some examples are described in detail below.

[0102] As mentioned above, in some example embodiments, if the failure is related to the random access request transmitted to the network device 120 and the second preamble transmission duration is not greater than the first preamble transmission duration, the terminal device 110 may determine not to re-attempt the RACH procedure by using the at least one second RO. An example is now described with reference to FIG. 4 which illustrates a signaling chart of an example of RACH transmissions with a failure due to a bad coverage according to some example embodiments of the present disclosure. The signaling chart 400 involves a UE 410 and a NW 420. The UE 410 may be considered as an example of the terminal device 110 of FIG. l, and the NW 420 may be considered as an example of the network device 120 of FIG. 1.

[0103] The NW 420 may transmit (402) an SBFD configuration and a RACH configuration to the UE 410. Correspondingly, the UE 410 may receive (404) the SBFD configuration and RACH configuration from the NW 420.

[0104] For example, the UE 410 may receive the SBFD configuration and RACH configuration Option 1 or RACH configuration Option 2. The SBFD configuration provides information on the location of SBFD symbols and UL and DL sub-bands in the SBFD symbols. The RACH configuration Option 1 or RACH configuration Option 2 provides information on the location of ROs in time and frequency domains, as well as the SSBs associated to the ROs and the preamble format. In this example, the RACH configuration Option 1 may indicate a short PRACH format for both the UL ROs and the additional ROs, or RACH configuration Option 2 may include an additional PCI which indicates a short PRACH format for the additional RO s.

[0105] Additionally, the UE 410 may receive an indication indicating the selection of the UL ROs. The indication may be transmitted by at least one of the DCI, SIB, or an RRC parameter.

[0106] The UE 410 may determine (406) two types of ROs, namely the UL ROs and the additional ROs based on the SBFD configuration and the RACH configuration. The UE 410 may transmit (408) a PRACH preamble (which is also referred to Msg1) on at least one of the UL ROs. The PRACH preamble may be transmitted with repetitions or without repetitions.

[0107] For example, the UE 410 may select the UL ROs for the initial attempt of random access based on one or more specified or configured conditions, or specified or configured prioritizations (e.g., SSB-RSRP thresholds, etc. ) . Alternatively, or additionally, the UE 410 may select the UL ROs for the initial attempt of random access based on the indication received from the NW 420.

[0108] The NW 420 does not receive the Msg 1 for example due to the bad coverage of the UE 410. The UE 410 does not receive a RAR (which is also referred to as Msg2) to the PRACH preamble after waiting for a period of time indicated by the parameter fa-Response Window.

[0109] Accordingly, the UE 410 re-attempt (412) the transmission of the Msg1 for X number of times with or without PRACH repetition and failed. For example, the parameter X may be same as preamble TransMax, or preamble TransMax-Msg1-Repetition in case of msg1 repetition. Alternatively, the parameter X may be a separated parameter from preamble TransMax, or preamble TransMax-Msg1-R epetition.

[0110] In this case, the UE 410 may determine (414) not to fall back to the additional ROs. The UE 410 may follow the legacy behavior, for example, may initiate a new random access procedure, e.g. using the UL ROs. For example, the UE may retry access with the same network device or another network device.

[0111] As mentioned above, in some example embodiments, if the failure is related to a contention resolution message from the network device 120 and the DCI is received and the second preamble transmission duration is not greater than the first preamble transmission duration, the terminal device 110 may determine not to re-attempt the RACH procedure by using the at least one second RO. An example is now described with reference to FIG. 5A which illustrates a signaling chart of an example of RACH transmissions with a failure due to a bad coverage according to some example embodiments of the present disclosure. The signaling chart 500A involves the UE 410 and the NW 420.

[0112] The NW 420 may transmit (502) an SBFD configuration and a RACH configuration to the UE 410. Correspondingly, the UE 410 may receive (504) the SBFD configuration and RACH configuration from the NW 420.

[0113] For example, the UE 410 may receive the SBFD configuration and RACH configuration Option 1 or RACH configuration Option 2. The SBFD configuration provides information on the location of SBFD symbols and UL and DL sub-bands in the SBFD symbols. The RACH configuration Option 1 or RACH configuration Option 2 provides information on the location of ROs in time and frequency domains, as well as the SSBs associated to the ROs and the preamble format. In this example, the RACH configuration Option 1 may indicate a short PRACH format for both the UL ROs and the additional ROs, or RACH configuration Option 2 may include an additional PCI which indicates a short PRACH format for the additional RO s.

[0114] Additionally, the UE 410 may receive an indication indicating the selection of the UL ROs. The indication may be transmitted by at least one of the DCI, SIB, or an RRC parameter.

[0115] The UE 410 may determine (506) two types of ROs, namely the UL ROs and the additional ROs based on the SBFD configuration and the RACH configuration. The UE 410 may transmit (508) a PRACH preamble (which is also referred to Msg1) on at least one of the UL ROs. The PRACH preamble may be transmitted with repetitions or without repetitions. Correspondingly, the NW 420 may receive (512) the PRACH preamble.

[0116] For example, the UE 410 may select the UL ROs for the initial attempt of random access based on one or more specified or configured conditions, or specified or configured prioritizations (e.g., SSB-RSRP thresholds, etc. ) . Alternatively, or additionally, the UE 410 may select the UL ROs for the initial attempt of random access based on the indication received from the NW 420.

[0117] The NW 420 may transmit (514) a RAR (which is also referred to as Msg2) to the PRACH preamble to the terminal device 110. Correspondingly, the terminal device 110 may receive (516) the RAR from the NW 420.

[0118] For example, the UE 410 may receive the RAR from the NW 420 with a UL grant for scheduling Msg3 transmission. In this example, the UE 410 may detect the DCI 1_0 with CRC scrambled by the corresponding RA-RNTI from the NW 420 and its corresponding PDSCH including the contention resolution identity.

[0119] The UE 420 may transmit (518) the RRC request (which is also referred to as Msg3) to the NW 420. The Msg3 may be transmitted with repetitions or without repetitions. For example, the UE may respond to Msg2 over the scheduled Msg3 with a contention resolution ID.

[0120] The NW 420 does not receive the Msg 3 for example due to the bad coverage of the UE 410. Accordingly, the NW 420 may transmit (522) a DCI 0_0 scrambled by TC-RNTI to the UE 410. Correspondingly, the UE 410 may receive (524) the DCI 0_0 from the NW 420. For example, the UE 410 may receive from the NW at least one Msg3 PUSCH re-transmission scheduled with DCI 0_0 scrambled by TC-RNTI.

[0121] Accordingly, the UE 410 may transmit (526) the Msg3 to the NW 420 for X number of times with or without PRACH repetition and failed. For example, the parameter X may be same as preambleTransMax, or preambleTransMax-Msg1-Repetition in case of msg1 repetition. Alternatively, the parameter X may be a separated parameter from preambleTransMax, or preambleTransMax-Msg1-Repetition. The Msg3 may be transmitted with repetitions or without repetitions after each retransmission request.

[0122] The NW 420 does not receive the Msg 3 for example due to the bad coverage of the UE 410. The UE 410 does not receive RRC setup message (Msg4) from the NW 420 before a contention resolution timer is expired (528) . For example, the Msg4 may include PDSCH with contention resolution identity.

[0123] In this case, the UE 410 may determine (532) not to fall back to the additional ROs. The UE 410 may follow the legacy behavior, for example, may initiate a new random access procedure, e.g. using the UL ROs. For example, the UE may retry access with the same network device or another network device.

[0124] As mentioned above, in some example embodiments, if the failure is related to a contention resolution message from the network device and the DCI is not received, the terminal device 110 may determine to re-attempt the RACH procedure by using the at least one second RO. An example is now described with reference to FIG. 5B which illustrates a signaling chart of an example of RACH transmissions with a failure due to a collision according to some example embodiments of the present disclosure. The signaling chart 500B involves the UE 410 and the NW 420. The acts 502-518 of FIG. 5B are the same as those in FIG. 5A and description thereof is omitted herein.

[0125] The signaling chart 500B is now going to 534. In this example, the UE 410 does not receive, from the NW 420, the DCI 0_0 for retransmission of Msg3. For example, the NW 420 may fail to decode the Msg3 due to two or more UEs sending the same information on Msg3 which leads to a collision between different UEs.

[0126] In one example, the UE 410 does not receive RRC setup message (Msg4) from the NW 420 before a contention resolution timer is expired (534) . The Msg4 may include PDSCH with contention resolution identity.

[0127] In another example, the UE 410 may receive Msg4 with a wrong contention resolution identity of another UE accessing the NW. In other words, the UE 410 does not receive the correct contention resolution identity.

[0128] In this case, the UE 410 may determine (536) to fallback to additional ROs for the re-attempt of the initial random access. The UE 410 may transmit to the NW 420 a PRACH preamble on the additional RO. For example, the UE 410 may re-apply RA steps (Msg1, Msg2, Msg3 and Msg4) using UL ROs and initial access may be achieved.

[0129] As mentioned above, in some example embodiments, if the failure is related to a random access request transmitted to the network device 120 and the second preamble transmission duration is greater than the first preamble transmission duration, the terminal device 110 may determine to re-attempt the RACH procedure by using the at least one second RO. An example is now described with reference to FIG. 6 which illustrates a signaling chart of an example of RACH transmissions with a failure due to a bad coverage according to some example embodiments of the present disclosure. The signaling chart 600 involves the UE 410 and the NW 420.

[0130] The NW 420 may transmit (602) an SBFD configuration and a RACH configuration to the UE 410. Correspondingly, the UE 410 may receive (604) the SBFD configuration and RACH configuration from the NW 420.

[0131] For example, the UE 410 may receive the SBFD configuration and RACH configuration Option 2. The SBFD configuration provides information on the location of SBFD symbols and UL and DL sub-bands in the SBFD symbols. The RACH configuration Option 2 provides information on the location of ROs in time and frequency domains, as well as the SSBs associated to the ROs and the preamble format. In this example, the RACH configuration Option 2 may include an additional PCI which indicates a long PRACH format for the additional RO s.

[0132] Additionally, the UE 410 may receive an indication indicating the selection of the UL ROs. The indication may be transmitted by at least one of the DCI, SIB, or an RRC parameter.

[0133] The UE 410 may determine (606) two types of ROs, namely the UL ROs and the additional ROs based on the SBFD configuration and the RACH configuration. The UE 410 may transmit (608) a PRACH preamble (which is also referred to as Msg1) on at least one of the UL ROs. The PRACH preamble may be transmitted with repetitions or without repetitions.

[0134] For example, the UE 410 may select the UL ROs for the initial attempt of random access based on one or more specified or configured conditions, or specified or configured prioritizations (e.g., SSB-RSRP thresholds, etc. ) . Alternatively, or additionally, the UE 410 may select the UL ROs for the initial attempt of random access based on the indication received from the NW 420.

[0135] The NW 420 does not receive the Msg 1 for example due to the bad coverage of the UE 410. The UE 410 does not receive a RAR (which is also referred to as Msg2) to the PRACH preamble after waiting for a period of time indicated by the parameter fa-Response Window.

[0136] Accordingly, the UE 410 may re-attempt (612) the transmission of the Msg1 for X number of times with or without PRACH repetition and failed. For example, the parameter X may be same as preamble TransMax, or preamble TransMax-Msg1-Repetition in case of msg1 repetition. Alternatively, the parameter X may be a separated parameter from preambleTransMax, or preambleTransMax-Msg1-Repetition.

[0137] In this case, the UE 410 may determine (614) to fall back to the additional ROs for the re-attempt of the initial random access. The UE 410 may transmit to the NW 420 a PRACH preamble on the additional RO. For example, the UE 410 may re-apply RA steps (Msg1, Msg2, Msg3 and Msg4) and initial access may be achieved.

[0138] As mentioned above, in some example embodiments, if the failure is related to a contention resolution message from the network device 120, and the DCI is received and the second preamble transmission duration is greater than the first preamble transmission duration, the terminal device 110 may determine to re-attempt the RACH procedure by using the at least one second RO. An example is now described with reference to FIG. 7A which illustrates a signaling chart of an example of RACH transmissions with a failure due to a collision according to some example embodiments of the present disclosure. The signaling chart 700A involves the UE 410 and the NW 420.

[0139] The NW 420 may transmit (702) an SBFD configuration and a RACH configuration to the UE 410. Correspondingly, the UE 410 may receive (704) the SBFD configuration and RACH configuration from the NW 420.

[0140] For example, the UE 410 may receive the SBFD configuration and RACH configuration Option 2. The SBFD configuration provides information on the location of SBFD symbols and UL and DL sub-bands in the SBFD symbols. The RACH configuration Option 2 provides information on the location of ROs in time and frequency domains, as well as the SSBs associated to the ROs and the preamble format. In this example, the RACH configuration Option 2 may include an additional PCI which indicates a long PRACH format for the additional RO s.

[0141] Additionally, the UE 410 may receive an indication indicating the selection of the UL ROs. The indication may be transmitted by at least one of the DCI, SIB, or an RRC parameter.

[0142] The UE 410 may determine (706) two types of ROs, namely the UL ROs and the additional ROs based on the SBFD configuration and the RACH configuration. The UE 410 may transmit (708) a PRACH preamble (which is also referred to Msg1) on at least one of the UL ROs. The PRACH preamble may be transmitted with repetitions or without repetitions. Correspondingly, the NW 420 may receive (712) the PRACH preamble from the UE 410.

[0143] For example, the UE 410 may select the UL ROs for the initial attempt of random access based on one or more specified or configured conditions, or specified or configured prioritizations (e.g., SSB-RSRP thresholds, etc. ) . Alternatively, or additionally, the UE 410 may select the UL ROs for the initial attempt of random access based on the indication received from the NW 420.

[0144] The NW 420 may transmit (714) a RAR (which is also referred to as Msg2) to the PRACH preamble to the terminal device 110. Correspondingly, the terminal device 110 may receive (716) the RAR from the NW 420.

[0145] For example, the UE 410 may receive RAR from the NW 420 with a UL grant for scheduling Msg3 transmission. In this example, the UE 410 may detect the DCI 1_0 with CRC scrambled by the corresponding RA-RNTI from the NW 420 and its corresponding PDSCH including the contention resolution identity.

[0146] The UE 420 may transmit (718) the RRC request (which is also referred to as Msg3) to the NW 420. The Msg3 may be transmitted with repetitions or without repetitions. For example, the UE may respond to Msg2 over the scheduled Msg3 with an ID contention resolution.

[0147] The NW 420 does not receive the Msg 3 for example due to the bad coverage of the UE 410. Accordingly, the NW 420 may transmit (722) a DCI 0_0 scrambled by TC-RNTI. Correspondingly, the UE 410 may receive (724) the DCI 0_0 from the NW 420.

[0148] For example, the UE 410 may receive from the NW at least one Msg3 PUSCH re-transmission scheduled with DCI 0_0 scrambled by TC-RNTI.

[0149] Accordingly, the UE 410 may transmit (726) the Msg3 to the NW 420 for X number of times with or without PRACH repetition and failed. For example, the parameter Xmay be the same as preamble TransMax, or preambleTransMax-Msg1-Repetition in case of msg1 repetition. Alternatively, the parameter X may be a separated parameter from preambleTransMax, or preambleTransMax-Msg1-Repetition. The Msg3 may be transmitted with repetitions or without repetitions after each retransmission request.

[0150] The NW 420 does not receive the Msg 3 for example due to the bad coverage of the UE 410. The UE 410 does not receive RRC setup message (Msg4) from the NW 420 before a contention resolution timer is expired (728) . For example, the Msg4 may include PDSCH with contention resolution identity.

[0151] In this case, the UE 410 may determine (732) to fall back to the additional ROs the re-attempt of the initial random access, since the addition RO has a long PRACH format. The UE 410 may transmit to the NW 420 a PRACH preamble on the additional RO. For example, the UE 410 may re-apply RA steps (Msg1, Msg2, Msg3 and Msg4) and initial access may be achieved.

[0152] As mentioned above, in some example embodiments, if the failure is related to a contention resolution message from the network device and the DCI is not received, the terminal device 110 may determine to re-attempt the RACH procedure by using the at least one second RO. An example is now described with reference to FIG. 7B which illustrates a signaling chart of an example of RACH transmissions with a failure due to a collision according to some example embodiments of the present disclosure. The acts 702-718 of FIG. 7B are the same as those in FIG. 7A and description thereof is omitted herein.

[0153] The signaling chart 700B is now going to 734. In this example, the UE 410 does not receive, from the NW 420, the DCI 0_0 for retransmission of Msg3. For example, the NW 420 may fail to decode the Msg3 due to two or more UEs sending the same information on Msg3 which leads to a collision between different UEs.

[0154] In one example, the UE 410 does not receive RRC setup message (Msg4) from the NW 420 before a contention resolution timer is expired (734) . The Msg4 may include PDSCH with contention resolution identity.

[0155] In another example, the UE 410 may receive Msg4 with a wrong contention resolution identity of another UE accessing the NW. In other words, the UE 410 does not receive the correct contention resolution identity.

[0156] In this case, the UE 410 may determine (736) to fallback to additional ROs for the re-attempt of the initial random access. The UE 410 may transmit to the NW 420 a PRACH preamble on the additional RO. For example, the UE 410 may re-apply RA steps (Msg1, Msg2, Msg3 and Msg4) and initial access may be achieved.

[0157] Reference is now made to FIG. 8 to illustrate example overall operations at the UE, which is an example of the terminal device 110.

[0158] FIG. 8 illustrates a flow chart of a procedure of a terminal device according to some example embodiments of the present disclosure. At 810, the UE may receive a RACH configuration indicating a first set of ROs in UL resources and a second set of ROs in SBFD resources, that is the UL ROs and SBFD ROs. At 820, the UE may select a RO in UL resources. In some examples, the UE may select the RO based on an indication from the network device. The set may comprise one or more ROs.

[0159] At 830, the UE may determine whether the RACH failure is related to Msg1 transmission. If the RACH failure is not related to Msg1 transmission, the flow chart proceeds to 840. At 840, the UE may determine whether the RACH failure is related to Msg4 transmission. If the RACH failure is not related to Msg4 transmission, the UE may determine that the RACH transmission is completed.

[0160] If the RACH failure is related to Msg1 transmission, the flow chart proceeds to 860. At 860, the UE may determine that whether a long PRACH format is configured for second set of ROs. If the long PRACH format is not configured for second set of ROs, the flow chart proceeds to 895. At 895, the UE may initiate a new RA procedure. If the long PRACH format is configured for second set of ROs, the flow chart proceeds to 890. At 890, the UE may re-attempt the random access on the second set of ROs.

[0161] Reference is made back to 840. If at 840 it is determined that the RACH failure is related to Msg4 transmission, the flow chart proceeds to 870. At 870, the UE may determine whether a long PRACH format is configured for second set of ROs. If the long PRACH format is configured for second set of ROs, the flow chart proceeds to 890. At 890, the UE may re-attempt the random access on the second set of ROs.

[0162] If the long PRACH format is not configured for second set of ROs, the flow chart proceeds to 880. At 880, the UE may determine whether the UE receive DCI for Msg3 retransmission. If the UE receives DCI for Msg3 retransmission, the flow chart proceeds to 895. At 895, the UE may initiate a new RA procedure. If the UE does not receive DCI for Msg3 retransmission, the flow chart proceeds to 890.

[0163] In the present disclosure, examples are described mainly with reference to the 4-step RACH procedure for illustration purpose and simplicity. However, it should be noted that the proposed solution is equally applicable to the 2-step RACH, CFRA or other random access procedure as well.

[0164] FIG. 9A shows a flowchart of an example method 900A implemented at a terminal device in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 900A will be described from the perspective of the terminal device 110 in FIG. 1.

[0165] At block 910, the terminal device 110 determines at least one first random access channel, RACH, occasion and at least one second RACH occasion based on configuration information from a network device, the at least one first RACH occasion comprising uplink resources in a time period comprising uplink resources only, and the at least one second RACH occasion comprising uplink resources in a time period comprising uplink resources and downlink resources.

[0166] At block 920, the terminal device 110 initiates a RACH procedure by using the at least one first RACH occasion.

[0167] At block 930, responsive to a failure in the RACH procedure, the terminal device 110 determines whether to re-attempt the RACH procedure using the at least one second RACH occasion based on at least one condition.

[0168] In some example embodiments, the at least one condition comprises at least one of: whether the failure in the RACH procedure is related to a random access request; whether the failure in the RACH procedure is related to a data carrying message; whether the failure in the RACH procedure is related to a contention resolution message; whether a second preamble transmission duration associated with the at least one second RACH occasion is greater than a first preamble transmission duration associated with the at least one first RACH occasion.

[0169] In some example embodiments, the method 900A further comprises: determining whether the failure is caused by collision of the terminal device with at least one other terminal device based on one or more messages in the RACH procedure that are related to the failure; and in accordance with a determination that the failure is caused by the collision, determining to re-attempt the RACH procedure by using the at least one second RACH occasion.

[0170] In some example embodiments, the method 900A further comprises: determining that the failure is caused by the collision based on at least one of. : the terminal device does not receive downlink control information for scheduling retransmission of a data carrying message; the terminal device does not receive a content resolution message with an identity of the terminal device; or that the terminal device receives a content resolution message with an identity of a further or another terminal device.

[0171] In some example embodiments, the method 900A further comprises: determining whether the failure is caused by a coverage state of the terminal device based on one or more messages in the RACH procedure that are related to the failure; and in accordance with a determination that the failure is caused by the coverage state of the terminal device, determining whether to re-attempt the RACH procedure using the at least one second RACH occasion based on whether a second preamble transmission duration associated with the at least one second RACH occasion is greater than a first preamble transmission duration associated with the at least one first RACH occasion.

[0172] In some example embodiments, the method 900A further comprises: in accordance with a determination that the second preamble transmission duration is greater than the first preamble transmission duration, determining to re-attempt the RACH procedure by using the at least one second RACH occasion; and in accordance with a determination that the second preamble transmission duration is not greater than the first preamble transmission duration, determining not to re-attempt the RACH procedure by using the at least one second RACH occasion.

[0173] In some example embodiments, the method 900A further comprises: determining that the failure is caused by the coverage state based on at least one of. : the terminal device does not receive, from the network device, a random access response to a random access request; or the terminal device receives downlink control information for scheduling retransmission of a data carrying message and does not receive a content resolution message with an identity of the terminal device.

[0174] In some example embodiments, the method 900A further comprises: determining whether a second preamble transmission duration associated with the at least one second RACH occasion is greater than a first preamble transmission duration associated with the at least one first RACH occasion; and in accordance with a determination that the second preamble transmission duration is greater than the first preamble transmission duration, determining to re-attempt the RACH procedure by using the at least one second RACH occasion.

[0175] In some example embodiments, the method 900A further comprises: in accordance with a determination that the failure is related to a random access request transmitted to the network device, determining whether a second preamble transmission duration associated with the at least one second RACH occasion is greater than a first preamble transmission duration associated with the at least one first RACH occasion; in accordance with a determination that the second preamble transmission duration is greater than the first preamble transmission duration, determining to re-attempt the RACH procedure by using the at least one second RACH occasion; and in accordance with a determination that the second preamble transmission duration is not greater than the first preamble transmission duration, determining not to re-attempt the RACH procedure by using the at least one second RACH occasion.

[0176] In some example embodiments, the method 900A further comprises: in accordance with a determination that the failure is related to a contention resolution message from the network device, determining whether downlink control information for scheduling retransmission of a data carrying message is received by the terminal device; and in accordance with a determination that the downlink control information is not received, determining to re-attempt the RACH procedure by using the at least one second RACH occasion.

[0177] In some example embodiments, the method 900A further comprises: in accordance with a determination that the downlink control information is received, determining whether a second preamble transmission duration associated with the at least one second RACH occasion is greater than a first preamble transmission duration associated with the at least one first RACH occasion; in accordance with a determination that the second preamble transmission duration is greater than the first preamble transmission duration, determining to re-attempt the RACH procedure by using the at least one second RACH occasion; and in accordance with a determination that the second preamble transmission duration is not greater than the first preamble transmission duration, determining not to re-attempt the RACH procedure by using the at least one second RACH occasion.

[0178] In some example embodiments, the method 900A further comprises: receiving, from the network device, an indication to use the at least one first RACH occasion for random access to the network device, wherein the RACH procedure is performed by using the first RACH occasion based on the indication.

[0179] In some example embodiments, the method 900A further comprises: receiving configuration information indicating the at least one first RACH occasion and the at least one second RACH occasion.

[0180] FIG. 9B shows a flowchart of an example method 900B implemented at a network device in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 900B will be described from the perspective of the network device 120 in FIG. 1.

[0181] At block 960, the network device 120 transmits, to a terminal device, configuration information for a random access channel, RACH, uplink resources and downlink resources, the configuration information indicating at least one first RACH occasion and at least one second RACH occasion, the at least one first RACH occasion comprising uplink resources in a time period comprising uplink resources only, and the at least one second RACH occasion comprising uplink resources in a time period comprising uplink resources and downlink resources.

[0182] At block 970, the network device 120 transmits, to the terminal device, information about at least one condition, wherein the at least one condition is for use by the terminal device in determining whether to re-attempt the RACH procedure using the at least one second RACH occasion responsive to a failure in a RACH procedure initiated by using the at least one first RACH occasion.

[0183] In some example embodiments, the at least one condition comprises at least one of: whether the failure in the RACH procedure is related to a random access request; whether the failure in the RACH procedure is related to a data carrying message; whether the failure in the RACH procedure is related to a contention resolution message; whether a second preamble transmission duration associated with the at least one second RACH occasion is greater than a first preamble transmission duration associated with the at least one first RACH occasion.

[0184] In some example embodiments, the method 900B further comprises: transmitting, to the terminal device, an indication to use the at least one first RACH occasion for random access to the network device.

[0185] In some example embodiments, a first apparatus capable of performing any of the method 900A (for example, the terminal device 110 in FIG. 1) may comprise means for performing the respective operations of the method 900A and any of the embodiments thereof. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The apparatus may be implemented as or included in the terminal device 110 in FIG. 1.

[0186] In some example embodiments, a second apparatus capable of performing any of the method 900B (for example, the network device 120 in FIG. 1) may comprise means for performing the respective operations of the method 900B and any of the embodiments thereof. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The second apparatus may be implemented as or included in the network device 120 in FIG. 1.

[0187] FIG. 10 is a simplified block diagram of a device 1000 that is suitable for implementing example embodiments of the present disclosure. The device 1000 may be provided to implement a communication device, for example, the terminal device 110 or the network device 120 as shown in FIG. 1. As shown, the device 1000 includes one or more processors 1010, one or more memories 1020 coupled to the processor 1010, and one or more communication modules 1040 coupled to the processor 1010.

[0188] The communication module 1040 is for bidirectional communications. The communication module 1040 has one or more communication interfaces to facilitate communication with one or more other modules or devices. The communication interfaces may represent any interface that is necessary for communication with other network elements. In some example embodiments, the communication module 1040 may include at least one antenna.

[0189] The processor 1010 may be of any type suitable to the local technical network and may include one or more of the following: general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples. The device 1000 may have multiple processors, such as an application specific integrated circuit chip that is slaved in time to a clock which synchronizes the main processor.

[0190] The memory 1020 may include one or more non-volatile memories and one or more volatile memories. Examples of the non-volatile memories include, but are not limited to, a Read Only Memory (ROM) 1024, an electrically programmable read only memory (EPROM) , a flash memory, a hard disk, a compact disc (CD) , a digital video disk (DVD) , an optical disk, a laser disk, and other magnetic storage and / or optical storage. Examples of the volatile memories include, but are not limited to, a random-access memory (RAM) 1022 and other volatile memories that will not last in the power-down duration.

[0191] A computer program 1030 includes computer executable instructions that are executed by the associated processor 1010. The instructions of the program 1030 may include instructions for performing operations / acts of some example embodiments of the present disclosure. The program 1030 may be stored in the memory, e.g., the ROM 1024. The processor 1010 may perform any suitable actions and processing by loading the program 1030 into the RAM 1022.

[0192] The example embodiments of the present disclosure may be implemented by means of the program 1030 so that the device 1000 may perform any process of the disclosure as discussed with reference to FIG. 3 to FIG. 9. The example embodiments of the present disclosure may also be implemented by hardware or by a combination of software and hardware.

[0193] In some example embodiments, the program 1030 may be tangibly contained in a computer readable medium which may be included in the device 1000 (such as in the memory 1020) or other storage devices that are accessible by the device 1000. The device 1000 may load the program 1030 from the computer readable medium to the RAM 1022 for execution. In some example embodiments, the computer readable medium may include any types of non-transitory storage medium, such as ROM, EPROM, a flash memory, a hard disk, CD, DVD, and the like. The term “non-transitory, ” as used herein, is a limitation of the medium itself (i.e., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM) .

[0194] FIG. 11 shows an example of the computer readable medium 1100 which may be in form of CD, DVD or other optical storage disk. The computer readable medium 1100 has the program 1030 stored thereon.

[0195] Generally, various embodiments of the present disclosure may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, and other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. Although various aspects of embodiments of the present disclosure are illustrated and described as block diagrams, flowcharts, or using some other pictorial representations, it is to be understood that the block, apparatus, system, technique or method described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

[0196] Some example embodiments of the present disclosure also provide at least one computer program product tangibly stored on a computer readable medium, such as a non-transitory computer readable medium. The computer program product includes computer-executable instructions, such as those included in program modules, being executed in a device on a target physical or virtual processor, to carry out any of the methods as described above. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, or the like that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Machine-executable instructions for program modules may be executed within a local or distributed device. In a distributed device, program modules may be located in both local and remote storage media.

[0197] Program code for carrying out methods of the present disclosure may be written in any combination of one or more programming languages. The program code may be provided to a processor or controller of a general-purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program code, when executed by the processor or controller, cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

[0198] In the context of the present disclosure, the computer program code or related data may be carried by any suitable carrier to enable the device, apparatus or processor to perform various processes and operations as described above. Examples of the carrier include a signal, computer readable medium, and the like.

[0199] The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable medium may include but not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the computer readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random-access memory (RAM) , a read-only memory (ROM) , an erasable programmable read-only memory (EPROM or Flash memory) , an optical fiber, a portable compact disc read-only memory (CD-ROM) , an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0200] Further, although operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, although several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Unless explicitly stated, certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, unless explicitly stated, various features that are described in the context of a single embodiment may also be implemented in a plurality of embodiments separately or in any suitable sub-combination.

[0201] Although the present disclosure has been described in languages specific to structural features and / or methodological acts, it is to be understood that the present disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1.A terminal device comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the terminal device at least to:determine at least one first random access channel, RACH, occasion and at least one second RACH occasion based on configuration information from a network device, the at least one first RACH occasion comprising uplink resources in a time period comprising uplink resources only, and the at least one second RACH occasion comprising uplink resources in a time period comprising uplink resources and downlink resources;initiate a RACH procedure by using the at least one first RACH occasion; andresponsive to a failure in the RACH procedure, determine whether to re-attempt the RACH procedure using the at least one second RACH occasion based on at least one condition.2.The terminal device of claim 1, wherein the at least one condition comprises at least one of:whether the failure in the RACH procedure is related to a random access request;whether the failure in the RACH procedure is related to a data carrying message;whether the failure in the RACH procedure is related to a contention resolution message; orwhether a second preamble transmission duration associated with the at least one second RACH occasion is greater than a first preamble transmission duration associated with the at least one first RACH occasion.3.The terminal device of claim 1 or 2, wherein the terminal device is caused to:determine whether the failure is caused by collision of the terminal device with at least one other terminal device based on one or more messages in the RACH procedure that are related to the failure; andin accordance with a determination that the failure is caused by the collision, determine to re-attempt the RACH procedure by using the at least one second RACH occasion.4.The terminal device of claim 3, wherein the terminal device is caused to:determine that the failure is caused by the collision based on at least one of:the terminal device does not receive downlink control information for scheduling retransmission of a data carrying message,the terminal device does not receive a content resolution message with an identity of the terminal device, orthe terminal device receives a content resolution message with an identity of a further terminal device.5.The terminal device of claim 1 or 2, wherein the terminal device is caused to:determine whether the failure is caused by a coverage state of the terminal device based on one or more messages in the RACH procedure that are related to the failure; andin accordance with a determination that the failure is caused by the coverage state of the terminal device, determine whether to re-attempt the RACH procedure using the at least one second RACH occasion based on whether a second preamble transmission duration associated with the at least one second RACH occasion is greater than a first preamble transmission duration associated with the at least one first RACH occasion.6.The terminal device of claim 5, wherein the terminal device is caused to:in accordance with a determination that the second preamble transmission duration is greater than the first preamble transmission duration, determine to re-attempt the RACH procedure by using the at least one second RACH occasion; andin accordance with a determination that the second preamble transmission duration is not greater than the first preamble transmission duration, determine not to re-attempt the RACH procedure by using the at least one second RACH occasion.7.The terminal device of claim 5, wherein the terminal device is caused to:determine that the failure is caused by the coverage state based on at least one of:the terminal device does not receive, from the network device, a random access response to a random access request, orthe terminal device receives downlink control information for scheduling retransmission of a data carrying message and does not receive a content resolution message with an identity of the terminal device.8.The terminal device of claim 1 or 2, wherein the terminal device is caused to:determine whether a second preamble transmission duration associated with the at least one second RACH occasion is greater than a first preamble transmission duration associated with the at least one first RACH occasion; andin accordance with a determination that the second preamble transmission duration is greater than the first preamble transmission duration, determine to re-attempt the RACH procedure by using the at least one second RACH occasion.9.The terminal device of claim 1 or 2, wherein the terminal device is caused to:in accordance with a determination that the failure is related to a random access request transmitted to the network device, determine whether a second preamble transmission duration associated with the at least one second RACH occasion is greater than a first preamble transmission duration associated with the at least one first RACH occasion;in accordance with a determination that the second preamble transmission duration is greater than the first preamble transmission duration, determine to re-attempt the RACH procedure by using the at least one second RACH occasion; andin accordance with a determination that the second preamble transmission duration is not greater than the first preamble transmission duration, determine not to re-attempt the RACH procedure by using the at least one second RACH occasion.10.The terminal device of claim 1 or 2, wherein the terminal device is caused to:in accordance with a determination that the failure is related to a contention resolution message from the network device, determine whether downlink control information for scheduling retransmission of a data carrying message is received by the terminal device; andin accordance with a determination that the downlink control information is not received, determine to re-attempt the RACH procedure by using the at least one second RACH occasion.11.The terminal device of claim 10, wherein the terminal device is caused to:in accordance with a determination that the downlink control information is received, determine whether a second preamble transmission duration associated with the at least one second RACH occasion is greater than a first preamble transmission duration associated with the at least one first RACH occasion;in accordance with a determination that the second preamble transmission duration is greater than the first preamble transmission duration, determine to re-attempt the RACH procedure by using the at least one second RACH occasion; andin accordance with a determination that the second preamble transmission duration is not greater than the first preamble transmission duration, determine not to re-attempt the RACH procedure by using the at least one second RACH occasion.12.The terminal device of any of claims 1 to 11, wherein the terminal device is further caused to:receive, from the network device, an indication to use the at least one first RACH occasion for random access to the network device, wherein the RACH procedure is performed by using the first RACH occasion based on the indication.13.The terminal device of any of claims 1 to 12, wherein the terminal device is further caused to:receive information about the at least one condition from the network device.14.The terminal device of any of claims 1 to 13, wherein the terminal device is further caused to:receive configuration information indicating the at least one first RACH occasion and the at least one second RACH occasion.15.A network device comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the network device at least to:transmit, to a terminal device, configuration information for a random access channel, RACH, uplink resources and downlink resources, the configuration information indicating at least one first RACH occasion and at least one second RACH occasion, the at least one first RACH occasion comprising uplink resources in a time period comprising uplink resources only, and the at least one second RACH occasion comprising uplink resources in a time period comprising uplink resources and downlink resources; andtransmit, to the terminal device, information about at least one condition, wherein the at least one condition is for use by the terminal device in determining whether to re-attempt the RACH procedure using the at least one second RACH occasion responsive to a failure in a RACH procedure initiated by using the at least one first RACH occasion.16.The network device of claim 15, wherein the at least one condition comprises at least one of:whether the failure in the RACH procedure is related to a random access request;whether the failure in the RACH procedure is related to a data carrying message;whether the failure in the RACH procedure is related to a contention resolution message; orwhether a second preamble transmission duration associated with the at least one second RACH occasion is greater than a first preamble transmission duration associated with the at least one first RACH occasion.17.The network device of claim 15 or 16, wherein the network device is further caused to:transmit, to the terminal device, an indication to use the at least one first RACH occasion for random access to the network device.18.A method comprising:determining, by a terminal device, at least one first random access channel, RACH, occasion and at least one second RACH occasion based on configuration information from a network device, the at least one first RACH occasion comprising uplink resources in a time period comprising uplink resources only, and the at least one second RACH occasion comprising uplink resources in a time period comprising uplink resources and downlink resources;initiating, by the terminal device, a RACH procedure by using the at least one first RACH occasion; andresponsive to a failure in the RACH procedure, determining, by the terminal device, whether to re-attempt the RACH procedure using the at least one second RACH occasion based on at least one condition.19.A method comprising:transmitting, by a network device to a terminal device, configuration information for a random access channel, RACH, uplink resources and downlink resources, the configuration information indicating at least one first RACH occasion and at least one second RACH occasion, the at least one first RACH occasion comprising uplink resources in a time period comprising uplink resources only, and the at least one second RACH occasion comprising uplink resources in a time period comprising uplink resources and downlink resources; andtransmitting, by the network device to the terminal device, information about at least one condition, wherein the at least one condition is for use by the terminal device in determining whether to re-attempt the RACH procedure using the at least one second RACH occasion responsive to a failure in a RACH procedure initiated by using the at least one first RACH occasion.20.A first apparatus comprising:means for determining at least one first random access channel, RACH, occasion and at least one second RACH occasion based on configuration information from a network device, the at least one first RACH occasion comprising uplink resources in a time period comprising uplink resources only, and the at least one second RACH occasion comprising uplink resources in a time period comprising uplink resources and downlink resources;means for initiating a RACH procedure by using the at least one first RACH occasion; andmeans for responsive to a failure in the RACH procedure, determine whether to re-attempt the RACH procedure using the at least one second RACH occasion based on at least one condition.21.A second apparatus comprising:means for transmitting, to a terminal device, configuration information for a random access channel, RACH, uplink resources and downlink resources, the configuration information indicating at least one first RACH occasion and at least one second RACH occasion, the at least one first RACH occasion comprising uplink resources in a time period comprising uplink resources only, and the at least one second RACH occasion comprising uplink resources in a time period comprising uplink resources and downlink resources; andmeans for transmitting, to the terminal device, information about at least one condition, wherein the at least one condition is for use by the terminal device in determining whether to re-attempt the RACH procedure using the at least one second RACH occasion responsive to a failure in a RACH procedure initiated by using the at least one first RACH occasion.22.A computer readable medium comprising instructions stored thereon for causing an apparatus at least to perform the method of claim 18 or the method of claim 19.

Images