Terminal, base station, communication method, and integrated circuit

Abstract

A terminal including: a reception circuit that receives information which is directed to terminals of a first number of types and relates to a second number of settings for a random access signal, the second number being smaller than the first number; and a transmission circuit that transmits the random access signals on the basis of the information.

Description

Terminal, base station, and communication method

[0001] The present disclosure relates to a terminal, a base station, and a communication method.

[0002] A communication system known as the fifth-generation mobile communication system (5G) is currently under consideration. The 3rd Generation Partnership Project (3GPP), an international standardization organization, is studying the advancement of the 5G communication system from the perspectives of both the advancement of the LTE / LTE-Advanced system and New Radio Access Technology (also referred to as New RAT or NR), a new method that is not necessarily backward compatible with the LTE / LTE-Advanced system (see, for example, Non-Patent Document 1).

[0003] RP-181726, “Revised WID on New Radio Access Technology”, NTT DOCOMO, September 2018RP-213661, “New SID on Study on further NR RedCap UE complexity reduction”, Ericsson, December 2021

[0004] There is room for further consideration regarding the method of transmitting the random access signal.

[0005] Non-limiting examples of the present disclosure contribute to providing a terminal, a base station, and a communication method that can appropriately transmit a random access signal.

[0006] A terminal according to one embodiment of the present disclosure includes a receiving circuit that receives information regarding a setting of a second number of random access signals for a first number of types of terminals, the second number being smaller than the first number, and a transmitting circuit that transmits the random access signals based on the information.

[0007] These comprehensive or specific aspects may be realized as a system, an apparatus, a method, an integrated circuit, a computer program, or a recording medium, or may be realized as any combination of a system, an apparatus, a method, an integrated circuit, a computer program, and a recording medium.

[0008] According to an embodiment of the present disclosure, the random access signal can be transmitted appropriately.

[0009] Further advantages and benefits of one embodiment of the present disclosure will become apparent from the specification and drawings. Such advantages and / or benefits may be provided by some embodiments and features described in the specification and drawings, respectively, but not necessarily all of them may be provided to obtain one or more identical features.

[0010] Diagram showing an example of Physical Random Access Channel (PRACH) configurationBlock diagram showing an example of the configuration of a portion of a base stationBlock diagram showing an example of the configuration of a portion of a terminalBlock diagram showing an example of the configuration of a base stationBlock diagram showing an example of the configuration of a terminalDiagram showing an example of the operation of a base station and a terminalDiagram showing an example of PRACH configurationDiagram showing an example of PRACH configurationDiagram showing an example of the operation of a base station and a terminalDiagram showing an example of PRACH configurationDiagram showing an example of the relationship between terminal types and PRACH configurationDiagram showing an example of PRACH configurationDiagram showing an example of the relationship between terminal types and PRACH configurationDiagram showing an example of the relationship between PRACH configuration and preamble indexDiagram showing an example of parameters in PRACH configurationDiagram showing an example of PRACH configurationDiagram of an exemplary architecture of a 3GPP NR systemSchematic diagram showing functional separation between NG-RAN and 5GCSequence diagram of Radio Resource Control (RRC) connection setup / reconfiguration proceduresSupported by enhanced Mobile BroadBand (eMBB), massive Machine Type Communications (mMTC), and Ultra Reliable and Low Latency Communications (URLLC) Schematic diagram illustrating a 5G Communications usage scenario. Block diagram illustrating an exemplary 5G system architecture for a non-roaming scenario.

[0011] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the drawings.

[0012] In the following description, for example, a radio frame, a slot, and a symbol are units of physical resources in the time domain. For example, the length of one frame may be 10 milliseconds. For example, one frame may be composed of multiple slots (e.g., 10, 20, or other values). Furthermore, the number of slots constituting one frame may be variable depending on the slot length. Furthermore, one slot may be composed of multiple symbols (e.g., 14 or 12). For example, one symbol is the smallest physical resource unit in the time domain, and the symbol length may vary depending on the subcarrier spacing (SCS).

[0013] Furthermore, a subcarrier and a resource block (RB) are units of physical resources in the frequency domain. For example, one resource block may consist of 12 subcarriers. For example, one subcarrier may be the smallest physical resource unit in the frequency domain. The subcarrier spacing (SCS) is variable and may be, for example, 15 kHz, 30 kHz, 60 kHz, 120 kHz, 240 kHz, 480 kHz, 960 kHz, or other values.

[0014] [About evolved Reduced Capability NR Devices] Release 18 NR (hereinafter also referred to as Rel-18) is expected to support terminals (e.g., mobile stations or user equipment (UE)) called evolved Reduced Capability NR Devices (eRedCap) (e.g., referred to as eRedCap terminals). Compared to Releases 15 / 16 / 17 (e.g., also referred to as Rel-15 / 16 / 17), eRedCap terminals aim to reduce, for example, power consumption or manufacturing costs by limiting some of the supported characteristics or performance (e.g., capabilities) and to support a variety of use cases (see, for example, Non-Patent Document 2).

[0015] Cells that support NR in Rel-18 and later (e.g., frequency range 1 (FR1) cells) can be accessed by the following three types of terminals: - Reduced Capability NR Devices - eRedCap Terminals - Non-RedCap Terminals

[0016] The RedCap terminal may be, for example, a terminal in which the number of resource blocks (e.g., the number of Physical Resource Blocks (PRBs)) used for transmitting and receiving a downlink data channel (e.g., PDSCH: Physical Downlink Shared Channel) or an uplink data channel (e.g., PUSCH: Physical Uplink Shared Channel) is equivalent to a maximum of 20 MHz. Also, the RedCap terminal may be, for example, a terminal supported by Release 17 NR (hereinafter also referred to as Rel-17).

[0017] Furthermore, the eRedCap terminal may be, for example, a terminal in which the number of PRBs used for transmitting and receiving PDSCH / PUSCH is equivalent to a maximum of 5 MHz.

[0018] Furthermore, a non-RedCap terminal may be, for example, a terminal that does not belong to either a RedCap terminal or an eRedCap terminal. For example, a non-RedCap terminal may be a terminal that uses a maximum PRB number of 100 MHz for transmitting and receiving PDSCH / PUSCH.

[0019] <Regarding early indication and PRACH configuration in RedCap terminals> RedCap terminals can notify a base station (also called a gNB or gNodeB) that they are RedCap terminals, for example, by using an uplink channel (e.g., Physical Random Access Channel (PRACH) or PUSCH) during initial access (random access procedure). This allows the base station to allocate appropriate resources to RedCap terminals at an early stage. This mechanism is sometimes called "early indication."

[0020] An example of early indication in PRACH will be described below.

[0021] The base station notifies the terminal of PRACH configurations available to the terminal using system information (SI). The PRACH configurations may include parameters such as a preamble identifier (PRACH preamble index) and physical resources for the PRACH (PRACH occasion, RO).

[0022] For example, the base station may notify both the "PRACH configuration for non-RedCap" and the "PRACH configuration for RedCap."

[0023] The RedCap mobile station that has received the notification transmits a preamble (also called a random access signal, PRACH signal, Msg1, or MsgA) based on the “PRACH setting for RedCap.” This allows the base station to recognize (or identify) that the terminal that transmitted the preamble received based on the PRACH setting for RedCap is a RedCap terminal.

[0024] For example, when only RedCap terminals and non-RedCap terminals access a certain cell (for example, when eRedCap terminals do not access), early indication can be performed according to the above-described method. On the other hand, there has been insufficient discussion about early indication and PRACH configuration methods when three types of terminals, eRedCap terminals, RedCap terminals, and non-RedCap terminals, access a cell.

[0025] Therefore, in a non-limiting embodiment of the present disclosure, a method for configuring a PRACH when three types of terminals, eRedCap terminal, RedCap terminal, and non-RedCap terminal, access a cell will be described.

[0026] One example is a method in which a base station notifies three types of PRACH configurations: "PRACH configuration for non-RedCap," "PRACH configuration for RedCap," and "PRACH configuration for eRedCap." However, this method increases the number of test items (e.g., operation verification) to determine whether the three types of PRACH configurations can be properly operated, which raises concerns about an increase in terminal costs, etc.

[0027] Here, a case may be assumed in which the number of RedCap terminals accessing a certain cell is much greater than the number of eRedCap terminals. In this case, the base station may notify the following two PRACH configuration combinations (also referred to as "Plurality 1"), for example, as shown in FIG. 1(a). With this PRACH configuration combination, RedCap terminals and eRedCap terminals may transmit preambles using a common PRACH configuration. - PRACH configuration A: configuration for non-RedCap terminals - PRACH configuration B: configuration for RedCap terminals and eRedCap terminals

[0028] On the other hand, a case may be assumed in which the number of eRedCap terminals accessing a certain cell is much greater than the number of RedCap terminals. In this case, the base station may notify the following two PRACH configuration combinations (also referred to as "Plurality 2"), for example, as shown in FIG. 1(b). With this PRACH configuration combination, non-RedCap terminals and RedCap terminals can transmit preambles using a common PRACH configuration. - PRACH configuration A: configuration for non-RedCap terminals and RedCap terminals - PRACH configuration B: configuration for eRedCap terminals

[0029] According to these PRACH setting methods, the number of PRACH settings included in one PRACH setting combination (Plurality) is two, which has the advantage of simplifying terminal testing, etc., compared to the case where a PRACH setting is used for each of the three types of terminals.

[0030] Which of these PRACH configuration combinations (e.g., Plurality 1 and Plurality 2) to notify the terminal can be determined by the base station depending on, for example, the cell situation (or certain conditions). By varying the combination of PRACH configurations to be notified depending on the cell situation, it becomes possible to operate a more appropriate PRACH configuration.

[0031] An example of a method for notifying multiple PRACH settings (combinations of PRACH settings) will be described below.

[0032] [Outline of Communication System] The communication system according to this embodiment includes a base station 100 and a terminal 200. The terminal 200 may be, for example, an eRedCap terminal, a RedCap terminal, or a non-eRedCap terminal.

[0033] 2 is a block diagram showing an example of the configuration of a portion of a base station 100 according to this embodiment. In the base station 100 shown in FIG. 1, a transmitter (e.g., corresponding to a transmitter circuit) transmits information regarding a second number of settings (e.g., PRACH settings) of random access signals, the second number being smaller than the first number, for a first number of types of terminals. A receiver (e.g., a receiver circuit) receives the random access signals based on the information.

[0034] 3 is a block diagram showing an example of the configuration of a portion of a terminal 200 according to this embodiment. In the terminal 200 shown in FIG. 2, a receiving unit (e.g., corresponding to a receiving circuit) receives information regarding the setting of a second number of random access signals, which is smaller than the first number, for a first number of types of terminals. A transmitting unit (e.g., corresponding to a transmitting circuit) transmits the random access signals based on the information.

[0035] (Embodiment 1) In this embodiment, base station 100 may notify terminal 200 of each of a plurality of PRACH configurations using at least one of the following: SI part X; SI part Y; and SI part Z.

[0036] SI part X may be, for example, SI (System Information) that can be decoded by non-RedCap terminals, RedCap terminals, and eRedCap terminals (or identifiable SI).

[0037] SI part Y may be, for example, SII (or identifiable SI) among SI that can be decoded by RedCap terminals and eRedCap terminals. For example, SI part Y may not be decoded by non-RedCap terminals.

[0038] SI part Z may be, for example, SI (or identifiable SI) that can be decoded by an eRedCap terminal among SI. For example, SI part Z may not be decoded by a non-RedCap terminal or a RedCap terminal.

