Device and communication method

Abstract

This device having a lower complexity than a narrow band Internet of things (NB-IoT) device comprises: a reception unit that receives an R2D message from a wireless communication device; a control unit that, upon receiving the R2D message, determines transmission of a D2R message or performs transmission control of D2R data waiting to be transmitted; and a transmission unit that transmits the D2R data and the D2R message to the wireless communication device.

Description

Devices and communication methods

[0001] This disclosure relates to devices and communication methods.

[0002] In NR (New Radio) (also known as "5G"), the successor system to LTE (Long Term Evolution), technologies are being considered that meet requirements such as large capacity, high data transmission speed, low latency, simultaneous connection of numerous terminals, low cost, and low power consumption (see, for example, Non-Patent Document 1).

[0003] Furthermore, Release 18 (Rel-18) of 3GPP® considers Ambient IoT (A-IoT: Ambient Internet of Things) (see, for example, Non-Patent Document 2). Ambient IoT targets devices with extremely simple configurations for low-end IoT applications that operate with extremely low power consumption.

[0004] 3GPP TS 38.300 V17.3.0 (2022-12)”Revised SID on Ambient IoT”, RP-232404, 3GPP TSG RAN Meeting #101, September 20233GPP TR 38.848 V1.0.0 (2023-09)3GPP TS 36.211 V16.8.0 (2023-09)”Study on solutions for Ambient IoT (Internet of Things) in NR”, RP-234058, 3GPP TSG RAN Meeting #102, December 2023

[0005] In communication systems including ambient IoT devices from Rel-19 onwards, use cases are envisioned in which ambient IoT devices generate D2R (device to reader) communication signals (hereinafter simply referred to as "D2R") and transmit sensor information to readers such as base stations. This type of transmission is called DO-A (Device originated autonomous) traffic type.

[0006] However, in this type of DO-A traffic, leaders such as base stations are not aware of the status of ambient IoT devices (e.g., whether they have a data buffer or are requesting resources). Furthermore, the procedure by which ambient IoT devices request transmission or resource requests from leaders such as base stations in order to transmit sensor information is also undetermined.

[0007] Therefore, in the DO-A traffic type, it is necessary to consider the procedure by which ambient IoT devices make transmission requests or resource requests to leaders such as base stations.

[0008] One aspect of this disclosure contributes to providing a device and communication method for an ambient IoT device to appropriately make a D2R transmission request or a D2R resource request to a leader such as a base station in a DO-A traffic type.

[0009] A device according to one aspect of the present disclosure is a device of lower complexity than a BNB-IoT (Narrow Band Internet of Things) device, comprising: a receiving unit that receives R2D messages from a wireless communication device; a control unit that, upon receiving the R2D messages, decides to transmit D2R messages or controls the transmission of D2R data awaiting transmission; and a transmitting unit that transmits the D2R data and the D2D messages to the wireless communication device.

[0010] This figure shows an example of a wireless communication system according to an embodiment of the present disclosure. This figure illustrates topology 1. This figure illustrates topology 2. This figure illustrates topology 3 in DL support. This figure illustrates topology 3 in UL support. This figure illustrates topology 4. This figure illustrates backscatter transmission. This figure shows an example of a candidate topology for CW / R2D / D2R transmission in topology 1. This figure shows an example of a candidate topology for CW / R2D / D2R transmission in topology 2. This figure shows an example of an access procedure for an A-IoT device. This figure shows an example of a 4-step (or 3-step) random access procedure for an A-IoT device. This figure shows an example of a 2-step random access procedure for an A-IoT device. This figure shows an example of a procedure when an A-IoT device does not use random access (RA). This figure shows an example of Proposal 1, Option 2 (Procedure a) according to an embodiment of the present disclosure. This figure shows an example of Proposal 1, Option 3 (Procedure b) according to an embodiment of the present disclosure. This figure shows an example of Proposal 1, Option 4 (Procedure c) according to an embodiment of the present disclosure. This figure shows an example of Proposal 1, Option 5 (Procedure d) according to an embodiment of the present disclosure. This figure shows an example of a variation of Proposal 1, Option 2 (Procedure a) according to an embodiment of the present disclosure. This figure shows an example of a variation of Proposal 1, Option 3 (Procedure b) according to an embodiment of the present disclosure. This block diagram shows an example of a base station configuration according to an embodiment of the present disclosure. This block diagram shows an example of a device configuration according to an embodiment of the present disclosure. This figure shows an example of a hardware configuration of a base station and device according to an embodiment of the present disclosure. This figure shows an example of a vehicle configuration according to an embodiment of the present disclosure.

[0011] Hereinafter, an embodiment relating to one aspect of this disclosure will be described with reference to the drawings. Note that the embodiment described below is merely an example, and the embodiments to which this disclosure applies are not limited to the embodiments described below.

[0012] In the operation of the wireless communication system according to the embodiments of this disclosure, existing technologies will be used as appropriate. Such existing technologies include, for example, existing LTE or NR, but are not limited to existing LTE or NR. Furthermore, the term "LTE" as used herein has a broad meaning that includes LTE-Advanced and LTE-Advanced and later technologies, unless otherwise specified.

[0013] Furthermore, in the embodiments of this disclosure described below, terms such as SS (synchronization signal), PSS (primary SS), SSS (secondary SS), PBCH (physical broadcast channel), PRACH (physical random access channel), PDCCH (physical downlink control channel), PDSCH (physical downlink shared channel), PUCCH (physical uplink control channel), and PUSCH (physical uplink shared channel), which are used in existing LTE systems, will be used. This is for convenience of description, and similar signals, functions, etc., may be called by other names. Also, the above terms in NR correspond to NR-SS, NR-PSS, NR-SSS, NR-PBCH, NR-PRACH, etc. However, even if a signal is used in NR, it is not necessarily explicitly stated as "NR-".

[0014] Furthermore, in the embodiments of this disclosure, the duplex method may be a TDD (Time Division Duplex) method, an FDD (Frequency Division Duplex) method, or any other method (for example, a Flexible Duplex).

[0015] Furthermore, in the embodiments of this disclosure, "configuring" wireless parameters means that predetermined values ​​are pre-configured, or that wireless parameters notified by a base station, device, terminal, etc. are configured.

[0016] (Embodiment) <Wireless Communication System> Figure 1 is a diagram showing an example of a wireless communication system according to an embodiment of the present disclosure. As shown in Figure 1, the wireless communication system 1 includes a base station 10 and a device 20. Figure 1 shows one base station 10 and one device 20, but this is just an example, and there may be multiple base stations and devices. The base station is also referred to as BS (Base Station), gNB, etc. The device 20 can be said to be a form of terminal (UE: User Equipment), and may be an ambient IoT device, which is a device with lower complexity than an NB-IoT (Narrow Band Internet of Things) device. The ambient IoT device may be referred to as an ambient IoT terminal, ambient IoT UE, etc.

[0017] Base station 10 is a communication device that provides one or more cells and performs wireless communication with device 20. The physical resources of the wireless signal are defined in the time domain and the frequency domain. The time domain may be defined by the number of OFDM (Orthogonal Frequency Division Multiplexing) symbols. The frequency domain may be defined by the number of subcarriers or the number of resource blocks (RB).

[0018] The base station 10 transmits DL (Downlink) signals to the device 20, including control information, configuration information, and data. The base station 10 receives UL (Uplink) signals from the device 20, including control information, information regarding the processing capabilities of the device 20 (device capability (information) or A-IoT capability (information); for example, capability, device capability, A-IoT capability, A-IoT device capability, etc.), and data.

[0019] The channels used to transmit DL signals include, for example, a data channel and a control channel. For example, the data channel may include a Physical Downlink Shared Channel (PDSCH), and the control channel may include a Physical Downlink Control Channel (PDCCH). For example, base station 10 transmits control information to device 20 using PDCCH and transmits DL data signals using PDSCH. Note that PDSCH is an example of a Downlink Shared Channel or a data channel, and PDCCH is an example of a Downlink Control Channel. PDCCH may be interpreted as Downlink Control Information (DCI), control information, etc., transmitted in the PDCCH.

[0020] As will be discussed later, wireless communication systems may include intermediate nodes, assisting nodes, and / or terminals (UEs) (see <Device Types and Topologies> below). In the following, "and / or" may simply be written as " / ".

[0021] Device 20 is a communication device equipped with wireless communication capabilities, and as described above, may be an ambient IoT device (e.g., a sensor). Hereafter, ambient IoT devices will also be referred to as A-IoT UE.

[0022] Device 20 receives DL signals such as control signals, configuration information, and data from base station 10, and transmits UL signals such as control signals, device 20 capability information, and data to base station 10.

[0023] The channels used to transmit UL signals include, for example, a data channel and a control channel. For example, the data channel may include a Physical Uplink Shared Channel (PUSCH), and the control channel may include a Physical Uplink Control Channel (PUCCH). For example, device 20 transmits control information using PUCCH and transmits UL data signals using PUSCH. Note that PUSCH is an example of an uplink shared channel or a data channel, and PUCCH is an example of an uplink control channel. Note that PUSCH or PUCCH may be interpreted as Uplink Control Information (UCI), control information, etc., transmitted in PUSCH or PUCCH.

[0024] <Ambient IoT> In Rel-18, consideration of ambient IoT, which is even lower end than existing NB-IoT (see, for example, Section 10 of Non-Patent Document 4), was approved (see, for example, Non-Patent Document 2). Ambient IoT targets ultra-low power consumption and ultra-low complexity devices.

[0025] In ambient IoT, for example, the following deployment scenarios and characteristics may be considered for relevant use cases: • Indoor or outdoor environment • Base station type, e.g., macro / micro / picocell-based deployment • Connectivity topology, e.g., which nodes (base stations, terminals (UEs), relays, and repeaters, etc.) communicate with ambient IoT devices • Duplexing method (TDD or FDD), frequency band (licensed or unlicensed) • Coexistence with existing UEs and network equipment in frequency bands intended for 3GPP technology • Assuming outgoing and incoming traffic from devices

[0026] Based on the above implementation scenarios and characteristics, the following RAN design targets may be formulated, for example: • Power consumption • Complexity • Coverage • Data rate • Positioning accuracy

[0027] Based on deployment scenarios suitable for relevant use cases, compare and evaluate the feasibility of meeting design targets and identify the supporting functionalities.

[0028] <Device Types and Topologies> Based on the results of the study items, TR 38.848 (Non-Patent Document 3) was approved. TR 38.848 considers ambient IoT devices in the following categories: Device A: Device A does not have power (energy) storage, does not have independent signal generation and signal amplification functions, and performs backscattering transmission. Device B: Device B has power storage, does not have independent signal generation functions, and performs backscattering transmission. Device B uses the stored power to amplify the reflected signal. Device C: Device C has power storage, has independent signal generation functions, and has an active RF (radio frequency) component for transmission.

[0029] The complexity of device A is expected to be similar to that of RFID (radio frequency identification).

[0030] TR 38.848 defines topologies 1 to 4, described below, for ambient IoT networks.

[0031] Figure 2 illustrates topology 1. As shown in Figure 2, topology 1 is a configuration in which a base station (BS) and ambient IoT devices communicate. The ambient IoT devices directly perform bidirectional communication with the base station.

[0032] Figure 3 illustrates topology 2. As shown in Figure 3, topology 2 is a configuration in which a base station and ambient IoT devices communicate via an intermediate node. Ambient IoT devices perform bidirectional communication with the intermediate node placed between the base station and the ambient IoT device. The intermediate node may be, for example, a relay, an IAB (integrated access and backhaul) node, a UE, a repeater, etc.

[0033] Figure 4 illustrates topology 3 in DL support. As shown in Figure 4, topology 3 is a configuration that includes communication between the base station and the assisting node, communication between the assisting node and the ambient IoT device, and communication between the ambient IoT device and the base station.

[0034] The support node assists with DL communication. For example, as shown in Figure 4, the support node receives DL signals from the base station and transmits the received DL signals to the ambient IoT device. For UL communication, the ambient IoT device transmits UL signals directly to the base station.

[0035] Figure 5 illustrates topology 3 in UL support. As shown in Figure 5, topology 3 is a configuration that includes communication between the base station and the support node, communication between the support node and the ambient IoT device, and communication between the ambient IoT device and the base station.

[0036] The support node assists with UL communication. For example, as shown in Figure 5, the support node receives UL signals from ambient IoT devices and transmits the received UL signals to the base station. For DL ​​communication, ambient IoT devices receive DL signals directly from the base station.

[0037] The support nodes shown in Figures 4 and 5 may be, for example, relays, IAB nodes, UEs, repeaters, etc.

[0038] Figure 6 illustrates topology 4. Topology 4 is a configuration in which the UE and ambient IoT devices communicate. The ambient IoT devices perform bidirectional communication with the UE. The communication related to topology 4 may be considered as sidelink (SL) communication.

[0039] In addition, in topologies 1 to 4 described above, the ambient IoT device may be supplied with a carrier wave from another node inside or outside the topology (see Section 4.2.1 of Non-Patent Document 3).

[0040] The wireless communication system 1 (wireless communication network) may include, in addition to device 20, base stations, support nodes, intermediate nodes and / or terminals (UEs in topology 4). In this specification, base stations, support nodes, intermediate nodes and terminals may be read as network or (network) nodes. Also, an A-IoT device may be simply referred to as A-IoT.

