Terminals, communication methods, and integrated circuits

By coordinating CP lengths and extension amounts, the method optimizes UE-initiated COT scheduling in unlicensed bands, addressing inefficiencies and enhancing transmission efficiency and fairness.

JP7862648B2Active Publication Date: 2026-05-19PANASONIC INTELLECTUAL PROPERTY CORP OF AMERICA
View PDF 4 Cites 0 Cited by

Patent Information

Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
PANASONIC INTELLECTUAL PROPERTY CORP OF AMERICA
Filing Date
2025-06-19
Publication Date
2026-05-19

AI Technical Summary

Technical Problem

Existing communication methods in unlicensed bandwidth, particularly in UE-initiated COT scheduling for Frame-based equipment (FBE), suffer from inefficiencies such as increased transmission delay and resource underutilization due to idle periods and potential collisions.

Method used

A base station determines a coordinated cyclic prefix (CP) length with terminals, adjusting CP extension amounts to optimize transmission start timings and prioritize COT acquisition, thereby improving scheduling flexibility and reducing collisions.

Benefits of technology

Enhances transmission efficiency in unlicensed frequency bands by minimizing idle periods and collisions, ensuring fair priority allocation among terminals, and reducing overall transmission delay.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007862648000001
    Figure 0007862648000001
  • Figure 0007862648000002
    Figure 0007862648000002
  • Figure 0007862648000003
    Figure 0007862648000003
Patent Text Reader

Abstract

To improve transmission efficiency in unlicensed bands.SOLUTION: A terminal includes a receiving circuit that receives control information regarding a cyclic prefix (CP) length from a base station, and a control circuit that controls uplink transmission based on the CP length. The CP length differs when information indicating a channel occupation time for the terminal is a first value and when it is a second value different from the first value.SELECTED DRAWING: Figure 7
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

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

Background Art

[0002] In the 3rd Generation Partnership Project (3GPP), as an extension of the functions of the 5th Generation mobile communication system (5G), the specification of the physical layer of Release 16 NR (New Radio access technology) has been completed. In NR, in addition to the advancement of mobile broadband (eMBB: enhanced Mobile Broadband) to meet the requirements such as high speed and large capacity, it supports a function to realize ultra-reliable and low-latency communication (URLLC: Ultra Reliable and Low Latency Communication) (for example, see Non-Patent Documents 1-5).

Prior Art Documents

Non-Patent Documents

[0003]

Non-Patent Document 1

Non-Patent Document 2

Non-Patent Document 3

Non-Patent Document 4

[0004] However, there is room for consideration regarding communication methods in unlicensed bandwidth.

[0005] Non-limiting embodiments of this disclosure contribute to the provision of base stations, terminals, and communication methods that can improve transmission efficiency in unlicensed bandwidth. [Means for solving the problem]

[0006] A base station according to one embodiment of the present disclosure comprises a control circuit for determining a coordinated cyclic prefix (CP) length between a terminal and the base station, and a transmission circuit for transmitting control information relating to the determined CP length to the terminal.

[0007] These comprehensive or specific embodiments may be implemented as systems, devices, methods, integrated circuits, computer programs, or recording media, or as any combination of systems, devices, methods, integrated circuits, computer programs, and recording media. [Effects of the Invention]

[0008] According to one embodiment of the present disclosure, transmission efficiency in the unlicensed bandwidth can be improved.

[0009] Further advantages and effects of one embodiment of this disclosure will be made apparent from the specification and drawings. Such advantages and / or effects are provided by several embodiments and features described in the specification and drawings, but not all of them are necessarily provided in order to obtain one or more identical features. [Brief explanation of the drawing]

[0010] [Figure 1] This diagram shows an example of channel access using Frame Based Equipment (FBE). [Figure 2] A diagram showing an example of a CP extension for multiple transmission timings. [Figure 3] A diagram showing an example of CP extension amount for gap adjustment. [Figure 4] Block diagram showing some example configurations of base stations. [Figure 5] Block diagram showing some example configurations of the terminal. [Figure 6] Block diagram showing an example of a base station configuration. [Figure 7] Block diagram showing an example of terminal configuration [Figure 8] Sequence diagram showing an example of base station and terminal operation. [Figure 9] A diagram showing an example of COT acquisition control in FBE according to Embodiment 1. [Figure 10] Figure showing an example of setting the CP extension amount according to Embodiment 2. [Figure 11] Figure showing an example of setting the CP extension amount according to Embodiment 2. [Figure 12] This figure shows an example of setting the CP extension amount according to Embodiment 3. [Figure 13] This figure shows an example of setting the CP extension amount according to Embodiment 3. [Figure 14] This figure shows an example of setting the CP extension amount according to Embodiment 4. [Figure 15] Diagram of a representative architecture of a 3GPP NR system [Figure 16] Schematic diagram showing the functional separation between NG-RAN (Next Generation - Radio Access Network) and 5GC (5th Generation Core) [Figure 17] Sequence diagram of the procedure for setting up / resetting a Radio Resource Control (RRC) connection [Figure 18] Schematic diagram showing usage scenarios of enhanced Mobile BroadBand (eMBB), massive Machine Type Communications (mMTC), and Ultra Reliable and Low Latency Communications (URLLC) [Figure 19] Block diagram showing an exemplary 5G system architecture for a non - roaming scenario

Embodiments for Carrying Out the Invention

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

[0012] [Unlicensed Frequency Band] In Release 16 NR, for example, the introduction of NR - Unlicensed (also referred to as NR - U), which performs communication based on the NR radio access method in an unlicensed frequency band (or also called an unlicensed band), is being considered.

[0013] In an unlicensed frequency band, for example, each device performs carrier sense (also referred to as Listen Before Talk (LBT)), which checks whether another system or terminal, etc. is using the radio channel before transmission.

[0014] Furthermore, Release 17 NR will consider extensions to enable the operation of, for example, ultra-reliable and low-latency communications (URLLC) services in unlicensed frequency bands. One of the extensions will consider is support for UE-initiated COT (e.g., UE-initiated COT) in Frame-based equipment (FBE), a channel access method, where terminals (also called User Equipment (UE)) acquire channel occupancy time (e.g., COT). FBE is also known as semi-static channel occupancy.

[0015] However, scheduling methods in UE-initiated COT have not been sufficiently considered.

[0016] Figure 1 shows an example of channel access using FBE. In Release 16 NR-U FBE, for example, as shown in Figure 1, a base station (also called a gNB) may acquire the COT by performing an LBT (e.g., Category 2 LBT) at the beginning of a period called a Fixed Frame Period (FFP). A terminal may acquire the COT by performing a Category 2 or Category 1 LBT within the base station's COT (e.g., also called a gNB COT).

[0017] Unlike FBE, Load Based Equipment (LBE), another channel access method, allows for attempts to acquire COT at any given time. On the other hand, LBE may perform Category 4 LBT, which may have a longer LBT period compared to Category 1 or Category 2.

[0018] Thus, FBE allows for COT acquisition in a shorter LBT period compared to LBE, for example. On the other hand, FBE includes an "idle period" during which both the base station and the terminal are unable to transmit (for example, a period during which COT cannot be acquired), as shown in Figure 1.

[0019] [Configured grant submission] This document describes the Configured grant transmissions supported in Release 15 NR (for example, Configured grant transmissions in the license frequency band).

[0020] For configured grant transmission of uplink data (e.g., PUSCH: Physical Uplink Shared Channel), there are, for example, "Configured grant type 1 transmission" and "Configured grant type 2 transmission".

[0021] In a Configured Grant type 1 transmission, information such as the Modulation and Coding Scheme (MCS), radio resource allocation (e.g., allocation of at least one time resource and frequency resource), transmission timing, and the number of Hybrid Automatic Repeat Request (HARQ) processes (e.g., referred to as Configured Grant setting information or CG setting information) may be set (in other words, notified or instructed) to the terminal by terminal-specific higher-layer signals. For example, when uplink data is generated, the terminal may transmit uplink data (e.g., PUSCH) based on the pre-configured CG setting information such as the MCS and radio resources, without a UL grant (e.g., dynamic uplink data scheduling information) from the base station via a downlink control channel (e.g., PDCCH).

[0022] The higher-layer signals are sometimes referred to as, for example, Radio Resource Control (RRC) signals, higher layer signaling, or higher layer parameters.

[0023] Furthermore, in Configured grant type 2 transmission, for example, the Configured grant transmission is activated or released by a PDCCH from the base station. In Configured grant type 2 transmission, information such as transmission timing and the number of HARQ processes may be set by terminal-specific upper-layer signals, similar to Configure grant type 1 transmission. On the other hand, in Configured grant type 2 transmission, information such as MCS and radio resource allocation information may be set by Downlink Control Information (DCI) for activation. For example, when uplink data is generated, the terminal may transmit uplink data (e.g., PUSCH) using CG setting information such as MCS and radio resources set by upper-layer signals and Activation DCI semi-permanently (in other words, statically or semi-statically) (in other words, without UL grant, or UL grant free).

[0024] Furthermore, in Release 15 NR, for example, UL grant is used for retransmission control of configured grant transmissions. For example, UL grant may control the MCS and radio resource allocation information of the uplink data for retransmission.

[0025] Furthermore, the HARQ process number (or HARQ process ID) used in configured grant transmission may, as an unrestricted example, be uniquely determined from the slot number from which the PUSCH is transmitted (in other words, the timing of the PUSCH transmission). For example, a PUSCH transmitted in configured grant transmission may be treated the same as the initial transmission signal, and its Redundancy Version (RV) may be 0.

[0026] [Configured grant transmission in unlicensed frequency bands] In configured grant transmissions in NR-U (NR in unlicensed frequency bands), some of the parameters used to decode PUSCH, such as the HARQ process number, New Data Indicator (NDI), and RV (for example, parameters related to retransmission control), may be notified from the terminal to the base station by uplink control information for configured grant transmissions (for example, called CG-UCI: Configured grant Uplink Control Information).

[0027] CG-UCI may be transmitted at the same transmission timing (e.g., the same slot) as PUSCH (or sometimes called CG-PUSCH), for example, using a portion of the radio resources allocated to PUSCH. In other words, CG-UCI may be multiplexed with CG-PUSCH.

[0028] The reason for explicitly notifying the HARQ process number using CG-UCI in NR-U is as follows: For example, in NR-U, a PUSCH may not be transmitted depending on the LBT result. Therefore, if the HARQ process number is determined by linking it to the transmission timing of a PUSCH, as in the license frequency band, the HARQ process may not be able to be used flexibly depending on whether or not the PUSCH is actually transmitted. Thus, the HARQ process number may be notified using CG-UCI, which is transmitted together with the CG-PUSCH.

[0029] Furthermore, NR-U supports the operation where, for example, upon receipt of a NACK or timer expiration, the terminal retransmits using the radio resources configured for configured grant without UL grant. In this case, for example, information indicating the status of the initial transmission or retransmission (e.g., NDI) and the RV to be applied to the PUSCH during retransmission may be transmitted by CG-UCI.

