METHOD AND APPARATUS FOR DETERMINING WIRELESS NETWORK TEMPORARY IDENTIFIER IN A TWO-STEP RANDOM ACCESS PROCEDURE - Patent application

Abstract

To provide a method and an apparatus for determining a radio network temporary identifier (RNTI) in a two-step random access procedure.SOLUTION: In a communication system, a terminal device includes determining a request message for random access that includes a preamble and a physical uplink shared channel (PUSCH) message, in which the PUSCH message is determined based on a first radio network temporary identification information (RNTI), sending the request message, and obtaining a response message for random access based on second RNTI. The first RNTI and the second RNTI are the same or different.SELECTED DRAWING: Figure 3

Description

[Technical field]

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

[0002] This section introduces aspects that may facilitate a better understanding of the present disclosure. Accordingly, the statements in this section are to be read in this light and not understood as admissions about what is in the prior art or what is not in the prior art.

[0003] In new radio (NR) systems, a four-step approach may be used for random access procedures, as shown in FIG. 1. In this approach, a user equipment (UE) detects synchronization signals (SS), including NR-Primary Synchronization Signals (NR-PSS), NR-Secondary Synchronization Signals (NR-SSS), and NR-Physical Broadcast Channel (PBCH), and decodes broadcasted system information, e.g., Residual Minimum System Information (RMSI). The UE may then transmit a Physical Random Access Channel (PRACH) preamble (Message 1) in the 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, a UL grant, and a temporary cell-radio network temporary identifier (TC-RNTI).

[0004] After receiving the RAR message, the UE may transmit message 3 on the physical uplink shared channel (PUSCH) including UE identification and transport block. 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 timing accuracy within the cyclic prefix (CP). Without this timing advance, a very large CP would be required to be able to demodulate and detect the PUSCH unless the system is applied in cells with very small distance between the UE and the gNB. Since NR also supports larger cells with the need to provide timing advance to the UE, a four-step approach is needed for the random access procedure.

[0005] The message 3 PUSCH is scheduled by the UL grant in the RAR message. Retransmissions of transport blocks in the 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 the message 3 PUSCH without repetition.

[0006] In 3GPP TS38.321 v15.4.0, the disclosure of which is incorporated herein by reference in its entirety, Table 1 is provided to define RNTI value ranges as follows: TIFF0007634335000001.tif51170

[0007] A two-step random access procedure has been approved as a work item for NR Release 16. As shown in Figure 2, initial access is completed in just two steps. In the first step, the UE sends a message, sometimes called message A, that includes a random access preamble along with 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 sends a response message, sometimes called message B, that includes, for example, a UE identifier allocation, timing advance information, and a contention resolution message to the UE. Message B is the response message carried in a physical downlink shared channel (PDSCH) scheduled by a physical downlink control channel (PDCCH) with a CRC scrambled by some RNTI. Summary of the Invention

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

[0009] This disclosure proposes a solution for determining the RNTI in a two-step random access procedure.

[0010] According to a first aspect of the present disclosure, a method in a terminal device is provided. The method includes determining a request message for random access, the request message including a preamble and a physical uplink shared channel (PUSCH) message, the PUSCH message being determined based on a first radio network temporary identity (RNTI). The method further includes transmitting the request message.

[0011] According to an example embodiment, the method further includes obtaining a response message for random access based on a second RNTI, where the first RNTI and the second RNTI are the same.

[0012] According to an example embodiment, the method further includes obtaining a response message for random access based on a second RNTI, where the first RNTI and the second RNTI are different.

[0013] According to an example embodiment, the second RNTI is determined based on a radio resource control (RRC) status of the terminal device.

[0014] According to an example embodiment, the RRC status includes a connected mode.

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

[0016] According to an example embodiment, the first RNTI is utilized to scramble the coded bits of the PUSCH message.

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

[0018] According to an example embodiment, the first RNTI and / or the second RNTI are determined based on a numbering of a set of Physical Random Access Channel (PRACH) occasions.

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

[0020] According to a second aspect of the present disclosure, there is provided a method in a network node, the method including determining a response message based on a second RNTI, the method further including transmitting the response message to a terminal device.

[0021] According to an example embodiment, the method further includes obtaining, from the terminal device, a request message including a preamble and a Physical Uplink Shared Channel (PUSCH) message based on a first Radio Network Temporary Identity (RNTI), where the first RNTI and the second RNTI are the same.

[0022] According to an example embodiment, the method further includes obtaining, from the terminal device, a request message including a preamble and a Physical Uplink Shared Channel (PUSCH) message based on a first Radio Network Temporary Identity (RNTI), the first RNTI being different from the second RNTI.

[0023] According to an example embodiment, the second RNTI is determined based on a radio resource control (RRC) status of the terminal device.

[0024] According to an example embodiment, the RRC status includes a connected mode.

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

[0026] According to an example embodiment, the first RNTI is utilized to scramble the coded bits of the PUSCH message.

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

[0028] According to an example embodiment, the first RNTI and / or the second RNTI are determined based on a numbering of a set of Physical Random Access Channel (PRACH) occasions.

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

[0030] According to a third aspect of the present disclosure, there is provided a terminal device, comprising: a non-transitory computer-readable medium having computer-executable instructions stored thereon; and a processor coupled to the non-transitory computer-readable medium, the computer-executable instructions causing the terminal device to implement the method of the first aspect of the present disclosure.

[0031] According to a fourth aspect of the present disclosure, there is provided a network node comprising a non-transitory computer-readable medium having computer-executable instructions stored thereon and a processor coupled to the non-transitory computer-readable medium, the computer-executable instructions causing the network node to implement the method of the second aspect of the present disclosure.

[0032] According to a fifth aspect of the present disclosure, a method in a terminal device is provided. The method includes determining a request message for random access, the request message including a preamble and a Physical Uplink Shared Channel (PUSCH) message, the PUSCH message being determined based on a first Radio Network Temporary Identity (RNTI). The method further includes transmitting the request message.

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

[0034] According to an example embodiment, the first RNTI and / or the second RNTI are determined based on a radio resource control (RRC) status of the terminal device.

[0035] According to an example embodiment, the RRC status includes an idle mode, a connected mode, and an inactive mode.

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

[0037] According to an example embodiment, 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.

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

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

[0040] According to an example embodiment, the CS-RNTI is selected based on at least one of one or more of the preamble indices, one or more physical random access channel (PRACH) occasions, the preamble format, PUSCH parameters, and the purpose of the terminal device's radio access (RA) attempt.

[0041] According to an example embodiment, the first RNTI is utilized to scramble the coded bits of the PUSCH message.

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

[0043] According to an example embodiment, the first RNTI and / or the second RNTI is determined based on at least one of a numbering of a set of physical random access channel (PRACH) occasions, a numbering of a set of preambles, a numbering of a set of PUSCH occasions, and a set of RNTI values, and is determined based on the numbering of the RNTI values ​​in the set.

[0044] According to an example embodiment, the numbering of the RNTI values ​​is configured based on at least one of: an order of preamble indices associated with the RNTI value in a PRACH occasion; an order of frequency resource indices of the PRACH occasion associated with the RNTI value; an order of time resource indices of the PRACH occasion associated with the RNTI value; and an order of indices for the PRACH slots associated with the RNTI value.

[0045] According to an example embodiment, the set of RNTI values ​​is determined based on at least one of the utilized frequency band, 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.

[0046] According to a sixth aspect of the present disclosure, a method in a terminal device is provided. The method includes determining a request message for random access, the request message including a preamble and a Physical Uplink Shared Channel (PUSCH) message, the PUSCH message being determined based on an identity (ID) of a cell in which the terminal device is located. The method further includes transmitting the request message.

[0047] According to an example embodiment, the method further includes obtaining (310) a response message for random access based on a second RNTI, where the second RNTI is determined based on an ID of the terminal device.

[0048] According to a seventh aspect of the present disclosure, there is provided a method in a network node, the method including determining a response message based on a second RNTI, the method further including transmitting the response message to a terminal device.

[0049] According to an example embodiment, the method further includes obtaining, from the terminal device, a request message including a preamble and a Physical Uplink Shared Channel (PUSCH) message based on a first Radio Network Temporary Identity (RNTI), where the first RNTI and the second RNTI are the same or different.

[0050] According to an example embodiment, the first RNTI and / or the second RNTI are determined based on a radio resource control (RRC) status of the terminal device.

[0051] According to an example embodiment, the RRC status includes an idle mode, a connected mode, and an inactive mode.

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

