Method, terminal device and base station for random access process

Abstract

A method, a terminal device and a base station for a random access procedure are disclosed. According to one embodiment, the terminal device determines a request message for random access. The request message includes a preamble and one or more physical uplink shared channels (PUSCHs). The terminal device sends the request message.

Description

Technical Field

[0001] Embodiments of the present disclosure generally relate to wireless communications, and more particularly to methods, terminal devices, and base stations for random access procedures. Background Art

[0002] This section introduces aspects that may facilitate a better understanding of the present disclosure. Therefore, the statements in this section should be read in this sense, and should not be understood as an admission of what is or is not prior art.

[0003] In New Radio (NR) systems, such as Figure 1 The four-step method shown can be used for the random access procedure. In this method, the user equipment (UE) detects the synchronization signal (SS), decodes the broadcast system information (which can be distributed on multiple physical channels such as the physical broadcast channel (PBCH) and the physical downlink shared channel (PDSCH)) to obtain the random access transmission parameters, and then sends the physical random access channel (PRACH) preamble on the uplink (message 1). The next generation Node B (gNB) detects message 1 and responds with a random access response (RAR, message 2). The UE then sends the UE identity on the physical uplink shared channel (PUSCH) (message 3). The gNB then sends a contention resolution message (CRM, message 4) to the UE to resolve the conflict caused when multiple UEs send the same PRACH preamble. Summary of the invention

[0004] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0005] One of the objectives of the present disclosure is to provide another solution for the random access procedure.

[0006] According to a first aspect of the present disclosure, a method implemented at a terminal device is provided. The method may include determining a request message for random access. The request message may include a preamble and one or more PUSCHs. The method may also include sending the request message.

[0007] In an embodiment of the present disclosure, a fixed modulation and coding scheme (MCS) table may be preconfigured for determining the request message.

[0008] In an embodiment of the present disclosure, PI / 2 Binary Phase Shift Keying (BPSK) may be preconfigured to be disabled in the terminal device.

[0009] In an embodiment of the present disclosure, the number of the one or more PUSCHs may be more than one, and the more than one PUSCHs may be multiple repetitions of a PUSCH.

[0010] In an embodiment of the present disclosure, the multiple repetitions of the PUSCH may be divided into one or more PUSCH transmission sets.

[0011] In an embodiment of the present disclosure, the random access may be initiated due to failure of a previous random access. The number of the multiple repetitions of the PUSCH used for the access may be no less than the number of the multiple repetitions of the PUSCH used for the previous random access.

[0012] In an embodiment of the present disclosure, each repetition of the PUSCH may be associated with the preamble.

[0013] In an embodiment of the present disclosure, the number of the multiple repetitions of the PUSCH may come from at least one of: radio resource control (RRC) signaling; pre-configuration in the terminal device; and determination based on at least one of the following: preamble code information, demodulation reference signal (DMRS) information, usage information, and frequency band information.

[0014] In an embodiment of the present disclosure, the preamble and the respective repetitions of the PUSCH may be time division multiplexed and / or frequency division multiplexed.

[0015] In an embodiment of the present disclosure, each repetition of the PUSCH may use a corresponding redundancy version (RV) in a RV sequence.

[0016] In an embodiment of the present disclosure, the RV sequence may come from at least one of the following: RRC signaling, and pre-configuration in the terminal device.

[0017] In an embodiment of the present disclosure, the number of repetitions of the PUSCH in each PUSCH transmission set used for the random access may be no less than the number of repetitions of the PUSCH in each PUSCH transmission set used for the previous random access. Alternatively or additionally, the number of the one or more PUSCH transmission sets used for the random access may be no less than the number of the one or more PUSCH transmission sets used for the previous random access.

[0018] In an embodiment of the present disclosure, the request message may be determined such that a size of a transport block (TB) carried in a PUSCH is scaled by a scaling factor relative to a reference size of the TB carried in the PUSCH.

[0019] In an embodiment of the present disclosure, the reference size of the TB may be determined based on a first product of the number of resource elements (REs) available for carrying the TB, a modulation order for the TB, and a target code rate. The size of the TB may be determined based on a second product of the scaling factor and the first product.

[0020] In an embodiment of the present disclosure, the scaling factor may come from at least one of: RRC signaling; pre-configuration in the terminal device; selection from a set of preconfigured values ​​based on channel quality estimation; and determination based on at least one of the following: preamble information, DMRS information, usage information, and frequency band information.

[0021] In an embodiment of the present disclosure, the request message may be determined based on an MCS table, the MCS table having a lower spectrum efficiency than a reference MCS table.

[0022] In an embodiment of the present disclosure, the MCS table may be a table obtained by adding one or more rows having lower spectrum efficiency to the reference MCS table.

[0023] In an embodiment of the present disclosure, the MCS table may be obtained by removing one or more rows having higher spectrum efficiency from the reference MCS table.

[0024] In an embodiment of the present disclosure, the reference MCS table may be a Quadrature Amplitude Modulation (QAM) 64 Low Spectral Efficiency (QAM64LowSE) MCS table with a transform precoder enabled, or a QAM64LowSE MCS table with a transform precoder disabled.

[0025] In an embodiment of the present disclosure, the MCS table may be a table defined instead of the reference MCS table, or a table defined separately from the reference MCS table.

[0026] In an embodiment of the present disclosure, which MCS table will be used to determine the request message may be indicated via RRC signaling. Alternatively, which MCS table will be used to determine the request message may be determined based on at least one of the following: preamble information, DMRS information, usage information, and frequency band information.

[0027] In an embodiment of the present disclosure, whether PI / 2BPSK is to be enabled for determining the request message may be indicated via RRC signaling. Alternatively, PI / 2BPSK may be preconfigured to be enabled in the terminal device.

[0028] In an embodiment of the present disclosure, the method may further include providing user data and forwarding the user data to the host via a transmission to the base station.

[0029] According to a second aspect of the present disclosure, a method implemented in a communication system including a host, a base station and a terminal device is provided. The method may include: receiving, at the host, user data sent from the terminal device to the base station. The terminal device may determine a request message for random access. The request message may include a preamble and one or more PUSCHs. The terminal device may send the request message.

[0030] In an embodiment of the present disclosure, the method may further include: providing the user data to the base station at the terminal device.

[0031] In an embodiment of the present disclosure, the method may further include: executing a client application at the terminal device to provide user data to be sent. The method may further include: executing a host application associated with the client application at the host.

[0032] In an embodiment of the present disclosure, the method may further include: executing a client application at the terminal device. The method may further include: receiving input data to the client application at the terminal device. The input data may be provided at the host by executing a host application associated with the client application. The user data to be sent may be provided by the client application in response to the input data.

[0033] According to a third aspect of the present disclosure, a method implemented at a base station is provided. The method may include receiving a request message for random access. The request message may include a preamble and one or more PUSCHs. The method may also include obtaining the one or more PUSCHs from the request message.

[0034] In an embodiment of the present disclosure, a fixed MCS table may be preconfigured for obtaining the one or more PUSCHs in the base station.

[0035] In an embodiment of the present disclosure, PI / 2BPSK may be preconfigured to be disabled in the base station for the request message.

[0036] In an embodiment of the present disclosure, the number of the one or more PUSCHs may be more than one, and the more than one PUSCHs may be multiple repetitions of a PUSCH.

[0037] In an embodiment of the present disclosure, the multiple repetitions of the PUSCH may be divided into one or more PUSCH transmission sets.

[0038] In an embodiment of the present disclosure, the random access may be initiated due to failure of a previous random access. The number of the multiple repetitions of the PUSCH used for the random access may be not less than the number of the multiple repetitions of the PUSCH used for the previous random access.

[0039] In an embodiment of the present disclosure, each repetition of the PUSCH may be associated with the preamble.

[0040] In an embodiment of the present disclosure, the number of the multiple repetitions of the PUSCH may be one of: sent in RRC signaling; preconfigured in the base station; and determined based on at least one of: preamble code information, DMRS information, usage information, and frequency band information.

[0041] In an embodiment of the present disclosure, the preamble and the respective repetitions of the PUSCH may be time division multiplexed and / or frequency division multiplexed.

[0042] In an embodiment of the present disclosure, each repetition of the PUSCH may use a corresponding RV in an RV sequence.

[0043] In an embodiment of the present disclosure, the RV sequence may be sent in RRC signaling, or preconfigured in the base station.

[0044] In an embodiment of the present disclosure, the number of repetitions of the PUSCH in each PUSCH transmission set used for the random access may be no less than the number of repetitions of the PUSCH in each PUSCH transmission set used for the previous random access. Alternatively or additionally, the number of the one or more PUSCH transmission sets used for the random access may be no less than the number of the one or more PUSCH transmission sets used for the previous random access.

[0045] In an embodiment of the present disclosure, the size of a TB carried in a PUSCH may be scaled by a scaling factor relative to a reference size of the TB carried in the PUSCH.

[0046] In an embodiment of the present disclosure, the reference size of the TB may be determined based on a first product of: the number of REs available for carrying the TB, a modulation order for the TB, and a target code rate. The size of the TB may be determined based on a second product of the scaling factor and the first product.

[0047] In an embodiment of the present disclosure, the scaling factor may be one of: sent in RRC signaling; preconfigured in the base station; blindly detected from a preconfigured set of values; and determined based on at least one of: preamble code information, DMRS information, usage information, and frequency band information.

[0048] In an embodiment of the present disclosure, the one or more PUSCHs may be obtained based on an MCS table, the MCS table having a lower spectral efficiency than a reference MCS table.

[0049] In an embodiment of the present disclosure, the MCS table may be a table obtained by adding one or more rows having lower spectrum efficiency to the reference MCS table.

[0050] In an embodiment of the present disclosure, the MCS table may be obtained by removing one or more rows having higher spectrum efficiency from the reference MCS table.

[0051] In an embodiment of the present disclosure, the reference MCS table may be a QAM64LowSE MCS table with a transform precoder enabled, or a QAM64LowSE MCS table with a transform precoder disabled.

