Patent Description:
In a new radio (NR) system, a four-step approach may be used for a random access procedure, as shown in <FIG>. In this approach, a user equipment (UE) detects a synchronization signal (SS) which comprises NR-primary synchronization signal (NR-PSS), NR-secondary synchronization signal (NR-SSS) and NR-physical broadcast channel (PBCH), and decodes broadcasted system information, e.g. remaining minimum system information (RMSI). Then the UE may transmit a physical random access channel (PRACH) preamble (message <NUM>) in uplink (UL). In response to receiving the message <NUM>, a base station (e.g. next generation node B (gNB)) replies with a random access response (RAR, message <NUM>). The RAR message is octet aligned and comprises a timing advance command, a UL grant, and a temporary cell-radio network temporary identifier (TC-RNTI).

After receiving the RAR message, the UE may transmit a message <NUM> including UE identification and a transport block on a physical uplink shared channel (PUSCH). The gNB then replies with a contention resolution message (message <NUM>). The timing advance command in the RAR message allows the message <NUM> PUSCH to be received with a timing accuracy within a cyclic prefix (CP). Without this timing advance, a very large CP would be needed in order to be able to demodulate and detect the PUSCH, unless the system is applied in a cell with very small distance between the UE and the gNB. Since NR will also support larger cells with a need for providing a.

The message <NUM> PUSCH is scheduled by the UL grant in the RAR message. Retransmissions, if any, of the transport block in the message <NUM> PUSCH are scheduled by a DCI format 0_0 with cyclic redundancy check (CRC) scrambled by a TC-RNTI provided in the RAR message. The UE always transmits the message <NUM> PUSCH without repetitions.

In 3GPP TS38. <NUM> v <NUM>. <NUM>, the disclosure of which is incorporated by reference herein in its entirety, table <NUM> is provided to define a range of RNTI values as below.

A two-step random access procedure has been approved as a work item for NR release <NUM>. As illustrated in <FIG>, an initial access is completed in only two steps. At the first step, the UE sends a message, which may be called message A, including a random access preamble together with higher layer data such as radio resource control (RRC) connection request possibly with some small payload on PUSCH. At the second step, the gNB sends a response message to the UE, which may be called message B, including e.g. UE identifier assignment, timing advance information, and contention resolution message, etc. Message B is a response message carried in physical downlink shared channel (PDSCH) scheduled by physical downlink control channel (PDCCH) with CRC scrambled by some RNTI.

The publication <NPL>, describes a <NUM>-step RACH procedure, where when a RACH preamble is shared between <NUM>-step RACH capable UE and <NUM>-step RACH capable UE, the Msg A includes at least C-RNTI for RRC_Connected or RRC_Inactive mode.

Further, embodiments of the invention are defined by the claims. Moreover, examples, embodiments and descriptions, which are not covered by the claims are presented not as embodiments of the invention, but as background art or examples useful for understanding the invention. Further, embodiments of the invention are defined by the dependent claims.

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

The disclosure itself, the preferable mode of use and further objectives are best understood by reference to the following detailed description of the embodiments when read in conjunction with the accompanying drawings, in which:.

As used herein, the term "communication network" refers to a network following any suitable communication standards, such as new radio (NR), long term evolution (LTE), LTE-Advanced, wideband code division multiple access (WCDMA), high-speed packet access (HSPA), and so on. Furthermore, the communications between a terminal device and a network node in the communication network may be performed according to any suitable generation communication protocols, including, but not limited to, the first generation (<NUM>), the second generation (<NUM>), <NUM>, <NUM>, the third generation (<NUM>), <NUM>, <NUM>, <NUM> communication protocols, and/or any other protocols either currently known or to be developed in the future.

The term "network node" refers to a network device in a communication network via which a terminal device accesses to the network and receives services therefrom. The 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. The BS may be, for example, a node B (NodeB or NB), an evolved NodeB (eNodeB or eNB), a next generation NodeB (gNodeB or gNB), an IAB node, a remote radio unit (RRU), a radio header (RH), a remote radio head (RRH), a relay, a low power node such as a femto, a pico, and so forth.

Yet further examples of the network node comprise multi-standard radio (MSR) radio equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, positioning nodes and/or the like. More generally, however, the network node may represent any suitable device (or group of devices) capable, configured, arranged, and/or operable to enable and/or provide a terminal device access to a wireless communication network or to provide some service to a terminal device that has accessed to the wireless communication network.

The term "terminal device" refers to any end device that can access a communication network and receive services therefrom. By way of example and not limitation, the terminal device may refer to user equipment (UE), or other suitable devices. The UE may be, for example, a subscriber station, a portable subscriber station, a mobile station (MS) or an access terminal (AT). The terminal device may include, but not limited to, portable computers, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, a mobile phone, a cellular phone, a smart phone, a tablet, a wearable device, a personal digital assistant (PDA), a vehicle, and the like.

