Method and apparatus for determining a radio network temporary identity in a two-step random access procedure

Abstract

Various embodiments of the present disclosure provide methods and apparatus for determining a radio network temporary identifier (RNTI) in a two-step random access procedure. A method of a terminal device includes: determining a request message for random access, wherein the request message includes a preamble and a physical uplink shared channel (PUSCH) message, and the PUSCH message is determined based on a first radio network temporary identifier (RNTI); transmitting the request message; and obtaining a response message for random access based on a second RNTI, wherein the first RNTI and the second RNTI are the same or different.

Description

Technical Field

[0001] The present disclosure relates generally to wireless communications and, more particularly, to methods and apparatus for a two-step random access procedure. Background Art

[0002] This section introduces various aspects that may help to better understand the present disclosure. Therefore, the statements in this section should be read in this light, and should not be understood as an admission about what is or is not in the prior art.

[0003] In New Radio (NR) systems, such as Figure 1 As shown, a four-step method can be used for a random access procedure. In this method, a user equipment (UE) detects synchronization signals (SS) including NR-primary synchronization signal (NR-PSS), NR-secondary synchronization signal (NR-SSS) and NR-physical broadcast channel (PBCH) and decodes broadcast system information (e.g., remaining minimum system information (RMSI)). The UE can then transmit a physical random access channel (PRACH) preamble (message 1) in an uplink (UL). In response to receiving message 1, a base station (e.g., a next generation Node B (gNB)) replies with a random access response (RAR, message 2). The RAR message is octet-aligned and includes a timing advance command, an UL grant, and a temporary cell radio network temporary identifier (TC-RNTI).

[0004] After receiving the RAR message, the UE may transmit message 3 including the UE identity and the transport block on the physical uplink shared channel (PUSCH). The gNB then replies with a contention resolution message (message 4). The timing advance command in the RAR message allows the message 3 PUSCH to be received with a timing accuracy within the cyclic prefix (CP). Unless the system is applied in a cell with a very small distance between the UE and the gNB, without this timing advance, a very large CP would be required to be able to demodulate and detect the PUSCH. Since NR will also support larger cells where timing advance needs to be provided to the UE, a four-step approach is required for the random access procedure.

[0005] Message 3 PUSCH is scheduled by the UL grant in the RAR message. Retransmissions of transport blocks in Message 3 PUSCH (if any) are scheduled by DCI format 0_0 with a cyclic redundancy check (CRC) scrambled by the TC-RNTI provided in the RAR message. The UE always transmits Message 3 PUSCH without using repetitions.

[0006] In 3GPP TS 38.321 v 15.4.0, the disclosure of which is incorporated herein by reference in its entirety, Table 1 is provided to define the range of RNTI values ​​as follows.

[0007] Table 1

[0008]

[0009] The two-step random access procedure has been approved as a work item for NR Release 16. Figure 2 As shown, the initial access is done in only two steps. In the first step, the UE transmits a message, which may be referred to as message A, which includes a random access preamble and higher layer data, such as a radio resource control (RRC) connection request, possibly with some small payload on the PUSCH. In the second step, the gNB transmits a response message to the UE, which may be referred to as message B, which includes, for example, UE identity allocation, timing advance information, conflict resolution messages, etc. Message B is a response message, which is carried in a physical downlink shared channel (PDSCH) scheduled by a physical downlink control channel (PDCCH) with a CRC scrambled by a certain RNTI. Summary of the invention

[0010] This Summary is provided in a simplified form to introduce selected concepts 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.

[0011] The present disclosure proposes a solution for determining RNTI in a two-step random access procedure.

[0012] According to a first aspect of the present disclosure, a method at a terminal device is provided. The method includes determining a request message for random access, wherein the request message includes a preamble and a physical uplink shared channel (PUSCH) message, and the PUSCH message is determined based on a first radio network temporary identifier (RNTI). The method also includes transmitting the request message.

[0013] According to an exemplary embodiment, the method further comprises: obtaining a response message for random access based on the second RNTI, wherein the first RNTI and the second RNTI are the same.

[0014] According to an exemplary embodiment, the method further comprises: obtaining a response message for random access based on the second RNTI, wherein the first RNTI and the second RNTI are different.

[0015] According to an exemplary embodiment, the second RNTI is determined based on a Radio Resource Control, RRC, state of the terminal device.

[0016] According to an exemplary embodiment, the RRC state includes: a connected mode.

[0017] According to an exemplary embodiment, if a Cell-RNTI (C-RNTI) is available, the C-RNTI is determined as the second RNTI.

[0018] According to an exemplary embodiment, the first RNTI is used to scramble coded bits of a PUSCH message.

[0019] According to an exemplary embodiment, the second RNTI is determined based on the first RNTI.

[0020] According to an exemplary embodiment, the first RNTI and / or the second RNTI is determined based on: a number of a set of Physical Random Access Channel PRACH opportunities.

[0021] According to an exemplary embodiment, the set of RNTI values ​​is determined based on the timing / frequency resources of the request message.

[0022] According to a second aspect of the present disclosure, a method at a network node is provided. The method includes: determining a response message based on a second RNTI. The method also includes transmitting the response message to a terminal device.

[0023] According to an exemplary embodiment, the method further comprises: obtaining a request message including a preamble and a physical uplink shared channel (PUSCH) message from a terminal device based on a first radio network temporary identifier (RNTI); wherein the first RNTI and the second RNTI are the same.

[0024] According to an exemplary embodiment, the method further comprises obtaining a request message including a preamble and a physical uplink shared channel (PUSCH) message from the terminal device based on a first radio network temporary identifier (RNTI); wherein the first RNTI and the second RNTI are different.

[0025] According to an exemplary embodiment, the second RNTI is determined based on a Radio Resource Control, RRC, state of the terminal device.

[0026] According to an exemplary embodiment, the RRC state includes: a connected mode.

[0027] According to an exemplary embodiment, if a Cell-RNTI (C-RNTI) is available, the C-RNTI is determined as the second RNTI.

[0028] According to an exemplary embodiment, the first RNTI is used to scramble coded bits of a PUSCH message.

[0029] According to an exemplary embodiment, the second RNTI is determined based on the first RNTI.

[0030] According to an exemplary embodiment, the first RNTI and / or the second RNTI is determined based on: a number of a set of Physical Random Access Channel PRACH opportunities.

[0031] According to an exemplary embodiment, the set of RNTI values ​​is determined based on the timing / frequency resources of the request message.

[0032] According to a third aspect of the present disclosure, a terminal device is provided. The terminal device comprises: a non-transitory computer-readable medium having computer-executable instructions stored thereon; and a processor coupled to the non-transitory computer-readable medium, wherein the computer-executable instructions enable the terminal device to implement the method according to the first aspect of the present disclosure.

[0033] According to a fourth aspect of the present disclosure, a network node is provided, comprising: a non-transitory computer-readable medium having computer-executable instructions stored thereon; and a processor coupled to the non-transitory computer-readable medium, wherein the computer-executable instructions enable the network node to implement the method according to the second aspect of the present disclosure.

[0034] According to a fifth aspect of the present disclosure, a method at a terminal device is provided. The method includes determining a request message for random access, wherein the request message includes a preamble and a physical uplink shared channel (PUSCH) message, and the PUSCH message is determined based on a first radio network temporary identifier (RNTI). The method also includes transmitting the request message.

[0035] According to an exemplary embodiment, the method further includes: obtaining a response message for random access based on the second RNTI, wherein the first RNTI and the second RNTI are the same or different.

[0036] According to an exemplary embodiment, the first RNTI and / or the second RNTI is determined based on a Radio Resource Control RRC state of the terminal device.

[0037] According to an exemplary embodiment, the RRC state includes: idle mode, connected mode, inactive mode.

[0038] According to an exemplary embodiment, if a cell-RNTI (C-RNTI) is available, the C-RNTI is determined as the first RNTI and / or the second RNTI.

[0039] According to an exemplary embodiment, if a Cell-RNTI (C-RNTI) is unavailable, a Configured Scheduling-RNTI (CS-RNTI) is determined as the first RNTI and / or the second RNTI.

[0040] According to an exemplary embodiment, the first RNTI and / or the second RNTI is determined by selecting a CS-RNTI from a plurality of CS-RNTIs in the broadcasted system information.

[0041] According to an exemplary embodiment, the CS-RNTI is randomly selected from a plurality of CS-RNTIs.

[0042] According to an exemplary embodiment, the CS-RNTI is selected based on at least one of: one or more indices of the preamble code, one or more physical random access channel PRACH opportunities, the format of the preamble code, PUSCH parameters, and the purpose of the radio access RA attempt of the terminal device.

[0043] According to an exemplary embodiment, the first RNTI is used to scramble coded bits of a PUSCH message.

[0044] According to an exemplary embodiment, the second RNTI is determined based on the first RNTI.

[0045] According to an exemplary embodiment, the first RNTI and / or the second RNTI is determined based on at least one of the following and based on the number of RNTI values ​​in a set of RNTI values: the number of a set of physical random access channel PRACH opportunities, the number of a set of preamble codes, the number of a set of PUSCH opportunities, and a set of RNTI values.

[0046] According to an exemplary embodiment, the numbering of RNTI values ​​is arranged based on at least one of: the order of indices of preamble codes associated with RNTI values ​​in PRACH opportunities; the order of frequency resource indices of PRACH opportunities associated with RNTI values; the order of time resource indices of PRACH opportunities associated with RNTI values; the order of indices for PRACH time slots associated with RNTI values.

[0047] According to an exemplary embodiment, the set of RNTI values ​​is determined based on at least one of: the frequency band used, the time gap between the first preamble and the PUSCH, the timing / frequency resources of the request message, and the ID of the terminal device.

[0048] According to a sixth aspect of the present disclosure, a method at a terminal device is provided. The method includes determining a request message for random access, wherein the request message includes a preamble and a physical uplink shared channel (PUSCH) message, and the PUSCH message is determined based on an identification ID of a cell in which the terminal device is located. The method also includes transmitting the request message.

[0049] According to an exemplary embodiment, the method further comprises obtaining (310) a response message for random access based on a second RNTI, wherein the second RNTI is determined based on an ID of the terminal device.

[0050] According to a seventh aspect of the present disclosure, a method at a network node is provided. The method includes: determining a response message based on a second RNTI. The method also includes transmitting the response message to a terminal device.

[0051] According to an exemplary embodiment, the method further comprises obtaining a request message including a preamble and a physical uplink shared channel (PUSCH) message from a terminal device based on a first radio network temporary identifier (RNTI); wherein the first RNTI and the second RNTI are the same or different.

[0052] According to an exemplary embodiment, the first RNTI and / or the second RNTI is determined based on a Radio Resource Control RRC state of the terminal device.

[0053] According to an exemplary embodiment, the RRC state includes: idle mode, connected mode, and inactive mode.

[0054] According to an exemplary embodiment, if a cell-RNTI (C-RNTI) is available, the C-RNTI is determined as the first RNTI and / or the second RNTI.

[0055] According to an exemplary embodiment, if a Cell-RNTI (C-RNTI) is unavailable, a Configured Scheduling-RNTI (CS-RNTI) is determined as the first RNTI and / or the second RNTI.

[0056] According to an exemplary embodiment, the first RNTI and / or the second RNTI is determined by selecting a CS-RNTI from a plurality of CS-RNTIs in the broadcasted system information.

[0057] According to an exemplary embodiment, the CS-RNTI is randomly selected from a plurality of CS-RNTIs.