[0052] In an embodiment of the present disclosure, the MCS table may be a table defined instead of the reference MCS table, or a table defined separately from the reference MCS table.

[0053] In an embodiment of the present disclosure, which MCS table will be used to obtain the one or more PUSCHs may be sent in RRC signaling. Alternatively, which MCS table will be used to obtain the one or more PUSCHs may be determined based on at least one of the following: preamble information, DMRS information, usage information, and frequency band information.

[0054] In an embodiment of the present disclosure, whether PI / 2BPSK is to be enabled for the request message may be sent in RRC signaling. Alternatively, PI / 2BPSK may be preconfigured to be enabled in the base station for the request message.

[0055] According to a fourth aspect of the present disclosure, a method implemented in a communication system including a host, a base station and a terminal device is provided. The method may include: receiving, at the host, from the base station, user data originating from a transmission that the base station has received from the terminal device. The base station may receive a request message for random access. The request message may include a preamble and one or more PUSCHs. The base station may obtain the one or more PUSCHs from the request message.

[0056] In an embodiment of the present disclosure, the method may further include: receiving the user data from the terminal device at the base station.

[0057] In an embodiment of the present disclosure, the method may further include: initiating, at the base station, transmission of the received user data to the host.

[0058] According to a fifth aspect of the present disclosure, a terminal device is provided. The terminal device may include at least one processor and at least one memory. The at least one memory may contain instructions executable by the at least one processor, whereby the terminal device may be operable to determine a request message for random access. The request message may include a preamble and one or more PUSCHs. The terminal device may also be operable to send the request message.

[0059] In an embodiment of the present disclosure, the terminal device may be operable to execute the method according to the first aspect above.

[0060] According to a sixth aspect of the present disclosure, a communication system including a host is provided. The host may include a communication interface configured to receive user data originating from a transmission from a terminal device to a base station. The terminal device may include a radio interface and a processing circuit. The processing circuit of the terminal device may be configured to determine a request message for random access. The request message may include a preamble and one or more PUSCHs. The processing circuit of the terminal device may also be configured to send the request message.

[0061] In an embodiment of the present disclosure, the communication system may further include the terminal device.

[0062] In an embodiment of the present disclosure, the communication system may further include the base station. The base station may include a radio interface configured to communicate with the terminal device, and a communication interface configured to forward user data carried by the transmission from the terminal device to the base station to the host.

[0063] In an embodiment of the present disclosure, the processing circuit of the host may be configured to execute a host application. The processing circuit of the terminal device may be configured to execute a client application associated with the host application, thereby providing the user data.

[0064] In an embodiment of the present disclosure, the processing circuit of the host may be configured to execute a host application to provide the request data. The processing circuit of the terminal device may be configured to execute a client application associated with the host application to provide the user data in response to the request data.

[0065] According to a seventh aspect of the present disclosure, a base station is provided. The base station may include at least one processor and at least one memory. The at least one memory may contain instructions executable by the at least one processor, whereby the base station may be operable to receive a request message for random access. The request message may include a preamble and one or more PUSCHs. The base station may also be operable to obtain the one or more PUSCHs from the request message.

[0066] In an embodiment of the present disclosure, the base station may be operable to execute the method according to the third aspect above.

[0067] According to an eighth aspect of the present disclosure, a communication system including a host is provided. The host may include a communication interface configured to receive user data originating from a transmission from a terminal device to a base station. The base station may include a radio interface and a processing circuit. The processing circuit of the base station may be configured to receive a request message for random access. The request message may include a preamble and one or more PUSCHs. The processing circuit of the base station may also be configured to obtain the one or more PUSCHs from the request message.

[0068] In an embodiment of the present disclosure, the communication system may further include the base station.

[0069] In an embodiment of the present disclosure, the communication system may further include the terminal device. The terminal device may be configured to communicate with the base station.

[0070] In an embodiment of the present disclosure, the processing circuit of the host may be configured to execute a host application. The terminal device may be configured to execute a client application associated with the host application, thereby providing the user data to be received by the host.

[0071] According to a ninth aspect of the present disclosure, a computer program product is provided. The computer program product may include instructions, which, when executed by at least one processor, cause the at least one processor to perform the method according to any one of the first and third aspects.

[0072] According to a tenth aspect of the present disclosure, a computer-readable storage medium is provided. The computer-readable storage medium may contain instructions, which, when executed by at least one processor, cause the at least one processor to perform the method according to any one of the first and third aspects.

[0073] According to an eleventh aspect of the present disclosure, a terminal device is provided. The terminal device may include a determination module, configured to determine a request message for random access. The request message may include a preamble and one or more PUSCHs. The terminal device may also include a sending module, configured to send the request message.

[0074] According to the twelfth aspect of the present disclosure, a base station is provided. The base station may include a receiving module for receiving a request message for random access. The request message may include a preamble and one or more PUSCHs. The base station may also include an obtaining module for obtaining the one or more PUSCHs from the request message.

[0075] According to the thirteenth aspect of the present disclosure, a method implemented in a communication system including a base station and at least one terminal device is provided. The method may include: at the at least one terminal device, determining a request message for random access. The request message may include a preamble and one or more PUSCHs. The method may also include: at the at least one terminal device, sending the request message. The method may also include: at the base station, receiving the request message for random access. The request message may include the preamble and the one or more PUSCHs. The method may also include: at the base station, obtaining the one or more PUSCHs from the request message.

[0076] According to a fourteenth aspect of the present disclosure, a communication system including at least one terminal device and a base station is provided. The at least one terminal device may be configured to: determine a request message for random access and send the request message. The request message may include a preamble and one or more PUSCHs. The base station may be configured to receive the request message for random access and obtain the one or more PUSCHs from the request message. The request message may include the preamble and the one or more PUSCHs. BRIEF DESCRIPTION OF THE DRAWINGS

[0077] These and other objects, features and advantages of the present disclosure will become apparent from the following detailed description of illustrative embodiments of the present disclosure, which is to be read in connection with the accompanying drawings.

[0078] Figure 1 is a diagram illustrating a four-step random access procedure in NR;

[0079] Figure 2 is a diagram illustrating a two-step random access procedure in NR;

[0080] Figure 3 is a diagram showing a second embodiment of the present disclosure;

[0081] Figure 4 is a diagram showing a third embodiment of the present disclosure;

[0082] Figure 5-6 is a diagram for explaining the second and third embodiments;

[0083] Figure 7 is a flowchart illustrating a method implemented at a terminal device according to an embodiment of the present disclosure;

[0084] Figure 8 is a flow chart showing a method implemented at a base station according to an embodiment of the present disclosure;

[0085] Fig. 9 is a block diagram illustrating an apparatus suitable for use in practicing some embodiments of the present disclosure;

[0086] Fig.10 is a block diagram showing a terminal device according to an embodiment of the present disclosure;

[0087] Fig.11 is a block diagram illustrating a base station according to an embodiment of the present disclosure;

[0088] Fig.12 is a diagram illustrating a telecommunications network connected to a host via an intermediate network according to some embodiments;

[0089] Fig.13 is a diagram illustrating a host communicating with a user equipment via a base station according to some embodiments;

[0090] Fig.14 is a flow chart illustrating a method implemented in a communication system according to some embodiments;

[0091] Fig.15 is a flow chart illustrating a method implemented in a communication system according to some embodiments;

[0092] Fig.16 is a flow chart illustrating a method implemented in a communication system according to some embodiments; and

[0093] Fig.17 is a flow chart illustrating a method implemented in a communication system according to some embodiments. DETAILED DESCRIPTION

[0094] For purposes of explanation, certain details are set forth in the following description in order to provide a thorough understanding of the disclosed embodiments. However, it is apparent to one skilled in the art that the embodiments may be practiced without these specific details or with an equivalent configuration.

[0095] In the four-step random access procedure, the UE sends a PUSCH (message 3) after receiving the timing advance command in the RAR and after adjusting the timing of the PUSCH transmission, allowing the PUSCH to be received at the gNB with a timing accuracy within the cyclic prefix (CP). Without this timing advance functionality, a very large CP would be required to be able to demodulate and detect the PUSCH unless the system is applied in a cell with a very small distance between the UE and the gNB. Since NR will also support larger cells, there is a need to provide timing advance to the UE and therefore the random access procedure requires a four-step approach.

[0096] The random access response carried in message 2 includes 4 bits for time domain resource allocation and 4 bits identifying the MCS to be used in message 3. The time domain resource allocation bits are used with Table 6.1.2.1.1-2 or Table 6.1.2.1.1-3 in the 3rd Generation Partnership Project (3GPP) Technical Specification (TS) 38.214 V15.4.0 to identify which PUSCH mapping type (A or B) to use, which time slot carries the PUSCH (identified via parameter K2), the starting symbol S relative to the beginning of the time slot, and the length L of the PUSCH transmission expressed in units of orthogonal frequency division multiplexing (OFDM) symbols. The 4 bits identifying the MCS determine the parameter I given by the lowest 16 entries of the MCS table for PUSCH. MCS (MCS index) and Q m (modulation order), as described below.