[0039] Terminal 200 may transmit a preamble based on the PRACH configuration included in any one of SI parts X, Y, and Z, for example.

[0040] The terminal 200 may select the SI part according to the following selection method, for example.

[0041] For example, when the eRedCap terminal identifies a PRACH setting (referred to as "PRACH setting Z") included in SI part Z, it selects PRACH setting Z. When the eRedCap terminal does not identify PRACH setting Z but identifies a PRACH setting (referred to as "PRACH setting Y") included in SI part Y, it selects PRACH setting Y. When the eRedCap terminal does not identify either PRACH setting Z or PRACH setting Y but identifies a PRACH setting (referred to as "PRACH setting X") included in SI part X, it selects PRACH setting X. In other words, the eRedCap terminal prioritizes PRACH setting Y notified by SI part Y over PRACH setting X notified by SI part X, and prioritizes PRACH setting Z notified by SI part Z over PRACH setting Y notified by SI part Y.

[0042] Also, for example, when the RedCap terminal identifies PRACH setting Y, it selects PRACH setting Y. Also, when the RedCap terminal does not identify PRACH setting Y but identifies PRACH setting X, it selects PRACH setting X. That is, the RedCap terminal preferentially selects PRACH setting Y notified by SI part Y over PRACH setting X notified by SI part X.

[0043] Also, for example, when the Non-RedCap terminal identifies the PRACH setting X, it selects the PRACH setting X.

[0044] As described above, the terminal 200 only needs to decode the information necessary for the terminal 200, and therefore the complexity and power consumption related to the preamble transmission process can be reduced.

[0045] [Configuration of Base Station] Fig. 4 is a block diagram showing an example configuration of base station 100 according to this embodiment. In Fig. 4, base station 100 has control unit 101, Downlink Control Information (DCI) generation unit 102, upper layer signal generation unit 103, coding and modulation unit 104, signal mapping unit 105, transmission unit 106, antenna 107, reception unit 108, signal separation unit 109, and demodulation and decoding unit 110.

[0046] For example, at least one of the transmitting unit 106 and the antenna 107 shown in Fig. 4 may be included in the transmitting unit shown in Fig. 2. Also, for example, at least one of the antenna 107 and the receiving unit 108 shown in Fig. 4 may be included in the receiving unit shown in Fig. 2.

[0047] The control unit 101 may, for example, determine resources (including, for example, downlink resources and uplink resources) to be allocated to the terminal 200. The control unit 101 may also, for example, determine the configuration of the PRACH.

[0048] For example, the control unit 101 may instruct the upper layer signal generating unit 103 to generate an upper layer signal (also referred to as an upper layer parameter or upper layer signaling, for example) based on information on the determined resources or information on the PRACH configuration. Furthermore, the control unit 101 may instruct the DCI generating unit 102 to generate control information (for example, DCI) to be included in a downlink control channel (for example, PDCCH) based on information on the determined resources or information on the PRACH configuration, for example.

[0049] Furthermore, the control unit 101 outputs (or instructs) information relating to downlink resources to the signal mapping unit 105 , and outputs (or instructs) information relating to uplink resources to the signal separation unit 109 .

[0050] The DCI generating unit 102 may generate DCI based on an instruction from the control unit 101 , for example, and output the generated DCI to the signal mapping unit 105 .

[0051] The upper layer signal generating unit 103 may generate an upper layer signal such as system information (SI) based on instructions from the control unit 101, for example, and output the generated upper layer signal to the coding / modulation unit 104.

[0052] The coding / modulation unit 104 may, for example, perform error correction coding and modulation on the downlink data and the upper layer signal input from the upper layer signal generation unit 103, and output the modulated signal to the signal mapping unit 105.

[0053] The signal mapping unit 105 may map, to resources, for example, at least one of the DCI input from the DCI generation unit 102 and the signal input from the coding and modulation unit 104. For example, the signal mapping unit 105 may map the signal input from the coding and modulation unit 104 to PDSCH resources and map the DCI to downlink control channel (e.g., PDCCH: Physical Downlink Control Channel) resources. The signal mapping unit 105 outputs the signals mapped to each resource to the transmission unit 106.

[0054] The transmitting unit 106 performs radio transmission processing, including frequency conversion (e.g., up-conversion) using a carrier wave, on the signal input from the signal placement unit 105, and outputs the signal after the radio transmission processing to the antenna 107.

[0055] The antenna 107, for example, emits a signal (for example, a downlink signal) input from the transmitting unit 106 toward the terminal 200. The antenna 107 also receives an uplink signal transmitted from the terminal 200, for example, and outputs the signal to the receiving unit 108.

[0056] The uplink signal may be a signal of a channel such as an uplink data channel (e.g., PUSCH), an uplink control channel (e.g., PUCCH: Physical Uplink Control Channel), or a random access channel (e.g., PRACH: Physical Random Access Channel).

[0057] Receiving section 108 performs radio reception processing including frequency conversion (for example, down-conversion) on the signal input from antenna 107 , and outputs the signal after radio reception processing to signal separating section 109 .

[0058] For example, based on information on uplink resources input from the control unit 101, the signal separation unit 109 extracts (or separates) signals on PUCCH resources (for example, uplink control information (UCI)) and signals on PRACH (for example, preambles) from the signals input from the receiving unit 108. Furthermore, the signal separation unit 109 outputs, for example, signals on PUSCH resources from the signals input from the receiving unit 108 to the demodulation and decoding unit 110.

[0059] The demodulation / decoding unit 110 demodulates and decodes the signal input from the signal separation unit 109, for example, and outputs uplink data.

[0060] [Configuration of Terminal] FIG. 5 is a block diagram showing an example of the configuration of terminal 200 according to this embodiment.

[0061] In FIG. 5 , terminal 200 has antenna 201, receiving section 202, signal separating section 203, DCI detecting section 204, demodulating / decoding section 205, control section 206, preamble generating section 207, coding / modulating section 208, signal mapping section 209, and transmitting section 210.

[0062] For example, at least one of the antenna 201 and the receiving unit 202 shown in Fig. 5 may be included in the receiving unit shown in Fig. 3. Also, for example, at least one of the antenna 201 and the transmitting unit 210 shown in Fig. 5 may be included in the transmitting unit shown in Fig. 3.

[0063] The antenna 201 receives, for example, a downlink signal (downlink channel) transmitted by the base station 100 and outputs the signal to the receiving unit 202. The antenna 201 also radiates, for example, an uplink signal (uplink channel) input from the transmitting unit 210 to the base station 100.

[0064] The receiving unit 202 performs radio reception processing including frequency conversion (for example, down-conversion) on the signal input from the antenna 201 , and outputs the signal after radio reception processing to the signal separating unit 203 .

[0065] For example, the signal separating unit 203 extracts (e.g., separates) signals on PDCCH resources from the signals input from the receiving unit 202, and outputs the extracted signals to the DCI detecting unit 204. Furthermore, for example, based on an instruction from the control unit 206, the signal separating unit 203 outputs signals on PDSCH resources from the signals input from the receiving unit 202 to the demodulating and decoding unit 205. Note that the signal separating unit 203 may perform signal separation based on information (not shown) on downlink resources instructed by the control unit 206, for example.

[0066] For example, the DCI detection unit 204 may detect DCI from the signal (for example, the signal on the PDCCH resource) input from the signal separation unit 203. The DCI detection unit 204 may output the detected DCI to the control unit 206, for example.

[0067] The demodulation and decoding unit 205, for example, demodulates and performs error correction decoding on a signal (e.g., a signal on a PDSCH resource) input from the signal separation unit 203 to obtain at least one of downlink data and an upper layer signal such as system information (SI). The demodulation and decoding unit 205 may, for example, output the upper layer signal (e.g., SI) obtained by decoding to the control unit 206. The demodulation and decoding unit 205 may also output the downlink data obtained by decoding, for example.

[0068] The control unit 206 may determine (or identify) downlink resources and uplink resources (e.g., PRACH configuration) based on, for example, at least one of the DCI input from the DCI detection unit 204 and the higher layer signal (e.g., SI) input from the demodulation and decoding unit 205. For example, the control unit 206 may output (e.g., instruct) information on the identified uplink resources to the signal mapping unit 209. Furthermore, for example, the control unit 206 may instruct the preamble generation unit 207 to generate a preamble based on the identified PRACH configuration.

[0069] Preamble generating section 207 generates a preamble according to, for example, an instruction from control section 206 and outputs the generated preamble to signal mapping section 209 .

[0070] The coding / modulation unit 208 may, for example, code and modulate the uplink data and output the modulated signal to the signal mapping unit 209 .

[0071] For example, the signal mapping section 209 may map the signal input from the coding and modulation section 208 to a PUSCH resource, map the UCI to a PUCCH resource, and map the preamble to a PRACH resource, based on information regarding the uplink resource input from the control section 206. The signal mapping section 209 outputs the signals mapped to each resource to the transmission section 210.

[0072] The transmitting section 210 performs radio transmission processing including frequency conversion (for example, up-conversion) on the signal input from the signal mapping section 209 , and outputs the signal after the radio transmission processing to the antenna 201 .

[0073] [Example of Operation of Base Station 100 and Terminal 200] Next, an example of operation of the base station 100 and terminal 200 described above will be described.

[0074] <Operation Example 1-1> FIG. 6 is a flowchart showing an example of processing by the base station 100 (for example, a gNB) and the terminal 200 (for example, a UE) according to Operation Example 1-1.

[0075] (S101) The base station 100 determines a combination of PRACH settings. Here, as an example, as shown in Fig. 7, the base station 100 may determine the following combinations of PRACH settings (for example, two settings) (Plurality 1): PRACH setting X: PRACH setting for non-RedCap terminals; PRACH setting Y: PRACH setting for RedCap terminals and eRedCap terminals.

[0076] Note that the multiple PRACH configurations (e.g., PRACH preamble index and PRACH occasion (e.g., time / frequency resource)) included in the above PRACH configuration combination may include different configurations. For example, in FIG. 7 , at least one of the PRACH preamble index and the PRACH occasion (e.g., time / frequency resource) may be different between PRACH configuration X and PRACH configuration Y. This allows base station 100 to identify the type of terminal 200 that has transmitted the preamble based on at least one of the preamble index and the PRACH occasion of the received PRACH.

[0077] Furthermore, base station 100 notifies terminal 200 of information related to the determined combination of PRACH settings (for example, each of the multiple PRACH settings included in the combination of PRACH settings) by, for example, SI. For example, the multiple PRACH settings included in the combination of PRACH settings (for example, PRACH setting X and PRACH setting Y) may be distributed to SI as follows and notified to terminal 200. - PRACH setting X: SI that can be decoded by non-RedCap terminals, RedCap terminals, and eRedCap terminals (hereinafter referred to as "SI part X") - PRACH setting Y: SI that can be decoded by RedCap terminals and eRedCap terminals (hereinafter referred to as "SI part Y")

[0078] Note that SI part X may be information based on SI corresponding to Rel-15 or Rel-16, and SI part Y may be information based on SI corresponding to Rel-17.

[0079] Base station 100 transmits SI (for example, SI part X, SI part Y) including information regarding the combination of the PRACH settings to terminal 200. In this way, base station 100 notifies terminal 200, for example, information regarding two types of PRACH settings (PRACH setting X and PRACH setting Y) for three types of terminal types (non-RedCap terminal, RedCap terminal, eRedCap terminal) using SI part X and SI part Y.

[0080] (S102) The terminal 200 receives the SI transmitted from the base station 100.