[0058] According to an exemplary embodiment, the CS-RNTI is selected based on at least one of: one or more indices of the preamble code, one or more physical random access channel PRACH opportunities, the format of the preamble code, PUSCH parameters, and the purpose of the radio access RA attempt of the terminal device.

[0059] According to an exemplary embodiment, the first RNTI is used to scramble coded bits of a PUSCH message.

[0060] According to an exemplary embodiment, the second RNTI is determined based on the first RNTI.

[0061] According to an exemplary embodiment, the method further comprises: obtaining a request message including a preamble and a PUSCH message from the terminal device based on an identification ID of a cell in which the terminal device is located.

[0062] According to an exemplary embodiment, the first RNTI and / or the second RNTI is determined based on an ID of the terminal device.

[0063] According to an exemplary embodiment, the first RNTI and / or the second RNTI is determined based on at least one of the following and based on the number of RNTI values ​​in a set of RNTI values: the number of a set of physical random access channel PRACH opportunities, the number of a set of preamble codes, the number of a set of PUSCH opportunities, and a set of RNTI values.

[0064] According to an exemplary embodiment, the numbering of RNTI values ​​is arranged based on at least one of: the order of indices of preamble codes associated with RNTI values ​​in PRACH opportunities; the order of frequency resource indices of PRACH opportunities associated with RNTI values; the order of time resource indices of PRACH opportunities associated with RNTI values; the order of indices for PRACH time slots associated with RNTI values.

[0065] According to an exemplary embodiment, the set of RNTI values ​​is determined based on at least one of: the frequency band used, the time gap between the first preamble and the PUSCH, the timing / frequency resources of the request message, and the ID of the terminal device.

[0066] According to an eighth aspect of the present disclosure, a terminal device is provided. The terminal device comprises: a non-transitory computer-readable medium on which computer-executable instructions are stored; and a processor coupled to the non-transitory computer-readable medium, wherein the computer-executable instructions enable the terminal device to implement the method according to the fifth aspect of the present disclosure.

[0067] According to a ninth aspect of the present disclosure, a network node is provided, comprising: a non-transitory computer-readable medium on which computer-executable instructions are stored; and a processor coupled to the non-transitory computer-readable medium, wherein the computer-executable instructions enable the network node to implement a method according to the seventh aspect of the present disclosure.

[0068] According to a tenth aspect of the present disclosure, a method at a terminal device is provided. The method includes obtaining a response message for random access based on a second radio network temporary identifier RNTI, wherein the response message is a response to a request message for random access, and the request message includes a preamble and a physical uplink shared channel PUSCH message.

[0069] According to an exemplary embodiment, the PUSCH message is determined based on the first RNTI, and the first RNTI and the second RNTI are the same or different.

[0070] According to an exemplary embodiment, the first RNTI and / or the second RNTI is determined based on a Radio Resource Control RRC state of the terminal device.

[0071] According to an exemplary embodiment, the RRC state includes: idle mode, connected mode, inactive mode.

[0072] According to an exemplary embodiment, if a cell-RNTI (C-RNTI) is available, the C-RNTI is determined as the first RNTI and / or the second RNTI.

[0073] According to an exemplary embodiment, if a Cell-RNTI (C-RNTI) is unavailable, a Configured Scheduling-RNTI (CS-RNTI) is determined as the first RNTI and / or the second RNTI.

[0074] According to an exemplary embodiment, the first RNTI and / or the second RNTI is determined by selecting a CS-RNTI from a plurality of CS-RNTIs in the broadcasted system information.

[0075] According to an exemplary embodiment, the CS-RNTI is randomly selected from a plurality of CS-RNTIs.

[0076] According to an exemplary embodiment, the CS-RNTI is selected based on at least one of: one or more indices of the preamble code, one or more physical random access channel PRACH opportunities, the format of the preamble code, PUSCH parameters, and the purpose of the radio access RA attempt of the terminal device.

[0077] According to an exemplary embodiment, the first RNTI is used to scramble coded bits of a PUSCH message.

[0078] According to an exemplary embodiment, the second RNTI is determined based on the first RNTI.

[0079] According to an exemplary embodiment, the method further comprises: determining a request message including a preamble and a PUSCH message based on an identification ID of a cell in which the terminal device is located.

[0080] According to an exemplary embodiment, the first RNTI and / or the second RNTI is determined based on an ID of the terminal device.

[0081] According to an exemplary embodiment, the first RNTI and / or the second RNTI is determined based on at least one of the following and based on the number of RNTI values ​​in a set of RNTI values: the number of a set of physical random access channel PRACH opportunities, the number of a set of preamble codes, the number of a set of PUSCH opportunities, and a set of RNTI values.

[0082] According to an exemplary embodiment, the numbering of RNTI values ​​is arranged based on at least one of: the order of indices of preamble codes associated with RNTI values ​​in PRACH opportunities; the order of frequency resource indices of PRACH opportunities associated with RNTI values; the order of time resource indices of PRACH opportunities associated with RNTI values; the order of indices for PRACH time slots associated with RNTI values.

[0083] According to an exemplary embodiment, the set of RNTI values ​​is determined based on at least one of: the frequency band used, the time gap between the first preamble and the PUSCH, the timing / frequency resources of the request message, and the ID of the terminal device.

[0084] According to an eleventh aspect of the present disclosure, a method at a network node is provided, wherein the method comprises obtaining a request message including a preamble and a physical uplink shared channel (PUSCH) message from a terminal device based on a first radio network temporary identifier (RNTI).

[0085] According to an exemplary embodiment, the method further comprises determining a response message based on the second RNTI.The method further comprises transmitting the response message to the terminal device.

[0086] According to an exemplary embodiment, the first RNTI and / or the second RNTI is determined based on a Radio Resource Control RRC state of the terminal device.

[0087] According to an exemplary embodiment, the RRC state includes: idle mode, connected mode, inactive mode.

[0088] According to an exemplary embodiment, if a cell-RNTI (C-RNTI) is available, the C-RNTI is determined as the first RNTI and / or the second RNTI.

[0089] According to an exemplary embodiment, if a Cell-RNTI (C-RNTI) is unavailable, a Configured Scheduling-RNTI (CS-RNTI) is determined as the first RNTI and / or the second RNTI.

[0090] According to an exemplary embodiment, the first RNTI and / or the second RNTI is determined by selecting a CS-RNTI from a plurality of CS-RNTIs in the broadcasted system information.

[0091] According to an exemplary embodiment, the CS-RNTI is randomly selected from a plurality of CS-RNTIs.

[0092] According to an exemplary embodiment, the CS-RNTI is selected based on at least one of: one or more indices of the preamble code, one or more physical random access channel PRACH opportunities, the format of the preamble code, PUSCH parameters, and the purpose of the radio access RA attempt of the terminal device.

[0093] According to an exemplary embodiment, the first RNTI is used to scramble coded bits of a PUSCH message.

[0094] According to an exemplary embodiment, the second RNTI is determined based on the first RNTI.

[0095] According to an exemplary embodiment, the first RNTI and / or the second RNTI is determined based on an ID of the terminal device.

[0096] According to an exemplary embodiment, the first RNTI and / or the second RNTI is determined based on at least one of the following and based on the number of RNTI values ​​in a set of RNTI values: the number of a set of physical random access channel PRACH opportunities, the number of a set of preamble codes, the number of a set of PUSCH opportunities, and a set of RNTI values.

[0097] According to an exemplary embodiment, the numbering of RNTI values ​​is arranged based on at least one of: the order of indices of preamble codes associated with RNTI values ​​in PRACH opportunities; the order of frequency resource indices of PRACH opportunities associated with RNTI values; the order of time resource indices of PRACH opportunities associated with RNTI values; the order of indices for PRACH time slots associated with RNTI values.

[0098] According to an exemplary embodiment, the set of RNTI values ​​is determined based on at least one of: the frequency band used, the time gap between the first preamble and the PUSCH, the timing / frequency resources of the request message, and the ID of the terminal device.

[0099] According to a twelfth aspect of the present disclosure, a method at a network node is provided, wherein the method comprises obtaining a request message including a preamble and a physical uplink shared channel (PUSCH) message from a terminal device based on a cell in which the terminal device is located.

[0100] According to an exemplary embodiment, the method further comprises: determining a response message based on the RNTI.The method further comprises transmitting the response message to the terminal device, wherein the RNTI is determined based on the ID of the terminal device.

[0101] According to the thirteenth aspect of the present disclosure, a terminal device is provided. The terminal device comprises: a non-transitory computer-readable medium on which computer-executable instructions are stored; and a processor coupled to the non-transitory computer-readable medium, wherein the computer-executable instructions enable the terminal device to implement the method according to the tenth aspect of the present disclosure.

[0102] According to a fourteenth aspect of the present disclosure, a network node is provided, comprising: a non-transitory computer-readable medium having computer-executable instructions stored thereon; and a processor coupled to the non-transitory computer-readable medium, wherein the computer-executable instructions enable the network node to implement the method according to the eleventh aspect of the present disclosure.

[0103] According to a fifteenth aspect of the present disclosure, a network node is provided, comprising: a non-transitory computer-readable medium having computer-executable instructions stored thereon; and a processor coupled to the non-transitory computer-readable medium, wherein the computer-executable instructions enable the network node to implement the method according to the twelfth aspect of the present disclosure.

[0104] According to a sixteenth aspect of the present disclosure, a terminal device is provided. The terminal device comprises: a non-transitory computer-readable medium on which computer-executable instructions are stored; and a processor coupled to the non-transitory computer-readable medium, wherein the computer-executable instructions enable the terminal device to implement the method according to the sixth aspect of the present disclosure.

[0105] According to the seventeenth aspect of the present disclosure, a non-transitory computer-readable medium is provided, on which program code for use with a computing device is stored, wherein the program code, when executed by a processor, executes a method according to any one of the first, second, fifth, sixth, seventh, tenth, eleventh and twelfth aspects of the present disclosure.

[0106] According to another aspect of the present disclosure, a method implemented in a communication system is provided, and the communication system may include a host computer, a base station, and a UE. The method may include: providing user data at the host computer. Optionally, the method may include: at the host computer, initiating a transmission carrying user data to the UE through a cellular network including a base station, and the base station may perform any steps of the method according to any of the second, seventh, eleventh, and twelfth aspects of the present disclosure.

[0107] According to another aspect of the present disclosure, a communication system including a host computer is provided. The host computer may include: a processing circuit configured to provide user data, and a communication interface configured to forward the user data to a cellular network for transmission to a UE. The cellular network may include: a base station having a radio interface and a processing circuit. The processing circuit of the base station may be configured to perform any steps of the method according to any of the second, seventh, eleventh and twelfth aspects of the present disclosure.

[0108] According to another aspect of the present disclosure, a method implemented in a communication system is provided, and the communication system may include a host computer, a base station, and a UE. The method may include: at the host computer, providing user data. Optionally, the method may include: at the host computer, initiating a transmission carrying user data to the UE through a cellular network including the base station. The UE may perform any steps of the method according to any of the first, fifth, sixth, and tenth aspects of the present disclosure.

[0109] According to another aspect of the present disclosure, a communication system including a host computer is provided. The host computer may include: a processing circuit configured to provide user data, and a communication interface configured to forward the user data to a cellular network for transmission to a UE. The UE may include a radio interface and a processing circuit. The processing circuit of the UE may be configured to perform any steps of the method according to any of the first, fifth, sixth and tenth aspects of the present disclosure.

[0110] According to another aspect of the present disclosure, a method implemented in a communication system is provided, the communication system may include a host computer, a base station and a UE. The method may include: at the host computer, receiving user data transmitted from the UE to the base station, the base station may perform any steps of the method according to any of the second, seventh, eleventh and twelfth aspects of the present disclosure.