[0030] In NR-U, for example, HARQ-ACK feedback for CG-PUSCH may be explicitly notified from the base station to the terminal by information called a Downlink Feedback Indicator (DFI). For example, the HARQ process number is notified to CG-PUSCH by CG-UCI. Therefore, if the base station fails to receive CG-UCI, it may not be able to identify which HARQ process's data was transmitted, and thus may not be able to specify the HARQ process and instruct the base station to retransmit PUSCH. In this case, the base station may notify (in other words, provide feedback) HARQ-ACK feedback information for all HARQ processes. Furthermore, the base station can reduce the overhead caused by LBT and improve the efficiency of retransmission control by, for example, feeding back HARQ-ACK feedback information for multiple PUSCHs to the terminal all at once.

[0031] In DFI-based retransmission control, the MCS and radio resource allocation for the retransmission PUSCH may be the same as those used for the initial transmission. Furthermore, DFI may be transmitted, for example, on the PDCCH. In addition, DFI may include other parameters besides HARQ-ACK, such as Transmission Power Control (TPC) commands.

[0032] [CP extension in CG-PUSCH] In CG-PUSCH transmission, for example, even if transmission resources are allocated to a terminal, if the terminal does not have any data to transmit, PUSCH transmission will not occur. If PUSCH transmission does not occur, the resources allocated to the terminal will not be used, which may reduce the efficiency of resource utilization.

[0033] Therefore, methods were considered to involve assigning multiple terminals to the same CG resource and sharing the resource. In resource sharing by multiple terminals, if multiple terminals transmit simultaneously on the shared resource, collisions may occur, potentially preventing the base station from correctly receiving signals from each terminal. To avoid collisions, a mechanism was introduced that uses "CP extension" to set different transmission start timings for each terminal.

[0034] In the following, the CP extension used to set different transmission start timings for each terminal will be referred to as the "CP extension for multiple transmission timings."

[0035] Figure 2 shows an example of a CP extension for multiple transmission timings. In the example shown in Figure 2, the CP extension for initiating the transmission of PUSCH (e.g., a useful symbol) in Symbol N is shown. Also, in Figure 2, as an example, the subcarrier spacing (SCS) is 15 kHz, and T shown in Figure 2 may correspond to one symbol. As shown in Figure 2, by setting different CP extension amounts (also called extension amount, CP extension length, or CP length) such as "T-16us", "T-25us", ... "T-61us", or "0us" for each terminal, the transmission start timing may differ between terminals.

[0036] For example, consider a scenario where another terminal (e.g., terminal B) has a transmission start timing set later than that of another terminal (e.g., terminal A) (e.g., terminal B has a smaller extension amount than terminal A). In this case, if terminal A starts transmitting before terminal B, terminal B will perform carrier sensing (e.g., LBT), the channel will become busy, and terminal B will not start transmitting.

[0037] Thus, with CP extensions for multiple transmission timings, setting different CP extension amounts for each terminal can suppress transmission collisions (in other words, interference) between terminals.

[0038] [CP extension in Dynamic Grant (DG)-PUSCH] For unlicensed band channel access, the gap since the last transmission (e.g., the period without transmission) may be set to a specified length (or less) depending on the LBT type (e.g., category). For example, the gap since the last transmission may be set to 16us or 25us.

[0039] Therefore, in DG-PUSCH, for example, UL grant may be used to set the CP extension amount to adjust the gap with the previous transmission.

[0040] In the following, the CP extension used for adjusting the gap with the previous transmission will be referred to as the "gap adjustment CP extension."

[0041] In gap adjustment CP extension, the amount of CP extension may be set together with the Channel Access Type (also called LBT Type) and the Channel access priority type (CAPC) in DCI format 0_1 ​​(for example, by joint encoding).

[0042] Figure 3 shows an example of a CP extension amount (or candidate CP extension amount) that can be set for gap adjustment. In Figure 3, C1 is a value set based on the subcarrier interval (SCS), and C2 and C3 are values ​​set by upper-layer signaling. TA indicates timing alignment. The transmission timing of PUSCH at the terminal may be set TA earlier than the terminal's reception timing in order to match the base station's transmission and reception timing. On the other hand, since gap adjustment is performed based on the terminal's transmission and reception timing (for example, to adjust the period from when the terminal receives until it transmits), TA may be included in the gap adjustment CP extension to subtract the effect of TA. Thus, the gap adjustment CP extension may include a candidate CP extension amount with the effect of TA subtracted (in other words, a CP extension amount calculated based on TA). However, for example, when transmitting immediately following an uplink transmission, TA is not subtracted during gap adjustment, so not all candidate CP extension amounts need to be calculated based on TA.

[0043] For example, a terminal may perform a CP extension in response to a notification of a gap adjustment CP extension before sending a PUSCH.

[0044] [UE-initiated COT scheduling] When UE-initiated COTs are scheduled semi-statically (in other words, when an FFP for acquiring a COT is semi-statically assigned to a terminal), the transmission delay time of the base station (or terminal) may increase. For example, if a COT acquisition (in other words, transmission start) is set at the beginning of a certain FFP for terminal A, and terminal A has no data to transmit, then even if another terminal B (or base station) has data to transmit (provided that terminal B does not have a COT acquisition set in that FFP), terminal A can transmit, but terminal B cannot, which may increase terminal B's delay time.

[0045] Furthermore, with FBE, COT acquisition is possible at the beginning of the FFP, and the timing of COT acquisition does not need to be set at a different time than the beginning of the FFP (see, for example, ETSI EN 301 893). Therefore, even if there is no transmission data at the beginning of the FFP, if transmission may occur at the terminal partway through the FFP, it is expected that COT acquisition will be performed at the beginning of the FFP.

[0046] Thus, based on the fact that the COT acquisition timing is at the beginning of the FFP (for example, constraints on COT acquisition), a UE-initiated COT scheduling method is expected for terminals with data to acquire COT.

[0047] Therefore, in one embodiment of this disclosure, a method for improving transmission efficiency when UE-initiated COT scheduling is performed in an unlicensed frequency band will be described.

[0048] (Embodiment 1) [Overview of the communication system] A communication system according to one aspect of this disclosure may include, for example, a base station 100 (e.g., gNB) shown in Figures 4 and 6, and a terminal 200 (e.g., UE) shown in Figures 5 and 7. Multiple base stations 100 and terminals 200 may exist in the communication system.

[0049] Figure 4 is a block diagram showing a partial configuration example of a base station 100 according to one aspect of the present disclosure. In the base station 100 shown in Figure 4, the scheduling unit 104 (corresponding to, for example, a control circuit) determines a coordinated CP length (e.g., CP extension amount) between the terminal 200 and the base station 100. The transmission unit 109 (corresponding to, for example, a transmission circuit) transmits control information (e.g., CP extension setting information) regarding the determined CP length to the terminal 200.

[0050] Figure 5 is a block diagram showing a partial configuration example of a terminal 200 according to one aspect of the present disclosure. In the terminal 200 shown in Figure 5, the receiving unit 201 (corresponding to, for example, a receiving circuit) receives control information (for example, CP extension setting information) regarding the coordinated CP length between the terminal 200 and the base station 100. The transmission control unit 204 (corresponding to, for example, a control circuit) controls the transmission of the uplink (for example, COT acquisition timing or transmission start timing) based on the CP length.

[0051] [Base station configuration] Figure 6 is a block diagram showing an example configuration of a base station 100 according to one aspect of the present disclosure. In Figure 6, the base station 100 includes a receiving unit 101, a demodulation / decoding unit 102, a carrier sense unit 103, a scheduling unit 104, a control information holding unit 105, a data / control information generation unit 106, an encoding / modulation unit 107, a Cyclic Prefix (CP) addition unit 108, and a transmission unit 109.

[0052] The receiving unit 101 performs reception processing, such as down-conversion or A / D conversion, on the received signal received via the antenna, and outputs the processed received signal to the demodulation / decoding unit 102 and the carrier sense unit 103. The received signal may include, for example, a signal transmitted from the terminal 200 (e.g., an uplink signal) or a signal from another system.

[0053] The demodulation / decoding unit 102 demodulates and decodes the received signal (e.g., an uplink signal) input from the receiving unit 101, and outputs the decoding result to the scheduling unit 104.

[0054] The carrier sense unit 103 may perform carrier sensing (e.g., LBT) based on the received signal input from the receiver unit 101. For example, the carrier sense unit 103 may determine whether the channel state is "busy" or "idle" (in other words, whether the channel is usable or not) based on the received signal input from the receiver unit 101. The carrier sense unit 103 outputs information indicating the determined channel state to the scheduling unit 104.

[0055] The scheduling unit 104 determines, for example, CP extension setting information for terminal 200 (which may include, for example, the CP extension amount), Configured grant (CG) setting information, or FBE setting information (which may include, for example, the FFP period or timing), and outputs the determined CP extension setting information, CG setting information, or FBE setting information to the control information holding unit 105.

[0056] Furthermore, the scheduling unit 104 may, for example, instruct the data / control information generation unit 106 to generate data or control information based on the decoding result input from the demodulation / decoding unit 102. Also, when transmitting signaling information including CP extension setting information, CG setting information, or FBE setting information, the scheduling unit 104 may instruct the data / control information generation unit 106 to generate signaling information. In addition, the scheduling unit 104 may, for example, output information regarding the amount of CP extension during downlink transmission to the CP addition unit 108. Furthermore, the scheduling unit 104 may, for example, determine whether or not to transmit based on channel status information input from the carrier sense unit 103, and output a transmission instruction to the transmission unit 109 based on the determination result.

[0057] The control information holding unit 105 holds control information such as CP extension setting information or CG setting information for each terminal 200. The control information holding unit 105 may output the held information to each component of the base station 100 (for example, the scheduling unit 104) as needed.

[0058] The data / control information generation unit 106 generates data or control information in accordance with instructions from, for example, the scheduling unit 104, and outputs a signal containing the generated data or control information to the encoding / modulation unit 107. For example, the data / control information generation unit 106 may generate data containing signaling information based on a signaling information generation instruction input from the scheduling unit 104, and output the generated data to the encoding / modulation unit 107.

[0059] The encoding and modulation unit 107 encodes and modulates the signal input from, for example, the data and control information generation unit 106, and outputs the modulated transmission signal (for example, a time-domain signal) to the CP addition unit 108.

[0060] The CP addition unit 108 adds CP to the time-domain signal input from the encoding / modulation unit 107 based on the amount of CP extension input from the scheduling unit 104, for example, and outputs the signal with added CP to the transmission unit 109.

[0061] The transmitting unit 109 performs transmission processing such as D / A conversion, upconversion, or amplification on the signal input from the CP addition unit 108. The transmitting unit 109 also transmits the radio signal obtained through the transmission processing from the antenna to the terminal 200, based on a transmission instruction from the scheduling unit 104.

[0062] [Device Configuration] Figure 7 is a block diagram showing an example configuration of a terminal 200 according to one aspect of the present disclosure. In Figure 7, the terminal 200 includes a receiving unit 201, a demodulation / decoding unit 202, a carrier sense unit 203, a transmission control unit 204, a control information holding unit 205, a data / control information generation unit 206, an encoding / modulation unit 207, a CP addition unit 208, and a transmission unit 209.