[0053] According to an example embodiment, 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.

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

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

[0056] According to an example embodiment, the CS-RNTI is selected based on at least one of one or more of the preamble indices, one or more physical random access channel (PRACH) occasions, the preamble format, PUSCH parameters, and the purpose of the terminal device's radio access (RA) attempt.

[0057] According to an example embodiment, the first RNTI is utilized to scramble the coded bits of the PUSCH message.

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

[0059] According to an example embodiment, the method further includes obtaining, from the terminal device, a request message including a preamble and a PUSCH message based on an identity (ID) of a cell in which the terminal device is located.

[0060] According to an example embodiment, the first RNTI and / or the second RNTI are determined based on an ID of the terminal device.

[0061] According to an example embodiment, the first RNTI and / or the second RNTI is determined based on at least one of a numbering of a set of physical random access channel (PRACH) occasions, a numbering of a set of preambles, a numbering of a set of PUSCH occasions, and a set of RNTI values, and is determined based on the numbering of the RNTI values ​​in the set.

[0062] According to an example embodiment, the numbering of the RNTI values ​​is configured based on at least one of: an order of preamble indices associated with the RNTI value in a PRACH occasion; an order of frequency resource indices of the PRACH occasion associated with the RNTI value; an order of time resource indices of the PRACH occasion associated with the RNTI value; and an order of indices for the PRACH slots associated with the RNTI value.

[0063] According to an example embodiment, the set of RNTI values ​​is determined based on at least one of the utilized frequency band, 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.

[0064] According to an eighth aspect of the present disclosure, there is provided a terminal device, comprising: a non-transitory computer-readable medium having stored thereon computer-executable instructions; and a processor coupled to the non-transitory computer-readable medium, the computer-executable instructions causing the terminal device to implement a method according to the fifth aspect of the present disclosure.

[0065] According to a ninth aspect of the present disclosure, there is provided a network node comprising a non-transitory computer-readable medium having computer-executable instructions stored thereon and a processor coupled to the non-transitory computer-readable medium, the computer-executable instructions causing the network node to implement a method according to the seventh aspect of the present disclosure.

[0066] According to a tenth aspect of the present disclosure, a method in a terminal device is provided, the method including: obtaining a response message for random access based on a second Radio Network Temporary Identity (RNTI), the response message being a response to a request message for random access, the request message including a preamble and a Physical Uplink Shared Channel (PUSCH) message.

[0067] According to an example embodiment, the PUSCH message is determined based on a first RNTI, where the first RNTI and the second RNTI are the same or different.

[0068] According to an example embodiment, the first RNTI and / or the second RNTI are determined based on a radio resource control (RRC) status of the terminal device.

[0069] According to an example embodiment, the RRC status includes an idle mode, a connected mode, and an inactive mode.

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

[0071] According to an example embodiment, 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.

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

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

[0074] According to an example embodiment, the CS-RNTI is selected based on at least one of one or more of the preamble indices, one or more physical random access channel (PRACH) occasions, the preamble format, PUSCH parameters, and the purpose of the terminal device's radio access (RA) attempt.

[0075] According to an example embodiment, the first RNTI is utilized to scramble the coded bits of the PUSCH message.

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

[0077] According to an example embodiment, the method further includes determining a request message including a preamble and a PUSCH message based on an identity (ID) of a cell in which the terminal device is located.

[0078] According to an example embodiment, the first RNTI and / or the second RNTI are determined based on an ID of the terminal device.

[0079] According to an example embodiment, the first RNTI and / or the second RNTI is determined based on at least one of a numbering of a set of physical random access channel (PRACH) occasions, a numbering of a set of preambles, a numbering of a set of PUSCH occasions, and a set of RNTI values, and is determined based on the numbering of the RNTI values ​​in the set.

[0080] According to an example embodiment, the numbering of the RNTI values ​​is configured based on at least one of: an order of preamble indices associated with the RNTI value in a PRACH occasion; an order of frequency resource indices of the PRACH occasion associated with the RNTI value; an order of time resource indices of the PRACH occasion associated with the RNTI value; and an order of indices for the PRACH slots associated with the RNTI value.

[0081] According to an example embodiment, the set of RNTI values ​​is determined based on at least one of the utilized frequency band, 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.

[0082] According to an eleventh aspect of the present disclosure, there is provided a method in a network node, the method including: obtaining, from a terminal device, a request message including a preamble and a Physical Uplink Shared Channel (PUSCH) message based on a first Radio Network Temporary Identity (RNTI).

[0083] According to an example embodiment, the method further includes determining a response message based on the second RNTI. The method further includes transmitting the response message to the terminal device.

[0084] According to an example embodiment, the first RNTI and / or the second RNTI are determined based on a radio resource control (RRC) status of the terminal device.

[0085] According to an example embodiment, the RRC status includes an idle mode, a connected mode, and an inactive mode.

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

[0087] According to an example embodiment, 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.

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

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

[0090] According to an example embodiment, the CS-RNTI is selected based on at least one of one or more of the preamble indices, one or more physical random access channel (PRACH) occasions, the preamble format, PUSCH parameters, and the purpose of the terminal device's radio access (RA) attempt.

[0091] According to an example embodiment, the first RNTI is utilized to scramble the coded bits of the PUSCH message.

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

[0093] According to an example embodiment, the first RNTI and / or the second RNTI are determined based on an ID of the terminal device.

[0094] According to an example embodiment, the first RNTI and / or the second RNTI is determined based on at least one of a numbering of a set of physical random access channel (PRACH) occasions, a numbering of a set of preambles, a numbering of a set of PUSCH occasions, and a set of RNTI values, and is determined based on the numbering of the RNTI values ​​in the set.

[0095] According to an example embodiment, the numbering of the RNTI values ​​is configured based on at least one of: an order of preamble indices associated with the RNTI value in a PRACH occasion; an order of frequency resource indices of the PRACH occasion associated with the RNTI value; an order of time resource indices of the PRACH occasion associated with the RNTI value; and an order of indices for the PRACH slots associated with the RNTI value.

[0096] According to an example embodiment, the set of RNTI values ​​is determined based on at least one of the utilized frequency band, 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.

[0097] According to a twelfth aspect of the present disclosure, there is provided a method in a network node, the method including obtaining, from a terminal device, a request message including a preamble and a Physical Uplink Shared Channel (PUSCH) message based on a cell in which the terminal device is located.

[0098] According to an example embodiment, the method further includes determining a response message based on the RNTI. The method further includes transmitting the response message to a terminal device, the RNTI being determined based on an ID of the terminal device.

[0099] According to a thirteenth aspect of the present disclosure, there is provided a terminal device, comprising: a non-transitory computer-readable medium having stored thereon computer-executable instructions; and a processor coupled to the non-transitory computer-readable medium, the computer-executable instructions causing the terminal device to implement a method according to the tenth aspect of the present disclosure.

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

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

[0102] According to a sixteenth aspect of the present disclosure, there is provided a terminal device, comprising: a non-transitory computer-readable medium having stored thereon computer-executable instructions; and a processor coupled to the non-transitory computer-readable medium, the computer-executable instructions causing the terminal device to implement a method according to the sixth aspect of the present disclosure.

[0103] According to a seventeenth aspect of the present disclosure, there is provided a non-transitory computer readable medium having program code embodied thereon for use with a computing device, the program code which, when executed by a processor, performs a method according to any of the first, second, fifth, sixth, seventh, tenth, eleventh and twelfth aspects of the present disclosure.

[0104] According to another aspect of the present disclosure, there is provided a method implemented in a communication system that 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 initiating a transmission at the host computer conveying the user data to the UE via a cellular network comprising a base station that may perform any step of the method according to any of the second, seventh, eleventh, and twelfth aspects of the present disclosure.

[0105] According to another aspect of the present disclosure, there is provided a communication system including a host computer. The host computer may comprise 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 comprise a base station having a wireless interface and a processing circuit. The processing circuit of the base station may be configured to perform any step of a method according to any of the second, seventh, eleventh and twelfth aspects of the present disclosure.

[0106] According to another aspect of the present disclosure, there is provided a method implemented in a communication system that 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 initiating a transmission at the host computer carrying the user data to the UE via a cellular network including the base station. The UE may perform any step of the method according to any of the first, fifth, sixth, and tenth aspects of the present disclosure.

[0107] According to another aspect of the present disclosure, there is provided a communication system including a host computer. The host computer may comprise 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 comprise a wireless interface and a processing circuit. The processing circuit of the UE may be configured to perform any step of a method according to any of the first, fifth, sixth, and tenth aspects of the present disclosure.