[0041] <Backscatter transmission> Base stations, intermediate nodes, support nodes, and other nodes transmit RF signals to ambient IoT devices. Ambient IoT devices are activated and receive power from the RF operating field of the base station, intermediate nodes, support nodes, and other nodes via inductive coupling.

[0042] Ambient IoT devices backscatter modulate RF signals received from base stations, intermediate nodes, support nodes, and other nodes by switching the reflection coefficient of their own antennas, and then transmit the information to base stations, intermediate nodes, support nodes, and other nodes.

[0043] Figure 7 illustrates backscatter transmission. Figure 7 shows an example where an ambient IoT device performs ON-OFF keying and transmits information. The dashed area in Figure 7 represents the OFF interval, which may correspond to a "0" in the information (bits). A sinusoidal signal may correspond to a "1" in the information.

[0044] <Rel-19 SID> In the Rel-19 SID (Study Item Description), solutions necessary and feasible for A-IoT were considered (see Section 4.1 of Non-Patent Document 5). The solutions considered included, for example, determining which functions and procedures are necessary and which are not.

[0045] Furthermore, several matters will be discussed under the leadership of RAN 1 for the DL and UL of A-IoT. One of the matters to be discussed is the scheduling and timing relationship of DL and UL in A-IoT. In the discussion of scheduling and timing relationships, the following may be considered: 1. Traffic flow, 2. Device assumption, and 3. Topology.

[0046] 1. Traffic Flow The following DT and DO-DTT are being considered as traffic flows for A-IoT.

[0047] DT (device terminated) traffic is characterized by the presence of transmissions to the A-IoT UE (DL) but no transmissions from the A-IoT UE (UL). In other words, there is information to be sent to the A-IoT UE but no information to be sent from the A-IoT UE. DT corresponds to command-type traffic, such as instructions or commands sent to the A-IoT UE.

[0048] DO-DTT (device originated - device terminated triggered) traffic has a trigger from the network (NW) and a transmission (UL) from the A-IoT UE. In other words, the traffic consists of information transmitted from the A-IoT UE. DO-DTT corresponds to, for example, a sensor information report type in which the A-IoT UE transmits sensor information it has collected.

[0049] In this disclosure, transmission of information corresponds to transmission of a signal containing information or transmission of a signal. In this disclosure, transmission to a device X corresponds to transmission of a signal (or information) to device X. Transmission from a device X, and transmission by a device X, correspond to device X transmitting a signal (or information). Reception from a device X corresponds to receiving a signal (or information) transmitted by device X. Reception by a device X corresponds to device X receiving a signal (or information).

[0050] 2. Device Requirements A-IoT UE assumes the following TX (transmission) and FR (frequency range) 1-FDD.

[0051] TX TX is either backscatter UL transmission without amplifier (amplification), or backscatter UL transmission with amplifier. Alternatively, a general UL transmission with amplifier may be performed.

[0052] FR1-FDD applies to the A-IoT UE. That is, the A-IoT UE can switch carrier frequencies between DL carriers and UL carriers. However, this disclosure is not limited to FR1-FDD and may also apply to TDD, FR2, or FR3.

[0053] The frequency bands for each FR are as follows: • FR1: 410 MHz to 7.125 GHz • FR2: 24.25 GHz to 52.6 GHz • FR3: 7.125 GHz to 24.25 GHz

[0054] In FR1, a subcarrier spacing (SCS) of 15 kHz, 30 kHz, or 60 kHz may be used, and a bandwidth (BW) of 5 to 100 MHz may be used. FR2 is a higher frequency than FR1, and an SCS of 60 kHz or 120 kHz (240 kHz may be included) may be used, and a bandwidth (BW) of 50 to 400 MHz may be used.

[0055] 3. Among the topologies shown in Topology Diagrams 2 to 6, Topology 1 and Topology 2 are of particular interest.

[0056] In Topology 1, UL and / or DL ​​communication takes place between the base station and the A-IoT UE without the need for intermediate nodes. Note that the base station in Topology 1 may also support microcells.

[0057] In Topology 2, communication takes place between the base station and the A-IoT UE via an intermediate node. The A-IoT UE performs bidirectional communication with the intermediate node located between the base station and the A-IoT UE. In Topology 2, the base station may correspond to a macrocell. Furthermore, the Topology 2 case may also be applied to indoor environments. Hereafter, the intermediate node will also be referred to as the intermediate UE, int. UE (intermediate UE), etc.

[0058] <Device Types> For A-IoT devices, the following three device types are defined: Device 1, Device 2a, and Device 2b.

[0059] Device 1 (may be referred to as Type 1) Device 1 is a device type that consumes power with a peak power of 1 μW or less. Device 1 has energy storage and has an initial sampling frequency offset (SFO) of up to Z [ppm (parts per million)] (where Z is 10 to the power of x (where x is a non-negative integer)). Also, there is no DL or UL amplification in Device 1. UL transmission in Device 1 is performed by backscatter of an externally supplied carrier wave (CW), i.e., an unmodulated wave.

[0060] Device 2a (may be referred to as Type 2a) Device 2a is a device type that consumes power with a peak power of several hundred μW. Device 2a has energy storage and an initial sampling frequency offset of up to Z [ppm] (where Z is 10 to the power of x (where x is a non-negative integer)). DL and / or UL amplification is also performed in Device 2a. UL transmission in Device 2a is performed by backscattering in CW provided externally.

[0061] Device 2b (may be referred to as Type 2b) Device 2b is a device type that consumes power with a peak power of several hundred μW. Device 2b has energy storage and an initial sampling frequency offset of up to Z [ppm] (where Z is 10 to the power of x (where x is a non-negative integer)). DL and / or UL amplification is also performed in Device 2b. UL transmission in Device 2b is performed internally within Device 2b. In other words, UL transmission in Device 2b does not have to be performed by backscattering in CW provided externally.

[0062] <Candidate Topologies> Next, we will explain the candidate topologies for CW / R2D / D2R transmission.

[0063] Figure 8 shows examples of candidate topologies for CW / R2D / D2R transmission in Topology 1. Figure 8 shows topologies 1A, 1B, 1C, 1D, and 1E as examples of candidate topologies.

[0064] As shown in Figure 8, in topologies 1A to 1E, CW / R2D communication signals (sometimes referred to as "R2D" in Figure 8 and below) and D2R communication signals (sometimes referred to as "D2R" in Figure 8 and below) can be transmitted to and received from A-IoT devices.

[0065] In this embodiment, DL and R2D (reader to device) may be interchangeable, and UL and D2R (device to reader) may be interchangeable. Here, reader corresponds to BS and / or intermediate UE, and device corresponds to A-IoT device.

[0066] In topology 1A, the node transmitting CW (first BS) is different from the node receiving D2R communication signals transmitted by backscatter by the A-IoT device (second BS), while the node transmitting CW is the same as the node transmitting R2D communication signals. Also, the node transmitting R2D communication signals is different from the node receiving D2R communication signals transmitted by backscatter by the A-IoT device. In other words, the R in R2D and the R in D2R are different.

[0067] In topology 1B, the node transmitting CW (BS), the node transmitting R2D communication signals, and the node receiving D2R communication signals transmitted by backscatter from the A-IoT device are all the same.

[0068] In topology 1C, the node transmitting CW (CW node) is different from the node transmitting R2D communication signals (BS). Also in topology 1C, the node transmitting CW is different from the node receiving D2R communication signals transmitted by backscatter by A-IoT devices (BS). Also in topology 1C, the node transmitting R2D communication signals is the same as the node receiving D2R communication signals transmitted by backscatter by A-IoT devices. In other words, the R in R2D and the R in D2R are the same. Note that the CW node may be a BS / (intermediate) UE / IAB node / NCR (network-controlled repeater) node / relay node / other type of node.

[0069] In topology 1D, the node (BS) that transmits R2D communication signals is the same node that receives D2R communication signals generated and transmitted by the A-IoT device. In other words, the R in R2D and the R in D2R are the same.

[0070] In topology 1E, the node that transmits the R2D communication signal (first BS) is different from the node that receives the D2R communication signal generated and transmitted by the A-IoT device (second BS). In other words, the R in R2D and the R in D2R are different.

[0071] Figure 9 shows examples of candidate topologies for CW / R2D / D2R transmission in Topology 2. Figure 9 shows topologies 2A, 2B, 2C, 2D, and 2E as examples of candidate topologies.

[0072] As shown in Figure 9, in topologies 2A to 2E, CW / R2D communication signals (labeled "R2D" in Figure 9) and D2R communication signals (labeled "D2R" in Figure 9) can be transmitted to and received from A-IoT devices.

[0073] In topology 2A, the node transmitting CW (first intermediate UE) is different from the node receiving D2R communication signals transmitted by backscatter by the A-IoT device (second intermediate UE), while the node transmitting CW is the same as the node transmitting R2D communication signals. Also, the node transmitting R2D communication signals is different from the node receiving D2R communication signals transmitted by backscatter by the A-IoT device. In other words, the R in R2D and the R in D2R are different.

[0074] In topology 2B, the node transmitting CW (intermediate UE), the node transmitting R2D communication signals, and the node receiving D2R communication signals transmitted by backscatter from A-IoT devices are all the same.

[0075] In topology 2C, the node transmitting CW (CW node) is different from the node transmitting R2D communication signals (intermediate UE). Also, in topology 1C, the node transmitting CW is different from the node receiving D2R communication signals transmitted by backscatter from the A-IoT device (BS). Also, in topology 1C, the node transmitting R2D communication signals is the same as the node receiving D2R communication signals transmitted by backscatter from the A-IoT device. In other words, the R in R2D and the R in D2R are the same. Note that the CW node may be a BS / (intermediate) UE / IAB node / NCR node / relay node / other type of node.

[0076] In topology 2D, the node that transmits R2D communication signals (intermediate UE) is the same node that receives D2R communication signals generated and transmitted by the A-IoT device. In other words, the R in R2D and the R in D2R are the same.

[0077] In topology 2E, the node that transmits the R2D communication signal (first intermediate UE) is different from the node that receives the D2R communication signal generated and transmitted by the A-IoT device (second intermediate UE). In other words, the R in R2D and the R in D2R are different.

[0078] <Explanation of Terms> Here, we will summarize and explain the terms related to A-IoT mentioned above.

[0079] A-IoT device or device: A device included in an A-IoT system that has one of the above-mentioned types of devices.

[0080] • Leader: The D2R receiver leader may be either a BS or a UE. The UE acting as the leader may also be called an intermediate UE. • The R2D transmitter and D2R receiver may be on the same node or on different nodes.

[0081] - R2D: Abbreviation for Reader-to-Device link. - PRDCH: Abbreviation for physical R2D channel. - D2R: Abbreviation for Device-to-Reader link. - PRDCH: Abbreviation for physical D2R channel.

[0082] DT traffic: This is an abbreviation for Device Terminated traffic. DT traffic is, for example, traffic that sends commands from a reader to a device and terminates at the device.

[0083] - DO-DTT traffic: Device Originated-Device Terminated Trigger - DO-DTT traffic is, for example, "inventory" traffic.

[0084] • DO-A traffic: Device Originated Autonomous Traffic • DO-A traffic includes, for example, traffic from sensors and monitoring systems.

[0085] The timing acquisition signal, preamble, midamble, postamble, and synchronization signal can be substituted for each other.

[0086] <Access Procedure for A-IoT Devices> In an A-IoT communication session, an access procedure for A-IoT devices (hereinafter also simply referred to as devices) is executed. Two approaches are being considered for the A-IoT device access procedure: a two-step approach and a four-step approach.

[0087] Figure 10 shows an example of an access procedure for an A-IoT device. Figure 10 shows the exchange of signals between one reader and one device. The horizontal axis in Figure 10 represents the time axis. Figure 10 shows exchanges including a two-step access procedure and a four-step access procedure.

[0088] In the two-step access procedure, the reader sends an A-IoT paging message. The A-IoT paging message corresponds to the first R2D transmission in the A-IoT communication session. The device that receives the A-IoT paging message sends a message called A-IoT Msg1 to the reader. In the two-step access procedure, A-IoT Msg1 contains information that identifies the device (e.g., device ID). A-IoT Msg1 can also be considered a device ID report. The reader that receives A-IoT Msg1 sends a message called A-IoT Msg2 to the device. For example, the reader that receives A-IoT Msg1 sends an A-IoT Msg2 addressed to the device indicated by the device ID contained in A-IoT Msg1. A-IoT Msg2 contains information indicating contention resolution. A-IoT Msg2 can be considered as Contention Resolution. The two-step access procedure is then complete.

[0089] In the four-step access procedure, the reader sends an A-IoT paging message. A device that receives the A-IoT paging message sends a message called A-IoT Msg1 to the reader. In the four-step access procedure, A-IoT Msg1 contains a random ID. A-IoT Msg1 can also be considered a random ID report. Upon receiving A-IoT Msg1, the reader sends a message called A-IoT Msg2 to the device. For example, an A-IoT reader sends A-IoT Msg2 containing the random ID included in A-IoT Msg1. A-IoT Msg2 contains information indicating a contention resolution. A-IoT Msg2 can also be considered a contention resolution. The device receives A-IoT Msg2 and sends A-IoT Msg3 to the reader. For example, the device sends A-IoT Msg3 to the reader if the random ID of the received A-IoT Msg2 matches the random ID of the transmitted A-IoT Msg1. In the four-step access procedure, A-IoT Msg3 contains information that identifies the device (e.g., device ID). A-IoT Msg3 can also be considered a device ID report. Upon receiving A-IoT Msg3, the reader sends a response (e.g., R2D response). The four-step access procedure is then completed. However, in the four-step access procedure, the reader that receives A-IoT Msg3 does not have to send a response (e.g., R2D response).