[0063] The receiving unit 201 performs reception processing, such as down-conversion or A / D conversion, on the received signal received via the antenna, and outputs the processed received signal to the demodulation / decoding unit 202 and the carrier sense unit 203. The received signal may include, for example, a signal transmitted from the base station 100 (e.g., a downlink signal) or a signal from another system.

[0064] The demodulation / decoding unit 202 demodulates and decodes the received signal (e.g., downlink signal) input from the receiving unit 201, and outputs the decoded result to the transmission control unit 204. The decoded result may include, for example, downlink control information (e.g., UL grant, slot format information, or COT information).

[0065] The carrier sense unit 203 may perform carrier sensing (or LBT) based on the received signal input from the receiver unit 201, for example. For example, the carrier sense unit 203 may determine whether the channel state is "busy" or "idle" (in other words, whether the channel is available or not) based on the received signal input from the receiver unit 201. The carrier sense unit 203 outputs information indicating the determined channel state to the transmission control unit 204.

[0066] The transmission control unit 204 outputs signaling information (e.g., CP extension setting information, CG setting information, or FBE setting information) included in the decoding result input from the demodulation / decoding unit 202 to the control information holding unit 205. The transmission control unit 204 may also instruct the data / control information generation unit 206 to generate data or control information based on control information such as CG setting information input from the control information holding unit 205, or downlink control information input from the demodulation / decoding unit 202. The transmission control unit 204 may also determine the amount of CP extension during uplink transmission based on the CP extension setting information and output information regarding the amount of CP extension to the CP addition unit 208. The transmission control unit 204 may also determine whether or not to transmit based on channel status information input from the carrier sense unit 203, and output a transmission instruction to the transmission unit 209 based on the determination result.

[0067] The control information holding unit 205 holds control information such as signaling information (e.g., CP extension setting information or CG setting information) input from the transmission control unit 204, and outputs the held information to each component (e.g., the transmission control unit 204) as needed.

[0068] The data / control information generation unit 206 generates data or control information according to instructions from, for example, the transmission control unit 204, and outputs a signal containing the generated data or control information to the encoding / modulation unit 207.

[0069] The encoding and modulation unit 207 encodes and modulates the signal input from, for example, the data and control information generation unit 206, and outputs the modulated transmission signal (for example, a time-domain signal) to the CP addition unit 208.

[0070] The CP addition unit 208 adds CP to the time-domain signal input from the encoding / modulation unit 207 based on the amount of CP extension input from the transmission control unit 204, for example, and outputs the signal with added CP to the transmission unit 209.

[0071] The transmitting unit 209 performs transmission processing such as D / A conversion, upconversion, or amplification on the signal input from the CP addition unit 208. The transmitting unit 209 also transmits the radio signal obtained through the transmission processing from the antenna to the base station 100, based on a transmission instruction from the transmission control unit 204.

[0072] [Operation of base station 100 and terminal 200] An example of operation in a base station 100 and terminal 200 having the above configuration will be described.

[0073] Figure 6 is a sequence diagram showing an example of the operation of the base station 100 and the terminal 200.

[0074] The base station 100 determines, for example, the CP extension setting for the terminal 200 (S101). The CP extension setting may include, for example, information about the amount of CP extension (e.g., CP length) to be set for the terminal 200.

[0075] The base station 100 transmits control information to the terminal 200 (S102). The control information may include, for example, at least CP extension setting information. The CP extension setting information may be notified to the terminal 200 by, for example, a higher layer signal (e.g., an RRC signal) and at least one of DCI. For example, the CP extension setting information may be set to the terminal 200 by a higher layer signal and dynamically notified to the terminal 200 by DCI. Alternatively, the CP extension setting information may be set to the terminal 200 by a higher layer signal, and a DCI including a control value (or index) corresponding to any of the candidate CP extension amounts may be notified to the terminal 200.

[0076] Terminal 200 may, for example, perform carrier sensing (e.g., LBT) (S103). Terminal 200 may, for example, set a CP extension for the uplink signal based on CP extension setting information. Then, terminal 200 may perform carrier sensing at the transmission start timing corresponding to the CP extension.

[0077] Terminal 200 may, for example, transmit an uplink signal if the result of carrier sensing for a channel is idle (S104).

[0078] [COT acquisition control method] An example of a control method for acquiring COT at a base station 100 (for example, a scheduling unit 104) will be described. A terminal 200 (for example, a transmission control unit 204) may, for example, control COT acquisition and uplink transmission (for example, PUSCH transmission) based on control by the base station 100.

[0079] In this embodiment, for example, the FFP cycle and duration may be common to both the base station 100 and the terminal 200. Also, in this embodiment, for example, a period during which CP extension is possible may be set before the beginning of the FFP (for example, immediately before the beginning of the FFP). Note that the period during which CP extension can be set is not limited to the period before the beginning of the FFP, but may also be the period after the beginning of the FFP (for example, immediately after the beginning of the FFP), or the period including the beginning of the FFP (for example, a period spanning multiple FFPs).

[0080] Figure 9 shows an example where the CP extension setting period is set immediately before the start of the FFP. Note that the idle period may be set to a length greater than or equal to a specified length (for example, 5% or more of the FFP, or 100 us or more) if the CP extension setting period described above is set.

[0081] For example, the base station 100 may set a CP extension amount for each terminal 200 that may transmit during the CP extension setting period, and notify the terminal 200 of CP extension setting information indicating the CP extension amount. The transmission start timing for each terminal 200 may be determined according to the CP extension amount set by the base station 100.

[0082] When terminal 200 transmits, it may wait until the transmission start timing based on, for example, the CP extension amount instructed by base station 100, and start transmitting if the channel is idle as a result of carrier sensing. For example, the terminal that acquires COT in each FFP (for example, the terminal that first acquires COT) may be the terminal 200 that started transmitting. If multiplex transmission in the frequency domain or spatial domain is possible, multiple terminals 200 may start transmitting within the FFP. In other words, there may be multiple terminals 200 that acquire COT in each FFP.

[0083] Furthermore, in a given FFP, if, after the terminal 200 has completed its transmission, there is remaining transmission time within the FFP excluding the idle period, the base station 100 may perform a downlink transmission after the terminal 200 has completed its transmission.

[0084] Furthermore, for example, if base station 100 performs COT acquisition and downlink transmission at the beginning of the FFP, the CP extension amount and transmission start timing may be determined based on the priority of base station 100's transmission compared with terminal 200's transmission, or based on the transmission status of terminal 200.

[0085] For example, if transmission from base station 100 is prioritized over transmission from terminal 200, base station 100 may be given a higher CP extension amount than terminal 200. By setting this CP extension amount, for example, base station 100 can start transmitting earlier than terminal 200, making it easier for base station 100 to acquire COT and enabling transmission with higher priority than terminal 200.

[0086] Furthermore, for example, if no terminal 200 transmits at the beginning of a certain FFP (or if even the terminal 200 with the shortest CP extension among the terminals 200 that can transmit in that FFP does not start transmitting), the base station 100 may start transmitting and obtain COT. This makes it possible to suppress situations where, for example, no terminal 200 or base station 100 transmits in an FFP (in other words, situations where the FFP is not used), and improve the transmission efficiency of the unlicensed frequency band.

[0087] Thus, the base station 100 may determine a coordinated CP extension amount (for example, a CP extension amount for multiple transmission timings) between the terminal 200 and the base station 100. Furthermore, the terminal 200 may control uplink transmission based on CP extension setting information (for example, a CP extension amount for multiple transmission timings) notified by the base station 100.

[0088] For example, by setting the CP extension amount, priority can be given to COT acquisition for terminal 200 or base station 100, making it easier for the higher-priority terminal 200 (or base station 100) to acquire COT, thereby reducing transmission delay. For example, base station 100 can set a higher priority for its own transmission than for terminal 200's transmission by setting the CP extension amount. Therefore, base station 100 can dynamically perform COT acquisition and downlink transmission based on the priority of base station 100's transmission and terminal 200's transmission, thereby improving scheduling flexibility.

[0089] Furthermore, the base station 100 can suppress situations where an FFP is not used by deciding to transmit (in other words, obtaining a COT) if, for example, none of the terminals 200 transmit during a certain FFP, based on the transmission status of the terminals 200. Also, for example, even if data is generated in the middle of an FFP (in other words, at a different timing than the beginning of the FFP) at the base station 100 and terminals 200, transmission becomes possible, thus reducing the transmission delay time.

[0090] Thus, for example, even when UE-initiated COT is performed when the COT acquisition timing is at the beginning of the FFP, the scheduling efficiency for the base station 100 and terminal 200 can be improved. Therefore, according to this embodiment, transmission efficiency can be improved when UE-initiated COT scheduling is performed in the unlicensed frequency band.

[0091] Furthermore, multiple CP extension amounts may be set for a single terminal 200. For example, different CP extension amounts may be set between FFPs (e.g., the CP extension amount may be changed periodically). This setting of CP extension amounts allows, for example, one FFP to have a higher CP extension amount and another FFP to have a lower CP extension amount. In this way, the priority for COT acquisition for each terminal 200 differs among FFPs, improving the fairness of priority for COT acquisition among multiple terminals 200. Alternatively, for example, multiple candidate CP extension amounts may be set for a single terminal 200 within the same FFP, and a selection may be made from among these candidates (e.g., randomly selected). This operation can, for example, change the priority for COT acquisition for a single terminal 200, improving the fairness of priority for COT acquisition among terminals 200.

[0092] Furthermore, the base station 100 may prioritize COT acquisition between terminals 200 (or between terminals 200 and base station 100) not only by setting the CP extension amount, but also by setting the data transmission timing. For example, the base station 100 may set the data transmission timing for higher-priority terminals 200 or base station 100 to be earlier. For example, the base station 100 may set the transmission timing for high-priority terminals 200 to be one symbol earlier than that of other terminals 200. This setting allows high-priority terminals 200 or base stations to perform transmissions with higher priority than other terminals.

[0093] (Embodiment 2) In this embodiment, the configuration of the base station and terminal may differ from that of Embodiment 1 in some functions, while other functions may be the same as those of Embodiment 1.

[0094] As described above, for example, the CP extension in DG-PUSCH is a gap adjustment CP extension used to adjust the gap length. Also, for example, the control method of Embodiment 1 (for example, a method of controlling the transmission priority of terminal 200 or base station 100 by setting multiple transmission start timings at the beginning of FFP) may be applied to DG-PUSCH. In other words, a CP extension for multiple transmission timings may be supported for DG-PUSCH.

[0095] However, when PUSCH transmission occurs within the COT of base station 100 (e.g., gNB COT), a CP extension for gap adjustment may be supported.

[0096] Therefore, in this embodiment, a method for setting both a CP extension for multiple transmission timings and a CP extension for gap adjustment for a DG-PUSCH will be described. Note that in this embodiment, the PUSCH is not limited to a DG-PUSCH, but may also be a CG-PUSCH.