As yet another specific example, in an Internet of things (IoT) scenario, a terminal device may also be called an IoT device and represent a machine or other device that performs monitoring, sensing and/or measurements etc., and transmits the results of such monitoring, sensing and/or measurements etc. to another terminal device and/or network equipment. The terminal device may in this case be a machine-to-machine (M2M) device, which may in a 3rd generation partnership project (3GPP) context be referred to as a machine-type communication (MTC) device.

As one particular example, the terminal device may be a UE implementing the 3GPP narrow band Internet of things (NB-IoT) standard. Particular examples of such machines or devices are sensors, metering devices such as power meters, industrial machinery, or home or personal appliances, e.g. refrigerators, televisions, personal wearables such as watches etc. In other scenarios, a terminal device may represent a vehicle or other equipment, for example, a medical instrument that is capable of monitoring, sensing and/or reporting etc. on its operational status or other functions associated with its operation.

As described above, in the two-step random access procedure as shown in <FIG>, the preamble and the PUSCH message will be transmitted by the UE in one message called message A before the UE receives the response message called massage B from the gNB. But for the PUSCH message in message A, as no RAR message is received from the gNB, there is no TC-RNTI available for PUSCH handling. Additionally, in message A, for each preamble, different RNTI values of PUSCH may be needed to avoid collision of PUSCHs between different messages A especially when more than one PUSCH are on the same timing frequency resource. Additionally, in order to differentiate the message <NUM> in the four-step random access procedure and the message B in the two-step random access procedure, there is a need to use different RNTIs. Therefore, it would be desirable to provide a solution for determining the RNTI for the PUSCH in message A and/or the PDCCH CRC scrambling and PDSCH scrambling in message B in the two-step random access procedure.

In accordance with some exemplary embodiments described throughout this disclosure, the present disclosure provides improved solutions for the 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 a 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 solutions, the RNTI used for the PUSCH in message A and/or the PDCCH CRC scrambling and PDSCH scrambling in message B can be determined.

It is noted that some embodiments of the present disclosure are mainly described in relation to <NUM> specifications being used as non-limiting examples for certain exemplary network configurations and system deployments. As such, the description of exemplary embodiments given herein specifically refers to terminology which is directly related thereto. Such terminology is only used in the context of the presented non-limiting examples and embodiments, and does not limit the present disclosure naturally in any way. Rather, any other system configuration or radio technologies may equally be utilized as long as exemplary embodiments described herein are applicable.

<FIG> is a flowchart illustrating a method <NUM> according to some embodiments described throughout this disclosure. The method <NUM> illustrated in <FIG> may be performed by an apparatus implemented in a terminal device or communicatively coupled to a terminal device. In accordance with an exemplary embodiment, the terminal device may be a UE.

According to the exemplary method <NUM> illustrated in <FIG>, the terminal device may determine a preamble of a request message for a two-step random access procedure, as shown in block <NUM>. In some embodiments, the preamble may be determined according to a set of preambles. The set of preambles may be specific for the two-step random access procedure. Alternatively, the set of preambles may be the same as those 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.

In block <NUM>, 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 broadcasted system information. The broadcasted system information comprises remaining minimum system information (RMSI) or other system information (OSI). In some embodiments, the plurality of configured scheduling RNTIs (CS-RNTIs) are provided in the broadcasted system information. Therefore, 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-RNTI 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 the purpose of a 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.

After determining the RNTI in block <NUM>, in block <NUM>, the terminal device may generate a PUSCH message based on the determined first RNTI. Generally, the determined first RNTI is utilized to scrambling encoded bits of the PUSCH message. The request message may comprise the preamble determined in block <NUM> and the PUSCH message. The preamble may be transmitted in the PRACH occasion, and the PUSCH message may be transmitted in the PUSCH occasion. Then, the request message including the preamble and the PUSCH message is determined. Then in block <NUM>, the terminal device may transmit the request message (i.e. message A) to the network node in the two-step random access procedure.

In response to transmitting the request message, the terminal device may obtain a response message (e.g. message B) based on a second RNTI from the network node, as shown in block <NUM>. Specifically, the terminal device may utilize the second RNTI to receive a physical downlink control channel (PDCCH) message scheduling a physical downlink shared channel (PDSCH) carrying the response message. The second RNTI may be the same as or different from the first RNTI. In some embodiments, the second RNTI is generated based on the first RNTI. For example, the second RNTI may be formed as a function/mapping of the first RNTI used in message A. Specifically, the network node may select a 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 RNTI allows the network node and the terminal device to efficiently differentiate message B in two-step random access procedure from message <NUM> in 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 message A PUSCH to determine the second RNTI so as to scramble the CRC of a PDCCH message for message B.

