Terminal, base station, and communication method

Abstract

The terminal of the present application is provided with: a reception circuit that receives downlink control information that contains information scrambled with a terminal-specific identifier and schedules an uplink signal independently of a terminal-specific configuration; and a transmission circuit that performs repeated transmission of the uplink signal based on repeated transmission-related information of the uplink signal determined in accordance with the downlink control information.

Description

Technical Field

[0001] This disclosure relates to terminals, base stations, and communication methods. Background Technology

[0002] In recent years, against the backdrop of the expansion and diversification of wireless services, the rapid development of the Internet of Things (IoT) is anticipated. The application of mobile communication is expanding beyond information terminals such as smartphones to all areas, including vehicles, homes, home appliances, and industrial equipment. To support this service diversification, in addition to increasing system capacity, significant improvements in the performance and functionality of mobile communication systems are required to meet various necessary conditions such as the increase in the number of connected devices and low latency. Fifth-generation mobile communication systems (5G) feature high capacity and ultra-high speed (eMBB), massive machine-type communication (mMTC), and ultra-reliable and low-latency communication (URLLC), providing flexible wireless communication to meet diverse needs.

[0003] The 3rd Generation Partnership Project (3GPP), an international standards organization, is developing specifications for New Radio (NR), one of the wireless interfaces for 5G.

[0004] Existing technical documents

[0005] Non-patent literature

[0006] Non-patent document 1: 3GPP TS38.104 V15.19.0, “NR Base Station (BS) radiotransmission and reception (Release 15),” June 2023.

[0007] Non-patent literature 2: RP-202928, “New WID on NR coverage enhancements,” ChinaTelecom, December 2020.

[0008] Non-patent literature 3: RP-220937, “Revised WID on Further NR coverage enhancements,” China Telecom, March 2022.

[0009] Non-patent document 4: 3GPP TS38.211 V17.6.0, “NR Physical channels and modulation (Release 17),” September 2023.

[0010] Non-patent document 5: 3GPP TS38.212 V17.6.0, “NR Multiplexing and channel coding (Release 17),” September 2023.

[0011] Non-patent literature 6: 3GPP TS38.213 V17.6.0, “NR Physical layer procedures for control (Release 17),” September 2023.

[0012] Non-patent literature 7: 3GPP TS38.214 V17.6.0, “NR Physical layer procedures for data (Release 17),” September 2023.

[0013] Non-patent literature 8: RP-232626, “Moderator's summary for REL-19 RAN1 additional topics,” RAN1 Chair, (Samsung), September 2023.

[0014] Non-patent document 9: 3GPP TS38.331 V17.6.0, “NR Radio Resource Control (RRC) protocol specification Release 17”, September 2023. Summary of the Invention

[0015] However, there is still room for research into the methods for transmitting signals in the uplink.

[0016] The non-limiting embodiments disclosed herein help to provide terminals, base stations, and communication methods capable of appropriately transmitting signals in the uplink.

[0017] A terminal according to an embodiment of this disclosure includes: a receiving circuit for receiving downlink control information, the downlink control information including information scrambled with a terminal-specific identifier and scheduling uplink signals independently of a terminal-specific configuration; and a transmitting circuit for repeatedly transmitting the uplink signals based on retransmission-related information of the uplink signals determined according to the downlink control information.

[0018] Furthermore, these broad or specific methods can be implemented by systems, devices, methods, integrated circuits, computer programs, or recording media, or by any combination of systems, devices, methods, integrated circuits, computer programs, and recording media.

[0019] According to one embodiment of this disclosure, signals can be appropriately transmitted in the uplink.

[0020] Further advantages and effects of one embodiment of this disclosure will be illustrated by the specification and drawings. These advantages and / or effects are provided by the various embodiments and the features described in the specification and drawings, but not necessarily all of them need to be provided in order to obtain one or more of the same features. Attached Figure Description

[0021] Figure 1 This is a block diagram representing a structural example of a part of a base station.

[0022] Figure 2 This is a block diagram representing a structural example of a part of a terminal.

[0023] Figure 3 This is a flowchart representing an example of a terminal action.

[0024] Figure 4 This is a diagram illustrating an example of downlink control information (DCI) used by a terminal for blind decoding.

[0025] Figure 5 This is a flowchart representing an example of a terminal action.

[0026] Figure 6 This is a diagram illustrating an example of DCI (Device Interchange Control) where the terminal performs blind decoding.

[0027] Figure 7 This is a diagram illustrating an example of the functionality applied to the Physical Uplink Shared Channel (PUSCH).

[0028] Figure 8 This is a block diagram representing a structural example of a base station.

[0029] Figure 9 This is a block diagram representing a structural example of a terminal.

[0030] Figure 10 This is a diagram illustrating the architecture of a 3GPP NR (3rd generation partnership project new radio) system.

[0031] Figure 11 This is a schematic diagram illustrating the functional separation between NG-RAN (Next Generation-Radio Access Network) and 5GC (5th Generation Core).

[0032] Figure 12 This is a timing diagram of the process of establishing / reconfiguring a Radio Resource Control (RRC) connection.

[0033] Figure 13 This is a schematic diagram illustrating the application scenarios of enhanced mobile broadband (eMBB), massive machine-type communications (mMTC), and ultra-reliable and low-latency communications (URLLC).

[0034] Figure 14 This is a block diagram illustrating an exemplary 5G system architecture for non-roaming scenarios. Detailed Implementation

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

[0036] In NR, for example, in addition to frequency bands below 6 GHz, such as the 700 MHz to 3.5 GHz band mainly used for cellular communication (e.g., also referred to as "Frequency Range 1" (FR1)), millimeter-wave frequency bands such as 28 GHz or 39 GHz bands that can ensure wide bandwidth may also be used (e.g., also referred to as "Frequency Range 2" (FR2)) (e.g., see Non-Patent Document 1). Furthermore, for example, it is possible to use frequency bands in FR1 that are higher than those used for Long Term Evolution (LTE) or 3G (3rd Generation mobile communication systems), such as the 3.5 GHz band.

[0037] The higher the frequency band, the greater the radio wave propagation loss, and the more easily the radio wave reception quality deteriorates. Therefore, in NR, for example, it is expected that when using frequency bands higher than LTE or 3G, the same level of communication area (or coverage) as Radio Access Technology (RAT) such as LTE or 3G will be ensured; in other words, appropriate communication quality will be ensured. For example, methods for improving coverage in NR were studied in 3GPP Release 17 (e.g., denoted as "Rel.17") and Release 18 (e.g., denoted as "Rel.18") (see, for example, Non-Patent Literature 2 and Non-Patent Literature 3).

[0038] In NR, a terminal (e.g., also referred to as "user equipment" (UE)) transmits and receives data (e.g., see Non-Patent Documents 4-7) according to resource allocation indicated by Layer 1 control signals (e.g., DCI: Downlink Control Information) or Layer 3 Radio Resource Control (RRC) on a downlink control channel (e.g., Physical Downlink Control Channel) from a base station (e.g., also referred to as "gNB").

[0039] In NR, repetition can be applied as one of the uplink (UL) coverage extension techniques (e.g., see Non-Patent Document 6 or 7). In NR up to version 18, the channels for which repetition can be applied are: uplink data channels scheduled by DCI format 0-1 or DCI format 0-2 (e.g., PUSCH: Physical Uplink Shared Channel) (e.g., PUSCH scheduled after configuring parameters via the pusch-Config information element (IE) as a terminal-specific RRC), Msg.3 PUSCH (e.g., PUSCH scheduled by Random Access Response (RAR)), uplink control channels (e.g., PUCCH: Physical Uplink Control Channel), and random access channels (e.g., PRACH: Physical Random Access Channel).

[0040] In NR, the application of repetition is not supported for PUSCH scheduled in DCI format 0-0, which is one of the DCI formats that scrambles the CRC check bits as an additional useful cell radio network temporary identifier (C-RNTI) (e.g., an example of a UE-specific identifier).

[0041] For example, the terminal sends Msg.3 PUSCH, and then, before the terminal-specific PUSCH configuration (e.g., Dedicated PUSCH configuration) is completed, the PUSCH may be scheduled by DCI format 0-0 with an additional useful C-RNTI scrambled CRC.

[0042] Here, the following PUSCH is sometimes referred to as "Msg.5 PUSCH", which is a DCI format 0-0 scheduled PUSCH with CRC scrambled with useful C-RNTI attached after the terminal sends Msg.3 PUSCH and before the terminal-specific PUSCH configuration is completed.

[0043] For example, Msg.5 PUSCH could be a PUSCH containing a message from the terminal to the base station that it has completed applying the configuration contained in RRC Setup (e.g., RRCSetupComplete) after receiving a message containing the configuration of the terminal (e.g., RRC Setup).

[0044] For example, the payload size of a PUSCH containing RRCSetupComplete may be larger than that of a Msg.3 PUSCH. In this case, PUSCHs without repetition applied (such as DCI format 0-0 scheduled PUSCHs with CRC scrambled with additional useful C-RNTI) may become a coverage bottleneck during initial access.

[0045] Therefore, the application of repetition to PUSCHs scheduled in DCI format 0-0 with CRC scrambled with additional useful C-RNTI is being investigated (e.g., see Non-Patent Document 8). However, there is still room for research into control methods for terminals to transmit PUSCHs (e.g., repetition transmission) in a manner that is a PUSCH scheduled in DCI format 0-0 with CRC scrambled with additional useful C-RNTI.

[0046] For example, as described above, a PUSCH scheduled in DCI format 0-0 with a CRC scrambled with a useful C-RNTI might be used to send Msg.5 PUSCH (e.g., a PUSCH containing RRCSetupComplete). Therefore, control over the transmission of Msg.5 PUSCH (e.g., a PUSCH containing RRCSetupComplete) is desirable. For example, in the transmission of Msg.5 PUSCH, it is envisioned that there might be a case where a terminal-specific RRC configuration (e.g., a dedicated RRC configuration) is available and a case where a terminal-specific RRC configuration is unavailable. Therefore, it is desirable that even when a terminal-specific RRC configuration is unavailable, the terminal can still receive and transmit a PUSCH in DCI format 0-0 with a CRC scrambled with a useful C-RNTI.

[0047] In NR, when the Type 3-PDCCH Common Search Space (CSS) set (e.g., configured as SearchSpaceType = common in the terminal-specific PDCCH-Config) and the UE-specific Search Space (USS) set are not assigned to the terminal, i.e., when the terminal-specific PDCCH receive configuration is unavailable in the terminal, the terminal monitors (or blindly decodes) PDCCH candidates in the Type 1-PDCCH CSS set for DCI format 0-0 with CRC scrambled with useful C-RNTI. Therefore, it is expected that repetition will be applied to PUSCHs scheduled by a DCI that is a DCI obtained by monitoring and decoding PDCCH candidates in the Type 1-PDCCH CSS set (e.g., DCI format 0-0 with CRC scrambled with useful C-RNTI).

[0048] Furthermore, the DCI format 0-0 of the CRC with added useful C-RNTI scrambling does not have the function of notifying information related to the repetition of PUSCH (e.g., the number of repetitions). Therefore, there is still room for research on methods for notifying information related to the repetition of PUSCH scheduled by the DCI format 0-0 of the CRC with added useful C-RNTI scrambling.

[0049] One non-limiting embodiment of this disclosure will illustrate a method for efficiently applying the Repetition function in consideration of the transmission of Msg.5 PUSCH (e.g., PUSCH containing RRCSetupComplete) for PUSCH scheduled in DCI format 0-0 with CRC scrambled by an additional useful C-RNTI.

[0050] The following describes non-limiting embodiments of this disclosure.

[0051] [Overview of Communication Systems]

[0052] The communication systems of various embodiments of this disclosure include, for example, at least one base station and at least one terminal.

[0053] Figure 1 This is a block diagram illustrating a structural example of a base station 100 according to an embodiment of the present disclosure. Figure 2 This is a block diagram illustrating a structural example of a terminal 200 according to an embodiment of the present disclosure.

[0054] exist Figure 1In the base station 100 shown, a transmitting unit (e.g., corresponding to a transmitting circuit) transmits downlink control information (e.g., DCI format 0-0), which includes information scrambled with a terminal-specific identifier (e.g., C-RNTI) (e.g., CRC) and schedules uplink signals independently of a terminal-specific configuration (e.g., dedicated RRC configuration). A receiving unit (e.g., corresponding to a receiving circuit) receives retransmissions of the uplink signals based on retransmission-related information (e.g., repetition-related information) determined according to the downlink control information.

[0055] exist Figure 2 In the terminal 200 shown, the receiving unit (e.g., corresponding to the receiving circuit) receives downlink control information (e.g., DCI format 0-0), which includes information scrambled with a terminal-specific identifier (e.g., C-RNTI) (e.g., CRC) and schedules uplink signals independently of terminal-specific configuration (e.g., dedicated RRC configuration). The transmitting unit (e.g., corresponding to the transmitting circuit) performs uplink signal repetition based on uplink signal repetition-related information (e.g., repetition-related information) determined according to the downlink control information.

[0056] (Implementation Method 1)

[0057] In this embodiment, it is envisioned that application repetition is applied for the transmission of PUSCH such as: Msg.5 PUSCH, PUSCH containing RRCSetupComplete, or PUSCH scheduled by DCI format 0-0 with CRC scrambled with useful C-RNTI after the terminal 200 transmits Msg.3 PUSCH and before the terminal-specific PUSCH configuration (e.g., Dedicated PUSCH configuration) is completed.

[0058] Furthermore, in this embodiment, the above-mentioned PUSCH is collectively referred to as "Msg.5 PUSCH".