[0108] According to another aspect of the present disclosure, there is provided a method implemented in a communication system that may include a host computer, a base station, and a UE, the method may include receiving, at the host computer, user data transmitted from the UE to the base station, the UE being capable of performing any step of the method according to any of the second, seventh, eleventh, and twelfth aspects of the present disclosure.

[0109] According to another aspect of the present disclosure, there is provided a communication system including a host computer. The host computer may comprise a communication interface configured to receive user data originating from a transmission from a UE to a base station. The UE may comprise a wireless interface and a processing circuit. The processing circuit of the UE may be configured to perform any step of a 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, there is provided a method implemented in a communication system that may include a host computer, a base station, and a UE. The method may include receiving, at the host computer, from the base station, user data originating from a transmission received by the base station from the UE. The base station may perform any step 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, there is provided a communication system that may include a host computer. The host computer may comprise a communication interface configured to receive user data originating from a transmission from a UE to a base station. The base station may comprise a wireless interface and a processing circuit. The processing circuit of the base station may be configured to perform any step of the method according to any of the second, seventh, eleventh and twelfth aspects of the present disclosure.

[0112] According to another aspect of the present disclosure, a terminal device is provided, comprising: a determining unit for determining a request message for random access, the request message including a preamble and a Physical Uplink Shared Channel (PUSCH) message, the PUSCH message being determined based on a first Radio Network Temporary Identity (RNTI), and a transmitting unit for transmitting the request message (308).

[0113] According to another aspect of the present disclosure, a terminal device is provided, comprising: a determining unit for determining a request message for random access, the request message including a preamble and a Physical Uplink Shared Channel (PUSCH) message, the PUSCH message being determined based on an identity (ID) of a cell in which the terminal device is located; and a transmitting unit for the request message.

[0114] According to another aspect of the present disclosure, a network node is provided, comprising: a determining unit for determining a response message based on a second RNTI, and transmitting the response message to a terminal device.

[0115] According to another aspect of the present disclosure, a terminal device is provided, comprising: a determining unit for obtaining a response message for random access based on a second Radio Network Temporary Identity (RNTI), the response message being a response to a request message for random access, the request message including a preamble and a Physical Uplink Shared Channel (PUSCH) message.

[0116] According to another aspect of the present disclosure, a network node is provided, comprising: an obtaining unit for obtaining, from a terminal device, a request message including a preamble and a Physical Uplink Shared Channel (PUSCH) message based on a first Radio Network Temporary Identity (RNTI).

[0117] According to another aspect of the present disclosure, there is provided a network node, comprising: an obtaining unit for obtaining, from a terminal device, a request message including a preamble and a Physical Uplink Shared Channel (PUSCH) message based on a cell in which the terminal device is located.

[0118] The disclosure itself, preferred mode of use and further objects will best be understood by reference to the following detailed description of the embodiments when read in conjunction with the accompanying drawings. [Brief description of the drawings]

[0119] [Figure 1] A diagram showing a four-step random access procedure in NR. [Diagram 2] A diagram showing a two-step random access procedure in NR. [Diagram 3] 3 is a flowchart illustrating a method 300 according to certain embodiments described throughout this disclosure. [Figure 4] 4 is a flowchart illustrating a method 400 according to certain embodiments described throughout this disclosure. [Diagram 5] 5 is a flowchart illustrating a method 500 according to some embodiments described throughout this disclosure. [Figure 6] FIG. 13 is an example diagram illustrating RNTI ordering in the time and frequency domain across different PRACH occasions. [Figure 7] FIG. 13 shows that 64 preamble indexes are used in each of two frequency multiplexed PRACH occasions. [Figure 8] 8 is a flowchart illustrating a method 800 according to some embodiments described throughout this disclosure. [Figure 9] 9 is a block diagram illustrating a terminal device 900 according to some embodiments described throughout this disclosure. [Figure 10] FIG. 10 is a block diagram illustrating a network node 1000 according to certain embodiments described throughout this disclosure. [Figure 11] 1 is a block diagram illustrating a communication network connected to a host computer through an intermediate network in accordance with some embodiments of the present disclosure. [Figure 12]FIG. 2 is a block diagram illustrating a host computer communicating with a UE via a base station over a partial wireless connection in accordance with some embodiments of the present disclosure. [Figure 13] 1 is a flowchart illustrating a method implemented in a communication system according to one embodiment of the present disclosure. [Figure 14] 1 is a flowchart illustrating a method implemented in a communication system according to one embodiment of the present disclosure. [Figure 15] 1 is a flowchart illustrating a method implemented in a communication system according to one embodiment of the present disclosure. [Figure 16] 1 is a flowchart illustrating a method implemented in a communication system according to one embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0120] The embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. It should be understood that these embodiments are not intended to imply any limitation on the scope of the present disclosure, but are merely discussed for the purpose of enabling those skilled in the art to better understand and therefore implement the present disclosure. References to features, advantages, or similar phrases throughout this specification do not imply that all of the features and advantages that may be realized with the present disclosure should or are in a single embodiment of the present disclosure. Rather, phrases referring to features and advantages should be understood to mean that a particular feature, advantage, or characteristic described with respect to an embodiment is included in at least one embodiment of the present disclosure. Furthermore, the described features, advantages, and characteristics of the present disclosure may be combined in any suitable manner in one or more embodiments. Those skilled in the art will recognize that the present disclosure may be practiced without one or more of the specific features or advantages of a specific embodiment. In other cases, additional features and advantages that may not be present in all embodiments of the present disclosure may be recognized in some embodiments.

[0121] As used herein, the term "communications network" refers to a network conforming to any suitable communications standard, such as New Radio (NR), long term evolution (LTE), LTE-Advanced, wideband code division multiple access (WCDMA), high speed packet access (HSPA), etc. Furthermore, communications between terminal devices and network nodes in a communications network may be performed according to any suitable generation of communications protocol, including, but not limited to, a first generation (1G) communications protocol, a second generation (2G) communications protocol, a 2.5G communications protocol, a 2.75G communications protocol, a third generation (3G) communications protocol, a 4G communications protocol, a 4.5G communications protocol, a 5G communications protocol, and / or any other protocol now known or to be developed in the future.

[0122] The term "network node" refers to a network device in a communication network through which a terminal device accesses the communication network and receives services from the communication 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 (Node B or NB), an evolved Node B (eNode B or eNB), a next generation Node B (gNode B or gNB), an IAB node, a remote radio unit (RRU), a radio header (RH), a remote radio head (RRH), a relay, a low power node such as femto, pico, etc.

[0123] Still further examples of network nodes comprise Multi-Standard Radio (MSR) radio equipment such as MSR BS, network controllers such as Radio Network Controllers (RNC) or Base Station Controllers (BSC), base transceiver stations (BTS), transmission points, transmitting nodes, positioning nodes, etc. However, more generally, a network node may represent any suitable device (or group of devices) capable, configured, configured to, and / or operable to enable and / or provide terminal device access to a wireless communication network or to provide some service to terminal devices that have accessed the wireless communication network.

[0124] The term "terminal device" refers to any end device capable of accessing and receiving services from a communication network. By way of example and not limitation, a terminal device may refer to 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 gaming terminal device, a music storage and playback appliance, a mobile phone, a cellular phone, a smartphone, a tablet, a wearable device, a personal digital assistant (PDA), a vehicle, and the like.

[0125] As yet another specific example, in an Internet of Things (IoT) scenario, a terminal device, sometimes referred to as an IoT device, may represent a machine or other device that performs monitoring, sensing, and / or measurement, etc., and transmits results of such monitoring, sensing, and / or measurement, etc. to another terminal device and / or network equipment. The terminal device, in this case, may be a Machine-to-Machine (M2M) device, which may be referred to in a 3rd Generation Partnership Project (3GPP) context as a Machine-Type Communication (MTC) device.

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

[0127] As used herein, the terms "first", "second", etc. refer to different elements. The singular forms "a" and "an" are intended to include the plural unless the context clearly indicates otherwise. As used herein, the terms "comprises", "comprising", "has", "having", "includes" and / or "including" specify the presence of stated features, elements, and / or components, etc., but do not preclude the presence or addition of one or more other features, elements, components, and / or combinations thereof. The term "based on" should be read as "based at least in part on". The terms "one embodiment" and "an embodiment" should be read as "at least one embodiment". The term "another embodiment" should be read as "at least one other embodiment". Other provisions, both explicit and implicit, may be included below.