[0097] To determine the transport block size for the PUSCH carrying message 3, the UE uses To determine the number of resource elements (REs) (N') allocated for PUSCH in a physical resource block (PRB) RE ), as described in Section 6.1.4.2 of 3GPP TS 38.214 V15.4.0. The intermediate number of PUSCH information bits (N info ) through N info =N RE ·R·Q m ·υ is obtained as described in step 2) of section 5.1.3.2 of 3GPP TS 38.214 V15.4.0. As defined in section 3.2 of 3GPP TS 38.211, the parameter υ is the number of layers used for transmission of the TB. Then, depending on whether N info ≤3824, the actual transport block size used is given by step 3) or step 4) of section 5.1.3.2 of 3GPP TS 38.214 V15.4.0.

[0098] In TS 38.214 V15.4.0, two MCS tables with the highest modulation order of 64-QAM are defined for PDSCH transmission, see Table 5.1.3.1-1 and Table 5.1.3.1-3 from TS 38.214 V15.4.0. Table 5.1.3.1-1 is the "qam64" MCS table for OFDM, while Table 5.1.3.1-3 is the "qam64LowSE" table for OFDM. These tables are also used for PUSCH when transform precoding is disabled. For Message 3 (Msg3) PUSCH transmission, the UE shall consider transform precoding as "enabled" or "disabled" depending on the parameter msg3-transformPrecoder configured by higher layers.

[0099] In TS 38.214 V15.4.0, two MCS tables with the highest modulation order of 64-QAM are defined for PUSCH transmission with transform precoding, see Table 6.1.4.1-1 and Table 6.1.4.1-2 from TS 38.214 V15.4.0. Table 6.1.4.1-1 is a "qam64" MCS table for discrete Fourier transform (DFT)-spread-OFDM (DFT-s-OFDM), and Table 6.1.4.1-2 is a "qam64LowSE" MCS table for DFT-s-OFDM. For Table 6.1.4.1-1 and Table 6.1.4.1-2, if the higher layer parameter tp-pi2BPSK is configured, q=1, otherwise q=2, where tp-pi2BPSK is defined as follows.

[0100] tp-pi2BPSK ENUMERATED{enabled}OPTIONAL,--Need S

[0101] tp-pi2BPSK

[0102] If this field is present, pi / 2-BPSK modulation with transform precoding is enabled, otherwise it is disabled.

[0103] like Figure 2As shown, in the 2-step random access procedure, the steps of detecting the synchronization signal block (SSB) and system information are the same as those in the 4-step method, but the initial access is done in only two steps in order to minimize the number of channel accesses. This is important for operations in, for example, unlicensed bands, where a listen-before-send must be performed before transmitting. At the first step, the UE sends a request message for random access (which is denoted as message A), which includes a random access preamble as well as higher layer data (such as an RRC connection request) and may have some small additional payload on the PUSCH. At the second step, the gNB sends a response message (which is denoted as message B), which includes, among other things, UE identifier allocation, timing advance information, and contention resolution information.

[0104] When the 2-step random access procedure is introduced, the PUSCH in message A (which is denoted as msgA) may be sent immediately after the associated random access channel (RACH) preamble. Therefore, compared with normal PUSCH, when two UEs select the same PUSCH resource, the PUSCH in msgA may collide with other PUSCHs. In addition, the msgA PUSCH may not be well time-aligned at the gNB because the UE may not have accurate timing advance. The preamble part of msgA generally has better performance than the PUSCH part because there is no data transmission in the preamble part. Therefore, it is desirable to provide a method for PUSCH enhancement to improve the msgA detection success rate in the 2-step random access procedure.

[0105] The present disclosure proposes an improved solution for a 2-step random access process. The solution can be applied to a wireless communication system including a terminal device and a base station. The terminal device can communicate with the base station via a radio access communication link. The base station can provide a radio access communication link to a terminal device in its communication service cell. The base station can be, for example, a gNB in ​​NR. It should be noted that communication can be performed between the terminal device and the base station according to any suitable communication standard and protocol. The terminal device may also be referred to as, for example, a device, an access terminal, a user equipment (UE), a mobile station, a mobile unit, a user station, etc. The terminal device may refer to any terminal device that can access a wireless communication network and receive services therefrom. By way of example and not limitation, the terminal device may include a portable computer, an image capture terminal device such as a digital camera, a game terminal device, a music storage and playback device, a mobile phone, a cellular phone, a smart phone, a tablet computer, a wearable device, a personal digital assistant (PDA), etc.

[0106] In the Internet of Things (IoT) scenario, a terminal device may refer to a machine or other device that performs monitoring and / or measurement and transmits the results of such monitoring and / or measurement to another terminal device and / or network device. In this case, the terminal device may be a machine-to-machine (M2M) device, which in the 3GPP context may be referred to as a machine type communication (MTC) device. Specific examples of such machines or devices may include sensors, metering devices such as power meters, industrial machinery, bicycles, vehicles, or household or personal appliances (e.g., refrigerators, televisions), personal wearable devices (such as watches), and the like.

[0107] Now, several embodiments will be described to illustrate an improved solution for the random access procedure. As a first embodiment, a transport block size (TBS) scaling factor S may be used to perform TBS scaling on the PUSCH in msgA. The TBS scaling factor S is a positive value and S <= 1. In order to apply TBS scaling, the existing PUSCH TBS determination process may be modified to achieve a lower code rate for the MsgA PUSCH, so that the actual spectral efficiency for TB transmission is lower than the nominal spectral efficiency (modulation order Q) from the MCS table. m × code rate R). By reducing the code rate of PUSCH, improved decoding performance can be expected.

[0108] As an illustrative example, for a PUSCH carrying MsgA, TBS determination may follow the procedure described above for determining the TBS for a PUSCH carrying Message 3, except for the following differences: The intermediate number of PUSCH information bits (N) in step 2 of section "5.1.3.2 Transport block size determination" of TS 38.214 is info ) is modified to include the calculation of N info =S·N RE ·R·Q m υ instead of N info =N RE ·R·Q m · υ performs TBS scaling, and MCS information and time domain resource allocation can be signaled via RRC signaling instead of using downlink control information (DCI).

[0109] Code rate R and modulation order Q m MCS index I MCS And MCS table to provide. For example, code rate R and modulation order Q m The value of can be determined by the row of the MCS table containing the minimum code rate R. The variable N REIndicates the number of resource elements (REs) that can be used to transmit a TB and can be provided by time domain and frequency domain configuration. For time domain configuration, the time domain resource allocation bits indicating the start symbol S and PUSCH duration L can be provided via (e.g., broadcast or UE-specific) RRC signaling. For frequency domain configuration, the number of PRBs allocated for MsgA TB transmission can be provided via (e.g., broadcast or UE-specific) RRC signaling. For example, Table 6.1.2.1.1-2 or Table 6.1.2.1.1-3 of 3GPP TS 38.214 can be used to identify the time domain resource allocation parameters.

[0110] For N RE Calculation also requires two variables and is the number of REs used for DMRS per PRB in the duration of the PUSCH allocation. It may be determined by the DMRS configuration of PUSCH transmission, where the DMRS configuration includes the number of a DMRS code division multiplexing (CDM) group and a DMRS port. is the number of REs per PRB used for other overhead. For simplicity, Can be set to a fixed value, e.g.

[0111] For example, one or more possible TBS scaling factors may be defined similar to the TBS scaling of PDSCH for paging and RAR. As an illustrative example, a scaling factor table with 4 entries as shown in Table 1 below may be used. Alternatively, a scaling factor table with 2 entries as shown in Table 2 below may be used.

[0112] TB scaling field Scaling factor S 00 1 01 0.5 10 0.25 11 0.125

[0113] Table 1: Scaling factors for TBS determination for msgA PUSCH

[0114] TB scaling field Scaling factor S 0 0.5 1 0.25

[0115] Table 2: Scaling factors for TBS determination for msgA PUSCH

[0116] The TBS scaling factor S used may be determined via one of the following options. As a first option, the value of S may be signaled in RRC signaling (e.g., system information or RRC dedicated signaling). In this way, a semi-static value of S may be sent from the gNB to the UE, and the UE may apply the signaled value S. Note that if the signaling is optional, a default value for S may be configured in the UE. As a second option, the gNB may configure a set of possible values ​​for S, such as 2 possible values ​​as shown in Table 2. The UE may select a value from the set of values ​​and apply it to a given MsgA transmission. For example, the UE may select the scaling factor S based on an estimate of the channel quality such as reference signal received power (RSRP). If the channel quality is above or below a predetermined threshold, a larger or smaller S value may be used, respectively. At the gNB receiver, it is unknown which S value the UE selects, and the receiver may blindly detect which S value is actually used. For example, the gNB may try two possible values ​​S=0.5 or 0.25 in Table 2. The value S that results in a successful detection of the PUSCH may be considered as the value actually applied by the UE. Successful detection of the PUSCH can be achieved when the decoding of the carried transport block successfully passes the cyclic redundancy check (CRC) check.

[0117] As a third option, the value of S can be implicitly determined by other known parameters. For example, other known parameters can be used to select a value from a set of 4 possible S values ​​shown in Table 1. Possible parameters that can be used to derive the value S may include, but are not limited to: PRACH preamble information (e.g., format and / or ID, PRACH occasion), DMRS information, usage information, frequency band information (e.g., licensed or unlicensed, frequency range 1 (FR1) or FR2). As a fourth option, S can take a fixed value. For example, S=0.25. It should be noted that in the first embodiment, since TBS scaling is applied, it is expected that higher modulation types can also be used at low coding rates.

[0118] As a second embodiment, PUSCH repetition can be used for one PUSCH transmission. For example, PUSCH can be configured with K repetitions for MsgA, where K is an integer and K>=1. Therefore, a PUSCH transmission set can be defined as consisting of K repetitions of a TB carrying MsgA higher layer data. In MsgA, a PRACH preamble can be followed by a PUSCH transmission set. The time and frequency position of the PUSCH transmission set can be related to the index that identifies the PRACH preamble. In other words, each of the K repetitions can be associated with a PRACH preamble sent before the repetition. Each of the K repetitions can be sent at a predetermined position in time and frequency and corresponds to an index that identifies the PRACH preamble. It should be noted that the term "repetition" is used here in such a way that 1 repetition refers to the TB itself, and 2 repetitions refer to the TB itself and 1 repetition of the TB.

[0119] In the time domain, the UE may send each of the K repetitions of the transmission set at different times. The K repetitions may occupy K consecutive available uplink transmission units, starting at a predefined instance relative to the end of the PRACH preamble. For example, in a time division duplex (TDD) system, symbols that cannot be used for PUSCH transmission may be excluded, including downlink (DL) symbols, gap symbols, flexible symbols, and symbols used for sounding reference signals (SRS).