[0059] For example, by attaching a partial information field of the DCI format 0-0 with useful C-RNTI scrambling to the CRC (e.g., by reusing the partial information field), information related to PUSCH repetition (e.g., the number of repetitions) is notified to the terminal 200 that requested Msg.5 PUSCH repetition, the terminal 200 that has notified the base station of its Msg.5 PUSCH repetition capability, or the terminal 200 that has Msg.5 PUSCH repetition capability.

[0060] For example, the following information fields of the DCI format 0-0 of the CRC with added useful C-RNTI scrambling can be reused to notify information related to PUSCH repetition.

[0061] [Option 1: Modulation and Coding Scheme (MCS) field]

[0062] For example, the most significant bit (MSB) of the 5 bits in the MCS field can be used to indicate information related to PUSCH repetition. Alternatively, the least significant bit (LSB) of the 5 bits in the MCS field (bits 5-X) can be used to indicate the MCS index.

[0063] At this point, the candidate values ​​for PUSCH repetition information and the MCS index, which can be notified via the MCS field, are 2 respectively. X 2 5-X These values ​​can be predefined in the standard or configured to terminal 200 via SIB (System Information Block) or RRC.

[0064] Additionally, for example, it is possible to define or configure via SIB or RRC to include MCS indexes and PUSCH repetition information in each column, up to a maximum of 2. 5 A table of rows. For example, MCS can be notified of index and PUSCH repetition related information by notifying the identifiers (e.g., indexes) corresponding to each row of the table.

[0065] [Option 2: Time Domain Resource Allocation (TDRA) field]

[0066] For example, X bits of the MSB out of the 4 bits in the TDRA field can be used to inform about information regarding PUSCH repetitions (e.g., the number of repetitions). Alternatively, 4-X bits of the LSB out of the 4 bits in the TDRA field can be used to inform about the TDRA index.

[0067] At this point, the candidate values ​​for the PUSCH repetition information and the TDRA index, which can be notified via the TDRA field, are 2 each. X 2 4-X These values ​​can be predefined in the standard or configured for terminal 200 via SIB or RRC.

[0068] Additionally, for example, it is possible to define or configure via SIB or RRC to include TDRA-related parameters (e.g., slot index, number of symbols, etc.) and PUSCH repetition-related information in each column, up to a maximum of 2. 4 A table of rows. For example, you can notify TDRA parameters and PUSCH repetition information by notifying the indexes corresponding to each row of this table.

[0069] [Option 3: Transmit Power Control (TPC) field]

[0070] Information about PUSCH repetitions (e.g., the number of repetitions) can be communicated using the MSB of the 2 bits of the TPC field (e.g., also known as the TPC command for scheduled PUSCH field). Alternatively, the LSB of the 2 bits of the TPC field can be used to communicate the TPC command.

[0071] At this point, the candidate values ​​for the PUSCH repetition information and the TPC command, which can be notified via the TPC field, are 2 respectively. X 2 2-X These values ​​can be predefined in the standard or configured for terminal 200 via SIB or RRC.

[0072] Additionally, for example, it is possible to define or configure via SIB or RRC to include up to 2 columns containing TPC commands and PUSCH repetition related information. 2 A table of rows. For example, TPC commands and PUSCH repetition information can be communicated by notifying the indexes corresponding to each row of this table.

[0073] [Option 4: Frequency Domain Resource Allocation (FDRA) field]

[0074] Information about PUSCH repetitions (e.g., the number of repetitions) can be notified using the MSB of the Y bits in the FDRA field. Alternatively, the LSB of the Y bits in the FDRA field can be used to notify of frequency domain resources.

[0075] At this point, the number of candidates for PUSCH repetition-related information that can be notified via the FDRA field is 2. X It can be predefined in the standard or configured to terminal 200 via SIB or RRC.

[0076] Additionally, the number of bits Y in the FDRA field can be, for example:

[0077] [Formula 1]

[0078]

[0079] in,

[0080] [Equation 2]

[0081]

[0082] It can be the number of resource blocks (RB) in the initial UL BWP (bandwidth portion) or the number of resource blocks in the active BWP.

[0083] [Option 5: Redundancy Version (RV) field]

[0084] Information about PUSCH repetitions (e.g., the number of repetitions) can be communicated using the MSB of the 2 bits in the RV field. Alternatively, the LSB of the 2 bits in the RV field (2-X bits) can be used to communicate about the RV index.

[0085] At this point, the candidate values ​​for the PUSCH repetition information and the RV index, which can be notified via the RV field, are 2 respectively. X 2 2-X These values ​​can be predefined in the standard or configured for terminal 200 via SIB or RRC.

[0086] Additionally, for example, it is possible to define or configure via SIB or RRC to include RV index and PUSCHrepetition related information in each column, up to a maximum of 2. 2 A table with rows. For example, you can notify the RV index and PUSCH repetition information by notifying the indexes corresponding to each row of the table.

[0087] [Option 6: Hybrid Automatic Repeat Request (HARQ) process number field]

[0088] Information about PUSCH repetitions (e.g., the number of repetitions) can be indicated using X bits of the 4 bits in the HARQ process number field. Alternatively, the HARQ process number can be indicated using 4-X bits of the 4 bits in the HARQ process number field.

[0089] At this point, the candidate values ​​for the PUSCH repetition information notified via the HARQ process number field and the HARQ process number are 2 respectively. X 2 4-X These values ​​can be predefined in the standard or configured for terminal 200 via SIB or RRC.

[0090] Additionally, for example, it is possible to define or configure via SIB or RRC to include HARQ process number and PUSCHrepetition related information in each column, up to a maximum of 2. 4 A table of rows. For example, you can notify the HARQ process number and PUSCH repetition information by notifying the index corresponding to each row of the table.

[0091] The above illustrates an example of how to inform PUSCH about repetition-related information by reusing a portion of the information field of the DCI format 0-0 of the CRC with added useful C-RNTI scrambling.

[0092] According to this embodiment, when a terminal 200 that has requested a Msg.5 PUSCH repetition, a terminal 200 that has notified the base station 100 of its Msg.5 PUSCH repetition capability, or a terminal 200 with Msg.5 PUSCH repetition capability receives a DCI format 0-0 with a CRC scrambled with a useful C-RNTI, it can obtain PUSCH repetition-related information by reinterpreting specific information fields as notifications of PUSCH repetition-related information. Therefore, according to this embodiment, the terminal 200 can repetition send PUSCHs scheduled by a DCI format 0-0 with a CRC scrambled with a useful C-RNTI.

[0093] Furthermore, the PUSCH applicable to this embodiment is not limited to the Msg.5 PUSCH described above, the PUSCH containing RRCSetupComplete, or the PUSCH scheduled by DCI format 0-0 with CRC scrambled with useful C-RNTI after the terminal 200 sends the Msg.3 PUSCH but before the terminal-specific PUSCH configuration is completed. For example, this embodiment can also be applied to PUSCHs scheduled by DCI format 0-0 with CRC scrambled with useful C-RNTI after the terminal-specific PUSCH configuration is completed.

[0094] Furthermore, in options 1 to 6 above, it is not limited to assigning PUSCH repetition-related information to the MSB or LSB as a specific field; the X bit can also be assigned to other areas. Additionally, in the information field assigned with PUSCH repetition-related information, the X bit can be any number of bits between 1 bit and all bits.

[0095] Alternatively, PUSCH repetition-related information can be distributed across multiple information fields. For example, PUSCH repetition-related information can be distributed across a portion or all of multiple information fields.