[0090] For example, in the "inventory" use case, such as checking the location of an A-IoT device, each communication session includes only the two-step access procedure or the four-step access procedure described above. Note that the "inventory" use case is not limited to checking the location of an A-IoT device.

[0091] For example, in an "inventory + command" use case that includes checking the location of an A-IoT device and issuing instructions to the A-IoT device, as shown in Figure 10, each communication session sends an R2D command message and a D2R response after the two-step or four-step access procedure described above.

[0092] Furthermore, in the exchange including the access procedure shown in Figure 10, a contention-based access procedure, such as slotted-ALOHA, may be applied to at least A-IoT Msg1.

[0093] In an A-IoT communication session, a single A-IoT paging message may be sent to multiple devices. Multiple devices that have received a single A-IoT paging message may then continue with subsequent transmissions / receptions within the communication session. These subsequent transmissions / receptions may include, as shown in Figure 10, at least one of the following: sending A-IoT Msg1, receiving A-IoT Msg2, sending A-IoT Msg3, receiving an R2D response, receiving an R2D command message, and sending a D2R response.

[0094] In the interactions including the access procedure shown in Figure 10, etc., A-IoT paging, A-IoT Msg1, A-IoT Msg2, and A-IoT Msg3 may be abbreviated as paging, Msg1, Msg2, and Msg3, respectively. Also, A-IoT paging, A-IoT Msg1, A-IoT Msg2, and A-IoT Msg3 may be associated with names other than these.

[0095] The message type may be any of the following: A-IoT paging, A-IoT Msg1, A-IoT Msg2, A-IoT Msg3, R2D response, R2D command message, or D2R response. The R2D response may be omitted. The message type may be interchangeable with the notation "message." The term "message" may be interchangeable with notations such as "signal" or "information." For example, sending / receiving a message may be interchangeable with sending / receiving a signal. The R2D command message may also be referred to as R2D data.

[0096] In the following, we will primarily use a four-step access procedure and "inventory+command" communication as examples. However, this disclosure is not limited to these. This disclosure may also be applied to a two-step access procedure or to "inventory" communication. The example of "inventory + command" communication corresponds to a case in which R2D command messages and D2R responses are sent / received after the four-step access procedure.

[0097] Furthermore, in the following description, one or more steps (e.g., processing) may be omitted (or skipped). For example, in the case of a two-step approach as described above, the transmission / reception of A-IoT Msg3 may be omitted. Also, in the case of "inventory" communication as described above, the R2D command message and D2R response may be omitted.

[0098] Furthermore, any of the above message types may be sent via unicast, multicast, broadcast, or groupcast.

[0099] <Procedures based on agreements> Rel-19 considers use cases related to inventory and command, as well as DO-DTT and DT traffic. For these use cases / traffic types, the following steps 1 and 2 are considered.

[0100] 1. In the case of "inventory only": Step A: The reader sends A-IoT paging to the device. Step B: The device sends its device ID to the reader (via Random Access (RA), or without using RA).

[0101] 2. In the case of "inventory and command": Step A: The reader sends A-IoT paging to the device. Step B: The device sends its device ID to the reader (via Random Access (RA), or without using RA). Step C: The reader sends data to the device (e.g., R2D command). Step D: The corresponding device sends data to the reader (e.g., feedback). It is yet to be determined whether Step D is optional or not.

[0102] Furthermore, at the 3GPP RAN2#126 meeting, the following steps were agreed upon in relation to the procedure described above.