[0111] According to another aspect of the present disclosure, a communication system including a host computer is provided. The host computer may include a communication interface configured to receive user data originating from a transmission from a UE to a base station. The UE may include a radio interface and a processing circuit. The processing circuit of the UE may be configured to perform any steps of the method according to any one of the first, fifth, sixth and tenth aspects of the present disclosure.

[0112] According to another aspect of the present disclosure, a method implemented in a communication system is provided, which may include a host computer, a base station and a UE. The method may include: at the host computer, receiving from the base station user data originating from a transmission that the base station has received from the UE. The base station may perform any steps of the method according to any of the second, seventh, eleventh and twelfth aspects of the present disclosure.

[0113] According to another aspect of the present disclosure, a communication system is provided, which may include a host computer. The host computer may include a communication interface configured to receive user data originating from a transmission from a UE 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 perform any steps of the method according to any one of the second, seventh, eleventh and twelfth aspects of the present disclosure.

[0114] According to another aspect of the present disclosure, a terminal device is provided. The terminal device includes: a determining unit, configured to determine a request message for random access, wherein the request message includes a preamble and a physical uplink shared channel (PUSCH) message, and the PUSCH message is determined based on a first radio network temporary identifier (RNTI); and a transmitting unit, configured to transmit (308) the request message.

[0115] According to another aspect of the present disclosure, a terminal device is provided. The terminal device includes: a determination unit, which is used to determine a request message for random access, wherein the request message includes a preamble code and a physical uplink shared channel PUSCH message, and the PUSCH message is determined based on an identification ID of a cell where the terminal device is located, and a transmission unit, which is used to transmit the request message.

[0116] According to another aspect of the present disclosure, a network node is provided. The network node includes: a determining unit, configured to determine a response message based on a second RNTI; and transmit the response message to a terminal device.

[0117] According to another aspect of the present disclosure, a terminal device is provided. The terminal device includes: a determination unit, which is used to obtain a response message for random access based on a second radio network temporary identifier RNTI, wherein the response message is a response to a request message for random access, and the request message includes a preamble code and a physical uplink shared channel PUSCH message.

[0118] According to another aspect of the present disclosure, a network node is provided. The network node comprises: an obtaining unit, which is configured to obtain a request message including a preamble and a physical uplink shared channel (PUSCH) message from a terminal device based on a first radio network temporary identifier (RNTI).

[0119] According to another aspect of the present disclosure, a network node is provided. The network node comprises: an obtaining unit, which is used to obtain a request message including a preamble and a physical uplink shared channel (PUSCH) message from a terminal device based on a cell where the terminal device is located. BRIEF DESCRIPTION OF THE DRAWINGS

[0120] The present disclosure itself, preferred modes of use and further objects may best be understood by reference to the following detailed description of embodiments when read in conjunction with the accompanying drawings, in which:

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

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

[0123] Figure 3 is a flow chart illustrating a method 300 according to some embodiments described throughout this disclosure;

[0124] Figure 4 is a flow chart illustrating a method 400 according to some embodiments described throughout this disclosure;

[0125] Figure 5 is a flow chart illustrating a method 500 according to some embodiments described throughout this disclosure;

[0126] Figure 6 is an example showing RNTI ordering in the time and frequency domains at different PRACH opportunities;

[0127] Figure 7 is a diagram showing 64 preamble indexes used in each of two frequency-reused PRACH opportunities;

[0128] Figure 8 is a flowchart illustrating a method 800 according to some embodiments described throughout this disclosure;

[0129] Fig. 9 is a block diagram illustrating a terminal device 900 according to some embodiments described throughout this disclosure; and

[0130] Fig.10 is a block diagram illustrating a network node 1000 according to some embodiments described throughout this disclosure.

[0131] Fig.11 is a block diagram illustrating a telecommunications network connected to a host computer via an intermediary network according to some embodiments of the present disclosure;

[0132] Fig.12 is a block diagram illustrating a host computer communicating with a UE through a base station via a partial wireless connection according to some embodiments of the present disclosure;

[0133] Fig.13 is a flow chart showing a method implemented in a communication system according to an embodiment of the present disclosure;

[0134] Fig.14 is a flow chart showing a method implemented in a communication system according to an embodiment of the present disclosure;

[0135] Fig.15 is a flowchart illustrating a method implemented in a communication system according to an embodiment of the present disclosure; and

[0136] Fig.16 is a flow chart illustrating a method implemented in a communication system according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0137] Embodiments of the present disclosure are described in detail with reference to the accompanying drawings. It should be understood that these embodiments are discussed only for the purpose of enabling those skilled in the art to better understand and thus realize the present disclosure, rather than suggesting any limitation on the scope of the present disclosure. References to features, advantages or similar language throughout the specification do not mean that all features and advantages that can be implemented with the present disclosure should be in or in any single embodiment of the present disclosure. On the contrary, the language referring to features and advantages should be understood to mean that specific features, advantages or characteristics described in conjunction with the embodiments are included in at least one embodiment of the present disclosure. In addition, in one or more embodiments, the features, advantages and characteristics described in the present disclosure may be combined in any suitable manner. Those skilled in the relevant art will recognize that the present disclosure may be practiced without one or more of the specific features or advantages of a particular embodiment. In other cases, additional features and advantages may be recognized in certain embodiments, and the additional features and advantages may not exist in all embodiments of the present disclosure.

[0138] As used herein, the term "communication network" refers to a network that complies with any appropriate communication standard, such as New Radio (NR), Long Term Evolution (LTE), Advanced LTE, Wideband Code Division Multiple Access (WCDMA), High Speed ​​Packet Access (HSPA), etc. In addition, communication between terminal devices and network nodes in the communication network can be performed according to any suitable communication protocols of various generations and / or any other protocols currently known or to be developed in the future, including but not limited to first generation (1G), second generation (2G), 2.5G, 2.75G, third generation (3G), 4G, 4.5G, 5G communication protocols.

[0139] The term "network node" refers to a network device in a communication network, through which a terminal device accesses the network and receives services from the network. A network node or network device may refer to a base station (BS), an access point (AP), a multi-cell / multicast coordination entity (MCE), a controller, or any other suitable device in a wireless communication network. A BS may be, for example, a Node B (NodeB or NB), an evolved NodeB (eNodeB or eNB), a next generation NodeB (gNodeB or gNB), an IAB node, a remote radio unit (RRU), a radio head (RH), a remote radio head (RRH), a repeater, a low power node (such as a femto base station, a pico base station), etc.

[0140] Yet another example of a network node includes a multi-standard radio (MSR) radio device (such as an MSR BS), a network controller such as a radio network controller (RNC) or a base station controller (BSC), a base transceiver station (BTS), a transmission point, a transmission node, a positioning node, etc. However, more generally, a network node may represent any suitable device (or group of devices) that is capable of, configured, arranged and / or operable to enable a terminal device to access a wireless communication network and / or to provide a terminal device with access to a wireless communication network or to provide a certain service to a terminal device that has accessed the wireless communication network.

[0141] The term "terminal device" refers to any terminal device that can access a communication network and receive services therefrom. As an example and not limitation, a terminal device may refer to a mobile terminal, a user equipment (UE), or other suitable device. A UE may be, for example, a subscriber station, a portable subscriber station, a mobile station (MS), or an access terminal (AT). A terminal device may include, but is not limited to, 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), a vehicle, etc.

[0142] As another specific example, in an Internet of Things (IoT) scenario, a terminal device may also be referred to as an IoT device, and may represent a machine or other device that performs monitoring, sensing and / or measurement, etc., and sends the results of such monitoring, sensing and / or measurement, etc. to another terminal device and / or network device. In this case, the terminal device may be a machine-to-machine (M2M) device, which may be referred to as a machine type communication (MTC) device in the context of the Third Generation Partnership Project (3GPP).

[0143] As a specific example, the terminal device may be a UE implementing the 3GPP Narrowband Internet of Things (NB-IoT) standard. Specific examples of such machines or devices are sensors, metering devices such as power meters, industrial machinery, or household or personal appliances such as refrigerators, televisions, personal wearable devices (such as watches), etc. In other cases, the terminal device may represent a vehicle or other equipment, such as a medical device capable of monitoring, sensing and / or reporting its operating status or other functions related to its operation.

[0144] As used herein, the terms "first", "second", etc. refer to different elements. Unless the context clearly indicates otherwise, the singular forms "one" and "an" are also intended to include the plural forms. As used herein, the terms "include", "comprise", "have", "have", "contain" and / or "cover" specify the presence of the features, elements and / or components, etc., but do not exclude the presence or addition of one or more other features, elements, components and / or combinations thereof. The term "based on" should be understood as "based at least in part on". The terms "one embodiment" and "embodiment" should be understood as "at least one embodiment". The term "another embodiment" should be understood as "at least one other embodiment". Other definitions (both explicit and implicit) may be included below.

[0145] As mentioned above, in Figure 2 In the two-step random access procedure shown, the preamble and PUSCH message will be transmitted by the UE in one message, referred to as message A, before the UE receives a response message, referred to as message B, from the gNB. However, for the PUSCH message in message A, no TC-RNTI is available for PUSCH processing since no RAR message is received from the gNB. In addition, in message A, for each preamble, especially when more than one PUSCH is on the same timing frequency resource, different RNTI values ​​for PUSCH may be required to avoid collision of PUSCHs between different messages A. In addition, in order to distinguish between message 2 in the four-step random access procedure and message B in the two-step random access procedure, different RNTIs need to be used. Therefore, a solution needs to be provided for determining the RNTI in the two-step random access procedure, which RNTI is used for PUSCH in message A and / or PDCCH CRC scrambling and PDSCH scrambling in message B.

[0146] According to some exemplary embodiments described throughout the present disclosure, the present disclosure provides an improved solution for a two-step random access procedure. These solutions can be applied to a wireless communication system including a terminal device and a base station. In the two-step random access procedure, the terminal device can determine the RNTI to be used for the PUSCH in the request message (e.g., message A) based on the broadcasted system information, and then the terminal device can transmit the request message based on the determined RNTI. Using the improved solution, an RNTI can be determined, which is used for PUSCH in message A and / or PDCCH CRC scrambling and PDSCH scrambling in message B.

[0147] Note that some embodiments of the present disclosure are primarily described with respect to the 5G specification used as non-limiting examples of certain exemplary network configurations and system deployments. Therefore, the description of the exemplary embodiments given herein specifically references terms directly related thereto. Such terms are used only in the context of the non-limiting examples and embodiments presented and do not inherently limit the present disclosure in any way. On the contrary, any other system configuration or radio technology may be used equally as long as the exemplary embodiments described herein are applicable.

[0148] Figure 3 is a flow chart illustrating a method 300 according to some embodiments described throughout this disclosure. Figure 3 The method 300 shown may be performed by an apparatus implemented in a terminal device or an apparatus communicatively coupled to the terminal device. According to an exemplary embodiment, the terminal device may be a UE.

[0149] according to Figure 3 In the exemplary method 300 shown, as shown in block 302, a terminal device may determine a preamble for a request message for a two-step random access procedure. In some embodiments, the preamble may be determined based on a set of preambles. The set of preambles may be dedicated to the two-step random access procedure. Alternatively, the set of preambles may be the same as the set of preambles used for the four-step random access procedure. In some embodiments, the set of preambles may be signaled in a signaling message from a network node such as a base station (e.g., a gNB). The signaling message may be a radio resource control (RRC) message. Alternatively, in some embodiments, the set of preambles may be predefined in the terminal device.