<FIG> is a flowchart illustrating a method <NUM> according to some embodiments described throughout this disclosure. The method <NUM> illustrated in <FIG> may be performed by an apparatus implemented in a terminal device or communicatively coupled to a terminal device. In accordance with an exemplary embodiment, the terminal device may be a UE. In the following description with respect to <FIG>, for the same or similar parts as those in the previous exemplary embodiments, the detailed description will be properly omitted.

According to the exemplary method <NUM> illustrated in <FIG>, the terminal device may determine a preamble of a request message for a two-step random access procedure, as shown in block <NUM>. In block <NUM>, the terminal device may determine whether a C-RNTI is available. If the C-RNTI is available, the terminal device will utilize the C-RNTI itself as the first RNTI, as shown in block <NUM>. For example, if the terminal device is in RRC connected mode and is used perform Contention Free Random Access (CFRA), it will have a C-RNTI. Accordingly, the terminal device may use the C-RNTI as the first RNTI.

If the C-RNTI is not available, then in block <NUM>, the terminal device will select one of a plurality of CS-RNTIs in the broadcasted system information based on the preamble determined in block <NUM>. For example, if the terminal device is in an idle mode, then it does not possess a valid C-RNTI. Accordingly, the terminal device may select one CS-RNTI as the first RNTI. The terminal device may select one of the plurality of CS-RNTI 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 the purpose of a radio access (RA) attempt of the terminal device. It is noted that the CS-RNTI can have one or multiple RNTI values which can be cell specifically configured. The CS-RNTI values may be provided in the broadcasted system information (e.g. in the RMSI or OSI). The terminal device selects the actual CS-RNTI value to be used from the configured multiple-value set.

In accordance with an exemplary embodiment, the RNTI may depend on the RRC status. The RRC status comprises an idle mode, a connected mode, and an inactive mode. For example, if the terminal device is in inactive mode and performing Contention Based Random Access (CBRA), it may use a CS-RNTI that is 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 device in the system or the tracking area. In one embodiment, if one or more UE attempts with C-RNTI or C-RNTI-based CS-RNTI are unsuccessful, it may revert to the approach where the UE does not possess valid C-RNTI above for subsequent attempts.

After determining the RNTI in block <NUM> or <NUM>, in block <NUM>, the terminal device may generate a PUSCH message based on the determined RNTI (i.e. first RNTI). Generally, the determined RNTI is used for scrambling the PUSCH payload for the request message (message A) in the two-step random access procedure. Then in block <NUM>, the terminal device may transmit a request message (e.g. message A) to the network node in the two-step random access procedure. The request message may comprise the preamble determined in block <NUM> and the PUSCH message generated in block <NUM>. In one embodiment, the network node detects the PUSCH message after detecting the preamble in the request message and can use the configuration information obtained by the preamble to receive the PUSCH message. In another embodiment, the network node may not require detecting the preamble in the request message (e.g. if the transmission at hand is a retransmission of the request message without retransmitting the preamble), and blindly decode the PUSCH message based on the plurality of possible CS-RNTI values.

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 <NUM>. The network node selects the second RNTI used for scrambling the CRC of the PDCCH message for the 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 PUSCH message of the request message. That RNTI then functionally becomes a new RA-RNTI for the given network node. Alternatively, the new RA-RNTI may be formed not as a copy but as a function/mapping of the C-RNTI or CS-RNTI used in the request message, e.g. selecting a RA-RNTI from a group of possibilities using a hash or a subset of bits of the RNTI used in the request message.

According to the exemplary method <NUM> illustrated in <FIG>, the terminal device may selecting a first preamble from a set of preambles for a request message, as shown in block <NUM>. The set of preambles may be specific for the two-step random access procedure. Alternatively, the set of preambles may be the same as those 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 an RRC message. Alternatively, in some embodiments, the set of preambles may be predefined in the terminal device.

In block <NUM>, the terminal device may determine a first RNTI, which may be called 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 a set of RNTI values, and based on the numbering of the RNTI values in the set.

After determining the RNTI in block <NUM>, in block <NUM>, the terminal device may generate a PUSCH message based on the determined first RNTI. Generally, the determined first RNTI is utilized to scrambling encoded bits of the PUSCH message. Then in block <NUM>, the terminal device may transmit a request message (i.e. message A) to the network node in the two-step random access procedure. The request message may comprise the preamble determined in block <NUM> and the PUSCH message generated in block <NUM>. The preamble may be transmitted in the PRACH occasion, and the PUSCH message may be transmitted in the PUSCH occasion. In response to transmitting the request message, the terminal device may receive a response message (e.g. message B) based on a second RNTI from the network node, as shown in block <NUM>.