[0128] As described above, in the two-step random access procedure shown in FIG. 2, the preamble and the PUSCH message are transmitted by the UE in one message, called message A, and then the UE receives a response message, called message B, from the gNB. However, for the PUSCH message in message A, there is no TC-RNTI available for PUSCH handling, since no RAR message is received from the gNB. Furthermore, in message A, for each preamble, different RNTI values ​​for PUSCH may be required to avoid collision of PUSCH between different messages A, especially when two or more PUSCHs are on the same timing frequency resource. Furthermore, different RNTIs need to be used to distinguish between message 2 in the four-step random access procedure and message B in the two-step random access procedure. Therefore, it would be desirable to provide a solution for determining RNTIs for PUSCH in message A and / or PDCCH CRC scrambling and PDSCH scrambling in message B in the two-step random access procedure.

[0129] According to some example embodiments described throughout the present disclosure, the present disclosure provides improved solutions for a two-step random access procedure. These solutions may 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 may determine an RNTI to be used for a PUSCH in a request message (e.g., message A) based on broadcasted system information, and then the terminal device may transmit the request message based on the determined RNTI. With the improved solution, an RNTI to be used for a PUSCH in message A and / or PDCCH CRC scrambling and PDSCH scrambling in message B may be determined.

[0130] It should be noted that some embodiments of the present disclosure are described primarily with respect to the 5G specification, which is used as a non-limiting example for some exemplary network configurations and system deployments. Thus, the description of the exemplary embodiments given herein will refer in detail to terminology directly related to those embodiments. Such terminology is used only in the context of the presented non-limiting examples and embodiments, and of course does not limit the present disclosure in any way. Rather, any other system configuration or wireless technology may be equally utilized as long as the exemplary embodiments described herein are applicable.

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

[0132] According to the example method 300 shown in FIG. 3, the terminal device may determine a preamble of a request message for a two-step random access procedure, as shown in block 302. In some embodiments, the preamble may be determined according to a set of preambles. The set of preambles may be unique for the two-step random access procedure. Alternatively, the set of preambles may be the same as the set of preambles 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.

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

[0134] After determining the RNTI in block 304, in block 306, the terminal device may generate a PUSCH message based on the determined first RNTI. In general, the determined first RNTI is utilized to scramble the coded bits of the PUSCH message. The request message may include the preamble determined in block 302 and a PUSCH message. The preamble may be transmitted in a PRACH occasion, and the PUSCH message may be transmitted in a PUSCH occasion. Then, a request message including the preamble and the PUSCH message is determined. Then, in block 308, the terminal device may transmit a request message (i.e., message A) to the network node in a two-step random access procedure.

[0135] In response to transmitting the request message, the terminal device may obtain a response message (e.g., message B) based on the second RNTI from the network node, as shown in block 310. In particular, the terminal device may utilize the second RNTI to receive a physical downlink control channel (PDCCH) message that schedules a physical downlink shared channel (PDSCH) that carries the response message. The second RNTI may be the same as the first RNTI 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. In particular, the network node may select the second RNTI (e.g., RA-RNTI) from a group of possibilities using a hash or a subset of bits of the first RNTI used in message A. The function / mapping relationship between the first and second RNTIs allows the network node and the terminal device to efficiently distinguish message B in a two-step random access procedure from message 2 in a four-step random access procedure. 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 to scramble the CRC of the PDCCH message for message B.

[0136] FIG. 4 is a flowchart illustrating a method 400 according to some embodiments described throughout the present disclosure. The method 400 illustrated in FIG. 4 may be performed by an apparatus implemented in a terminal device or communicatively coupled to a terminal device. According to an exemplary embodiment, the terminal device may be a UE. In the following description of FIG. 4, detailed descriptions of parts that are the same as or similar to those in the previous exemplary embodiment are appropriately omitted.

[0137] According to the example method 400 shown in FIG. 4, the terminal device may determine a preamble of a request message for a two-step random access procedure, as shown in block 402. In block 403, the terminal device may determine whether a C-RNTI is available. If the C-RNTI is available, the terminal device may utilize the C-RNTI itself as the first RNTI, as shown in block 404. For example, if the terminal device is in an RRC connected mode and is used to implement contention-free random access (CFRA), the terminal device has a C-RNTI. Thus, the terminal device may use the C-RNTI as the first RNTI.

[0138] If the C-RNTI is not available, in block 405, the terminal device selects one of the multiple CS-RNTIs in the broadcasted system information based on the preamble determined in block 402. For example, when the terminal device is in an idle mode, the terminal device does not possess a valid C-RNTI. Thus, the terminal device may select one of the multiple CS-RNTIs as the first RNTI. The terminal device may select one of the multiple CS-RNTIs based on at least one of an index of the determined preamble, a physical random access channel (PRACH) occasion of the determined preamble, a format of the determined preamble, a PUSCH parameter, and a purpose of a radio access (RA) attempt of the terminal device. It should be noted that the CS-RNTI may have one or more RNTI values ​​that may be configured cell-specific. The CS-RNTI value may be provided in the broadcasted system information (e.g., in the RMSI or OSI). The terminal device selects an actual CS-RNTI value to be used from a set of multiple configured values.

[0139] According to an example embodiment, the RNTI may depend on the RRC status. The RRC status includes idle mode, connected mode, and inactive mode. For example, when a terminal device is in an inactive mode and performing contention-based random access (CBRA), the terminal device may use a CS-RNTI based on its C-RNTI, e.g., a function of some bits in the C-RNTI. This reduces the blind decoding complexity for the network node compared to tentatively detecting the C-RNTIs of all inactive terminal devices in the system or tracking area. In an embodiment, if one or more UE attempts using a C-RNTI or a C-RNTI-based CS-RNTI are unsuccessful, it may revert to the above approach of the UE not possessing a valid C-RNTI for subsequent attempts.

[0140] After determining the RNTI in block 404 or 405, in block 406, the terminal device may generate a PUSCH message based on the determined RNTI (i.e., the first RNTI). Generally, the determined RNTI is used to scramble a PUSCH payload for a request message (message A) in a two-step random access procedure. Then, in block 408, the terminal device may transmit a request message (e.g., message A) to a network node in a two-step random access procedure. The request message may include the preamble determined in block 402 and the PUSCH message generated in block 406. In one embodiment, the network node may detect the PUSCH message after detecting the preamble in the request message and use the configuration information obtained by the preamble to receive the PUSCH message. In another embodiment, the network node may blindly decode the PUSCH message based on multiple possible CS-RNTI values ​​without needing to detect the preamble in the request message (e.g., when the current transmission is a retransmission of the request message without retransmitting the preamble).

[0141] 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, as shown in block 410. The network node selects the second RNTI used to scramble the CRC of the PDCCH message for message B in the two-step random access procedure based on the received RNTI derived from the PUSCH message. In this embodiment, the network node uses the RNTI (e.g., C-RNTI or CS-RNTI) used by the terminal device in the PUSCH message (message A) to scramble the CRC of the PDCCH message for message B. The network node detects the CS-RNTI based on the received preamble of the request message or based on blind detection of the PUSCH message of the request message. That RNTI then functionally becomes the new RA-RNTI for the given network node. Alternatively, the new RA-RNTI may be formed not as a copy of the C-RNTI or CS-RNTI used in the request message, but as a function / mapping of that C-RNTI or CS-RNTI, for example using a hash or subset of the bits of the RNTI used in the request message to select an RA-RNTI from a group of possibilities.

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

[0143] According to the example method 500 shown in FIG. 5, the terminal device may select a first preamble from a set of preambles for the request message, as shown in block 502. The set of preambles may be unique for a two-step random access procedure. Alternatively, the set of preambles may be the same as the set of preambles 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.

[0144] In block 504, the terminal device may determine a first RNTI, which may be referred to as a TS-RNTI (two-step RNTI), based on at least one of the numbering of a set of physical random access channel (PRACH) occasions, the numbering of a set of preambles, the numbering of a set of PUSCH occasions, and the set of RNTI values, as well as based on the numbering of the RNTI values ​​in the set.

[0145] After determining the RNTI in block 504, the terminal device may generate a PUSCH message based on the determined first RNTI in block 506. In general, the determined first RNTI is utilized to scramble the coded bits of the PUSCH message. Then, in block 508, the terminal device may transmit a request message (i.e., message A) to the network node in a two-step random access procedure. The request message may include the preamble determined in block 502 and the PUSCH message generated in block 506. The preamble may be transmitted in a PRACH occasion, and the PUSCH message may be transmitted in a PUSCH occasion. In response to transmitting the request message, the terminal device may receive a response message (e.g., message B) based on the second RNTI from the network node, as shown in block 510.