[0150] In box 304, the terminal device may determine a first RNTI, which is used for a PUSCH message in a request message of a two-step random access procedure. The terminal device may determine the first RNTI by selecting one of the multiple RNTI values ​​in the broadcast system information. The broadcast system information includes remaining minimum system information (RMSI) or other system information (OSI). In some embodiments, multiple configured scheduling RNTIs (CS-RNTIs) are provided in the broadcast system information. Therefore, the terminal device may select one of the multiple CS-RNTIs in the broadcast system information as the first RNTI. In one embodiment, the terminal device may randomly select one of the multiple CS-RNTIs. In another embodiment, the terminal device may select one of the multiple CS-RNTIs based on at least one of the following: an index of a determined preamble, a physical random access channel (PRACH) timing of a determined preamble, a format of a determined preamble, a PUSCH parameter, and the purpose of a radio access (RA) attempt of the terminal device. In another embodiment, the terminal device may determine the first RNTI based on an identifier (ID) of a cell in which the terminal device is located.

[0151] After determining the RNTI in box 304, in box 306, the terminal device can generate a PUSCH message based on the determined first RNTI. Typically, the determined first RNTI is used to scramble the coded bits of the PUSCH message. The request message may include the preamble determined in box 302 and the PUSCH message. The preamble may be transmitted in a PRACH opportunity, and the PUSCH message may be transmitted in a PUSCH opportunity. Then, a request message including the preamble and the PUSCH message is determined. Then in box 308, the terminal device may transmit a request message (i.e., message A) in a two-step random access process to the network node.

[0152] As shown in box 310, in response to the transmission request message, the terminal device may obtain a response message (e.g., message B) from the network node based on the second RNTI. Specifically, the terminal device may use the second RNTI to receive a physical downlink control channel (PDCCH) message that schedules a physical downlink shared channel (PDSCH) carrying the response message. The second RNTI may be the same as or different from the first RNTI. In some embodiments, the second RNTI is generated based on the first RNTI. For example, the second RNTI may be formed as a function / mapping of the first RNTI used in message A. Specifically, the network node may use a hash or subset of the bits of the first RNTI used in message A. The function / mapping relationship between the first RNTI and the second RNTI allows the network node and the terminal device to effectively distinguish message B in the two-step random access process from message 2 in the four-step random access process. In some other embodiments, if the first RNTI is determined based on the ID of the cell in which the terminal device is located, the network node may use the cell ID of the terminal device carried in the message A PUSCH to determine the second RNTI, thereby scrambling the CRC of the PDCCH message for message B.

[0153] Figure 4 is a flow chart illustrating a method 400 according to some embodiments described throughout this disclosure. Figure 4 The method 400 shown may be performed by an apparatus implemented in a terminal device or an apparatus communicatively coupled to the terminal device. According to an exemplary embodiment, the terminal device may be a UE. Figure 4 In the description of the exemplary embodiment, for the parts that are the same as or similar to those in the aforementioned exemplary embodiment, the detailed description will be appropriately omitted.

[0154] according to Figure 4 In the exemplary method 400 shown, as shown in block 402, the terminal device may determine a preamble of a request message for a two-step random access procedure. In block 403, the terminal device may determine whether a C-RNTI is available. As shown in block 404, if the C-RNTI is available, the terminal device will use the C-RNTI itself as the first RNTI. For example, if the terminal device is in RRC connected mode and is used to perform contention-free random access (CFRA), it will have a C-RNTI. Therefore, the terminal device may use the C-RNTI as the first RNTI.

[0155] If the C-RNTI is not available, in box 405, the terminal device will select one of the multiple CS-RNTIs in the broadcast system information based on the preamble determined in box 402. For example, if the terminal device is in idle mode, it does not have a valid C-RNTI. Therefore, the terminal device can select a CS-RNTI as the first RNTI. The terminal device can select one of the multiple CS-RNTIs based on at least one of the following: the index of the determined preamble, the physical random access channel (PRACH) timing of the determined preamble, the format of the determined preamble, the PUSCH parameters, and the purpose of the radio access (RA) attempt of the terminal device. It should be noted that the CS-RNTI can have one or more RNTI values, which can be cell-specifically configured. The CS-RNTI value can be provided in the broadcast system information (for example, in the RMSI or OSI). The terminal device selects the actual CS-RNTI value to be used from the set of configured multiple values.

[0156] According to an exemplary embodiment, the RNTI may depend on the RRC state. The RRC state includes an idle mode, a connected mode, and an inactive mode. For example, if the terminal device is in an inactive mode and performs contention-based random access (CBRA), it may use a CS-RNTI, which is based on its C-RNTI, such as a function of certain bits in the C-RNTI. This reduces the complexity of blind decoding of the network node compared to experimentally detecting the C-RNTI of all inactive terminal devices in the system or tracking area. In one embodiment, if one or more UE attempts using the C-RNTI or a CS-RNTI based on the C-RNTI are unsuccessful, it may revert to the method where the UE does not possess the above-mentioned valid C-RNTI for subsequent attempts.

[0157] After determining the RNTI in box 404 or 405, in box 406, the terminal device may generate a PUSCH message based on the determined RNTI (i.e., the first RNTI). Typically, the determined RNTI is used to scramble the PUSCH payload of the request message (message A) in the two-step random access process. Then in box 408, the terminal device may transmit a request message (e.g., message A) to the network node in the two-step random access process. The request message may include the preamble determined in step 402 and the PUSCH message generated in step 406. In one embodiment, the network node detects the PUSCH message after detecting the preamble in the request message, and may receive the PUSCH message using the configuration information obtained through the preamble. In another embodiment, the network node may not need to detect the preamble in the request message (e.g., if the current transmission is a retransmission of the request message without retransmitting the preamble), and blindly decode the PUSCH message based on multiple possible CS-RNTI values.

[0158] As shown in box 410, in response to transmitting the request message, the terminal device may receive a response message (e.g., message B) based on another RNTI (i.e., a second RNTI) from the network node. The network node selects the second RNTI based on the received RNTI derived from the PUSCH message, and the second RNTI is used to scramble the CRC of the PDCCH message for message B in the two-step random access process. In this embodiment, the network node scrambles the CRC of the PDCCH message for message B using the RNTI (e.g., C-RNTI or CS-RNTI) used by the terminal device in the PUSCH message (message A). The network node detects the CS-RNTI based on the preamble of the received request message or based on blind detection of the PUSCH message of the request message. The RNTI then functionally becomes the new RA-RNTI for the given network node. Alternatively, the new RA-RNTI may be formed but not as a copy of the C-RNTI or CS-RNTI used in the request message but rather as a function / mapping of the C-RNTI or CS-RNTI used in the request message, for example using a hash or subset of the bits of the RNTI used in the request message to select the RA-RNTI from a set of possibilities.

[0159] Figure 5 is a flow chart illustrating a method 500 according to some embodiments described throughout this disclosure. Figure 5 The method 500 shown may be performed by an apparatus implemented in a terminal device or an apparatus communicatively coupled to the terminal device. According to an exemplary embodiment, the terminal device may be a UE.

[0160] according to Figure 5In the exemplary method 500 shown, as shown in block 502, the terminal device may select a first preamble from a set of preambles for a request message. The set of preambles may be specific to a two-step random access procedure. Alternatively, the set of preambles may be the same as the set of preambles used for a four-step random access procedure. In some embodiments, the set of preambles may be signaled in a signaling message from a network node such as a base station (e.g., a gNB). The signaling message may be an RRC message. Alternatively, in some embodiments, the set of preambles may be predefined in the terminal device.

[0161] In box 504, the terminal device can determine a first RNTI (which can be called TS-RNTI (two-step RNTI)) based on at least one of the following and based on the number of RNTI values ​​in the set of RNTI values: the number of a set of physical random access channel PRACH opportunities, the number of a set of preamble codes, the number of a set of PUSCH opportunities, and a set of RNTI values.

[0162] After determining the RNTI in box 504, in box 506, the terminal device can generate a PUSCH message based on the determined first RNTI. Typically, the determined first RNTI is used to scramble the coded bits of the PUSCH message. Then in box 508, the terminal device can transmit a request message (i.e., message A) to the network node in a two-step random access process. The request message may include the preamble determined in box 502 and the PUSCH message generated in box 506. The preamble can be transmitted in a PRACH opportunity, and the PUSCH message can be transmitted in a PUSCH opportunity. As shown in box 510, in response to transmitting the request message, the terminal device can receive a response message based on the second RNTI (e.g., message B) from the network node.

[0163] In some embodiments, the order of RNTI values ​​is arranged based on at least one of: the order of the index of the preamble code associated with the RNTI value in the PRACH opportunity; the order of the frequency resource index of the PRACH opportunity associated with the RNTI value; the order of the time resource index of the PRACH opportunity associated with the RNTI value; the order of the index of the PRACH time slot associated with the RNTI value. It should be noted that the first RNTI used in the two-step random access process is designed to be different from the RA-RNTI and therefore will not conflict with the RA-RNTI.

[0164] Figure 6is an example showing RNTI sorting in the time domain and frequency domain at different PRACH occasions. First, the order of RNTI values ​​is arranged based on the increasing order of the index of the preamble code in the PRACH opportunity (for example, the index of RNTI values ​​0, 1, 2 in PRACH opportunity OC1). Secondly, the order of RNTI values ​​is arranged based on the increasing order of the frequency resource index of the PRACH opportunity (for example, the index of RNTI values ​​3, 4, 5 in PRACH opportunity OC2; the frequency resource of PRACH opportunity OC2 is higher than the frequency resource of PRACH opportunity OC1). Thirdly, the order of RNTI values ​​is arranged based on the increasing order of the time resource index of the PRACH opportunity (for example, the index of RNTI values ​​6, 7, 8 in PRACH opportunity OC3; the time slot of PRACH opportunity OC3 is greater than the time slot of PRACH opportunity OC1). Fourth, the order of RNTI values ​​is arranged based on the increasing order of PRACH slot indexes (eg, RNTI values ​​0-11 are indexed in PRACH slot 1; RNTI values ​​12-23 are indexed in PRACH slot 2). Figure 6 is an example showing three indices of preambles (0-2) configured in each PRACH opportunity and the RNTI for the first 8 PRACH opportunities. It should be noted that the ordering may also be performed in any other specified order, such as frequency resources, time resources, preamble resources. The determined order may be predetermined or RRC configured. In this embodiment, the terminal device is able to calculate the RNTI when the selected preamble is transmitted. In the same embodiment, the network node may calculate the RNTI when the network node receives a specific preamble on a specific PRACH opportunity.

[0165] It is also possible to use only a subset of indices, such as an ordering based on the preamble index and the frequency index for frequency multiplexing PRACH. Figure 7This is shown in Figure 1, where 64 preamble indices (0-63) are used for each of the two frequency-reused PRACH opportunities. This gives 0-127 as possible first RNTIs. The PUSCH opportunities are also linked to the preamble and PRACH opportunities so that, for example, the first 32 indices in each PRACH opportunity are mapped to the PUSCH opportunity with the lower frequency index. In this embodiment, the indices of RNTI 0-63 are arranged in the first PRACH opportunity and the indices of RNTI 64-127 are arranged in the second PRACH opportunity. Then, message A (Msg A) transmitted in PUSCH opportunity 0 will be scrambled by the index of RNTI 0-31 depending on the selected preamble, MsgA transmitted in PUSCH opportunity 1 will be scrambled by the index of RNTI 32-63 depending on the selected preamble, MsgA transmitted in PUSCH opportunity 3 will be scrambled by the index of RNTI 64-95 depending on the selected preamble, and finally MsgA transmitted in PUSCH opportunity 3 will be scrambled by the index of RNTI 96-127 depending on the selected preamble.