[0081] (S103) Terminal 200 decodes the SI received in S102 and identifies the PRACH configuration. Note that the decoding operation (or the SI part to be decoded) may differ depending on the type of terminal 200 (for example, a non-RedCap terminal, a RedCap terminal, or an eRedCap terminal).

[0082] For example, the non-RedCap terminal may decode SI part X. In operation example 1-1, the non-RedCap terminal may identify PRACH configuration X included in SI part X.

[0083] Also, for example, the RedCap terminal may attempt to decode SI part Y and SI part X. In operation example 1-1, the RedCap terminal may identify PRACH setting X included in SI part X and PRACH setting Y included in SI part Y.

[0084] Also, for example, the eRedCap terminal may attempt to decode SI part Z, SI part Y, and SI part X. In operation example 1-1, the eRedCap terminal may identify PRACH setting X included in SI part X and PRACH setting Y included in SI part Y.

[0085] In the above-described example, a case has been described in which terminal 200 (for example, a non-RedCap terminal, a RedCap terminal, and an eRedCap terminal) attempts to decode all SI that can be decoded according to the terminal type, but the present invention is not limited to this. In operation example 1-1, information indicating the use of Plurality 1 (for example, PRACH setting X and PRACH setting Y) as a combination of multiple PRACH settings may be separately notified to terminal 200 by a control signal or the like. In this case, the eRedCap terminal may perform decoding processing on SI part Y and SI part X, for example, without performing decoding processing on SI part Z (SI corresponding to PRACH setting Z that is not included in Plurality 1).

[0086] Also, in operation example 1-1, the RedCap terminal and eRedCap terminal may omit the decoding process of SI part X when, for example, PRACH setting Y is identified.

[0087] (S104) Terminal 200 selects a PRACH configuration to be used for preamble transmission from the PRACH configurations identified in S103. For example, the operation of selecting a PRACH configuration may differ depending on the type of terminal 200 (terminal type), as follows.

[0088] For example, a non-RedCap terminal may select PRACH configuration X.

[0089] Furthermore, for example, the RedCap terminal and the eRedCap terminal may select the PRACH setting Y with priority over the PRACH setting X from among the identified PRACH setting X and PRACH setting Y.

[0090] For example, RedCap terminals and eRedCap terminals may preferentially decode or select PRACH setting Y included in SI part Y, which can be decoded by fewer terminal types (e.g., RedCap terminals and eRedCap terminals), over PRACH setting X included in SI part X, which can be decoded by many terminal types (e.g., non-RedCap terminals, RedCap terminals and eRedCap terminals).

[0091] Also, for example, RedCap terminals and eRedCap terminals may preferentially decode or select PRACH setting Y included in SI part Y based on the newer release Rel-17 over PRACH setting X included in SI part X based on Rel-15 / 16.

[0092] (S105) The terminal 200 transmits a preamble based on each PRACH configuration selected in S104.

[0093] (S106) The base station 100 receives a preamble based on the PRACH configuration.

[0094] According to the operation example 1-1, the terminal 200 only needs to decode information necessary for the terminal 200, which has the effect of reducing the complexity or power consumption related to preamble transmission.

[0095] <Operation Example 1-2> An example of processing by the base station 100 (for example, gNB) and the terminal 200 (for example, UE) according to Operation Example 1-2 may be similar to the example of processing in Operation Example 1-1 shown in FIG.

[0096] (S101) The base station 100 determines a combination of PRACH settings. Here, as an example, as shown in Fig. 8, the base station 100 may determine the following combinations of PRACH settings (for example, two settings) (Plurality 2): PRACH setting X: PRACH setting for non-RedCap terminals and RedCap terminals; PRACH setting Z: PRACH setting for eRedCap terminals.

[0097] Note that the multiple PRACH configurations (e.g., PRACH preamble index and PRACH occasion (e.g., time / frequency resource)) included in the above PRACH configuration combination may include different configurations. For example, in FIG. 8 , at least one of the PRACH preamble index and the PRACH occasion (e.g., time / frequency resource) may be different between PRACH configuration X and PRACH configuration Z. This allows base station 100 to identify the type of terminal 200 that has transmitted the preamble based on at least one of the preamble index and the PRACH occasion of the received PRACH.

[0098] Furthermore, base station 100 notifies terminal 200 of information related to the determined combination of PRACH settings (for example, each of the multiple PRACH settings included in the combination of PRACH settings) by, for example, SI. For example, the multiple PRACH settings included in the combination of PRACH settings (for example, PRACH setting X and PRACH setting Z) may be distributed to SI as follows and notified to terminal 200. - PRACH setting X: SI that can be decoded by non-RedCap terminals, RedCap terminals, and eRedCap terminals (hereinafter referred to as "SI part X") - PRACH setting Z: SI that can be decoded by eRedCap terminals (hereinafter referred to as "SI part Z")

[0099] In the operation example 1-2, unlike the SI part Y in the operation example 1-1, the SI part Z does not need to be decoded by a terminal other than the eRedCap terminal (for example, a RedCap terminal).

[0100] Note that SI part X may be information based on SI corresponding to Rel-15 or Rel-16, and SI part Z may be information based on SI corresponding to Rel-18.

[0101] Base station 100 transmits SI (for example, SI part X, SI part Z) including information related to the above-mentioned combination of PRACH settings to terminal 200. In this way, base station 100 notifies terminal 200, for example, information related to two types of PRACH settings (PRACH setting X and PRACH setting Z) for three types of terminal types (non-RedCap terminal, RedCap terminal, eRedCap terminal) using SI part X and SI part Z.

[0102] (S102) The terminal 200 receives the SI transmitted from the base station 100.

[0103] (S103) Terminal 200 decodes the SI and identifies the PRACH configuration. Note that the decoding operation (or the SI part to be decoded) may differ depending on the type of terminal 200 (for example, a non-RedCap terminal, a RedCap terminal, or an eRedCap terminal).

[0104] For example, the non-RedCap terminal may decode SI part X. In operation example 1-2, the non-RedCap terminal may identify PRACH configuration X included in SI part X.

[0105] Also, for example, the RedCap terminal may attempt to decode SI part Y and SI part X. In operation example 1-2, the RedCap terminal may identify PRACH setting X included in SI part X. Thus, in operation example 1-2, unlike operation example 1-1, the RedCap terminal does not identify a PRACH setting (e.g., PRACH setting Y) different from PRACH setting X.

[0106] Also, for example, the eRedCap terminal may attempt to decode SI part Z, SI part Y, and SI part X. In operation example 1-2, the eRedCap terminal may identify PRACH setting X included in SI part X and PRACH setting Z included in SI part Z.

[0107] Note that, in the above-described example, a case has been described in which terminal 200 (for example, a non-RedCap terminal, a RedCap terminal, and an eRedCap terminal) attempts to decode all SI that can be decoded according to the terminal type, but the present invention is not limited to this. In operation example 1-2, information indicating the use of Plurality 2 (for example, PRACH setting X and PRACH setting Z) as a combination of multiple PRACH settings may be separately notified to terminal 200 by a control signal or the like. In this case, for example, an eRedCap terminal may perform decoding processing of SI part Z and SI part X without performing decoding processing of SI part Y (SI corresponding to PRACH setting Y that is not included in Plurality 2), and a RedCap terminal may perform decoding processing of SI part X without performing decoding processing of SI part Y.

[0108] Also, in operation example 1-2, if the eRedCap terminal identifies PRACH setting Z, for example, it may omit the decoding process of SI part X and SI part Y.

[0109] (S104) Terminal 200 selects a PRACH configuration to be used for preamble transmission from the PRACH configurations identified in S103. For example, the operation of selecting a PRACH configuration may differ depending on the type of terminal 200 (terminal type), as follows.

[0110] For example, a non-RedCap terminal and a RedCap terminal may select PRACH configuration X.

[0111] Also, for example, the eRedCap terminal may select the PRACH setting Z with priority over the PRACH setting X from among the identified PRACH setting Z and PRACH setting X.

[0112] For example, an eRedCap terminal may preferentially decode or select PRACH setting Z included in SI part Z, which can be decoded by fewer terminal types (e.g., eRedCap terminals), over PRACH setting X included in SI part X, which can be decoded by many terminal types (e.g., non-RedCap terminals, RedCap terminals, and eRedCap terminals).

[0113] Also, for example, an eRedCap terminal may preferentially decode or select PRACH setting Z included in SI part Z based on a newer release, Rel-18, over PRACH setting X included in SI part X based on Rel-15 / 16.

[0114] (S105) The terminal 200 transmits a preamble based on each PRACH configuration selected in S104.

[0115] (S106) The terminal 200 receives a preamble based on the PRACH configuration.

[0116] According to the operation example 1-2, the terminal 200 only needs to decode information necessary for the terminal 200, which has the effect of reducing the complexity or power consumption related to preamble transmission.

[0117] An example of the operation of the base station 100 and the terminal 200 has been described above.

[0118] As described above, in the present embodiment, base station 100 transmits information on a second number of PRACH configurations (e.g., two types of PRACH configurations) that is less than the first number for a first number of terminal types (e.g., three types of terminal types) to terminal 200, and receives a PRACH signal (e.g., a preamble) based on the information. Furthermore, terminal 200 receives information on a second number of PRACH configurations (e.g., two types of PRACH configurations) that is less than the first number for the first number of terminal types (e.g., three types of terminal types) from base station 100, and transmits a PRACH signal (e.g., a preamble) based on the information.

[0119] As a result, even when three types of terminals, for example, an eRedCap terminal, a RedCap terminal, and a non-RedCap terminal, access a cell, each type of terminal 200 can transmit a preamble based on an appropriate PRACH configuration. Thus, according to the present embodiment, terminal 200 can transmit a preamble appropriately.

[0120] For example, even if three types of terminals, eRedCap terminal, RedCap terminal, and non-RedCap terminal, access a cell, by notifying two types of PRACH settings, it is possible to reduce the increase in test items and the increase in costs of terminal 200 compared to operating three types of PRACH settings for each terminal type.

[0121] Furthermore, in the present embodiment, terminal 200 determines which of a plurality of PRACH configurations included in the obtained SI (for example, any one of SI part X, SI part Y, and SI part Z) to preferentially select, for example, according to the terminal type of terminal 200. That is, base station 100 can implicitly notify "information regarding which type of terminal each PRACH configuration is used by" by distributing PRACH configurations for each terminal type to SIs (for example, any one of SI part X, SI part Y, and SI part Z) with different identifiable terminal types (or different numbers of terminal types) and notifying them. This allows terminal 200 to identify the PRACH configuration without explicitly notifying "information regarding which type of terminal each PRACH configuration is used by."

[0122] In this embodiment, base station 100 may flexibly switch PRACH settings (e.g., combinations of PRACH settings) depending on information (or conditions) regarding cell conditions, such as the number of terminal types accessing the cell, different use cases, or time periods.

[0123] For example, depending on a certain condition (or situation), any one of a plurality of candidates for information regarding the PRACH setting combination (for example, the above-mentioned Plurality 1 and Plurality 2) may be notified to terminal 200. For example, base station 100 may notify terminal 200 of the PRACH setting combination (Plurality 1) as in Operation Example 1-1 in a certain situation, and may notify terminal 200 of the PRACH setting combination (Plurality 2) as in Operation Example 1-2 in another situation.

[0124] For example, when the number of RedCap terminals accessing the cell is much greater than the number of eRedCap terminals (for example, when the difference between the number of RedCap terminals and the number of eRedCap terminals is equal to or greater than a threshold), the base station 100 may notify the terminal 200 of a PRACH configuration such as that in operation example 1-1. This allows RedCap terminals to appropriately transmit preambles based on a PRACH configuration that differs from that of non-RedCap terminals.