[0096] [Example of Terminal 200's Actions]

[0097] Figure 3 This is a flowchart representing an example of the actions of terminal 200.

[0098] exist Figure 3In step S101, terminal 200 acquires information related to the repetition of a PUSCH (e.g., Msg.5 PUSCH) scheduled in DCI format 0-0 with a CRC scrambled with an additional useful C-RNTI. The PUSCH repetition-related information acquired by terminal 200 in S101 may include, for example, multiple candidates for repetition-related information (e.g., the number of repetitions) notified by DCI format 0-0, information about information fields in DCI format 0-0 that are reused as repetition-related information, or information such as the number of bits X allocated to repetition-related information in that information field. Furthermore, some or all of the above information may be predetermined in the standard.

[0099] Terminal 200 receives DCI format 0-0 (S102).

[0100] Terminal 200 determines whether a repetition of PUSCH scheduled by DCI format 0-0 has been requested (S103).

[0101] If a PUSCH repetition is requested (S103: Yes), the terminal 200 obtains information related to the PUSCH repetition (e.g., the number of repetitions) by reinterpreting the received DCI format 0-0 partial information fields (e.g., partial bits) (S104). Then, the terminal 200 sends the PUSCH repetition (e.g., the PUSCH that was retransmitted) (S105).

[0102] On the other hand, if no repetition of PUSCH is requested (S103: No), the terminal 200 reads the received DCI format 0-0 information field in the existing manner to obtain information related to PUSCH transmission (S106). Then, the terminal 200 sends PUSCH (S107).

[0103] As described above, in this embodiment, terminal 200 receives DCI format 0-0 containing a CRC scrambled with C-RNTI and scheduling PUSCH independently of terminal-specific RRC configuration (e.g., dedicated RRC configuration), and performs PUSCH repetition based on PUSCH repetition information determined according to the received DCI format 0-0. Additionally, base station 100 transmits DCI format 0-0 containing a CRC scrambled with C-RNTI and scheduling PUSCH independently of terminal-specific RRC configuration, and receives PUSCH repetition based on PUSCH repetition information determined according to the transmitted DCI format 0-0.

[0104] In this embodiment, at least a portion of the information fields in the DCI format 0-0 that contain information different from repetition-related information are allocated with repetition-related information. Therefore, the terminal 200 can control the transmission of repetitions for PUSCHs scheduled using DCI format 0-0 with a CRC scrambled with an additional useful C-RNTI. Furthermore, for PUSCHs scheduled using DCI format 0-0 with a CRC scrambled with an additional useful C-RNTI, repetition-related information can be notified to the terminal 200 via this DCI format 0-0.

[0105] Therefore, according to this embodiment, for PUSCHs scheduled in DCI format 0-0 with CRC scrambling supplemented with useful C-RNTI, the Repetition function can be applied efficiently taking into account the transmission of Msg.5 PUSCHs (e.g., PUSCHs containing RRCSetupComplete). Thus, the terminal 200 can appropriately transmit signals in the uplink.

[0106] (Implementation Method 2)

[0107] In this embodiment, it is envisioned that application repetition is applied for the transmission of PUSCH such as: Msg.5PUSCH, PUSCH containing RRCSetupComplete, or PUSCH scheduled by DCI format 0-0 with CRC scrambled with useful C-RNTI after terminal 200 sends Msg.3 PUSCH and before the terminal-specific PUSCH configuration (e.g., Dedicated PUSCH configuration) is completed.

[0108] Furthermore, in this embodiment, the above-mentioned PUSCH is collectively referred to as "Msg.5 PUSCH".

[0109] In Implementation 1, a portion of the existing information fields in DCI format 0-0 are used (reused for) notification of PUSCH repetition-related information. Therefore, the flexibility of scheduling existing parameters notified by the information field used to notify of PUSCH repetition-related information may be reduced.

[0110] Here, we envision the application of the Repetition function (extended function) to a PUSCH scheduled by DCI format 0-0 with CRC scrambled by an additional useful C-RNTI. The application targets are Msg.5 PUSCH, PUSCH containing RRCSetupComplete, or PUSCH scheduled after terminal 200 sends Msg.3 PUSCH but before the terminal-specific PUSCH configuration is completed.

[0111] In this scenario, terminal 200 monitors PDCCH candidates for DCI format 0-0 with CRC scrambling with added useful C-RNTI within the type 1-PDCCH CSS set, and applies repetition to PUSCHs scheduled by the decoded DCI (e.g., DCI format 0-0 with CRC scrambling with added useful C-RNTI). At this point, it is envisioned that terminal 200 may be unable to utilize the terminal-specific PDCCH reception configuration. Therefore, it is envisioned that, for example, in terminal 200, because monitoring is not performed in the terminal-specific USS, there is a margin in the number of blind decoding operations performed by terminal 200.

[0112] Therefore, in this embodiment, terminal 200 monitors PDCCH candidates for a DCI format specific to PUSCH repetitions scheduled by DCI format 0-0 with CRC scrambled with useful C-RNTI.

[0113] For example, terminal 200 monitors PDCCH candidates that are DCI format 0-0 PDCCH candidates with a payload size different from the payload size of the existing DCI format 0-0 with CRC scrambling with added useful C-RNTI. Alternatively, for example, base station 100 generates a DCI format 0-0 with CRC scrambling with added useful C-RNTI, containing information related to Msg.5 PUSCH repetition, using a payload size different from the payload size of the existing DCI format 0-0 with CRC scrambling with added useful C-RNTI, and sends it to terminal 200.

[0114] Terminal 200, for example, monitors PDCCH candidates for DCI format 0-0 with CRC scrambling for additional useful C-RNTI within a type 1-PDCCH CSS set. At this time, in addition to existing DCI format 0-0 (e.g., DCI without repetition-related information fields) and DCI format 1-0, terminal 200 also performs blind decoding on DCI format 0-0 with a payload size different from existing DCI format 0-0 (and DCI format 1-0). That is, terminal 200 performs blind decoding on DCI format 0-0 for multiple payload sizes. Furthermore, the terminal 200 performing blind decoding on DCI format 0-0 for multiple payload sizes could be, for example, a terminal 200 that has requested Msg.5 PUSCH repetition, a terminal 200 that has notified base station 100 of its Msg.5 PUSCH repetition capability, or a terminal 200 with Msg.5 PUSCH repetition capability.

[0115] Here, a DCI format 0-0 with a payload size different from the existing DCI format 0-0 with additional useful C-RNTI scrambling for CRC, could be a DCI format that adds an information field for notifying PUSCH repetition information to the existing DCI format 0-0. This information field for notifying PUSCH repetition information could be, for example, at least one of an information field notifying the number of repetitions and other information fields (e.g., notifications related to the frequency hopping method, notifications related to whether flexible symbols are used). Furthermore, the information fields added to the existing DCI format 0-0 are not limited to those for notifying PUSCH repetition information; they could also be information fields for purposes other than PUSCH repetition. In addition to the added information fields, reserved bits can also be added to the existing DCI format 0-0 to account for future standard extensions.

[0116] If the payload size of a successfully decoded DCI (e.g., DCI format 0-0 with CRC scrambling added with useful C-RNTI) is the same as the payload size of an existing DCI format 0-0 (and DCI format 1-0), the terminal 200 determines that it will not apply repetition to the PUSCH it has scheduled and sends the PUSCH.

[0117] On the other hand, if the payload size of a successfully decoded DCI (e.g., DCI format 0-0 with CRC scrambling with useful C-RNTI) is different from the payload size of the existing DCI format 0-0 (and DCI format 1-0), the terminal 200 determines that it is applying repetition to the PUSCH it has scheduled, and sends the PUSCH after repetition.

[0118] Additionally, in this embodiment, for example, such as Figure 4 As shown, the timing (or time period) for blind decoding of multiple payload sizes (e.g., existing DCI and new DCI) of DCI format 0-0 candidates for CRC with additional useful C-RNTI scrambling within the type 1-PDCCH CSS set can be the timing (or time period) until the terminal 200 is assigned a type 3-PDCCH CSS set (e.g., configured with SearchSpaceType = common in the terminal-specific PDCCH-Config) or a USS set. Figure 4 As shown, after terminal 200 is assigned a type 3-PDCCH CSS set or a USS CSS set, blind decoding of multiple payload sizes within a type 1-PDCCH CSS set is not required. For example, as Figure 4 As shown, after the terminal 200 is assigned a type 3-PDCCH CSS set or a USS set, blind decoding of the existing DCI can be performed within the type 1-PDCCH CSS set. In this way, the increase in the number of blind decodings for different DCI payload sizes (e.g., up to 4 times) can be suppressed, and the impact on DCI decoding after obtaining the USS can be suppressed.

[0119] Furthermore, the blind decoding action of terminal 200 is not limited to Figure 4 The example shown could also be that, after terminal 200 is assigned a type 3-PDCCH CSS set or a USS set, terminal 200 performs blind decoding of multiple payload sizes (e.g., existing DCI and new DCI).

[0120] [Example of Terminal 200's Actions]

[0121] Figure 5 This is a flowchart representing an example of the actions of terminal 200.

[0122] exist Figure 5In S201, terminal 200 acquires information related to the repetition of a PUSCH (e.g., Msg.5 PUSCH) scheduled in DCI format 0-0 with an additional useful C-RNTI scrambled CRC (S201). The information about the PUSCH repetition acquired by terminal 200 in S201 may include, for example, information related to the payload size of DCI format 0-0 (or the size of the information field of the PUSCH repetition in DCI format 0-0).

[0123] Terminal 200 determines whether a repetition of PUSCH scheduled by DCI format 0-0 has been requested (S202).

[0124] If a PUSCH repetition is requested (S202: Yes), then terminal 200, for example within a Type 1 PDCCH CSS set, performs blind decoding (monitoring) of DCI format 0-0 for multiple payload sizes of the DCI (e.g., existing DCI size and DCI size different from existing DCI size) for the DCI format 0-0 with CRC for additional useful C-RNTI scrambling (S203). Then, for example, if the blind decoding of DCI format 0-0 with a DCI size different from existing DCI size is successful, terminal 200 obtains PUSCH repetition related information (e.g., number of repetitions) from DCI format 0-0 (S204). Then, terminal 200 sends the PUSCH repetition (e.g., the PUSCH that was repeatedly sent) (S205).

[0125] On the other hand, if no repetition of PUSCH is requested (S202: No), terminal 200, for example, within the type 1 PDCCH CSS set, performs blind decoding (monitoring) of DCI format 0-0 of the existing DCI size with respect to the PDCCH candidate for DCI format 0-0 with CRC scrambling with additional useful C-RNTI (S206). Then, for example, if the blind decoding of DCI format 0-0 of the existing DCI size is successful, terminal 200 obtains information related to PUSCH transmission from DCI format 0-0 (S207). Then, terminal 200 transmits PUSCH (S208).

[0126] As described above, in this embodiment, terminal 200 receives DCI format 0-0 containing a CRC scrambled with C-RNTI and scheduling PUSCH independently of terminal-specific RRC configuration (e.g., dedicated RRC configuration), and performs PUSCH repetition based on information related to PUSCH repetition determined according to the received DCI format 0-0.

[0127] In this embodiment, a DCI format 0-0 with a payload size different from that of the existing DCI format 0-0 is used; that is, a DCI format 0-0 with multiple payloads is used. For example, the DCI format 0-0 with a payload size different from that of the existing DCI format 0-0 includes an information field for notifying information related to PUSCH repetition. Thus, according to this embodiment, information related to PUSCH repetition (e.g., the number of repetitions) can be notified without changing the existing information fields. Therefore, PUSCH repetition scheduling can be performed without reducing the flexibility of scheduling related to parameters other than PUSCH repetition.

[0128] Furthermore, when the terminal-specific PDCCH receive configuration is unavailable and there is sufficient margin for blind decoding in the terminal 200, the terminal 200 performs blind decoding on multiple payload sizes for PDCCH candidates with DCI format 0-0 for CRC scrambling with added useful C-RNTI. For example, the terminal 200 performs blind decoding on DCI format 0-0 for multiple payload sizes before being assigned a terminal-specific search space (e.g., a type 3-PDCCHCSS set or a USS set). On the other hand, when the terminal-specific PDCCH receive configuration is available, the terminal 200 performs blind decoding on PDCCH candidates with DCI format 0-0 for CRC scrambling with added useful C-RNTI at the existing DCI size, instead of performing blind decoding on DCI format 0-0 at a different size than the existing DCI size. In this way, the impact on the blind decoding capability of the terminal 200 can be suppressed.

[0129] (Implementation Method 3)

[0130] In this embodiment, it is envisioned that repetition is applied to PUSCHs such as: Msg.5 PUSCH, PUSCH containing RRCSetupComplete, or PUSCHs scheduled in DCI format 0-0 with an additional useful C-RNTI scrambled CRC after the terminal 200 sends Msg.3 PUSCH and before the terminal-specific PUSCH configuration (e.g., Dedicated PUSCH configuration) is completed.

[0131] Furthermore, in this embodiment, the above-mentioned PUSCH is collectively referred to as "Msg.5 PUSCH".

[0132] In this embodiment, terminal 200 monitors multiple DCI format 0-0 PDCCH candidates for CRCs scrambled with different useful C-RNTIs. For example, regarding DCI format 0-0 with CRCs scrambled with useful C-RNTIs, terminal 200 monitors PDCCH candidates corresponding to multiple RNTIs, such as C-RNTIs for PUSCH scheduling without PUSCH repetition and C-RNTIs for PUSCH scheduling with PUSCH repetition.

[0133] For example, in the Type 1-PDCCH CSS set, terminal 200 monitors DCI format 0-0 candidates for CRCs scrambled with additional useful C-RNTIs. At this time, terminal 200 performs blind decoding on multiple DCI format 0-0s for CRCs scrambled with different useful C-RNTIs. That is, terminal 200 performs blind decoding on multiple C-RNTIs for DCI format 0-0. Furthermore, the terminal 200 performing blind decoding on multiple C-RNTIs for DCI format 0-0 can be, for example, a terminal 200 that has requested a Msg.5 PUSCH repetition, a terminal 200 that has notified base station 100 of its Msg.5 PUSCH repetition capability, or a terminal 200 that has a Msg.5 PUSCH repetition capability.

[0134] Here, for example, when the C-RNTI configured in terminal 200 is “n”, multiple different C-RNTIs can be C-RNTIs given by “n” and “n+1”, where: C-RNTI n is a C-RNTI for PUSCH scheduling without PUSCH repetition, and C-RNTI n+1 is a C-RNTI for PUSCH scheduling with PUSCH repetition.

[0135] Furthermore, the C-RNTI for PUSCH scheduling with PUSCH repetition is not limited to n+1; it can also be a value calculated from C-RNTI n using other methods. Additionally, the C-RNTI for PUSCH scheduling with PUSCH repetition can be predefined in the standard or calculated based on parameters configured to terminal 200 via SIB or RRC.

[0136] If the successfully decoded DCI (e.g., DCI format 0-0 with CRC scrambling with useful C-RNTI) is scrambled with C-RNTI for PUSCH scheduling that does not apply PUSCH repetition (e.g., DCI format 0-0 that does not notify PUSCH repetition related information), then terminal 200 determines that it will not apply repetition to the PUSCH it schedules and sends the PUSCH.

[0137] On the other hand, if the successfully decoded DCI (e.g., DCI format 0-0 with CRC scrambling and useful C-RNTI) is scrambled using C-RNTI for PUSCH scheduling for PUSCH repetition (e.g., DCI format 0-0 notifying PUSCH repetition related information), then terminal 200 determines that a repetition is to be applied to its scheduled PUSCH and sends the repetition. In this case, for example, based on one of the methods described in embodiments 1 to 6, the PUSCH repetition related information (e.g., the number of repetitions) can be notified to terminal 200 by reusing a portion of the information fields of DCI format 0-0.

[0138] In addition, in this embodiment, for example, as Figure 6 As shown, in the Type 1-PDCCH CSS set, the timing (or time period) for blind decoding of multiple C-RNTIs on the DCI format 0-0 PDCCH candidate for CRC scrambling with additional useful C-RNTIs can be the timing (or time period) until the terminal 200 is assigned to the Type 3-PDCCH CSS set (e.g., configured as SearchSpaceType = common in the terminal-specific PDCCH-Config) or the USS set. Figure 6 As shown, after terminal 200 is assigned a type 3-PDCCH CSS set or a USS set, blind decoding of multiple C-RNTIs within the type 1-PDCCH CSS set is not required. For example, as Figure 6As shown, after the terminal 200 is assigned a type 3-PDCCH CSS set or a USS set, blind decoding of the existing C-RNTI can be performed within the type 1-PDCCH CSS set. In this way, the increase in the number of blind decodings for different C-RNTIs (e.g., up to 4 times) can be suppressed, and the impact on DCI decoding after obtaining the USS can be suppressed.

[0139] Furthermore, the blind decoding action of terminal 200 is not limited to Figure 6 The example shown could also be that, after terminal 200 is assigned a type 3-PDCCH CSS set or a USS set, terminal 200 performs blind decoding of multiple C-RNTIs (e.g., existing DCI and new DCI).

[0140] As described above, in this embodiment, terminal 200 receives DCI format 0-0 containing a CRC scrambled with C-RNTI and scheduling PUSCH independently of terminal-specific RRC configuration (e.g., dedicated RRC configuration), and performs PUSCH repetition based on information related to PUSCH repetition determined according to the received DCI format 0-0.

[0141] In this embodiment, a DCI format 0-0 is used, wherein the C-RNTI used for CRC scrambling in the DCI format 0-0 is a variety of payloads. For example, for a DCI format 0-0 using a C-RNTI different from that of the existing DCI format 0-0, as in Embodiment 1, PUSCH repetition related information is notified in a portion of the information field that notifies other parameters. Thus, according to this embodiment, whether a portion of the information field of the DCI format is reused for PUSCH repetition related information (e.g., the number of repetitions) can vary depending on whether PUSCH repetition is applied. For example, when PUSCH repetition is not applied, there is no need to change the existing information field, thus maintaining the scheduling flexibility when PUSCH repetition is not applied.

[0142] Furthermore, when the terminal-specific PDCCH receiving configuration is unavailable and there is sufficient margin for blind decoding in the terminal 200, the terminal 200 performs blind decoding of multiple C-RNTIs for PDCCH candidates with DCI format 0-0 scrambled against a CRC with an added useful C-RNTI. For example, the terminal 200 performs blind decoding of DCI format 0-0 for multiple C-RNTIs before being assigned a terminal-specific search space (e.g., a type 3-PDCCH CSS set or a USS set). On the other hand, when the terminal-specific PDCCH receiving configuration is available, the terminal 200 performs blind decoding of existing C-RNTIs for PDCCH candidates with DCI format 0-0 scrambled against a CRC with an added useful C-RNTI, but does not perform blind decoding for C-RNTIs that are different from existing C-RNTIs. In this way, the impact on the blind decoding capability of the terminal 200 can be suppressed.

[0143] Furthermore, the PUSCH applicable to this embodiment is not limited to the Msg.5 PUSCH described above, the PUSCH containing RRCSetupComplete, or the PUSCH scheduled in DCI format 0-0 with an additional useful C-RNTI scrambled CRC after the terminal 200 sends the Msg.3 PUSCH but before the terminal-specific PUSCH configuration is completed. For example, this embodiment can also be applied to PUSCHs scheduled in DCI format 0-0 with an additional useful C-RNTI scrambled CRC after the terminal-specific PUSCH configuration is completed.

[0144] Furthermore, this embodiment describes a scenario where, when applying PUSCH repetition, a portion of the information field of the existing DCI format 0-0 is reinterpreted (reused) as PUSCH repetition-related information, as in Embodiment 1. However, the method for notifying PUSCH repetition-related information is not limited to this. For example, if the successfully decoded DCI format 0-0 is scrambled using C-RNTI scrambling for PUSCH scheduling applied to PUSCH repetition, then terminal 200 determines that PUSCH repetition is applied and performs PUSCH repetition. In other words, whether or not PUSCH repetition is applied can be implicitly notified to terminal 200. In this case, PUSCH repetition-related information (e.g., the number of repetitions) can be predefined in the standard or configured to terminal 200 via SIB or RRC.

[0145] Furthermore, in this embodiment, the C-RNTI (a C-RNTI different from existing C-RNTIs) used when applying PUSCH repetition is not limited to one, but can be multiple. For example, the action of PUSCH repetition (e.g., the number of repetitions) can correspond to different C-RNTIs.

[0146] (A variation of implementation method 3)

[0147] In Implementation 3, a method is described to distinguish whether the DCI format 0-0 of the CRC with added useful C-RNTI scrambling contains PUSCH repetition-related information by making the C-RNTI for PUSCH scheduling without PUSCH repetition different from the C-RNTI for PUSCH scheduling with PUSCH repetition. However, this method is not limited to this.

[0148] For example, the same effect as in implementation 3 can be achieved by applying a method that distinguishes whether the DCI format 0-0 of the CRC with added useful C-RNTI scrambling contains PUSCH repetition related information by making the CRC mask (instead of C-RNTI) different.

[0149] For example, a CRC mask could be omitted (or applied as a CRC mask [0, 0, 0, 0, ..., 0]) for DCI format 0-0 of a PUSCH schedule without PUSCH repetition, while a CRC mask could be applied for DCI format 0-0 of a PUSCH schedule with PUSCH repetition. As an example, applying a CRC mask [0, 0, 0, 0, ..., 1] to DCI format 0-0 of a PUSCH schedule with PUSCH repetition has the same effect as using C-RNTI n and n+1.

[0150] (Implementation Method 4)

[0151] In this embodiment, it is envisioned that repetition is applied to PUSCHs such as: Msg.5 PUSCH, PUSCH containing RRCSetupComplete, or PUSCHs scheduled in DCI format 0-0 with an additional useful C-RNTI scrambled CRC after the terminal 200 sends Msg.3 PUSCH and before the terminal-specific PUSCH configuration (e.g., Dedicated PUSCH configuration) is completed.

[0152] Furthermore, in this embodiment, the above-mentioned PUSCH is collectively referred to as "Msg.5 PUSCH".

[0153] Furthermore, the PUSCH to which this embodiment can be applied is not limited to the Msg.5 PUSCH described above, the PUSCH containing RRCSetupComplete, or the PUSCH scheduled by DCI format 0-0 with an additional useful C-RNTI scrambled CRC after the terminal 200 sends the Msg.3 PUSCH but before the terminal-specific PUSCH configuration is completed. For example, it is also conceivable to apply this embodiment to a PUSCH scheduled by DCI format 0-0 with an additional useful C-RNTI scrambled CRC after the terminal-specific PUSCH configuration is completed.

[0154] In this embodiment, the functionality (or mechanism) for PUSCH repetition is configured (or maintained) to be the same between the following two types of PUSCH: repetition of Msg.5 PUSCH (e.g., PUSCH scheduled in DCI format 0-0 with CRC scrambled with additional useful C-RNTI before terminal-specific PUSCH configuration is completed), and PUSCH scheduled in DCI format 0-0 with CRC scrambled with additional useful C-RNTI after terminal-specific PUSCH configuration is completed.

[0155] For example, when applying the method of Embodiment 1 (e.g., one of the methods in Options 1 to 6) or the method of Embodiment 3 to a repetition of Msg.5 PUSCH (e.g., a PUSCH scheduled in DCI format 0-0 with a CRC scrambled with an additional useful C-RNTI before the terminal-specific PUSCH configuration is completed), the same method as applied to the repetition of Msg.5 PUSCH is also applied to a PUSCH scheduled in DCI format 0-0 with a CRC scrambled with an additional useful C-RNTI after the terminal-specific PUSCH configuration is completed.

[0156] According to this embodiment, the base station 100 can schedule PUSCHs scheduled by DCI format 0-0 with CRC scrambled with additional useful C-RNTI without determining the RRC processing delay (e.g., RRC decoding time) of the terminal 200, and without distinguishing between PUSCHs scheduled by DCI format 0-0 with CRC scrambled with additional useful C-RNTI before the terminal-specific PUSCH configuration is completed and PUSCHs scheduled by DCI format 0-0 with CRC scrambled with additional useful C-RNTI after the terminal-specific PUSCH configuration is completed, by applying Repetition.

[0157] (Implementation Method 5)

[0158] In this embodiment, it is envisioned that repetition is applied to PUSCHs such as: Msg.5 PUSCH, PUSCH containing RRCSetupComplete, or PUSCHs scheduled in DCI format 0-0 with an additional useful C-RNTI scrambled CRC after the terminal 200 sends Msg.3 PUSCH and before the terminal-specific PUSCH configuration (e.g., Dedicated PUSCH configuration) is completed.

[0159] Furthermore, in this embodiment, the above-mentioned PUSCH is collectively referred to as "Msg.5 PUSCH".

[0160] Furthermore, the PUSCH to which this embodiment can be applied is not limited to the Msg.5 PUSCH described above, the PUSCH containing RRCSetupComplete, or the PUSCH scheduled by DCI format 0-0 with an additional useful C-RNTI scrambled CRC after the terminal 200 sends the Msg.3 PUSCH but before the terminal-specific PUSCH configuration is completed. For example, it is also conceivable to apply this embodiment to a PUSCH scheduled by DCI format 0-0 with an additional useful C-RNTI scrambled CRC after the terminal-specific PUSCH configuration is completed.

[0161] In this embodiment, the function (or mechanism) for PUSCH repetition is made different between two types of PUSCH: repetition of Msg.5 PUSCH (e.g., a PUSCH scheduled in DCI format 0-0 with a CRC scrambled with an additional useful C-RNTI before terminal-specific PUSCH configuration is completed), and PUSCH scheduled in DCI format 0-0 with a CRC scrambled with an additional useful C-RNTI after terminal-specific PUSCH configuration is completed.

[0162] For example, you can choose Figure 7 One of the combinations shown (options A to H) serves as the function of applying repetition to Msg.5 PUSCH (e.g., PUSCH scheduled in DCI format 0-0 with CRC scrambled with additional useful C-RNTI before terminal-specific PUSCH configuration is completed), and the function of applying PUSCH scheduled in DCI format 0-0 with CRC scrambled with additional useful C-RNTI after terminal-specific PUSCH configuration is completed.

[0163] <Option A>

[0164] In option A, for example, for Msg.5 PUSCH repetition (e.g., a PUSCH scheduled by DCI format 0-0 with CRC scrambled with additional useful C-RNTI before the terminal-specific PUSCH configuration is completed), the method of embodiment 1 (e.g., one of the methods in options 1 to 6) or the method of embodiment 3 is applied.

[0165] Furthermore, for PUSCHs scheduled in DCI format 0-0 with a CRC scrambled with an additional useful C-RNTI after the terminal-specific PUSCH configuration is completed, the same method as applied to the repetition of Msg.5 PUSCH is applied. However, in this case, a different RRC configuration may be followed than that for Msg.5 PUSCH. For example, when applying the method of Implementation 1, the candidates for notifiable PUSCH repetition-related information (e.g., number of repetitions) and other parameters may differ by the RRC configuration for both Msg.5 PUSCH repetitions and PUSCH repetitions scheduled in DCI format 0-0 with a CRC scrambled with an additional useful C-RNTI after the terminal-specific PUSCH configuration is completed.

[0166] <Option B>

[0167] In option B, for example, for Msg.5 PUSCH repetition (e.g., a PUSCH scheduled by DCI format 0-0 with CRC scrambled with additional useful C-RNTI before the terminal-specific PUSCH configuration is completed), the method of implementation 1 (e.g., one of the methods in options 1 to 6) is applied.

[0168] Additionally, for PUSCHs scheduled in DCI format 0-0 with CRC scrambled with useful C-RNTI after terminal-specific PUSCH configuration is completed, the method of Implementation 1 (e.g., one of options 1 to 6) is applied. However, for this PUSCH, the option applied is different from the option applied during Msg.5 PUSCH repetition.

[0169] <Option C>

[0170] In option C, for the repetition of Msg.5 PUSCH (e.g., a PUSCH scheduled by DCI format 0-0 with CRC scrambled with additional useful C-RNTI before the terminal-specific PUSCH configuration is completed), the method of implementation 1 (e.g., one of the methods in options 1 to 6) or the method of implementation 2 is applied.

[0171] In addition, for PUSCHs scheduled by DCI format 0-0 with CRC scrambled with additional useful C-RNTI after the terminal-specific PUSCH configuration is completed, the method of implementation method 3 is applied.

[0172] <Option D>

[0173] In option D, for the repetition of Msg.5 PUSCH (e.g., a PUSCH scheduled by DCI format 0-0 with CRC scrambled with additional useful C-RNTI before the terminal-specific PUSCH configuration is completed), the method of implementation 2 or implementation 3 is applied.

[0174] Additionally, for PUSCHs scheduled in DCI format 0-0 with CRC scrambled with additional useful C-RNTI after the terminal-specific PUSCH configuration is completed, the method of Implementation 1 (e.g., one of the methods in Options 1 to 6) is applied.

[0175] <Option E>

[0176] In option E, for the repetition of Msg.5 PUSCH (e.g., a PUSCH scheduled by DCI format 0-0 with CRC scrambled with additional useful C-RNTI before the terminal-specific PUSCH configuration is completed), the method of implementation 1 (e.g., one of the methods in options 1 to 6), the method of implementation 2, or the method of implementation 3 is applied.

[0177] In addition, for PUSCH scheduled in DCI format 0-0 with CRC scrambled with additional useful C-RNTI after the terminal-specific PUSCH configuration is completed, the number of repetitions is configured through the terminal-specific RRC. The terminal 200 applies repetitions to the PUSCH scheduled in DCI format 0-0 with CRC scrambled with additional useful C-RNTI based on the semi-static number of repetitions configured through RRC.

[0178] <Option F>

[0179] In option F, for the repetition of Msg.5 PUSCH (e.g., a PUSCH scheduled by DCI format 0-0 with CRC scrambled with additional useful C-RNTI before the terminal-specific PUSCH configuration is completed), the method of implementation 1 (e.g., one of the methods in options 1 to 6), the method of implementation 2, or the method of implementation 3 is applied.

[0180] Additionally, for PUSCHs scheduled in DCI format 0-0 with CRC scrambled with additional useful C-RNTI after terminal-specific PUSCH configuration is completed, a repetition is applied based on the number of repetitions of the most recently given Msg.5 PUSCH.

[0181] <Option G>

[0182] In option G, for the repetition of Msg.5 PUSCH (e.g., a PUSCH scheduled by DCI format 0-0 with CRC scrambled with additional useful C-RNTI before the terminal-specific PUSCH configuration is completed), the method of implementation 1 (e.g., one of the methods in options 1 to 6), the method of implementation 2, or the method of implementation 3 is applied.

[0183] Additionally, for PUSCHs scheduled in DCI format 0-0 with CRC scrambled with a useful C-RNTI after terminal-specific PUSCH configuration is completed, the repetition count is configured using the same method as for PUSCHs scheduled in DCI format 0-1 / 0-2 up to version 18. For example, this could be configured via RRC with a maximum of 2 columns containing TDRA-related parameters (e.g., slot index, number of symbols, etc.) and the repetition count. 5 The table of rows notifies the terminal 200 of the TDRA parameters and the number of repetitions by notifying the terminal 200 of one of the indexes corresponding to each row in the table.

[0184] <Option H>

[0185] In option H, for the repetition of Msg.5 PUSCH (e.g., a PUSCH scheduled by DCI format 0-0 with CRC scrambled with additional useful C-RNTI before the terminal-specific PUSCH configuration is completed), the method of implementation 1 (e.g., one of the methods in options 1 to 6), the method of implementation 2, or the method of implementation 3 are applied.

[0186] Additionally, PUSCH repetition is not supported for PUSCHs scheduled in DCI format 0-0 with an additional useful C-RNTI scrambled CRC after terminal-specific PUSCH configuration is completed.

[0187] The above examples illustrate combinations of functions for various PUSCH applications. Furthermore, the functions and combinations of functions for various PUSCH applications are not limited to... Figure 7 The example shown.

[0188] According to this embodiment, it is possible to provide the flexibility to apply different design guidelines to the following two types of PUSCH: PUSCH scheduled in DCI format 0-0 with CRC scrambled with additional useful C-RNTI before the terminal-specific PUSCH configuration is completed, and PUSCH scheduled in DCI format 0-0 with CRC scrambled with additional useful C-RNTI after the terminal-specific PUSCH configuration is completed.

[0189] (Variations of embodiments 4 and 5)

[0190] In embodiments 4 and 5 described above, a switching of transmission timing may occur between the repetition of Msg.5 PUSCH (e.g., PUSCH transmission scheduled by DCI format 0-0 with CRC scrambled with additional useful C-RNTI before the completion of the terminal-specific PUSCH configuration) and the PUSCH transmission scheduled by DCI format 0-0 with CRC scrambled with additional useful C-RNTI after the completion of the terminal-specific PUSCH configuration).

[0191] At this time, the timing of the switch (e.g., the timing when the terminal-specific PUSCH configuration is completed) may be, for example, the timing after the corresponding RRC decoding time specified in Non-Patent Document 9 has elapsed after the terminal 200 successfully receives the RRC message (e.g., RRCSetup).

[0192] For example, the timing of the switchover can be configured as a fixed time period (e.g., 10ms) after receiving an RRC message (e.g., RRCSetup) as the request time for RRC processing from RRCSetup to the sending of RRCSetupComplete.

[0193] Additionally, the timing of the handover (e.g., when the terminal-specific PUSCH configuration is completed) can be predefined in the standard or configured for the terminal 200 via SIB or RRC. For example, it can be configured to occur at a fixed time interval (e.g., 10ms) after receiving an RRC message (e.g., RRCSetup).

[0194] In addition, the time period after receiving an RRC message (e.g., RRCSetup) configured for switching timing is not limited to 10ms, but can also be other values.

[0195] [Base station structure]

[0196] Figure 8 This is a block diagram representing a structural example of base station 100. Figure 8 In this base station 100, there are a control unit 101, a higher layer control signal generation unit 102, a downlink control information generation unit 103, an encoding unit 104, a modulation unit 105, a signal distribution unit 106, a transmission unit 107, a receiving unit 108, an extraction unit 109, a demodulation unit 110, and a decoding unit 111.

[0197] It should be explained that Figure 8 The transmitting unit 107 shown may also be included in Figure 1 The transmitting unit is shown. Furthermore... Figure 8 At least one of the control unit 101, higher-layer control signal generation unit 102, downlink control information generation unit 103, encoding unit 104, modulation unit 105, signal distribution unit 106, receiving unit 108, extraction unit 109, demodulation unit 110, and decoding unit 111 shown may also be included in Figure 1 The receiving unit shown.

[0198] Control unit 101 determines, for example, information related to uplink transmission (e.g., PUSCH transmission) for terminal 200, and outputs the determined information to at least one of higher-layer control signal generation unit 102 and downlink control information generation unit 103. The information related to PUSCH transmission may include, for example, information related to PUSCH repetition (e.g., number of repetitions), time-domain resource allocation information (e.g., TDRA), and frequency-domain resource allocation information (e.g., FDRA). Furthermore, control unit 101 outputs the determined information to extraction unit 109, demodulation unit 110, and decoding unit 111.

[0199] Additionally, the control unit 101 may determine, for example, information related to higher-layer control signals or downlink signals used to transmit downlink control information (e.g., modulation and coding scheme (MCS) and radio resource allocation), and output the determined information to the coding unit 104, the modulation unit 105, and the signal allocation unit 106. Furthermore, the control unit 101 may output, for example, information related to downlink signals (e.g., data signals or higher-layer control signals) to the downlink control information generation unit 103.

[0200] The higher-level control signal generation unit 102 generates a higher-level control signal bit string based on information input from the control unit 101, and outputs the higher-level control signal bit string to the encoding unit 104.

[0201] The downlink control information generation unit 103 generates a downlink control information (e.g., DCI) bit string based on information input from the control unit 101, and outputs the generated DCI bit string to the encoding unit 104. It should be noted that the control information is sometimes sent to multiple terminals. For example, the downlink control information generation unit 103 may, according to any of the above embodiments, generate a DCI bit string (or, also called a DCI sequence) containing information related to PUSCH repetition. Furthermore, the downlink control information generation unit 103 may, according to any of the above embodiments, append a CRC sequence scrambled with RNTI (e.g., C-RNTI) to the DCI sequence.

[0202] The encoding unit 104 encodes, for example, the bit string input from the higher-layer control signal generation unit 102 or the DCI bit string input from the downlink control information generation unit 103 based on information input from the control unit 101. The encoding unit 104 outputs the encoded bit string to the modulation unit 105.

[0203] The modulation unit 105 modulates the encoded bit string input from the encoding unit 104 based on information input from the control unit 101, and outputs the modulated signal (e.g., symbol string) to the signal distribution unit 106.

[0204] The signal allocation unit 106 maps the symbol string (e.g., containing downlink data signals or control signals) input from the modulation unit 105 to the radio resources, for example, based on information representing radio resources input from the control unit 101. The signal allocation unit 106 then outputs the mapped downlink signal to the transmission unit 107.

[0205] The transmitting unit 107 performs transmission waveform generation processing on the signal input from the signal distribution unit 106, for example, using orthogonal frequency division multiplexing (OFDM). Additionally, in the case of OFDM transmission with an added cyclic prefix (CP), the transmitting unit 107 performs inverse fast fourier transform (IFFT) processing on the signal and adds CP to the IFFT-derived signal. Furthermore, the transmitting unit 107 performs RF (radio frequency) processing on the signal, such as D / A (digital / analog) conversion or up-conversion, and transmits the wireless signal to the terminal 200 via an antenna.

[0206] The receiving unit 108 performs RF processing, such as down-conversion or A / D (Analog / Digital) conversion, on the uplink signal received from the terminal 200 via the antenna. Alternatively, in the case of OFDM transmission, the receiving unit 108 performs Fast Fourier Transform (FFT) processing on the received signal and outputs the obtained frequency domain signal to the extraction unit 109.

[0207] The extraction unit 109 extracts, for example, the radio resource portion of the uplink signal (e.g., PUSCH) that was transmitted from the received signal input from the receiving unit 108 based on the information input from the control unit 101, and outputs the extracted radio resource portion to the demodulation unit 110.

[0208] The demodulation unit 110 demodulates the uplink signal (e.g., PUSCH) input from the extraction unit 109 based on information input from the control unit 101. The demodulation unit 110 outputs the demodulation result to the decoding unit 111, for example.

[0209] The decoding unit 111 performs error correction decoding on the uplink signal (e.g., PUSCH) based on information input from the control unit 101 and demodulation results input from the demodulation unit 110, and obtains the decoded received bit sequence.

[0210] [Terminal Structure]

[0211] Figure 9 This is a block diagram illustrating a structural example of a terminal 200 according to an embodiment of the present disclosure. For example, in Figure 9 In the terminal 200, there are receiving units 201, extraction units 202, demodulation units 203, decoding units 204, control units 205, encoding units 206, modulation units 207, signal distribution units 208, and transmitting units 209.

[0212] It should be explained that Figure 9 The receiving unit 201 shown may also be included in Figure 2 The receiving section is shown. Additionally... Figure 9 At least one of the extraction unit 202, demodulation unit 203, decoding unit 204, control unit 205, encoding unit 206, modulation unit 207, signal distribution unit 208, and transmission unit 209 shown may also be included in Figure 2 The transmitting unit is shown.

[0213] The receiving unit 201 receives downlink signals (e.g., downlink data signals or downlink control information) from the base station 100 via an antenna, and performs RF processing such as down-conversion or A / D conversion on the received wireless signal to obtain a received signal (baseband signal). Additionally, when receiving OFDM signals, the receiving unit 201 performs FFT processing on the received signal to convert it to the frequency domain. The receiving unit 201 outputs the received signal to the extraction unit 202.

[0214] For example, the extraction unit 202 extracts radio resource portions that may contain downlink control information from the received signal input from the receiving unit 201 based on radio resource information related to downlink control information input from the control unit 205, and outputs it to the demodulation unit 203. Additionally, the extraction unit 202 extracts radio resource portions containing downlink data signals based on radio resource information related to data signals input from the control unit 205, and outputs it to the demodulation unit 203.

[0215] The demodulation unit 203 demodulates the signal (e.g., PDCCH or PDSCH) input from the extraction unit 202 based on information input from the control unit 205, and outputs the demodulation result to the decoding unit 204.

[0216] The decoding unit 204 uses the demodulation result input from the demodulation unit 203 to perform error correction decoding on the PDCCH or PDSCH to obtain, for example, higher-layer control signals or downlink control information. The decoding unit 204 outputs the higher-layer control signals and downlink control information to the control unit 205. In addition, the decoding unit 204 may also generate a response signal (e.g., ACK / NACK (Acknowledgement / Negative Acknowledgement)) based on the decoding result of the PDSCH.

[0217] The control unit 205, for example, performs uplink transmission control (including determining whether a repetition for PUSCH transmission exists, the number of repetitions, etc., according to the method described above) based on information related to PUSCH transmission obtained from signals input from the decoding unit 204 (e.g., higher-layer control signals or downlink control information). The control unit 205 outputs the determined information to the encoding unit 206 and the signal distribution unit 208, for example.

[0218] The encoding unit 206 encodes, for example, the uplink data signal (UL data signal) or the uplink control signal based on information input from the control unit 205. The encoding unit 206 outputs the encoded bit string to the modulation unit 207.

[0219] The modulation unit 207 modulates, for example, the encoded bit string input from the encoding unit 206, and outputs the modulated signal (symbol string) to the signal distribution unit 208.

[0220] The signal allocation unit 208, for example, maps the signal (e.g., sequence) input from the modulation unit 207 to the radio resources based on information input from the control unit 205. The signal allocation unit 208, for example, outputs the mapped uplink signal to the transmission unit 209.

[0221] The transmitting unit 209 generates a transmit signal waveform, such as OFDM, from the signal input from the signal distribution unit 208. Alternatively, in the case of OFDM transmission using CP, the transmitting unit 209 performs IFFT processing on the signal and appends CP to the IFFT-generated signal. Or, in the case of generating a single-carrier waveform, the transmitting unit 209 may add a DFT section (not shown) after the modulation unit 207 or before the signal distribution unit 208. Furthermore, the transmitting unit 209 performs RF processing on the transmit signal, such as D / A conversion and up-conversion, and transmits the wireless signal to the base station 100 via an antenna.

[0222] (Other implementation methods)

[0223] (1) In the above embodiments, the base station 100 may notify the terminal 200 in the SIB that it supports Msg.5 PUSCH repetition, or the function of repetition of PUSCH scheduled by DCI format 0-0 with CRC scrambled with useful C-RNTI before the terminal-specific PUSCH configuration (e.g., Dedicated PUSCH configuration) is completed.

[0224] (2) In the above embodiments, the terminal 200 may request Msg.5 PUSCH repetition from the base station 100, or may notify the base station 100 that it has Msg.5 PUSCH repetition capability.

[0225] Furthermore, terminal 200 may choose not to notify base station 100 of its Msg.5 PUSCH repetition capability. In embodiments 2 or 3 described above, base station 100 may send DCI format 0-0 with different DCI payload sizes, or DCI format 0-0 scrambled with different C-RNTIs, to terminal 200 regardless of terminal 200's capabilities. Terminal 200 then sends a PUSCH or PUSCH repetition corresponding to the successfully decoded DCI format 0-0.

[0226] (3) In the above embodiments, it can also be determined whether flexible symbols can be used for PUSCH scheduled in DCI format 0-0 with CRC scrambled by an additional useful C-RNTI by the following methods. For example, the terminal can be informed by the following explicit notification whether the time slot containing flexible symbols, configured by higher-level parameters (e.g., tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated), or the flexible symbols themselves, can be used for PUSCH repetition configuration.

[0227] [Option 1: Notification via bitmap using SIB / Msg.4 PDSCH / DCI]

[0228] Base station 100 informs terminal 200 by including a bitmap in SIB, Msg.4 PDSCH, or DCI indicating whether a time slot containing flexible symbols is available. Each bit of the bitmap corresponds to one or more time slots composed of flexible symbols and indicates whether the associated time slot is available.

[0229] [Option 2: Notification via SIB / Msg.4 PDSCH / DCI using a 1-bit flag]

[0230] Base station 100 will notify terminal 200 by including a 1-bit flag indicating whether a time slot containing flexible symbols is available in the SIB, Msg.4PDSCH, or DCI. For example, when the 1-bit flag is triggered, it means that flexible symbols can be used for PUSCH repetition, and when the 1-bit flag is not triggered, it means that flexible symbols cannot be used for PUSCH repetition.

[0231] [Option 3: Notification via invalidSymbolPattern in SIB / Msg.4 PDSCH / DCI]

[0232] Base station 100 may, for example, include information indicating invalid symbols for PUSCH repetition (e.g., invalid symbol patterns) (e.g., existing invalidSymbolPattern) in the SIB, Msg.4 PDSCH, or DCI to notify terminal 200. The invalidSymbolPattern may, for example, indicate whether flexible symbols are available.

[0233] The above illustrates an example of a notification method for whether a time slot containing flexible symbols is available.

[0234] In addition, when notifying about the availability of flexible symbols via DCI, in the above-described implementation 2, a field for notifying about the availability of flexible symbols can be added to DCI format 0-0 as an information field for notifying about PUSCH repetition information.

[0235] Alternatively, the functionality related to the availability of flexible symbols can be differentiated between two types of PUSCHs: those repetitions of the Msg.5 PUSCH (e.g., PUSCHs scheduled in DCI format 0-0 with a CRC scrambled with a useful C-RNTI before the completion of terminal-specific PUSCH configuration (e.g., Dedicated PUSCH configuration)) and those scheduled in DCI format 0-0 with a CRC scrambled with a useful C-RNTI after the completion of terminal-specific PUSCH configuration (e.g., Dedicated PUSCH configuration). For example, for the repetition of the Msg.5 PUSCH, the availability of flexible symbols can be determined based on notifications related to their availability. On the other hand, for the PUSCH scheduled in DCI format 0-0 with a CRC scrambled with a useful C-RNTI after the completion of terminal-specific PUSCH configuration, the availability of flexible symbols can be predefined in the standard (e.g., it can be configured to always allow the use of flexible symbols).

[0236] (4) In the above embodiments, for PUSCH scheduled by DCI format 0-0 with CRC scrambled by additional useful C-RNTI, the application of frequency hopping and the hopping method can also be determined by the following methods.

[0237] [Option a]

[0238] For PUSCH repetitions scheduled in DCI format 0-0 with CRC scrambled with an additional useful C-RNTI, intra-slot frequency hopping is not applied. In this case, information fields in DCI format 0-0 related to the frequency hopping flag can be used, for example, to indicate whether inter-slot frequency hopping is valid or invalid.

[0239] [Option b]

[0240] For PUSCH repetitions scheduled in DCI format 0-0 with CRC scrambled with an additional useful C-RNTI, both intra-slot frequency hopping and inter-slot frequency hopping are supported. Information fields related to the frequency hopping flag in DCI format 0-0 can be used, for example, to notify whether an inter-slot or intra-slot frequency hopping is valid or invalid. Additionally, information regarding which hopping method is applied, whether inter-slot or intra-slot, can also be included in the SIB, Msg.4PDSCH, or DCI to notify terminal 200.

[0241] In addition, when notifying information related to the frequency hopping method via DCI, in the above-described embodiment 2, a field for notifying information related to the frequency hopping method can be added to the DCI format 0-0 as an information field for notifying PUSCH repetition related information.

[0242] Alternatively, the frequency hopping-related functionality can be differentiated between two types of PUSCHs: those scheduled for Msg.5 PUSCH repetition (e.g., PUSCH scheduled in DCI format 0-0 with CRC scrambled with useful C-RNTI before terminal-specific PUSCH configuration (e.g., Dedicated PUSCH configuration) is completed), and those scheduled in DCI format 0-0 with CRC scrambled with useful C-RNTI after terminal-specific PUSCH configuration (e.g., Dedicated PUSCH configuration) is completed. For example, for Msg.5 PUSCH repetition, inter-slot frequency hopping can be supported, but intra-slot frequency hopping cannot. On the other hand, for PUSCH scheduled in DCI format 0-0 with CRC scrambled with useful C-RNTI after terminal-specific PUSCH configuration is completed, both inter-slot and intra-slot frequency hopping can be supported.

[0243] (5) In the above embodiments, the RNTI used to scramble the CRC attached to the DCI is not limited to C-RNTI, but can also be other types of RNTI. For example, C-RNTI can also be replaced with temporary C-RNTI (TC-RNTI).

[0244] (6) In the above embodiments, the DCI format is not limited to DCI format 0-0, but may be other formats. DCI format 0-0 is sometimes referred to as the fallback DCI format. In addition, in the above embodiments, the types of information fields, the number of information fields, and the size (number of bits) of the information fields included in the DCI are only examples, and DCI formats containing other types, other numbers, or other sizes of information fields may also be used.

[0245] Furthermore, in the above embodiments, the channel used for uplink transmission (or the channel using repetition) is not limited to PUSCH, but can also be other channels. Additionally, the type of information transmitted is not limited to data, but can also be other types of information (e.g., uplink control signals (PUCCH)). Furthermore, one embodiment of this disclosure is not limited to uplink transmission, but can also be applied to downlink transmission or sidelink transmission.

[0246] This disclosure can also be applied, for example, to communication between terminals, such as sidelink communication.

[0247] In addition, in this disclosure, the downlink control channel, downlink data channel, uplink control channel, and uplink data channel are not limited to PDCCH (Physical Downlink Control Channel), PDSCH (Physical Downlink Shared Channel), PUCCH (Physical Uplink Control Channel), and PUSCH (Physical Uplink Shared Channel), respectively, and may also be control channels with other names.

[0248] In addition, although RRC signaling is envisioned as higher-layer signaling in this disclosure, it can also be replaced by signaling from MAC (Medium Access Control), physical layer signaling, i.e., DCI notification.

[0249] (Replenish)

[0250] Information indicating whether terminal 200 supports the functions, actions, or processes shown in the above embodiments and supplements can also be sent (or notified) by terminal 200 to base station 100 as capability information or capability parameters of terminal 200.

[0251] The capability information may also include an information element indicating whether the terminal 200 supports at least one of the functions, actions, and processes described in the above embodiments, variations, and supplements. Alternatively, the capability information may include an information element indicating whether the terminal 200 supports a combination of two or more of the functions, actions, and processes described in the above embodiments, variations, and supplements.

[0252] Base station 100 can, for example, determine (or decide or envision) the functions, actions, or processes supported (or not supported) by the source terminal 200, based on capability information received from terminal 200. Base station 100 can implement actions, processes, or controls corresponding to the determination results based on the capability information. For example, base station 100 can control uplink-related processes based on the capability information received from terminal 200.

[0253] It should be noted that terminal 200 does not support some of the functions, operations, or processes shown in the above embodiments, modifications, and supplements. Alternatively, in terminal 200, such a portion of the functions, operations, or processes may be limited. For example, information or requests related to such limitations may also be notified to base station 100.

[0254] Information related to the capabilities or limitations of terminal 200 may be defined in a standard, or may be implicitly communicated to base station 100 in association with information known to base station 100 or information sent to base station 100.

[0255] The above describes various implementations, modifications, and additions of a non-limiting embodiment of this disclosure.

[0256] (Control signal)

[0257] In this disclosure, the downlink control signal (information) associated with this disclosure can be a signal (information) transmitted in the physical layer PDCCH, or a signal (information) transmitted in the higher layer MAC (Medium Access Control) CE (Control Element) or RRC. Alternatively, a predefined signal (information) can also be used as the downlink control signal.

[0258] The uplink control signals (information) associated with this disclosure can be signals (information) transmitted in the physical layer PUCCH, or signals (information) transmitted in the higher layer MAC CE or RRC. Alternatively, the uplink control signals can be predefined signals (information). Furthermore, the uplink control signals can be replaced with UCI (Uplink Control Information), first-stage SCI (Sidelink Control Information), or second-stage SCI.

[0259] (Base station)

[0260] In this disclosure, a base station can be a TRP (Transmission Reception Point), cluster head, access point, RRH (Remote Radio Head), eNodeB (eNB), gNodeB (gNB), BS (BaseStation), BTS (Base Transceiver Station), host, gateway, etc. Additionally, in sidelink communication, the base station can be replaced with a terminal. A base station can also be a relay device for communication between a high-level relay node and a terminal. Furthermore, a base station can also be a roadside device.

[0261] (Uplink / Downlink / Sidelink)

[0262] This disclosure can be applied to any link in the uplink, downlink, and sidelink. For example, this disclosure can be applied to the uplink PUSCH, PUCCH, PRACH (Physical Random Access Channel), downlink PDSCH, PDCCH, PBCH (Physical Broadcast Channel), and sidelink PSSCH (Physical Sidelink Shared Channel), PSCCH (Physical Sidelink Control Channel), and PSBCH (Physical Sidelink Broadcast Channel).

[0263] It should be noted that PDCCH, PDSCH, PUSCH, and PUCCH are examples of downlink control channels, downlink data channels, uplink data channels, and uplink control channels, respectively. PSCCH and PSSCH are examples of sidelink control channels and sidelink data channels, respectively. PBCH and PSBCH are examples of broadcast channels, and PRACH is an example of a random access channel.

[0264] (Data Channel / Control Channel)

[0265] This disclosure can be applied to any channel in the data channel and the control channel. For example, the channels of this disclosure can also be replaced with PDSCH, PUSCH, PSSCH of the data channel and PDCCH, PUCCH, PBCH, PSCCH, PSBCH of the control channel.

[0266] (Reference signal)

[0267] In this disclosure, the reference signal is a signal known to both the base station and the terminal, and is sometimes also referred to as "RS (Reference Signal)" or "pilot signal". The reference signal can also be one of the following: DMRS (Demodulation Reference Signal), CSI-RS (Channel State Information-Reference Signal), TRS (Tracking Reference Signal), PTRS (Phase Tracking Reference Signal), CRS (Cell-specific Reference Signal), and SRS (Sounding Reference Signal).

[0268] (Time interval)

[0269] In this disclosure, the unit of time resource is not limited to one or a combination of time slots and symbols. For example, it can be a frame, superframe, subframe, time slot, sub-time slot, micro-time slot, or symbol, OFDM (Orthogonal Frequency Division Multiplexing) symbol, SC-FDMA (Single Carrier-Frequency Division Multiple Access) symbol, or other time resource units. Furthermore, the number of symbols contained in one time slot is not limited to the number of symbols exemplified in the above embodiments, and can also be other numbers of symbols.

[0270] (frequency band)

[0271] This disclosure can be applied to any band domain, whether it is an authorized band domain or an unauthorized band domain.

[0272] (communication)

[0273] This disclosure can be applied to any of the following: communication between a base station and a terminal (Uu link communication), communication between terminals (sidelink communication), and V2X (Vehicle to Everything) communication. For example, the channels in this disclosure can be replaced with PSCCH, PSSCH, PSFCH (Physical Sidelink Feedback Channel), PSBCH, PDCCH, PUCCH, PDSCH, PUSCH, and PBCH.

[0274] Furthermore, this disclosure can be applied to any network, including terrestrial networks and non-terrestrial networks (NTNs) that use satellites or High Altitude Pseudo Satellites (HAPS). Additionally, this disclosure can also be applied to terrestrial networks with transmission delays greater than the symbol length or time slot length, such as networks with large cell sizes and ultra-wideband transmission networks.

[0275] (Full duplex and sub-band SBFD)

[0276] In one embodiment of this disclosure, the actions of symbols for uplink, downlink, and sidelink can also be applied to symbols for SBFD (Subband non-overlapping full duplex) actions or control (e.g., SBFD symbols). In SBFD symbols, the frequency domain (or frequency resources, frequency band) is divided into multiple frequency domains (e.g., also called sub-bands, RB sets, sub-band domains, sub-BWPs (BandWidth Parts)). Terminals transmit and receive in different directions (e.g., downlink or uplink) using the divided areas, i.e., sub-bands. In SBFD symbols, a terminal can transmit and receive in one direction (uplink or downlink) without transmitting and receiving in the other direction. Alternatively, a base station can simultaneously transmit and receive in both the uplink and downlink, or be configured to be capable of both. It is possible that, compared to symbols that only transmit and receive in the downlink, SBFD symbols have less frequency domain available for the downlink. Conversely, it is possible that, compared to symbols that only transmit and receive in the uplink, SBFD symbols have less frequency domain available for the uplink.

[0277] In addition, in SBFD symbols, the terminal can simultaneously transmit and receive uplink and downlink signals. In this case, the frequency domains transmitted and received by the terminal do not have to be adjacent, but rather have a frequency gap (also known as a frequency interval).

[0278] In addition, the transmission and reception of side links can also be included in different directions based on the divided areas, i.e., sub-bands.

[0279] In one embodiment of this disclosure, the actions of symbols for uplink, downlink, and sidelink can also be applied to symbols for full-duplex operations or control (e.g., full-duplex symbols). In full-duplex symbols, both the terminal and the base station can simultaneously transmit and receive uplink and downlink signals. Full-duplex symbols can employ simultaneous transmission and reception by the terminal and base station in the available frequency domain (or frequency resources, frequency band), or they can employ simultaneous transmission and reception in a portion of the frequency domain (i.e., transmission or reception can be performed in a frequency domain other than a portion of the frequency domain). In this case, the frequency domains for transmission and reception by the base station or terminal may not be adjacent, but rather have a frequency gap (also called a frequency interval). Additionally, for example, for the purpose of reducing interference, actions can be employed where one of the terminal and the base station can simultaneously transmit and receive (i.e., the other party can either transmit or receive).

[0280] Furthermore, full-duplex operation can also be applied to a terminal's ability to simultaneously transmit and receive on the sidelink. Additionally, full-duplex operation can also be applied to a terminal's ability to simultaneously transmit and receive on the sidelink, uplink, and downlink.

[0281] (Antenna Port)

[0282] An antenna port refers to a logical antenna (antenna array) consisting of one or more physical antennas. That is, an antenna port does not necessarily refer to a single physical antenna; sometimes it refers to an array antenna composed of multiple antennas. For example, instead of specifying the number of physical antennas constituting an antenna port, it is defined as the smallest unit that the terminal can transmit a reference signal. Additionally, an antenna port is sometimes defined as the smallest unit multiplied by a precoding vector.

[0283] <5G NR System Architecture and Protocol Stack>

[0284] To realize the next version of fifth-generation mobile phone technology (also known simply as "5G"), which includes the development of a new radio access technology (NR) operating in the frequency range up to 100 GHz, 3GPP is continuing its work. The first version of the 5G standard was completed at the end of 2017, thus enabling the transition to the trial production of terminals (e.g., smartphones) according to the 5G NR standard and commercial deployment.

[0285] For example, the overall system architecture envisions a gNB-RAN (Next Generation Radio Access Network). The gNB provides UE-side termination for the NG radio access user plane (SDAP (Service Data Adaptation Protocol) / PDCP (Packet Data Convergence Protocol) / RLC (Radio Link Control) / MAC / PHY (Physical Layer)) and control plane (RRC) protocols. gNBs are interconnected via the Xn interface. Additionally, gNBs are connected to the NGC (Next Generation Core) via the Next Generation (NG) interface, and more specifically, to the AMF (Access and Mobility Management Function) (e.g., a specific core entity implementing the AMF) via the NG-C interface, and to the UPF (User Plane Function) (e.g., a specific core entity implementing the UPF) via the NG-U interface. Figure 10 This refers to the NG-RAN architecture (e.g., refer to 3GPP TS 38.300 v15.6.0, section 4).

[0286] The user plane protocol stack for NR (e.g., see 3GPP TS 38.300, section 4.4.1) comprises the PDCP (Packet Data Convergence Protocol, see TS 38.300, section 6.4) sublayer, RLC (Radio Link Control, see TS 38.300, section 6.3) sublayer, and MAC (Media Access Control, see TS 38.300, section 6.2) sublayer, which terminates on the network side in the gNB. Additionally, a new Access Stratum (AS) sublayer (SDAP: Service Data Adaptation Protocol) has been incorporated into PDCP (e.g., see 3GPP TS 38.300, section 6.5). Furthermore, a control plane protocol stack is defined for NR (e.g., see TS 38.300, section 4.4.2). A summary of Layer 2 functionality is described in Section 6 of TS 38.300. The functions of the PDCP sublayer, RLC sublayer, and MAC sublayer are listed in Sections 6.4, 6.3, and 6.2 of TS 38.300, respectively. The functions of the RRC layer are listed in Section 7 of TS 38.300.

[0287] For example, the media access control layer handles the multiplexing of logical channels, as well as scheduling and scheduling-related functions, including handling various parameter sets.

[0288] For example, the Physical Layer (PHY) is responsible for encoding, PHY HARQ (Physical Layer Hybrid Automatic Repeat Request) processing, modulation, multi-antenna processing, and mapping signals to appropriate physical time-frequency resources. Additionally, the Physical Layer handles the mapping of physical channels to transport 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 to transmit a specific transport channel; each transport channel is mapped to a corresponding physical channel. For example, in physical channels, uplink physical channels include PRACH (Physical Random Access Channel), PUSCH (Physical Uplink Shared Channel), and PUCCH (Physical Uplink Control Channel), while downlink physical channels include PDSCH (Physical Downlink Shared Channel), PDCCH (Physical Downlink Control Channel), and PBCH (Physical Broadcast Channel).

[0289] In NR use cases / extended scenarios, enhanced mobile broadband (eMBB), ultra-reliable low-latency communications (URLLC), and massive machine-type communications (mMTC) may have multiple necessary conditions in terms of data rate, latency, and coverage. For example, eMBB is expected to support peak data rates approximately three times that of IMT-Advanced (20Gbps in downlink and 10Gbps in uplink) and effective (user-experienced) data rates. On the other hand, in the case of URLLC, more stringent necessary conditions are proposed for ultra-low latency (0.5ms latency in both UL and DL) and high reliability (within 1ms, 1-10-5). Finally, in mMTC, high connection density (1,000,000 devices / km in urban environments) is preferably required. 2 ), wide coverage in harsh environments and extremely long battery life (15 years) for inexpensive devices.