[0166] In some embodiments, the set of RNTI values ​​is determined based on at least one of: the frequency band used, the time gap between the first preamble and the PUSCH, the timing / frequency resources of the request message, and the ID of the terminal device.

[0167] Regarding frequency bands such as in unlicensed frequency bands, RA-RNTI or modified RA-RNTI cannot be used for TS-RNTI because RA-RNTI may be unavailable when the network node is preparing PUSCH while waiting for LBT for transmission of the preamble in message A. Or in order to avoid the problem of RA-RNTI unavailability, RA-RNTI is always generated based on RO of, for example, the first LBT. In licensed frequency bands, TS-RNTI may be RA-RNTI or modified RA-RNTI, or a newly defined RNTI.

[0168] Regarding the time gap between the first preamble and the PUSCH, for example, when the interval is not less than a threshold, the RA-RNTI or modified RA-RNTI may be applied to both message A and message B transmissions in the two-step random access process, otherwise an RNTI independent of the RA-RNTI is used. The threshold may be predetermined or signaled in the RRC signaling, which is not limited here. In addition, the RNTI scrambled by message A may depend more directly on the time distance between the preamble and the PUSCH. The dependency may be based on the time in seconds between the preamble and the PUSCH, and / or based on the number of OFDM symbols and / or time slots, and / or based on the number of PRACH opportunities (in time and / or frequency) between the preamble and the PUSCH.

[0169] Regarding the timing / frequency resources of the request message, for message B, the RNTI is based on the timing / frequency of the corresponding transmission of message A. This is preferred, in particular, when message A PUSCHs from different terminal devices have different PUSCH timings, so that different terminal devices will use different RNTIs. In addition, if the time position of the preamble can be determined from the time position of the PUSCH (for example, if the configuration is such that the PUSCH follows the preamble immediately, or the time gap is less than a given threshold, see the previous section), the RNTI used for scrambling of message A can be independent of time, otherwise the RNTI used for scrambling of message A can be dependent on time. When / if the message A RNTI is independent of time, the message B RNTI may still be dependent on time. As a special case, the message A RNTI can be the same as the message B RNTI, except that the time dependency is omitted. The interval threshold mentioned above (also in the previous section) can be predetermined in the specification and / or explicitly or implicitly signaled by other signaling, such as the PRACH configuration index. As an alternative to the selection of scrambling based on the time gap threshold, the selection can be signaled.

[0170] Regarding the ID of the terminal device, the ID of the terminal device itself or a certain RNTI mapped from the ID of the terminal device can be used to scramble message B. The following provides a detailed design of the ID based on the TS-RNTI of the terminal device to ensure that message B is scrambled by a different value from message 2 (which is scrambled by RA-RNTI).

[0171] The space of possible RA-RNTI values ​​is approximately 18,000 values ​​(most of which are not used in any configuration). In the case where scrambling is performed based on the ID of the terminal device (RRC idle / inactive) and 16 bits are used to scramble message B, the first 15 bits from the terminal device ID are used as the 15 LSB bits and the MSB bit of the TS-RNTI is set to 1 to ensure that the number is greater than 18,000, which is greater than and close to the maximum value of the RA-RNTI. This makes the TS-RNTI different from the RA-RNTI so that message B and message 2 can be identified by different scrambling sequences. Table 2 is provided to define the range of RNTI values ​​according to an embodiment of the present disclosure.

[0172] Table 2

[0173]

[0174] Figure 8 is a flow chart illustrating a method 800 according to some embodiments described throughout this disclosure. Figure 8 The method 800 shown in the figure may be performed by an apparatus implemented in a network node or an apparatus communicatively coupled to a network node. According to an exemplary embodiment, the network node may be a base station, such as a gNB. Figure 8 In the description of the exemplary embodiment, for the parts that are the same as or similar to those in the aforementioned exemplary embodiment, the detailed description will be appropriately omitted.

[0175] according to Figure 8 In the exemplary method 800 shown, as shown in block 802, a network node may receive a request message including a preamble and a PUSCH message in a two-step random access procedure. The PUSCH message is received based on a first radio network temporary identifier (RNTI). In block 804, the network node may generate a response message based on a second RNTI. Then, in block 806, the network node may transmit the response message to the terminal device.

[0176] In one embodiment, the network node uses the identifier (ID) of the cell in which the terminal device is located to determine the RNTI or 'msgB RA-RNTI' to scramble the CRC of the PDCCH scheduling msgB. The ID of the terminal device is carried in the PUSCH message of message A. In some embodiments, in addition to its UE ID (e.g., C-RNTI or UE conflict resolution identifier) ​​that transmits message A, the terminal device uses the cell identifier to scramble the PUSCH message carried in the payload of message A. Since the network node receives the UE ID of the message directly in the PUSCH payload, and all terminal devices in the cell use the same PUSCH scrambling, the cell ID can be used for PUSCH reception. Therefore, in such an embodiment, there is no need to blindly decode the PUSCH with multiple scrambling assumptions or to determine the PUSCH scrambling from the preamble carried in message A. The new "message B" RA-RNTI may be formed not as a copy of the C-RNTI used in message A but as a function / mapping of the C-RNTI used in message A, for example by selecting the RA-RNTI from a set of possibilities using a hash or subset of the bits of the msgA RNTI. Similarly, in some embodiments where message A carries a UE conflict resolution identifier or the CCCH SDU has more bits than the message B RA-RNTI, the terminal device may use a subset or hash of the bits in the UE conflict resolution identifier to generate the msgB RA-RNTI. In some embodiments, the UE conflict resolution identifier is derived from a CCCH SDU as described in 3GPP TS 38.321 revision 15.4.0 sub-clause 6.1.3.3. The scrambling sequence generation for PUSCH may be derived using a modification of 3GPP TS 38.211 revision 15.4.0 sub-clause 6.3.1.1 (the disclosure of which is incorporated herein by reference in its entirety), where When PUSCH is used for transmission of message A, the scrambling sequence generator is initialized with the cell ID, otherwise the Rel-15 mechanism is used.

[0177] It can therefore be seen that, through the solution for the two-step random access process proposed according to the above-mentioned embodiments, the terminal device and / or the network node can determine the RNTI used for PUSCH CRC scrambling and PDSCH scrambling in the request message (message A) and / or in the response message (message B) in the two-step random access process.

[0178] Figure 3-5 The various blocks shown in 8 may be viewed as method steps, and / or as operations resulting from the operation of computer program code, and / or as a plurality of coupled logic circuit elements constructed to perform the associated functions. Figure 1The method of the present invention is generally described as a logical flow chart. Therefore, the order and labeled steps depicted indicate a specific embodiment of the method presented. Other steps and methods that are equivalent in function, logic or effect to one or more steps or portions thereof of the method shown can be envisioned. In addition, the order in which a particular method occurs may or may not strictly follow the order of the corresponding steps shown.

[0179] Fig. 9 is a block diagram illustrating a terminal device 900 according to some embodiments described throughout this disclosure. In an exemplary embodiment, the terminal device 900 may be a UE. Fig. 9 As shown, the terminal device 900 may include a receiving circuit 901, a transmitting circuit 902, one or more processors (e.g., a processor 903) and one or more memories (e.g., a memory 904), and a non-transitory computer-readable medium 904 on which computer-executable instructions are stored. The processor 903 is coupled to the receiving circuit 901, the transmitting circuit 902, and the non-transitory computer-readable medium 904. Optionally, the receiving circuit 901, the transmitting circuit 902, the processor 903, the memory 904, and / or the non-transitory computer-readable medium 904 may be operated to perform more or less operations to implement the proposed method according to the exemplary embodiments of the present disclosure.

[0180] Fig.10 1 is a block diagram illustrating a network node 1000 according to some embodiments described throughout this disclosure. In an exemplary embodiment, the network node 1000 may be a gNB or an eNB. Fig.10 As shown, the network node 1000 may include a receiving circuit 1001, a transmitting circuit 1002, one or more processors (e.g., a processor 1003) and one or more memories (e.g., a memory 1004), and a non-transitory computer-readable medium 1005 on which computer-executable instructions are stored. The processor 1003 is coupled to the receiving circuit 1001, the transmitting circuit 1002, and the non-transitory computer-readable medium 1005. Optionally, the receiving circuit 1001, the transmitting circuit 1002, the processor 1003, the memory 1004, and / or the non-transitory computer-readable medium 1005 may be operated to perform more or less operations to implement the proposed method according to the exemplary embodiments of the present disclosure.

[0181] Fig.11 is a block diagram illustrating a telecommunications network connected to a host computer via an intermediary network according to some embodiments of the present disclosure.

[0182] refer to Fig.11According to an embodiment, a communication system includes a telecommunication network 1110 such as a cellular network of the 3GPP type, which includes an access network 1111 such as a radio access network and a core network 1114. The access network 1111 includes a plurality of base stations 1112a, 1112b, 1112c, such as NBs, eNBs, gNBs or other types of wireless access points, each of which defines a corresponding coverage area 1113a, 1113b, 1113c. Each base station 1112a, 1112b, 1112c may be connected to the core network 1114 via a wired or wireless connection 1115. A first UE 1191 located in the coverage area 1113c is configured to be wirelessly connected to or paged by the corresponding base station 1112c. A second UE 1192 in the coverage area 1113a may be wirelessly connected to the corresponding base station 1112a. Although multiple UEs 1191 , 1192 are shown in this example, the disclosed embodiments are equally applicable to situations where only a UE is in the coverage area or a only UE is connected to the corresponding base station 1112 .

[0183] The telecommunications network 1110 itself is connected to a host computer 1130, which may be embodied in the hardware and / or software of a stand-alone server, a cloud-implemented server, a distributed server, or as a processing resource in a server farm. The host computer 1130 may be under the ownership or control of a service provider, or may be operated by or on behalf of the service provider. The connections 1121 and 1122 between the telecommunications network 1110 and the host computer 1130 may extend directly from the core network 1114 to the host computer 1130, or may be connected through an optional intermediate network 1120. The intermediate network 1120 may be one of the following, or a combination of more than one of the following: a public, private, or managed network; the intermediate network 1120 (if any) may be a backbone network or the Internet; in particular, the intermediate network 1120 may include two or more sub-networks (not shown).

[0184] Overall, Fig.11The communication system enables connectivity between the connected UEs 1191, 1192 and the host computer 1130. The connectivity can be described as an OTT (Over-the-top) connection 1150. The host computer 1130 and the connected UEs 1191, 1192 are configured to use the access network 1111, the core network 1114, any intermediate networks 1120, and possible other infrastructures (not shown) as intermediaries to communicate data and / or signaling via the OTT connection 1150. The OTT connection 1150 can be transparent in the sense that the participating communication devices through which the OTT connection 1150 passes are unaware of the routing of uplink and downlink communications. For example, the base station 1112 may not or need not be informed of the past routing of incoming downlink communications having data originating from the host computer 1130 to be forwarded (e.g., handed over) to the connected UE 1191. Similarly, in this case, base station 1112 does not need to know the future routing of outgoing uplink communications originating from UE 1191 to host computer 1130.

[0185] Fig.12 is a block diagram illustrating a host computer communicating with a UE via a base station over a partially wireless connection according to some embodiments of the present disclosure.