[0103] [3GPP RAN2#126 Agreement (Command Procedure)] 1. If "inventory only" is the baseline, the following procedure is supported: - Step A: A-IoT paging - Step B: Sending device ID (via Random Access (RA) or without RA). Details are TBD.

[0104] 2. For "inventory and command" as the baseline, the following steps will be supported: - Step A: A-IoT paging - Step B: Sending device ID (via Random Access (RA) or without RA). Details are TBD. - Step C: Sending data from reader to device (e.g., R2D command), and - Step D: Sending data from corresponding device to reader (e.g., feedback). Whether this is optional is TBD and awaits discussion in other working groups.

[0105] For an example where random access (RA) is not used, please refer to Figure 13.

[0106] <Random Access (RA) Based on Agreements> The following steps 1 and 2 are being considered for random access.

[0107] 1.4 Steps (or 3 Steps) (See Figure 11) ・A-IoT Msg1: The device sends an ID to the reader. The ID is a random ID generated by the device. The size of the random ID is fixed and is 16 bits. ・A-IoT Msg2: The reader echoes the ID received in Msg1. ・A-IoT Msg3: The device sends the device ID and / or other higher-layer data (as requested by the higher layer). ・The device considers the conflict resolution to have been successful when it receives Msg2 containing the same random ID as Msg1. ・"Msg4" (i.e., subsequent R2D transmissions after D2R transmissions) do not always need to be sent with random access. "Msg4" may be considered to handle failures of Msg3 transmission (for various reasons).

[0108] 2.2 Step (See Figure 12) - A-IoT Msg1: The device transmits the device ID and / or other higher-layer data (as required by the higher layer). A random ID (fixed 16 bits) may be additionally included in Msg1. - A-IoT Msg2: If Msg1 contains a random ID, the reader echoes the ID received in Msg1.

[0109] Furthermore, at the 3GPP RAN2 #126 and #127 meetings, the following steps were agreed upon in relation to the procedures described above.

[0110] [3GPP RAN2#126 "4-Step" RA Agreement] 1. A-IoT Msg1: The device sends an ID to the reader. The ID is a random ID generated by the device (the generation method is undetermined; for example, it may be randomly generated or based on the device ID). The ID size is undetermined. This does not exclude other information agreed upon in RAN1. 2. A-IoT Msg2: The reader echoes the ID received in Msg1. Based on the agreement in RAN1, Msg2 may contain further information. 3. A-IoT Msg3: The device sends the device ID and / or other higher-layer data (as required by the higher layer). 4. The device considers the conflict resolution successful when it receives Msg2 containing the same random ID as Msg1. RAN2 assumes that the size of the random ID in Msg1 is sufficient for the purpose of conflict resolution. 5. "Msg4" (i.e., the R2D transmission following a D2R transmission) does not always need to be transmitted with random access. "Msg4" may be considered to handle the failure of Msg3 transmission (for various reasons). The use / existence of "Msg4" may be further discussed. RAN2 does not use the term "Msg4" for further consideration of random access.

[0111] [3GPP RAN2#126 Agreement on 2-Step CB RA] 1. A-IoT Msg1: The device transmits a device ID and / or other higher-level data (as requested by the higher layer). What the device ID is is TBD. Whether an additional random ID is needed is TBD. This does not preclude any other information agreed upon in RAN1. 2. A-IoT Msg2: The reader may echo some information from Msg1. What that information is is TBD. The use / existence of "Msg2" may be further discussed.

[0112] [3GPP RAN2#127 Agreement (3-step CBRA)] - For 3-step CBRA (Contention-Based Random Access) support, the fixed random ID size is 16 bits. IDs are generated randomly. - Indication of D2R failure / success is being considered. It is undecided whether D2R failure / success indication will be implicit or explicit, and under what circumstances it will be required. It is also undecided whether D2R failure / success indication will apply only in certain cases.

[0113] [3GPP RAN2#127 Agreement (2-step CBRA)] ・In the case of 2-step CBRA, the RAN2 specification supports Msg2. Whether it is necessary is up to the reader. If it is necessary, it is TBD. In the case of 2-step CBRA (if Msg2 is required), the random ID (fixed 16 bits) is also included in A-IoT Msg1 and echoed to A-IoT Msg2. If there are devices that only support 2-step RA, it is TBD whether other optimizations will be required for such devices. ・In contention-free access, after being triggered, the A-IoT device directly sends higher-layer data (such as device ID) in the first D2R message (i.e., skips conflict resolution Msg1 / 2). Whether a short AS ID is also included in the message, and what type of ID is included for scheduling purposes, is TBD. ・If the reader assigns an AS ID for scheduling purposes, it is TBD.

[0114] <Consideration Item 1> In considering A-IoT from Rel-19 onwards, in addition to the inventory and command use cases mentioned above, a use case in which an A-IoT device reports sensor information to a reader is listed as one of the A-IoT use cases. In the use case in which an A-IoT device reports sensor information to a reader, in addition to the DT and DO-DTT traffic types, a traffic type called DO-A (Device Originated Autonomous) may be considered.

[0115] (Characteristics of the DO-A scenario) In both the DT and DO-DTT traffic types, the A-IoT device transmits D2R data triggered by the reader. In contrast, in the DO-A traffic type, the A-IoT device generates D2R data traffic without an R2D command.

[0116] However, in this type of DO-A traffic, the network / reader may not know in advance whether the A-IoT device has a D2R data buffer, nor may it know the amount of data in the A-IoT device's D2R data buffer. Furthermore, the specific procedure by which the A-IoT device requests D2R transmission requests or D2R resources from the reader for D2R data transmission remains undetermined.

[0117] Therefore, in the DO-A traffic type, it is necessary to consider the procedure by which an A-IoT device requests a D2R transmission request or D2R resource from the reader.

[0118] Therefore, in this embodiment, Proposal 1 proposes a procedure for an A-IoT device to send a D2R transmission request or a D2R resource request to a reader in the DO-A traffic type. <Consideration 2> Also, in the DO-A traffic type, D2R message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ However, the specific procedures for triggering / canceling these features are still undecided and require further consideration.

[0119] Therefore, in Proposal 2 of this embodiment, in the DO-A traffic type, the A-IoT device receives D2R message X Ｄ２Ｒ / D2R Message Y Ｄ２ＲWe propose messages / events for triggering / canceling the procedure. <Consideration 3> Also, in the random access procedure in the DO-A traffic type, if the random access procedure is performed without setting constraints, all A-IoT devices that receive the R2D message that triggers the random access procedure will send Msg1.

[0120] However, considering the DO-A scenario, A-IoT devices that do not have D2R data to transmit do not need to perform the random access procedure, and only A-IoT devices that have D2R data to transmit should need to perform the random access procedure. Furthermore, preventing A-IoT devices that do not need the random access procedure from performing it would be beneficial in reducing Msg1 collisions.

[0121] Therefore, it is necessary to define the behavior of the A-IoT device regarding whether or not it sends Msg1.

[0122] Therefore, in Proposal 3 of this embodiment, we propose the conditions for the A-IoT device to transmit Msg1.

[0123] For illustrative purposes, the communication flow of the communication session shown in Figure 10 will be considered in this study. Furthermore, as an example, the following explanation assumes that the device can monitor only a single frequency band (or single frequency bandwidth).

[0124] In this embodiment, "frequency," "frequency resource," and "frequency domain resource" may be interchangeable. Also, in this embodiment, "signal monitoring" may be interchangeable with "signal reception."

[0125] Furthermore, in this embodiment, "R2D," "R2D signal," "R2D message," and "R2D message type" may be substituted for each other. Also, in this embodiment, "D2R," "D2R signal," "D2R message," and "D2R message type" may be substituted for each other.

[0126] The matters described in the following proposals may be combined as appropriate, provided that they do not create contradictions.

[0127] In the following proposals, the options may be combined as appropriate.

[0128] In the following proposals, different options may be applied on a case-by-case basis.

[0129] In the following proposal, indication / configuration may be transmitted by physical (PHY) layer control information or higher-layer payloads (e.g., MAC (Medium Access Control) layer control information, Msg0 (paging), Msg2 (RAR (Random Access Response)), Msg4, unicast data, etc.).

[0130] In the following proposal, the terminology used in R2D may have the same meaning as described above.

[0131] In the following proposal, the display / configuration may be transmitted by PRDCH or R2D timing acquisition signals (preamble / midamble / postamble) / synchronization signals.

[0132] In the following proposal, a slot may be a time interval of 1 ms (i.e., one slot in OFDM), a slotted ALOHA, or any other unit of time domain consisting of one or more symbols.

[0133] In the following proposal, the symbol may be a single OFDM symbol, an OOK M chip, or a single PSF / FSK modulation symbol.

[0134] In the following proposals, different alternatives / options may be applied to R2D and D2R.

[0135] In the following proposals, different alternatives / options may be applied depending on the device type.

[0136] In the following proposals, different connection topologies may be subject to different alternatives / options.

[0137] In the following proposals, different alternatives / options may be applied to different R2D / D2R channels (PRDCH: PHY channel for R2D control, PDRCH: PHY channel for D2R control).

[0138] In the following proposals, different R2D / D2R information / formats / commands (R2D data, R2D control, R2D system information, R2D information that triggers contention-based access, D2R data, D2R control, D2R ACK / NACK responses, D2R responses in contention-based access (Msg1 / Msg3)) may be subject to different alternatives / options.

[0139] In the following, "CW / R2D / D2R transmission" may also be referred to as communication in a wireless communication system including an A-IoT device, communication of an A-IoT device, communication with an A-IoT device, communication involving an A-IoT device, etc.

[0140] In the following, notifications may be carried in the Physical (PHY) layer / MAC layer / RRC (Radio Resource Control) layer / new layers defined for A-IoT.

[0141] <Proposal 1> (D2R message) The A-IoT device sends a D2R message like the following 1-2, and the reader receives the D2R message.

[0142] 1. D2R Message X Ｄ２Ｒ This is a message "like an SR (scheduling request)" and provides information about (1) and (2) below. (1) D2R message X Ｄ２Ｒ This indicates whether the A-IoT device has a D2R data buffer. (2) D2R message X Ｄ２Ｒ This indicates whether the A-IoT device requests resources for D2R transmission (Tx).

[0143] 2. D2R Message YＤ２Ｒ is a message like "BSR (buffer status report)" and indicates information regarding the following (1) to (2). (1) D2R message Y Ｄ２Ｒ indicates the amount of the D2R data buffer of the A-IoT device (the amount of data in the data buffer that the A-IoT device transmits by D2R). (2) D2R message Y Ｄ２Ｒ indicates the number of resources requested by the A-IoT device for D2R transmission (Tx).

[0144] Note that D2R message X Ｄ２Ｒ / D2R message Y Ｄ２Ｒ may be L1 information or upper layer information.

[0145] This Proposal 1 can affect both the operation of the A-IoT device and the operation of the intermediate UE.

[0146] (Mapping to the size of the D2R data buffer) In the case of the report related to the D2R message Y in 2. (1) described above Ｄ２Ｒ the problem is how to indicate the "size of the D2R data buffer" in the report.

[0147] Therefore, as a method for indicating the size of the D2R data buffer, Option 0 of Proposal 1 will be described, and hereinafter, Option 0-1 to Option 0-3 will be sequentially described.

[0148] (Option 0) In the D2R message Y Ｄ２Ｒ report, the D2R data buffer size may be indicated in a predetermined method.

[0149] (Option 0-1) In the D2R message Y Ｄ２Ｒ report, the D2R data buffer size may be indicated in bit unit / plurality of bit units / byte unit / plurality of byte units.

[0150] When using code points to indicate the size of a D2R data buffer, it is necessary to define a mapping from the code points to the size of the D2R data buffer. However, it is not necessary to map code points to all possible values ​​of the D2R data buffer size, and such mapping can introduce overhead.

[0151] Therefore, in options 0-2 to 0-3 of Proposal 1, the following mapping is assumed.

[0152] (Option 0-2) D2R Message Y Ｄ２Ｒ In the report, each code point may be mapped to a value of the D2R data buffer size.

[0153] For example, code points 0 through M may be mapped to D2R data buffer sizes of 0 through M bits / byte, respectively.

[0154] (Options 0-3) D2R Message Y Ｄ２Ｒ In the report, the range of D2R data buffer sizes may be mapped as follows: • Code point 0 is mapped to a D2R data buffer size of 0 to M1 bits / byte. • Code point 1 is mapped to a D2R data buffer size of M1 to M2 bits / byte. • Code point 2 is mapped to a D2R data buffer size of M2 to M3 bits / byte. • And so on.

[0155] (Effects of Option 0) According to Option 0 of Proposal 1, overhead can be prevented and the A-IoT device can efficiently transmit reports by indicating the size of the D2R data buffer in an appropriate manner in the report related to the D2R message YD2R.

[0156] Next, regarding the D2R transmission type / format / channel, Option 1 of Proposal 1 will be explained below.

[0157] (Option 1) The A-IoT device transmits D2R message X using the D2R transmission type / format / channel shown in (Option 1-a) to (Option 1-d) below. Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ The leader sends the D2R message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ You may receive it.

[0158] (Option 1-1) The A-IoT device transmits D2R messages X by a specific type / format / channel of D2R transmission (Tx). Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ It may be transmitted.

[0159] The specific type / format / channel may be a different type / format / channel from the D2R data.

[0160] The D2R message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ The transmission (Tx) is a specific type of R2D message X Ｒ２Ｄ / R2D Message Y Ｒ２Ｄ Scheduled by R2D message X Ｒ２Ｄ This is D2R message X Ｄ２Ｒ It supports the transmission (Tx) scheduling of R2D message Y Ｒ２Ｄ This is D2R message Y Ｄ２Ｒ Supports transmission (Tx) scheduling.

[0161] R2D Message X Ｒ２Ｄ / R2D Message Y Ｒ２Ｄ This refers to the D2R message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ It provides resources for sending (Tx) the D2R message X. Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ It is used specifically for sending (Tx).

[0162] (Options 1-2) The A-IoT device sends D2R messages X using the same D2R transmission (Tx) type / format / channel as the D2R data. Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ It may be transmitted.

[0163] D2R Message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ The transmission (Tx) may be scheduled by the same R2D message that schedules the D2R data.

[0164] Furthermore, R2D message Z provides resources for D2R transmission (Tx). These resources include D2R data and / or D2R message X. Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ It can be used for: That is, D2R transmission (Tx) is either D2R data only, or D2R message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ Only, or D2R data and D2R message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ This means that both can be transmitted.

[0165] (Options 1-3) The A-IoT device receives D2R message X via D2R Msg3 in a 4-step (3-step) random access procedure. Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ It may be transmitted.

[0166] The A-IoT device may transmit the device ID and D2R data, and / or D2R messages X / Y, by sending Msg3 D2R.

[0167] (Options 1-4) The A-IoT device receives D2R message X via D2R Msg1 in a two-step random access procedure. Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ It may be transmitted.

[0168] The A-IoT device transmits a random ID, device ID, and D2R data, and / or D2R message X via Msg1 D2R transmission.Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ It may be transmitted.

[0169] (Effect of Option 1) According to Option 1 of Proposal 1, D2R message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ By assuming that D2R messages will be transmitted using various types / formats / channels depending on the procedure, D2R messages can be transmitted in a flexible manner according to the procedure. Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ It can be sent.

[0170] (Options 2-5: Procedures a-d) Next, regarding the procedures for signal exchange between A-IoT devices and readers in the DO-A traffic type, Options 2-5 of Proposal 1 will be described in order below.

[0171] (Option 2: Details of Procedure a) The A-IoT device / reader applies the following procedure (hereinafter referred to as "Procedure a") to the DO-A scenario.

[0172] Step 1: The A-IoT device receives R2D message X Ｒ２Ｄ / R2D Message Y Ｒ２Ｄ Received (sent by the reader).

[0173] R2D Message X Ｒ２Ｄ / R2D Message Y Ｒ２Ｄ This is D2R message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ Schedule the transmission and provide the resources.

[0174] Step 2: The A-IoT device receives D2R message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ Send (received by the reader).

[0175] Step 3: The A-IoT device receives (sent by the reader) R2D message Z.

[0176] R2D message Z schedules the transmission of D2R data and provides resources.

[0177] Step 4: The A-IoT device transmits (and the reader receives) the D2R data.

[0178] (Option 2: Example of Procedure a) Figure 14 shows an example of Procedure a in Option 2 of Proposal 1. Figure 14 shows the signal exchange between the reader and the device in a four-step procedure.

[0179] In Step 1, the leader sends an R2D message X to the A-IoT device. Ｒ２Ｄ / R2D Message Y Ｒ２Ｄ Send R2D Message X. Ｒ２Ｄ / R2D Message Y Ｒ２Ｄ The A-IoT device that received R2D message X Ｒ２Ｄ / R2D Message Y Ｒ２Ｄ Therefore, D2R message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ The transmission is scheduled and the resources are provided.

[0180] In step 2, the A-IoT device sends a D2R message X to the reader. Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ Send the following: Here, D2R message X Ｄ２Ｒ This is a message like an SR (scheduling request) and contains information indicating whether the A-IoT device has a D2R data buffer or whether the A-IoT device is requesting resources for D2R transmission (Tx). Also, D2R message Y Ｄ２Ｒ This is a message like a BSR (buffer status report) and contains information indicating the amount of data in the A-IoT device's D2R data buffer, or the number of resources the A-IoT device requested for D2R transmission (Tx). The reader receives D2R message X. Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ Upon receiving this information, the system recognizes the status of the D2R data buffer and resource requests of the A-IoT device.

[0181] In step 3, the leader transmits the R2D message Z. When the A-IoT device receives the R2D message Z (transmitted by the leader), the transmission of D2R data is scheduled by the R2D message Z, and resources are provided.

[0182] In step 4, the A-IoT device transmits D2R data to the leader. Thus, procedure a is completed.

[0183] (Option 2: Variation of procedure a) The R2D message X Ｒ２Ｄ / R2D message Y Ｒ２Ｄ in step 1 of option 2 (procedure a) of Proposal 1 Ｄ２Ｒ / D2R message Y Ｄ２Ｒ may provide periodic resources to the D2R message X

[0184] As described above, when periodic resources are provided to the D2R message X Ｄ２Ｒ / D2R message Y Ｄ２Ｒ the A-IoT device may receive (the leader transmits) / monitor the R2D message X Ｒ２Ｄ / R2D message Y Ｒ２Ｄ on the periodic resources in step 1.

[0185] (Example of the implementation of option 2: Variation of procedure a) FIG. 18 shows an example when periodic resources are provided to the D2R message X Ｄ２Ｒ / D2R message Y Ｄ２Ｒ in step 2 of option 2 (procedure a) of Proposal 1. FIG. 18 shows the signal exchange between the leader and the device in steps 1 and 2 of procedure a.

[0186] In step 1, the leader transmits the R2D message X Ｒ２Ｄ / R2D message Y Ｒ２Ｄ to the A-IoT device, schedules the periodic transmission of the D2R message X Ｄ２Ｒ / D2R message Y Ｄ２Ｒ in the A-IoT device, and provides periodic resources for the transmission.

[0187] In step 2, the A-IoT device periodically sends the D2R message X Ｄ２Ｒ / D2R message Y Ｄ２Ｒ to the leader. The leader recognizes the status of the D2R data buffer of the A-IoT device and the resource requests by periodically receiving the D2R message X Ｄ２Ｒ / D2R message Y Ｄ２Ｒ .

[0188] Note that after step 3, it is the same as the above (Option 2: Example of Procedure a).

[0189] (Option 2: Effect of Procedure a) According to Option 2 (Procedure a) of Proposal 1, in the traffic type of DO-A, the procedure for the A-IoT device to send the D2R message X Ｄ２Ｒ / D2R message Y Ｄ２Ｒ is clarified including variations, so that the A-IoT device can send the D2R message X Ｄ２Ｒ / D2R message Y Ｄ２Ｒ in a flexible form.

[0190] (Option 3: Details of Procedure b) The A-IoT device / leader applies the following procedure (hereinafter referred to as "Procedure b") to the DO-A scenario.

[0191] - Step 1: The A-IoT device receives the R2D message Z (sent by the leader).

[0192] The R2D message Z schedules the D2R transmission and provides resources. The scheduled D2R can be used for D2R data and / or the D2R message X Ｄ２Ｒ / D2R message Y Ｄ２Ｒ .

[0193] - Step 2: The A-IoT device sends the D2R (received by the leader).

[0194] In D2R, one or more of the following can be transmitted. - D2R upper layer data - D2R message X Ｄ２Ｒ - D2R message Y Ｄ２Ｒ

[0195] Furthermore, an A-IoT device can transmit multiple of the above in a single D2R transmission. For example, an A-IoT device can transmit D2R data and D2R message X in a single D2R transmission. Ｄ２Ｒ Both, or D2R data and D2R message Y Ｄ２Ｒ It can transmit both.

[0196] Regarding the transmission of R2D messages Z and R2D, the following two options 3-1 and 3-2 may also be considered.

[0197] (Option 3-1) In step 1 above, the reader may instruct the A-IoT device to explicitly send a D2R in the R2D message Z.

[0198] (Option 3-2) In step 1 above, the A-IoT device that receives the R2D message Z may decide which D2R to send depending on the situation.

[0199] (Option 3: Example of Procedure b) Figure 15 shows an example of Procedure b in Option 3 of Proposal 1. Figure 15 shows the signal exchange between the reader and the device in a two-step procedure.

[0200] In step 1, the reader sends R2D message Z to the A-IoT device. Upon receiving R2D message Z, the A-IoT device schedules the transmission of D2R data and provides resources.

[0201] In step 2, the A-IoT device sends a D2R to the reader. With a single D2R transmission, the A-IoT device sends D2R data (D2R upper layer data), D2R data and D2R message X. Ｄ２Ｒ Both D2R data and D2R message Y Ｄ２Ｒ Both, D2R message X Ｄ２Ｒ , or D2R message Y Ｄ２Ｒ One of the following transmission methods can be performed. With this, step b is complete.

[0202] Figure 15 shows that after steps 1 and 2 of procedure b are completed, steps 1 and 2 of procedure b are executed a second time.

[0203] (Option 3: Variation of Procedure b) In Option 3 (Procedure b) of Proposal 1, #1: The R2D message Z in Step 1 may provide D2R with a periodic resource.

[0204] As described above, if periodic resources are provided to D2R, the A-IoT device may receive (or send, if a reader sends) / monitor R2D messages Z on the periodic resources in step 1.

[0205] In Option 3 (Procedure b) of Proposal 1, #2: In Step 2, only D2R data may be transmitted in D2R. In this case, unlike the original Procedure b, D2R message X Ｄ２Ｒ / Y will not be sent.

[0206] (Option 3: Example of a variation of procedure b) Figure 19 shows an example in Option 3 (procedure b) of Proposal 1 where periodic resources are provided to D2R in step 2. Figure 19 shows the signal exchange between the reader and the device in steps 1 and 2 of procedure b.

[0207] In step 1, the reader sends an R2D message Z to the A-IoT device, scheduling periodic D2R transmissions in the A-IoT device and providing periodic resources for those transmissions.

[0208] In step 2, the A-IoT device sends D2R (D2R data / D2R message X) to the reader. Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ It periodically sends ).

[0209] (Option 3: Effect of Procedure b) According to Option 3 (Procedure b) of Proposal 1, in the DO-A traffic type, the A-IoT device sends D2R message X Ｄ２Ｒ / D2R Message Y Ｄ２ＲThe procedure for sending D2R messages has been clarified, including variations, allowing A-IoT devices to send D2R messages X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ It can be sent in a flexible format.

[0210] (Option 4: Details of Procedure c) The A-IoT device / reader applies the following procedure (hereinafter referred to as "Procedure c") to the DO-A scenario.

[0211] Step 1: The A-IoT device receives R2D message A (sent by the reader).

[0212] R2D message A triggers a random access procedure.

[0213] Step 2: The A-IoT device sends Msg1 (the reader receives it).

[0214] Step 3: The A-IoT device receives Msg2 (sent by the reader).

[0215] Step 4: The A-IoT device sends Msg3 (the reader receives it).

[0216] In addition to the device ID, Msg3 may include one or more of the following: • D2R upper layer data • D2R message X Ｄ２Ｒ D2R Message Y Ｄ２Ｒ

[0217] Step 5-1: The A-IoT device receives Msg4 (sent by the reader).

[0218] Step 5-2: The leader sends an R2D message (R2D Message X) to the A-IoT device. Ｒ２Ｄ / R2D Message Y Ｒ２Ｄ Send R2D message Z.

[0219] Regarding the transmission of R2D messages Z and R2D, the following two options 4-1 and 4-2 may also be considered.

[0220] (Option 4-1) In step 5-2 above, the reader may instruct the A-IoT device to explicitly send a D2R in the R2D message Z.

[0221] (Option 4-2) In step 5-2 above, the A-IoT device that receives the R2D message Z may decide which D2R to send depending on the circumstances.

[0222] Steps 5-1 and 5-2 may be performed as separate R2D transmissions or as a single R2D transmission.

[0223] Step 6: The A-IoT device sends D2R (D2R data / D2R message X) to the reader. Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ ) Send.

[0224] Steps 5-2 and 6 may be the same as steps 3 and 4 of procedure a, or steps 1 and 2 of procedure b.

[0225] Messages 1, 2, and 4 may be the same as those described in <A-IoT Device Access Procedure>.

[0226] (Option 4: Example of Procedure c) Figure 16 shows an example of Procedure c in Option 4 of Proposal 1. Figure 16 shows the signal exchange between the reader and the device in a six-step procedure.

[0227] In Step 1, the reader sends R2D message A to the A-IoT device. Upon receiving R2D message A, the A-IoT device triggers a random access procedure.

[0228] In step 2, the A-IoT device sends Msg1 to the reader. Msg1 contains a random ID (fixed 16 bits).

[0229] In step 3, the reader sends Msg2 to the A-IoT device by echoing the random ID (fixed 16 bits) received in Msg1. The A-IoT device considers the conflict resolution to have been successful if the received Msg2 contains the random ID sent in Msg1.

[0230] In step 4, the A-IoT device sends Msg3 to the reader. Upon sending Msg3, the A-IoT device receives the device ID, D2R data (D2R upper layer data), D2R data and D2R message X. Ｄ２Ｒ Both D2R data and D2R message Y Ｄ２Ｒ Both, D2R message X Ｄ２Ｒ , or D2R message Y Ｄ２Ｒ One of the following transmission methods is possible.

[0231] In step 5-1, the leader sends Msg4 as a response to receiving Msg3.

[0232] In step 5-2, the reader sends R2D message Z. Steps 5-1 and 5-2 may be separate R2D transmissions or may be combined into a single R2D transmission. When the A-IoT device receives R2D message Z, the R2D message Z schedules the transmission of D2R data and provides resources.

[0233] In step 6, the A-IoT device sends a D2R to the reader. In a single D2R transmission, the A-IoT device sends D2R data (D2R upper layer data), D2R data, and D2R message X. Ｄ２Ｒ Both D2R data and D2R message Y Ｄ２Ｒ Both, D2R message X Ｄ２Ｒ , or D2R message Y Ｄ２Ｒ One of the following transmissions can be performed. Here, steps 5-2 and 6 may be the same as steps 3 and 4 of procedure a, or steps 1 and 2 of procedure b. With this, procedure c is completed.

[0234] (Option 4: Variation of Procedure c) In Option 4 (Procedure c) of Proposal 1, #1: R2D message A in Step 1 may provide periodic resources for sending Msg1 (Tx).

[0235] As described above, if a periodic resource is provided for the transmission (Tx) of Msg1, the A-IoT device may receive (the reader transmits) / monitor R2D message A on the periodic resource in step 1.

[0236] #2 in Option 4 (Procedure c) of Proposal 1: In Step 4, only the random ID and / or the device ID and / or D2R data may be transmitted via D2R. In this case, unlike the original Procedure c, D2R message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ It will not be sent.

[0237] (Option 4: Effect of Procedure c) According to Option 4 (Procedure c) of Proposal 1, in the DO-A traffic type, the A-IoT device sends D2R message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ The procedure for sending D2R messages has been clarified, including variations, allowing A-IoT devices to send D2R messages X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ It can be sent in a flexible format.

[0238] (Option 5: Details of step d) The A-IoT device / reader applies the following procedure (hereinafter referred to as "step d") to the DO-A scenario.

[0239] Step 1: The A-IoT device receives R2D message A (sent by the reader).

[0240] R2D message A triggers a random access procedure.

[0241] Step 2: The A-IoT device sends Msg1 (the reader receives it).

[0242] In addition to the random ID and device ID, Msg1 may include one or more of the following: • D2R upper layer data • D2R message X Ｄ２Ｒ D2R Message Y Ｄ２Ｒ

[0243] Step 3-1: The A-IoT device receives Msg2 (sent by the reader).

[0244] Msg2 may be the same as the one described in <A-IoT Device Access Procedure>.

[0245] Step 3-2: The leader sends an R2D message (R2D Message X) to the A-IoT device. Ｒ２Ｄ / R2D Message Y Ｒ２Ｄ Send R2D message Z.

[0246] Regarding the transmission of R2D messages Z and R2D, the following two options 5-1 and 5-2 may also be considered.

[0247] (Option 5-1) In step 3-2 above, the reader may instruct the A-IoT device to explicitly send a D2R in the R2D message Z.

[0248] (Option 5-2) In step 3-2 above, the A-IoT device that receives the R2D message Z may decide which D2R to send depending on the situation.

[0249] Steps 3-1 and 3-2 may be performed as separate R2D transmissions or as a single R2D transmission.

[0250] Step 4: The A-IoT device sends D2R (D2R Data / D2R Message X) to the reader. Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ ) Send.

[0251] Note that steps 3-2 and 4 may be the same as steps 3 and 4 of procedure a, or steps 1 and 2 of procedure b.

[0252] (Option 5: Example of Procedure d) Figure 17 shows an example of Procedure d in Option 5 of Proposal 1. Figure 17 shows the signal exchange between the reader and the device in a five-step procedure.

[0253] In Step 1, the reader sends R2D message A to the A-IoT device. Upon receiving R2D message A, the A-IoT device triggers a random access procedure.

[0254] In step 2, the A-IoT device sends Msg1 to the reader. Msg1 contains a random ID (fixed 16 bits) and a device ID, as well as D2R data (D2R upper layer data), D2R data, and D2R message X. Ｄ２Ｒ Both D2R data and D2R message Y Ｄ２Ｒ Both, D2R message X Ｄ２Ｒ , or D2R message Y Ｄ２Ｒ It may include any of the following.

[0255] In step 3-1, if the reader receives Msg1, it sends Msg2 to the A-IoT device by echoing the random ID (a fixed 16-bit ID). The A-IoT device considers the conflict resolution to be successful if it receives Msg2 and it contains the random ID sent in Msg1.

[0256] In step 3-2, the reader sends R2D message Z. Steps 3-1 and 3-2 may be separate R2D transmissions or may be combined into a single R2D transmission. When the A-IoT device receives R2D message Z, the R2D message Z schedules the transmission of D2R data and provides resources.

[0257] In step 4, the A-IoT device sends a D2R to the reader. In a single D2R transmission, the A-IoT device sends D2R data (D2R upper layer data), D2R data, and D2R message X. Ｄ２Ｒ Both D2R data and D2R message Y Ｄ２Ｒ Both, D2R message X Ｄ２Ｒ, or D2R message Y Ｄ２Ｒ Either of the following transmissions may be performed. Also, steps 3-2 and 4 may be the same as steps 3 and 4 of procedure a, or steps 1 and 2 of procedure b. With the above, procedure d is completed.

[0258] (Option 5: Variation of Procedure d) In Option 5 (Procedure d) of Proposal 1, #1: R2D message A in Step 1 may provide periodic resources for sending Msg1 (Tx).

[0259] As described above, if a periodic resource is provided for the transmission (Tx) of Msg1, the A-IoT device may receive (the reader transmits) / monitor R2D message A on the periodic resource in step 1.

[0260] #2 in Option 5 (Procedure d) of Proposal 1: In Step 2, either the random ID and / or the device ID and / or the D2R data may be transmitted via D2R. In this case, unlike the original Procedure d, D2R message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ It will not be sent.

[0261] (Option 5: Effect of Procedure d) According to Option 5 (Procedure d) of Proposal 1, in the DO-A traffic type, the A-IoT device sends D2R message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ The procedure for sending D2R messages has been clarified, including variations, allowing A-IoT devices to send D2R messages X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ It can be sent in a flexible format.

[0262] <Proposal 2> Next, in Proposal 2, in the DO-A traffic type, the A-IoT device receives D2R message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ This section describes the messages / events used to trigger / cancel reports.

[0263] Proposal 2: The A-IoT device receives D2R message XＤ２Ｒ / D2R Message Y Ｄ２Ｒ The messages / events for triggering / canceling the report are as follows: <Proposal 2-1> and <Proposal 2-2>.

[0264] <Proposal 2-1> D2R Message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ The A-IoT device report is D2R message X according to Proposal 1. Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ The following triggers may occur:

[0265] (Option 1) D2R Message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ The A-IoT device report may be triggered "by an R2D message".

[0266] In Option 1 of Proposal 2-1, D2R message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ The A-IoT device report may be triggered when a specific R2D message is received. Here, a specific R2D message is, for example, the following: Example: R2D message X in step a of Proposal 1 Ｒ２Ｄ / R2D Message Y Ｒ２Ｄ - Example: R2D message Z for step b of Proposal 1 - Example: R2D message A for step d of Proposal 1 - Example: R2D Msg. 2 for random access procedure - Example: R2D A - IoT paging

[0267] (Option 2) D2R Message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ The A-IoT device report may be triggered "by an event".

[0268] In Option 2 of Proposal 2-1, D2R message X Ｄ２Ｒ / D2R Message Y Ｄ２ＲThe A-IoT device report may be triggered "by a specific event." Here, the specific event that triggers the device report is, for example, one of the following options 2-1 to 2-6.

[0269] (Option 2-1) D2R Message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ The A-IoT device report may be triggered when "D2R data arrives (when traffic occurs in higher layers, etc.)."

[0270] (Option 2-2) D2R Message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ The A-IoT device report may be triggered "if the amount of data contained in the D2R data buffer is not zero."

[0271] (Option 2-3) D2R Message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ The A-IoT device report may be triggered "when the amount of data contained in the D2R data buffer is greater than threshold: X".

[0272] (Option 2-4) D2R Message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ The A-IoT device report may be triggered "when the configured timer expires."

[0273] In Option 2-4 of Proposal 2, D2R message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ The A-IoT device report is triggered when a specific timer is set and that timer expires. The timer that is set is as follows:

[0274] • Periodic timers: A-IoT devices use D2R message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ The periodic timer may be started after the transmission.

[0275] • Retransmission timer: A-IoT devices use D2R message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ The retransmission timer may be started after the initial transmission.

[0276] A-IoT devices use D2R message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ The retransmission timer may be started after receiving an R2D response (for example, an R2D message scheduling the transmission (Tx) of D2R data).

[0277] (Option 2-5) D2R Message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ The A-IoT device report states that "a D2R resource has been allocated to the D2R sent by the A-IoT device, and the D2R resource is D2R message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ This may be triggered if there are sufficient resources to send it.

[0278] (Option 2-6) D2R Message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ The A-IoT device report states that "D2R resources are allocated to the D2R transmitted by the A-IoT device, and the remaining D2R resources (padding bits after multiplexing the D2R data) after multiplexing the D2R data are used in D2R message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ This may be triggered if there are sufficient resources to send it.

[0279] This proposal 2-1 may affect the operation of A-IoT devices.

[0280] (Variation of Option 2) In Option 2 of Proposal 2-1, when a D2R resource is allocated to a D2R transmitted by an A-IoT device, if that D2R resource is sufficient to transmit all D2R data awaiting transmission, the A-IoT device may refrain from sending (triggering) a device report to request additional D2R resources.

[0281] Furthermore, due to a newly occurring event, the A-IoT device received D2R message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ If it is determined that sending a report is unnecessary or impossible, the system may choose not to send (not trigger) the report.

[0282] (Effects of Proposal 2-1) According to Proposal 2-1, in the DO-A traffic type, the A-IoT device sends D2R message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ The D2R Message X has been clarified, including variations, regarding the messages / events that trigger the report. Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ This makes it easier to anticipate the triggers for sending reports, and also improves the usability of those reports.

[0283] <Proposal 2-2> D2R Message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ The A-IoT device report is D2R message X according to Proposal 1. Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ In contrast, it can be canceled as follows:

[0284] (Option 1) D2R Message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ The A-IoT device report may be canceled when an R2D message is received.

[0285] In Option 1 of Proposal 2-2, when the A-IoT device receives a specific R2D message that implicitly or explicitly indicates cancellation, it receives a D2R message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ You may cancel the sending of the A-IoT device report.

[0286] (Option 2) D2R Message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ The A-IoT device report may be canceled when an event occurs.

[0287] In Option 2 of Proposal 2-2, when the reader allocates a D2R resource, if the D2R resource has sufficient resources to send all D2R data awaiting transmission, the A-IoT device will send D2R message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ You may cancel the sending of the A-IoT device report.

[0288] For example, if the allocated D2R resources are sufficient to transmit all the data in the D2R data buffer, the A-IoT device may cancel sending a device report to the reader, as it does not need to send a device report requesting additional D2R resources.

[0289] (Variation of Option 2) In Option 2 of Proposal 2-2, a newly occurring event causes the A-IoT device to send D2R message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ If it is determined that sending a device report related to the above is unnecessary or impossible, the sending of the report may be canceled.

[0290] This proposal 2-2 may affect the operation of A-IoT devices.

[0291] (Effects of Proposal 2-2) According to Proposal 2-2, in the DO-A traffic type, the A-IoT device receives D2R message X Ｄ２Ｒ / D2R Message Y Ｄ２ＲThe message / event for canceling a report has been clarified, including variations, resulting in D2R Message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ This can suppress the transmission and reception of unnecessary signals related to this.

[0292] <Proposal 3> Next, in Proposal 3, we will explain the conditions for the A-IoT device to send Msg1.

[0293] Proposal 3: When an A-IoT device receives an R2D message that triggers a random access procedure, under certain conditions, it may send Msg1.

[0294] The specific conditions in Proposal 3 may be as follows:

[0295] (Option 1-1) If the A-IoT device has D2R data waiting to be sent, the A-IoT device may send Msg1 when it receives an R2D message that triggers a random access procedure.

[0296] (Option 1-2) "According to Proposal 1 / 2, D2R message X Ｄ２Ｒ / D2R Message Y Ｄ２Ｒ If the report is triggered, the A-IoT device may send Msg1 when it receives an R2D message that triggers a random access procedure.

[0297] (Option 2) Whether the A-IoT device receives an R2D message that triggers a random access procedure and sends Msg. 1 may depend on the type of R2D message.

[0298] For example, the fact that an A-IoT device may receive an R2D message that triggers a random access procedure and send Msg. 1 depending on the type of R2D message could be as follows: • Example: When R2D message A is received, the above conditions may apply. • Example: When R2D message B is received, all A-IoT devices may send Msg1. • Example: When R2D message B is received, and certain conditions (different from those above) are met, A-IoT may send Msg1.

[0299] R2D messages A and B can be distinguished by their display within the R2D preamble, R2D L1 control, R2D upper layer control, or payload.

[0300] (Effects of Proposal 3) According to Proposal 3, the transmission of unnecessary Msg1 from A-IoT devices can be suppressed, thereby reducing Msg1 collisions in random access procedures.

[0301] <Device Configuration> Next, the configuration of the base station 10 and the device 20 will be described. Note that the configuration of the base station 10 and the device 20 described below is an example of a function related to this embodiment. The base station 10 and the device 20 may have functions not shown. Furthermore, the function classification and / or the name of the function unit are not limited as long as the function performs the operation according to this embodiment.

[0302] <Base Station Configuration> Figure 20 is a block diagram showing an example of the configuration of a base station 10 according to an embodiment. The base station 10 includes, for example, a transmitting unit 101, a receiving unit 102, and a control unit 103. The base station 10 communicates wirelessly with the device 20 (see Figure 21). The base station 10 may be a terminal (an intermediate UE that communicates with the device 20) or a CW node.

[0303] The transmitting unit 101 transmits a downlink (DL) signal to the device 20. For example, the transmitting unit 101 transmits the DL signal under the control of the control unit 103.

[0304] The DL signal may include, for example, data signals for the downlink and control information (e.g., DCI (Downlink Control Information)). The DL signal may also include information indicating the scheduling of signal transmission for device 20 (e.g., UL grant). Furthermore, the DL signal may include control information from higher layers (e.g., RRC (Radio Resource Control) control information). The DL signal may also include a reference signal.

[0305] The channels used to transmit DL signals include, for example, a data channel and a control channel. For example, the data channel may include a PDSCH (Physical Downlink Shared Channel), and the control channel may include a PDCCH (Physical Downlink Control Channel). For example, base station 10 transmits control information to device 20 using the PDCCH and transmits downlink data signals using the PDSCH.

[0306] The reference signals included in the DL signal may include, for example, at least one of the following: DMRS (Demodulation Reference Signal), PTRS (Phase Tracking Reference Signal), CSI-RS (Channel State Information-Reference Signal), SRS (Sounding Reference Signal), and PRS (Positioning Reference Signal) for position information. For example, reference signals such as DMRS and PTRS are used for demodulating the data signal of the downlink and are transmitted using PDSCH.

[0307] The receiving unit 102 receives the uplink (UL) signal transmitted from the device 20. For example, the receiving unit 102 receives the UL signal under the control of the control unit 103.

[0308] The control unit 103 controls the communication operations of the base station 10, including the transmission process of the transmission unit 101 and the reception process of the reception unit 102.

[0309] For example, the control unit 103 acquires information such as data and control information from the upper layer and outputs it to the transmission unit 101. The control unit 103 also outputs the data and control information received from the receiving unit 102 to the upper layer.

[0310] For example, the control unit 103 allocates resources (or channels) used for transmitting and receiving DL signals and / or resources used for transmitting and receiving UL signals based on signals received from the device 20 (e.g., data and control information, etc.) and / or data and control information, etc. acquired from higher layers. Information regarding the allocated resources may be included in the control information transmitted to the device 20.

[0311] The control unit 103 sets a PUCCH resource as an example of resource allocation for transmitting and receiving UL signals. Information regarding PUCCH settings, such as the PUCCH cell timing pattern (PUCCH setting information), may be notified to the device 20 by RRC.

[0312] Here, the transmitting unit 101 and the receiving unit 102 (which may be collectively referred to as the communication unit) communicate with the device 20.

[0313] For example, the transmitting unit 101 may transmit information regarding frequency resources used for communication involving the A-IoT device to the device 20 or the like.

[0314] Furthermore, for example, the communications unit may use the above-mentioned frequency resources to perform communications involving A-IoT devices.

[0315] <Device Configuration> Figure 21 is a block diagram showing an example of the configuration of a device 20 according to an embodiment. The device 20 includes, for example, a receiving unit 201, a transmitting unit 202, and a control unit 203. The device 20 communicates wirelessly with, for example, a base station 10. The device 20 may be a terminal (for example, an intermediate UE) or a CW node.

[0316] The receiving unit 201 receives DL signals transmitted from the base station 10. For example, the receiving unit 201 receives DL signals under the control of the control unit 203.

[0317] The transmitting unit 202 transmits the UL signal to the base station 10. For example, the transmitting unit 202 transmits the UL signal under the control of the control unit 203.

[0318] The UL signal may include, for example, data signals for the uplink and control information (e.g., UCI (Uplink Control Information)). It may also include, for example, information regarding the processing capability of device 20 (e.g., A-IoT capability). Furthermore, the UL signal may include a reference signal.

[0319] The channels used to transmit UL signals include, for example, a data channel and a control channel. For example, the data channel may include PUSCH (Physical Uplink Shared Channel), and the control channel may include PUCCH (Physical Uplink Control Channel). For example, device 20 transmits control information from base station 10 using PUCCH and transmits uplink data signals using PUSCH.

[0320] The reference signals included in the UL signal may include, for example, at least one of DMRS, PTRS, CSI-RS, SRS, and PRS. For example, reference signals such as DMRS and PTRS are used for demodulating the uplink data signal and are transmitted using an uplink channel (e.g., PUSCH).

[0321] The control unit 203 controls the communication operation of the device 20, including the receiving process in the receiving unit 201 and the transmitting process in the transmitting unit 202.

[0322] For example, the control unit 203 acquires information such as data and control information from the upper layer and outputs it to the transmission unit 202. The control unit 203 also outputs data and control information received from the receiving unit 201 to the upper layer.

[0323] For example, the control unit 203 controls the transmission of information to be fed back to the base station 10. The information to be fed back to the base station 10 may include, for example, HARQ ACK / NACK, Channel State Information (CSI), or Scheduling Request (SR). The information to be fed back to the base station 10 may also be included in the UCI. The UCI is transmitted, for example, in the PUCCH resource.

[0324] The control unit 203 sets up PUCCH resources based on the setting information received from the base station 10 (for example, setting information such as the PUCCH cell timing pattern notified by RRC and / or DCI). The control unit 203 determines the PUCCH resource to be used to transmit the information to be fed back to the base station 10. The transmission unit 202 transmits the information to be fed back to the base station 10 using the PUCCH resource determined by the control unit 203, under the control of the control unit 203.

[0325] The channels used for transmitting DL signals and UL signals are not limited to the examples described above. For example, the channels used for transmitting DL signals and UL signals may include RACH (Random Access Channel) and PBCH (Physical Broadcast Channel). RACH may be used, for example, for transmitting DCI including RA-RNTI (Random Access Radio Network Temporary Identifier).

[0326] Here, the receiving unit 201 and the transmitting unit 202 (which may be collectively referred to as the communication unit) communicate with the base station 10, intermediate UE, and other network components.

[0327] For example, the receiving unit 201 may receive information from the base station 10 and the intermediate UE network regarding the frequency resources used for communication involving the A-IoT device, and the control unit 203 may determine the frequency resources used for communication involving the A-IoT device based on the information received by the receiving unit 201. The frequency resources used for communication involving the A-IoT device may be a single frequency resource, a series of consecutive frequency resources, a series of non-consecutive frequency resources, or may include a first frequency resource used in a first frequency hop and a second frequency resource used in a second frequency hop.

[0328] Furthermore, for example, the communication unit may use the frequency resources determined by the control unit 203 to perform communication involving the A-IoT device.

[0329] This concludes the explanation of this disclosure. The division of items in the above explanation is not essential to this disclosure, and matters described in two or more items may be combined as needed, and matters described in one item may be applied to matters described in another item (as long as they do not contradict each other).

[0330] <Hardware Configuration, etc.> The block diagram used in the description of the above embodiment shows functional units. These functional blocks (components) are realized by any combination of at least one of hardware and software. Furthermore, the method of realizing each functional block is not particularly limited. That is, each functional block may be realized using one device that is physically or logically coupled, or it may be realized using two or more physically or logically separated devices that are directly or indirectly connected (for example, using wired, wireless, etc.). A functional block may be realized by combining the above one device or the above multiple devices with software.

[0331] Functions include, but are not limited to, judgment, decision, judgment, calculation, calculation, processing, derivation, investigation, exploration, confirmation, reception, transmission, output, access, resolution, selection, selection, establishment, comparison, assumption, expectation, assumption, broadcasting, notifying, communicating, forwarding, configuring, reconfiguring, allocating (mapping), and assigning. For example, a functional block (configuration part) that enables transmission is called a transmitting unit or transmitter. In all cases, as mentioned above, the method of implementation is not particularly limited.

[0332] For example, a base station, device, etc. in one embodiment of the present disclosure may function as a computer that processes the wireless communication method of the present disclosure. Figure 22 is a diagram showing an example of the hardware configuration of a base station and device according to an embodiment. The base station 10 and device 20 described above may be physically configured as a computer device including a processor 1001, memory 1002, storage 1003, communication device 1004, input device 1005, output device 1006, bus 1007, etc.

[0333] In the following explanation, the term "device" can be replaced with "circuit," "device," "unit," etc. The hardware configuration of the base station 10 and device 20 may include one or more of the devices shown in the figure, or it may be configured without some of the devices.

[0334] Each function in the base station 10 and device 20 is realized by loading predetermined software (programs) onto hardware such as the processor 1001 and memory 1002, which allows the processor 1001 to perform calculations and control communication by the communication device 1004, or control at least one of reading and writing data in the memory 1002 and storage 1003.

[0335] Processor 1001 controls the entire computer by operating, for example, an operating system. Processor 1001 may be constituted by a central processing unit (CPU: Central Processing Unit) including an interface with peripheral devices, a control device, an arithmetic device, registers, and the like. For example, the above-described control unit 103 and control unit 203 may be realized by processor 1001.

[0336] Further, processor 1001 reads a program (program code), software module, data, etc. from at least one of storage 1003 and communication device 1004 into memory 1002, and executes various processes according thereto. As the program, a program for causing a computer to execute at least a part of the operations described in the above embodiments is used. For example, the control unit 103 of base station 10 and the control unit 203 of device 20 may be stored in memory 1002 and realized by a control program operating in processor 1001, and other functional blocks may be realized in the same manner. Although it has been described that the above various processes are executed by one processor 1001, they may be executed simultaneously or sequentially by two or more processors 1001. Processor 1001 may be mounted by one or more chips. Note that the program may be transmitted from a network via a telecommunication line.

[0337] Memory 1002 is a computer-readable recording medium and may be constituted by at least one of, for example, ROM (Read Only Memory), EPROM (Erasable Programmable ROM), EEPROM (Electrically Erasable Programmable ROM), RAM (Random Access Memory), and the like. Memory 1002 may be referred to as a register, a cache, a main memory (main storage device), and the like. Memory 1002 can store a program (program code), software module, etc. executable for implementing the wireless communication method according to an embodiment of the present disclosure.

[0338] Storage 1003 is a computer-readable recording medium, which may be composed of, for example, at least one of an optical disk such as a CD-ROM (Compact Disc ROM), a hard disk drive, a flexible disk, a magneto-optical disk (e.g., a compact disc, a digital versatile disc, a Blu-ray (registered trademark) disc), a smart card, a flash memory (e.g., a card, a stick, a key drive), a floppy (registered trademark) disk, a magnetic strip, etc. Storage 1003 may be called an auxiliary storage device. The above-mentioned storage medium may be, for example, a database, a server, or other appropriate media including at least one of the memory 1002 and the storage 1003.

[0339] Communication device 1004 is hardware (a transmission / reception device) for performing communication between computers via at least one of a wired network and a wireless network, and is also referred to as, for example, a network device, a network controller, a network card, a communication module, etc. Communication device 1004 may be configured to include, for example, a high-frequency switch, a duplexer, a filter, a frequency synthesizer, etc. to realize at least one of frequency division duplex (FDD: Frequency Division Duplex) and time division duplex (TDD: Time Division Duplex). For example, the above-mentioned transmission unit 101, reception unit 102, reception unit 201, and transmission unit 202, etc. may be realized by the communication device 1004.

[0340] Input device 1005 is an input device (e.g., a keyboard, a mouse, a microphone, a switch, a button, a sensor, etc.) for receiving an external input. Output device 1006 is an output device (e.g., a display, a speaker, an LED lamp, etc.) for performing an output to the external. Note that the input device 1005 and the output device 1006 may have an integrated configuration (e.g., a touch panel).

[0341] Furthermore, each device, such as the processor 1001 and memory 1002, is connected by a bus 1007 for communicating information. The bus 1007 may be configured using a single bus, or different buses may be configured for each device.

[0342] Furthermore, the base station 10 and the device 20 may be configured to include hardware such as a microprocessor, a digital signal processor (DSP), an ASIC (Application Specific Integrated Circuit), a PLD (Programmable Logic Device), and an FPGA (Field Programmable Gate Array), and some or all of each functional block may be realized by such hardware. For example, the processor 1001 may be implemented using at least one of these hardware components.

[0343] <Notification of Information, Signaling> Notification of information is not limited to the embodiments described herein and may be carried out by other methods. For example, notification of information may be carried out by physical layer signaling (e.g., DCI (Downlink Control Information), UCI (Uplink Control Information)), upper layer signaling (e.g., RRC (Radio Resource Control) signaling, MAC (Medium Access Control) signaling, broadcast information (MIB (Master Information Block), SIB (System Information Block))), other signals, or combinations thereof. RRC signaling may also be called RRC messages, and may be, for example, RRC Connection Setup messages, RRC Connection Reconfiguration messages, etc.

[0344] <Applicable Systems> The embodiments described in this disclosure include LTE (Long Term Evolution), LTE-A (LTE-Advanced), SUPER 3G, IMT-Advanced, 4G (4th generation mobile communication system), 5G (5th generation mobile communication system), 6th generation mobile communication system (6G), xth generation mobile communication system (xG) (xG (where x is, for example, an integer or decimal)), FRA (Future Radio Access), NR (new Radio), New radio access (NX), Future generation radio access (FX), W-CDMA (registered trademark), GSM (registered trademark), CDMA2000, UMB (Ultra Mobile Broadband), IEEE 802.11 (Wi-Fi (registered trademark)), IEEE 802.16 (WiMAX (registered trademark)), IEEE 802.20 may apply to at least one system utilizing UWB (Ultra-WideBand), Bluetooth®, or other appropriate systems, and to next-generation systems extended, modified, created, or defined based thereon. Alternatively, multiple systems may be applied in combination (e.g., a combination of at least one of LTE and LTE-A with 5G).

[0345] <Processing Procedures, etc.> The processing procedures, sequences, flowcharts, etc., of each aspect / embodiment described in this disclosure may be rearranged in order, as long as there is no contradiction. For example, the methods described in this disclosure present various step elements using exemplary order and are not limited to the specific order presented.

[0346] <Base Station Operation> The specific operations described in this disclosure as being performed by a base station may, in some cases, be performed by its upper node. In a network consisting of one or more network nodes having a base station, it is clear that various operations performed for communication with a terminal can be performed by the base station and at least one other network node (for example, an MME or S-GW, but not limited to these). The above example illustrates the case where there is one other network node besides the base station, but it may also be a combination of multiple other network nodes (for example, an MME and an S-GW).

[0347] <Direction of Input / Output> Information, etc. (see the section on <Information, Signals>) can be output from a higher layer (or lower layer) to a lower layer (or higher layer). Input and output may also occur via multiple network nodes.

[0348] <Handling of Input / Output Information, etc.> Input and output information, etc. may be stored in a specific location (e.g., memory) or managed using a management table. Input and output information, etc. may be overwritten, updated, or appended to. Output information, etc. may be deleted. Input information, etc. may be transmitted to other devices.

[0349] <Determination Method> The determination may be made by a value represented by one bit (0 or 1), by a boolean value (true or false), or by a numerical comparison (for example, a comparison with a predetermined value).

[0350] <Variations of Embodiments, etc.> Each embodiment / appearance described in this disclosure may be used individually, in combination, or switched between during implementation. Furthermore, notification of predetermined information (for example, notification that "it is X") is not limited to explicit notification, but may also be implicit (for example, by not providing notification of the predetermined information).

[0351] Although the present disclosure has been described in detail above, it will be clear to those skilled in the art that the present disclosure is not limited to the embodiments described herein. The present disclosure can be implemented in modified and altered forms without departing from the intent and scope of the present disclosure as defined by the claims. Therefore, the descriptions in the present disclosure are illustrative and not intended to be restrictive in any way.

[0352] <Software> Software should be broadly interpreted to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, executable files, execution threads, procedures, functions, etc., whether they are called software, firmware, middleware, microcode, hardware description languages, or by any other name.

[0353] Furthermore, software, instructions, information, etc., may be transmitted and received via a transmission medium. For example, if software is transmitted from a website, server, or other remote source using at least one of wired technology (such as coaxial cable, fiber optic cable, twisted pair, or digital subscriber line (DSL)) and wireless technology (such as infrared or microwave), then at least one of these wired and wireless technologies is included in the definition of a transmission medium.

[0354] <Information, Signals> The information, signals, etc. described in this disclosure may be represented using any of the various different techniques. For example, data, instructions, commands, information, signals, bits, symbols, chips, etc., which may be referred to throughout the above description may be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, optical fields or photons, or any combination thereof.

[0355] In addition, terms used in this disclosure and terms necessary for understanding this disclosure may be replaced with terms having the same or similar meanings. For example, at least one of the channel and symbol may be a signal (signaling). Also, a signal may be a message. Furthermore, a component carrier (CC) may be called a carrier frequency, cell, frequency carrier, etc.

[0356] <Systems and Networks> The terms “systems” and “networks” as used in this disclosure are interchangeable.

[0357] <Parameters, Channel Names> Furthermore, the information, parameters, etc. described in this disclosure may be expressed using absolute values, relative values ​​from a predetermined value, or other corresponding information. For example, wireless resources may be indicated by an index.

[0358] The names used for the parameters described above are not restrictive in any way. Furthermore, the formulas and other expressions using these parameters may differ from those expressly disclosed in this disclosure. Various channels (e.g., PUCCH, PDCCH, etc.) and information elements can be identified by any suitable name, and therefore, the various names assigned to these various channels and information elements are not restrictive in any way.

[0359] <Base Station> In this disclosure, terms such as "Base Station (BS)", "wireless base station", "fixed station", "NodeB", "eNodeB (eNB)", "gNodeB (gNB)", "access point", "transmission point", "reception point", "transmission / reception point", "cell", "sector", "cell group", "carrier", and "component carrier" may be used interchangeably. Base stations may also be referred to by terms such as macrocell, small cell, femtocell, and picocell.

[0360] A base station can accommodate one or more (e.g., three) cells. If a base station accommodates multiple cells, the entire coverage area of ​​the base station can be divided into multiple smaller areas, each of which may also be provided with communication services by a base station subsystem (e.g., a Remote Radio Head (RRH)). The terms “cell” or “sector” refer to part or all of the coverage area of ​​at least one of the base station and / or base station subsystems that provide communication services in that coverage.

[0361] In this disclosure, the transmission of information by a base station to a terminal may be interpreted as the base station instructing the terminal to perform control or operation based on the information.

[0362] <Mobile Station> In this disclosure, terms such as "Mobile Station (MS)", "user terminal", "User Equipment (UE)", and "terminal" may be used interchangeably.

[0363] A mobile station may also be referred to by those skilled in the art as a subscriber station, mobile unit, subscriber unit, wireless unit, remote unit, mobile device, wireless device, wireless communication device, remote device, mobile subscriber station, access terminal, mobile terminal, wireless terminal, remote terminal, handset, user agent, mobile client, client, or several other appropriate terms.

[0364] <Base Station / Mobile Station> At least one of a base station and a mobile station may be called a transmitting device, a receiving device, a communication device, etc. At least one of a base station and a mobile station may be a device mounted on a mobile body, the mobile body itself, etc. The mobile body refers to a movable object, and its speed of movement is arbitrary. This also includes cases where the mobile body is stationary. The mobile body includes, but is not limited to, vehicles, transport vehicles, automobiles, motorcycles, bicycles, connected cars, excavators, bulldozers, wheel loaders, dump trucks, forklifts, trains, buses, handcarts, rickshaws, ships and other watercraft, airplanes, rockets, satellites, drones (registered trademark), multicopters, quadcopters, balloons, and items mounted on them. The mobile body may also be a mobile body that moves autonomously based on operation commands. It may be a vehicle (e.g., a car, an airplane, etc.), an unmanned mobile body (e.g., a drone, an autonomous vehicle, etc.), or a robot (manned or unmanned). Furthermore, at least one of the base station and the mobile station may include devices that do not necessarily move during communication operations. For example, at least one of the base station and the mobile station may be an IoT (Internet of Things) device such as a sensor.

[0365] Furthermore, the term "base station" in this disclosure may be interpreted as "terminal." For example, the embodiments of this disclosure may be applied to a configuration in which communication between a base station and a terminal is replaced with communication between multiple terminals (which may be called, for example, D2D (Device-to-Device), V2X (Vehicle-to-Everything)). In this case, the device 20 may have the functions that the base station 10 has. Also, terms such as "uplink" and "downlink" may be interpreted as terms corresponding to terminal-to-terminal communication (for example, "side"). For example, uplink channel, downlink channel, etc., may be interpreted as side channel.

[0366] Similarly, the term "terminal" in this disclosure may be replaced with "base station." In this case, the base station 10 may be configured to have the same functions as the device 20 described above.

[0367] Figure 23 shows an example of the configuration of vehicle 2001. As shown in Figure 23, vehicle 2001 includes a drive unit 2002, a steering unit 2003, an accelerator pedal 2004, a brake pedal 2005, a shift lever 2006, front wheels 2007, rear wheels 2008, an axle 2009, an electronic control unit 2010, various sensors 2021 to 2029, an information service unit 2012, and a communication module 2013. Each aspect / embodiment described in this disclosure may be applied to a communication device mounted on vehicle 2001, for example, to the communication module 2013.

[0368] The drive unit 2002 consists of, for example, an engine, a motor, or a hybrid of an engine and a motor. The steering unit 2003 includes at least a steering wheel (also called a handle) and is configured to steer at least one of the front wheels and the rear wheels based on the operation of the steering wheel, which is operated by the user.

[0369] The electronic control unit 2010 is composed of a microprocessor 2031, a memory (ROM, RAM) 2032, and a communication port (IO port) 2033. Signals from various sensors 2021 to 2029 provided in the vehicle 2001 are input to the electronic control unit 2010. The electronic control unit 2010 may also be referred to as an ECU (Electronic Control Unit).

[0370] Signals from various sensors 2021 to 2029 include a current signal from a current sensor 2021 that senses the current of the motor, a rotational speed signal of the front or rear wheels acquired by a rotational speed sensor 2022, an air pressure signal of the front or rear wheels acquired by an air pressure sensor 2023, a vehicle speed signal acquired by a vehicle speed sensor 2024, an acceleration signal acquired by an acceleration sensor 2025, a depression amount signal of an accelerator pedal acquired by an accelerator pedal sensor 2029, a depression amount signal of a brake pedal acquired by a brake pedal sensor 2026, an operation signal of a shift lever acquired by a shift lever sensor 2027, a detection signal for detecting obstacles, vehicles, pedestrians, etc. acquired by an object detection sensor 2028, and the like.

[0371] The information service unit 2012 is composed of various devices for providing (outputting) various information such as driving information, traffic information, and entertainment information, such as a car navigation system, an audio system, speakers, a television, and a radio, and one or more ECUs for controlling these devices. The information service unit 2012 uses the information acquired from an external device via a communication module 2013 or the like to provide various multimedia information and multimedia services to the passengers of the vehicle 2001.

[0372] The information service unit 2012 may include an input device (for example, a keyboard, a mouse, a microphone, a switch, a button, a sensor, a touch panel, etc.) for receiving an external input, or may include an output device (for example, a display, speakers, an LED lamp, a touch panel, etc.) for performing an external output.

[0373] The driver assistance system unit 2030 consists of various devices that provide functions to prevent accidents or reduce the driver's workload, such as millimeter-wave radar, LiDAR (Light Detection and Ranging), cameras, positioning locators (e.g., GNSS), map information (e.g., high-definition (HD) maps, autonomous vehicle (AV) maps), gyro systems (e.g., IMU (Inertial Measurement Unit), INS (Inertial Navigation System)), AI (Artificial Intelligence) chips, and AI processors, as well as one or more ECUs that control these devices. The driver assistance system unit 2030 also transmits and receives various information via the communication module 2013 to realize driver assistance functions or autonomous driving functions.

[0374] The communication module 2013 can communicate with the microprocessor 2031 and components of the vehicle 2001 via its communication port. For example, the communication module 2013 sends and receives data via the communication port 2033 between the drive unit 2002, steering unit 2003, accelerator pedal 2004, brake pedal 2005, shift lever 2006, front wheels 2007, rear wheels 2008, axle 2009, the microprocessor 2031 and memory (ROM, RAM) 2032 in the electronic control unit 2010, and sensors 2021-29 provided in the vehicle 2001.

[0375] The communication module 2013 is a communication device that can be controlled by the microprocessor 2031 of the electronic control unit 2010 and can communicate with external devices. For example, it can send and receive various types of information with external devices via wireless communication. The communication module 2013 may be located either inside or outside the electronic control unit 2010. The external device may be, for example, a base station or a mobile station.

[0376] The communication module 2013 may transmit at least one of the following to an external device via wireless communication: signals from the various sensors 2021 to 2029 input to the electronic control unit 2010, information obtained based on said signals, and information based on input from an external source (user) obtained via the information service unit 2012. The electronic control unit 2010, the various sensors 2021 to 2029, the information service unit 2012, etc., may also be called input units that accept input. For example, the PUSCH transmitted by the communication module 2013 may include the information based on the above input.

[0377] The communication module 2013 receives various information (traffic information, signal information, inter-vehicle information, etc.) transmitted from an external device and displays it on the information service unit 2012 provided in the vehicle 2001. The information service unit 2012 may also be called an output unit, which outputs information (for example, it outputs information to devices such as displays and speakers based on the PDSCH (or data / information decoded from the PDSCH) received by the communication module 2013).

[0378] Furthermore, the communication module 2013 stores various information received from external devices in a memory 2032 that can be used by the microprocessor 2031. Based on the information stored in the memory 2032, the microprocessor 2031 may control the drive unit 2002, steering unit 2003, accelerator pedal 2004, brake pedal 2005, shift lever 2006, front wheels 2007, rear wheels 2008, axles 2009, sensors 2021 to 2029, etc., which are provided in the vehicle 2001.

[0379] <Meaning and Interpretation of Terms> As used in this disclosure, the terms “determining” and “determining” may encompass a wide variety of actions. “Determining” may include, for example, judging, calculating, computing, processing, deriving, investigating, looking up, search, inquiry (e.g., searching in tables, databases or other data structures), and ascertaining. “Determining” may also include, for example, receiving (e.g., receiving information), transmitting (e.g., sending information), input, output, and accessing (e.g., accessing data in memory). Furthermore, "judgment" and "decision" can include considering something as having "judgmented" or "decided" after resolving, selecting, choosing, establishing, comparing, etc. In other words, "judgment" and "decision" can include considering something as having "judgmented" or "decided" about some action. Also, "judgment (decision)" can be reinterpreted as "assuming," "expecting," or "considering."

[0380] The terms “connected,” “coupled,” and any variations thereof mean any direct or indirect connection or coupling between two or more elements, and may include the presence of one or more intermediate elements between two elements that are “connected” or “coupled” with each other. The coupling or connection between elements may be physical, logical, or a combination thereof. For example, “connection” may be reinterpreted as “access.” As used in this disclosure, two elements may be considered to be “connected” or “coupled” with each other using at least one of one or more wires, cables, and printed electrical connections, and, in some non-limiting and non-exclusive examples, electromagnetic energy having wavelengths in the radio frequency domain, microwave domain, and optical (both visible and invisible) domain.

[0381] <Reference Signal> The reference signal can also be abbreviated as RS (Reference Signal), and may be called a pilot depending on the applicable standard.

[0382] <Meaning of "based on"> As used in this disclosure, the phrase "based on" does not mean "based solely on" unless otherwise specified. In other words, the phrase "based on" means both "based solely on" and "based at least on".

[0383] <"First", "Second"> Any reference to elements using the designations "first", "second", etc. as used in this disclosure does not generally limit the quantity or order of those elements. These designations may be used in this disclosure as a convenient way to distinguish between two or more elements. Accordingly, references to first and second elements do not imply that only two elements may be adopted, or that the first element must precede the second element in any way.

[0384] <Means> The "means" in the configuration of each of the above devices may be replaced with "part," "circuit," "device," etc.

[0385] <Open Format> Where the terms “include,” “including,” and variations thereof are used in this disclosure, these terms are intended to be inclusive, as is the term “comprising.” Furthermore, the term “or” as used in this disclosure is not intended to be exclusive OR.

[0386] <Time units such as TTI, frequency units such as RB, and wireless frame configuration> A wireless frame may consist of one or more frames in the time domain. Each of the one or more frames in the time domain may be called a subframe. A subframe may further consist of one or more slots in the time domain. A subframe may have a fixed time length (e.g., 1 ms) that is independent of numerology.

[0387] Numerology may be communication parameters applied to at least one of the transmission and reception of a signal or channel. Numerology may include, for example, at least one of the following: subcarrier spacing (SCS), bandwidth, symbol length, cyclic prefix length, transmission time interval (TTI), number of symbols per TTI, radio frame configuration, specific filtering processes performed by the transceiver in the frequency domain, and specific windowing processes performed by the transceiver in the time domain.

[0388] A slot may consist of one or more symbols in the time domain (such as OFDM (Orthogonal Frequency Division Multiplexing) symbols, SC-FDMA (Single Carrier Frequency Division Multiple Access) symbols, etc.). A slot may also be a time unit based on neurology.

[0389] A slot may include multiple minislots. Each minislot may consist of one or more symbols in the time domain. Minislots may also be called subslots. Minislots may consist of fewer symbols than a slot. A PDSCH (or PUSCH) transmitted in a time unit larger than a minislot may be called a PDSCH (or PUSCH) mapping type A. A PDSCH (or PUSCH) transmitted using a minislot may be called a PDSCH (or PUSCH) mapping type B.

[0390] Wireless frames, subframes, slots, minislots, and symbols all represent units of time when transmitting a signal. Different names may be used for each of these terms.

[0391] For example, one subframe may be called a Transmission Time Interval (TTI), multiple consecutive subframes may be called a TTI, or one slot or one minislot may be called a TTI. In other words, at least one of a subframe and a TTI may be a subframe in existing LTE (1 ms), a period shorter than 1 ms (e.g., 1-13 symbols), or a period longer than 1 ms. Note that the unit representing the TTI may be called a slot, minislot, etc., instead of a subframe.

[0392] Here, TTI refers to, for example, the smallest time unit for scheduling in wireless communication. For example, in an LTE system, the base station schedules each user terminal to allocate wireless resources (such as the frequency bandwidth and transmission power available to each user terminal) in TTI units. However, the definition of TTI is not limited to this.

[0393] TTI may be a transmission time unit for channel-encoded data packets (transport blocks), code blocks, code words, etc., or it may be a processing unit for scheduling, link adaptation, etc. When a TTI is given, the actual time interval (e.g., number of symbols) in which the transport block, code block, code word, etc. are mapped may be shorter than the TTI.

[0394] Furthermore, if one slot or one mini-slot is referred to as a TTI, then one or more TTIs (i.e., one or more slots or one or more mini-slots) may constitute the minimum time unit for scheduling. In addition, the number of slots (number of mini-slots) that constitute this minimum time unit for scheduling may be controlled.

[0395] A TTI with a time length of 1 ms may be called a normal TTI, a long TTI, a normal subframe, a long subframe, a slot, etc. A TTI shorter than a normal TTI may be called a shortened TTI, a short TTI, a partial or fractional TTI, a shortened subframe, a short subframe, a mini slot, a sub slot, a slot, etc.

[0396] Furthermore, long TTIs (e.g., normal TTIs, subframes, etc.) may be interpreted as TTIs with a time length exceeding 1 ms, and short TTIs (e.g., shortened TTIs, etc.) may be interpreted as TTIs with a TTI length less than that of a long TTI but 1 ms or more.

[0397] A resource block (RB) is a resource allocation unit in the time domain and frequency domain, and in the frequency domain, it may contain one or more consecutive subcarriers. The number of subcarriers in an RB may be the same regardless of the neurology, for example, 12. The number of subcarriers in an RB may be determined based on the neurology.

[0398] Furthermore, the time domain of the RB may contain one or more symbols and may be the length of one slot, one minislot, one subframe, or one TTI. One TTI, one subframe, etc., may each consist of one or more resource blocks.

[0399] One or more RBs may also be called a Physical RB (PRB), Sub-Carrier Group (SCG), Resource Element Group (REG), PRB pair, RB pair, etc.

[0400] Furthermore, a resource block may consist of one or more resource elements (REs). For example, one RE may be a radio resource area comprising one subcarrier and one symbol.

[0401] A Bandwidth Part (BWP), also known as a partial bandwidth, may represent a subset of consecutive common resource blocks (RBs) for a given neurology in a given carrier. These common RBs may be identified by an index of the RBs relative to a common reference point of the carrier. The PRBs may be defined and numbered within a given BWP.

[0402] A BWP may include a BWP for UL (UL BWP) and a BWP for DL ​​(DL BWP). One or more BWPs may be set within a single carrier for a UE.

[0403] At least one of the configured BWPs may be active, and the UE does not need to assume that it will transmit or receive a predetermined signal / channel outside of the active BWP. In this disclosure, terms such as "cell" and "carrier" may be read as "BWP".

[0404] The structures described above, such as wireless frames, subframes, slots, minislots, and symbols, are merely illustrative. For example, the number of subframes included in a wireless frame, the number of slots per subframe or wireless frame, the number of minislots included in a slot, the number of symbols and RBs included in a slot or minislot, the number of subcarriers included in an RB, and the number of symbols, symbol length, and cyclic prefix (CP) length within a TTI can be varied in various ways.

[0405] <Maximum Transmit Power> The term "maximum transmit power" as used in this disclosure may mean the maximum value of the transmit power, the nominal UE maximum transmit power, or the rated UE maximum transmit power.

[0406] <Articles> In this disclosure, if articles are added by translation, such as a, an, and the in English, this disclosure may also include the fact that the noun following these articles is plural.

[0407] <"Different"> In this disclosure, the term "A and B are different" may mean "A and B are different from each other." The term may also mean "A and B are each different from C." Terms such as "separate" and "combine" may be interpreted similarly to "different."

[0408] One aspect of this disclosure is useful for wireless communication systems.

[0409] 10 Base station 20 Devices 101, 202 Transmitting unit 102, 201 Receiving unit 103, 203 Control unit

Claims

1. A device with lower complexity than an NB-IoT (Narrow Band Internet of Things) device, comprising: a receiving unit that receives R2D messages from a wireless communication device; a control unit that, upon receiving the R2D message, decides to send a D2R message or controls the transmission of D2R data awaiting transmission; and a transmitting unit that transmits the D2R data and the D2R message to the wireless communication device.

2. The device according to claim 1, wherein the D2R message that the control unit determines to be transmitted is a D2R message X reporting an SR (scheduling request) to the wireless communication device, or a D2R message Y reporting a BSR (buffer status report) to the wireless communication device.

3. The device according to claim 1, wherein the control unit determines whether to send or cancel the D2R message upon receipt of a specific R2D message or the occurrence of a specific event.

4. The device according to claim 1, wherein the control unit, upon receiving the R2D message that triggers a random access procedure when there is D2R data awaiting transmission or when the D2R message is triggered, decides to transmit Msg1.

5. A communication method comprising: a device with lower complexity than an NB-IoT (Narrow Band Internet of Things) device receiving an R2D message from a wireless communication device; deciding to send a D2R message upon receiving the R2D message, or controlling the transmission of D2R data awaiting transmission; and transmitting the D2R data and the D2R message to the wireless communication device.

Images