[0097] In the base station 100 (Figure 6), the scheduling unit 104 may, for example, individually set CP extension setting information (e.g., CP extension amount) for each terminal 200, and CP extension setting information to be applied within the COT (e.g., gNB COT) acquired by the base station 100, and CP extension setting information to be applied during a period different from the base station 100's COT (e.g., the beginning of FFP). The scheduling unit 104 may, for example, output the determined CP extension setting information to the control information holding unit 105. The scheduling unit 104 may also, for example, use the CP extension setting information to schedule the transmission of signaling information and the PUSCH transmission of terminal 200.

[0098] In the terminal 200 (Fig. 7), the transmission control unit 204 may determine whether the PUSCH to be transmitted is within the COT (e.g., gNB COT) of the base station 100 based on, for example, control information such as Configured grant setting information and FBE setting information input from the control information holding unit 205, or the decoding result input from the demodulation / decoding unit 202. The transmission control unit 204 may determine the CP extension amount to be applied to the PUSCH based on the determination result and the CP extension setting information, and output information regarding the determined CP extension amount to the CP addition unit 208.

[0099] [Operation examples of base station 100 and terminal 200] The operation examples in the base station 100 and terminal 200 having the above configuration will be described.

[0100] In the present embodiment, for example, the combinations of a plurality of candidate CP extension amounts (e.g., candidate CP lengths) that can be notified by the CP extension setting information may be different for each type of COT. For example, the base station 100 may include any one of a plurality of combinations of different candidate CP lengths for each type of COT in the control information. Further, the terminal 200 may determine one CP extension amount from among the plurality of candidate CP lengths of the combination corresponding to the type of COT based on, for example, the control information notified from the base station 100.

[0101] The types of COT may include, for example, gNB COT and a period different from gNB COT.

[0102] For example, examples of the COT acquisition control method in the case where the PUSCH transmitted by the terminal 200 is "DG-PUSCH", the case of "type 1 CG PUSCH", and the case of "type 2 CG PUSCH" will be described. The terminal 200 may perform COT acquisition and PUSCH transmission based on, for example, the control information from the base station 100.

[0103] [Case of DG-PUSCH] For example, two types of tables may be set: one for setting the amount of CP extension applied within the COT (gNB COT) of base station 100 (for example, an example of associating an index with a CP extension amount for gap adjustment), and another for setting the amount of CP extension applied over a period different from the COT of base station 100 (for example, an example of associating an index with a CP extension amount for multiple transmission timings).

[0104] A table applied within the gNB COT (for example, referred to as "Table 1") may be used, for example, to notify of gap adjustment CP extensions. A table applied over a different period than the gNB COT (for example, referred to as "Table 2") may be used, for example, to notify of multiple transmission timing CP extensions.

[0105] For example, Table 1 may or may not include other parameters such as channel access type and CAPC in addition to the CP extension amount for gap adjustment. Similarly, Table 2 may or may not include parameters different from the CP extension amount for multiple transmission timings. For example, the size of Table 2 can be reduced by reducing the number of possible parameter settings.

[0106] Furthermore, for example, a common index may be set in Table 1 and Table 2. In other words, the base station 100 and the terminal 200 may determine which table from Table 1 and Table 2 to apply (or refer to) in COT acquisition and PUSCH transmission, depending on the type of COT (or transmission timing).

[0107] For example, terminal 200 may determine which table to refer to based on whether the timing of sending a PUSCH is within the COT (gNB COT) of base station 100. Terminal 200 may determine whether it is gNB COT based on, for example, FBE configuration information and COT information (e.g., COT duration) included in downlink control information (e.g., DCI format 2_0). For example, terminal 200 may determine, for example, that if it is instructed to transmit at the beginning of FFP based on FBE configuration information, it is a different period from gNB COT and select table 2. Alternatively, for example, terminal 200 may determine the duration of COT based on COT information, and if the timing of the transmission instruction is within the duration of COT, it may determine that it is within gNB COT and select table 1.

[0108] The index to be referenced within the table may be notified to terminal 200 from base station 100, for example. The index may be notified to terminal 200 using UL grant, for example. For example, terminal 200 may set one of several candidate CP extension amounts in the selected table based on the index included in the control information (e.g., CP extension setting information) notified from base station 100.

[0109] Figure 10 shows examples of Table 1 and Table 2 for configuring CP extensions.

[0110] Table 1 shown in Figure 10 is, for example, a table applied within the COT of base station 100, and may contain a CP extension for gap adjustment. In the example shown in Figure 10, Table 1 includes the CP extension amount, but is not limited to this; for example, it may include an index of another table that defines the CP extension amount for gap adjustment (for example, the index of Table 5.3.1-1 in Non-Patent Literature 1).

[0111] Furthermore, Table 1 shown in Figure 10 may include, for example, the Channel Access Type and CAPC in addition to the CP extension amount. For example, the CP extension amount may be set together with the Channel Access Type and CAPC in DCI format 0_1 ​​(e.g., joint encoding). Note that Table 1 does not necessarily have to include at least one of the Channel Access Type and CAPC, and may include other parameters.

[0112] Table 2 shown in Figure 10 is, for example, a table applied over a period different from the COT of base station 100, and may contain CP extensions for multiple transmission timings. In the example shown in Figure 10, Table 2 includes the amount of CP extension, but is not limited to this; for example, it may include an index of another table that defines the amount of CP extensions for multiple transmission timings (for example, the index of Table 5.3.1-2 in Non-Patent Literature 1).

[0113] Furthermore, Table 2 shown in Figure 10 may include, for example, CAPC in addition to the CP extension amount. For example, the CP extension amount may be set together with CAPC (e.g., joint encoding). Note that Table 2 does not necessarily have to include CAPC, and may include other parameters.

[0114] For example, at least one candidate CP extension amount included in Table 1 (e.g., combination of candidate CPs) corresponding to the COT of base station 100 (e.g., first type) may be based on Timing alignment (TA) and Channel Access Type (or LBT category). On the other hand, the candidate CP extension amount length included in Table 2 corresponding to a different period from the COT of base station 100 (e.g., second type) does not have to be based on TA and Channel Access Type. Also, for example, the granularity of the CP extension amounts included in Table 2 may be finer than the granularity of the CP extension amounts included in Table 1.

[0115] In this way, in addition to the CP extension for gap adjustment, a CP extension for multiple transmission timings can be set for DG-PUSCH. This allows the base station 100 to set both CG-PUSCH and DG-PUSCH transmissions (e.g., CP extensions for multiple transmission timings) when acquiring COT at the beginning of FFP (e.g., a different period from gNB COT), thereby improving the scheduling flexibility of the base station 100.

[0116] Furthermore, even when CG-PUSCH and DG-PUSCH are mixed, the base station 100 may set priorities (e.g., different CP extension amounts) for CG-PUSCH and DG-PUSCH and schedule them accordingly. This allows the base station 100 to prioritize PUSCH transmissions with shorter delay settings, regardless of whether they are CG-PUSCH or DG-PUSCH, thereby reducing the delay time.

[0117] Also, for example, regarding the setting of the CP extension amount for gap adjustment CP extension and CP extension for multiple transmission timings, as shown in FIG. 10, when using two tables compared to using one table, the size of each table (in other words, the number of indexes) can be reduced, so the signaling overhead when notifying the index can be reduced.

[0118] Note that, for example, it is not limited to two tables according to the COT type as shown in FIG. 10, and a setting in which the CP extension amount for gap adjustment and the CP extension amount for multiple transmission timings are mixed in one table may be used. In this case, for example, when referring to the index of another table that defines the CP extension amount, it may be explicitly set (or defined) which CP extension (in other words, which other table) it is. FIG. 11 is a diagram showing an example including the CP extension amount for gap adjustment and the CP extension amount for multiple transmission timings in one table. In FIG. 11, for example, indexes in a plurality of tables (for example, Table 1 and Table 2) may be set.

[0119] Also, for example, the tables (or combinations of CP extensions for multiple transmission timings) applied in periods different from the gNB COT are not limited to one, and a plurality of them may be set. For example, the granularity of the CP extension amount for multiple transmission timings in each of the plurality of tables applied in periods different from the gNB COT may be different.

[0120] <In the case of type 1 CG PUSCH> In type 1 CG, for example, the CP extension applied within the COT of base station 100 (e.g., gNB COT), such as the CP extension for gap adjustment, and the CP extension applied during a period different from the COT of base station 100 (e.g., CP extension for multiple transmission timings) may be individually and semi-statically set for terminal 200.

[0121] Terminal 200 may determine, for example, the CP extension to be applied to type 1 CG PUSCH based on whether it is within the COT of base station 100 or not.

[0122] Thus, different types of CP extensions can be set for type 1 CG-PUSCH. Thereby, for example, base station 100 can switch and use different CP extensions inside and outside the gNB COT in type 1 CG, so that the freedom of scheduling in base station 100 can be improved.

[0123] Note that when CG transmission is performed during a period different from the COT of base station 100 (for example, at the beginning of FFP), in other words, when CG transmission is not performed within the COT of base station 100, if the CP extension is not used separately, one type of CP extension amount may be set.

[0124] <In the case of type 2 CG PUSCH> In type 2 CG, for example, since activation is performed by PDCCH (or DCI), a method using two tables corresponding to the COT type (e.g., FIG. 10), similar to DG-PUSCH, may be applied.

[0125] For example, a table to be applied within the COT of base station 100 (e.g., table 1 shown in FIG. 10), and a table to be applied during a period different from the COT of base station 100 (e.g., table 2 shown in FIG. 10) may be set.

[0126] Terminal 200 may determine which table to reference based, for example, whether the timing of transmitting CG-PUSCH is within the COT (gNB COT) of base station 100. Furthermore, the index corresponding to the table determined by terminal 200 may be set (or notified) to terminal 200, for example, by an activation PDCCH. Also, for example, the index set to terminal 200 may be used until the transmission of CG-PUSCH is stopped by deactivation, or until it is reactivated.

[0127] In this way, different types of CP extensions can be set for type 2 CG-PUSCH. This allows, for example, base station 100 to switch between using CP extensions inside and outside the gNB COT in type 2 CG. Furthermore, base station 100 can dynamically set the amount of CP extension for each terminal 200, for example, using an activation PDCCH. Thus, the flexibility of scheduling at base station 100 can be improved for type 2 CG-PUSCH.

[0128] In addition, in Type 2 CG, different types of CP extensions may be set semi-statically, similar to Type 1 CG. Furthermore, if different CP extensions are not used, such as when CG transmission is performed at a different time than the COT of base station 100 (for example, at the beginning of FFP) (in other words, when CG transmission is not performed at the COT of base station 100), then only one type of CP extension amount may be set.

[0129] The above describes an example of a method for controlling COT acquisition.

[0130] Thus, in this embodiment, the combination of multiple candidate CP extension amounts (e.g., a table) for the CP extension amount notified by the CP extension setting information may differ for each type of COT. The base station 100 can control multiple transmission timing CP extensions for both DG-PUSCH and CG-PUSCH, for example. As a result, the base station 100 can reduce the delay of PUSCH transmissions at the terminal 200 by setting the CP extension amount for both DG-PUSCH and CG-PUSCH according to the type of each PUSCH transmission (e.g., service type or delay request).