[0146] In some embodiments, the order of the RNTI values ​​is configured based on at least one of the following: an order of preamble indices associated with the RNTI value in the PRACH occasion, an order of frequency resource indices of the PRACH occasion associated with the RNTI value, an order of time resource indices of the PRACH occasion associated with the RNTI value, an order of indexes for the PRACH slot associated with the RNTI value. It should be noted that the first RNTI used in the two-step random access procedure is designed differently from the RA-RNTI and therefore does not collide with the RA-RNTI.

[0147] FIG. 6 is an example illustrating RNTI ordering in time and frequency domain across different PRACH occasions. First, the order of RNTI values ​​is configured based on the increasing order of preamble indexes in the PRACH occasions (e.g., RNTI value indexes 0, 1, 2 in PRACH occasion OC1). Second, the order of RNTI values ​​is configured based on the increasing order of frequency resource indexes of the PRACH occasions (e.g., RNTI value indexes 3, 4, 5 in PRACH occasion OC2, where the frequency resources of PRACH occasion OC2 are higher than those of PRACH occasion OC1). Third, the order of RNTI values ​​is configured based on the increasing order of time resource indexes of the PRACH occasions (e.g., RNTI value indexes 6, 7, 8 in PRACH occasion OC3, where the time slots of PRACH occasion OC3 are higher than those of PRACH occasion OC1). Fourth, the order of RNTI values ​​is configured based on the increasing order of indexes for the PRACH slots (e.g., RNTI value indexes 0-11 are in PRACH slot 1, and RNTI value indexes 12-23 are in PRACH slot 2). FIG. 6 is an example showing three indices (0-2) of preambles configured in every PRACH occasion and RNTI for the first eight PRACH occasions. Note that ordering can also be done in any other specified order, e.g., frequency resource, time resource, preamble resource. The determined order can be either pre-determined or RRC-configured. In this embodiment, the terminal device can calculate the RNTI when a selected preamble is transmitted. In the same embodiment, the network node can calculate the RNTI when the network node receives a specific preamble on a specific PRACH occasion.

[0148] It is also possible to use only a subset of the indices, e.g., ordering based on the preamble index and the frequency index for the frequency multiplexed PRACH. This is shown in Figure 7, where 64 preamble indices (0 to 63) are used in each of the two frequency multiplexed PRACH occasions. This gives 0 to 127 as possible first RNTIs. The PUSCH occasions are also linked to the preamble and PRACH occasions, e.g., the first 32 indices in each PRACH occasion map to a PUSCH occasion with a lower frequency index. In this embodiment, RNTI indices 0 to 63 are configured in the first PRACH occasion, and RNTI indices 64 to 127 are configured in the second PRACH occasion. Next, message A (Msg A) transmitted on PUSCH occasion 0 is scrambled with RNTI indices 0 to 31 in accordance with the selected preamble, Msg A transmitted on PUSCH occasion 1 is scrambled with RNTI indices 32 to 63 in accordance with the selected preamble, Msg A transmitted on PUSCH occasion 3 is scrambled with RNTI indices 64 to 95 in accordance with the selected preamble, and finally, Msg A transmitted on PUSCH occasion 3 is scrambled with RNTI indices 96 to 127 in accordance with the selected preamble.

[0149] In an embodiment, the set of RNTI values ​​is determined based on at least one of the utilized frequency band, the time gap between the first preamble and the PUSCH, the timing / frequency resource of the request message, and the ID of the terminal device.

[0150] Regarding frequency bands, for example, in unlicensed bands, the RA-RNTI or modified RA-RNTI may not be used for the TS-RNTI because the RA-RNTI may not be available when the network node is preparing the PUSCH while waiting for the LBT for the transmission of the preamble in message A. Or, to avoid the problem that the RA-RNTI is not available, the RA-RNTI is always generated, for example, based on the RO of the first LBT. In licensed bands, the TS-RNTI may be either the RA-RNTI or modified RA-RNTI, or a new defined RNTI.

[0151] Regarding the time gap between the first preamble and PUSCH, for example, when the gap is equal to or greater than a threshold, the RA-RNTI or modified RA-RNTI may be applied for message A and message B transmission in the two-step random access procedure, and otherwise an RNTI unrelated to the RA-RNTI is used. The threshold may be either predetermined or signaled in RRC signaling, which is not limited here. Furthermore, the RNTI for message A scrambling may depend more directly on the time distance between the preamble and PUSCH. The dependence may be based on the time in seconds between the preamble and PUSCH, and / or the number of OFDM symbols and / or slots, and / or the number of PRACH occasions (in time and / or frequency) between the preamble and PUSCH.

[0152] With respect to 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 especially preferred when message A PUSCHs from different terminal devices have different PUSCH occasions, resulting in different terminal devices using different RNTIs. Furthermore, if the preamble position in time can be determined from the PUSCH position in time (e.g., if the configuration is such that the PUSCH immediately follows the preamble or with a time gap smaller than a given threshold, see previous subsection), the RNTI for message A scrambling may be time independent, while in other cases the RNTI for message A scrambling may be time dependent. When / if the message A RNTI is time independent, the message B RNTI may still be time dependent. As a special case, the message A RNTI may be equivalent to the message B RNTI, except that the time dependency is omitted. The gap thresholds mentioned above (also in the previous subsection) may be predetermined in the specification and / or either explicitly signaled or implied by other signaling, e.g., the PRACH configuration index. Instead of basing the scrambling selection on the time gap threshold, the selection may be signaled.

[0153] With respect to the terminal device ID, the terminal device ID itself or some RNTI mapped from the terminal device ID may be used for scrambling message B. An example of a detailed design of a terminal device ID-based TS-RNTI to ensure that message B is scrambled by a value different from message 2 (scrambled by RA-RNTI) is provided as follows:

[0154] The space of possible RA-RNTI values ​​is about 18000 values ​​(most of them unused in the configuration). If the scrambling is done 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 ID of the terminal device are used as the 15 LSB bits, and the MSB bit of TS-RNTI is set to 1 to ensure that the number is higher than 18000, and is higher than and close to the maximum value of 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 one embodiment of the present disclosure. TIFF0007634335000002.tif56170

[0155] FIG. 8 is a flowchart illustrating a method 800 according to some embodiments described throughout the disclosure. The method 800 illustrated in FIG. 8 may be performed by an apparatus implemented in a network node or communicatively coupled to a network node. According to an exemplary embodiment, the network node may be a base station, for example, a gNB. In the following description of FIG. 8, detailed descriptions of parts that are the same as or similar to parts in the previous exemplary embodiment are appropriately omitted.