[0125] Furthermore, for example, when the number of eRedCap terminals accessing the cell is much greater than the number of RedCap terminals (for example, when the difference between the number of eRedCap terminals and the number of RedCap terminals is equal to or greater than a threshold), the base station 100 may notify the terminal 200 of a PRACH configuration such as that in operation example 1-2. This allows the eRedCap terminal to appropriately transmit a preamble based on a PRACH configuration that can only be used by eRedCap terminals.

[0126] As a result, base station 100 can notify the optimal PRACH configuration depending on the cell situation. Furthermore, terminal 200 may flexibly switch the PRACH configuration to be used, for example, in accordance with a notification from base station 100 (for example, a specified SI).

[0127] Second Embodiment The base station 100 and the terminal 200 according to this embodiment may be the same as those in the first embodiment.

[0128] Base station 100 explicitly notifies terminal 200 of, for example, "information on a plurality of PRACH configurations" and "information on which type of terminal uses each PRACH configuration."

[0129] The terminal 200 selects a PRACH configuration based on the information notified (or instructed) by the base station 100, and transmits a preamble based on the selected PRACH configuration.

[0130] An example of the operation of base station 100 and terminal 200 according to this embodiment will be described below.

[0131] <Operation Example 2-1> FIG. 9 is a flowchart showing an example of processing by the base station 100 (for example, a gNB) and the terminal 200 (for example, a UE) according to Operation Example 2-1.

[0132] (S201) The base station 100 determines a combination of PRACH settings. Here, as an example, as shown in Fig. 10, the base station 100 may determine the following combinations of PRACH settings (for example, two settings) (Plurality 1): PRACH setting A: PRACH setting for non-RedCap terminals; PRACH setting B: PRACH setting for RedCap terminals and eRedCap terminals.

[0133] Note that the multiple PRACH configurations (e.g., PRACH preamble index and PRACH occasion (e.g., time / frequency resource)) included in the above PRACH configuration combination may include different configurations. For example, in FIG. 10 , at least one of the PRACH preamble index and the PRACH occasion (e.g., time / frequency resource) may be different between PRACH configuration A and PRACH configuration B. This allows base station 100 to identify the type of terminal 200 that has transmitted the preamble based on at least one of the preamble index and the PRACH occasion of the received PRACH.

[0134] In addition, the base station 100 may determine information regarding the relationship (or association) between each of the multiple PRACH settings (e.g., two types of setting types) included in the PRACH setting combination and the terminal type (e.g., three types of non-RedCap terminals, RedCap terminal, and eRedCap terminal), for example, as shown in FIG. 11 .

[0135] The base station 100 transmits, to the terminal 200, SI including, for example, information regarding the combination of the PRACH settings (for example, Plurality 1 including PRACH setting A and PRACH setting B) and information regarding the relationship between each PRACH setting and the terminal type.

[0136] (S202) The terminal 200 receives the SI transmitted from the base station 100.

[0137] (S203) Terminal 200 decodes the SI received in S202, and identifies the combination of PRACH settings and the relationship between each PRACH setting and terminal type.

[0138] Furthermore, terminal 200 selects a PRACH configuration to be used for preamble transmission by terminal 200 based on the relationship between each PRACH configuration and the terminal type. For example, in the example of Fig. 11, terminal 200 selects PRACH configuration A if the terminal is a non-RedCap terminal, and selects PRACH configuration B if the terminal is a RedCap terminal or eRedCap terminal.

[0139] (S204) Terminal 200 transmits a preamble based on each PRACH configuration selected in S203.

[0140] (S205) The base station 100 receives a preamble based on the PRACH configuration.

[0141] In operation example 2-1, information regarding combinations of PRACH settings and information regarding the relationship between each PRACH setting and a terminal type may be notified by, for example, SI that can be decoded by all terminal types (for example, non-RedCap terminals, RedCap terminals, and eRedCap terminals). This allows each terminal 200 to identify (or understand) "how base station 100 allocates each terminal type to combinations of PRACH settings" and optimize subsequent operations based on this information.

[0142] In operation example 2-1, the information on the combination of PRACH settings is not limited to being notified by SI that can be decoded by all terminal types. For example, similar to embodiment 1, the information on the combination of PRACH settings may be notified by being distributed to a plurality of SIs that have different identifiable terminal types. Even in this case, terminal 200 of some of the terminal types can identify the SI to attempt decoding based on, for example, information on the relationship between each PRACH setting and the terminal type, thereby simplifying the processing of terminal 200.

[0143] <Operation Example 2-2> An example of processing by the base station 100 (for example, gNB) and the terminal 200 (for example, UE) according to Operation Example 2-2 may be similar to the example of processing in Operation Example 2-1 shown in FIG.

[0144] (S201) The base station 100 determines a combination of PRACH settings. Here, as an example, as shown in FIG. 12 , the base station 100 may determine the following combinations of multiple (for example, two) PRACH settings (Plurality 2): PRACH setting A: PRACH setting for non-RedCap terminals and RedCap terminals; PRACH setting B: PRACH setting for eRedCap terminals.

[0145] Note that the multiple PRACH configurations (e.g., PRACH preamble index and PRACH occasion (e.g., time / frequency resource)) included in the above PRACH configuration combination may include different configurations. For example, in FIG. 12 , at least one of the PRACH preamble index and the PRACH occasion (e.g., time / frequency resource) may be different between PRACH configuration A and PRACH configuration B. This allows base station 100 to identify the type of terminal 200 that has transmitted the preamble based on at least one of the preamble index and the PRACH occasion of the received PRACH.

[0146] Furthermore, the base station 100 may determine information regarding the relationship (or association) between each of a plurality of PRACH configurations (e.g., PRACH configuration indexes identifying two types of PRACH configuration A and PRACH configuration B) included in the PRACH configuration combination and a terminal type (e.g., three types of non-RedCap terminals, RedCap terminals, and eRedCap terminals), as shown in, for example, FIG. 12 .

[0147] Base station 100 transmits, to terminal 200, SI including, for example, information regarding the above-mentioned combination of PRACH settings (e.g., Plurality 2 including PRACH setting A and PRACH setting B) and information regarding the relationship between each PRACH setting and terminal type.

[0148] (S202) The terminal 200 receives the SI transmitted from the base station 100.

[0149] (S203) Terminal 200 decodes the SI received in S202, and identifies the combination of PRACH settings and the relationship between each PRACH setting and terminal type.

[0150] Furthermore, based on the relationship between each PRACH configuration and the terminal type, terminal 200 selects a PRACH configuration (or a configuration type) to be used for preamble transmission by terminal 200. For example, in the example of Fig. 13, terminal 200 selects PRACH configuration A in the case of a non-RedCap terminal or a RedCap terminal, and selects PRACH configuration B in the case of an eRedCap terminal.

[0151] (S204) Terminal 200 transmits a preamble based on each PRACH configuration selected in S203.

[0152] (S205) The base station 100 receives a preamble based on the PRACH configuration.

[0153] In operation example 2-2, information regarding combinations of PRACH settings and information regarding the relationship between each PRACH setting and a terminal type may be notified by, for example, SI that can be decoded by all terminal types (for example, non-RedCap terminals, RedCap terminals, and eRedCap terminals). This allows each terminal 200 to identify (or understand) "how base station 100 allocates each terminal type to combinations of PRACH settings" and optimize subsequent operations based on this information.

[0154] In operation example 2-2, the information on the combination of PRACH settings is not limited to being notified by SI that can be decoded by all terminal types. For example, as in embodiment 1, the information on the combination of PRACH settings may be notified by dividing it into multiple SIs for different identifiable terminal types. Even in this case, terminal 200 of some of the terminal types can identify the SI to attempt decoding based on, for example, information on the relationship between each PRACH setting and the terminal type, thereby simplifying the processing of terminal 200.

[0155] An example of the operation of the base station 100 and the terminal 200 has been described above.

[0156] As described above, in the present embodiment, information on a second number of PRACH configurations (e.g., two types of PRACH configurations) that is less than the first number for a first number of terminal types (e.g., three types of terminal types) is transmitted to terminal 200, and a PRACH signal (e.g., a preamble) is received based on the information. Furthermore, terminal 200 receives information on a second number of PRACH configurations (e.g., two types of PRACH configurations) that is less than the first number for the first number of terminal types (e.g., three types of terminal types) from base station 100, and transmits a PRACH signal (e.g., a preamble) based on the information.

[0157] As a result, even when three types of terminals, for example, an eRedCap terminal, a RedCap terminal, and a non-RedCap terminal, access a cell, each type of terminal 200 can transmit a preamble based on an appropriate PRACH configuration. Thus, according to the present embodiment, terminal 200 can transmit a preamble appropriately.

[0158] Furthermore, in the present embodiment, information indicating a plurality of PRACH configurations and information relating to the association between each of the PRACH configurations and a terminal type are explicitly notified from base station 100 to terminal 200. This allows terminal 200 to identify the PRACH configuration used by each terminal type based on the information notified from base station 100.

[0159] In this embodiment, base station 100 may flexibly switch PRACH settings (e.g., combinations of PRACH settings) depending on information (or conditions) regarding cell conditions, such as the number of terminal types accessing the cell, different use cases, or time periods.

[0160] For example, depending on a certain condition (or situation), any one of a plurality of candidates for information regarding the PRACH setting combination (for example, the above-mentioned Plurality 1 and Plurality 2) may be notified to terminal 200. For example, base station 100 may notify terminal 200 of the PRACH setting combination (Plurality 1) as in Operation Example 2-1 in a certain situation, and may notify terminal 200 of the PRACH setting combination (Plurality 2) as in Operation Example 2-2 in another situation.

[0161] For example, when the number of RedCap terminals accessing the cell is much greater than the number of eRedCap terminals (for example, when the difference between the number of RedCap terminals and the number of eRedCap terminals is equal to or greater than a threshold), the base station 100 may notify the terminal 200 of a PRACH configuration such as that in operation example 2-1. This allows RedCap terminals to appropriately transmit preambles based on a PRACH configuration that differs from that of non-RedCap terminals.

[0162] Furthermore, for example, when the number of eRedCap terminals accessing the cell is much greater than the number of RedCap terminals (for example, when the difference between the number of eRedCap terminals and the number of RedCap terminals is equal to or greater than a threshold), the base station 100 may notify the terminal 200 of a PRACH configuration such as that in operation example 2-2. This allows the eRedCap terminal to appropriately transmit a preamble based on a PRACH configuration that can only be used by eRedCap terminals.

[0163] In this way, base station 100 can notify the optimum PRACH configuration depending on the cell situation. Furthermore, terminal 200 may flexibly switch the PRACH configuration to be used in accordance with the notification from base station 100, for example.

[0164] The embodiments of the present disclosure have been described above.

[0165] (Other Embodiments) [Examples of PRACH Configuration] In each of the above embodiments, different preamble indices may be configured for multiple PRACH configurations included in a PRACH configuration combination. For example, as shown in Fig. 14, preamble index 0-9 may be configured for PRACH configuration A included in the PRACH configuration combination, and preamble index 10-19 may be configured for PRACH configuration B. Note that the values ​​and numbers of preamble indices configured for each PRACH configuration (configuration type) are merely examples and are not limited to these.

[0166] Furthermore, the method of notifying the preamble index may be, for example, a method in which the value of the preamble index itself is indicated, or a method in which at least one of the smallest value of multiple preamble indices included in the PRACH configuration (e.g., 0 for PRACH configuration A and 10 for PRACH configuration B in FIG. 14 ) and the number of preamble indices included in the PRACH configuration (e.g., 10 in the example of FIG. 14 ) is indicated.