[0120] The predetermined position in time may be signaled to the UE as one or more of: a periodicity expressed in symbols between times when the repetition may start, an offset indicating when one repetition may start relative to the system frame number, an indication of a starting symbol, and a length of the PUSCH transmission relative to the symbol identified by the periodicity and the offset. As an illustrative example, the predetermined position in time may be indicated according to one or more of the following parameters in the information element (IE) ConfiguredGrantConfig in 3GPP TS 38.331 V15.4.0: periodicity, timeDomainOffset, and timeDomainAllocation.

[0121] In the frequency domain, the K repetitions may or may not use frequency hopping. If frequency hopping is not applied, the K repetitions may occupy the same set of PRBs. If frequency hopping is applied, the K repetitions may occupy different sets of PRBs to achieve frequency diversity.

[0122] For repetitions, the predetermined position on frequency may be signaled in the form of: a starting virtual resource block, and a length expressed in consecutively allocated resource blocks. As an illustrative example, the parameter frequencyDomainAllocation in the IE ConfiguredGrantConfig in 3GPP TS 38.331 V15.4.0 may be used to identify the predetermined position on frequency. In the case where each repetition may be configured to occupy a different position on frequency, each repetition may be configured with a different value of frequencyDomainAllocation.

[0123] The parameter K may be provided to the UE using one of the following options. As a first option, the value of K may be signaled via RRC signaling. The RRC signaling may be carried in broadcast system information or dedicated signaling. In this way, a semi-static value of K may be sent from the gNB to the UE, and the UE may apply the notified value K to a set of PUSCH transmissions. Note that if the signaling is optional, a default value of K may be configured in the UE. As a second option, K may take a fixed value. For example, K=2. As a third option, K may be associated with other parameters such as PRACH preamble information (e.g., format and / or ID, PRACH timing), DMRS information, usage information, frequency band information (e.g., licensed or unlicensed, FR1 or FR2).

[0124] Optionally, the unit of repetition may be uniform, wherein the unit may be a time slot or a micro-time slot. Figure 3 As shown, a PUSCH transmission set consists of 4 repetitions, and the repetition unit is a time slot. If the unit is a time slot and K>1, for the TB of MsgA, the UE can repeat the TB on K consecutive designated time slots. For the PUSCH position in each time slot, two alternatives are possible. In the first alternative, the UE can apply the same symbol allocation in each time slot. That is, the PUSCH can occupy the same {start, end} symbol position in each designated time slot. In the second alternative, the UE can be allowed to use a PUSCH with a different {start, end} symbol allocation in each designated time slot.

[0125] If the unit is a minislot and K>1, the UE can repeat the TB on K consecutive designated minislots. If the K repetitions of the minislot need to cross the slot boundary, the UE can use one of the following alternatives. In the first alternative, the UE can terminate the PUSCH transmission at the minislot repetition that will cause the slot boundary to cross. Depending on the minislot duration and the K value, the UE may not be able to complete the K repetitions. In the second alternative, the UE can complete the K repetitions regardless of whether the slot boundary is crossed. It should be noted that, as an alternative, the unit of repetition can also be non-uniform. For example, the 1st, 2nd, and 3rd repetitions of the MsgA TB can use a 7-symbol minislot, a slot (containing 14 symbols), and a 4-symbol minislot, respectively.

[0126] In the above discussion, the K designated time slots (and similarly, the same applies to designated mini-time slots) may refer to one of the following:

[0127] 1) K slots according to absolute slot numbering. In this alternative, for a TDD system, if a slot (or some symbols in a slot) is marked for downlink transmission, some slots may not be available for PUSCH transmission. Such unavailable slots are skipped, resulting in potentially less than K slots being used for actual PUSCH repetition.

[0128] 2) K slots available for PUSCH transmission. In this alternative, for a TDD system, due to slots not available for PUSCH transmission, a PUSCH transmission may span more than K slots in terms of absolute slot numbering.

[0129] 3) K time slots defined by periodicity and timeDomainOffset.

[0130] Optionally, between K repetitions of the PUSCH transmission, a redundancy version (RV) sequence may be defined such that each of the K PUSCH repetitions may use a different RV. As a non-limiting example, for the nth transmission opportunity (n=1, 2, ..., K) among the K repetitions, it may be associated with the (mod(n-1, 4)+1)th value in the provided RV sequence.

[0131] The RV sequence may be provided to the UE via one of the following options. As a first option, the RV sequence may be RRC configured. The RRC signaling may be system information or RRC dedicated signaling. As a second option, the RV sequence may be fixed. Examples of RV sequences of length 4 may include {0,0,0,0}, {0,2,3,1}, {0,3,0,3}, etc.

[0132] As a third embodiment, repeated PUSCH transmissions may be used for progressive msgA attempts. For example, when the UE makes a msgA attempt, the msgA attempt may fail and the UE needs to try again. After sending the jth msgA attempt, the UE may wait to see if the gNB sends MsgB. If msgB is not received within a predefined time interval, the UE may consider the jth msgA to have failed and may make a (j+1)th msgA attempt. In order to improve the probability of success in the (j+1)th attempt, the UE may repeat PUSCH transmissions increasingly in the progressive msgA attempt.

[0133] As an example, a PUSCH transmission set may be repeated, where a PUSCH transmission set may consist of K repetitions of a given TB. For example, in the jth msgA attempt, the UE may repeat PUSCH transmission L j In the (j+1)th msgA attempt, the UE may repeat the PUSCH transmission L j+1 times, among which L j+1 >L j >=1. Consider the case where a PUSCH transmission consists of K repetitions of a MsgA TB, and the jth and (j+1)th msgA attempts use K*L of this TB respectively. j and K*L j+1 For example, Figure 4 As shown, the first / second / third MsgA attempt uses 1 / 2 / 4 PUSCH transmission sets of a given MsgA TB.

[0134] As another example, the length of the PUSCH transmission set is increased after each failed MsgA attempt. For example, in the jth MsgA attempt, the PUSCH transmission set may consist of K of the MsgA TBs. j The UE can repeat the MsgA TBK. j In the (j+1)th msgA attempt, the PUSCH transmission set can be composed of K of MsgA TB j+1 The UE can repeat MsgA TB K j+1 times, of which K j+1 >K j >=1. K j and K j+1 The value of may be determined by the parameters used for the j-th and (j+1)-th msgA transmissions, respectively, and / or the number j, and / or the step size used to increase the number of repetitions.

[0135] In the above second and third embodiments, repeated PUSCH transmissions and / or PUSCH repetitions in one transmission may be performed on a continuous or predetermined set of PUSCH time-frequency resources configured for MsgA PUSCH transmission in 2-step random access. The PRACH timing and PUSCH timing for one MsgA transmission may be time-division multiplexed and / or frequency-division multiplexed.

[0136] For example, Figure 5 A PRACH opportunity multiplexed with two PUSCH opportunities in a time division multiplexing (TDM) manner is shown. As shown, one msgA transmission may include: one preamble transmission in a PRACH opportunity, one PUSCH transmission of a transport block carried on PUSCH opportunity #1 in a first time interval, and a second PUSCH transmission of a transport block carried on PUSCH opportunity #2 in a second time interval. In this example, the PRACH and two PUSCH transmissions occupy the same frequency domain resources.

[0137] Figure 6 Show Figure 5 . As shown, the PRACH and two PUSCH transmissions are still sent in separate time intervals, but the PUSCH opportunities can also occupy frequency resources that are different from the PRACH and from each other. Sending PUSCH transport blocks in different frequency resources can improve performance by providing diversity gain in multipath fading channels, or by enhancing robustness to interference when the interference varies with frequency.

[0138] As a fourth embodiment, in order to improve PUSCH performance, a low spectrum efficiency 64QAM MCS table ("qam64LowSE" table, such as Table 5.1.3.1-3 and Table 6.1.4.1-2 of TS 38.214V15.4.0) may be used. The qam64LowSE MCS table contains lower MCS values ​​having a lower target coding rate than the ordinary qam64 MCS table (e.g., Table 5.1.3.1-1 and Table 6.1.4.1-1 of TS38.214V15.4.0). Specifically, the MCS index I in the range of 0-5 MCS Lower spectrally efficient entries than the normal 64QAM MCS Table 1 ("qam64" table, eg, Table 6.1.4.1-1: MCS Index Table 1 of TS 38.214 V15.4.0) may be provided.

[0139] As an illustrative example, more rows of MCS values ​​with lower spectral efficiency can be added to the "qam64LowSE" MCS table. Optionally, some rows with MCS values ​​with high spectral efficiency can be removed from the "qam64LowSE" MCS table. This creates a new "qam64LowSE2" MCS table for OFDM, and a new "qam64LowSE2" MCS table for DFT-s-OFDM. The new "qam64LowSE2" MCS table for OFDM is shown in Table 3 below. As shown in the table, the two rows with lower spectral efficiency are the same as I MCS = 0 and 1 are added together, and the two rows with the highest spectral efficiency in the qam64 MCS table for OFDM (e.g. Table 5.1.3.1-3 of TS 38.214 V15.4.0: MCS Index Table 3 for PDSCH) are removed. A similar "qam64LowSE2" MCS table for DFT-s-OFDM can also be introduced.

[0140]

[0141] Table 3: qam64LowSE2 MCS index table for PUSCH with transform precoding disabled

[0142] Optionally, some RRC signaling may be sent to determine which table will be used for MsgAPUSCH in 2-step random access (RA). For example, the following field may be added to (eg, broadcast RRC or UE-specific) RRC signaling to select the MCS table.

[0143] mcs-Table-msgA ENUMERATED{qam64,qam64LowSE,qam64LowSE2}

[0144] OPTIONAL,--Need S

[0145] mcs-TableTransformPrecoder-msgA ENUMERATED{qam64,qam64LowSE,qam64LowSE2}