[0186] Now refer to Fig.12 Describe the example implementation of the UE, base station and host computer described in the preceding paragraphs according to the embodiment. In the communication system 1200, the host computer 1210 includes hardware 1215, and the hardware 1215 includes a communication interface 1216, which is configured to establish and maintain a wired or wireless connection with the interface of different communication devices of the communication system 1200. The host computer 1210 also includes a processing circuit 1218, which may have storage and / or processing capabilities. In particular, the processing circuit 1218 may include: one or more programmable processors, application-specific integrated circuits, field programmable gate arrays, or a combination thereof (not shown) suitable for executing instructions. The host computer 1210 also includes software 1211, which is stored in the host computer 1210 or can be accessed by the host computer 1210 and can be run by the processing circuit 1218. Software 1211 includes a host application 1212. The host application 1212 may be used to provide services to a remote user, such as a UE 1230, connected via an OTT connection 1250 terminated at the UE 1230 and the host computer 1210. In providing services to the remote user, the host application 1212 may provide user data transmitted using the OTT connection 1250.

[0187] The communication system 1200 also includes a base station 1220 provided in the telecommunication system, the base station 1220 including hardware 1225 that enables the base station 1220 to communicate with the host computer 1210 and the UE 1230. The hardware 1225 may include a communication interface 1226 for establishing and maintaining a wired or wireless connection to the interface of different communication devices of the communication system 1200, and a radio interface 1227 for establishing and maintaining at least a wireless connection 1270 with the UE 1230 located in a coverage area (not shown) served by the base station 1220. The communication interface 1226 may be configured to facilitate a connection 1260 to the host computer 1210. The connection 1260 may be direct or it may be through a core network ( Fig.12 1220) and / or through one or more intermediate networks outside the telecommunications system. In the illustrated embodiment, the hardware 1225 of the base station 1220 also includes processing circuitry 1228, which may include one or more programmable processors, application specific integrated circuits, field programmable gate arrays, or a combination of these (not shown) adapted to execute instructions. The base station 1220 also has software 1221 stored internally or accessible via an external connection.

[0188] The communication system 1200 also includes the UE 1230 already mentioned. Its hardware 1235 may include a radio interface 1237, which is configured to establish and maintain a wireless connection 1270 with a base station serving the coverage area where the UE 1230 is currently located. The hardware 1235 of the UE 1230 also includes a processing circuit 1238, which may include one or more programmable processors, application specific integrated circuits, field programmable gate arrays, or a combination thereof (not shown) suitable for executing instructions. The UE 1230 also includes software 1231, which is stored in the UE 1230 or can be accessed by the UE 1230 and can be run by the processing circuit 1238. The software 1231 includes a client application 1232. The client application 1232 is operable to provide services to human users or non-human users through the UE 1230 with the support of the host computer 1210. In the host computer 1210, the running host application 1212 can communicate with the running client application 1232 through the OTT connection 1250 terminated at the UE 1230 and the host computer. When providing services to the user, the client application 1232 can receive request data from the host application 1212 and provide user data in response to the request data. The OTT connection 1250 can transmit both the request data and the user data. The client application 1232 can interact with the user to generate the user data it provides.

[0189] Fig.12 The host computer 1210, base station 1220 and UE 1230 shown can be connected with Fig.12 The host computer 1230, one of the base stations 1212a, 1212b, 1212c and one of the UEs 1291, 1292 are similar or identical to each other. That is, the internal workings of these entities may be similar to Fig.12 As shown, and independently, the surrounding network topology can be Fig.12 The surrounding network topology.

[0190] exist Fig.12 In the present invention, an OTT connection 1250 has been abstractly drawn to illustrate the communication between the host computer 1210 and the UE 1230 through the base station 1220, without explicitly referencing any intermediate devices and the precise routing of the messages via these devices. The network infrastructure can determine the routing, which can be configured to be hidden from the UE 1230 or from the service provider operating the host computer 1210, or from both. When the OTT connection 1250 is active, the network infrastructure can further make decisions by which it dynamically changes the routing (e.g., based on load balancing considerations or reconfiguration of the network).

[0191] The wireless connection 1270 between the UE 1230 and the base station 1220 is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments use the OTT connection 1250 to improve the performance of the OTT service provided to the UE 1230, where the wireless connection 1270 forms the last leg. More specifically, the teachings of these embodiments can improve latency and power consumption, and thereby provide benefits such as lower complexity, reduced time required to access a cell, better responsiveness, extended battery life, etc.

[0192] The measurement process may be provided for the purpose of monitoring the 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 1250 between the host computer 1210 and the UE 1230 in response to changes in the measurement results. The measurement process and / or network function for reconfiguring the OTT connection 1250 may be implemented in the software 1211 and hardware 1215 of the host computer 1210 or in the software 1231 and hardware 1235 of the UE 1230 or in both. In an embodiment, a sensor (not shown) may be deployed in or associated with a communication device through which the OTT connection 1250 passes; the sensor may participate in the measurement process by providing the values ​​of the monitoring quantities exemplified above or providing the values ​​of other physical quantities, and the software 1211, 1231 may calculate or estimate the monitoring quantities from the values ​​of other physical quantities. The reconfiguration of the OTT connection 1250 may include message formats, retransmission settings, preferred routes, etc.; the reconfiguration does not necessarily affect the base station 1220, and the base station 1220 may be unaware or imperceptible. Such processes and functions are known and practiced in the art. In some embodiments, the measurements may involve proprietary UE signaling that facilitates host computer 1210 measurements of throughput, propagation time, latency, etc. The measurements may be implemented in software 1211 and 1231 that uses OTT connection 1250 to transmit messages (particularly null messages or "dummy" messages) while software 1211 and 1231 monitors propagation time, errors, etc.

[0193] Fig.13 is a flow chart showing a method implemented in a communication system according to an embodiment. The communication system includes a host computer, a base station and a UE, which can be reference Fig.11 and Fig.12 For the sake of brevity of this disclosure, this section only includes references Fig.13 . In step 1310, the host computer provides user data. In sub-step 1311 of step 1310 (which may be optional), the host computer provides the user data by executing a host application. In step 1320, the host computer initiates a transmission to the UE carrying the user data. In step 1330 (which may be optional), in accordance with the teachings of the embodiments described throughout the present disclosure, the base station transmits the user data carried in the host-initiated transmission to the UE. In step 1340 (which may also be optional), the UE executes a client application associated with the host application executed by the host computer.

[0194] Fig.14 is a flow chart showing a method implemented in a communication system according to an embodiment. The communication system includes a host computer, a base station and a UE, which can be reference Fig.11 and Fig.12For the sake of brevity of this disclosure, only references to Fig.14 . In step 1410 of the method, the host computer provides user data. In an optional sub-step (not shown), the host computer provides the user data by executing a host application. In step 1420, the host computer initiates a transmission to the UE carrying the user data. According to the teachings of the embodiments described throughout the present disclosure, the transmission can be passed through a base station. In step 1430 (which may be optional), the UE receives the user data carried in the transmission.

[0195] Fig.15 is a flow chart showing a method implemented in a communication system according to an embodiment. The communication system includes a host computer, a base station and a UE, which can be reference Fig.11 and Fig.12 For the sake of brevity of this disclosure, this section only includes references Fig.15 . In step 1510 (which may be optional), the UE receives input data provided by the host computer. Additionally or alternatively, in step 1520, the UE provides user data. In sub-step 1521 (which may be optional) of step 1520, the UE provides user data by executing a client application. In sub-step 1511 (which may be optional) of step 1510, the UE executes a client application that provides user data in response to received input data provided by the host computer. When providing user data, the executed client application may further consider user input received from the user. Regardless of the specific manner of providing user data, the UE initiates transmission of user data to the host computer in sub-step 1530 (which may be optional). In step 1540 of the method, in accordance with the teachings of the embodiments described throughout the present disclosure, the host computer receives user data transmitted from the UE.

[0196] Fig.16 is a flow chart showing a method implemented in a communication system according to an embodiment. The communication system includes a host computer, a base station and a UE, which can be reference Fig.11 and Fig.12 For the sake of brevity of this disclosure, this section only includes references Fig.16 In step 1610 (which may be optional), the base station receives user data from the UE in accordance with the teachings of the embodiments described throughout the present disclosure. In step 1620 (which may be optional), the base station initiates a transmission of the received user data to the host. In step 1630 (which may be optional), the host computer receives the user data carried in the transmission initiated by the base station.

[0197] In general, various exemplary embodiments may be implemented in hardware or dedicated chips, 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, but the disclosure is not limited thereto. Although various aspects of the exemplary embodiments of the present disclosure may be illustrated and described as block diagrams, flow charts, or using some other illustrations, it is well understood that these block diagrams, devices, systems, techniques, or methods described herein may be implemented in hardware, software, firmware, dedicated circuits or logic, general hardware or controllers or other computing devices, or some combination thereof as non-limiting examples.

[0198] It should therefore 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. It should therefore 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 possible 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 are configurable to operate in accordance with the exemplary embodiments of the present disclosure.

[0199] 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 (e.g., in one or more program modules). Typically, a program module includes routines, programs, objects, components, data structures, etc. that 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 computer readable media such as hard disks, optical disks, removable storage media, solid-state memory, random access memory (RAM), etc. As will be appreciated by those skilled in the art, the functionality of the program modules may be combined or distributed in various embodiments as desired. In addition, the functionality may be embodied in whole or in part in firmware or hardware equivalents, such as integrated circuits, field programmable gate arrays (FPGAs), etc.

[0200] For better understanding, some preferred embodiments of the present disclosure are provided below.

[0201] Example 1: RNTI for two-step RA depends on RRC state

[0202] In one embodiment, if the UE does not have a valid C-RNTI, for example in idle mode, the CS-RNTI (Configured Scheduling RNTI) is used. The CS-RNTI may have one or more RNTI values, which may be cell-specifically configured. For example, the CS-RNTI value may be provided in the RMSI or OSI. The UE selects the actual CS-RNTI value to be used from the set of configured multiple values. When the UE has a C-RNTI, for example in RRC connected mode and is to perform CFRA, in one embodiment, it uses its C-RNTI.

[0203] In another embodiment, for example in inactive mode and performing CBRA, it may use a CS-RNTI based on its C-RNTI, for example a function of certain bits in the C-RNTI. This reduces the complexity of blind decoding for the gNB receiver compared to experimentally detecting all inactive UE C-RNTIs in the system or tracking area.

[0204] In one embodiment, if one or more UE attempts using C-RNTI or CS-RNTI based on C-RNTI are unsuccessful, it may revert to the method where the UE does not possess a valid C-RNTI for subsequent attempts.

[0205] Embodiment 1a: CS-RNTI used to scramble msgA PUSCH payload in two-step RA depends on msgA preamble used by UE

[0206] For UEs that do not possess a valid C-RNTI, the selected CS-RNTI may be selected based on, for example, the msgA preamble ID, the PRACH opportunity, or the PRACH preamble format, and / or the selected CS-RNTI may be associated with, for example, the msgA preamble ID, the PRACH opportunity, or the PRACH preamble format. Since the preamble ID and the opportunity are selected from a set that depends on the SSB, this embodiment may alternatively be viewed as selecting the CS-RNTI based on the best detected SSB in the cell.

[0207] In one embodiment, the gNB detects PUSCH after detecting the preamble and may use the obtained preamble configuration information to configure PUSCH reception.

[0208] In another embodiment, possible CS-RNTI values ​​may be detected blindly. Then, for example, if the current transmission is a retransmission of msgA without retransmission of the preamble, no preamble detection is required.

[0209] Embodiment 1b: Selecting CS-RNTI for scrambling msgAPUSCH payload in two-step RA based on, e.g., PUSCH parameters, access purpose

[0210] Alternatively, the CS-RNTI may be selected from a set of multiple options provided in the SI or specification, regardless of the selected preamble. Alternatively, the CS-RNTI may be selected, for example, based on PUSCH payload attributes (size, format) or based on the purpose of performing the RA attempt (short data, regular access).