In some embodiments, the order of the RNTI values is arranged based on at least one of the following: an order of indexes of preambles associated with the RNTI values in a PRACH occasion; an order of frequency resource indexes of PRACH occasions associated with the RNTI values; an order of time resource indexes of PRACH occasions associated with the RNTI values; an order of indexes for PRACH slots associated with the RNTI values. It is noted that the first RNTI used in the two-step random access procedure is designed differently from the RA-RNTI and thus will not collide with the RA-RNTI.

<FIG> is an example illustrating RNTIs ordering in time, frequency domain over different PRACH occasions. First, the order of the RNTI values is arranged based on an increasing order of indexes of preambles in a PRACH occasion (e.g., the indexes of the RNTI values <NUM>, <NUM>, <NUM> in a PRACH occasion OC1). Second, the order of the RNTI values is arranged based on an increasing order of frequency resource indexes of PRACH occasions (e.g., the indexes of the RNTI values <NUM>, <NUM>, <NUM> in a PRACH occasion OC2; the frequency resources of the PRACH occasion OC2 are higher than those of the PRACH occasion OC1). Third, the order of the RNTI values is arranged based on an increasing order of time resource indexes of PRACH occasions (e.g., the indexes of the RNTI values <NUM>, <NUM>, <NUM> in a PRACH occasion OC3; the time slot of the PRACH occasion OC3 is larger than those of the PRACH occasion OC1). Fourth, the order of the RNTI values is arranged based on an increasing order of indexes for PRACH slots (e.g., the indexes of the RNTI values <NUM>-<NUM> are in a PRACH slot <NUM>; the indexes of the RNTI values <NUM>-<NUM> are in a PRACH slot <NUM>). <FIG> is an example illustrating three indexes of preambles (<NUM>-<NUM>) configured in every PRACH occasion and the RNTIs for the first <NUM> PRACH occasions. It should be noted that it is also possible to do the ordering in any other specified order, e.g. frequency resource, time resource, preamble resource. The determined order can be either predetermined or RRC configured. In this embodiment, the terminal device is able to compute the RNTI when the selected preamble is transmitted. In the same embodiment, the network node can calculate the RNTI when it receives a specific preamble on a specific PRACH occasion.

It is also possible to only use a subset of the indices, e.g. an ordering based on the indexes of preambles and the indexes of frequency for frequency multiplexed PRACH. This is shown in <FIG>, where <NUM> preamble indexes (<NUM>-<NUM>) are used in each of two frequency multiplexed PRACH occasions. This gives <NUM>-<NUM> as possible first RNTIs. The PUSCH occasions are also linked to the preambles and PRACH occasions so that e.g. the first <NUM> indices in each PRACH occasion maps to the PUSCH occasion with the lower frequency index. In this embodiment, the indexes of RNTIs <NUM>-<NUM> are arranged in the first PRACH occasion and the indexes of RNTIs <NUM>-<NUM> are arranged in the second PRACH occasion. A message A (Msg A) transmitted in PUSCH occasion <NUM> would then be scrambled by the indexes of RNTIs <NUM>-<NUM> depending on the chosen preamble, MsgA transmitted in PUSCH occasion <NUM> would be scrambled by the indexes of RNTIs <NUM>-<NUM> depending on the chosen preamble, MsgA transmitted in PUSCH occasion <NUM> would be scrambled by the indexes of RNTIs <NUM>-<NUM> depending on the chosen preamble and finally MsgA transmitted in PUSCH occasion <NUM> would be scrambled by the indexes of RNTIs <NUM>-<NUM> depending on the chosen preamble.

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

Regarding the frequency band, for example, in unlicensed band, RA-RNTI or modified RA-RNTI cannot be used for TS-RNTI, as RA-RNTI may be not available when the network node is preparing the PUSCH while waiting for a LBT for the transmission of the preamble in message A. Or to avoid the RA-RNTI not available issue, always generate an RA-RNTI based on the RO of the e.g. <NUM>st LBT. In licensed band, the TS-RNTI can be either RA-RNTI or a modified RA-RNTI, or a new defined RNTI.

Regarding the time gap between the first preamble and the PUSCH, for example, when the gap is no less than a threshold, the RA-RNTI or modified RA-RNTI can be applied for message A and message B transmissions in the two-steps random access procedure, otherwise an RNTI independent from RA-RNTI is used. The threshold can be either predetermined or signaled in RRC signaling, which is not limited here. Further, the RNTI for the message A scrambling can be more directly dependent on the time distance between preamble and PUSCH. The dependence may be based on the time in seconds between preamble and PUSCH, and/or on number of OFDM symbols and/or slots, and/or on number of PRACH occasions (in time and/or frequency) between preamble and PUSCH.