[0146] OPTIONAL,--Need S

[0147] Similarly, the corresponding configuration regarding whether to use the transform precoder may also be signaled using (eg, broadcast or UE-specific) RRC signaling, as shown below.

[0148] transformPrecoderMsgA ENUMERATED{enabled,disabled}

[0149] OPTIONAL,--Need S

[0150] Alternatively, a fixed table may be applied for 2-step RA. For example, it may be predefined that the qam64LowSE MCS table should be used. In addition, whether transform precoding is to be used and the MCS table to be used may be predefined for MsgA. For example, for PUSCH MsgA, transform precoding may be always disabled.

[0151] Alternatively, which table to be used may be determined by other factors such as PRACH preamble information (PRACH format and / or preamble ID, PRACH timing), DMRS information, usage information, frequency band information (e.g. licensed or unlicensed, FR1 or FR2).

[0152] Optionally, a new MCS table may be defined separately from the existing table for msgA PUSCH transmission. For example, the 8-entry Table 4 shown below may be used for MsgA PUSCH with disabled transform precoding. If MsgAPUSCH is not retransmitted, Table 4 does not include reserved entries.

[0153]

[0154] Table 4: qam64LowSE2 MCS index table for PUSCH with transform precoding disabled

[0155] If MsgA PUSCH has retransmission, some reserved rows may be included for each modulation order, as shown in Table 5 below.

[0156]

[0157] Table 5: qam64LowSE2 MCS index table for PUSCH with transform precoding disabled

[0158] Optionally, the following alternatives may be utilized to consider whether PI / 2 BPSK will be supported for msgA PUSCH when transform precoding is enabled. As a first alternative, PI / 2-BPSK may be always enabled or disabled. As a second alternative, whether PI / 2-BPSK will be enabled may be notified via RRC signaling. If possible, the signaling may be cell-specific RRC signaling or UE-specific RRC signaling. As an illustrative example, the following parameter tp-pi2BPSK-msgA may be defined in the PUSCH-ConfigCommon IE for configuring cell-specific PUSCH parameters.

[0159] tp-pi2BPSK-msgA ENUMERATED{enabled}OPTIONAL,--Need S

[0160] tp-pi2BPSK-msgA

[0161] If this field is present, pi / 2-BPSK modulation with transform precoding is enabled for msgA, otherwise it is disabled.

[0162] As a fifth embodiment, for the above-mentioned first to fourth embodiments, the msgA attempt may include transmission with "both preamble and PUSCH" or transmission with "only PUSCH".

[0163] In the following, reference will be made to Figure 7-17 Further explain the solution. Figure 7 702 is a flow chart illustrating a method implemented at a terminal device according to an embodiment of the present disclosure. At box 702, the terminal device determines a request message for random access. The request message includes a preamble and one or more PUSCHs. At box 704, the terminal device sends the request message. The random access may be a two-step random access, and the request message may be message A. For example, the request message may be determined at box 702 using one or more of the three options described below. At box 704, the request message may be sent to a base station over an air interface.

[0164] As a first option, the number of one or more PUSCHs is more than one, and the more than one PUSCHs are multiple repetitions of the PUSCH. In this way, the reliability of the PUSCH transmission of the request message can be improved, so that the detection / decoding rate of the request message can be improved in the two-step random access process. For example, the multiple repetitions of the PUSCH can be divided into one or more PUSCH transmission sets. Each PUSCH transmission set can include more than one repetition of the PUSCH.

[0165] As described above in the second and third embodiments, each repetition of PUSCH can be associated with a preamble. The number of multiple repetitions of PUSCH can be obtained from RRC signaling and / or preconfiguration in the terminal device. Alternatively, the number of multiple repetitions of PUSCH can be determined based on at least one of the following: preamble information, DMRS information, usage information, and frequency band information. The preamble and each repetition of PUSCH can be time-division multiplexed and / or frequency-division multiplexed. Optionally, each repetition of PUSCH can use a corresponding RV in a redundant version (RV) sequence. The RV sequence can be obtained from RRC signaling and / or preconfiguration in the terminal device.

[0166] The first option may be applied to the case of retransmission of the request message. For example, the random access may be initiated due to the failure of the previous random access. In this case, the number of multiple repetitions of the PUSCH used for the access may not be less than the number of multiple repetitions of the PUSCH used for the previous random access. For example, the number of repetitions of the PUSCH in each PUSCH transmission set for random access may not be less than the number of repetitions of the PUSCH in each PUSCH transmission set for the previous random access. Additionally or alternatively, the number of one or more PUSCH transmission sets for random access may not be less than the number of one or more PUSCH transmission sets used for the previous random access.

[0167] As a second option, the size of the TB carried in the PUSCH is scaled by a scaling factor relative to a reference size of the TB carried in the PUSCH. The scaling factor may be a positive value less than or equal to one. As described above in the first embodiment, the reference size of the TB may be determined based on a first product of: the number of REs available for carrying the TB, the modulation order and the target code rate for the TB. The size of the TB may be determined based on a second product of the scaling factor and the first product. The scaling factor may be obtained from RRC signaling, and / or pre-configuration in the terminal device. Alternatively, the scaling factor may be selected from a set of preconfigured values ​​based on channel quality estimation. Alternatively, the scaling factor may be determined based on at least one of: preamble information, DMRS information, usage information, and frequency band information.

[0168] As a third option, the request message is determined based on an MCS table having a lower spectral efficiency than a reference MCS table. For example, as described above in the fourth embodiment, the MCS table may be a table obtained by adding one or more rows with lower spectral efficiency to a reference MCS table. Alternatively, the MCS table may be obtained by removing one or more rows with higher spectral efficiency from a reference MCS table. As an illustrative example, the reference MCS table may be a QAM64LowSE MCS table in which a transform precoder is enabled, or a QAM64LowSE MCS table in which a transform precoder is disabled. The MCS table may be a table defined in place of a reference MCS table, or a table defined separately from a reference MCS table.

[0169] Optionally, which MCS table will be used to determine the request message can be indicated via RRC signaling. Alternatively, a fixed MCS table can be preconfigured for determining the request message. Alternatively, which MCS table will be used to determine the request message can be determined based on at least one of the following: preamble information, DMRS information, usage information, and frequency band information.

[0170] Optionally, whether PI / 2BPSK is to be enabled for the determination request message may be indicated via RRC signaling.Alternatively, PI / 2BPSK may be preconfigured to be enabled or disabled in the terminal device.

[0171] Figure 8 804. It is a flowchart illustrating a method implemented at a base station according to an embodiment of the present disclosure. At box 802, the base station receives a request message for random access. The request message includes a preamble and one or more PUSCHs. At box 804, the base station obtains one or more PUSCHs from the request message. The random access may be a two-step random access, and the request message may be message A. At box 802, a request message may be received from a terminal device over an air interface. One or more PUSCHs may be obtained at box 804 using one or more of the three options described below. It should be noted that when more than one PUSCH is included in the request message, some or all of the more than one PUSCHs may be obtained at box 804, as described later.

[0172] As a first option, the number of one or more PUSCHs is more than one, and the more than one PUSCHs are multiple repetitions of the PUSCH. In this way, the detection / decoding rate of the request message can be improved in the two-step random access process. For example, multiple repetitions of the PUSCH can be divided into one or more PUSCH transmission sets. Each PUSCH transmission set can include more than one repetition of the PUSCH.

[0173] As described above in the second and third embodiments, each repetition of the PUSCH may be associated with a preamble. The number of multiple repetitions of the PUSCH may be sent to the terminal device in RRC signaling. Alternatively, there is no need to send RRC signaling, and the number of multiple repetitions of the PUSCH may be preconfigured in both the base station and the terminal device. Alternatively, the number of multiple repetitions of the PUSCH may be determined by the base station based on at least one of the following: preamble information, DMRS information, usage information, and frequency band information. The preamble and each repetition of the PUSCH may be time-division multiplexed and / or frequency-division multiplexed. Optionally, each repetition of the PUSCH may use a corresponding RV in an RV sequence. The RV sequence may be sent to the terminal device in RRC signaling. Alternatively, there is no need to send RRC signaling, and the RV sequence may be preconfigured in both the base station and the terminal device.

[0174] The first option can be applied to the case of receiving a retransmission of a request message. For example, a random access may be initiated due to the failure of a previous random access. In this case, the number of multiple repetitions of the PUSCH used for the access may not be less than the number of multiple repetitions of the PUSCH used for the previous random access. For example, the number of repetitions of the PUSCH in each PUSCH transmission set for random access may not be less than the number of repetitions of the PUSCH in each PUSCH transmission set for the previous random access. Additionally or alternatively, the number of one or more PUSCH transmission sets for random access may not be less than the number of one or more PUSCH transmission sets for the previous random access. Accordingly, the base station can obtain at least a portion of the multiple repetitions of the PUSCH based on the configuration of the above-mentioned request message. For example, if one or some repetitions of the PUSCH can be correctly decoded, other repetitions of the PUSCH can be omitted.

[0175] As a second option, the size of the TB carried in the PUSCH is scaled by a scaling factor relative to a reference size of the TB carried in the PUSCH. The scaling factor may be a positive value less than or equal to one. As described above in the first embodiment, the reference size of the TB may be determined based on the following first product: the number of REs available for carrying the TB, the modulation order used for the TB, and the target code rate. The size of the TB may be determined based on a second product of the scaling factor and the first product. The scaling factor may be sent to the terminal device in RRC signaling. Alternatively, RRC signaling does not need to be sent, and the scaling factor may be preconfigured in both the base station and the terminal device. Alternatively, the scaling factor may be blindly detected from a set of preconfigured values. Alternatively, the scaling factor may be determined based on at least one of the following: preamble information, DMRS information, usage information, and frequency band information. Accordingly, the base station may obtain the PUSCH from the request message based on the scaling factor.