[0167] Furthermore, the number of preambles included in each PRACH configuration may be the same or different between PRACH configurations. For example, the number of preambles included in each PRACH configuration may be determined according to cell conditions. For example, a PRACH configuration for a larger number of terminal types among non-RedCap terminals, RedCap terminals, and eRedCap mobile stations accessing a cell may include a larger number of preambles than PRACH configurations for other terminal types. As an example, if the number of eRedCap terminals accessing a cell is larger than the number of non-RedCap terminals and RedCap terminals, a PRACH configuration for eRedCap terminals may include a larger number of preambles than the PRACH configurations for non-RedCap terminals and RedCap terminals.

[0168] Furthermore, in each of the above-described embodiments, the PRACH occasions (also referred to as PRACH transmission occasions; for example, time / frequency resources) may be different for multiple PRACH configurations included in a PRACH configuration combination. For example, as shown in FIG. 15 , time / frequency resources may be configured for each configuration type (for example, PRACH configuration A and PRACH configuration B) included in a PRACH configuration combination. Here, the "PRACH configuration index" may be a parameter representing the time resource or the like of the PRACH occasion, and "Msg1-FDM" (for example, the number of PRACH occasions to be frequency-multiplexed) and "Msg1-FrequencyStart" (for example, the offset of the PRACH occasion in the frequency domain) may be parameters representing the frequency resource or the like of the PRACH occasion. Note that the parameters and parameter setting values ​​related to the PRACH occasion are not limited to the parameters shown in FIG. 15 , and may be other parameters or other setting values.

[0169] Furthermore, the size of the time / frequency resource for the PRACH occasion included in each PRACH configuration may be the same or different between PRACH configurations. For example, the size of the time / frequency resource for the PRACH occasion may be determined according to cell conditions. For example, a PRACH configuration for a larger number of terminal types among non-RedCap terminals, RedCap terminals, and eRedCap terminals accessing a cell may include a PRACH occasion resource with a larger size than PRACH configurations for other terminal types. For example, if the number of eRedCap terminals accessing a cell is greater than the number of non-RedCap terminals and RedCap terminals, the PRACH configuration for eRedCap terminals may include a PRACH occasion resource with a larger size than the PRACH configurations for non-RedCap terminals and RedCap terminals.

[0170] [Modifications of PRACH Configuration Combinations] The relationships between the PRACH configurations included in the PRACH configuration combinations shown in the above embodiments and the terminal types are merely examples, and other relationships may be applied. For example, as shown in Fig. 16, a relationship may be such that PRACH configuration A is used by non-RedCap terminals and eRedCap terminals, and PRACH configuration B is used by RedCap terminals. Furthermore, any other combination of relationships between PRACH configurations and terminal types may be used.

[0171] In addition, combinations of PRACH settings may include combinations of PRACH settings that can be decoded by RedCap terminals and eRedCap terminals (e.g., PRACH setting Y in Figure 7) and PRACH settings that can be decoded by eRedCap terminals (e.g., PRACH setting Z in Figure 8).

[0172] Furthermore, in the above embodiment, an example has been described in which the number of PRACH settings included in the PRACH setting combination is two, but the number of PRACH settings included in the PRACH setting combination is not limited to two and may be one or three or more. Similarly, in the above embodiment, an example has been described in which there are three types of terminal types: a non-RedCap terminal, a RedCap terminal, and an eRedCap terminal, but the number of terminal types is not limited to three and may be two or four or more.

[0173] [Regarding the relationship with BWP] The frequency resources for PRACH configuration in each of the above embodiments may be included in the frequency resources (band) occupied by a Bandwidth part (BWP) for RedCap terminals, a BWP for eRedCap terminals, or a BWP common to all terminals (or a BWP not specifically designated for RedCap, etc.).

[0174] Furthermore, the frequency resources of each PRACH configuration in a combination of PRACH configurations may be included in different BWP bands. For example, the frequency resources of one PRACH configuration may be included in the BWP band for RedCap, and the frequency resources of the other PRACH configuration may be included in the BWP band for eRedCap.

[0175] Furthermore, for example, when terminal 200 is notified that PRACH setting A is a PRACH setting for non-RedCap terminals and PRACH setting B is a PRACH setting for RedCap terminals and eRedCap terminals, the frequency resources of PRACH setting A may be included in the band of a BWP common to all terminals (or all terminal types). On the other hand, the frequency resources of PRACH setting B may be included in, for example, at least one band of a BWP for RedCap and a BWP for eRedCap.

[0176] Furthermore, for example, when terminal 200 is notified that PRACH setting A is a PRACH setting for non-RedCap terminals and RedCap terminals, and PRACH setting B is a PRACH setting for eRedCap terminals, the frequency resources of PRACH setting A may be included in the band of a BWP common to all terminals (or all terminal types) or a BWP for RedCap. On the other hand, the frequency resources of PRACH setting B may be included in the band of a BWP for RedCap or a BWP for eRedCap.

[0177] Alternatively, all PRACH configurations may be contained in the same BWP band.

[0178] [Regarding Selection of PRACH Configuration] In the above-described embodiments, the terminal 200 selects a PRACH configuration according to a terminal type corresponding to each PRACH configuration intended by the base station 100. However, the present invention is not limited to this. For example, the terminal 200 may select a PRACH configuration different from that intended by the base station 100 and transmit a preamble.

[0179] For example, when base station 100 configures PRACH setting A for a non-RedCap terminal or a RedCap terminal and configures PRACH setting B for an eRedCap terminal, the eRedCap terminal may transmit a preamble using PRACH setting A instead of PRACH setting B. This enables terminal 200 to transmit a preamble flexibly.

[0180] As an example, the following case can be considered.

[0181] For example, an "eRedCap PR1-standalone" terminal may be introduced as a type of the eRedCap terminal described above. A feature of the eRedCap PR1-standalone terminal is that the number of PRBs used for transmitting and receiving PDSCH or PUSCH is equivalent to a maximum of 20 MHz (e.g., approximately the same as that of a RedCap terminal), and other functions (e.g., the modulation level or the number of MIMO layers) are significantly limited (e.g., set (or limited) to a lower value than that of a RedCap terminal). For example, when the base station 100 configures PRACH configuration A for a non-RedCap terminal or a RedCap terminal and configures PRACH configuration B for an eRedCap terminal, the eRedCap PR1-standalone terminal may transmit a preamble using PRACH configuration A instead of PRACH configuration B. This enables the base station 100 to perform appropriate PDSCH / PUSCH scheduling for eRedCap PR1-standalone terminals capable of transmitting and receiving PRBs equivalent to 20 MHz.

[0182] Note that "PR1-standalone" is just an example of a name, and other names may be used.

[0183] Furthermore, in the above embodiment, a case has been described in which a PRACH configuration is selected (or classified) according to a terminal type for a combination of multiple PRACH configurations, but the present invention is not limited thereto, and a PRACH configuration may be selected according to, for example, a bandwidth (or the number of PRBs) available to terminal 200. This enables base station 100 to perform appropriate PDSCH / PUSCH scheduling according to the bandwidth available to each terminal 200.

[0184] [Method for Notifying PRACH Configuration] In the above embodiments, an example has been described in which SI is used as a method for notifying PRACH configuration. The SI used for notifying PRACH configuration may be, for example, System Information Block 1 (SIB1) or another SIB. Furthermore, the signal or information used for notifying PRACH configuration is not limited to SI. For example, other signals such as higher layer signals, Radio Resource Control (RRC) signals, Master Information Block (MIB), Media Access Control (MAC), and Downlink Control Information (DCI) may also be used.

[0185] For example, in the second embodiment, information regarding a plurality of PRACH configurations and information regarding the relationship between each PRACH configuration and a terminal type may be notified to terminal 200 by the same signal, or may be notified separately by different signals. For example, information regarding a plurality of PRACH configurations may be notified to terminal 200 by SI, and information regarding the relationship between each PRACH configuration and a terminal type may be notified to terminal 200 by DCI.

[0186] Furthermore, even when the base station 100 has notified the terminal 200 of access prohibition for the RedCap terminal by a signal such as an SIB, the base station 100 may notify the terminal 200 of the PRACH setting for RedCap. For example, even when the base station 100 has notified the terminal 200 of access prohibition for the RedCap terminal, the above-described eRedCap PR1-standalone terminal may transmit a preamble using the PRACH setting for RedCap.

[0187] [Terminal Type, Classification, and Identification] The above-described embodiment may be applied to, for example, an "eRedCap terminal (including, for example, the above-described eRedCap PR1-standalone terminal)," a "RedCap terminal," or a "non-RedCap terminal," and may also be applied in situations where terminals of other terminal types access a cell. For example, operations similar to those of the above-described embodiment may be applied in situations where a battery-less terminal or a terminal with an extremely small battery capacity (for example, an Ambient IoT terminal), which is expected to be standardized in Release 19 NR (hereinafter also referred to as Rel-19) or later, accesses a cell. In this case, the Ambient IoT terminal may transmit a preamble using, for example, a PRACH setting different from the PRACH setting used by non-RedCap terminals, RedCap terminals, and eRedCap terminals, or may transmit a preamble using the same PRACH setting as any of the terminal types.

[0188] In the above embodiment, the case where the maximum frequency allocation size supported (e.g., frequency bandwidth or the number of PRBs usable for PDSCH or PUSCH transmission) is equal to or less than a threshold has been described as an example of a feature (e.g., characteristic, attribute, or capability) of a RedCap terminal and an eRedCap terminal. However, the RedCap terminal and the eRedCap terminal may be terminals having at least one of the following features, for example: (1) A terminal that notifies (e.g., reports) the base station 100 that it is a "RedCap terminal," an "eRedCap terminal," a "terminal that is the target of coverage extension," or a "terminal that receives repeatedly transmitted signals." Note that, for example, an uplink channel such as PRACH and PUSCH, or an uplink signal such as a Sounding Reference Signal (SRS), may be used for the above notification (report). (2) A terminal that corresponds to at least one of the following characteristics and capabilities, or a terminal that reports at least one of the following capabilities to the base station 100: Note that the report may use uplink channels such as PRACH and PUSCH, or uplink signals such as UCI or SRS. - A terminal whose transmittable / receiveable frequency bandwidth (e.g., maximum value) is equal to or less than a threshold (e.g., 20 MHz or 5 MHz or less). - A terminal whose transmittable / receiveable number of PRBs (e.g., maximum number) is equal to or less than a threshold (e.g., 106 or less, 51 or less, 25 or less, or 11 or less). - A terminal whose implemented number of receive antennas is equal to or less than a threshold (e.g., threshold = 1). - A terminal whose supportable number of downlink ports (e.g., number of receive antenna ports) is equal to or less than a threshold (e.g., threshold = 2). - A terminal whose supportable number of transmission ranks (e.g., maximum number of Multiple-Input Multiple-Output (MIMO) layers (or rank number)) is equal to or less than a threshold (e.g., threshold = 2). - A terminal capable of transmitting and receiving signals in a frequency band equal to or less than a threshold (e.g., Frequency Range 1 (FR1) or a band equal to or less than 6 GHz). - A terminal whose processing time is equal to or more than a threshold. A terminal whose available transport block size (TBS) is equal to or less than a threshold. A terminal whose available transmission rank number (for example, the number of MIMO transmission layers) is equal to or less than a threshold.- A terminal whose available modulation order is equal to or less than a threshold. - A terminal whose available number of Hybrid Automatic Repeat reQuest (HARQ) processes is equal to or less than a threshold. - A terminal that supports Rel-17 or later if it is a RedCap terminal, and a terminal that supports Rel-18 or later if it is an eRedCap terminal. (3) A terminal to which parameters corresponding to a RedCap terminal or an eRedCap terminal are notified from the base station 100. Note that the parameters corresponding to a RedCap terminal or an eRedCap terminal may include, for example, a parameter such as a Subscriber Profile ID for RAT / Frequency Priority (SPID).