Regarding the timing/frequency resource of the request message, for message B, an RNTI that is based on the timing/frequency of the corresponding the transmission of message A. This is preferred especially when message A PUSCHs from different terminal devices have different PUSCH occasions, so that different terminal devices will use different RNTIs. Further, if preamble position in time can be determined from PUSCH position in time (e.g. if configuration is such that PUSCH follows immediately after preamble, or with a time gap smaller than a given threshold, cf. previous subsection), the RNTI for message A scrambling could be independent of time, while otherwise RNTI for message A scrambling could be dependent on time. When/if message A RNTI is not dependent on time, message B RNTI could still be dependent on time. As a special case, the message A RNTI could be identical to message B RNTI, except with time dependence omitted. The gap thresholds mentioned above (also in previous subsection) may be predetermined in specifications, and/or be signaled, either explicitly, or implied by other signaling, e.g. the PRACH configuration index. Instead of basing the choice of scrambling on a time gap threshold, the choice could be signaled.

Regarding the ID of the terminal device, the ID of the terminal device itself or some RNTI mapped from the ID of the terminal device can be used for the scrambling of message B. An example of the detail design of the ID of the terminal device based TS-RNTI to make sure that message B is scrambled by a different value than message <NUM> (which is scrambled by RA-RNTI) is provided as below:.

The space of possible RA-RNTI values is approximately <NUM> values (majority of them unused in any configuration). In the case when the scrambling is done based on an ID of the terminal device (RRC Idle/Inactive) and <NUM> bits are used to scramble message B, the first <NUM> bits from the ID of the terminal device are used as the <NUM> LSB bits and set the MSB bit of the TS-RNTI to be <NUM> to make sure the number be higher than <NUM> which is larger and close to the maximum of the RA-RNTI. This makes the TS-RNTI different from RA-RNTI, such that message B and message <NUM> can be identified by different scrambling sequences. Table <NUM> is provided to define a range of RNTI values according to an embodiment of the present disclosure.

<FIG> is a flowchart illustrating a method <NUM> according to some embodiments described throughout this disclosure. The method <NUM> illustrated in <FIG> may be performed by an apparatus implemented in a network node or communicatively coupled to a network node. In accordance with an exemplary embodiment, the network node may be a base station, e.g. a gNB. In the following description with respect to <FIG>, for the same or similar parts as those in the previous exemplary embodiments, the detailed description will be properly omitted.

According to the exemplary method <NUM> illustrated in <FIG>, the 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 <NUM>. The PUSCH message is received based on a first radio network temporary identity (RNTI). In block <NUM>, the network node may generate a response message based on a second RNTI. Then, in block <NUM>, the network node may transmit the response message to the terminal device.

In an embodiment, the network node uses an identity (ID) of a cell in which the terminal device is located to determine an RNTI to scramble the CRC of a PDCCH that schedules a msgB, or '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 a cell identity in addition to transmitting its UE ID (such as C-RNTI or UE contention resolution identity) of message A. Since the network node receives the UE ID of message directly in the PUSCH payload and all terminal devices in a cell use the same PUSCH scrambling, that cell ID can be used for PUSCH reception. Therefore, it is not necessary to blindly decode PUSCH with multiple scrambling hypotheses or to determine the PUSCH scrambling from the preamble carried in message A in such embodiments. The new 'message B' RA-RNTI may be formed not as a copy but as a function/mapping of the C-RNTI used in message A, e.g. selecting an RA-RNTI from a group of possibilities using a hash or a subset of bits of the msgA RNTI. Similarly, in some embodiments where message A carries a UE contention resolution identity or CCCH SDU that has more bits than the message B RA-RNTI, the terminal device may either use a subset of or a hash of the bits in the UE contention resolution identity to produce the msgB RA-RNTI. In some embodiments, the UE contention resolution identity is derived from a CCCH SDU as described in 3GPP TS <NUM> rev. <NUM> subclause <NUM>. The scrambling sequence generation for PUSCH can be done using a modification of 3GPP TS <NUM> rev. <NUM> subclause <NUM>. <NUM>, the disclosure of which is incorporated by reference herein in its entirety, where <MAT> such that the scrambling sequence generator is initialized with the cell ID when the PUSCH is used for transmission of message A, and otherwise Rel-<NUM> mechanism is used.

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

The various blocks shown in <FIG> and <FIG> may be viewed as method steps, and/or as operations that result from operation of computer program code, and/or as a plurality of coupled logic circuit elements constructed to carry out the associated function(s). The schematic flow chart diagrams described above are generally set forth as logical flow chart diagrams. As such, the depicted order and labeled steps are indicative of specific embodiments of the presented methods. 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 methods. Additionally, the order in which a particular method occurs may or may not strictly adhere to the order of the corresponding steps shown.