[0131] In this embodiment, the control method for acquiring COT may be the same as the control method for acquiring COT in Embodiment 1 (for example, a method for controlling the transmission priority of terminal 200 or base station 100 by setting multiple transmission start timings at the beginning of FFP), or other control methods may be applied.

[0132] (Embodiment 3) In this embodiment, the configuration of the base station and terminal may differ from that of Embodiment 1 in some functions, while other functions may be the same as those of Embodiment 1.

[0133] [Time domain scheduling] When scheduling in the time domain using DG-PUSCH, the terminal 200 may be instructed to send a PUSCH based on the timing of receiving the UL grant.

[0134] For example, compared to scheduling within an FFP, if a DG-PUSCH at the beginning of the next FFP is instructed (or scheduled) to the terminal, the scheduling may be further apart in time. For example, the FFP period can be as long as 10ms.

[0135] To cover scheduling that is far apart in time, one could, for example, increase the number of bits in the time-domain scheduling parameter (e.g., the Time Domain Resource Assignment (TDRA) field in UL grant) or reduce the degree of scheduling flexibility. One way to reduce the degree of scheduling flexibility is to increase the number of scheduling candidates that are farther away in time, instead of decreasing the number of scheduling candidates that are closer in time.

[0136] [Action taken when COT acquisition fails] For example, in terminal 200, even if it attempts to acquire COT at the beginning of FFP for DG-PUSCH transmission, COT may not be acquired due to interference or other reasons. As mentioned above, in FBE, COT is not acquired at intermediate timings other than the beginning of FFP. Therefore, if terminal 200 fails to acquire COT at the beginning of FFP, it will wait for rescheduling from base station 100 until at least the next FFP, which may increase the delay time.

[0137] Therefore, in this embodiment, for example, a method for suppressing the increase in delay time in PUSCH transmission will be described.

[0138] In the base station 100 (Figure 6), the scheduling unit 104 may, for example, set COT acquisition setting information when determining CP extension setting information (e.g., CP extension amount) for each terminal 200.

[0139] The COT acquisition setting information may include, for example, information related to time-domain scheduling (e.g., information different from the CP extension amount). The time-domain scheduling information may include, for example, at least one of the following: information indicating the start timing of scheduling for terminal 200 (corresponding to "Next FFP" described later), and information indicating a candidate timing for COT acquisition for terminal 200 (or a retry timing for COT acquisition) (corresponding to "Re-attempt" described later).

[0140] The scheduling unit 104 outputs, for example, the determined CP extension setting information and COT acquisition setting information to the control information holding unit 105. The scheduling unit 104 may also use, for example, the CP extension setting information and COT acquisition setting information to schedule the transmission of signaling information and the PUSCH transmission of terminal 200.

[0141] In terminal 200 (Figure 7), the transmission control unit 204 may determine the transmission timing of PUSCH based on, for example, control information such as Configured grant setting information and FBE setting information input from the control information holding unit 205, or downlink control information (for example, CP extension setting information) and COT acquisition setting information input from the demodulation / decoding unit 202, and instruct the data / control information generation unit 206 to generate data or control information.

[0142] [Example of operation of base station 100 and terminal 200] An example of operation in a base station 100 and terminal 200 having the above configuration will be described.

[0143] For example, an example of a COT acquisition control method in a base station 100 (e.g., scheduling unit 104) will be described. A terminal 200 (e.g., transmission control unit 204) may, for example, control COT acquisition and uplink transmission (e.g., PUSCH transmission) based on control by the base station 100.

[0144] <Control Method 1> In control method 1, for example, signaling may be added to notify the terminal 200 of information indicating the start timing of time-domain scheduling (e.g., "Next FFP") as an example of COT acquisition setting information.

[0145] For example, in the time domain scheduling of DG-PUSCH, the timing of receiving the UL grant can be the starting point. On the other hand, in control method 1, for example, when "Next FFP" is notified to terminal 200, base station 100 may perform DG-PUSCH time domain scheduling starting from the beginning of the FFP corresponding to Next FFP (for example, FFP after the timing of receiving the UL grant).

[0146] For example, the FFP corresponding to the Next FFP may be the FFP following the current FFP. Note that the current FFP is, for example, the FFP at the time the UL grant was received, and the next FFP may be the FFP in the next cycle relative to the current FFP.

[0147] The following is an example of a Next FFP notification. Example 1: For example, a 1-bit flag may be used to notify terminal 200 of "Next FFP".

[0148] For example, a 1-bit flag corresponding to the Next FFP may set the starting point for time-domain scheduling for terminal 200. For instance, Next FFP="0" means the starting point is the UL grant, and Next FFP="1" means the starting point is the beginning of the next FFP after the UL grant was received.

[0149] The Next FFP (1-bit flag) may be notified to terminal 200 (joint encoding) together with, for example, the CP extension amount (e.g., CP extension configuration information), or it may be notified to terminal 200 individually in the UL grant field.

[0150] Figure 12 shows an example where the Next FFP is notified together with the CP extension amount (and CAPC). For example, the table shown in Figure 12 (for example, an index and an example of the association between the CP extension amount, CAPC and Next FFP) may be pre-configured from the base station 100 to the terminal 200. Note that the table shown in Figure 12 is just an example, and for example, the parameters included in the table do not necessarily have to include CAPC, and other parameters different from CAPC may be included.

[0151] In this way, when "Next FFP" is notified to terminal 200, base station 100 can schedule, for example, starting from the beginning of the next FFP after the FFP at the time the UL grant was received. The time-domain scheduling parameters for terminal 200 (e.g., TDRA) can be the same as the parameters starting from the time the UL grant was received. Therefore, the signaling overhead of the time-domain scheduling parameters (e.g., TDRA) can be reduced, and the degree of flexibility in time-domain scheduling can be improved.

[0152] Furthermore, the starting point for scheduling the time domain notified to terminal 200 by Next FFP is not limited to the FFP immediately following the FFP that received the UL grant, but may be any FFP after the FFP that received the UL grant.

[0153] Example 2: For example, the "Next FFP" message may be sent to terminal 200 via the M-bit field.

[0154] For example, the starting point for time-domain scheduling may be set for terminal 200 by the M bit field corresponding to Next FFP. For example, Next FFP may notify how many FFPs ahead from the time of UL grant reception will be set as the starting point for time-domain scheduling. For example, Next FFP=“0” means that the UL grant will be the starting point, and Next FFP=“m” means that the beginning of the FFP m times ahead from the time of UL grant reception will be the starting point. Note that m may represent, for example, the value notified in the M bit field.

[0155] The Next FFP (e.g., an M-bit field) may be notified (joint encoded) together with, for example, the CP extension amount (e.g., CP extension configuration information), or it may be notified individually in the UL grant field. For example, if the Next FFP is notified together with the CP extension amount, a table like the one shown in Figure 12 may be pre-configured from the base station 100 to the terminal 200, similar to Example 1.

[0156] In this way, by notifying terminal 200 of "Next FFP" in an M bit field, base station 100 can, for example, schedule from an earlier FFP start or from more FFPs compared to Example 1. Also, the time-domain scheduling parameters for terminal 200 (e.g., TDRA) can be the same as the parameters that start from the timing of receiving the UL grant. Therefore, the signaling overhead of the time-domain scheduling parameters (e.g., TDRA) can be reduced, and the degree of scheduling flexibility can be improved.

[0157] <Control Method 2> In control method 2, for example, as an example of COT acquisition setting information, signaling may be added to notify terminal 200 of information indicating a retry of COT acquisition when COT acquisition fails (for example, "Re-attempt").

[0158] For example, if terminal 200 is instructed to retry, and fails to acquire the COT in the scheduled FFP, it may retry acquiring the COT in the FFP corresponding to "Re-attempt".

[0159] For example, the FFP corresponding to a Re-attempt may be the FFP following the current FFP. Note that the current FFP is, for example, the FFP at the time the UL grant was received, and the next FFP may be the FFP in the next cycle relative to the current FFP.

[0160] The following is an example of a Re-attempt notification.

[0161] Example 1: For example, a 1-bit flag may be used to notify terminal 200 of a retry attempt to obtain the COT.

[0162] For example, a 1-bit flag corresponding to Re-attempt may instruct terminal 200 whether or not to retry acquiring the COT if acquisition fails. For instance, Re-attempt="0" means that no retry will be performed even if acquisition of the COT fails, while Re-attempt="1" means that if acquisition of the COT fails, acquisition of the COT will be retried in the next FFP.

[0163] Furthermore, for example, if the acquisition of the COT fails during a retry in the next FFP, it may be predetermined or defined whether or not to retry acquiring the COT, or the number of retries. For example, the number of retries may be one or multiple.

[0164] Furthermore, the CP extension amount may be changed when retrying COT acquisition. For example, increasing the CP extension amount during a retry may set a higher priority for transmission to terminal 200. Increasing the priority increases the likelihood of acquiring COT, thus reducing latency. Alternatively, for example, decreasing the CP extension amount during a retry may set a lower priority for transmission to terminal 200. Lowering the priority may, for example, prioritize directly scheduled transmissions over retry transmissions via Re-attempt between multiple terminals 200 (or base stations). Note that the change in the CP extension amount during retries may be set or defined in advance.

[0165] The Re-attempt (1-bit flag) may be notified to terminal 200 (joint encoding) together with, for example, the CP extension amount (e.g., CP extension configuration information), or it may be notified to terminal 200 individually in the UL grant field.

[0166] Figure 13 shows an example where Re-attempt is notified together with the CP extension amount (and CAPC). For example, the table shown in Figure 13 (e.g., the index and the association between CP extension amount, CAPC, and Re-attempt) may be pre-configured from base station 100 to terminal 200. Note that the table shown in Figure 13 is just an example, and for example, the parameters included in the table do not necessarily have to include CAPC, and other parameters different from CAPC may be included.

[0167] In this way, by notifying terminal 200 of an instruction to retry acquiring COT (Re-attempt), terminal 200 can potentially transmit uplink without waiting for scheduling from base station 100 by retrying to acquire COT in the next FFP, even if it fails to acquire COT for an FFP scheduled by base station 100, thus reducing latency.

[0168] Furthermore, the timing of the COT acquisition retry, which is notified to terminal 200 by Re-attempt, is not limited to the FFP immediately following the FFP that received the UL grant, but may be any FFP after the FFP that received the UL grant.

[0169] Example 2: For example, the M bit field may notify terminal 200 of instructions regarding retrying COT acquisition (e.g., Re-attempt).

[0170] For example, the field of the M bit corresponding to Re-attempt may instruct terminal 200 on the conditions for retrying COT acquisition when COT acquisition fails.

[0171] For example, the number of retries may be instructed to terminal 200 via an M-bit field. By instructing the number of retries, the base station 100 can dynamically set (e.g., change) the number of retries based on, for example, the state of terminal 200 within the cell (e.g., whether or not there are terminal 200 with high-priority data), thereby reducing latency and improving scheduling flexibility.