[0189] In addition, "non-eRedCap terminal" or "non-eRedCap terminal" may mean, for example, a terminal that supports Rel-15 / 16 / 17 (e.g., a terminal that does not support Rel-18), or a terminal that supports Rel-18 or later but does not have the above features.

[0190] (Supplementary Note) Information indicating whether the terminal 200 supports the functions, operations, or processes described in the above-described embodiments may be transmitted (or notified) from the terminal 200 to the base station 100, for example, as capability information or capability parameters of the terminal 200.

[0191] The capability information may include an information element (IE) that individually indicates whether or not the terminal 200 supports at least one of the functions, operations, or processes described in the above-described embodiments. Alternatively, the capability information may include an information element that indicates whether or not the terminal 200 supports a combination of any two or more of the functions, operations, or processes described in the above-described embodiments, modifications, and supplements.

[0192] For example, the base station 100 may determine (or decide or assume) functions, operations, or processes that the terminal 200 that transmitted the capability information supports (or does not support) based on the capability information received from the terminal 200. The base station 100 may perform operations, processes, or control according to the determination result based on the capability information. For example, the base station 100 may control the PRACH configuration to be assigned to the terminal based on the capability information received from the terminal 200.

[0193] Note that the fact that terminal 200 does not support some of the functions, operations, or processes described in the above-described embodiments may be interpreted as meaning that such some of the functions, operations, or processes are restricted in terminal 200. For example, information or a request regarding such restrictions may be notified to base station 100.

[0194] Information regarding the capabilities or limitations of terminal 200 may, for example, be defined in a standard, or may be implicitly notified to base station 100 in association with information known at base station 100 or information transmitted to base station 100.

[0195] (Control Signal) In the present disclosure, a downlink control signal (or downlink control information) related to an embodiment of the present disclosure may be, for example, a signal (or information) transmitted in a Physical Downlink Control Channel (PDCCH) of a physical layer, or a signal (or information) transmitted in a Medium Access Control Control Element (MAC CE) or Radio Resource Control (RRC) of a higher layer. Furthermore, the signal (or information) is not limited to being notified by a downlink control signal, but may be predefined in a specification (or standard) or preconfigured in a base station and a terminal.

[0196] Furthermore, the PDCCH may be transmitted, for example, in either a Common Search Space (CSS) or a UE Specific Search Space (USS).

[0197] (Base Station) In an embodiment of the present disclosure, the base station may be a Transmission Reception Point (TRP), a cluster head, an access point, a Remote Radio Head (RRH), an eNodeB (eNB), a gNodeB (gNB), a Base Station (BS), a Base Transceiver Station (BTS), a parent device, a gateway, or the like. In sidelink communication, a terminal may play the role of a base station. Instead of a base station, a relay device that relays communication between an upper node and a terminal may be used. Alternatively, a roadside unit may be used.

[0198] (Uplink / Downlink / Sidelink) An embodiment of the present disclosure may be applied to, for example, any of the uplink, downlink, and sidelink. For example, an embodiment of the present disclosure may be applied to a Physical Uplink Shared Channel (PUSCH), a Physical Uplink Control Channel (PUCCH), or a Physical Random Access Channel (PRACH) in the uplink, a Physical Downlink Shared Channel (PDSCH), a PDCCH, or a Physical Broadcast Channel (PBCH) in the downlink, or a Physical Sidelink Shared Channel (PSSCH), a Physical Sidelink Control Channel (PSCCH), or a Physical Sidelink Broadcast Channel (PSBCH) in the sidelink.

[0199] For example, in the above embodiment, the configuration of the PRACH, which is an uplink, has been described as an example, but an embodiment of the present disclosure can also be applied to notification of the configuration of other uplinks (e.g., PUSCH or PUCCH). For example, the PRACH in the above embodiment may be a PUSCH or a PUCCH. Alternatively, an embodiment of the present disclosure can also be applied to notification of the configuration of a downlink (e.g., a PDCCH, a PDSCH, or a PBCH). For example, the PRACH in the above embodiment may be a PDCCH, a PDSCH, or a PBCH.

[0200] The PDCCH, PDSCH, PUSCH, and PUCCH are examples of a downlink control channel, a downlink data channel, an uplink data channel, and an uplink control channel, respectively. The PSCCH and PSSCH are examples of a sidelink control channel and a sidelink data channel. The PBCH and PSBCH are examples of a broadcast channel, and the PRACH is an example of a random access channel.

[0201] (Data Channel / Control Channel) An embodiment of the present disclosure may be applied to, for example, either a data channel or a control channel. For example, the channel in an embodiment of the present disclosure may be replaced with any of the data channels PDSCH, PUSCH, and PSSCH, or the control channels PDCCH, PUCCH, PBCH, PSCCH, and PSBCH.

[0202] (Reference Signal) In one embodiment of the present disclosure, the reference signal is, for example, a signal known by both the base station and the terminal, and may also be called a Reference Signal (RS) or a pilot signal. The reference signal may be any of a Demodulation Reference Signal (DMRS), a Channel State Information - Reference Signal (CSI-RS), a Tracking Reference Signal (TRS), a Phase Tracking Reference Signal (PTRS), a Cell-specific Reference Signal (CRS), or a Sounding Reference Signal (SRS). For example, the PRACH in the above embodiment may be any of the above reference signals.

[0203] (Time Interval) In one embodiment of the present disclosure, the unit of time resource is not limited to one or a combination of slots and symbols, but may be, for example, a time resource unit such as a frame, a superframe, a subframe, a slot, a time slot, a subslot, a minislot, a symbol, an Orthogonal Frequency Division Multiplexing (OFDM) symbol, a Single Carrier-Frequency Division Multiplexing Access (SC-FDMA) symbol, or another time resource unit. Furthermore, the number of symbols included in one slot is not limited to the number of symbols exemplified in the above-mentioned embodiment, and may be another number of symbols.

[0204] (Frequency Band) An embodiment of the present disclosure may be applied to both licensed and unlicensed bands (unlicensed spectrum, shared spectrum). In the case of unlicensed bands, a channel access procedure (Listen Before Talk (LBT), carrier sense, Channel Clear Assessment (CCA)) may be performed before each signal transmission.

[0205] (Communication) An embodiment of the present disclosure may be applied to any of communication between a base station and a terminal (Uu link communication), communication between terminals (Sidelink communication), and Vehicle to Everything (V2X) communication. For example, the PDCCH in an embodiment of the present disclosure may be replaced with a PSCCH, the PUSCH / PDSCH with a PSSCH, the PUCCH with a Physical Sidelink Feedback Channel (PSFCH), and the PBCH with a PSBCH. Furthermore, the PRACH in the above embodiment may be replaced with a PSCCH, a PSSCH, or a PSFCH.

[0206] An embodiment of the present disclosure may be applied to a terrestrial network, a non-terrestrial network (NTN) using a satellite or a high altitude pseudo satellite (HAPS), or a terrestrial network in which transmission delay is large compared to the symbol length or slot length, such as a network with a large cell size or an ultra-wideband transmission network.

[0207] (Full Duplex and SBFD Symbols) An embodiment of the present disclosure may be applied to symbols (e.g., SBFD symbols) for which subband non-overlapping full duplex (SBFD) operation or control is performed. In SBFD symbols, a frequency resource (or a frequency band) is divided into multiple bands (e.g., subbands, RB sets, subbands, or sub-BWPs (Bandwidth Parts)), and transmission in different directions (e.g., downlink or uplink) is supported for each subband. In SBFD symbols, a terminal may transmit and receive only on either the uplink or downlink, and not on the other. On the other hand, in SBFD symbols, a base station can transmit and receive on both the uplink and downlink simultaneously. In SBFD symbols, fewer frequency resources may be available for the downlink than in symbols for transmitting and receiving only on the downlink. In addition, in SBFD symbols, fewer frequency resources may be available for the uplink than in symbols for transmitting and receiving only on the uplink.

[0208] In addition, in the SBFD symbol, the terminal may transmit and receive uplink and downlink simultaneously. In this case, the frequency resource from which the terminal transmits and the frequency resource from which the terminal receives may not be adjacent, but may be spaced apart by a frequency interval (also called a frequency gap).

[0209] In addition, a sidelink may be included as a different direction per subband in SBFD.

[0210] An embodiment of the present disclosure may be applied to a symbol (e.g., a full duplex symbol) in which full duplex operation or control is performed. In a full duplex symbol, both a terminal and a base station can simultaneously transmit and receive data on the uplink and downlink. However, for example, for the purpose of reducing interference, only one of the terminal and the base station may support simultaneous transmission and reception (i.e., the other may support operation of only transmitting or receiving data). In a full duplex symbol, the terminal and the base station may simultaneously transmit and receive data on all available frequency resources (or frequency bands), or may simultaneously transmit and receive data on only some frequency resources (or frequency bands) (i.e., operation of only transmitting or receiving data on other frequency resources).

[0211] (Antenna Port) In one embodiment of the present disclosure, an antenna port refers to a logical antenna (antenna group) consisting of one or more physical antennas. For example, an antenna port does not necessarily refer to a single physical antenna, but may refer to an array antenna consisting of multiple antennas. For example, the number of physical antennas that an antenna port is composed of is not specified, and the antenna port may be specified as the smallest unit by which a terminal station can transmit a reference signal. Furthermore, an antenna port may also be specified as the smallest unit by which a weighting of a precoding vector is multiplied.

[0212] 5G NR System Architecture and Protocol Stack 3GPP continues work on the next release of fifth-generation cellular technology (also referred to simply as "5G"), which includes the development of new radio access technology (NR) operating in the frequency range up to 100 GHz. The first version of the 5G standard was completed at the end of 2017, allowing for the prototyping and commercial deployment of 5G NR-compliant devices (e.g., smartphones).

[0213] For example, the system architecture generally assumes a Next Generation - Radio Access Network (NG-RAN) including gNBs. The gNBs provide UE-side termination of the NG radio access user plane (SDAP / PDCP / RLC / MAC / PHY) and control plane (RRC) protocols. The gNBs are connected to each other via an Xn interface. The gNBs are also connected to a Next Generation Core (NGC) via a Next Generation (NG) interface, more specifically to an Access and Mobility Management Function (AMF) (e.g., a specific core entity performing AMF) via an NG-C interface, and to a User Plane Function (UPF) (e.g., a specific core entity performing UPF) via an NG-U interface. The NG-RAN architecture is shown in Figure 17 (see, for example, 3GPP TS 38.300 v15.6.0, section 4).

[0214] The NR user plane protocol stack (see, for example, 3GPP TS 38.300, section 4.4.1) includes a PDCP (Packet Data Convergence Protocol (see, for example, TS 38.300, section 6.4)) sublayer, a RLC (Radio Link Control (see, for example, TS 38.300, section 6.3)) sublayer, and a MAC (Medium Access Control (see, for example, TS 38.300, section 6.2)) sublayer, which are terminated on the network side in the gNB. A new access stratum (AS) sublayer (SDAP: Service Data Adaptation Protocol) has also been introduced above PDCP (see, for example, 3GPP TS 38.300, section 6.5). A control plane protocol stack has also been defined for the NR (see, for example, TS 38.300, section 4.4.2). An overview of Layer 2 functions is described in Section 6 of TS 38.300. The functions of the PDCP sublayer, RLC sublayer, and MAC sublayer are listed in clauses 6.4, 6.3, and 6.2 of TS 38.300, respectively. The functions of the RRC layer are listed in clause 7 of TS 38.300.