[0290] Therefore, a set of OFDM parameters suitable for one use case (e.g., subcarrier spacing (SCS), OFDM symbol length, cyclic prefix (CP) length, number of symbols per scheduling interval) may be ineffective for other use cases. For example, in low-latency services, it is preferable to require a shorter symbol length than in mMTC services (therefore, a larger subcarrier spacing) and / or fewer symbols per scheduling interval (also known as "TTI"). Moreover, in extended scenarios with large channel delay spread, it is preferable to require a longer CP length than in scenarios with shorter delay spread. The subcarrier spacing can also be optimized depending on the situation to maintain the same CP overhead. NR supports more than one subcarrier spacing value. Correspondingly, subcarrier spacings of 15kHz, 30kHz, 60kHz... are currently considered. The symbol length Tu and the subcarrier spacing Δf are directly related according to the formula Δf = 1 / Tu. Similar to LTE systems, the term "resource element" can be used to refer to the smallest unit of resources consisting of a subcarrier of the length of one OFDM / SC-FDMA (Single-Carrier Frequency Division Multiple Access) symbol.

[0291] In the new 5G-NR wireless system, resource grids for subcarriers and OFDM symbols are defined in both the uplink and downlink for each parameter set and each carrier. Each element of the resource grid is called a "resource element," which is determined based on the frequency index in the frequency domain and the symbol position in the time domain (refer to 3GPP TS 38.211 v15.6.0).