[0172] Furthermore, for example, the M bit field may instruct (or specify) the terminal 200 to retry if it is a UL symbol, or if it is either a UL symbol or a Flexible symbol. By specifying the retry condition, the base station 100 can, for example, instruct the terminal 200 to retry acquiring the COT when the condition (e.g., the type of symbol) is met, thereby improving the flexibility of the base station 100's scheduling.

[0173] Furthermore, for example, the setting of the CP extension amount during retries (e.g., increase or decrease) may also be notified via the M bit field. This allows for dynamic setting of the CP extension amount during attempts to acquire COT (e.g., including retries), thereby reducing latency and improving the scheduling flexibility of the base station 100.

[0174] Furthermore, Re-attempt (the M-bit field) may be notified to terminal 200 (joint encoding) together with, for example, the CP extension amount (e.g., CP extension configuration information), or it may be notified to terminal 200 individually in the UL grant field. For example, if Re-attempt is notified together with the CP extension amount, then, for example, similar to Example 1, the table shown in Figure 13 may be pre-configured from base station 100 to terminal 200.

[0175] In this way, by notifying terminal 200 of "Re-attempt" in the M bit field, it becomes possible to conditionally instruct a retry of COT acquisition. In addition to the effects of Example 1, this improves the flexibility of scheduling for base station 100.

[0176] Control Method 1 and Control Method 2 have been described above.

[0177] Furthermore, control method 1 and control method 2 may be applied in combination. For example, if terminal 200 fails to acquire COT in an FFP transmitted by "Next FFP", "Re-attempt" can be used to instruct whether or not to retry acquiring COT in the next FFP. This can reduce latency and improve scheduling flexibility.

[0178] In this embodiment, the control method for acquiring COT may be the same as the control method for acquiring COT in Embodiment 1 (for example, a method for controlling the transmission priority of terminal 200 or base station 100 by setting multiple transmission start timings at the beginning of FFP), or other control methods may be applied.

[0179] (Embodiment 4) [Priority settings in URLLC, Release 16] As an extension to the URLLC functionality in Release 16, support has been added for defining or setting the priority of terminal transmissions using "priority (High or Low)". This feature can be used to determine (or decide) which transmission takes priority when multiple transmissions are triggered within a terminal. For example, the priority of a PUSCH can be set dynamically by UL grant or semi-statically.

[0180] This embodiment describes, for example, a method for controlling CP extension settings based on the priority of terminal transmissions (or data, channel, or service type).

[0181] In this embodiment, the configuration of the base station and terminal may differ from that of Embodiment 1 in some functions, while other functions may be the same as those of Embodiment 1.

[0182] In the base station 100 (Figure 6), the scheduling unit 104 may, for example, set multiple CP extension setting information corresponding to multiple priorities when determining CP extension setting information (e.g., CP extension amount) for each terminal 200. The scheduling unit 104 may, for example, output the determined CP extension setting information to the control information holding unit 105. The scheduling unit 104 may also, for example, use this CP extension setting information to schedule the transmission of signaling information and the PUSCH transmission of terminal 200.

[0183] In terminal 200 (Figure 7), the transmission control unit 204 may, for example, refer to the CP extension setting information corresponding to the priority of the PUSCH to be transmitted, based on the Configured grant setting information input from the control information holding unit 205, or the decoding result input from the demodulation / decoding unit 202, and determine the amount of CP extension to be applied to the PUSCH. The transmission control unit 204 may, for example, output information regarding the determined amount of CP extension to the CP addition unit 208.

[0184] [Example of operation of base station 100 and terminal 200] An example of operation in a base station 100 and terminal 200 having the above configuration will be described.

[0185] In this embodiment, for example, the combination of multiple candidate CP extension amounts (e.g., candidate CP lengths) that can be notified by the CP extension setting information may differ for each priority of the terminal 200's transmission.

[0186] For example, the base station 100 may include in the control information one of several candidate CP lengths, each with a different combination for each transmission priority of the terminal 200. Alternatively, the terminal 200 may, for example, determine one CP extension amount from among several candidate CP lengths corresponding to the transmission priority of the terminal 200, based on the control information notified by the base station 100.

[0187] The transmission priority of terminal 200 may include, for example, "high" and "low". Furthermore, the transmission priority of terminal 200 is not limited to two types; it may include three or more types.

[0188] For example, examples of COT acquisition control methods for the cases where the PUSCH transmitted by terminal 200 is "DG-PUSCH", "type 1 CG PUSCH", and "type 2 CG PUSCH" will be described. Terminal 200 may, for example, acquire COT and transmit PUSCH based on control information from base station 100.

[0189] <In the case of DG-PUSCH> For example, a table for notifying a plurality of CP extension amounts based on priority may be set. The table for notifying the CP extension amount based on priority may be set by the base station 100 in advance for the terminal 200, or may be defined in the standard.

[0190] Here, it is assumed that for high-priority transmission, for example, a larger CP extension amount is set in order to facilitate obtaining COT. Therefore, for example, the table corresponding to high priority may be set to include candidates with a larger CP extension amount compared to the table corresponding to low priority.

[0191] For example, the terminal 200 may determine the table to be referred to during PUSCH transmission based on the priority notified by the UL grant. Also, for example, even when there is no priority notification, the terminal 200 may implicitly determine the table to be referred to during PUSCH transmission based on other parameters that can determine the priority. Other parameters that can determine the priority include, for example, the DCI format or an identifier used by the terminal 200 (e.g., Radio Network Temporary Identifier (RNTI)).

[0192] For example, when there are two types of priorities, high and low, two types of tables for setting the CP extension amount may be set. The terminal 200 may determine the table to be referred to during PUSCH transmission based on the notification of the UL grant (e.g., priority) instructing PUSCH transmission.

[0193] Figure 14 shows an example of a table that sets the CP extension amount corresponding to low priority and high priority, respectively (for example, an example of the association between an index and the CP extension amount).

[0194] The high-priority table shown in Figure 14 may include CP extension amounts that are larger than those in the low-priority table (e.g., "T-16us", "T-25us", or "T-341us").

[0195] Note that the CP extension amounts included in the high-priority and low-priority tables are not limited to the example shown in Figure 14, and some CP extension amounts may be included in both the high-priority and low-priority tables. Also, the tables shown in Figure 14 include, for example, Channel Access Type and CAPC in addition to CP extension amounts, but are not limited to these, and for example, at least one of Channel Access Type and CAPC may not be included, and other parameters may be included.

[0196] In this way, by setting or defining multiple tables corresponding to the transmission priority of terminal 200 for DG-PUSCH, and switching the table that terminal 200 refers to according to the priority, terminal 200 can transmit PUSCH (for example, obtain COT) with a CP extension amount corresponding to the priority of DG-PUSCH transmission.

[0197] Also, for example, compared with the case where the CP extension amounts corresponding to a plurality of priorities are set in one table, since the CP extension amounts are set in a plurality of tables corresponding to a plurality of priorities, the number of candidates for the CP extension amount included in each table (in other words, the number of indexes) can be reduced, and the signaling overhead for notifying the indexes can be reduced.

[0198] <In the case of type 1 CG-PUSCH> In type 1 CG, the transmission priority of the terminal 200 may be set semi-statically, for example. Also, for example, the priorities of the upper layer data included in the physical layer data (for example, the priorities of the logical channels) may dynamically differ.

[0199] Therefore, for example, a plurality of tables corresponding to the priorities of the logical channels may be set for the CP extension amount. The terminal 200 may determine the table to be referred to based on any of the priorities of the upper layer data included in the physical layer data, for example. For example, the terminal 200 may dynamically switch the CP extension by determining the table to be referred to based on the logical channel with the highest priority. Note that the determination of table reference is not limited to the highest priority and may be other priorities.

[0200] In this way, for type 1 CG-PUSCH, by switching the CP extension according to the priority of the logical channel, it becomes possible to support dynamic control of the priority even in type 1 CG operating with a semi-static setting, and the delay time of the data to be transmitted with higher priority can be reduced.

[0201] <In the case of type 2 CG-PUSCH> In type 2 CG, for example, the priority may be set for each activation using the priority field included in the activation PDCCH.

[0202] Therefore, for example, similar to DG-PUSCH, multiple tables corresponding to multiple priorities may be set up for the CP extension amount.

[0203] Terminal 200 may, for example, determine the table to refer to when transmitting CG-PUSCH and the amount of CP extension corresponding to the notified index in that table, based on the priority and table index notified by the activation PDCCH.

[0204] Thus, for type 2 CG-PUSCH, terminal 200 can flexibly set the CP extension amount (for each activation or reactivation) compared to when the CP extension is determined semi-statically, by determining the CP extension amount based on the priority and index notified by the activation PDCCH.

[0205] Furthermore, compared to a case where CP extension amounts are set for multiple priorities in a single table, setting CP extension amounts for multiple tables corresponding to multiple priorities reduces the number of candidate CP extension amounts (in other words, the number of indexes) in each table, thereby reducing the signaling overhead of notifying indexes.

[0206] The above describes an example of a method for controlling COT acquisition.

[0207] Thus, in this embodiment, the combination of multiple candidate CP extension amounts (e.g., a table) for the CP extension amount notified by the CP extension setting information may differ for each transmission priority of the terminal 200. The base station 100 can reduce the delay of PUSCH transmission at the terminal 200 by setting multiple transmission timing CP extensions for both DG-PUSCH and CG-PUSCH based on the PUSCH transmission priority.

[0208] In this embodiment, for example, the transmission priority within terminal 200 has been described, but the embodiment is not limited to this, and the priority may be, for example, the priority between multiple terminals 200 (or base station 100).

[0209] Furthermore, the control method for acquiring COT in this embodiment may be the same as the control method for acquiring COT in Embodiment 1 (for example, a method for controlling the transmission priority of terminal 200 or base station 100 by setting multiple transmission start timings at the beginning of FFP), or other control methods may be applied.

[0210] An embodiment of the present disclosure has been described above.

[0211] (Other embodiments) Furthermore, each of the above embodiments may be applied in combination.

[0212] In the embodiments described above, the uplink signal is not limited to uplink data channels such as PUSCH, DG-PUSCH, or CG-PUSCH, but may be other signals or channels. For example, it may be applied to the Physical Uplink Control Channel (PUCCH) or the Sounding Reference Signal (SRS). For example, since PUCCH or SRS may be instructed to transmit by DL assignment (e.g., dynamic downlink data scheduling information) rather than UL grant, the UL grant in the embodiments described above may be replaced with DL assignment.

[0213] (Control signal) In one embodiment of this disclosure, the downlink control signal (or downlink control information) may be, for example, a signal (or information) transmitted in the Physical Downlink Control Channel (PDCCH) of the physical layer, or a signal (or information) transmitted in the Medium Access Control (MAC) or Radio Resource Control (RRC) of the upper layer. Furthermore, the signal (or information) is not limited to being notified by the downlink control signal, but may be predetermined in the specification (or standard), or may be pre-configured in the base station and terminal.