<FIG> is a block diagram illustrating a terminal device <NUM> according to some embodiments described throughout this disclosure. In an exemplary embodiment, the terminal device <NUM> may be a UE. As shown in <FIG>, the terminal device <NUM> may comprise a receiving circuitry <NUM>, a transmitting circuitry <NUM>, one or more processors such as processor <NUM> and one or more memories such as memory <NUM>, and non-transitory computer-readable medium <NUM> having stored thereon computer-executable instructions. The processor <NUM> is coupled to the receiving circuitry <NUM>, the transmitting circuitry <NUM> and the non-transitory computer-readable medium <NUM>. Optionally, the receiving circuitry <NUM>, the transmitting circuitry <NUM>, the processor <NUM>, the memory <NUM> and/or the non-transitory computer-readable medium <NUM> may be operable to carry out more or less operations to implement the proposed methods according to the exemplary embodiments of the present disclosure.

<FIG> is a block diagram illustrating a network node <NUM> according to some embodiments described throughout this disclosure. In an exemplary embodiment, the network node <NUM> may be a gNB or an eNB. As shown in <FIG>, the network node <NUM> may comprise a receiving circuitry <NUM>, a transmitting circuitry <NUM>, one or more processors such as processor <NUM> and one or more memories such as memory <NUM>, and non-transitory computer-readable medium <NUM> having stored thereon computer-executable instructions. The processor <NUM> is coupled to the receiving circuitry <NUM>, the transmitting circuitry <NUM> and the non-transitory computer-readable medium <NUM>. Optionally, the receiving circuitry <NUM>, the transmitting circuitry <NUM>, the processor <NUM>, the memory <NUM> and/or the non-transitory computer-readable medium <NUM> may be operable to carry out more or less operations to implement the proposed methods according to the exemplary embodiments of the present disclosure.

<FIG> is a block diagram illustrating a telecommunication network connected via an intermediate network to a host computer in accordance with some embodiments of the present disclosure.

With reference to <FIG>, in accordance with an embodiment, a communication system includes a telecommunication network <NUM>, such as a 3GPP-type cellular network, which comprises an access network <NUM>, such as a radio access network, and a core network <NUM>. The access network <NUM> comprises a plurality 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 is connectable to the core network <NUM> over a wired or wireless connection <NUM>. A first UE <NUM> located in a coverage area 1113c is configured to wirelessly connect to, or be paged by, the corresponding base station 1112c. A second UE <NUM> in a coverage area 1113a is wirelessly connectable to the corresponding base station 1112a.

An intermediate network <NUM> may be one of, or a combination of more than one of, a public, private or hosted network; the intermediate network <NUM>, if any, may be a backbone network or the Internet; in particular, the intermediate network <NUM> may comprise two or more sub-networks (not shown).

<FIG> is a block diagram illustrating a host computer communicating via a base station with a UE over a partially wireless connection in accordance with some embodiments of the present disclosure.

The host computer <NUM> further comprises a processing circuitry <NUM>, which may have storage and/or processing capabilities. The host application <NUM> may be operable to provide a service to a remote user, such as UE <NUM> connecting via an OTT connection <NUM> terminating at the UE <NUM> and the host computer <NUM>.

In the embodiment shown, the hardware <NUM> of the base station <NUM> further includes a processing circuitry <NUM>, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions.

The hardware <NUM> of the UE <NUM> further includes a processing circuitry <NUM>, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions.

It is noted that the host computer <NUM>, the base station <NUM> and the UE <NUM> illustrated in <FIG> may be similar or identical to the host computer <NUM>, one of base stations 1212a, 1212b, 1212c and one of UEs <NUM>, <NUM> of <FIG>, respectively.

In <FIG>, the OTT connection <NUM> has been drawn abstractly to illustrate the communication between the host computer <NUM> and the UE <NUM> via the base station <NUM>, without explicit reference to any intermediary devices and the precise routing of messages via these devices.

Wireless connection <NUM> between the UE <NUM> and the base station <NUM> is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to the UE <NUM> using the OTT connection <NUM>, in which the wireless connection <NUM> forms the last segment. More precisely, the teachings of these embodiments may improve the latency and the power consumption, and thereby provide benefits such as lower complexity, reduced time required to access a cell, better responsiveness, extended battery lifetime, etc..

There may further be optional network functionality for reconfiguring the OTT connection <NUM> between the host computer <NUM> and the UE <NUM>, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection <NUM> may be implemented in software <NUM> and hardware <NUM> of the host computer <NUM> or in software <NUM> and hardware <NUM> of the UE <NUM>, or both. In embodiments, sensors (not shown) may be deployed in or in association with communication devices through which the OTT connection <NUM> passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which the software <NUM>, <NUM> may compute or estimate the monitored quantities. In certain embodiments, measurements may involve proprietary UE signaling facilitating the host computer <NUM>'s measurements of throughput, propagation times, latency and the like. The measurements may be implemented in that the software <NUM> and <NUM> causes messages to be transmitted, in particular empty or 'dummy' messages, using the OTT connection <NUM> while it monitors propagation times, errors etc..