[0292] <Functional Separation between NG-RAN and 5GC in 5G NR>

[0293] Figure 11 This indicates the functional separation between NG-RAN and 5GC. The logical node of NG-RAN is either gNB or ng-eNB. 5GC has logical nodes AMF, UPF, and SMF (Session Management Function).

[0294] For example, gNB and ng-eNB host the following main functions:

[0295] - Functions such as Radio Bearer Control, Radio Admission Control, Connection Mobility Control, and Radio Resource Management (RRM) that dynamically allocates (schedules) resources to the UE in both the uplink and downlink links;

[0296] - Data IP (Internet Protocol) header compression, encryption, and integrity protection;

[0297] - Selection of AMF when attaching a UE in situations where the route to the AMF cannot be determined based on the information provided by the UE;

[0298] - Routing to user plane data towards UPF;

[0299] - Routing of control plane information toward AMF;

[0300] - Establishment and termination of connections;

[0301] - Scheduling and sending paging messages;

[0302] - The scheduling and transmission of system broadcast information (originating from AMF or Operation, Admission, and Maintenance functions (OAM));

[0303] - Configuration of measurements and measurement reports for mobility and scheduling;

[0304] - Packet markings for transmission class in the uplink;

[0305] -Session management;

[0306] -Support for network slicing;