[0214] In one embodiment of this disclosure, the uplink control signal (or uplink control information) may be, for example, a signal (or information) transmitted in the physical layer PDCCH, or a signal (or information) transmitted in the upper layer MAC or RRC. Furthermore, the signal (or information) is not limited to being notified by the uplink control signal, but may be predetermined in the specification (or standard), or may be pre-configured in the base station and terminal. In addition, the uplink control signal may be replaced with, for example, uplink control information (UCI), 1st stage sidelink control information (SCI), or 2nd stage SCI.

[0215] (base station) In one embodiment of this disclosure, the base station may be a Transmission Reception Point (TRP), cluster head, access point, Remote Radio Head (RRH), eNodeB (eNB), gNodeB (gNB), Base Station (BS), Base Transceiver Station (BTS), master unit, gateway, etc. Also, in sidelink communication, a terminal may be used instead of a base station. Also, a relay device that relays communication between a higher node and a terminal may be used instead of a base station.

[0216] (Uphill rink / Downhill rink / Side rink) One embodiment of the present disclosure may be applied to, for example, an uplink, a downlink, or a sidelink. For example, one embodiment of the present disclosure may be applied to the Physical Uplink Shared Channel (PUSCH), Physical Uplink Control Channel (PUCCH), Physical Random Access Channel (PRACH) of an uplink, the Physical Downlink Shared Channel (PDSCH), PDCCH, Physical Broadcast Channel (PBCH) of a downlink, or the Physical Sidelink Shared Channel (PSSCH), Physical Sidelink Control Channel (PSCCH), Physical Sidelink Broadcast Channel (PSBCH) of a sidelink.

[0217] 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. PBCH and PSBCH are examples of broadcast channels, and PRACH is an example of a random access channel.

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

[0219] (reference signal) In one embodiment of the present disclosure, the reference signal is, for example, a signal known to both the base station and the mobile station, and may be called a Reference Signal (RS) or pilot signal. The reference signal may be any of the following: Demodulation Reference Signal (DMRS), Channel State Information - Reference Signal (CSI-RS), Tracking Reference Signal (TRS), Phase Tracking Reference Signal (PTRS), Cell-specific Reference Signal (CRS), or Sounding Reference Signal (SRS).

[0220] (Time interval) In one embodiment of the present disclosure, the unit of time resource is not limited to one or a combination of slots and symbols, but may also be a time resource unit such as a frame, superframe, subframe, slot, time slot subslot, minislot, or symbol, Orthogonal Frequency Division Multiplexing (OFDM) symbol, Single Carrier - Frequency Division Multiplexing (SC-FDMA) symbol, or any other time resource unit. Furthermore, the number of symbols contained in one slot is not limited to the number of symbols exemplified in the above embodiment, but may be any other number of symbols.

[0221] (Frequency band) One embodiment of the present disclosure may be applied to either a licensed band or an unlicensed band.

[0222] (communication) One embodiment of the present disclosure may be applied to communication between a base station and a terminal, communication between terminals (Sidelink communication, Uu-link communication), or Vehicle to Everything (V2X) communication. For example, the channel in one embodiment of the present disclosure may be replaced with any of PSCCH, PSSCH, Physical Sidelink Feedback Channel (PSFCH), PSBCH, PDCCH, PUCCH, PDSCH, PUSCH, or PBCH.

[0223] Furthermore, one embodiment of this disclosure may be applied to any of the following: a terrestrial network, a satellite, or a non-terrestrial network (NTN) using a high-altitude pseudo-satellite (HAPS). Also, one embodiment of this disclosure may be applied to terrestrial networks with large cell sizes, ultra-wideband transmission networks, and other networks where transmission delay is large relative to symbol length or slot length.

[0224] (Antenna port) In one embodiment of this disclosure, an antenna port refers to a logical antenna (antenna group) composed of one or more physical antennas. For example, an antenna port does not necessarily refer to a single physical antenna, but may refer to an array antenna composed of multiple antennas. For example, the number of physical antennas that make up an antenna port is not specified, and it may be defined as the smallest unit on which a terminal station can transmit a reference signal. Alternatively, an antenna port may be defined as the smallest unit on which the weighting of a precoding vector is multiplied.

[0225] <5G NR System Architecture and Protocol Stack> 3GPP is continuing work on the next release of fifth-generation mobile phone technology (also simply called "5G"), which includes the development of new radio access technologies (NR) operating in the frequency range up to 100 GHz. The initial version of the 5G standard was completed at the end of 2017, which will enable the prototyping and commercial deployment of devices (e.g., smartphones) that comply with the 5G NR standard.

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

[0227] The NR user plane protocol stack (see, for example, 3GPP TS 38.300, section 4.4.1) includes the PDCP (Packet Data Convergence Protocol (see section 6.4 of TS 38.300)) sublayer, RLC (Radio Link Control (see section 6.3 of TS 38.300)) sublayer, and MAC (Medium Access Control (see section 6.2 of TS 38.300)) sublayer, which are terminated on the network side in gNB. Additionally, a new Access Stratum (AS) sublayer (SDAP: Service Data Adaptation Protocol) is introduced on top of PDCP (see, for example, 3GPP TS 38.300, section 6.5). Furthermore, a control plane protocol stack is defined for NR (see, for example, TS 38.300, section 4.4.2). An overview 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.

[0228] For example, the Medium-Access-Control layer handles scheduling and scheduling-related functions, including the multiplexing of logical channels and the handling of various neural networks.

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

[0230] Use cases / deployment scenarios for NR may include enhanced mobile broadband (eMBB), ultra-reliable low-latency communications (URLLC), and massive machine type communications (mMTC), each with diverse requirements in terms of data rate, latency, and coverage. For example, eMBB is expected to support peak data rates (20 Gbps on the downlink and 10 Gbps on the uplink) and effective (user-experienced) data rates approximately three times that of IMT-Advanced. URLLC, on the other hand, imposes more stringent requirements for ultra-low latency (0.5 ms for UL and DL respectively for user plane latency) and high reliability (1-10⁻⁵ within 1 ms). Finally, mMTC may preferably require high connectivity density (1,000,000 devices / km² in urban environments), wide coverage in harsh environments, and extremely long-lasting batteries (15 years) for low-cost devices.

[0231] Therefore, an OFDM neurology suitable for one use case (e.g., subcarrier spacing, OFDM symbol length, cyclic prefix (CP) length, number of symbols per scheduling interval) may not be effective for other use cases. For example, low-latency services may preferably require a shorter symbol length (and thus a larger subcarrier spacing) and / or fewer symbols per scheduling interval (also known as TTI) than mMTC services. Furthermore, deployment scenarios with large channel delay spreads may preferably require a longer CP length than scenarios with short delay spreads. The subcarrier spacing may be optimized on a case-by-case basis to maintain similar CP overhead. There may be one or more subcarrier spacing values ​​supported by NR. Accordingly, subcarrier spacings of 15kHz, 30kHz, 60kHz, etc. are currently being considered. The symbol length Tu and subcarrier spacing Δf are directly related by the equation Δf = 1 / Tu. Similar to LTE systems, the term “resource element” can be used to mean the smallest resource unit consisting of one subcarrier for the length of one OFDM / SC-FDMA symbol.

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

[0233] <Functional separation between NG-RAN and 5GC in 5G NR> Figure 16 shows the functional separation between NG-RAN and 5GC. The logical nodes of NG-RAN are gNB or ng-eNB. 5GC has logical nodes AMF, UPF, and SMF.

[0234] For example, gNB and ng-eNB host the following main functions: - Radio resource management functions such as radio bearer control, radio admission control, connection mobility control, and dynamic allocation (scheduling) of resources to UEs on both uplink and downlink; - Compression, encryption, and integrity protection of the IP header of the data; - Selection of the AMF when the UE attaches if routing to the AMF cannot be determined from the information provided by the UE; - Routing of user plane data toward UPF; - Routing of control plane information to AMF; - Setting up and disconnecting connections; - Scheduling and sending paging messages; - Scheduling and transmission of system notification information (originating from AMF or Operation, Admission, Maintenance functions (OAM)); - Setting up measurements and measurement reporting for mobility and scheduling; - Transport-level packet marking on the uplink; - Session management; - Support for network slicing; - Management of QoS flows and mapping to data radio bearers; - Support for UEs in the RRC_INACTIVE state; - NAS message delivery function; - Sharing of wireless access network; - Dual connectivity; - Close cooperation between NR and E-UTRA.

[0235] The Access and Mobility Management Function (AMF) hosts the following main functions: - A function to terminate Non-Access Stratum (NAS) signaling; - Security of NAS signaling; - Security control of Access Stratum (AS); - Core Network (CN) node-to-node signaling for mobility between 3GPP access networks; - Reachability of the UE in idle mode (including control and execution of paging retransmissions); - Management of registration areas; - Support for intra-system and inter-system mobility; - Access authentication; - Access authorization including roaming permission checks; - Mobility management and control (enrollment and policies); - Support for network slicing; - Selection of Session Management Function (SMF).

[0236] Furthermore, the User Plane Function (UPF) hosts the following main functions: - Anchor points for intra-RAT mobility / inter-RAT mobility (where applicable); - External PDU (Protocol Data Unit) session points for interconnection with data networks; - Routing and forwarding of packets; - Packet inspection and enforcement of policy rules in the user plane. - Reporting traffic usage; - Uplink classifier to support routing of traffic flow to data networks; - Branching Point for supporting multi-homed PDU sessions; - QoS processing for the user plane (e.g., packet filtering, gating, UL / DL rate enforcement); - Verification of uplink traffic (mapping to QoS flows of SDFs); - Downlink packet buffering and trigger function for downlink data notification.

[0237] Finally, the Session Management Function (SMF) hosts the following main functions: - Session management; - IP address allocation and management for the UE; - Selection and control of the UPF; - Traffic steering setting function in the User Plane Function (UPF) for routing traffic to the appropriate destination; - Enforcement of control plane policies and QoS; - Notification of downlink data.

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

[0239] RRC is a higher-layer signaling protocol used for configuring UEs and gNBs. During this transition, the AMF prepares UE context data (including, for example, PDU session context, security key, UE Radio Capability, UE Security Capabilities, etc.) and sends it to the gNB along with an Initial Context Setup Request. The gNB then activates AS security together with the UE. This is done by the gNB sending a SecurityModeCommand message to the UE, to which the UE responds with a SecurityModeComplete message. Subsequently, the gNB sends an RRCReconfiguration message to the UE, and upon receiving an RRCReconfigurationComplete from the UE, the gNB reconfigures itself to set up the Signaling Radio Bearer 2 (SRB2) and Data Radio Bearer (DRB). For signaling-only connections, the RRCReconfiguration step is omitted because SRB2 and DRB are not set up. Finally, gNB notifies AMF that the setup procedure is complete with an Initial Context Setup Response.