[0211] Embodiment 2: The network selects the RNTI for scrambling the PDCCH CRC of msgB in two-step RA based on the received msgA PUSCH RNTI

[0212] In this embodiment, the NW scrambles the CRC of the PDCCH of msgB using the RNTI (e.g., C-RNTI or CS-RNTI) used by the UE in the msgA PUSCH. The NW detects the CS-RNTI based on the received msgA preamble or based on blind detection of the PUSCH. This RNTI then functionally becomes the new RA-RNTI for the given UE.

[0213] Alternatively, the new RA-RNTI may be formed but not as a copy of the C-RNTI or CS-RNTI used in msgA but as a function / mapping of the C-RNTI or CS-RNTI used in msgA, e.g. using a hash or subset of the bits of the msgA RNTI to select the RA-RNTI from a set of possibilities.

[0214] These principles defined for the new RA-RNTI also allow the NW and UE to effectively differentiate between the two-step msgB and four-step msg2 responses.

[0215] Embodiment 3: A separate RNTI such as TS-RNTI (two-step-RNTI) is designed based on the preamble id and the number of PRACH opportunities configured in a determined order.

[0216] The TS-RNTI is associated with the preamble id and the PRACH opportunity and is designed to be different from the RA-RNTI and therefore will not conflict with the RA-RNTI. An example is in the following order (see Figure 6 ) in the TS-RNTI numbering. First, in ascending order of preamble index within a single PRACH opportunity. Second, in ascending order of frequency resource index for frequency-reused PRACH opportunities. Third, in ascending order of time resource index for time-reused PRACH opportunities within a PRACH slot. Fourth, in ascending order of index for PRACH slots.

[0217] The ordering may also be performed in any other specified order, such as frequency resources, time resources, preamble resources. In this way, the UE is able to calculate the TS-RNTI when the selected preamble is transmitted. In the same way, the gNB can calculate the TS-RNTI when a specific preamble is received on a specific PRACH opportunity. In this method, the determined order may be predetermined or RRC configured. Figure 6 An example in which 3 preamble ids (0-2) are configured in each PRACH opportunity and the TS-RNTI for the first 8 PRACH opportunities is shown in FIG.

[0218] It is also possible to use only a subset of the indices, for example based on the ordering of the preamble index and the frequency resource index for frequency reuse PRACH. Figure 7 This is shown in , where 64 preamble indices (0-63) are used in each of two frequency-reused PRACH opportunities. This gives 0-127 as possible first RNTIs. The PUSCH opportunities are also linked to the preamble and PRACH opportunities so that, for example, the first 32 indices in each PRACH opportunity are mapped to a PUSCH opportunity with a lower frequency index. In this case, the TS-RNTI is 0-63 in the first PRACH opportunity and 64-127 in the second PRACH opportunity. Then, Msg A transmitted in PUSCH opportunity 0 will be scrambled by RNTI 0-31 depending on the selected preamble, MsgA transmitted in PUSCH opportunity 1 will be scrambled by RNTI 32-63 depending on the selected preamble, MsgA transmitted in PUSCH opportunity 3 will be scrambled by RNTI 64-95 depending on the selected preamble, and finally MsgA transmitted in PUSCH opportunity 3 will be scrambled by RNTI 96-127 depending on the selected preamble.

[0219] Embodiment 3a: TS-RNTI is associated with one or more of the following factors:

[0220] (i) Frequency band used

[0221] For example, in an unlicensed band, RA-RNTI or modified RA-RNTI cannot be used for TS-RNTI because RA-RNTI may be unavailable when the UE is preparing for PUSCH while waiting for LBT for msgA preamble transmission. Or to avoid the problem of RA-RNTI unavailability, RA-RNTI is always generated based on RO of, for example, the first LBT. In a licensed band, TS-RNTI can be RA-RNTI or modified RA-RNTI, or a newly defined RNTI.

[0222] (ii) The time gap between the preamble and msgA PUSCH

[0223] For example, when the interval is not less than a threshold, the RA-RNTI or modified RA-RNTI may be applied to msgA and msgB transmissions, otherwise an RNTI independent of the RA-RNTI may be used. The threshold may be predetermined or signaled in RRC signaling.

[0224] In addition, the RNTI used for MsgA scrambling may be more directly dependent on the temporal distance between the preamble and the PUSCH. This dependency may be based on the time in seconds between the preamble and the PUSCH, and / or based on the number of OFDM symbols and / or time slots, and / or based on the number of PRACH opportunities (time and / or frequency) between the preamble and the PUSCH.

[0225] (iii) Time / frequency of msgA transmission

[0226] For MsgB, the RNTI is based on the timing / frequency of the corresponding transmission of MsgA. This is especially preferred when the msgA PUSCH from different UEs have different PUSCH opportunities, so different UEs will use different RNTIs.

[0227] Furthermore, if the time position of the preamble can be determined from the time position of the PUSCH (e.g., if the configuration is such that the PUSCH follows the preamble immediately, or has a time gap less than a given threshold, see the previous subsection), the RNTI used for RNTI MsgA scrambling may be independent of time, otherwise the RNTI used for MsgA scrambling may be dependent on time. When / if the MsgA RNTI is independent of time, the MsgB RNTI may still be dependent on time. As a special case, the MsgA RNTI may be the same as the MsgB RNTI, except that the time correlation is omitted.

[0228] The gap thresholds mentioned above (also in the previous subsection) may be predetermined in the specification and / or signaled explicitly or implicitly by other signaling (eg, a PRACH configuration index). As an alternative to selecting scrambling based on a time gap threshold, the selection may be signaled.

[0229] (iv)UEID

[0230] The UE ID itself or a certain RNTI mapped from the UE ID can be used for scrambling of MsgB. An example of a detailed design of TS-RNTI based on UEID is provided below to ensure that MsgB is scrambled by a different value from Msg2 (which is scrambled by RA-RNTI): the space of possible RA-RNTI values ​​is approximately 18,000 values ​​(most of which are not used in any configuration). In the case where scrambling is based on UE id (RRC idle / inactive) and 16 bits are used to scramble MsgB, the first 15 bits from the UE id are used as 15 LSB bits and the MSB bit of the TS-RNTI is set to 1 to ensure that the number is greater than 18,000, which is greater than and close to the maximum value of RA-RNTI. This makes TS-RNTI different from RA-RNTI, and MsgB and Msg2 can be identified by different scrambling sequences.

[0231] Embodiment 4: The network selects an RNTI based on the UE ID carried in the msgA PUSCH, which is used to scramble the CRC of the PDCCH of msgB scheduled in the two-step RA.

[0232] In these embodiments, the NW uses the UE's ID carried in the msgA PUSCH to determine the RNTI (or 'msgB RA-RNTI') for scrambling the CRC of the PDCCH scheduling msgB.

[0233] In some embodiments, the UE scrambles the PUSCH msgA payload with the cell identity in addition to transmitting its msgA UE ID (e.g., C-RNTI or UE conflict resolution identity). Since the gNB receives the msgA UE ID directly in the PUSCH payload and all UEs in the cell use the same PUSCH scrambling, the cell ID can be used for PUSCH reception. Therefore, in such embodiments, it is not necessary to blindly decode the PUSCH using multiple scrambling hypotheses or to determine the PUSCH scrambling from the msgA preamble.

[0234] The new 'msgB' RA-RNTI may be formed not as a copy of the C-RNTI used in msgA, but as a function / mapping of the C-RNTI used in msgA, e.g. using a hash or subset of the bits of the msgA RNTI to select the RA-RNTI from a set of possibilities. Similarly, in embodiments where msgA carries the UE conflict resolution identifier or the CCCH SDU has more bits than the msgB RA-RNTI, the UE may generate the msgB RA-RNTI using a subset or hash of the bits in the UE conflict resolution identifier. In some embodiments, the UE conflict resolution identifier is derived from the CCCH SDU as described in 3GPP TS 38.321 Revision 15.4.0 subclause 6.1.3.3.

[0235] The scrambling sequence generation for PUSCH can be accomplished using modifications to 3GPP TS 38.211 revision 15.4.0 subclause 6.3.1.1. When PUSCH is used for msgA transmission, the cell ID is used to initialize the scrambling sequence generator, otherwise the Rel-15 mechanism is used.

[0236] According to some embodiments described throughout the present disclosure, the present disclosure provides options for how the UE and the network select the RNTI for msgA PUSCH scrambling and / or msgB PDCCH CRC scrambling and PDSCH scrambling in two-step RACH. The following methods are provided:

[0237] (a) The RNTI depends on the RRC state and / or RA type of the UE.

[0238] - When CS-RNTI is used, it may depend on the preamble, PUSCH parameters, access purpose, or may be set randomly.

[0239] (b) The RNTI used to scramble the PDCCH CRC of msgB in two-step RA is based on the received msgAPUSCH RNTI.

[0240] (c) A separate RNTI, such as TS-RNTI (two-step-RNTI), is designed based on the preamble id and the number of PRACH opportunities configured in a determined order, where the TS-RNTI can be associated with one or more of the following factors: the frequency band used, and / or the time gap between the preamble and the msgA PUSCH, and / or the timing / frequency of msgA transmissions, and / or the mapping to UE ID (at least in some cases only for msgB).

[0241] abbreviation

[0242] CBRA Contention-Based Random Access

[0243] CFRA Contention-free random access

[0244] MA Multiple Access

[0245] NR New Radio

[0246] NW Network

[0247] PUSCH Physical Uplink Shared Channel

[0248] RACH Random Access Channel

[0249] PRACH Physical Random Access Channel

[0250] RAR Random Access Response

[0251] RNTI Radio Network Temporary Identifier

[0252] SI System Information

[0253] SIB1 System Information Block Type 1

[0254] TF Time and Frequency

[0255] The present disclosure includes any novel feature or combination of features explicitly disclosed herein or disclosed by any generalization thereof. When read in conjunction with the accompanying drawings, various modifications and adaptations to the aforementioned exemplary embodiments of the present disclosure will become apparent to those skilled in the relevant art in view of the foregoing 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 at a terminal device, comprising: determining (302, 304, 306) a request message for random access, wherein the request message includes a preamble and a physical uplink shared channel (PUSCH) message, and the PUSCH message is determined based on a first radio network temporary identifier (RNTI); and transmitting (308) the request message; obtaining (310) a response message for the random access based on a second RNTI; The first RNTI is used to scramble the coded bits of the PUSCH message; The second RNTI is used to scramble a cyclic redundancy check CRC of a physical downlink control channel PDCCH message that schedules a physical downlink shared channel PDSCH carrying the response message; The first RNTI is RA-RNTI, and the second RNTI is C-RNTI.

2. The method according to claim 1, wherein: The first RNTI and the second RNTI are the same.

3. The method according to claim 1, wherein: The first RNTI and the second RNTI are different.

4. The method according to any one of claims 1 to 3, wherein: The second RNTI is determined based on a radio resource control (RRC) state of the terminal device.

5. The method according to claim 4, wherein: The RRC state includes: connection mode.

6. The method according to any one of claims 1 to 3 and 5, wherein: If a cell-RNTI C-RNTI is available, the C-RNTI is determined as the second RNTI.

7. The method according to any one of claims 1 to 3 and 5, wherein: The second RNTI is determined based on the first RNTI.

8. The method according to any one of claims 1 to 3 and 5, wherein: The first RNTI and / or the second RNTI is determined based on a number of a set of physical random access channel PRACH opportunities.

9. The method according to claim 8, wherein: The set of RNTI values ​​is determined based on the timing / frequency resources of the request message.