[0215] For example, the Medium-Access-Control layer handles logical channel multiplexing and scheduling and scheduling-related functions, including handling various numerologies.

[0216] For example, the physical layer (PHY) is responsible for coding, PHY HARQ processing, modulation, multi-antenna processing, and mapping of signals to appropriate physical time-frequency resources. The physical layer also handles mapping of transport channels to physical channels. The physical layer provides services to the MAC layer in the form of transport channels. A physical channel corresponds to a set of time-frequency resources used for transmitting a specific transport channel, and each transport channel is mapped to a corresponding physical channel. For example, physical channels include the Physical Random Access Channel (PRACH), the Physical Uplink Shared Channel (PUSCH), and the Physical Uplink Control Channel (PUCCH) as uplink physical channels, and the Physical Downlink Shared Channel (PDSCH), the Physical Downlink Control Channel (PDCCH), and the Physical Broadcast Channel (PBCH) as downlink physical channels.

[0217] NR use cases / deployment scenarios may include enhanced mobile broadband (eMBB), ultra-reliable low-latency communications (URLLC), and massive machine-type communication (mMTC), which have diverse requirements in terms of data rate, latency, and coverage. For example, eMBB is expected to support peak data rates (20 Gbps in the downlink and 10 Gbps in the uplink) and effective (user-experienced) data rates approximately three times higher than those offered by IMT-Advanced. On the other hand, URLLC imposes stricter requirements on ultra-low latency (0.5 ms for user plane latency in both UL and DL) and high reliability (1-10-5 within 1 ms). Finally, mMTC preferably requires high connection density (1,000,000 devices / km in urban environments).２ ), wide coverage in adverse environments, and extremely long battery life (15 years) for a low-cost device may be desired.

[0218] Therefore, OFDM numerology (e.g., subcarrier spacing, OFDM symbol length, cyclic prefix (CP) length, number of symbols per scheduling interval) suitable for one use case may not be valid for another use case. For example, low-latency services may preferably require a shorter symbol length (and therefore a larger subcarrier spacing) and / or fewer symbols per scheduling interval (also referred to as TTI) than mMTC services. Furthermore, deployment scenarios with large channel delay spreads may preferably require a longer CP length than scenarios with short delay spreads. The subcarrier spacing may be optimized accordingly to maintain similar CP overhead. NR may support one or more subcarrier spacing values. Correspondingly, subcarrier spacings of 15 kHz, 30 kHz, 60 kHz, etc. are currently considered. The symbol length Tu and subcarrier spacing Δf are directly related by the formula Δf = 1 / Tu. Similar to LTE systems, the term "resource element" can be used to mean the smallest resource unit consisting of one subcarrier for the length of one OFDM / SC-FDMA symbol.

[0219] In the new radio system 5G-NR, for each numerology and each carrier, a resource grid of subcarriers and OFDM symbols is defined for each uplink and downlink. Each element of the resource grid is called a resource element and is specified based on a frequency index in the frequency domain and a symbol position in the time domain (see 3GPP TS 38.211 v15.6.0).

[0220] <Functional Separation Between NG-RAN and 5GC in 5G NR> Figure 18 shows the functional separation between NG-RAN and 5GC. The logical node of NG-RAN is gNB or ng-eNB. 5GC has logical nodes AMF, UPF, and SMF.

[0221] For example, gNB and ng-eNB host the following main functions: - Radio Resource Management functions such as Radio Bearer Control, Radio Admission Control, Connection Mobility Control, dynamic allocation (scheduling) of resources to UEs in both uplink and downlink; - IP header compression, ciphering and integrity protection of data; - AMF selection at UE attach time if routing to the AMF cannot be determined from the information provided by the UE; - Routing of user plane data towards the UPF; - Routing of control plane information towards the AMF; - Connection setup and release; - Scheduling and transmission of paging messages; - Scheduling and transmission of system broadcast information (sourced from the AMF or Operation, Admission, Maintenance (OAM)); - Configuration of measurements and measurement reports for mobility and scheduling; - Transport level packet marking in the uplink; - Session management; Support for network slicing; - QoS flow management and mapping to data radio bearers; - Support for UEs in RRC_INACTIVE state; - NAS message delivery function; - Radio access network sharing; - Dual connectivity; - Close coordination between NR and E-UTRA.

[0222] The Access and Mobility Management Function (AMF) hosts the following main functions: - Termination of Non-Access Stratum (NAS) signaling; - Security of NAS signaling; - Security control of Access Stratum (AS); - Signaling between Core Network (CN) nodes for mobility between 3GPP access networks; - Reachability to idle mode UEs (including control and execution of paging retransmissions); - Registration area management; - Support for intra-system and inter-system mobility; - Access authentication; - Access authorization including checking of roaming rights; - Mobility management control (subscription and policy); - Support for network slicing; - Selection of Session Management Function (SMF).

[0223] Furthermore, the User Plane Function (UPF) hosts the following main functions: - anchor point for intra-RAT / inter-RAT mobility (if applicable); - external PDU (Protocol Data Unit) session point for interconnection with data networks; - packet routing and forwarding; - packet inspection and policy rule enforcement for the user plane part; - traffic usage reporting; - uplink classifier to support routing of traffic flows to the data network; - branching point to support multi-homed PDU sessions; - QoS processing for the user plane (e.g. packet filtering, gating, UL / DL rate enforcement); - uplink traffic validation (mapping of SDF to QoS flows); - downlink packet buffering and triggering of downlink data notifications.

[0224] Finally, the Session Management Function (SMF) hosts the following main functions: session management; allocation and management of IP addresses for UEs; selection and control of UPF; configuration of traffic steering in the User Plane Function (UPF) to route traffic to the appropriate destination; policy enforcement and QoS of the control part; downlink data notification.

[0225] <RRC connection setup and reconfiguration procedure> Figure 19 shows some of the interactions between the UE, gNB, and AMF (5GC entities) when the UE transitions from RRC_IDLE to RRC_CONNECTED in the NAS part (see TS 38.300 v15.6.0).

[0226] RRC is a higher layer signaling (protocol) used to configure the UE and gNB. With this transition, the AMF prepares UE context data (including, for example, PDU session context, security keys, UE radio capabilities, UE security capabilities, etc.) and sends it to the gNB along with an INITIAL CONTEXT SETUP REQUEST. The gNB then activates AS security together with the UE. This is done by the gNB sending a SecurityModeCommand message to the UE, and the UE responding with a SecurityModeComplete message to the gNB. The gNB then sends an RRCReconfiguration message to the UE, and upon receiving an RRCReconfigurationComplete from the UE, the gNB performs reconfiguration to set up Signaling Radio Bearer 2 (SRB2) and Data Radio Bearer (DRB). For signaling-only connections, the steps related to RRCReconfiguration are omitted because SRB2 and DRB are not set up. Finally, the gNB notifies the AMF that the setup procedure is complete with an INITIAL CONTEXT SETUP RESPONSE.

[0227] Accordingly, the present disclosure provides a 5th Generation Core (5GC) entity (e.g., AMF, SMF, etc.) that includes: a control circuit that, upon operation, establishes a Next Generation (NG) connection with a gNodeB; and a transmitter that, upon operation, transmits an initial context setup message to the gNodeB via the NG connection so that a signaling radio bearer between the gNodeB and a user equipment (UE) is set up. Specifically, the gNodeB transmits Radio Resource Control (RRC) signaling, including a resource allocation configuration information element (IE), to the UE via the signaling radio bearer. The UE then transmits in uplink or receives in downlink based on the resource allocation configuration.

[0228] <IMT Usage Scenarios Beyond 2020> Figure 20 shows some use cases for 5G NR. The 3rd Generation Partnership Project New Radio (3GPP NR) is considering three use cases envisioned by IMT-2020 to support a wide variety of services and applications. The first phase of specifications for enhanced mobile broadband (eMBB) has been completed. Current and future work includes standardization for ultra-reliable and low-latency communications (URLLC) and massive machine-type communications (mMTC), in addition to expanding support for eMBB. Figure 20 shows some examples of envisioned usage scenarios for IMT beyond 2020 (see, for example, ITU-R M.2083 Figure 2).

[0229] The URLLC use case has stringent performance requirements for throughput, latency, and availability. It is envisioned as one of the enabling technologies for future applications such as wireless control of industrial production or manufacturing processes, remote medical surgery, automated power transmission and distribution in smart grids, and road safety. URLLC's ultra-high reliability is supported by identifying technologies that meet the requirements set by TR 38.913. Key requirements for NR URLLC in Release 15 include a target user plane latency of 0.5 ms on the uplink (UL) and 0.5 ms on the downlink (DL). The overall URLLC requirement for a single packet transmission is a block error rate (BLER) of 1E-5 for a 32-byte packet size with a user plane latency of 1 ms.

[0230] From a physical layer perspective, reliability can be improved in many possible ways. Current room for reliability improvement includes defining a separate CQI table for URLLC, more compact DCI formats, PDCCH repetition, etc. However, this room can be expanded to achieve ultra-high reliability as NR (with respect to the key requirements of NR URLLC) becomes more stable and developed. Specific use cases for NR URLLC in Release 15 include Augmented Reality / Virtual Reality (AR / VR), e-health, e-safety, and mission-critical applications.

[0231] Additionally, the technology enhancements targeted by NR URLLC aim to improve latency and reliability. Technology enhancements for latency improvement include configurable numerology, non-slot-based scheduling with flexible mapping, grant-free (configured grant) uplink, slot-level repetition in the data channel, and preemption in the downlink. Preemption means that a transmission with already allocated resources is stopped and the already allocated resources are used for another transmission with a later requested lower latency / higher priority. Therefore, a previously allowed transmission is preempted by a later transmission. Preemption is applicable regardless of the specific service type. For example, a transmission of service type A (URLLC) may be preempted by a transmission of service type B (eMBB, etc.). Technology enhancements for reliability improvement include a dedicated CQI / MCS table for a target BLER of 1E-5.

[0232] The use case of mMTC (massive machine type communication) is characterized by a very large number of connected devices that typically transmit relatively small amounts of data that are not sensitive to delays. These devices are required to be low-cost and have very long battery life. From the NR perspective, utilizing very narrow bandwidth portions is one solution that saves power and extends battery life from the UE's perspective.

[0233] As mentioned above, the scope of reliability improvement in NR is expected to be broader. One of the key requirements for all cases, for example, URLLC and mMTC, is high or ultra-high reliability. Several mechanisms can improve reliability from a radio perspective and a network perspective. Generally, there are two to three key areas that can help improve reliability. These areas include compact control channel information, repetition of data channels / control channels, and diversity in the frequency, time, and / or spatial domains. These areas are generally applicable to reliability improvement regardless of the specific communication scenario.

[0234] For NR URLLC, further use cases with more stringent requirements are envisaged, such as factory automation, transportation, and power distribution, with high reliability (up to 10-6 level reliability), high availability, packet size up to 256 bytes, time synchronization down to a few μs (depending on the use case, the value can be 1 μs or a few μs depending on the frequency range and low latency in the order of 0.5 ms to 1 ms (e.g., 0.5 ms latency on the targeted user plane)).