<FIG> is a flowchart illustrating a method implemented in a communication system, in accordance with an embodiment.

<FIG> is a flowchart illustrating a method implemented in a communication system, in accordance with an embodiment.

<FIG> is a flowchart illustrating a method implemented in a communication system, in accordance with an embodiment.

<FIG> is a flowchart illustrating a method implemented in a communication system, in accordance with an embodiment.

In general, the various exemplary embodiments may be implemented in hardware or special purpose chips, circuits, software, logic or any combination thereof.

It should be appreciated that at least some aspects of the exemplary embodiments of the 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, program modules include 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 on a computer readable medium such as a hard disk, optical disk, removable storage media, solid state memory, random access memory (RAM), etc. As will be appreciated by one of skill in the art, the function of the program modules may be combined or distributed as desired in various embodiments. In addition, the function may be embodied in whole or partly in firmware or hardware equivalents such as integrated circuits, field programmable gate arrays (FPGA), and the like.

Some preferred embodiments of the present disclosure are provided below for better understanding.

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

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

In one embodiment, if one or more UE attempts with C-RNTI or C-RNTI-based CS-RNTI are unsuccessful, it may revert to the approach where the UE does not possess valid C-RNTI above for subsequent attempts.

For a UE not possessing a valid C-RNTI, the selected CS-RNTI can be selected based on, and/or be associated with, e.g. the msgA preamble ID, the PRACH occasion, or PRACH preamble format. As the preamble ID and the occasion are selected from a set that is SSB-dependent, this embodiment can alternatively be seen as selecting the CS-RNTI based on the best detected SSB in the cell.

In one embodiment, the gNB detects the PUSCH after detecting the preamble and can use the obtained preamble configuration info to configure PUSCH reception.

In another embodiment, the possible CS-RNTI values can be blindly detected. Then preamble detection is not required, e.g. if the transmission at hand is a retransmission of msgA without retransmitting the preamble.

Alternatively, the CS-RNTI may be selected from a set of multiple options provided in SI or in the specification without considering the selected preamble. The CS-RNTI may instead be selected e.g. based on the PUSCH payload properties (size, format) or based on the purpose of performing the RA attempt (short data, regular access).

In this embodiment, the NW uses the RNTI (e.g. C-RNTI or CS-RNTI) used by the UE in 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 PUSCH. That RNTI then functionally becomes a new RA-RNTI for the given UE.

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

Such principles for new RA-RNTI definition also allow the NW and the UEs to efficiently differentiate between the <NUM>-step msgB and <NUM>-step msg2 responses.

The TS-RNTI is associated to the preamble-ids and PRACH occasions and is designed differently from the RA-RNTI and will thus not collide with the RA-RNTI. An example is to derive the TS-RNTI based on a TS-RNTI numbering in the following order, see <FIG>. First, in increasing order of preamble indexes within a single PRACH occasion. Second, in increasing order of frequency resource indexes for frequency multiplexed PRACH occasions. Third, in increasing order of time resource indexes for time multiplexed PRACH occasions within a PRACH slot. Fourth, in increasing order of indexes for PRACH slots.

It is also possible to do the ordering in any other specified order, e.g. frequency resource, time resource, preamble resource. In this way the UE is able to compute the TS-RNTI when the selected preamble is transmitted. In the same way, the gNB can calculate the TS-RNTI when it receives a specific preamble on a specific PRACH occasion. In the method, the determined order can be either predetermined or RRC configured. An example where <NUM> preamble ids are configured (<NUM>-<NUM>) in every PRACH occasion and the TS-RNTIs for the first <NUM> PRACH occasions are shown in <FIG>.

It is also possible to only use a subset of the indices, e.g. an ordering based on preamble indices and frequency resource indexes for frequency multiplexed PRACH. This is shown in <FIG>, where <NUM> preamble indices (<NUM>-<NUM>) are used in each in two frequency multiplexed PRACH occasions. This gives <NUM>-<NUM> as possible TS-RNTIs. The PUSCH occasions are also linked to the preambles and PRACH occasions so that e.g. the first <NUM> indices in each PRACH occasion maps to the PUSCH occasion with the lower frequency index. In this case, the TS-RNTI is <NUM>-<NUM> in the first PRACH occasion and <NUM>-<NUM> in the second. A MsgA transmitted in PUSCH occasion <NUM> would then be scrambled by an RNTI of <NUM>-<NUM> depending on the chosen preamble, MsgA transmitted in PUSCH occasion <NUM> would be scrambled by an RNTI of <NUM>-<NUM> depending on the chosen preamble, MsgA transmitted in PUSCH occasion <NUM> would be scrambled by an RNTI of <NUM>-<NUM> depending on the chosen preamble and finally MsgA transmitted in PUSCH occasion <NUM> would be scrambled by an RNTI of <NUM>-<NUM> depending on the chosen preamble.