10. A method at a network node, comprising: Obtaining (802) a request message including a preamble and a physical uplink shared channel PUSCH message from a terminal device based on a first radio network temporary identifier RNTI; determining (804) a response message based on the second RNTI; as well as Transmitting (806) the response message to the terminal device; The first RNTI is used to scramble the coded bits of the PUSCH message; The second RNTI is used to scramble a cyclic redundancy check CRC of a physical downlink control channel PDCCH message that schedules a physical downlink shared channel PDSCH carrying the response message; The first RNTI is RA-RNTI, and the second RNTI is C-RNTI.

11. The method according to claim 10, wherein: The first RNTI and the second RNTI are the same.

12. The method according to claim 10, wherein: The first RNTI and the second RNTI are different.

13. The method according to any one of claims 10 to 12, wherein: The second RNTI is determined based on a radio resource control (RRC) state of the terminal device.

14. The method according to claim 13, wherein: The RRC state includes: connection mode.

15. The method according to any one of claims 10-12 and 14, wherein: If the cell RNTIC-RNTI is available, the C-RNTI is determined as the second RNTI.

16. The method according to any one of claims 10-12 and 14, wherein: The second RNTI is determined based on the first RNTI.

17. The method according to any one of claims 10-12 and 14, wherein: The first RNTI and / or the second RNTI is determined based on a number of a set of physical random access channel PRACH opportunities.

18. The method according to claim 17, wherein: The set of RNTI values ​​is determined based on the timing / frequency resources of the request message.

19. A terminal device, comprising: a non-transitory computer-readable medium having computer-executable instructions stored thereon; as well as a processor coupled to the non-transitory computer readable medium, The computer executable instructions enable the terminal device to implement the method according to claim 1.

20. The terminal device according to claim 19, comprising: a non-transitory computer-readable medium having computer-executable instructions stored thereon; as well as a processor coupled to the non-transitory computer readable medium, The computer executable instructions enable the terminal device to implement the method according to any one of claims 2-9.

21. A network node, comprising: a non-transitory computer-readable medium having computer-executable instructions stored thereon; as well as a processor coupled to the non-transitory computer readable medium, The computer executable instructions enable the network node to implement the method according to claim 10.

22. The network node according to claim 21, comprising: a non-transitory computer-readable medium having computer-executable instructions stored thereon; as well as a processor coupled to the non-transitory computer readable medium, The computer executable instructions cause the network node to implement the method according to any one of claims 11-18.

23. A method at a terminal device, comprising: determining (306) a request message for random access, wherein the request message includes a preamble and a physical uplink shared channel (PUSCH) message, and the PUSCH message is determined based on an identification ID of a cell in which the terminal device is located; and transmitting (308) the request message; obtaining (310) a response message for the random access based on a second RNTI; The second RNTI is used to scramble a cyclic redundancy check CRC of a physical downlink control channel PDCCH message that schedules a physical downlink shared channel PDSCH carrying the response message; wherein a first RNTI is determined based on an identification ID of the cell, and the first RNTI is used to scramble coded bits of the PUSCH message; The first RNTI is RA-RNTI, and the second RNTI is C-RNTI.

24. The method according to claim 23, wherein: The second RNTI is determined based on the ID of the terminal device.

25. A method at a terminal device, comprising: Obtaining a response message for random access based on a second radio network temporary identifier RNTI, wherein the response message is a response to a request message for random access, the request message including a preamble and a physical uplink shared channel PUSCH message; The second RNTI is used to scramble a cyclic redundancy check CRC of a physical downlink control channel PDCCH message that schedules a physical downlink shared channel PDSCH carrying the response message; The PUSCH message is determined based on a first RNTI, and the first RNTI is used to scramble coded bits of the PUSCH message; The first RNTI is RA-RNTI, and the second RNTI is C-RNTI.

26. The method according to claim 25, wherein: The first RNTI and the second RNTI are the same or different.

27. The method according to claim 26, wherein: The first RNTI and / or the second RNTI is determined based on a radio resource control (RRC) state of the terminal device.

28. The method according to claim 27, wherein: The RRC state includes: idle mode, connected mode, and inactive mode.

29. The method according to any one of claims 25 to 28, wherein: If a cell-RNTI C-RNTI is available, the C-RNTI is determined as the first RNTI and / or the second RNTI.

30. The method according to any one of claims 25 to 28, wherein: If the cell RNTI C-RNTI is unavailable, the configured scheduling RNTI CS-RNTI is determined as the first RNTI and / or the second RNTI.

31. The method according to any one of claims 25 to 28, wherein: The first RNTI and / or the second RNTI is determined by: The CS-RNTI is selected from a plurality of CS-RNTIs in the broadcasted system information.

32. The method according to claim 31, wherein: The CS-RNTI is randomly selected from the multiple CS-RNTIs.

33. The method according to claim 31, wherein: The CS-RNTI is selected based on at least one of the following: one or more indices of the preamble code, one or more physical random access channel PRACH opportunities, the format of the preamble code, PUSCH parameters and the purpose of the wireless access RA attempt of the terminal device.

34. The method according to any one of claims 25-28 and 32-33, wherein: The second RNTI is determined based on the first RNTI.

35. The method of claim 25, further comprising: A request message including a preamble code and a PUSCH message is determined based on an identification ID of a cell in which the terminal device is located.

36. The method according to any one of claims 25-28, 32-33 and 35, wherein: The first RNTI and / or the second RNTI are determined based on the ID of the terminal device.

37. The method according to any one of claims 25-28, 32-33 and 35, wherein: The first RNTI and / or the second RNTI is determined based on at least one of the following and based on the number of RNTI values ​​in a set of RNTI values: the number of a set of physical random access channel PRACH opportunities, the number of a set of preamble codes, the number of a set of PUSCH opportunities, and the set of RNTI values.

38. The method of claim 37, wherein: The RNTI values ​​are numbered based on at least one of: the order of indices of the preamble codes associated with the RNTI values ​​in the PRACH opportunities; the order of frequency resource indices of the PRACH opportunities associated with the RNTI values; the order of time resource indices of the PRACH opportunities associated with the RNTI values; and the order of indices for the PRACH time slots associated with the RNTI values.

39. The method of claim 37, wherein: The set of RNTI values ​​is determined based on at least one of: the frequency band used, the time gap between the first preamble and the PUSCH, the timing / frequency resources of the request message, and the ID of the terminal device.

40. A method at a network node, comprising: Based on the first radio network temporary identifier RNTI, obtaining (802) a request message including a preamble and a physical uplink shared channel PUSCH message from the terminal device; determining (804) a response message based on the second RNTI; The second RNTI is used to scramble a cyclic redundancy check CRC of a physical downlink control channel PDCCH message that schedules a physical downlink shared channel PDSCH carrying the response message; The first RNTI is used to scramble the coded bits of the PUSCH message; The first RNTI is RA-RNTI, and the second RNTI is C-RNTI.

41. The method of claim 40, transmitting (806) the response message to the terminal device.

42. The method according to claim 40 or 41, wherein: The first RNTI and / or the second RNTI is determined based on a radio resource control (RRC) state of the terminal device.

43. The method of claim 42, wherein: The RRC state includes: idle mode, connected mode, and inactive mode.

44. The method according to any one of claims 40-41 and 43, wherein: If a cell-RNTI C-RNTI is available, the C-RNTI is determined as the first RNTI and / or the second RNTI.

45. The method according to any one of claims 40-41 and 43, wherein: If the cell RNTI C-RNTI is unavailable, the configured scheduling RNTI CS-RNTI is determined as the first RNTI and / or the second RNTI.

46. ​​The method according to any one of claims 40-41 and 43, wherein: The first RNTI and / or the second RNTI is determined by: The CS-RNTI is selected from a plurality of CS-RNTIs in the broadcasted system information.

47. The method of claim 46, wherein: The CS-RNTI is randomly selected from the multiple CS-RNTIs.

48. The method of claim 46, wherein: The CS-RNTI is selected based on at least one of the following: one or more indices of the preamble code, one or more physical random access channel PRACH opportunities, the format of the preamble code, PUSCH parameters and the purpose of the wireless access RA attempt of the terminal device.

49. The method according to any one of claims 40-41, 43 and 47-48, wherein The second RNTI is determined based on the first RNTI.

50. The method according to any one of claims 40-41, 43 and 47-48, wherein The first RNTI and / or the second RNTI are determined based on the ID of the terminal device.

51. The method according to any one of claims 40-41, 43 and 47-48, wherein: The first RNTI and / or the second RNTI is determined based on at least one of the following and based on the number of RNTI values ​​in a set of RNTI values: the number of a set of physical random access channel PRACH opportunities, the number of a set of preamble codes, the number of a set of PUSCH opportunities, and the set of RNTI values.

52. The method of claim 51, wherein: The RNTI values ​​are numbered based on at least one of: the order of indices of the preamble codes associated with the RNTI values ​​in the PRACH opportunities; the order of frequency resource indices of the PRACH opportunities associated with the RNTI values; the order of time resource indices of the PRACH opportunities associated with the RNTI values; and the order of indices for the PRACH time slots associated with the RNTI values.

53. The method of claim 51, wherein: The set of RNTI values ​​is determined based on at least one of: the frequency band used, the time gap between the first preamble and the PUSCH, the timing / frequency resources of the request message, and the ID of the terminal device.

54. A method at a network node, comprising: Based on the cell in which the terminal device is located, obtaining a request message including a preamble and a physical uplink shared channel (PUSCH) message from the terminal device; wherein a first RNTI is determined based on an identification ID of the cell, and the first RNTI is used to scramble coded bits of the PUSCH message; The first RNTI is a RA-RNTI; determining a response message based on the second RNTI; and The response message is transmitted to the terminal device, wherein the second RNTI is determined based on the ID of the terminal device.

55. A terminal device, comprising: a non-transitory computer-readable medium having computer-executable instructions stored thereon; as well as a processor coupled to the non-transitory computer readable medium, The computer executable instructions enable the terminal device to implement the method according to claim 25.

56. The terminal device according to claim 55, comprising: a non-transitory computer-readable medium having computer-executable instructions stored thereon; as well as a processor coupled to the non-transitory computer readable medium, The computer executable instructions enable the terminal device to implement the method according to any one of claims 26-39.

57. A network node, comprising: a non-transitory computer-readable medium having computer-executable instructions stored thereon; as well as a processor coupled to the non-transitory computer readable medium, The computer executable instructions cause the network node to implement the method according to claim 40.

58. The network node according to claim 57, comprising: a non-transitory computer-readable medium having computer-executable instructions stored thereon; as well as a processor coupled to the non-transitory computer readable medium, The computer executable instructions enable the network node to implement the method according to any one of claims 41-53.

59. A network node, comprising: a non-transitory computer-readable medium having computer-executable instructions stored thereon; as well as a processor coupled to the non-transitory computer readable medium, Wherein, the computer executable instructions cause the network node to implement the method according to claim 54.

60. A terminal device, comprising: a non-transitory computer-readable medium having computer-executable instructions stored thereon; as well as a processor coupled to the non-transitory computer readable medium, The computer executable instructions enable the terminal device to implement the method according to claim 23.

61. The terminal device according to claim 60, comprising: a non-transitory computer-readable medium having computer-executable instructions stored thereon; as well as a processor coupled to the non-transitory computer readable medium, The computer executable instructions enable the terminal device to implement the method according to claim 24.

62. A non-transitory computer readable medium having stored thereon program code for use with a computing device, wherein: When the program code is executed by a processor, the program code performs the method according to any one of claims 1-18 or 23-54.

Images