[0235] Furthermore, for NR URLLC, there may be several technical enhancements from the physical layer perspective. These technical enhancements include PDCCH (Physical Downlink Control Channel) enhancements for compact DCI, PDCCH repetition, and increased PDCCH monitoring. Also, UCI (Uplink Control Information) enhancements relate to enhanced Hybrid Automatic Repeat Request (HARQ) and CSI feedback enhancements. There may also be PUSCH enhancements related to minislot-level hopping and retransmission / repetition enhancements. The term "minislot" refers to a Transmission Time Interval (TTI) that contains fewer symbols than a slot (a slot comprises 14 symbols).

[0236] <QoS Control> The 5G Quality of Service (QoS) model is based on QoS flows and supports both QoS flows that require a guaranteed flow bit rate (Guaranteed Bit Rate QoS flows (GBR)) and QoS flows that do not require a guaranteed flow bit rate (non-GBR QoS flows). Thus, at the NAS level, a QoS flow is the finest granularity of QoS classification in a PDU session. A QoS flow is identified within a PDU session by a QoS Flow ID (QFI) carried in an encapsulation header over the NG-U interface.

[0237] For each UE, 5GC establishes one or more PDU sessions. For each UE, the NG-RAN establishes at least one Data Radio Bearer (DRB) for each PDU session, e.g., as shown above with reference to Figure 19. Additional DRBs for the QoS flows of that PDU session can be configured later (when this is up to the NG-RAN). The NG-RAN maps packets belonging to different PDU sessions to different DRBs. NAS-level packet filters in the UE and 5GC associate UL and DL packets with QoS flows, while AS-level mapping rules in the UE and NG-RAN associate UL and DL QoS flows with DRBs.

[0238] Figure 21 shows the non-roaming reference architecture for 5G NR (see TS 23.501 v16.1.0, section 4.23). An Application Function (AF) (e.g., an external application server hosting 5G services, as illustrated in Figure 20) interacts with the 3GPP core network to provide services. For example, it may access a Network Exposure Function (NEF) to support applications that affect traffic routing, or interact with a policy framework for policy control (e.g., QoS control) (see Policy Control Function (PCF)). Based on operator deployment, Application Functions considered trusted by the operator can interact directly with the associated Network Functions. Application Functions not permitted by the operator to directly access Network Functions interact with the associated Network Functions using an external exposure framework via the NEF.

[0239] Figure 21 further illustrates further functional units of the 5G architecture, namely, Network Slice Selection Function (NSSF), Network Repository Function (NRF), Unified Data Management (UDM), Authentication Server Function (AUSF), Access and Mobility Management Function (AMF), Session Management Function (SMF), and Data Network (DN, e.g., operator-provided services, Internet access, or third-party services). All or part of the core network functions and application services may be deployed and run in a cloud computing environment.

[0240] Therefore, the present disclosure provides an application server (e.g., an AF in a 5G architecture) comprising: a transmitter that, in operation, sends a request including QoS requirements for at least one of a URLLC service, an eMMB service, and an mMTC service to at least one of 5GC functions (e.g., an NEF, an AMF, an SMF, a PCF, an UPF, etc.) to establish a PDU session including a radio bearer between a gNodeB and a UE according to the QoS requirements; and a control circuit that, in operation, performs a service using the established PDU session.

[0241] Furthermore, the notation "... section" in the above-described embodiments may be replaced with other notations such as "... circuitry," "... device," "... unit," or "... module."

[0242] Furthermore, in the above-described embodiments, the values ​​of parameters such as the number of RBs, frequency bandwidth, and SCS are merely examples and other values ​​may be used.

[0243] The present disclosure can be realized by software, hardware, or software integrated with hardware. Each functional block described in the above embodiments may be partially or entirely realized as an LSI, which is an integrated circuit. Each process described in the above embodiments may be partially or entirely controlled by a single LSI or a combination of LSIs. The LSI may be composed of individual chips, or may be composed of a single chip that includes some or all of the functional blocks. The LSI may have data inputs and outputs. Depending on the level of integration, an LSI may be referred to as an IC, system LSI, super LSI, or ultra LSI. The integrated circuit implementation is not limited to LSIs, and may be realized using dedicated circuits, general-purpose processors, or dedicated processors. Furthermore, a field programmable gate array (FPGA), which can be programmed after LSI fabrication, or a reconfigurable processor, which allows the connections and settings of circuit cells within an LSI to be reconfigured, may also be used. The present disclosure may be realized as digital or analog processing. Furthermore, if an integrated circuit technology that can replace LSI emerges due to advances in semiconductor technology or other derivative technologies, it is natural that such technology may be used to integrate functional blocks. The application of biotechnology, etc. is also a possibility.

[0244] The present disclosure may be implemented in any type of apparatus, device, or system (collectively referred to as a communications apparatus) that has a communications function. The communications apparatus may include a radio transceiver and processing / control circuitry. The radio transceiver may include a receiver and a transmitter, or both functions. The radio transceiver (transmitter and receiver) may include a radio frequency (RF) module and one or more antennas. The RF module may include an amplifier, an RF modulator / demodulator, or the like. Non-limiting examples of communication devices include telephones (e.g., cell phones, smartphones), tablets, personal computers (PCs) (e.g., laptops, desktops, notebooks), cameras (e.g., digital still / video cameras), digital players (e.g., digital audio / video players), wearable devices (e.g., wearable cameras, smartwatches, tracking devices), game consoles, digital book readers, telehealth / telemedicine devices, communication-enabled vehicles or mobile transportation (e.g., cars, airplanes, ships), and combinations of the above devices.

[0245] The communication devices are not limited to portable or mobile devices, but also include any kind of non-portable or fixed equipment, devices, and systems, such as smart home devices (such as home appliances, lighting equipment, smart meters or measuring devices, control panels, etc.), vending machines, and any other "things" that may exist on an IoT (Internet of Things) network.

[0246] Communications include data communications via cellular systems, wireless LAN systems, communication satellite systems, and the like, as well as data communications via combinations of these.

[0247] A communications apparatus also includes devices such as controllers and sensors connected or coupled to a communications device that performs the communications functions described in this disclosure, such as controllers and sensors that generate control and data signals used by the communications device to perform the communications functions of the communications apparatus.

[0248] The communication apparatus also includes infrastructure facilities, such as base stations, access points, and any other apparatus, device, or system that communicates with or controls the various apparatuses listed above, but are not limited to these.

[0249] A terminal according to a non-limiting example of the present disclosure includes a receiving circuit that receives information regarding a setting of a second number of random access signals for a first number of types of terminals, the second number being smaller than the first number, and a transmitting circuit that transmits the random access signals based on the information.

[0250] In a non-limiting example of the present disclosure, the first number of types of terminals includes terminals of a first type, a second type, and a third type, and the second number of settings includes one of a first setting notified by first information identifiable by terminals of the first type, the second type, and the third type, a second setting notified by second information identifiable by terminals of the second type and the third type, and a third setting notified by third information identifiable by terminals of the third type.

[0251] In a non-limiting example of the present disclosure, the third type of terminal selects the second setting with priority over the first setting, and the third setting with priority over the second setting.

[0252] In a non-limiting example of the present disclosure, the second type of terminal selects the second setting in preference to the first setting.

[0253] In a non-limiting example of the present disclosure, the terminal is notified of either a combination of the first setting and the second setting or a combination of the first setting and the third setting depending on certain conditions.

[0254] In a non-limiting example of the present disclosure, the information includes information indicating the second number settings and information regarding the correspondence between each of the second number settings and the first number type.

[0255] A base station according to a non-limiting example of the present disclosure includes a transmitting circuit that transmits information regarding a setting of a second number of random access signals for a first number of types of terminals, the second number being smaller than the first number, and a receiving circuit that receives the random access signals based on the information.

[0256] In a communication method according to a non-limiting example of the present disclosure, a terminal receives information regarding a setting of a second number of random access signals for a first number of types of terminals, the second number being smaller than the first number, and transmits the random access signals based on the information.

[0257] In a communication method according to a non-limiting example of the present disclosure, a base station transmits information regarding a setting of a second number of random access signals to a first number of types of terminals, the second number being smaller than the first number, and receives the random access signals based on the information.

[0258] The disclosures of the specification, drawings and abstract contained in Japanese Patent Application No. 2023-019121, filed February 10, 2023, are incorporated herein by reference in their entirety.

[0259] One embodiment of the present disclosure is useful in wireless communication systems.

[0260] 100 Base station 101, 206 Control unit 102 DCI generation unit 103 Upper layer signal generation unit 104, 208 Coding and modulation unit 105, 209 Signal mapping unit 106, 210 Transmission unit 107, 201 Antenna 108, 202 Reception unit 109, 203 Signal separation unit 110, 205 Demodulation and decoding unit 200 Terminal 204 DCI detection unit 207 Preamble generation unit

Claims

1. A receiving circuit for receiving information regarding the setting of a random access signal; a transmitting circuit for transmitting the random access signal based on the information; The setting of the random access signal is a first setting that can be identified by a first type of terminal, a second type of terminal, and a third type of terminal; a second setting that can be specified by the second type and the third type of terminal, and a third setting that can be specified by the third type of terminal; Terminal.

2. The second type of terminal is a RedCap terminal, The third type of terminal is an eRedCap terminal, and the first type of terminal is a terminal other than the RedCap terminal and the eRedCap terminal. The terminal according to claim 1 .

3. the third type terminal selects the second setting with priority over the first setting and the third setting with priority over the second setting; The terminal according to claim 2.

4. The second type terminal selects the second setting with priority over the first setting. The terminal according to claim 2.

5. the terminal is notified of either a combination of the first setting and the second setting or a combination of the first setting and the third setting in accordance with a certain condition; The terminal according to claim 2.

6. The first type of terminal selects the first setting. The terminal according to claim 1 .

7. The second setting and the third setting are notified by a Radio Resource Control (RRC) signal. The terminal according to claim 1 .

8. A transmitting circuit for transmitting information regarding the setting of a random access signal; a receiving circuit for receiving the random access signal based on the information; The setting of the random access signal is a first setting that can be identified by a first type of terminal, a second type of terminal, and a third type of terminal; a second setting that can be specified by the second type and the third type of terminal, and a third setting that can be specified by the third type of terminal; Base station.

9. The terminal is receiving information regarding the configuration of a random access signal; transmitting the random access signal based on the information; The setting of the random access signal is a first setting that can be identified by a first type of terminal, a second type of terminal, and a third type of terminal; a second setting that can be specified by the second type and the third type of terminal, and a third setting that can be specified by the third type of terminal; Communication method.

10. The base station is Transmitting information about the configuration of the random access signal; receiving the random access signal based on the information; The setting of the random access signal is a first setting that can be identified by a first type of terminal, a second type of terminal, and a third type of terminal; a second setting that can be specified by the second type and the third type of terminal, and a third setting that can be specified by the third type of terminal; Communication method.

11. A receiving circuit for receiving information regarding the setting of a random access signal; a transmitting circuit that transmits the random access signal based on the information; Equipped with The setting of the random access signal is a first setting that can be identified by a first type of terminal, a second type of terminal, and a third type of terminal; a second setting that can be specified by the second type and the third type of terminal, and a third setting that can be specified by the third type of terminal; Integrated circuit.

12. A transmitting circuit for transmitting information regarding the setting of a random access signal; a receiving circuit for receiving the random access signal based on the information; Equipped with The setting of the random access signal is a first setting that can be identified by a first type of terminal, a second type of terminal, and a third type of terminal; a second setting that can be specified by the second type and the third type of terminal, and a third setting that can be specified by the third type of terminal; Integrated circuit.