[0307] - QoS (Quality of Service) flow management and mapping to data radio bearers;

[0308] Support for UEs in RRC_INACTIVE (RRC inactive) state;

[0309] - NAS (Non-Access Stratum) message distribution function;

[0310] - Sharing of wireless access networks;

[0311] - Dual connectivity;

[0312] - Close collaboration between NR and E-UTRA (Evolved Universal Terrestrial Radio Access).

[0313] The Access and Mobility Management Function (AMF) administers the following main functions:

[0314] - Function to terminate Non-Access Stratum (NAS) signaling;

[0315] -Security of NAS signaling;

[0316] - Security controls at the access layer (AS);

[0317] - Core Network (CN) inter-node signaling for mobility between 3GPP access networks;

[0318] - Reachability of UEs in idle mode (including control and execution of paging retransmission);

[0319] - Management of the registered area;

[0320] - Support for intra-system mobility and inter-system mobility;

[0321] -Access authentication;

[0322] - Access licenses that include roaming permission checks;

[0323] - Mobility management controls (subscription and policies);

[0324] -Support for network slicing;

[0325] - Selection of Session Management Function (SMF).

[0326] In addition, the User Face Function (UPF) hosts the following main functions:

[0327] - Anchor points for intra-RAT (Radio Access Technology) mobility / inter-RAT (where applicable) mobility;