[0156] According to an example method 800 shown in FIG. 8, a network node may receive a request message including a preamble and a PUSCH message in a two-step random access procedure, as shown in block 802. The PUSCH message is received based on a first Radio Network Temporary Identity (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.

[0157] In one embodiment, the network node uses the identity (ID) of the cell in which the terminal device is located to determine the RNTI for scrambling the CRC of the PDCCH that schedules msgB, or the "msgB RA-RNTI". The ID of the terminal device is carried in the PUSCH message of message A. In some embodiments, the terminal device scrambles the PUSCH message carried in the payload of message A with the cell identity in addition to transmitting its UE ID (such as the C-RNTI or UE contention resolution identity) 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. Thus, in such an embodiment, it is not necessary to blindly decode the PUSCH with multiple scrambling hypotheses 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 that C-RNTI, e.g., using a hash or a subset of the bits of the msgA RNTI to select an RA-RNTI from a group of possibilities. Similarly, in some embodiments where Message A carries a UE Contention Resolution Identity or a CCCH SDU that has more bits than the Message B RA-RNTI, the terminal device may use either a subset of the bits or a hash of the bits in the UE Contention Resolution Identity to create the msgB RA-RNTI. In some embodiments, the UE Contention Resolution Identity is derived from the CCCH SDU as described in 3GPP TS38.321 rev.15.4.0 subclause 6.1.3.3.The scrambling sequence generation for the PUSCH may be performed using a modification of 3GPP TS38.211 rev.15.4.0 subclause 6.3.1.1, the disclosure of which is incorporated herein by reference in its entirety, such that when the PUSCH is used for transmission of message A, the scrambling sequence generator is initialized with the cell ID. JPEG0007634335000003.jpg9170, otherwise the Rel-15 mechanism is used.

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

[0159] The various blocks illustrated in Figures 3-5 and 8 may be considered as multiple coupled logic circuit elements constructed to perform method steps and / or operations resulting from the operation of computer program code and / or related function(s). The schematic flow chart diagrams described above are generally described as logical flow chart diagrams. Thus, the illustrated order and labeled steps are indicative of particular embodiments of the presented method. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more steps, or portions thereof, of the illustrated method. Furthermore, the order in which a particular method is performed may or may not strictly follow the order of the corresponding steps shown.

[0160] 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. As shown in FIG. 9, the terminal device 900 may include a receiving circuit 901, a transmitting circuit 902, one or more processors, such as a processor 903, one or more memories, such as a memory 904, and a non-transitory computer-readable medium 904 having computer-executable instructions stored thereon. 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 operable to perform more or less operations to implement the proposed method according to an exemplary embodiment of the present disclosure.

[0161] FIG. 10 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. As shown in FIG. 10, the network node 1000 may comprise a receiving circuit 1001, a transmitting circuit 1002, one or more processors, such as a processor 1003, one or more memories, such as a memory 1004, and a non-transitory computer-readable medium 1005 having computer-executable instructions stored thereon. 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 operable to perform more or less operations to implement the proposed method according to an exemplary embodiment of the present disclosure.

[0162] FIG. 11 is a block diagram illustrating a communication network connected to a host computer through an intermediate network, according to some embodiments of the present disclosure.

[0163] Referring to Fig. 11, according to one embodiment, a communication system includes a communication network 1110, such as a 3GPP type cellular network, comprising an access network 1111, such as a wireless access network, and a core network 1114. The access network 1111 comprises a number of base stations 1112a, 1112b, 1112c, such as NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 1113a, 1113b, 1113c. Each base station 1112a, 1112b, 1112c can 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 wirelessly connect to the corresponding base station 1112c or to be paged by the corresponding base station 1112c. A second UE 1192 in the coverage area 1113a can 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 one UE is in the coverage area or where only one UE is connected to the corresponding base station 1112.

[0164] The communication network 1110 is itself connected to a host computer 1130, which may be embodied in hardware and / or software of a standalone server, a cloud-implemented server, a distributed server, or as a processing resource in a server farm. The host computer 1130 may be owned or under the control of a service provider, or may be operated by or on behalf of the service provider. The connections 1121 and 1122 between the communication network 1110 and the host computer 1130 may extend directly from the core network 1114 to the host computer 1130, or may proceed through an optional intermediate network 1120. The intermediate network 1120 may be one of a public network, a private network, or a hosted network, or a combination of two or more of them, and the intermediate network 1120 may be a backbone network or the Internet, if any, and in particular the intermediate network 1120 may comprise two or more sub-networks (not shown).

[0165] The communication system of FIG. 11 as a whole enables connectivity between connected UEs 1191, 1192 and a host computer 1130. The connectivity may be described as an over-the-top (OTT) connection 1150. The host computer 1130 and connected UEs 1191, 1192 are configured to communicate data and / or signaling via the OTT connection 1150 using the access network 1111, the core network 1114, any intermediate networks 1120 and possible further infrastructure (not shown) as intermediaries. The OTT connection 1150 may be transparent in the sense that the participating communication devices through which the OTT connection 1150 passes are unaware of the routing of the uplink and downlink communications. For example, the base station 1112 may not be or need not be informed about the past routing of incoming downlink communications involving data originating from the host computer 1130 to be forwarded (e.g., handed over) to the connected UE 1191. Similarly, the base station 1112 does not need to be aware of the future routing of outgoing uplink communications originating from the UE 1191 and destined for the host computer 1130 .

[0166] FIG. 12 is a block diagram illustrating a host computer communicating with a UE via a base station over a partial wireless connection in accordance with some embodiments of the disclosure.

[0167] Next, an exemplary implementation of the UE, base station and host computer described in the previous paragraph according to an embodiment will be described with reference to FIG. 12. In the communication system 1200, the host computer 1210 comprises hardware 1215 including a communication interface 1216 configured to set up and maintain wired or wireless connections with interfaces of different communication devices of the communication system 1200. The host computer 1210 further comprises a processing circuit 1218, which may have storage and / or processing capabilities. In particular, the processing circuit 1218 may comprise one or more programmable processors, application specific integrated circuits, field programmable gate arrays, or combinations thereof (not shown) adapted to execute instructions. The host computer 1210 further comprises software 1211, which is stored in or accessible by the host computer 1210 and is executable by the processing circuit 1218. The software 1211 includes a host application 1212. The host application 1212 may be operable to provide services to a remote user, such as the UE 1230 connecting via an OTT connection 1250 that terminates at the UE 1230 and the host computer 1210. In providing services to the remote user, the host application 1212 may provide user data that is transmitted using the OTT connection 1250.

[0168] The communication system 1200 further includes a base station 1220 provided in the communication system, the base station 1220 comprising hardware 1225 enabling 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 setting up and maintaining wired or wireless connections with interfaces of different communication devices of the communication system 1200, as well as a wireless interface 1227 for setting up and maintaining at least a wireless connection 1270 with a UE 1230 located in a coverage area (not shown in FIG. 12) 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 the connection 1260 may pass through a core network (not shown in FIG. 12) of the communication system and / or one or more intermediate networks outside the communication system. In the illustrated embodiment, the hardware 1225 of the base station 1220 further includes processing circuitry 1228, which may comprise one or more programmable processors, application specific integrated circuits, field programmable gate arrays, or combinations thereof (not shown) adapted to execute instructions. The base station 1220 further has software 1221 stored internally or accessible via an external connection.

[0169] The communication system 1200 further includes the UE 1230 already mentioned. The hardware 1235 of the UE 1230 may include a wireless interface 1237 configured to set up and maintain a wireless connection 1270 with a base station serving a coverage area in which the UE 1230 is currently located. The hardware 1235 of the UE 1230 further includes a processing circuit 1238, which may comprise one or more programmable processors, application specific integrated circuits, field programmable gate arrays, or combinations thereof (not shown) adapted to execute instructions. The UE 1230 further includes software 1231 stored in or accessible by the UE 1230 and executable by the processing circuit 1238. The software 1231 includes a client application 1232. The client application 1232, with the support of the host computer 1210, may be operable to provide services to a human or non-human user via the UE 1230. At the host computer 1210, a running host application 1212 may communicate with a running client application 1232 via an OTT connection 1250 that terminates at the UE 1230 and the host computer 1210. In providing services to a user, the client application 1232 may receive request data from the host application 1212 and provide user data in response to the request data. The OTT connection 1250 may transfer both the request data and the user data. The client application 1232 may interact with the user to generate the user data that the client application 1232 provides.

[0170] It should be noted that the host computer 1210, base station 1220, and UE 1230 shown in Figure 12 may be similar or equivalent to the host computer 1230, one of the base stations 1212a, 1212b, 1212c, and one of the UEs 1291, 1292, respectively, of Figure 12. That is, the inner workings of these entities may be as shown in Figure 12, and separately, the surrounding network topology may be that of Figure 12.

[0171] 12, the OTT connection 1250 is depicted abstractly to show communication between the host computer 1210 and the UE 1230 via the base station 1220, without explicit reference to intermediary devices and the exact routing of messages through these devices. The network infrastructure may determine the routing, and the network infrastructure may be configured to hide the routing from the UE 1230 or from the service provider operating the host computer 1210, or both. While the OTT connection 1250 is active, the network infrastructure may also make decisions to dynamically change the routing (e.g., based on load balancing considerations or reconfiguration of the network).

[0172] The wireless connection 1270 between the UE 1230 and the base station 1220 follows the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of the OTT service provided to the UE 1230 using the OTT connection 1250 of which the wireless connection 1270 forms the last segment. More precisely, the teachings of these embodiments may improve latency and power consumption, thereby providing benefits such as lower complexity, reduced time required to access a cell, improved responsiveness, extended battery life, etc.

[0173] Measurement procedures may be provided for the purpose of monitoring data rates, latency, and other factors that one or more embodiments improve upon. There may further be an optional network function for reconfiguring the OTT connection 1250 between the host computer 1210 and the UE 1230 in response to fluctuations in the measurement results. The measurement procedures and / or the 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 both. In an embodiment, sensors (not shown) may be deployed in or in association with the communication devices through which the OTT connection 1250 passes, and the sensors may participate in the measurement procedures by providing values ​​of the monitored quantities exemplified above, or other physical quantities from which the software 1211, 1231 may calculate or estimate the monitored quantities. The reconfiguration of the OTT connection 1250 may include message formats, retransmission settings, preferred routing, etc., and the reconfiguration need not affect the base station 1220, and the reconfiguration may be unknown or imperceptible to the base station 1220. Such procedures and functions may be known and practiced in the art. In some embodiments, the measurements may involve proprietary UE signaling that facilitates the host computer 1210 measurements of throughput, propagation time, latency, etc. The measurements may be implemented in the software 1211 and 1231 causing messages, particularly empty or "dummy" messages, to be sent using the OTT connection 1250 while the software 1211 and 1231 monitors propagation times, errors, etc.

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

[0175] FIG. 14 is a flow chart illustrating a method implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, which may be as described with reference to FIG. 11 and FIG. 12. For simplicity of the disclosure, only drawing references to FIG. 14 are included in this section. 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 carrying the user data to the UE. The transmission may proceed via the base station according to the teachings of the embodiments described throughout this disclosure. In step 1430 (which may be optional), the UE receives the user data carried in the transmission.

[0176] FIG. 15 is a flow chart illustrating a method implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, which may be as described with reference to FIG. 11 and FIG. 12. For simplicity of the disclosure, only drawing reference to FIG. 15 is included in this section. 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 the 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 the user data in response to the received input data provided by the host computer. In providing the user data, the executed client application may further take into account user input received from the user. Regardless of the particular manner in which the user data is provided, the UE initiates transmission of the user data to the host computer in sub-step 1530 (which may be optional). In method step 1540, the host computer receives user data transmitted from the UE according to the teachings of the embodiments described throughout this disclosure.

[0177] FIG. 16 is a flow chart illustrating a method implemented in a communication system according to one embodiment. The communication system includes a host computer, a base station, and a UE, which may be as described with reference to FIG. 11 and FIG. 12. For simplicity of the disclosure, only a drawing reference to FIG. 16 is included in this section. In step 1610 (which may be optional), the base station receives user data from the UE, according to the teachings of the embodiments described throughout this disclosure. In step 1620 (which may be optional), the base station initiates transmission of the received user data to the host computer. In step 1630 (which may be optional), the host computer receives the user data carried in the transmission initiated by the base station.

[0178] Generally, 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, and other aspects may be implemented in firmware or software that may be executed by a controller, microprocessor, or other computing device, but the present 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 diagrammatic representation, it should be fully understood that these blocks, apparatus, systems, techniques, or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, dedicated circuits or logic, general-purpose hardware or controllers or other computing devices, or any combination thereof.

[0179] It should therefore be appreciated that at least some aspects of the exemplary embodiments of the present disclosure may be practiced in a variety of components, such as integrated circuit chips and modules. It should therefore be appreciated that the exemplary embodiments of the present disclosure may be realized in an apparatus embodied as an integrated circuit, where the integrated circuit may comprise circuitry (and possibly firmware) for embodying at least one or more of a data processor, a digital signal processor, a baseband circuit, and a radio frequency circuit that are configurable to operate in accordance with the exemplary embodiments of the present disclosure.

[0180] It should be appreciated that at least some aspects of the exemplary embodiments of the present disclosure may be embodied in computer-executable instructions, such as in one or more program modules executed by one or more computers or other devices. Generally, a program module includes routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types when executed by a processor in a computer or other device. The computer-executable instructions may be stored in a computer-readable medium, such as a hard disk, an optical disk, a removable storage medium, a solid-state memory, a 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 as desired in various embodiments. Furthermore, 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.

[0181] Some preferred embodiments of the present disclosure are provided below for a better understanding.

[0182] Embodiment 1: RNTI used in 2-step RA depends on RRC status In one embodiment, if the UE does not possess a valid C-RNTI, e.g., in idle mode, the CS-RNTI (configured Scheduling RNTI) is used. The CS-RNTI can have one or more RNTI values, which may be configured cell-specific. The CS-RNTI value may be provided, e.g., in RMSI or OSI. The UE selects the actual CS-RNTI value to be used from a set of configured values. When the UE has a C-RNTI, e.g., when in RRC connected mode and should perform CFRA, in one embodiment, the UE uses its C-RNTI.

[0183] In another embodiment, for example, when in an inactive mode and performing CBRA, a UE may use a CS-RNTI based on its C-RNTI, e.g., a function of some bits in the C-RNTI, which reduces the blind decoding complexity for the gNB receiver compared to tentatively detecting all inactive UE C-RNTIs in the system or tracking area.

[0184] In one embodiment, if one or more UE attempts using a C-RNTI or a C-RNTI-based CS-RNTI are unsuccessful, it may revert to the above approach in which the UE does not possess a valid C-RNTI for subsequent attempts.

[0185] Embodiment 1a: The CS-RNTI used to scramble the msgA PUSCH payload in two-step RA depends on the msgA preamble used by the UE For a UE that does not possess a valid C-RNTI, the selected CS-RNTI may be selected based on and / or related to, for example, the msgA preamble ID, the PRACH occasion, or the PRACH preamble format. Because the preamble ID and occasion are selected from an SSB-dependent set, this embodiment may alternatively be viewed as selecting a CS-RNTI based on the best detected SSB in the cell.

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

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

[0188] Embodiment 1b: The CS-RNTI used to scramble the msgA PUSCH payload in two-step RA is selected based on, for example, PUSCH parameters, access purpose. Alternatively, the CS-RNTI may be selected from a set of options provided in the SI or in the specification without considering the selected preamble. The CS-RNTI may instead be selected based on, for example, PUSCH payload properties (size, format) or the purpose for performing the RA attempt (short data, normal access).

[0189] Embodiment 2: The network selects the RNTI used to scramble the PDCCH CRC of msgB in the two-step RA based on the received msgA PUSCH RNTI. In this embodiment, the NW uses the RNTI (e.g., C-RNTI or CS-RNTI) used by the UE in the msgA PUSCH to scramble the CRC of the PDCCH for msgB. The NW detects the CS-RNTI based on the received msgA preamble or based on blind detection of the PUSCH. That RNTI then functionally becomes the new RA-RNTI for the given UE.

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

[0191] Such a principle for the new RA-RNTI definition also enables the NW and UE to efficiently distinguish between two-step msgB responses and four-step msg2 responses.

[0192] Embodiment 3: A separate RNTI, e.g., TS-RNTI (2-step RNTI), is designed based on the configured preamble id and the numbering of PRACH occasions in a determined order. The TS-RNTI is related to the preamble id and the PRACH occasion and is designed differently from the RA-RNTI and therefore does not collide with the RA-RNTI. One example is to derive the TS-RNTI based on the TS-RNTI numbering in the following order, see Figure 6: First, in increasing order of preamble index within a single PRACH occasion. Second, in increasing order of frequency resource index for frequency multiplexed PRACH occasions. Third, in increasing order of time resource index for time multiplexed PRACH occasions within a PRACH slot. Fourth, in increasing order of index for the PRACH slot.

[0193] The ordering may be done in any other specified order, e.g., frequency resources, time resources, preamble resources. In this way, the UE can calculate the TS-RNTI when the selected preamble is transmitted. In a similar manner, the gNB can calculate the TS-RNTI when the gNB receives a specific preamble on a specific PRACH occasion. In this method, the determined order may be either pre-determined or RRC configured. An example is shown in FIG. 6, where three preamble ids (0-2) are configured in every PRACH occasion for the first eight PRACH occasions, and the TS-RNTI is configured.

[0194] It is also possible to use only a subset of the indices, e.g., ordering based on the preamble index and the frequency resource index for the frequency multiplexed PRACH. This is shown in Figure 7, where 64 preamble indices (0 to 63) are used in each of the two frequency multiplexed PRACH occasions. This gives 0 to 127 as possible TS-RNTIs. The PUSCH occasions are also linked to the preamble and PRACH occasions, e.g., the first 32 indices in each PRACH occasion map to the PUSCH occasion with the lower frequency index. In this case, the TS-RNTI is 0 to 63 in the first PRACH occasion and 64 to 127 in the second PRACH occasion. Next, MsgA transmitted in PUSCH occasion 0 is scrambled with an RNTI from 0 to 31 depending on the selected preamble, MsgA transmitted in PUSCH occasion 1 is scrambled with an RNTI from 32 to 63 depending on the selected preamble, MsgA transmitted in PUSCH occasion 3 is scrambled with an RNTI from 64 to 95 depending on the selected preamble, and finally, MsgA transmitted in PUSCH occasion 3 is scrambled with an RNTI from 96 to 127 depending on the selected preamble.

[0195] Embodiment 3a: The TS-RNTI is related to one or more of the following factors:

[0196] (i) Frequency bands used For example, in an unlicensed band, the RA-RNTI or a modified RA-RNTI may not be used for the TS-RNTI because the RA-RNTI may not be available when the UE is preparing the PUSCH while waiting for the LBT for the msgA preamble transmission. Or, to avoid the problem that the RA-RNTI is not available, the RA-RNTI is always generated, for example, based on the RO of the first LBT. In a licensed band, the TS-RNTI may be either the RA-RNTI or a modified RA-RNTI, or a new defined RNTI.

[0197] (ii) Time gap between preamble and msgA PUSCH For example, when the gap is equal to or greater than a threshold, the RA-RNTI or a modified RA-RNTI may be applied for msgA and msgB transmissions, otherwise an RNTI unrelated to the RA-RNTI is used, where the threshold may be either predetermined or signaled in the RRC signaling.

[0198] Furthermore, the RNTI for MsgA scrambling may depend more directly on the time distance between the preamble and the PUSCH, which may be based on the time in seconds between the preamble and the PUSCH, and / or the number of OFDM symbols and / or slots, and / or the number of PRACH occasions (in time and / or frequency) between the preamble and the PUSCH.

[0199] (iii) Timing / frequency of msgA transmission For MsgB, the RNTI is based on the timing / frequency of the corresponding transmission of MsgA. This is especially preferred when msgA PUSCH from different UEs have different PUSCH occasions, which results in different UEs using different RNTIs.

[0200] Furthermore, if the preamble position in time can be determined from the PUSCH position in time (e.g., if the configuration is such that the PUSCH immediately follows the preamble or with a time gap smaller than a given threshold, see previous subsection), the RNTI for MsgA scrambling may be time independent, but in other cases the RNTI for MsgA scrambling may be time dependent. When / if the MsgA RNTI is time independent, the MsgB RNTI may still be time dependent. As a special case, the MsgA RNTI may be equivalent to the MsgB RNTI, except that the time dependency is omitted.

[0201] The gap thresholds mentioned above (also in the previous subsection) may be predetermined in the specification and / or either explicitly signaled or implied by other signaling, e.g., the PRACH configuration index. Instead of basing the scrambling selection on the time gap threshold, the selection may be signaled.

[0202] (iv) UE ID The UE ID itself or some RNTI mapped from the UE ID may be used for scrambling MsgB. An example of a detailed design of a UE ID-based TS-RNTI to ensure that MsgB is scrambled by a value different from Msg2 (scrambled by RA-RNTI) is provided as follows: The space of possible RA-RNTI values ​​is about 18000 values ​​(most of them unused in the configuration). If the 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 the 15 LSB bits, and the MSB bit of TS-RNTI is set to 1 to ensure that the number is higher than 18000, which is higher than and close to the maximum value of RA-RNTI. This makes the TS-RNTI different from the RA-RNTI, and MsgB and Msg2 can be identified by different scrambling sequences.

[0203] Embodiment 4: The network selects the RNTI used to scramble the CRC of the PDCCH that schedules msgB in a two-step RA based on the UE ID carried in the msgA PUSCH. In these embodiments, the NW uses the UE's ID carried in the msgA PUSCH to determine the RNTI to use to scramble the CRC of the PDCCH that schedules msgB, or the "msgB RA-RNTI."

[0204] In some embodiments, the UE scrambles the PUSCH msgA payload with a cell identity in addition to transmitting its msgA UE ID (such as a C-RNTI or UE contention resolution identity). The gNB receives the msgA UE ID directly in the PUSCH payload, and since all UEs in the cell use the same PUSCH scrambling, that cell ID can be used for PUSCH reception. Thus, in such embodiments, it is not necessary to blindly decode the PUSCH with multiple scrambling hypotheses or to determine the PUSCH scrambling from the msgA preamble.

[0205] 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 that C-RNTI, e.g., using a hash or a subset of the bits of the msgA RNTI to select an RA-RNTI from a group of possibilities. Similarly, in embodiments where msgA carries a UE contention resolution identity or a CCCH SDU that has more bits than the msgB RA-RNTI, the UE may use either a subset of the bits or a hash of the bits in the UE contention resolution identity to create the msgB RA-RNTI. In some embodiments, the UE contention resolution identity is derived from the CCCH SDU as described in 3GPP TS38.321 rev.15.4.0 subclause 6.1.3.3.

[0206] The scrambling sequence generation for the PUSCH may be performed using a modification of 3GPP TS38.211 rev.15.4.0 subclause 6.3.1.1 such that when the PUSCH is used for the transmission of msgA, the scrambling sequence generator is initialized with the cell ID. JPEG0007634335000004.jpg8170, otherwise the Rel-15 mechanism is used.

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

[0208] (a) The RNTI depends on the RRC status and / or RA type of the UE. When CS-RNTI is used, it may depend on the preamble, the PUSCH parameters, the access purpose, or it may be set randomly.

[0209] (b) The RNTI used to scramble the PDCCH CRC of msgB in 2-step RA is based on the received msgA PUSCH RNTI.

[0210] (c) A separate RNTI, e.g., TS-RNTI (2-step RNTI), is designed based on the configured preamble id and the numbering of the PRACH occasions in the determined order, and the TS-RNTI may be related to one or more of the following factors: frequency band used, and / or time gap between the preamble and the msgA PUSCH, and / or timing / frequency of msgA transmission, and / or mapping to UE ID (at least in some cases only for msgB).

[0211] Abbreviation CBRA Contention-Based Random Access CFRA Contention-Free Random Access MA multiple access NR new radio NW Network PUSCH Physical Uplink Shared Channel RACH Random Access Channel PRACH Physical Random Access Channel RAR Random Access Response RNTI Radio Network Temporary Identification SI System Information SIB1 System Information Block Type 1 TF Timing and Frequency

[0212] The present disclosure includes any novel feature or combination of features explicitly disclosed herein or any generalization thereof. Various modifications and adaptations to the above exemplary embodiments of the present disclosure may become apparent to those skilled in the art in view of the above description, when read in conjunction with the accompanying drawings. However, any and all modifications will still fall within the scope of the non-limiting and exemplary embodiments of the present disclosure.

Claims

1. 1. A method in a terminal device, comprising: determining a request message for random access (302, 304, 306), the request message including a preamble and a physical uplink shared channel (PUSCH) message, the PUSCH message being determined based on a first radio network temporary identity (RNTI); Sending (308) the request message; and Obtaining a response message for random access based on a second RNTI (310); Including, The first RNTI is utilized to scramble coded bits of the PUSCH message, and 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) that carries the response message; the first RNTI and the second RNTI are different; The second RNTI is determined based on a radio resource control (RRC) status of the terminal device. method.