For example, in unlicensed band, RA-RNTI or modified RA-RNTI cannot be used for TS-RNTI, as RA-RNTI may be not available when UE is preparing the PUSCH while waiting for a LBT for the msgA preamble transmission. Or to avoid the RA-RNTI not available issue, always generate an RA-RNTI based on the RO of the e.g. <NUM>st LBT. In licensed band, the TS-RNTI can be either RA-RNTI or a modified RA-RNTI, or a new defined RNTI.

For example, when the gap is no less than a threshold, the RA-RNTI or modified RA-RNTI can be applied for msgA and msgB transmissions, otherwise an RNTI independent from RA-RNTI is used. Here the threshold can be either predetermined or signaled in RRC signaling.

Further, the RNTI for MsgA scrambling can be more directly dependent on the time distance between preamble and PUSCH. The dependence may be based on the time in seconds between preamble and PUSCH, and/or on number of OFDM symbols and/or slots, and/or on number of PRACH occasions (in time and/or frequency) between preamble and PUSCH.

For MsgB, an RNTI that is based on the timing/frequency of the corresponding transmission of MsgA. This is preferred especially when msgA PUSCHs from different UEs have different PUSCH occasions, so that different UEs will use different RNTIs.

Further, if preamble position in time can be determined from PUSCH position in time (e.g. if configuration is such that PUSCH follows immediately after preamble, or with a time gap smaller than a given threshold, cf. previous subsection), the RNTI for MsgA scrambling could be independent of time, while otherwise RNTI for MsgA scrambling could be dependent on time. When/if MsgA RNTI is not dependent on time, MsgB RNTI could still be dependent on time. As a special case, the MsgA RNTI could be identical to MsgB RNTI, except with time dependence omitted.

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

The UE ID itself or some RNTI mapped from UE ID can be used for the scrambling of MsgB. An example of the detail design of the UE ID based TS-RNTI to make sure that MsgB is scrambled by a different value than Msg2 (which is scrambled by RA-RNTI) is provided as below: The space of possible RA-RNTI values is approximately <NUM> values (majority of them unused in any configuration). In the case when the scrambling is done based on a UE id (RRC Idle/Inactive) and <NUM> bits are used to scramble MsgB, the first <NUM> bits from the UE id are used as the <NUM> LSB bits and set the MSB bit of the TS-RNTI to be <NUM> to make sure the number be higher than <NUM> which is larger and close to the maximum of the RA-RNTI. This makes the TS-RNTI different from RA-RNTI and MsgB and Msg2 can be identified by different scrambling sequences.

In these embodiments, the NW uses an ID of the UE carried in msgA PUSCH to determine an RNTI to use to scramble the CRC of a PDCCH that schedules a msgB, or 'msgB RA-RNTI'.

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

The new 'msgB' RA-RNTI may be formed not as a copy but as a function/mapping of the C-RNTI used in msgA, e.g. selecting an RA-RNTI from a group of possibilities using a hash or a subset of bits of the msgA RNTI. Similarly, in embodiments where msgA carries a UE contention resolution identity or CCCH SDU that has more bits than the msgB RA-RNTI, the UE may either use a subset of or a hash of the bits in the UE contention resolution identity to produce the msgB RA-RNTI. In some embodiments, the UE contention resolution identity is derived from a CCCH SDU as described in 3GPP TS <NUM> rev. <NUM> subclause <NUM>.

The scrambling sequence generation for PUSCH can be done using a modification of 3GPP TS <NUM> rev. <NUM> subclause <NUM>. <NUM>, where <MAT> such that the scrambling sequence generator is initialized with the cell ID when the PUSCH is used for transmission of msgA, and otherwise Rel-<NUM> mechanism is used.

Claim 1:
A method performed at a terminal device, comprising:
determining (<NUM>, <NUM>, <NUM>) a request message for random access, wherein the request message comprises a preamble and a physical uplink shared channel, PUSCH, message and the PUSCH message is determined based on a first radio network temporary identity, RNTI; and
transmitting (<NUM>) the request message;
obtaining (<NUM>) a response message for random access based on a second RNTI;
characterized in that
the first RNTI is used for scrambling encoded bits of the PUSCH message;
the second RNTI is used for scrambling a Cyclic redundancy check, CRC, of a Physical Downlink Control Channel, PDCCH, message scheduling a Physical Downlink Shared Channel, PDSCH, carrying the response message;
the second RNTI is different from the first RNTI, and
a cell-RNTI, C-RNTI, is determined as the second RNTI if the C-RNTI is available.