[0328] - External PDU (Protocol Data Unit) session points used for interconnection with data networks;

[0329] - Packet routing and forwarding;

[0330] - Enforcement of policy rules in group checks and user-facing aspects;

[0331] - Reports on business usage;

[0332] - Uplink classifier used to support routing of service flows toward the data network;

[0333] - Branching points used to support multi-homed PDU sessions;

[0334] - For user plane QoS processing (e.g., packet filtering, gating, UL / DL rate enforcement);

[0335] - Uplink service verification (SDF (Service Data Flow) mapping to QoS flow);

[0336] - Downlink packet buffering and downlink data notification triggering functions.

[0337] Finally, the Session Management Function (SMF) administers the following main functions:

[0338] -Session management;

[0339] - The allocation and management of UE IP addresses;

[0340] -Selection and control of UPF;

[0341] - Configuration features for traffic steering in the User Plane Function (UPF) to direct traffic to the appropriate destination;

[0342] - Enforcing policies and QoS in the control section;

[0343] - Notification of downlink data.

[0344] <The process of establishing and reconfiguring an RRC connection>

[0345] Figure 12 This refers to several interactions between the UE, gNB, and AMF (5GC entity) when the UE in the NAS part transitions from RRC_IDLE (RRC idle) to RRC_CONNECTED (RRC connected) (refer to TS 38.300 v15.6.0).

[0346] RRC is a higher-level signaling (protocol) used for UE and gNB configuration. Through this transition, the AMF prepares UE context data (which includes, 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. Next, the gNB and UE activate AS security together. The gNB sends a SecurityModeCommand message to the UE, and the UE responds to the gNB with a SecurityModeComplete message, thereby activating AS security. Then, the gNB sends an RRCReconfiguration message to the UE, and the gNB receives an RRCReconfigurationComplete message from the UE for this RRCReconfiguration message, thus performing reconfiguration for establishing Signaling Radio Bearer 2 (SRB2) and Data Radio Bearer (DRB). For signaling-only connections, since SRB2 and DRB are not established, the steps related to RRC reconfiguration can be omitted. Finally, the gNB notifies the AMF that the establishment process is complete using the Initial Context Setup Reply (INITIAL CONTEXT SETUP RESPONSE).

[0347] Therefore, this disclosure provides an entity (e.g., AMF, SMF, etc.) for a fifth-generation core network (5GC), comprising: a control circuit that, upon operation, establishes a Next Generation (NG) connection with the gNodeB; and a transmission unit that, upon operation, sends an initial context establishment message to the gNodeB via the NG connection to establish a signaling radio bearer between the gNodeB and the User Equipment (UE). Specifically, the gNodeB transmits Radio Resource Control (RRC) signaling containing Resource Allocation Configuration Information Elements (IEs) to the UE via the signaling radio bearer. The UE then performs uplink transmission or downlink reception based on the resource allocation configuration.

[0348] <Application Scenarios of IMT after 2020>

[0349] Figure 13 This section outlines several use cases for 5G NR. Within the 3rd Generation Partnership Project New Radio (3GPP NR), three use cases supporting a wide variety of services and applications, conceived through IMT-2020, have been studied. Planning for the first phase of specifications for enhanced mobile broadband (eMBB) has been completed. Current and future work, in addition to gradually expanding eMBB support, includes standardization for ultra-reliable and low-latency communications (URLLC) and massive machine-type communications (mMTC). Figure 13 Several examples illustrating conceptual application scenarios for IMT after 2020 (e.g., referring to ITU-R M.2083). Figure 2 ).

[0350] URLLC use cases have strict requirements related to performance such as throughput, latency, and availability. URLLC is conceived as a key technology for enabling wireless control of future industrial production or manufacturing processes, remote medical surgery, automation of power transmission and distribution in smart grids, and traffic safety applications. Ultra-high reliability of URLLC is supported by defining technologies that meet the requirements configured by TR38.913. In NR URLLC version 15, a crucial requirement is a target user plane latency of 0.5ms in the UL (uplink) and 0.5ms in the DL (downlink). For a single packet transmission, the overall requirement for URLLC is a block error rate (BLER) of 1E-5 for a 32-byte packet size with a user plane latency of 1ms.

[0351] Considering the physical layer, numerous methods are available to improve reliability. Current possibilities for reliability enhancement include defining additional CQI (Channel Quality Indicator) tables for URLLC, a more compact DCI format, and PDCCH iteration. However, as NR (a crucial prerequisite for NR URLLC) becomes more stable and is further developed, this scope can be expanded to achieve ultra-high reliability. Specific use cases for NR URLLC in version 15 include augmented reality / virtual reality (AR / VR), e-health, e-safety, and other critical applications.

[0352] Furthermore, the technical enhancements for NR URLLC aim to improve latency and reliability. Latency enhancements include configurable parameter sets, non-slot-based scheduling utilizing flexible mapping, unlicensed (configured licensed) uplinks, slot-level repetition in the data channel, and pre-emption in the downlink. Pre-emption refers to stopping a transmission with allocated resources and using those resources for a later-requested transmission that requires lower latency / higher priority. Therefore, a permitted transmission is replaced by a subsequent transmission. Pre-emption can be applied regardless of the specific service type. For example, a transmission in service type A (URLLC) can be replaced by a transmission in service type B (eMBB, etc.). Reliability enhancements include a dedicated CQI / MCS table for a target BLER of 1E-5.

[0353] The use cases for mMTC (massive machine-type communications) are characterized by a large number of connected devices that transmit relatively small amounts of data that are not easily affected by latency. These devices require low cost and very long battery life. From NR's perspective, utilizing very narrow bandwidth segments is a solution to save UE power and extend its battery life.

[0354] As mentioned above, the potential for improved reliability in NR is further expanded. It is one of the essential conditions for all situations; for example, high or ultra-high reliability is a crucial requirement related to URLLC and mMTC. From both wireless and network perspectives, reliability can be improved through several mechanisms. Generally, there are two to three important areas that could potentially contribute to improved reliability. These areas include compact control channel information, data / control channel iteration, and diversity related to the frequency, time, and / or spatial domains. These areas can be used universally to improve reliability, independent of specific communication scenarios.

[0355] Regarding NR URLLC, further use cases with more stringent requirements are envisioned, such as factory automation, transportation, and power transmission. Stricter requirements refer to high reliability (reaching level 10⁻⁶), high availability, a packet size of 256 bytes, and time synchronization of approximately several microseconds (μs) (capable of corresponding to use cases, with values ​​set to 1 μs or several microseconds depending on the frequency range and short latency of approximately 0.5ms to 1ms (e.g., 0.5ms latency in the target user plane)).

[0356] Furthermore, from a physical layer perspective, there are several technical enhancements related to NR URLLC. These enhancements include strengthening the PDCCH (Physical Downlink Control Channel) associated with compact DCI, PDCCH repetition, and increased PDCCH monitoring. Additionally, enhancements to UCI (Uplink Control Information) are related to enhanced HARQ (Hybrid Automatic Repeat Request) and CSI feedback. Furthermore, there may be enhancements to PUSCH and retransmission / repetition related to mini-slot-level frequency hopping. The term "mini-slot" refers to a transmission time interval (TTI) containing fewer symbols than a time slot (a time slot has 14 symbols).