2. The method of claim 1 , wherein the RRC status comprises a connected mode.

3. The method of claim 1 , wherein if a Cell-RNTI (C-RNTI) is available, the C-RNTI is determined as the second RNTI.

4. The method according to claim 1 , wherein the second RNTI is determined based on the first RNTI.

5. 5. The method of claim 1, wherein the first RNTI and / or the second RNTI are determined based on a numbering of a set of Physical Random Access Channel (PRACH) occasions.

6. The method of claim 5 , wherein a set of RNTI values ​​is determined based on timing / frequency resources of the request message.

7. A method in a network node, comprising the steps of: Obtaining a request message from a terminal device, the request message including a preamble and a physical uplink shared channel (PUSCH) message based on a first radio network temporary identity (RNTI); determining a response message based on the second RNTI; sending the response message to a terminal device; Including, The first RNTI is utilized to scramble coded bits of the PUSCH message, and 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) that carries the response message; the first RNTI and the second RNTI are different; The method, wherein the second RNTI is determined based on a radio resource control (RRC) status of the terminal device.

8. A terminal device, comprising: a non-transitory computer readable medium having computer executable instructions stored thereon; a processor coupled to the non-transitory computer readable medium; Equipped with The computer-executable instructions cause the terminal device to implement the method of claim 1. Terminal device.

9. A network node, a non-transitory computer readable medium having computer executable instructions stored thereon; a processor coupled to the non-transitory computer readable medium; Equipped with The computer-executable instructions cause the network node to implement the method of claim 7. Network node.

Images