[0176] As a third option, one or more PUSCHs are obtained based on an MCS table having a lower spectral efficiency than a reference MCS table. For example, as described above in the fourth embodiment, the MCS table may be a table obtained by adding one or more rows with lower spectral efficiency to a reference MCS table. Alternatively, the MCS table may be obtained by removing one or more rows with higher spectral efficiency from a reference MCS table. As an illustrative example, the reference MCS table may be a QAM64LowSE MCS table in which the transform precoder is enabled, or a QAM64LowSE MCS table in which the transform precoder is disabled. The MCS table may be a table defined in place of the reference MCS table, or a table defined separately from the reference MCS table.

[0177] Optionally, which MCS table will be used to obtain one or more PUSCHs may be sent to the terminal device in RRC signaling. Alternatively, no RRC signaling is required, and a fixed MCS table may be preconfigured in both the base station and the terminal device for obtaining one or more PUSCHs. Alternatively, which MCS table will be used to obtain one or more PUSCHs is determined based on at least one of: preamble information, DMRS information, usage information, and frequency band information.

[0178] Optionally, whether PI / 2BPSK is to be enabled for obtaining one or more PUSCHs may be indicated to the terminal device via RRC signaling. Alternatively, no RRC signaling is required, and PI / 2BPSK may be preconfigured to be enabled or disabled in both the base station and the terminal device. It should be noted that two consecutively shown blocks in the accompanying drawings may actually be executed substantially in parallel, or they may sometimes be executed in the opposite order, depending on the functions involved.

[0179] In one embodiment, the present disclosure also provides a method for determining the number of information bits to be used in a random access transmission. The method may include determining a set of parameters including a modulation order Q m , code rate R, and the number of resource elements N carrying PUSCH RE The method may also include determining an information payload scaling factor S. The method may also include calculating an intermediate number of information bits to be used in the random access transmission as N info =S·N RE ·R·Q m The method may further include quantizing the intermediate number of information bits to form the number of information bits to be used in the random access transmission.

[0180] Optionally, the step of determining the information payload scaling factor S may further comprise selecting a value of S from a set of values ​​according to a channel quality estimate. For higher channel qualities, the value of S may be larger.

[0181] In one embodiment, the present disclosure also provides a method for repeating a transport block used in a random access transmission. The method may include determining a first number K of repetitions of the transport block. The method may also include determining a position in time and frequency for each of the K repetitions of the transport block. The method may also include sending a first random access preamble. The method may also include sending K repetitions of the transport block, each repetition being sent at its time and frequency position, and each repetition being associated with the first random access preamble.

[0182] Optionally, the method may further include determining a second number of repetitions K2 for repeating the transport block, wherein K2 is greater than K. The method may further include determining a position in time and frequency for each of the K2 repetitions of the transport block. The method may further include sending a second random access preamble. The method may further include sending K2 repetitions of the transport block, each repetition being sent at its time and frequency position, and each repetition being associated with a second random access preamble.

[0183] Optionally, the preamble and repetitions may be time-division multiplexed, and the repetitions may be in a different set of subcarriers than the preamble. For example, the first random access preamble may be sent in a first set of OFDM symbols and a first set of subcarriers. Each of the K repetitions may be sent in a set of OFDM symbols that is different from the other K repetitions and different from the first set of OFDM symbols. At least one of the K repetitions may occupy a second set of subcarriers that is different from the first set of subcarriers.

[0184] Based on the above description, at least one aspect of the present disclosure provides a method implemented in a communication system including a base station and at least one terminal device. The method may include: determining a request message for random access at at least one terminal device. The request message may include a preamble and one or more PUSCHs. The method may also include: sending a request message at at least one terminal device. The method may also include: receiving a request message for random access at the base station. The request message may include a preamble and one or more PUSCHs. The method may also include: obtaining one or more PUSCHs from the request message at the base station.

[0185] Fig. 9 9 is a block diagram showing an apparatus suitable for use in practicing some embodiments of the present disclosure. For example, any of the above-mentioned terminal devices and base stations can be implemented by apparatus 900. As shown in the figure, apparatus 900 may include a processor 910, a memory 920 storing programs, and an optional communication interface 930 for data communication with other external devices via wired and / or wireless communication.

[0186] The program includes program instructions that, when executed by the processor 910, enable the device 900 to operate according to the embodiments of the present disclosure, as discussed above. That is, the embodiments of the present disclosure may be implemented at least in part by computer software executable by the processor 910, or by hardware, or by a combination of software and hardware.

[0187] The memory 920 may be of any type suitable for the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor-based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory, and removable memory. The processor 910 may be of any type suitable for the local technical environment and may include, as non-limiting examples, one or more of a general-purpose computer, a special-purpose computer, a microprocessor, a digital signal processor (DSP), and a processor based on a multi-core processor architecture.

[0188] Fig.10 1 is a block diagram illustrating a terminal device according to an embodiment of the present disclosure. As shown in the figure, the terminal device 1000 includes a determination module 1002 and a transmission module 1004. The determination module 1002 can be configured to determine a request message for random access, as described above with respect to block 702. The request message includes a preamble and one or more PUSCHs. The transmission module 1004 can be configured to send the request message, as described above with respect to block 704.

[0189] Fig.11 1 is a block diagram illustrating a base station according to an embodiment of the present disclosure. As shown in the figure, the base station 1100 includes a receiving module 1102 and an obtaining module 1104. The receiving module 1102 may be configured to receive a request message for random access, as described above with respect to block 802. The request message includes a preamble and one or more PUSCHs. The obtaining module 1104 may be configured to obtain one or more PUSCHs from the request message, as described above with respect to block 804. The above modules may be implemented by hardware, software, or a combination of both.

[0190] Based on the above description, at least one aspect of the present disclosure provides a communication system including at least one terminal device and a base station. At least one terminal device may be configured to determine a request message for random access and send the request message. The request message may include a preamble and one or more PUSCHs. The base station may be configured to receive a request message for random access and obtain one or more PUSCHs from the request message. The request message may include the preamble and the one or more PUSCHs.

[0191] refer to Fig.12According to an embodiment, the communication system includes a telecommunication network 3210 such as a 3GPP type cellular network, which includes an access network 3211 such as a radio access network and a core network 3214. The access network 3211 includes a plurality of base stations 3212a, 3212b, 3212c (such as NB, eNB, gNB or other types of wireless access points), each defining a corresponding coverage area 3213a, 3213b, 3213c. Each base station 3212a, 3212b, 3212c can be connected to the core network 3214 via a wired or wireless connection 3215. A first UE 3291 located in the coverage area 3213c is configured to be wirelessly connected to the corresponding base station 3212c, or to be paged by the corresponding base station 3212c. A second UE 3292 in the coverage area 3213a can be wirelessly connected to the corresponding base station 3212a. Although multiple UEs 3291, 3292 are shown in this example, the disclosed embodiments are equally applicable to situations where a single UE is in the coverage area or a single UE is connected to the corresponding base station 3212.

[0192] The telecommunications network 3210 itself is connected to a host 3230, which may be embodied in the hardware and / or software of a standalone server, a cloud-implemented server, a distributed server, or as processing resources in a server farm. The host 3230 may be under the ownership or control of a service provider, or may be operated by or on behalf of a service provider. The connections 3221 and 3222 between the telecommunications network 3210 and the host 3230 may extend directly from the core network 3214 to the host 3230, or may extend via an optional intermediate network 3220. The intermediate network 3220 may be one of a public network, a private network, or a hosted network, or a combination of more than one; if any, the intermediate network 3220 may be a backbone network or the Internet; in particular, the intermediate network 3220 may include two or more subnetworks (not shown).

[0193] Fig.12The communication system as a whole implements connectivity between connected UEs 3291, 3292 and a host 3230. The connectivity may be described as an over-the-top (OTT) connection 3250. The host 3230 and the connected UEs 3291, 3292 are configured to use the access network 3211, the core network 3214, any intermediate networks 3220, and possible additional infrastructure (not shown) as intermediaries to pass data and / or signaling via the OTT connection 3250. The participating communication devices traversed by the OTT connection 3250 are not aware of the routing of uplink and downlink communications, and in this sense, the OTT connection 3250 may be transparent. For example, the base station 3212 may not or need not be informed of the past routing of incoming downlink communications with data originating from the host 3230 to be forwarded (e.g., handed over) to the connected UE 3291. Similarly, base station 3212 need not be aware of future routing of uplink communications originating from UE 3291 toward host 3230.

[0194] Now refer to Fig.13 Describe the example implementation of the UE, base station and host discussed in the previous paragraph according to one embodiment. In the communication system 3300, the host 3310 includes hardware 3315, and the hardware 3315 includes a communication interface 3316, which is configured to establish and maintain a wired or wireless connection of an interface with different communication devices of the communication system 3300. The host 3310 also includes a processing circuit 3318, which may have storage and / or processing capabilities. In particular, the processing circuit 3318 may include one or more programmable processors, application specific integrated circuits, field programmable gate arrays, or a combination of these suitable for executing instructions (not shown). The host 3310 also includes software 3311, which is stored in the host 3310 or can be accessed by the host 3310, and can be executed by the processing circuit 3318. Software 3311 includes a host application 3312. The host application 3312 may be operable to provide services to a remote user, such as a UE 3330 connected via an OTT connection 3350 terminating at the UE 3330 and the host 3310. In providing services to the remote user, the host application 3312 may provide user data transmitted using the OTT connection 3350.