[0357] <QoS Control>

[0358] 5G's QoS (Quality of Service) model is based on QoS flows, supporting both QoS flows that require guaranteed bit rate (GBR) and QoS flows that do not require guaranteed bit rate (non-GBR QoS flows). Therefore, at the NAS level, QoS flows represent the finest granular QoS classification within a PDU session. QoS flows are determined within a PDU session based on the QoS Flow ID (QFI) transmitted via the encapsulation header through the NG-U interface.

[0359] For each UE, 5GC establishes one or more PDU sessions. For each UE, in conjunction with the PDU session, NG-RAN, for example, refers to the previous text. Figure 12 As explained, at least one Data Radio Bearer (DRB) is established. Additionally, DRBs can be configured later for QoS flows added to this PDU session (when to configure depends on NG-RAN). NG-RAN maps packets belonging to various PDU sessions to various DRBs. NAS-level packet filters in the UE and 5GC are used to 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.

[0360] Figure 14 This refers to the non-roaming reference architecture of 5G NR (refer to TS 23.501 v16.1.0, section 4.23). Application Function (AF) (e.g., hosting...) Figure 13 The external application server for the illustrated 5G service interacts with the 3GPP core network to provide services. For example, it may access a Network Exposure Function (NEF) to support applications that impact service routing, or it may interact with a policy framework (see Policy Control Function (PCF)) for policy control (e.g., QoS control). Based on operator deployment, operators deem trusted application functions capable of directly interacting with associated network functions. Application functions not permitted by the operator to directly access network functions interact with associated network functions via the NEF, using an open framework accessible to the outside world.

[0361] Figure 14It also indicates further functional units of the 5G architecture, namely, the Network Slice Selection Function (NSSF), the Network Repository Function (NRF), Unified Data Management (UDM), the Authentication Server Function (AUSF), the Access and Mobility Management Function (AMF), the Session Management Function (SMF), and the Data Network (DN: Data Network, such as services provided by operators, internet access, or services provided by third parties). All or part of the core network's functions and application services can also be deployed and operate in a cloud computing environment.

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

[0363] The term “...department” as used in this disclosure may be interchanged with other terms such as “...circuitry”, “...device”, “...unit” or “...module”.

[0364] This disclosure can be implemented in software, hardware, or software in cooperation with hardware. The functional blocks used in the above embodiments are implemented partially or wholly as LSIs (Large Scale Integration), and the processes described in the above embodiments can also be controlled partially or wholly by a single LSI or a combination of LSIs. An LSI can be composed of individual chips, or it can be composed of a single chip containing some or all of the functional blocks. An LSI can also include data input and output. Depending on the degree of integration, an LSI can also be referred to as an "IC (Integrated Circuit)," "System LSI," "Super LSI," or "Ultra LSI."

[0365] The method of integrating the LSI is not limited to LSI; it can also be implemented using dedicated circuits, general-purpose processors, or special-purpose processors. Alternatively, it can utilize FPGAs (Field Programmable Gate Arrays) that are programmable after LSI fabrication, or reconfigurable processors that allow reconfiguration of the connections or configurations of the circuit blocks within the LSI. This disclosure can also be implemented for digital or analog processing.

[0366] Furthermore, if advancements in semiconductor technology or the emergence of other derivative technologies lead to integrated circuit technologies that can replace LSIs, these technologies could also be used to integrate functional blocks. There are also possibilities for applications such as biotechnology.

[0367] This disclosure can be implemented in all kinds of devices, apparatuses, and systems with communication capabilities (collectively referred to as "communication devices"). A communication device may also include a wireless transceiver and processing / control circuitry. The wireless transceiver may also include a receiving unit and a transmitting unit, or perform the functions of these units. The wireless transceiver (transmitting unit, receiving unit) may also include an RF (Radio Frequency) module and one or more antennas. The RF module may also include an amplifier, an RF modulator / demodulator, or similar devices. Non-limiting examples of communication devices include: telephones (mobile phones, smartphones, etc.), tablet computers, personal computers (PCs) (laptops, desktops, laptops, etc.), cameras (digital cameras, digital camcorders, etc.), digital players (digital audio / video players, etc.), wearable devices (wearable cameras, smartwatches, tracking devices, etc.), game consoles, e-book readers, remote health / telemedicine (remote healthcare / medical prescription) devices, vehicles or transportation vehicles with communication capabilities (cars, airplanes, ships, etc.), and combinations of the various devices described above.

[0368] Communication devices are not limited to portable or movable devices, but also include all kinds of devices, equipment, and systems that cannot be carried or fixed. Examples include: smart home devices (home appliances, lighting equipment, smart meters or meters, control panels, etc.), vending machines, and all other "things" that can exist on the IoT (Internet of Things) network.

[0369] In addition to data communication via cellular systems, wireless LAN (Local Area Network) systems, and communication satellite systems, communication also includes data communication via a combination of these systems.

[0370] In addition, the communication device also includes devices such as controllers or sensors that are connected or linked to a communication device performing the communication functions described in this disclosure. For example, it includes a controller or sensor that generates control signals or data signals used by the communication device to perform the communication functions of the communication device.

[0371] In addition, the communication device includes infrastructure equipment that communicates with or controls the various devices described above (not limited to these), such as base stations, access points, and all other devices, equipment, and systems.

[0372] A terminal according to an embodiment of this disclosure includes: a receiving circuit for receiving downlink control information, the downlink control information including information scrambled with a terminal-specific identifier and scheduling uplink signals independently of a terminal-specific configuration; and a transmitting circuit for repeatedly transmitting the uplink signals based on retransmission-related information of the uplink signals determined according to the downlink control information.

[0373] In one embodiment of this disclosure, the downlink control information includes a field that notifies information different from the duplicate transmission related information, and at least a portion of the field is allocated with the duplicate transmission related information. In another embodiment of this disclosure, the downlink control information is a first DCI format 0-0 that includes a field notifying the duplicate transmission related information, and the payload size of the first DCI format 0-0 differs from the payload size of a second DCI format 0-0 that does not include a field notifying the duplicate transmission related information.

[0374] In one embodiment of this disclosure, the receiving circuit performs blind decoding for multiple payload sizes corresponding to the first DCI format 0-0 and the second DCI format 0-0, respectively.

[0375] In one embodiment of this disclosure, the terminal is a terminal that requests the retransmission of the uplink signal, a terminal that has notified the base station of its ability to retransmit the uplink signal, or a terminal that has the ability to retransmit the uplink signal.

[0376] In one embodiment of this disclosure, the receiving circuit performs blind decoding for the plurality of payload sizes before being assigned a specific search space to the terminal.

[0377] In one embodiment of this disclosure, the identifier is a Radio Network Temporary Identifier (RNTI), and the downlink control information is a first DCI format 0-0 that notifies the retransmission related information. The RNTI corresponding to the first DCI format 0-0 is different from the RNTI corresponding to a second DCI format 0-0 that does not notify the retransmission related information.

[0378] In one embodiment of this disclosure, the receiving circuit performs blind decoding of a plurality of RNTIs corresponding to the first DCI format 0-0 and the second DCI format 0-0, respectively.

[0379] In one embodiment of this disclosure, the terminal is a terminal that requests the retransmission of the uplink signal, a terminal that has notified the base station of its ability to retransmit the uplink signal, or a terminal that has the ability to retransmit the uplink signal.

[0380] In one embodiment of this disclosure, the receiving circuit performs blind decoding of the plurality of RNTIs before being assigned a specific search space to the terminal.

[0381] In one embodiment of this disclosure, the function of repeated transmission is the same between the uplink signal scheduled by the downlink control information received by the terminal before the terminal-specific configuration is completed and the uplink signal scheduled by the downlink control information received by the terminal after the terminal-specific configuration is completed.

[0382] In one embodiment of this disclosure, the function for repeated transmission differs between the uplink signal scheduled by the downlink control information received by the terminal before the terminal-specific configuration is completed and the uplink signal scheduled by the downlink control information received by the terminal after the terminal-specific configuration is completed.

[0383] A base station according to an embodiment of this disclosure includes: a transmitting circuit for transmitting downlink control information, the downlink control information including information scrambled with a terminal-specific identifier and scheduling uplink signals independently of a terminal-specific configuration; and a receiving circuit for receiving retransmission of the uplink signals based on retransmission-related information of the uplink signals determined according to the downlink control information.

[0384] In a communication method according to an embodiment of this disclosure, a terminal performs the following steps: receiving downlink control information, the downlink control information including information scrambled with a terminal-specific identifier and scheduling uplink signals independently of a terminal-specific configuration; and repeating the uplink signals based on retransmission-related information of the uplink signals determined according to the downlink control information.

[0385] In a communication method according to an embodiment of this disclosure, a base station performs the following steps: sending downlink control information, the downlink control information including information scrambled with a terminal-specific identifier and scheduling uplink signals independently of a terminal-specific configuration; and receiving retransmission of the uplink signal based on retransmission-related information of the uplink signal determined according to the downlink control information.

[0386] The entire contents of the description, drawings and abstract of the description contained in Japanese Patent Application No. 2023-201637, filed on November 29, 2023, are incorporated herein by reference.

[0387] Industrial applicability

[0388] One embodiment of this disclosure is useful for wireless communication systems.

[0389] Explanation of reference numerals in the attached figures

[0390] 100 base stations

[0391] 101, 205 Control Department

[0392] 102 High-rise control signal generation unit

[0393] 103 Downlink Control Information Generation Unit

[0394] Coding sections 104 and 206

[0395] Modulation sections 105 and 207

[0396] Signal Distribution Sections 106 and 208

[0397] 107, 209 Sending Department

[0398] Receiving Departments 108 and 201

[0399] Extraction sections 109 and 202

[0400] 110, 203 De-escalation Department

[0401] Decoding sections 111 and 204

[0402] 200 terminals

Claims

1. A terminal, characterized in that, have: The receiving circuit receives downlink control information, which includes information scrambled with a terminal-specific identifier and schedules uplink signals independently of a terminal-specific configuration. as well as The transmitting circuit performs repeated transmission of the uplink signal based on the uplink signal retransmission information determined according to the downlink control information.

2. The terminal as described in claim 1, wherein, The downlink control information includes fields that provide information different from the information related to repeated transmission. At least a portion of the field contains information related to repeated transmission.

3. The terminal as described in claim 1, wherein, The downlink control information is a first DCI format 0-0 containing fields that notify of information related to repeated transmissions. The payload size of the first DCI format 0-0 is different from the payload size of the second DCI format 0-0, which does not contain a field that notifies the retransmission of related information.

4. The terminal as described in claim 3, wherein, The receiving circuit performs blind decoding for multiple payload sizes corresponding to the first DCI format 0-0 and the second DCI format 0-0, respectively.

5. The terminal as described in claim 4, wherein, The terminal is a terminal that requests the retransmission of the uplink signal, a terminal that has notified the base station of its ability to retransmit the uplink signal, or a terminal that has the ability to retransmit the uplink signal.

6. The terminal as described in claim 4, wherein, The receiving circuit performs blind decoding on the plurality of payload sizes before being assigned a specific search space to the terminal.

7. The terminal as claimed in claim 1, wherein, The identifier is a wireless network temporary identifier, i.e., RNTI. The downlink control information is a first DCI format 0-0 that notifies the repeated transmission of relevant information. The RNTI corresponding to the first DCI format 0-0 is different from the RNTI corresponding to the second DCI format 0-0 that does not notify of information related to repeated transmission.

8. The terminal as described in claim 7, wherein, The receiving circuit performs blind decoding on multiple RNTIs corresponding to the first DCI format 0-0 and the second DCI format 0-0, respectively.

9. The terminal as described in claim 8, wherein, The terminal is a terminal that requests the retransmission of the uplink signal, a terminal that has notified the base station of its ability to retransmit the uplink signal, or a terminal that has the ability to retransmit the uplink signal.

10. The terminal as claimed in claim 8, wherein, The receiving circuit performs blind decoding on the plurality of RNTIs before being assigned a specific search space to the terminal.

11. The terminal as claimed in claim 1, wherein, The function of repeated transmission is the same between the uplink signal scheduled by the downlink control information received by the terminal before the terminal-specific configuration is completed and the uplink signal scheduled by the downlink control information received by the terminal after the terminal-specific configuration is completed.

12. The terminal as claimed in claim 1, wherein, The function of repeated transmission differs between the uplink signal scheduled by the downlink control information received by the terminal before the terminal-specific configuration is completed and the uplink signal scheduled by the downlink control information received by the terminal after the terminal-specific configuration is completed.

13. A base station, characterized in that, have: The transmitting circuit transmits downlink control information, which includes information scrambled with a terminal-specific identifier and schedules uplink signals independently of a terminal-specific configuration. as well as The receiving circuit receives the repeated transmission of the uplink signal based on the uplink signal retransmission information determined according to the downlink control information.

14. A communication method, characterized in that, The terminal performs the following steps: Receive downlink control information, which contains information scrambled with a terminal-specific identifier and schedules uplink signals independently of a terminal-specific configuration. as well as The uplink signal is repeatedly transmitted based on the uplink signal retransmission information determined according to the downlink control information.

15. A communication method, characterized in that, The base station performs the following steps: Send downlink control information, which includes information scrambled with a terminal-specific identifier and schedules uplink signals independently of a terminal-specific configuration. as well as The uplink signal retransmission is received based on the uplink control information determined according to the downlink control information.

Images