[0240] Accordingly, this disclosure provides a 5th Generation Core (5GC) entity (e.g., AMF, SMF, etc.) comprising a control circuit that establishes a Next Generation (NG) connection with a gNodeB during operation, and a transmission unit that sends an initial context setup message to the gNodeB via the NG connection during operation so that a signaling radio bearer between the gNodeB and the user equipment (UE) is set up. Specifically, the gNodeB transmits Radio Resource Control (RRC) signaling, including an Information Element (IE), to the UE via the signaling radio bearer. The UE then transmits on the uplink or receives on the downlink based on the resource allocation setting.

[0241] <IMT Usage Scenarios from 2020 Onward> Figure 18 shows some use cases for 5G NR. The 3rd generation partnership project for new radio (3GPP NR) is considering three use cases envisioned by IMT-2020 to support a wide variety of services and applications. The first phase of specification development for enhanced mobile-broadband (eMBB) has been completed. Current and future work will include expanding eMBB support, as well as standardization for ultra-reliable and low-latency communications (URLLC) and massive machine-type communications (mMTC). Figure 18 shows some examples of conceptual use scenarios for IMT beyond 2020 (see, e.g., ITU-R M.2083 Figure 2).

[0242] URLLC use cases have stringent performance requirements, such as throughput, latency, and availability. URLLC use cases are envisioned as one of the key technologies to enable future applications such as wireless control of industrial production or manufacturing processes, telemedicine surgery, automation of power transmission and distribution in smart grids, and traffic safety. The ultra-high reliability of URLLC is supported by identifying technologies that meet the requirements set by TR 38.913. In NR URLLC in Release 15, a key requirement is that the target user plane latency is 0.5 ms for UL (uplink) and 0.5 ms for DL ​​(downlink). The general URLLC requirement for a single packet transmission is a block error rate (BLER) of 1E-5 for a 32-byte packet size when the user plane latency is 1 ms.

[0243] From a physical layer perspective, reliability can be improved in many ways. Current room for reliability improvement includes defining a separate CQI table for URLLC, a more compact DCI format, and PDCCH iterations. However, this room for improvement may expand towards achieving ultra-high reliability as NR becomes more stable and developed (in terms of critical requirements for NR URLLC). Specific use cases for NR URLLC in Release 15 include augmented reality / virtual reality (AR / VR), e-health, e-safety, and mission-critical applications.

[0244] Furthermore, the technical enhancements targeted by NR URLLC aim to improve latency and reliability. Technical enhancements for latency improvement include configurable neurology, non-slot-based scheduling with flexible mapping, grant-free (configured grant) uplink, slot-level iteration on data channels, and preemption on downlink. Preemption means that a transmission for which a resource has already been allocated is stopped, and that allocated resource is used for other transmissions with lower latency / higher priority requirements that are requested later. Thus, transmissions that were already permitted are replaced by later transmissions. Preemption is applicable regardless of the specific service type. For example, a transmission of service type A (URLLC) may be replaced by a transmission of service type B (eMBB, etc.). Technical enhancements for reliability improvement include a dedicated CQI / MCS table for the 1E-5 target BLER.

[0245] A key characteristic of mMTC (massive machine type communication) use cases is the extremely large number of connected devices that typically transmit relatively small amounts of data that are less susceptible to latency. These devices require low cost and very long battery life. From a noise reduction (NR) perspective, utilizing a very narrow bandwidth is one solution that saves power from the user interface (UE) and extends battery life.

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

[0247] Regarding NR URLLC, further use cases with more stringent requirements, such as factory automation, transportation, and power distribution, are envisioned. The stringent requirements include high reliability (reliability up to the 10-6 level), high availability, packet sizes up to 256 bytes, time synchronization up to about several μs (depending on the use case, the value can be 1 μs or several μs according to the frequency range and a short latency of about 0.5 ms to 1 ms, for example, a latency of 0.5 ms in the target user plane).

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

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

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

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

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

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

[0254] This disclosure can be implemented in software, hardware, or software in conjunction with hardware. Each functional block used in the description of the above embodiments may be implemented in part or in whole as an integrated circuit (LSI), and each process described in the above embodiments may be controlled in part or in whole by a single LSI or a combination of LSIs. An LSI may consist of individual chips, or it may consist of a single chip that includes some or all of the functional blocks. An LSI may have data inputs and outputs. Depending on the degree of integration, LSIs may be referred to as ICs, system LSIs, super LSIs, or ultra LSIs.

[0255] The method of integration is not limited to LSIs; it may also be implemented using dedicated circuits, general-purpose processors, or dedicated processors. Furthermore, FPGAs (Field Programmable Gate Arrays) that can be programmed after LSI manufacturing, or reconfigurable processors that allow for the reconfiguration of the connections and settings of circuit cells within the LSI, may also be used. This disclosure may be implemented as digital or analog processing.

[0256] Furthermore, if advancements in semiconductor technology or other derived technologies lead to the emergence of integrated circuit technologies that replace LSIs, then naturally, it would be possible to use those technologies to integrate functional blocks. The application of biotechnology, for example, is a possibility.

[0257] This disclosure is applicable to all types of devices, systems, and equipment having communication capabilities (collectively referred to as communication equipment). Communication equipment may include a radio transceiver and a processing / control circuit. A radio transceiver may include a receiver and a transmitter, or both as functions. A radio transceiver (transmitter, receiver) may include an RF (Radio Frequency) module and one or more antennas. The RF module may include an amplifier, an RF modulator / demodulator, or similar. Non-exclusive examples of communication devices include telephones (mobile phones, smartphones, etc.), tablets, personal computers (PCs) (laptops, desktops, notebooks, etc.), cameras (digital still / video cameras, etc.), digital players (digital audio / video players, etc.), wearable devices (wearable cameras, smartwatches, tracking devices, etc.), game consoles, digital book readers, telehealth / telemedicine devices, vehicles or mobile transport with communication capabilities (cars, airplanes, ships, etc.), and combinations of the above-mentioned devices.

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

[0259] Communication includes data communication via cellular systems, wireless LAN systems, and communication satellite systems, as well as data communication using combinations of these.

[0260] Furthermore, the communication device also includes devices such as controllers and sensors that are connected to or linked to a communication device that performs the communication functions described in this disclosure. For example, this includes controllers and sensors that generate control signals and data signals used by the communication device that performs the communication functions of the communication device.

[0261] Furthermore, communication equipment includes infrastructure facilities such as base stations, access points, and any other devices, devices, and systems that communicate with or control the aforementioned non-limited types of equipment.

[0262] A terminal according to one embodiment of the present disclosure comprises a control circuit that determines a coordinated cyclic prefix (CP) length between the terminal and a base station, and a transmission circuit that transmits control information relating to the determined CP length to the terminal.

[0263] In one embodiment of the present disclosure, the control circuit includes in the control information one of a plurality of candidate CP lengths in one of a different combinations for each type of channel occupancy time.

[0264] In one embodiment of the present disclosure, at least one of the candidate CP lengths included in the combination corresponding to the first type is based on Timing Alignment (TA), and the candidate CP lengths included in the combination corresponding to the second type are not based on TA.

[0265] In one embodiment of the present disclosure, at least one of the candidate CP lengths included in the combination corresponding to the first type is based on a carrier sense category, and the candidate CP lengths included in the combination corresponding to the second type are not based on the category.

[0266] In one embodiment of the present disclosure, the transmitting circuit transmits other information relating to time-domain scheduling, which is different from the CP length.

[0267] In one embodiment of the present disclosure, the other information includes information indicating the start timing of the scheduling for the terminal.

[0268] In one embodiment of the present disclosure, the other information includes information indicating candidate timings of channel occupancy time for the terminal.

[0269] In one embodiment of the present disclosure, the control circuit includes any one of a plurality of candidate CP lengths with different combinations for each priority for the terminal or the channel in the control information.

[0270] A terminal according to one embodiment of the present disclosure includes a receiving circuit that receives control information regarding a cyclic prefix (CP) length coordinated between the terminal and a base station, and a control circuit that controls uplink transmission based on the CP length.

[0271] In a communication method according to one embodiment of the present disclosure, a base station determines a cyclic prefix (CP) length coordinated between the terminal and the base station, and transmits control information regarding the determined CP length to the terminal.

[0272] In a communication method according to one embodiment of the present disclosure, a terminal receives control information regarding a cyclic prefix (CP) length coordinated between the terminal and a base station, and controls uplink transmission based on the CP length.

[0273] The disclosures of the specification, drawings, and abstracts included in Japanese Patent Application No. 2020-134799 filed on August 7, 2020 are all incorporated herein by reference.

Industrial Applicability

[0274] One embodiment of the present disclosure is useful for a wireless communication system.

Explanation of Signs

[0275] 100 Base station 101, 201 Receiver 102,202 Demodulation / Decoding Unit 103,203 Career Sense Department 104 Scheduling Unit 105,205 Control Information Holding Unit 106,206 Data and control information generation unit 107,207 Encoding and Modulation Section 108,208 CP additions 109,209 Transmitter 200 terminals 204 Transmission Control Unit

Claims

1. A receiving circuit that receives control information regarding the cyclic prefix (CP) length from the base station, A control circuit that controls the transmission of the uplink based on the CP length, It is equipped with, The CP length differs depending on whether the information indicating the channel occupancy time for the terminal is a first value or a second value different from the first value. Terminal.

2. Information regarding the CP length differs for each type of channel occupancy time. The terminal according to claim 1.

3. The CP length corresponding to the first type is determined based on Timing Alignment (TA), The CP length corresponding to the second type is not based on the TA, The terminal according to claim 2.

4. The CP length corresponding to the first type is determined based on the career sense category, The CP length corresponding to the second type is not based on the category, The terminal according to claim 2.

5. The receiving circuit receives an index related to the table used to set the CP length. The terminal according to claim 1.

6. The receiving circuit receives information indicating the start timing of scheduling for the terminal. The terminal according to claim 1.

7. The receiving circuit receives information indicating candidate timings for channel occupancy time for the terminal. The terminal according to claim 1.

8. Information regarding the CP length differs for each priority level for transmission from the aforementioned terminal. The terminal according to claim 1.

9. The aforementioned control information is notified via Radio Resource Control (RRC). The terminal according to claim 1.

10. The aforementioned control information is notified to each terminal. The terminal according to claim 1.

11. The CP length differs depending on whether the channel occupancy time for the terminal is a first length or a second length different from the first length. The terminal according to claim 1.

12. The CP length differs based on the subcarrier spacing. The terminal according to claim 1.

13. The same CP length can be set whether the channel occupancy time for the terminal is a first length or a second length different from the first length. A terminal as described in claim 1.

14. The transmission from the aforementioned terminal is a sidelink transmission. A terminal as described in claim 1.

15. The device is, Control information regarding the cyclic prefix (CP) length is received from the base station. Based on the CP length, the transmission on the uplink is controlled. The CP length differs depending on whether the information indicating the channel occupancy time for the terminal is a first value or a second value different from the first value. Communication method.

16. A receiving circuit that receives control information regarding the cyclic prefix (CP) length from the base station, A control circuit that controls the transmission of the uplink based on the CP length, It is equipped with, The CP length differs depending on whether the information indicating the channel occupancy time for the terminal is a first value or a second value different from the first value. Integrated circuit.