[0195] The communication system 3300 also includes a base station 3320, which is provided in the telecommunication system and includes hardware 3325 that enables it to communicate with the host 3310 and the UE 3330. The hardware 3325 may include a communication interface 3326 for establishing and maintaining a wired or wireless connection with different communication devices of the communication system 3300, and a communication interface 3326 for establishing and maintaining a connection with a network located in the coverage area ( Fig.133327 of at least a wireless connection 3370 of a UE 3330 in the example embodiment (not shown). The communication interface 3326 may be configured to facilitate a connection 3360 to the host 3310. The connection 3360 may be direct, or the connection 3360 may pass through a core network ( Fig.13 3320) and / or traverse one or more intermediate networks external to the telecommunications system. In the illustrated embodiment, the hardware 3325 of the base station 3320 also includes processing circuitry 3328, which may include one or more programmable processors, application specific integrated circuits, field programmable gate arrays, or a combination of these suitable for executing instructions (not shown). The base station 3320 also has software 3321 stored internally or accessible via an external connection.

[0196] The communication system 3300 also includes the UE 3330 already mentioned. Its hardware 3335 may include a radio interface 3337, which is configured to establish and maintain a wireless connection 3370 with a base station serving the coverage area where the UE 3330 is currently located. The hardware 3335 of the UE 3330 also includes a processing circuit 3338, which may include one or more programmable processors, application specific integrated circuits, field programmable gate arrays, or a combination of these suitable for executing instructions (not shown). The UE 3330 also includes software 3331, which is stored in the UE 3330 or can be accessed by the UE 3330 and can be executed by the processing circuit 3338. The software 3331 includes a client application 3332. The client application 3332 may be operable to provide services to human or non-human users via the UE 3330 under the support of the host 3310. In the host 3310, the executed host application 3312 can communicate with the executed client application 3332 via the OTT connection 3350 terminated at the UE 3330 and the host 3310. In the process of providing services to the user, the client application 3332 can receive request data from the host application 3312 and provide user data in response to the request data. The OTT connection 3350 can transmit both the request data and the user data. The client application 3332 can interact with the user to generate the user data it provides.

[0197] It should be noted that Fig.13 The host 3310, base station 3320 and UE 3330 shown in Fig.12 The host 3230, one of the base stations 3212a, 3212b, 3212c, and one of the UEs 3291, 3292 are similar or identical. That is, the internal workings of these entities can be similar to Fig.13 As shown, and independently, the surrounding network topology can be Fig.12 The surrounding network topology.

[0198] exist Fig.13 In the figure, the OTT connection 3350 has been abstractly drawn to show the communication between the host 3310 and the UE 3330 via the base station 3320, without explicit reference to any intermediate devices and the precise routing of messages via these devices. The network infrastructure can determine the route, and the network infrastructure can be configured to hide the route from the UE 3330, or hide the route from the service provider operating the host 3310, or hide the route from both. When the OTT connection 3350 is active, the network infrastructure can also make decisions by which the network infrastructure dynamically changes the route (for example, based on load balancing considerations or reconfiguration of the network).

[0199] The wireless connection 3370 between the UE 3330 and the base station 3320 is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to the UE 3330 using the OTT connection 3350, in which the wireless connection 3370 forms the last leg. More precisely, the teachings of these embodiments can improve latency and thereby provide benefits such as reduced user waiting time.

[0200] The measurement process may be provided for the purpose of monitoring data rate, latency, and other factors improved by one or more embodiments. There may also be an optional network function for reconfiguring the OTT connection 3350 between the host 3310 and the UE 3330 in response to changes in the measurement results. The measurement process and / or network function for reconfiguring the OTT connection 3350 may be implemented in the software 3311 and hardware 3315 of the host 3310, or in the software 3331 and hardware 3335 of the UE 3330, or in both. In some embodiments, a sensor (not shown) may be deployed in or associated with a communication device through which the OTT connection 3350 passes; the sensor may participate in the measurement process by supplying the values ​​of the monitored quantities exemplified above, or supplying the values ​​of other physical quantities from which the software 3311, 3331 can calculate or estimate the monitored quantities. The reconfiguration of the OTT connection 3350 may include message formats, retransmission settings, preferred routes, etc.; the reconfiguration does not need to affect the base station 3320, and the reconfiguration may be unknown or imperceptible to the base station 3320. Such processes and functions may be known and practiced in the art. In certain embodiments, the measurements may involve proprietary UE signaling that facilitates measurement of throughput, propagation time, latency, etc., of the host 3310. The measurements may be implemented because the software 3311 and 3331 causes messages (particularly, empty messages or 'dummy' messages) to be transmitted using the OTT connection 3350 while the software 3311 and 3331 monitors propagation time, errors, etc.

[0201] Fig.14is a flow chart showing a method implemented in a communication system according to an embodiment. The communication system includes a host, a base station and a UE, which can be reference Fig.12 and 13 For the sake of brevity of this disclosure, only the Fig.14 Reference to the accompanying drawings of . In step 3410, the host provides user data. In sub-step 3411 of step 3410 (which may be optional), the host provides user data by executing a host application. In step 3420, the host initiates a transmission carrying the user data to the UE. In step 3430 (which may be optional), in accordance with the teachings of the embodiments described in the full text of this disclosure, the base station sends the user data carried in the transmission initiated by the host to the UE. In step 3440 (which may be optional), the UE executes a client application associated with the host application executed by the host.

[0202] Fig.15 is a flow chart showing a method implemented in a communication system according to an embodiment. The communication system includes a host, a base station and a UE, which can be reference Fig.12 and 13 For the sake of brevity of this disclosure, only the Fig.15 Reference to the accompanying drawings of the method. In step 3510 of the method, the host provides user data. In an optional sub-step (not shown), the host provides the user data by executing a host application. In step 3520, the host initiates a transmission carrying the user data to the UE. According to the teachings of the embodiments described in the full text of this disclosure, the transmission can be performed via a base station. In step 3530 (which may be optional), the UE receives the user data carried in the transmission.

[0203] Fig.16 is a flow chart showing a method implemented in a communication system according to an embodiment. The communication system includes a host, a base station and a UE, which can be reference Fig.12 and 13 For the sake of brevity of this disclosure, only the Fig.16Reference to the accompanying drawings. In step 3610 (which may be optional), the UE receives input data provided by the host. Additionally or alternatively, in step 3620, the UE provides user data. In sub-step 3621 of step 3620 (which may be optional), the UE provides user data by executing a client application. In sub-step 3611 of step 3610 (which may be optional), the UE executes a client application that provides user data as a reaction to the received input data provided by the host. In the process of providing user data, the executed client application may also consider user input received from the user. Regardless of the specific manner of providing user data, in sub-step 3630 (which may be optional), the UE initiates transmission of user data to the host. In step 3640 of the method, in accordance with the teachings of the embodiments described in the entire disclosure, the host receives user data sent from the UE.

[0204] Fig.17 is a flow chart showing a method implemented in a communication system according to an embodiment. The communication system includes a host, a base station and a UE, which can be reference Fig.12 and 13 For the sake of brevity of this disclosure, only the Fig.17 In step 3710 (which may be optional), in accordance with the teachings of the embodiments described throughout this disclosure, the base station receives user data from the UE. In step 3720 (which may be optional), the base station initiates a transmission of the received user data to the host. In step 3730 (which may be optional), the host receives the user data carried in the transmission initiated by the base station.

[0205] In general, various exemplary embodiments may be implemented in hardware or dedicated circuits, software, logic, or any combination thereof. For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software that may be executed by a controller, microprocessor, or other computing device, although the present disclosure is not limited thereto. Although various aspects of the exemplary embodiments of the present disclosure may be shown and described as block diagrams, flow charts, or using some other graphical representations, it should be well understood that, as non-limiting examples, the blocks, devices, systems, techniques, or methods described herein may be implemented in hardware, software, firmware, dedicated circuits or logic, general-purpose hardware or controllers, or other computing devices, or some combination thereof.

[0206] Thus, it should be understood that at least some aspects of the exemplary embodiments of the present disclosure may be practiced in various components such as integrated circuit chips and modules. Thus, it should be understood that the exemplary embodiments of the present disclosure may be implemented in a device embodied as an integrated circuit, wherein the integrated circuit may include circuits (and possibly firmware) for embodying at least one or more of a data processor, a digital signal processor, a baseband circuit, and a radio frequency circuit that may be configured to operate according to the exemplary embodiments of the present disclosure.

[0207] It should be understood that at least some aspects of the exemplary embodiments of the present disclosure may be embodied in computer executable instructions executed by one or more computers or other devices, such as embodied in one or more program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., which perform specific tasks or implement specific abstract data types when executed by a processor in a computer or other device. Computer executable instructions may be stored on a computer readable medium, such as a hard disk, an optical disk, a removable storage medium, a solid-state memory, a RAM, etc. It will be appreciated by those skilled in the art that the functions of the program modules may be combined or distributed as needed in various embodiments. In addition, the functions may be embodied in firmware or hardware equivalents (such as integrated circuits, field programmable gate arrays (FPGAs), etc.) in whole or in part.

[0208] References in this disclosure to "one embodiment," "an embodiment," etc., indicate that the described embodiment may include a particular feature, structure, or characteristic, but not every embodiment must include the particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment. In addition, when a particular feature, structure, or characteristic is described in conjunction with an embodiment, it is within the knowledge of those skilled in the art to implement such feature, structure, or characteristic in conjunction with other embodiments, whether or not explicitly described.

[0209] It should be understood that, although the terms "first", "second", etc. can be used in this article to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another element. For example, the first element can be referred to as the second element, and similarly, the second element can be referred to as the first element without departing from the scope of this disclosure. As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed terms.

[0210] The terms used herein are only used to describe the purpose of specific embodiments, and are not intended to limit the present disclosure. As used herein, the singular "a, an" and "the" are intended to also include plural forms, unless the context clearly indicates otherwise. It will also be understood that the terms "include", "have" and / or "comprise" when used herein refer to the existence of stated features, elements and / or components, and do not exclude the existence or addition of one or more other features, elements, components and / or their combinations. The term "connection" used herein covers the direct and / or indirect connection between two elements.

[0211] The present disclosure includes any novel feature or feature combination disclosed herein, either explicitly or in any generalized form thereof. When read in conjunction with the accompanying drawings, various modifications and adaptations to the above exemplary embodiments of the present disclosure will become apparent to those skilled in the relevant art in view of the above description. However, any and all modifications will still fall within the scope of the non-limiting and exemplary embodiments of the present disclosure.

Claims

1. A method in a terminal device, comprising: determining (702) a request message for random access, the request message comprising a preamble and one or more physical uplink shared channels PUSCH; as well as sending (704) the request message, Wherein, PI / 2 binary phase shift keying BPSK is preconfigured to be disabled in the terminal device for the request message.

2. The method according to claim 1, wherein: A fixed modulation and coding scheme MCS table is preconfigured for determining the request message.

3. The method according to claim 1 or 2, wherein: The number of the one or more PUSCHs is more than one, and the more than one PUSCHs are multiple repetitions of a PUSCH.

4. The method according to claim 3, wherein: The multiple repetitions of the PUSCH are divided into one or more PUSCH transmission sets.

5. The method according to claim 3, wherein: The random access is initiated due to failure of a previous random access; and The number of the multiple repetitions of the PUSCH used for the random access is not less than the number of the multiple repetitions of the PUSCH used for the previous random access.

6. The method according to claim 3, wherein: Each repetition of the PUSCH is associated with the preamble.

7. The method according to claim 3, wherein: The number of the plurality of repetitions of the PUSCH is selected from at least one of the following: Radio Resource Control RRC signaling; Pre-configuration in the terminal device; as well as The determination is based on at least one of the following: preamble information, demodulation reference signal DMRS information, usage information, and frequency band information.

8. The method according to claim 3, wherein: The preamble and the respective repetitions of the PUSCH are time division multiplexed and / or frequency division multiplexed.

9. The method according to claim 3, wherein: Each repetition of the PUSCH uses a corresponding RV in a redundancy version RV sequence.

10. The method according to claim 9, wherein: The RV sequence comes from at least one of the following: RRC signaling, and pre-configuration in the terminal device.

11. The method according to claim 5, wherein: The number of repetitions of the PUSCH in each PUSCH transmission set used for the random access is not less than the number of repetitions of the PUSCH in each PUSCH transmission set used for the previous random access; and / or The number of the one or more PUSCH transmission sets used for the random access is not less than the number of the one or more PUSCH transmission sets used for the previous random access.

12. The method according to claim 1 or 2, wherein: The request message is determined such that the size of a transport block TB carried in the PUSCH is scaled by a scaling factor relative to a reference size of the TB carried in the PUSCH.

13. The method according to claim 12, wherein: The reference size of the TB is determined based on a first product of: the number of resource elements RE available for carrying the TB, a modulation order for the TB, and a target code rate; and The size of the TB is determined based on a second product of the scaling factor and the first product.

14. The method according to claim 12, wherein: The scaling factor is derived from at least one of: RRC signaling; Pre-configuration in the terminal device; Selection from a set of preconfigured values ​​based on a channel quality estimate; and The determination is based on at least one of: preamble information, DMRS information, usage information, and frequency band information.

15. The method according to claim 1 or 2, wherein: The request message is determined based on an MCS table, the MCS table having a lower spectrum efficiency than a reference MCS table.

16. The method according to claim 15, wherein: The MCS table is a table obtained by adding one or more rows having lower spectrum efficiency to the reference MCS table.

17. The method according to claim 15, wherein: The MCS table is obtained by removing one or more rows having higher spectrum efficiency from the reference MCS table.

18. The method according to claim 15, wherein: The reference MCS table is a quadrature amplitude modulation QAM64 low spectral efficiency QAM64LowSE MCS table with a transform precoder enabled, or a QAM64LowSE MCS table with a transform precoder disabled.

19. The method according to claim 15, wherein: The MCS table is a table defined instead of the reference MCS table, or a table defined separately from the reference MCS table.

20. The method according to claim 1, wherein: which MCS table is to be used to determine if the request message is indicated via RRC signaling; or Which MCS table will be used to determine the request message is determined based on at least one of the following: preamble information, DMRS information, usage information, and frequency band information.

21. A method in a base station, comprising: receiving (802) a request message for random access, the request message comprising a preamble and one or more physical uplink shared channels PUSCH; as well as obtaining (804) the one or more PUSCHs from the request message, Wherein, PI / 2 binary phase shift keying BPSK is preconfigured to be disabled in the base station for the request message.

22. The method according to claim 21, wherein: A fixed modulation and coding scheme (MCS) table is preconfigured for obtaining the one or more PUSCHs in the base station.

23. The method according to claim 21 or 22, wherein: The number of the one or more PUSCHs is more than one, and the more than one PUSCHs are multiple repetitions of a PUSCH.

24. The method according to claim 23, wherein: The multiple repetitions of the PUSCH are divided into one or more PUSCH transmission sets.

25. The method according to claim 23, wherein: The random access is initiated due to failure of a previous random access; and The number of the multiple repetitions of the PUSCH used for the random access is not less than the number of the multiple repetitions of the PUSCH used for the previous random access.

26. The method of claim 23, wherein: Each repetition of the PUSCH is associated with the preamble.

27. The method according to claim 23, wherein: The number of the plurality of repetitions of the PUSCH is one of: Sent in Radio Resource Control (RRC) signaling; preconfigured in the base station; and The information is determined based on at least one of the following: preamble information, demodulation reference signal DMRS information, usage information, and frequency band information.

28. The method of claim 23, wherein: The preamble and the respective repetitions of the PUSCH are time division multiplexed and / or frequency division multiplexed.

29. The method of claim 23, wherein: Each repetition of the PUSCH uses a corresponding RV in a redundancy version RV sequence.

30. The method of claim 29, wherein: The RV sequence is sent in RRC signaling or is preconfigured in the base station.

31. The method of claim 25, wherein: The number of repetitions of the PUSCH in each PUSCH transmission set used for the random access is not less than the number of repetitions of the PUSCH in each PUSCH transmission set used for the previous random access; and / or The number of the one or more PUSCH transmission sets used for the random access is not less than the number of the one or more PUSCH transmission sets used for the previous random access.

32. The method according to claim 21 or 22, wherein: The size of a transport block TB carried in a PUSCH is scaled by a scaling factor relative to a reference size of the TB carried in the PUSCH.

33. The method of claim 32, wherein: The reference size of the TB is determined based on a first product of: the number of resource elements RE available for carrying the TB, a modulation order for the TB, and a target code rate; and The size of the TB is determined based on a second product of the scaling factor and the first product.

34. The method of claim 32, wherein: The scaling factor is one of: Sent in RRC signaling; preconfigured in the base station; blindly detected from a preconfigured set of values; and Determined based on at least one of: preamble information, DMRS information, usage information, and frequency band information.

35. The method according to claim 21 or 22, wherein: The one or more PUSCHs are obtained based on an MCS table, the MCS table having a lower spectral efficiency than a reference MCS table.

36. The method of claim 35, wherein: The MCS table is a table obtained by adding one or more rows having lower spectrum efficiency to the reference MCS table.

37. The method of claim 35, wherein: The MCS table is obtained by removing one or more rows having higher spectrum efficiency from the reference MCS table.

38. The method of claim 35, wherein: The reference MCS table is a quadrature amplitude modulation QAM64 low spectral efficiency QAM64LowSE MCS table with a transform precoder enabled, or a QAM64LowSE MCS table with a transform precoder disabled.

39. The method of claim 35, wherein: The MCS table is a table defined instead of the reference MCS table, or a table defined separately from the reference MCS table.

40. The method of claim 21, wherein: which MCS table is to be used to obtain the one or more PUSCHs to be sent in RRC signaling; or Which MCS table is to be used to obtain the one or more PUSCHs is determined based on at least one of the following: preamble information, DMRS information, usage information, and frequency band information.

41. A terminal device (900), comprising: at least one processor (910); as well as at least one memory (920), the at least one memory (920) containing instructions executable by the at least one processor (910), whereby the terminal device (900) is operable to: determining a request message for random access, the request message comprising a preamble and one or more physical uplink shared channels (PUSCH); and Sending the request message, Wherein, PI / 2 binary phase shift keying BPSK is preconfigured to be disabled in the terminal device for the request message.

42. The terminal device (900) according to claim 41, wherein: The terminal device (900) is operable to perform the method according to any one of claims 2 to 20.

43. A base station (900), comprising: at least one processor (910); as well as at least one memory (920) containing instructions executable by the at least one processor (910), whereby the base station (900) is operable to: receiving a request message for random access, the request message comprising a preamble and one or more physical uplink shared channels (PUSCH); and obtaining the one or more PUSCHs from the request message, Wherein, PI / 2 binary phase shift keying BPSK is preconfigured to be disabled in the base station for the request message.

44. The base station (900) of claim 43, wherein: The base station (900) is operable to perform a method according to any one of claims 22 to 40.

45. A method implemented in a communication system including a base station and at least one terminal device, comprising: At the at least one terminal device, determining (702) a request message for random access, the request message comprising a preamble and one or more physical uplink shared channels, PUSCH; At the at least one terminal device, sending (704) the request message; At the base station, receiving (802) the request message for random access, the request message including the preamble and the one or more PUSCHs; as well as At the base station, obtaining (804) the one or more PUSCHs from the request message, The PI / 2 binary phase shift keying BPSK is preconfigured to be disabled for the request message in the terminal device, and the PI / 2 binary phase shift keying BPSK is preconfigured to be disabled for the request message in the base station.

46. ​​A communication system comprising: At least one terminal device is configured to determine a request message for random access and send the request message, wherein the request message includes a preamble and one or more physical uplink shared channels PUSCH; as well as a base station, configured to receive the request message for random access and obtain the one or more PUSCHs from the request message, wherein the request message includes the preamble and the one or more PUSCHs, The PI / 2 binary phase shift keying BPSK is preconfigured to be disabled for the request message in the terminal device, and the PI / 2 binary phase shift keying BPSK is preconfigured to be disabled for the request message in the base station.

47. A computer readable storage medium comprising instructions which, when executed by at least one processor, cause the at least one processor to perform the method of any one of claims 1 to 40.

Images