Uplink transmission and reception method for ambient iot, and apparatus therefor

Abstract

A method according to one embodiment of the present specification comprises the steps of: determining a mode related to transmission by a first device; and transmitting a signal to a second device on the basis of the mode. The mode is determined on the basis of a device type associated with the first device.

Description

Method and device for AMBIENT IOT uplink transmission and reception

[0001] This specification relates to a method and device for Ambient IoT uplink transmission and reception.

[0002] The 5G mobile communications system, the successor to LTE (long-term evolution), is a new, clean-slate mobile communications system characterized by high performance, low latency, and high availability. 5G NR can utilize all available spectrum resources, from low-frequency bands below 1 GHz, to intermediate-frequency bands between 1 GHz and 10 GHz, and high-frequency (millimeter wave) bands above 24 GHz. 6G mobile communications systems are being developed based on the underlying technologies of 5G mobile communications.

[0003] The 6G (wireless) system aims to provide (i) very high data rates per device, (ii) a very large number of connected devices, (iii) global connectivity, (iv) very low latency, (v) low energy consumption for battery-free Internet of Things (IoT) devices, (vi) ultra-reliable connectivity, and (vii) connected intelligence with machine learning capabilities. The vision of the 6G system can be divided into four aspects: intelligent connectivity, deep connectivity, holographic connectivity, and ubiquitous connectivity.

[0004] Conventional non-3GPP-based IoT technologies, including RFID, have limited UL transmission modes and thus support only a very narrow set of use cases.

[0005] The purpose of this specification is to propose a method to effectively support various use cases for Ambient IoT.

[0006] The technical problems to be achieved in this specification are not limited to the technical problems mentioned above, and other technical problems not mentioned can be clearly understood by a person having ordinary skill in the technical field to which this specification pertains from the description below.

[0007] A method according to one embodiment of the present disclosure comprises the steps of determining a mode associated with transmission by a first device and transmitting a signal to a second device based on the mode.

[0008] The above mode is characterized in that it is determined based on the device type associated with the first device.

[0009] The mode may be determined based on at least one of i) the device type, ii) a state associated with the first device, iii) a setting received from the second device or a preset associated with the mode, iv) a signal received from the second device or a type associated with the signal, v) a payload property associated with the signal, or vi) a transmission timing or number of transmissions associated with the signal.

[0010] The above device type may be one of a plurality of device types. The plurality of device types may be defined based on at least one of i) presence or absence of energy storage, ii) energy storage capacity, ii) energy consumption level, iii) support for amplification operation, iii) amplification capability, v) presence or absence of a band pass filter (BPF) and / or v) BPF capability.

[0011] The state associated with the first device may be based on one of a plurality of states associated with RRC (Radio Resource Control) or RFID (Radio Frequency Identification).

[0012] The settings received from the second device may include a command indicating application of the mode.

[0013] The settings received from the second device may include information indicating modes supported by the second device. The mode may be determined from among the modes.

[0014] The type associated with the signal may be based on i) a first type associated with a message or ii) a second type associated with a command.

[0015] The above payload property may be based on i) size, ii) importance or iii) priority.

[0016] The above transmission timing may be related to a maximum response time allowed for transmission of the signal to the second device.

[0017] The above number of transmissions may be related to the maximum number of transmissions allowed for transmission of the signal to the second device.

[0018] The above signal may be associated with one of different procedures being performed simultaneously on different Ambient Internet of Things (IoT) devices.

[0019] The above signal may be based on i) one of multi channels and / or ii) one of multi sessions.

[0020] The above multiple channels may be associated with different frequency resources.

[0021] The above multiple sessions may be associated with logical channels for the above different procedures.

[0022] The first device may be an Ambient IoT (Internet of Things) device. The second device may be i) a base station, ii) a user equipment (UE), iii) an intermediate node, or iv) an assisting node.

[0023] A first device according to another embodiment of the present disclosure includes one or more transceivers, one or more processors, and one or more memories connected to the one or more processors and storing instructions.

[0024] The instructions are characterized in that they cause the first device to perform all steps of any one of the methods based on being executed by the one or more processors.

[0025] According to another embodiment of the present disclosure, an electronic device comprises one or more memories and one or more processors connected to the one or more memories. The one or more memories are characterized in that they store instructions that cause the electronic device to perform all steps of any one of the above methods based on instructions executed by the one or more processors.

[0026] A non-transitory computer-readable storage medium according to another embodiment of the present disclosure stores instructions, the instructions being executable by one or more processors, characterized in that they cause a first device to perform all steps of any one of the above methods.

[0027] A method according to another embodiment of the present disclosure comprises receiving a signal from a first device based on a mode associated with transmission by the first device, wherein the mode is determined based on a device type associated with the first device.

[0028] A second device according to another embodiment of the present disclosure comprises one or more transceivers, one or more processors, and one or more memories connected to the one or more processors and storing instructions.

[0029] The instructions are characterized in that they cause the second device to perform all steps of the method based on being executed by the one or more processors.

[0030] According to embodiments of this specification, the mode associated with transmission by the first device is determined based on the device type. Therefore, a mode suitable for the use case of an Ambient IoT device can be flexibly selected / configured considering the Ambient IoT device type. Consequently, various Ambient IoT services can be efficiently supported.

[0031] According to an embodiment of the present specification, the mode is determined based on at least one of the device type, a state related to the first device, a preset, a type related to a signal, a payload characteristic related to a signal, transmission timing, or the number of transmissions. Accordingly, a mode suitable for a use case for Ambient IoT can be determined by considering various factors in addition to the device type. Specifically, various use cases for Ambient IoT can be effectively supported by modes determined / defined by considering at least one of the factors listed above.

[0032] The effects that can be obtained from this specification are not limited to the effects mentioned above, and other effects that are not mentioned can be clearly understood by a person having ordinary skill in the technical field to which this specification belongs from the description below.

[0033] Figure 1 is an example of a topology related to Ambient IoT.

[0034] Figure 2 is another example of a topology related to Ambient IoT.

[0035] Figure 3 is another example of a topology related to Ambient IoT.

[0036] Figure 4 is another example of a topology related to Ambient IoT.

[0037] Figure 5 illustrates the state according to the operating status of an energy harvesting-based device.

[0038] Figure 6 is a flowchart illustrating a method according to one embodiment of the present specification.

[0039] FIG. 7 is a flowchart illustrating a method according to another embodiment of the present specification.

[0040] FIG. 8 is a drawing showing the configuration of the first device and the second device according to an embodiment of the present specification.

[0041] As used herein, "A or B" can mean "only A," "only B," or "both A and B." In other words, as used herein, "A or B" can be interpreted as "A and / or B." For example, as used herein, "A, B or C" can mean "only A," "only B," "only C," or "any combination of A, B and C."

[0042] As used herein, a slash ( / ) or a comma can mean "and / or." For example, "A / B" can mean "A and / or B." Accordingly, "A / B" can mean "only A," "only B," or "both A and B." For example, "A, B, C" can mean "A, B, or C."

[0043] In this specification, "at least one of A and B" may mean "only A", "only B" or "both A and B". Additionally, in this specification, the expressions "at least one of A or B" or "at least one of A and / or B" may be interpreted identically to "at least one of A and B".

[0044] Additionally, in this specification, “at least one of A, B and C” can mean “only A,” “only B,” “only C,” or “any combination of A, B and C.” Additionally, “at least one of A, B or C” or “at least one of A, B and / or C” can mean “at least one of A, B and C.”

[0045] Additionally, parentheses used herein may mean "for example." Specifically, when indicated as "control information (PDCCH)", "PDCCH" may be proposed as an example of "control information." In other words, "control information" in this specification is not limited to "PDCCH," and "PDCCH" may be proposed as an example of "control information." Furthermore, even when indicated as "control information (i.e., PDCCH)", "PDCCH" may be proposed as an example of "control information."

[0046] In the following explanation, ‘when, if, in case of’ can be replaced with ‘based on’.

[0047] Technical features individually described in a single drawing in this specification may be implemented individually or simultaneously.

[0048] In this specification, a terminal (UE, User Equipment) may be a portable device and may be a second node that receives a signal from a base station / first node / IAB node.

[0049] In this specification, a base station (BS) may be a base station / first node / IAB node / Transmission-Reception Point.

[0050] In this specification, higher layer parameters may be parameters that are set for the terminal, preset, or predefined. For example, a base station or network may transmit higher layer parameters to the terminal. For example, higher layer parameters may be transmitted via radio resource control (RRC) signaling or medium access control (MAC) signaling.

[0051] In this specification, "configured or defined" may be interpreted as being configured or preset to a device through predefined signaling (e.g., SIB, MAC, RRC) from a base station or network. In this specification, "configured or defined" may be interpreted as being preset to a device.

[0052] Hereinafter, downlink (DL) refers to communication from a base station to a terminal, and uplink (UL) refers to communication from a terminal to a base station. In downlink, a transmitter may be part of a base station, and a receiver may be part of a terminal. In uplink, a transmitter may be part of a terminal, and a receiver may be part of a base station. A base station may be expressed as a first communication device, and a terminal may be expressed as a second communication device. A base station (BS) may be replaced by terms such as a fixed station, Node B, eNB (evolved-NodeB), gNB (Next Generation NodeB), BTS (base transceiver system), access point (AP: Access Point), network (5G network), AI system, RSU (road side unit), vehicle, robot, drone (Unmanned Aerial Vehicle, UAV), AR (Augmented Reality) device, VR (Virtual Reality) device, etc. In addition, the terminal may be fixed or mobile, and may be replaced with terms such as UE (User Equipment), MS (Mobile Station), UT (user terminal), MSS (Mobile Subscriber Station), SS (Subscriber Station), AMS (Advanced Mobile Station), WT (Wireless terminal), MTC (Machine-Type Communication) device, M2M (Machine-to-Machine) device, D2D (Device-to-Device) device, vehicle, robot, AI module, drone (Unmanned Aerial Vehicle, UAV), AR (Augmented Reality) device, VR (Virtual Reality) device, etc.

[0053] Ambient IoT communication (Rel-18)

[0054] The Internet of Things (IoT) has recently attracted significant attention in the wireless communications world. By reducing the size, complexity, and power consumption of IoT devices and installing and connecting hundreds of billions to trillions of IoT devices, it can be applied to a wide range of applications. Specifically, 3GPP SA1 is discussing use cases, scenarios, and KPIs for these IoT devices, captured in TR 22.840. Furthermore, 3GPP RAN has conducted a study on IoT communications using the SID objectives shown in Table 1 below, and the output of this study is captured in TR 38.848.

[0055]

[0056] According to the 3GPP RAN study, the following three types of IoT devices were considered:

[0057] - Device A: No energy storage, no independent signal generation, i.e. backscattering transmission

[0058] - Device B: Has energy storage, no independent signal generation, i.e. backscattering transmission. Use of stored energy can include amplification of reflected signals.

[0059] - Device C: Has energy storage, has independent signal generation, i.e. active RF component for transmission.

[0060] Additionally, according to the 3GPP RAN study, the following four topologies were considered. These are described below with reference to Figures 1 to 4.

[0061] Figure 1 is an example of a topology related to Ambient IoT. Specifically, Figure 1 illustrates the following Topology (1).

[0062] - Topology (1): Base Station (BS) <-> Ambient IoT device

[0063] In Topology 1, Ambient IoT devices communicate directly and bidirectionally with a base station. Communication between the base station and Ambient IoT devices includes Ambient IoT data and / or signaling. This topology includes the possibility that the base station transmitting to the Ambient IoT device may be different from the base station receiving the data from the Ambient IoT device.

[0064] Figure 2 illustrates another example of a topology related to Ambient IoT. Specifically, Figure 2 illustrates Topology (2) below.

[0065] - Topology (2): Base Station (BS) <-> Intermediate Node <-> Ambient IoT Device

[0066] In Topology 2, Ambient IoT devices communicate bidirectionally with an intermediate node between the Ambient IoT devices and the base station. In this topology, the intermediate node can be an Ambient IoT-enabled relay, IAB node, UE, repeater, etc. The intermediate node transfers Ambient IoT data and / or signaling between the base station and the Ambient IoT devices.

[0067] Figure 3 is another example of a topology related to Ambient IoT. Specifically, Figure 3 illustrates Topology (3) below.

[0068] - Topology (3): BS <-> Assisting node <-> Ambient IoT device <-> Base station (BS)

[0069] In Topology 3, Ambient IoT devices transmit data / signaling to a base station and receive data / signaling from auxiliary nodes. Alternatively, Ambient IoT devices receive data / signaling from a base station and transmit data / signals to auxiliary nodes. In this topology, auxiliary nodes can be Ambient IoT-enabled relays, IABs, UEs, repeaters, etc.

[0070] Figure 4 is another example of a topology related to Ambient IoT. Specifically, Figure 4 illustrates Topology (4) below.

[0071] - Topology (4): Terminal (UE) <-> Ambient IoT device

[0072] In Topology 4, Ambient IoT devices communicate bidirectionally with the terminals. Communication between the terminals and Ambient IoT devices includes Ambient IoT data and / or signaling.

[0073] < Ambient IoT solutions SI (Rel-19) >

[0074] A study item titled “Study on solutions for Ambient IoT (Internet of Things) in NR” was approved in 3GPP NR Release 19. Specifically, the study item will be conducted in 3GPP NR Release 19 based on the following:

[0075] This study aims to further evaluate Ambient IoT, a new 3GPP IoT technology suitable for deployment in 3GPP systems, at the RAN WG level. It relies on ultra-low-power, ultra-low-complexity devices for very low-end IoT applications. This study must provide a clear differentiation: it must address use cases and scenarios that cannot be met by existing 3GPP LPWA IoT technologies (e.g., NB-IoT with reduced peak Tx power).

[0076] General range

[0077] The definitions given in TR 38.848 apply to this SI and are of an exclusive general scope.

[0078] A. The overall goal is to study a harmonized wireless interface design that minimizes the differences required to enable Ambient IoT to enable the following devices:

[0079] i. ~1μW peak power consumption, energy storage, initial sampling frequency offset (SFO) of up to 10X ppm, and no DL or UL amplification in the device. The device's UL transmission is backscattered from an externally supplied carrier wave.

[0080] ii. ≤hundreds of μW peak power consumption1, energy storage, initial sampling frequency offset (SFO) of up to 10X ppm, and DL and / or UL amplification within the device. The device's UL transmission may be generated internally or backscattered from an externally provided carrier wave.

[0081] -X is decided by WG.

[0082] - Coverage design goal: Up to 10-50 m distance with the device indoors according to TR 38.848: "...the range within which the WG can sub-select".

[0083] -No RRC state, no mobility (i.e. at least no functionality like cell selection / reselection), no HARQ, no ARQ for topologies 1 and 2 (UE as intermediate node under NW control) according to TR 38.848.

[0084] Note 1: It should be understood that the WG is not tasked with setting a specific value for "≤hundreds of μW", and it is a matter for the WG to discuss whether the proposed design and its power consumption meet the "≤hundreds of μW" requirement.

[0085] B. Deployment scenarios with the following characteristics, referring to the table in clause 4.2.2 of TR 38.848:

[0086] - Deployment Scenario 1 Using Topology 1

[0087] Base Station and Coexistence Characteristics: Microcells, Co-sites

[0088] - Deployment scenario 2 using UE as an intermediate node under topology 2 and network control.

[0089] Base Station and Coexistence Characteristics: Macro Cell, Co-site

[0090] The location of the intermediate node is indoors

[0091] C. FDD's FR1 licensed spectrum.

[0092] D. In-band spectrum distribution for NR, guard bands for LTE / NR, and standalone band(s).

[0093] E. Traffic types DO-DTT, DT focusing on rUC1 (indoor inventory) and rUC4 (indoor command).

[0094] - In RAN#104, this study evaluates whether the harmonized radio interface design (see bullet 'A' above) can address Device-Initiated Autonomous (DO-A) use cases and identifies which parts of the harmonized radio interface design (see bullet 'A' above) are insufficient for DO-A use cases.

[0095] Transmissions from surrounding IoT devices (including backscattering when used) can occur at least in the UL spectrum.

[0096] The following goals are set within the general range:

[0097] 1. Evaluation assumptions

[0098] a) Conclude at least the following aspects of the design objectives left to the WG in clause 5 (RAN design objectives) of TR 38.848 [RAN1]:

[0099] Article 5.3: Applicable Maximum Distance Target Value

[0100] Clause 5.6: Refines the definition of latency suitable for use in RAN WGs.

[0101] Article 5.8: 2D Distribution of Devices

[0102] b) Define additional assessment assumptions required for deployment scenarios for coverage and coexistence assessments [RAN1, RAN4].

[0103] c) Identify the basic blocks / components of a possible peripheral IoT device architecture, considering the latest implementations of low-power, low-complexity devices that meet RAN design goals for power consumption and complexity. [RAN1]

[0104] d) Define link budget calculations for coverage, including whether / how to model carrier waves at nodes inside or outside the connection topology.

[0105] Note: The evaluation performance of the design target falls within the scope of the feasibility and necessity study of the proposal, with the following objectives: For example, testing a reference implementation in the field, conducting simulations, and conducting analytical tests.

[0106] Note: RAN1 strives to minimize evaluation cases.

[0107] 2. Investigate necessary and feasible solutions for Ambient IoT, as defined in the general scope. This includes determining which functions, procedures, etc. are necessary and which are not, and ensures at least the essential functions specified in Section 6.2 of TR 38.848.

[0108] Positioning research for Rel-19 is led by RAN3 and is limited to features that have no or minimal impact on the specification (Note: This does not imply decisions regarding WI generation).

[0109] We study the feasibility and required features for proximity determination (coordination with SA3 is necessary for privacy reasons).

[0110] - RAN1 led:

[0111] For Ambient IoT DL and UL:

[0112] Frame structure, synchronization and timing, random access

[0113] Numerology, Bandwidth, and Multi-Access

[0114] Waveforms and modulation

[0115] Channel coding

[0116] Downlink channel / signal aspect

[0117] Uplink channel / signal aspect

[0118] Scheduling and Timing Relationships

[0119] We study the required characteristics of the carrier wave waveform provided to ambient IoT devices from outside, including interference handling at ambient IoT UL receivers and NR base stations.

[0120] For topology 2, there is no difference in the physical layer design from topology 1.

[0121] RAN2 led:

[0122] We study and determine the features required for an ambient IoT compact protocol stack and lightweight signaling procedures that enable DO-DTT and DT data transmission.

[0123] for example:

[0124] Paging

[0125] Random access

[0126] Data transmission including necessary radio resource control aspects that comply with general range limitations.

[0127] Interaction with higher layers

[0128] Features not listed above will only be studied if deemed essential.

[0129] RAN3 led:

[0130] Identify the necessary impacts on the signals and procedures of the CN-RAN interface to enable:

[0131] Paging

[0132] Device context management

[0133] Data transfer

[0134] Identify RAN architecture aspects, including whether split architecture support is required.

[0135] Identify potential solutions for finding Ambient IoT devices that don't impact the specifications. For example, reusing existing user location reports or transmitting location information to the core network with minimal impact on the specifications.

[0136] RAN4 led:

[0137] A study on the coexistence of Ambient IoT and NR / LTE.

[0138] RF Requirements Study for Ambient IoT:

[0139] Ambient IoT BS Transmission and Reception

[0140] Ambient IoT devices, transmitting and receiving, according to general scope

[0141] Intermediate nodes (UEs) according to general range, transmitting and receiving

[0142] RAN2 and RAN3 are expected to work with SA2 to identify the RAN-CN functional split.

[0143] Note: This study targets IoT segments that are significantly lower than existing 3GPP IoT technologies (e.g., NB-IoT, eMTC, RedCap, etc.). This study does not aim to replace existing 3GPP LPWA technologies.

[0144] Device type

[0145] As mentioned above, the device types of AmIoT (ambient IoT) devices are divided into two types as follows, and there is a design target to pursue a harmonized air interface design that minimizes differences between device types.

[0146] 1) Type 1: It has a maximum power consumption of approximately 1 uW, is capable of storing energy, has no amplification function, and performs uplink transmission by backscattering a carrier wave (CW) provided from an external source (e.g., a reader such as a base station or UE, or a separate node).

[0147] 2) Type 2: It has a maximum power consumption of approximately several hundred microwatts, is capable of storing energy, has an amplification function, and performs uplink transmission by backscattering a carrier wave (CW) provided from the outside (e.g., a base station or a reader such as a UE or a separate node) or by using an internally generated signal.

[0148] Topology

[0149] Among the four topologies described in Figures 1 to 4, the following two topologies are primarily considered in release 19 SI.

[0150] 1) Topology #1: BS <-> Ambient IoT device

[0151] a. Direct communication between base stations and AmIoT devices in a micro-cell environment

[0152] b. The base station is located co-site with a base station equipped with existing 3GPP technology.

[0153] 2) Topology #2: BS <-> intermediate node <-> Ambient IoT device

[0154] a. An intermediate node exists between the base station and the AmIoT device in a macro-cell environment.

[0155] b. The base station is located co-site with a base station equipped with existing 3GPP technology.

[0156] c. Intermediate nodes are limited to UEs and are located indoors.

[0157] Additionally, we are focusing on the FDD licensed spectrum in FR1, and transmissions from AmIoT devices can occur at least in the FDD UL spectrum.

[0158] Technical terms used in this specification are as follows:

[0159] - SSB: Synchronization Signal Block

[0160] - MIB: Master Information Block

[0161] - RMSI: Remaining Minimum System Information

[0162] - FR1: Frequency Range 1. Refers to the frequency range below 6 GHz (e.g., 450 MHz to 6000 MHz).

[0163] - FR2: Frequency Range 2. Refers to the millimeter wave (mmWave) range above 24 GHz (e.g., 24250 MHz to 52600 MHz).

[0164] - BW: Bandwidth

[0165] - BWP: Bandwidth Part

[0166] - RNTI: Radio Network Temporary Identifier

[0167] - CRC: Cyclic Redundancy Check

[0168] - SIB: System Information Block

[0169] - SIB1: SIB1 for NR devices = RMSI (Remaining Minimum System Information). Broadcasts information necessary for NR terminals to connect to the cell.

[0170] - CORESET (COntrol REsource SET): Time / frequency resource for NR terminal to attempt candidate PDCCH decoding

[0171] - CORESET#0: CORESET for Type0-PDCCH CSS set for NR devices (configured in MIB)

[0172] - Type0-PDCCH CSS set: a search space set in which an NR UE monitors a set of PDCCH candidates for a DCI format with CRC scrambled by a SI-RNTI

[0173] - MO: PDCCH Monitoring Occasion for Type0-PDCCH CSS set

[0174] - SIB1-R: (additional) SIB1 for reduced capability NR devices. May be limited to cases where it is generated as a separate TB from SIB1 and transmitted on a separate PDSCH.

[0175] - CORESET#0-R: CORESET#0 for reduced capability NR devices

[0176] - Type0-PDCCH-R CSS set: a search space set in which an redcap UE monitors a set of PDCCH candidates for a DCI format with CRC scrambled by a SI-RNTI

[0177] - MO-R: PDCCH Monitoring Occasion for Type0-PDCCH CSS set

[0178] - Cell defining SSB (CD-SSB): SSB containing RMSI scheduling information among NR SSBs

[0179] Non-cell defining SSB (non-CD-SSB): An SSB that is placed in the NR sync raster but does not contain RMSI scheduling information for the corresponding cell for measurement purposes. However, it may contain information indicating the location of the cell defining SSB.

[0180] - SCS: subcarrier spacing

[0181] - SI-RNTI: System Information Radio-Network Temporary Identifier

[0182] - Camp on: "Camp on" is the UE state in which the UE stays on a cell and is ready to initiate a potential dedicated service or to receive an ongoing broadcast service.

[0183] - TB: Transport Block

[0184] - RSA (Redcap standalone): A cell that supports only Redcap devices or services.

[0185] - SIB1(-R)-PDSCH: PDSCH that transmits SIB1(-R).

[0186] - SIB1(-R)-DCI: SIB1(-R)-PDSCH scheduling DCI. DCI format 1_0 with CRC scrambled by SI-RNTI.

[0187] - SIB1(-R)-PDCCH: PDCCH that transmits SIB1(-R)-DCI

[0188] - FDRA: Frequency Domain Resource Allocation

[0189] - TDRA: Time Domain Resource Allocation

[0190] - RA: Random Access

[0191] - MSGA: preamble and payload transmissions of the random access procedure for 2-step RA type.

[0192] - MSGB: response to MSGA in the 2-step random access procedure. MSGB may consist of response(s) for contention resolution, fallback indication(s), and backoff indication.

[0193] - RO-N: RO (RACH Occasion) for normal UE 4-step RACH and 2-step RACH(if configured)

[0194] - RO-N1, RO-N2: if separate RO is set for normal UE 2-step RACH, it is divided into RO-N1(4-step), RO-N2(2-step)

[0195] - RO-R: redcap UE 4-step RACH and 2-step RACH(if configured) RO(RACH Occasion) set separately from RO-N

[0196] - RO-R1, RO-R2: if separate RO is set for redcap UE 2-step RACH, separate RO-R1(4-step), RO-R2(2-step)

[0197] - PG-R: MsgA-Preambles Group for redcap UEs

[0198] - RAR: Random Access Response

[0199] - RAR window: the time window to monitor RA response(s)

[0200] - FH: Frequency Hopping

[0201] - iBWP: initial BWP

[0202] - iBWP-DL(-UL): initial DL(UL) BWP

[0203] - iBWP-DL(-UL)-R: (separate) initial DL(UL) BWP for RedCap

[0204] - CS: Cyclic shift

[0205] - NB: Narrowband

[0206] - TO: Traffic Offloading

[0207] - mMTC; massive Machine Type Communications

[0208] - eMBB: enhanced Mobile Broadband Communication

[0209] - URLLC: Ultra-Reliable and Low Latency Communication

[0210] - RedCap: Reduced Capability

[0211] - eRedCap: enhanced RedCap

[0212] - FDD: Frequency Division Duplex

[0213] - HD-FDD: Half-Duplex-FDD

[0214] - DRX: Discontinuous Reception

[0215] - RRC: Radio Resource Control

[0216] - RRM: Radio Resource Management

[0217] - IWSN: Industrial Wireless Sensor Network

[0218] - LPWA: Low Power Wide Area

[0219] - RB: Resource Block

[0220] - CCE: Control Channel Element

[0221] - AL: Aggregation Level

[0222] - PRG: Physical Resource-block Group

[0223] - DFT-s-OFDM: DFT-spread OFDM

[0224] - PBCH: Physical Broadcast Channel

[0225] - A-PBCH: Additional PBCH

[0226] - BD: blind detection

[0227] - EPRE: Energy Per RE

[0228] - SNR: Signal-to-Noise Ratio

[0229] - TDM: Time Division Multiplexing

[0230] - FDM: Frequency Division Multiplexing

[0231] - DMRS: DeModulation Reference Signal

[0232] - TDD: Time Division Duplex

[0233] - PCI: Physical layer Cell ID

[0234] - EH: Energy Harvesting

[0235] - EH device: A device that operates based on EH. It can include all of Device A / B / C being discussed in 3GPP. In addition, although this specification primarily considers RF EH, an EH device does not necessarily have to be RF EH-based.

[0236] - ES: Energizing Signal. A signal / channel transmitted by a base station / IN / AN / UE for the purpose of supplying RF energy to a device operating on RF-based energy harvesting. (Modulated) CW, NR / LTE DL / UL signals, etc. can be ES, and a dedicated signal / channel for ES can also be designed and supported.

[0237] - ET: Energy Transfer

[0238] CW: Carrier wave. Ambient IoT devices supporting backscattering-based UL transmission transmit information by modulating and backscattering "externally provided" CW. Ambient IoT devices supporting independent signal generation-based UL transmission transmit information by modulating "internally generated" CW. Unless otherwise specified, "externally provided" CW for backscattering is assumed. CW can be used as an energizing signal (ES) for RF energy transfer.

[0239] - R: Reader / interrogator. This is a standard RFID term. In the 3GPP Ambient IoT context, readers can include gNB / eNB, intermediate / assisting nodes, and UEs, depending on the topology. Furthermore, Ambient IoT is not limited to 4G / 5G communication systems, and can include base stations, intermediate / assisting nodes, and UEs in next-generation communication systems.

[0240] - T: Tag / ambient IoT device. This is a standard RFID term. In this specification, it can be interchanged with EH device, and in the 3GPP Ambient IoT context, it mainly refers to Ambient IoT device, Device A / B / C. The abbreviation 'T' can be interpreted / replaced with 'D', which stands for Ambient IoT Device.

[0241] - R=>T: Reader-to-Tag or Reader-to-Tag communication link. This may have the same meaning as DL when the base station or intermediate / assisting node is the reader. 'R=>T' can be interpreted / replaced with 'R=>D' (Reader-to-Device).

[0242] - T=>R: Tag-to-Reader or Tag-to-Reader communication link. This may have the same meaning as UL when the base station or intermediate / assisting node is the reader. 'T=>R' can be interpreted / replaced with 'D=>R' (Device-to-Reader).

[0243] - R<=>T: Includes cases where R=>T and T=>R, or R=>T or T=>R. It may be the case that both R=>T and T=>R apply.

[0244] - BS: Base Station

[0245] - IN: Intermediate node. In Topology 2 (BS ↔ IN ↔ Ambient IoT device), IN acts as the reader. Relay, IAB, UE, repeater, etc. can be IN.

[0246] - AN: Assisting node. It can assist DL transmission in Topology 3-1 (BS AN Ambient IoT device ? BS) or assist UL transmission in Topology 3-2 (BS Ambient IoT device AN ? BS). AN can be a relay, IAB, UE, repeater, etc.

[0247] - UE: User Equipment. In the case of LTE, NR, or next-generation communication systems, it refers to the LTE, NR, or next-generation communication system UE / terminal, respectively. It is a general wireless communication terminal type that is distinct from Ambient IoT devices or Device A / B / C. In Topology 4 (UE ↔ Ambient IoT device), the UE acts as the reader.

[0248] - Device: Unless otherwise stated, and when used alone, refers to EH device, Ambient IoT device, or Device A / B / C indiscriminately.

[0249] - AmIoT: Ambient IoT

[0250] - F-gap: Frequency gap

[0251] - T-gap: Time gap

[0252] - TD: Time Domain

[0253] - FD: Frequency Domain

[0254] - PEI: Paging Early Indication

[0255] - LP-WUS: Low-Power Wake-Up Signal

[0256] - LP-SS: Low-Power Synchronization Signal

[0257] - RSRP: Reference Signal Received Power

[0258] - ESRP: ES Received Power. This may refer to RSRP measured using ES. It may have the same meaning as ES-RSRP.

[0259] - PRB: Physical Resource Block

[0260] - EH circuit: A circuit that performs EH operations. An EH device can be viewed as containing an EH circuit in component form.

[0261] - PHR: Power Headroom Report

[0262] - EHR: Energy Headroom Report

[0263] - BPF: Band-Pass Filter

[0264] - SM: Subcarrier Modulation

[0265] In this specification, '()' can be interpreted as either excluding the contents within () or including the contents within the parentheses.

[0266] In this specification, ' / ' may mean including all of the contents separated by / (and) or including only some of the contents separated by / (or).

[0267] Ambient IoT devices can be characterized as maintenance-free, meaning they can operate permanently without battery replacement. This is achieved by harvesting energy from RF signals and / or other sources of ambient energy. According to 3GPP SA1 study results document TR 22.840, RF energy harvesting can have the following advantages and potential applications:

[0268] The main advantage of RF-based energy harvesting is its availability in deployed environments and the fact that RF power is controllable (e.g., power can be sent by a transmitter on demand or periodically). Potential applications include logistics / warehouse, manufacturing, smart homes, health monitoring, and environmental monitoring, etc.

[0269] In the 3GPP Rel-18 Ambient IoT study, Ambient IoT devices were classified into the following types / classes.

[0270] Device A: No energy storage, no independent signal generation, ie backscattering transmission

[0271] Complexity comparable to UHF passive RFID

[0272] Device B: Has energy storage, no independent signal generation, ie backscattering transmission. Use of stored energy can include amplification for reflected signals

[0273] Complexity to be somewhere b / w Device A and C

[0274] Device C: Has energy storage, has independent signal generation, ie active RF component for transmission

[0275] Complexity to be orders-of-magnitude lower than NB-IoT

[0276] Additionally, the ongoing Rel-19 Ambient IoT solutions study classifies devices into the following two types / classes and pursues a harmonized air interface design that minimizes differences between device types / classes.

[0277] Device i: has a maximum power consumption of approximately 1 uW, is capable of storing energy, has no amplification function, and performs uplink transmission by backscattering a carrier wave (CW) provided from an external source (e.g., a reader such as a base station or UE, or a separate node).

[0278] Device ii: has a maximum power consumption of approximately several hundred microwatts, is capable of storing energy, has an amplification function, and performs uplink transmission by backscattering a carrier wave (CW) provided from an external source (e.g., a base station or a reader such as a UE or a separate node) or by using an internally generated signal.

[0279] In addition to the above classification methods, Ambient IoT device types / classes can be distinguished in various ways using parameters related to device characteristics (e.g., presence / capacity of energy storage, degree of energy / power consumption, presence / capability of amplification, presence / capability of BPF, supported DL / UL transmission method(s), etc.) or combinations of parameters. (Here, BPF capability can be distinguished by 3-dB bandwidth, sharpness, etc. of the supported BPF, and UL transmission methods can be distinguished by, for example, backscattered UL transmission, UL transmission by internal signal generation, etc.)

[0280] For some Ambient IoT device types / classes (e.g., Device B / C / i / ii), energy storage capability, i.e. capacitor or charging battery, may be provided for the following purposes:

[0281] - Securing stable energy at the time of reception / transmission

[0282] - Operation of low-power communication module through energy storage in low RF energy state

[0283] For example, the minimum RF Rx sensitivity for operating a low-power communication module may be -20 dBm, and the minimum Rx sensitivity for energy harvesting may be -20 dBm. In this case, if the ambient IoT device Rx power ranges between -30 and -20 dBm, communication is impossible without a capacitor, but with a capacitor, communication may be possible after a charging time.

[0284] - Energy harvested from various energy sources (e.g., solar, thermal, wind, kinetic, etc.) is accumulated in a single capacitor and a low-power communication module is operated at a desired time.

[0285] Figure 5 illustrates the state according to the operating status of an energy harvesting-based device.

[0286] Specifically, FIG. 5 is an example of power consumption according to the operating state of an energy harvesting-based device with energy storage capability, and the device energy state at that time.

[0287] Referring to (b) of Fig. 5, S1 may be a sleep state, S2 may be an active state, and P1 and P2 may be power consumption in the S1 and S2 states, respectively.

[0288] Active state can mean a state in which the device consumes power to perform operations such as receiving / transmitting, sensing, etc. for communication, and sleep state can be a state that is not active.

[0289] Figure 5 (a) may be a device energy state corresponding to Figure 5 (b).

[0290] E1, E2 values ​​may vary by device (type / class) and may be reported by the device to the R / base station as capability parameters.

[0291] E2 can be defined as the energy value in the buffer state, and E1 can be defined as the minimum energy value required in the active state.

[0292] The transition from S1 to S2 is possible only when the device energy state value is Alt.G1) E2, or has reached E2, or is greater than Alt.G2) E1, i.e., is possible in the range of E1 to E2, and Alt.G1 is assumed in Fig. 5.

[0293] Ambient IoT devices can be applied in various connection topologies. For example, the Rel-18 Ambient IoT study defined the following four connection topologies to support Ambient IoT communications in 3GPP communication systems (see the descriptions in Figures 1 to 4).

[0294] Topology (1): BS <-> Ambient IoT device

[0295] Topology (2): BS <-> intermediate node <-> Ambient IoT device

[0296] Topology (3): BS <-> assisting node <-> Ambient IoT device <-> BS

[0297] Topology (4): UE <-> Ambient IoT device

[0298] This specification proposes embodiments for flexibly selecting / configuring Ambient IoT UL transmission modes, taking into account the characteristics and diversity of characteristics of the above Ambient IoT device types / classes, UL transmission payloads and payload transmission timing characteristics, etc. Through this, it is expected that a wireless communication system can support various Ambient IoT services. The above-described embodiments are described in detail below.

[0299] < Ambient IoT UL(T=>R) transmission support method >

[0300] Considering various Ambient IoT device types / classes and various transmission environments, the Ambient IoT communication system can support multiple UL transmission modes. According to the multiple UL transmission modes, the following operations can be supported. Some or all of the components constituting the transmitter can support multiple methods or multiple modes. Based on specific conditions / methods, the Ambient IoT device can select / decide / apply one method / mode for each component. The methods / modes supported for each component can include cases where the corresponding component is disabled or bypassed.

[0301] As an example, a transmitter for an Ambient IoT device may consist of the following components:

[0302] 1) Channel coding block: Performs operations such as FEC and CRC.

[0303] 2) Baseband encoding block: Performs operations such as line encoding and PIE encoding.

[0304] 3) Modulation block: Performs operations such as ASK (Amplitude Shift Keying) / PSK (Phase Shift Keying) / FSK (Frequency Shift Keying) modulation.

[0305] 4) Waveform generation block: Performs operations such as baseband waveform (e.g., OFDM signal) generation and resource mapping (considering coexistence with coexisting 4G / 5G / 6G communication systems)

[0306] 5) RF front end block: May consist of (part of) DAC, PA, BPF, LO, mixer, antenna, etc.

[0307] For example, each of the above components may support multiple methods / modes as follows:

[0308] [1] Channel coding block: Select / set / instruct from {CRC only, FEC(+CRC), None}

[0309] [2] Baseband encoding block: Select / set / instruct among {Line encoding method(s), PIE encoding}

[0310] [3] Modulation block: Select / set / instruct among {ASK (including OOK), PSK, FSK}

[0311] [4] Waveform generation block:

[0312] i) Select / set / indicate between {Externally provided CW, internally generated CW} (externally provided CW means backscattered UL transmission)

[0313] ii) Select / set / instruct from {normal waveform, low-PAPR waveform}

[0314] - Low-PAPR (Peak to Average Power Ratio) waveform can be a waveform generation method that applies PAPR reduction techniques.

[0315] - For example, PAPR reduction techniques may include PAPR reduction techniques, single-tone transmission, pi / 2-BPSK, pi / 4-QPSK, phase continuity guarantee techniques, etc.

[0316] - Alternatively, the proposed method may directly set / indicate whether to apply a specific technique(s) among the above techniques.

[0317] The base station / IN / AN / UE (e.g., Reader) may support all UL (e.g., D2R, Device to Reader) transmission modes supported by the Ambient IoT communication system, or may support some UL transmission modes. In this specification, UL may be interpreted / replaced with T2R (Tag to Reader) or D2R (Device to Reader). Here, supporting a specific UL transmission mode may mean that the Ambient IoT device can receive a signal transmitted UL by applying the UL transmission mode. The base station / IN / AN / UE may indicate / instruct / configure the supported UL transmission mode to the Ambient IoT in the form of a preamble / frame-sync transmitted DL (in the form of a UL transmission mode selectable by the Ambient IoT device) or a message / command transmitted as a payload.

[0318] For example, an Ambient IoT device may select / determine / apply a UL transmission mode based on one of the following proposed schemes or a combination of the following proposed schemes. For example, if an Ambient IoT device receives information from a base station / IN / AN / UE indicating one of the following proposed schemes or a combination of the following proposed schemes, the Ambient IoT device may select / determine / apply a UL transmission mode based on the information.

[0319] In the following embodiments, the 'setting / application / instruction' mentioned may mean the following operations. For example, the 'setting / instruction' may be the 'setting / instruction' of a transmission mode by a base station / IN / AN / UE. As a specific example of the 'setting / instruction', the following operations may be performed. The Ambient IoT device may receive information related to a UL transmission mode from the base station / IN / AN / UE. As an example, 'application' may mean determination / application of a transmission mode by the Ambient IoT device. As a specific example of the 'application', the following operations may be performed. The Ambient IoT device may determine / apply a UL transmission mode.

[0320] < UL transmission mode determination method based on device type / class >

[0321] Ambient IoT devices can determine / select / support UL transmission modes based on their device type / class. Ambient IoT device types / classes can be distinguished by parameters associated with device characteristics or a combination of parameters associated with device characteristics. For example, parameters associated with device characteristics can include parameter(s) associated with at least one of the following: i) to v).

[0322] i) Energy storage availability / capacity

[0323] ii) Energy / power consumption level

[0324] iii) Presence / capability of amplification

[0325] iv) Presence / capability of BPF

[0326] v) Supported DL / UL transmission method(s)

[0327] Here, BPF capability can be distinguished by the 3-dB bandwidth, sharpness, etc. of the supported BPF (Band-Pass Filter). For example, UL transmission methods can be distinguished by backscattered UL transmission, UL transmission by internal signal generation, etc.

[0328] [example]

[0329] - Supports {CRC only, FEC+CRC} as a channel coding method, and determines and applies either CRC only or FEC+CRC based on the Ambient IoT device type / class.

[0330] For example, if there is no amplification or the amplification capacity is small, the error probability may increase. Considering this, if the Ambient IoT device does not have an amplifier, or if its capacity is less than A dB, FEC is set / applied / instructed. Conversely, if the amplification capacity is greater than A dB, CRC only can be set / applied / instructed.

[0331] - Supports {ASK only, SM (Subcarrier Modulation) + ASK} as a modulation method, and determines and applies either ASK only or SM (Subcarrier Modulation) + ASK based on the Ambient IoT device type / class.

[0332] For example, if there is no BPF or the 3 dB BW is large, SM application may be difficult. In this case, ASK only is set / applied / instructed. If there is a BPF with a small 3 dB BW, SM+ASK can be set / applied / instructed.

[0333] Or, based on the presence / capacity of BPF, i) whether SM is applied and / or ii) (if SM is applied) the maximum value of frequency shift and / or frequency interval that can be supported through SM may be set / applied / indicated.

[0334] SM can be a method for applying frequency shift considering the following purposes. SM can be applied to avoid collisions by applying different amounts of frequency shift (by Ambient IoT device (type / class)) or to minimize collisions by distributing UL transmissions. SM can be applied to support full-duplex operation for base stations / INs / ANs / UEs that support SBFD (Subband non-overlapping Full Duplex).

[0335] SM may be unusable or have very limited utility if there is no BPF or if the 3dB BW is large.

[0336] For example, the UL transmission modes to be applied by an Ambient IoT device for each Ambient IoT device type / class may be predefined for each Ambient IoT device type / class and / or each transmitter component.

[0337] For example, the UL transmission modes to be applied by the Ambient IoT device depending on the Ambient IoT device type / class can be set / instructed / displayed to the Ambient IoT device in the form of a preamble / frame-sync transmitted by the base station / IN / AN / UE to the DL (e.g., R2D, Reader to Device) or a message / command transmitted as a payload.

[0338]

[0339] Ambient IoT devices can determine / select / support UL transmission modes based on their device state. For example, the Ambient IoT device state can be based on either i) or ii).

[0340] i) (For NR / LTE UE) State classified as idle / inactive / connected, etc.

[0341] ii) (For RFID) State divided into ready / arbitrate / reply / acknowledged / open / secured / killed, etc.

[0342] In one embodiment, the method may be performed as follows. For example, the UL transmission mode may be changed or a specific UL transmission mode may be applied based on the time point before and after the transmission of the Ambient IoT device ID. For example, the UL transmission mode may be changed or a specific UL transmission mode may be applied based on the time point at which the corresponding ACK is received after the transmission of the Ambient IoT device ID.

[0343] Here, the Ambient IoT device ID may include i) a random number (e.g., RN16) temporarily issued by the Ambient IoT device during the initial access or inventory (ID collection) process, ii) a random number (e.g., handle) issued by the Ambient IoT device or base station / IN / AN / UE for contention resolution, and / or iii) a Tag unique ID (e.g., Electronic Product Code (EPC)). The RN16 may be based on a random temporary binary stream.

[0344] In one embodiment, the method may be performed as follows. For example, (after transmitting the Ambient IoT device ID) the UL transmission mode may be changed or a specific UL transmission mode may be applied starting from the time point of transmitting the Ambient IoT device type / class / capability report. For example, (after transmitting the Ambient IoT device ID) the UL transmission mode may be changed or a specific UL transmission mode may be applied starting from the time point of receiving the corresponding ACK after transmitting the Ambient IoT device type / class / capability report.

[0345] For example, the UL transmission modes to be applied according to the state of the Ambient IoT device may be predefined according to the device state and / or according to the transmitter component. The UL transmission modes may include UL transmission modes to be applied before and after a specific point in time when the Ambient IoT device determines the UL transmission mode based on that point in time.

[0346] For example, the UL transmission modes to be applied according to the status of the above Ambient IoT device can be set / instructed / displayed to the Ambient IoT device in the form of a preamble / frame-sync transmitted by the base station / IN / AN / UE to the DL (e.g., R2D, Reader to Device) or a message / command transmitted as a payload.

[0347] < UL transmission mode determination method based on base station / IN / AN / UE settings or presets >

[0348] Ambient IoT devices can determine / select / support UL transmission modes based on base station / IN / AN / UE settings / instructions / commands.

[0349] For example, as described above, the base station / IN / AN / UE can configure / instruct / indicate to the Ambient IoT the UL transmission mode it supports in the form of a preamble / frame-sync transmitted in DL (in the form of a UL transmission mode selectable by the Ambient IoT device) or a message / command transmitted in the payload. When the Ambient IoT device receives the above information from the base station / IN / AN / UE, the Ambient IoT device can select / decide on a UL transmission mode from among the UL transmission mode(s) supported by the base station / IN / AN / UE or the selectable UL transmission mode(s). The Ambient IoT device can transmit a signal based on the selected / decided UL transmission mode.

[0350] For example, the base station / IN / AN / UE can directly command / instruct the Ambient IoT to select / apply the UL transmission mode in the form of a preamble / frame-sync transmitted in DL or a message / command transmitted in payload. When the Ambient IoT device receives the command / instruction from the base station / IN / AN / UE, the Ambient IoT device can select / apply the UL transmission mode commanded / instructed by the base station / IN / AN / UE and transmit it.

[0351] For example, in the above method, the settings / instructions / commands by the base station / IN / AN / UE may be applied commonly to all Ambient IoT devices.

[0352] For example, in the above method, the configuration / instruction / command by the base station / IN / AN / UE may be performed according to the type / class / state of the Ambient IoT device. In this case, the Ambient IoT devices may determine / select / apply the UL transmission mode by referring to the configuration / instruction / command value corresponding to their type / class / state.

[0353] For example, an Ambient IoT device can determine / select / support a UL transmission mode based on presets.

[0354] In one embodiment, a method based on a preset scheme may be performed as follows. UL transmission modes supported by a base station / IN / AN / UE and / or UL transmission modes supported by an Ambient IoT communication system may be preset / defined (in the form of UL transmission modes selectable by an Ambient IoT device). The Ambient IoT device may select / decide on a UL transmission mode from among the preset (selectable) UL transmission mode(s) and apply the selected UL transmission mode. As a specific example, when a plurality of preset (selectable) UL transmission modes are defined, the Ambient IoT device may (randomly) select / decide on one of the plurality of UL transmission modes.

[0355] For example, the preset / defined UL transmission mode(s) in the above preset method can be commonly applied to all Ambient IoT devices.

[0356] For example, in the above preset method, the preset / defined UL transmission mode(s) may be set / defined for each Ambient IoT device type / class / state. In this case, Ambient IoT devices may determine / select / apply the UL transmission mode by referring to the preset / defined value corresponding to their type / class / state.

[0357] < UL transmission mode determination method based on command / message type (group) >

[0358] Ambient IoT devices can determine / select / support UL transmission modes based on the command / message transmitted in DL and / or the message type (group) to be transmitted in UL.

[0359] In one embodiment, a method based on Command / message type (group) may be performed as follows:

[0360] For example, the UL transmission mode to be applied by an Ambient IoT device may be predefined / configured for each DL / UL command / message type (group) and / or each transmitter component. The Ambient IoT device may select / apply the UL transmission mode based on the predefined / defined DL / UL command / message type (group).

[0361] For example, the UL transmission mode to be applied by the Ambient IoT device may be configured / instructed / indicated to the Ambient IoT device in the form of a preamble / frame-sync transmitted by the base station / IN / AN / UE to the DL (e.g., R2D, Reader to Device) or a message / command transmitted as payload, based on the DL / UL command / message type (group) and / or transmitter component. The Ambient IoT device may select / apply the UL transmission mode based on the configuration / instruction / indication by the base station / IN / AN / UE based on the DL / UL command / message type (group).

[0362] For example, in the case of a UL transmission mode set / defined for each DL command / message type (group), the UL transmission mode can be selected / applied for UL transmission (including retransmission) transmitted by an Ambient IoT device in response to the DL command / message type (group).

[0363] For example, in the case of a UL transmission mode set / defined for each DL command / message type (group), the corresponding UL transmission mode may be selected / applied for subsequent UL transmissions starting from the time of receiving the DL command / message type (group). As a specific example, the corresponding UL transmission mode may be selected / applied for a specific time period defined by a timer / window or until the time when a process triggered by the DL command / message type (group) is terminated.

[0364] For example, if an Ambient IoT device receives a paging / query command, which is a DL command that initiates an inventory (ID collection) process, a specific UL transmission mode may be applied from the time the Ambient IoT device transmits for that process.

[0365]

[0366] Ambient IoT devices can determine / select / support UL transmission modes based on UL transmission payload characteristics. For example, payload characteristics may include payload size, importance, and / or priority.

[0367] [example]

[0368] - A method that supports multiple candidate CRC lengths and allows the Ambient IoT device to determine the CRC length to apply during UL transmission based on UL transmission payload characteristics such as UL transmission payload size, importance, and priority.

[0369] For example, length-X CRC and length-Y CRC are supported (X <Y), Ambient IoT device는 UL payload size가 특정 값 Z 이상이면 length-Y CRC를 적용할 수 있다. 그렇지 않은 경우(UL payload size가 특정 값 Z 미만인 경우) Ambient IoT device는 length-X CRC를 적용할 수 있다.

[0370] - Supports {CRC only, FEC+CRC} as a channel coding method, and the Ambient IoT device determines and applies either CRC only or FEC+CRC during UL transmission based on UL transmission payload characteristics such as UL transmission payload size, importance, and priority.

[0371] For example, an Ambient IoT device can apply CRC only if the importance of the UL transmission payload is 0 or low. An Ambient IoT device can apply FEC+CRC (FEC with CRC) if the importance is 1 or high.

[0372] For example, UL transmission payload characteristics and / or UL transmission modes to be applied by the Ambient IoT device may be pre-configured / defined for each UL transmission payload characteristic and / or each transmitter component.

[0373] For example, UL transmission payload characteristics and / or UL transmission modes to be applied by the Ambient IoT device can be set / instructed / indicated to the Ambient IoT device in the form of a preamble / frame-sync transmitted by the base station / IN / AN / UE to the DL (e.g., R2D, Reader to Device) or a message / command transmitted as payload.

[0374] < UL transmission mode determination method based on UL transmission timing / number of times >

[0375] Ambient IoT devices can determine / select / support UL transmission modes based on UL transmission timing / number of transmissions. For example, UL transmission timing may be a (indicated) response time to a DL command / message or a maximum allowed response time for UL transmission. For example, the number of UL transmissions may be a (indicated) number of UL transmissions that must be transmitted in UL in response to a single DL command / message or a maximum number of UL transmissions allowed for transmission.

[0376] [example]

[0377] - Supports {CRC only, FEC+CRC} as a channel coding method, and the Ambient IoT device decides and applies either CRC only or FEC+CRC based on the (instructed) response time for the DL command / message.

[0378] For example, an Ambient IoT device may apply FEC+CRC (FEC with CRC) if the (instructed) response time for a DL command / message is greater than T1. If the response time is less than T1, the Ambient IoT device may apply CRC only (e.g., T1=20ms).

[0379] When there is excessive delay in response, the probability of reception errors may increase due to sync issues. In this case, switching from CRC to FEC+CRC based on a specific response time can be expected to have the effect of reducing the probability of reception errors.

[0380] - Supports {CRC only, FEC+CRC} as a channel coding method, and the Ambient IoT device decides and applies either CRC only or FEC+CRC based on the number of UL transmissions.

[0381] For example, an Ambient IoT device may apply FEC+CRC (FEC with CRC) if the number of UL transmissions corresponding to a single DL command / message is N1 or greater. If the number of UL transmissions is less than N1, the Ambient IoT device may apply CRC only (e.g., N1=2).

[0382] A large number of UL transmissions can occur primarily when the UL transmission payload size is large. This embodiment utilizes this correlation. Specifically, when the number of UL transmissions exceeds a certain value, a transition to a longer CRC or FEC+CRC can be performed.

[0383] For example, UL transmission timing / number of times and / or UL transmission modes to be applied by the Ambient IoT device based thereon can be pre-configured / defined in the spec for each DL / UL command / message (group) and / or each transmitter component.

[0384] For example, the UL transmission timing / number of times and / or the UL transmission modes to be applied by the Ambient IoT device based thereon may be set / instructed / indicated to the Ambient IoT device in the form of a preamble / frame-sync transmitted by the base station / IN / AN / UE to the DL (e.g., R2D, Reader to Device) or a message / command transmitted as a payload.

[0385] < Multi-channel / session support method >

[0386] Ambient IoT communication systems can support multi-channels. For example, multi-channels can be applied / utilized to simultaneously perform inventory / paging processes, thereby reducing the required time. For example, multi-channels can be applied / utilized to appropriately distribute DL / UL signals to minimize collisions.

[0387] A multi-channel may be composed of a set of non-overlapping frequency resources. For example, the frequency resources may include frequency resources based on the same size. For example, the frequency resources may include frequency resources with different sizes for each channel.

[0388] In one embodiment, in a multi-channel environment, information related to the above methods (e.g., information required to support the above methods) may be set / defined in advance. For example, the information may be set / defined for each channel in common or for each channel. For example, the information may be set / defined for each transmitter component. For example, the information may be set / defined for each combination of channel and transmitter component. For example, the information may be set / defined for each transmitter component in common across channels.

[0389] In one embodiment, in a multi-channel environment, information related to the above methods (e.g., information required to support the above methods) may be set / indicated / displayed to the Ambient IoT device in the form of a preamble / frame-sync transmitted by the base station / IN / AN / UE to the DL (e.g., R2D, Reader to Device) or a message / command transmitted as a payload. For example, the information may be set / indicated / displayed for a specific channel. For example, the information may be set / indicated / displayed per channel. For example, the information may be set / indicated / displayed per transmitter component. For example, the information may be set / indicated / displayed per combination based on at least one of i) a specific channel, ii) each channel, and / or iii) each transmitter component.

[0390] For example, in order to support multi-channel communication, the support method / mode(s) for each component of the Ambient IoT transmitter may be set / indicated / displayed commonly for each channel. For example, in order to support multi-channel communication, the support method / mode(s) for each component of the Ambient IoT transmitter may be set / indicated / displayed for each channel. For example, in order to support multi-channel communication, some of the support methods / mode(s) for each component of the Ambient IoT transmitter may be set / indicated / displayed commonly for each channel, and the rest of the support methods / mode(s) for each component of the Ambient IoT transmitter may be set / indicated / displayed for each channel.

[0391] In one embodiment, an Ambient IoT communication system may support multiple sessions. For example, multiple sessions may be applied / utilized to reduce the time required for inventory / paging. For example, multiple concurrent sessions may be opened to simultaneously perform inventory / paging processes for different Ambient IoT devices (types / classes / states).

[0392] For example, a multi-session may consist of a set of logical channels or virtual channels through which inventory / paging processes occur between an Ambient IoT device and a base station / IN / AN / UE.

[0393] In one embodiment, in a multi-session environment, information related to the above methods (e.g., information required to support the above methods) may be set / defined in advance. For example, the information may be set / defined for each session or for each session. For example, the information may be set / defined for each transmitter component. For example, the information may be set / defined for each combination of session and transmitter component. For example, the information may be set / defined for each transmitter component while being common to each session.

[0394] In one embodiment, in a multi-session environment, information related to the above methods (e.g., information required to support the above methods) may be set / indicated / displayed to the Ambient IoT device in the form of a preamble / frame-sync transmitted by the base station / IN / AN / UE to the DL (e.g., R2D, Reader to Device) or a message / command transmitted as a payload. For example, the information may be set / indicated / displayed for a specific session. For example, the information may be set / indicated / displayed per session. For example, the information may be set / indicated / displayed per transmitter component. For example, the information may be set / indicated / displayed per combination based on at least one of i) a specific session, ii) each session, and / or iii) each transmitter component.

[0395] For example, in order to support multiple sessions, the support method / mode(s) for each component of the Ambient IoT transmitter may be set / indicated / displayed commonly for each session. For example, in order to support multiple sessions, the support method / mode(s) for each component of the Ambient IoT transmitter may be set / indicated / displayed for each session. For example, in order to support multiple sessions, some of the support methods / mode(s) for each component of the Ambient IoT transmitter may be set / indicated / displayed commonly for each session, and the rest of the support methods / mode(s) for each component of the Ambient IoT transmitter may be set / indicated / displayed for each session.

[0396] In the above multi-channel / session environment, Ambient IoT devices can be assigned to different channels / sessions to perform inventory / paging processes simultaneously. For example, the channels / sessions can be assigned based on at least one of: i) device type / class / state, ii) UL transmission payload characteristics, and / or iii) UL transmission timing / number of times.

[0397] In terms of implementation, the operations of the first device (e.g., Ambient IoT Device) / second device (e.g., Reader, BS, IN, AN, UE) according to the embodiments described above can be processed by the device of FIG. 8 (e.g., the processor (110, 210) of FIG. 8).

[0398] In addition, the operations of the first device (e.g., Ambient IoT Device) / second device (e.g., Reader, BS, IN, AN, UE) according to the above-described embodiment may be stored in a memory (e.g., 140, 240 of FIG. 8) in the form of a command / program (e.g., instruction, executable code) for driving at least one processor (e.g., 110, 210 of FIG. 8).

[0399] The embodiments described below are specifically described with reference to FIGS. 6 and 7 in terms of the operation of a first device (e.g., Ambient IoT Device) and a second device (e.g., Reader, Base Station, Intermediate Node, Auxiliary Node, Terminal). The methods described below are distinguished for convenience of explanation, and it is understood that some components of one method may be substituted for some components of another method or may be applied in combination with each other.

[0400] Figure 6 is a flowchart illustrating a method according to one embodiment of the present specification.

[0401] Referring to FIG. 6, a method according to one embodiment of the present specification includes a mode determination step (S610) and a signal transmission step (S620) based on the mode.

[0402] In S610, the first device determines a mode associated with transmission by the first device.

[0403] In S620, the first device transmits a signal to the second device based on the mode.

[0404] As an example of D2R (Device to Reader), the signal transmitted from a first device (Ambient IoT Device) to a second device (Reader) may be based on a physical channel. The physical channel may be referred to as a D2R channel or a Physical Device-to-Reader Channel (PDRCH). As a specific example, the PDRCH may carry i) any higher-layer payload, ii) a response transmitted from the Ambient IoT Device to the Reader during a contention-based access procedure, and / or iii) D2R control information.

[0405] As an example of R2D (Reader to Device), a signal transmitted from a second device (Reader) to a first device (Ambient IoT Device) may be based on a physical channel. The physical channel may be referred to as an R2D channel or a Physical Reader-to-Device CHannel (PRDCH). As a specific example, the PRDCH may carry i) all higher-layer payloads (e.g., higher-layer payload including system information, higher-layer payload including configuration / information other than system information) and / or ii) R2D control information.

[0406] For example, the mode may be based on the UL transmission mode described above. As a specific example, the mode may include a mode related to an operation performed by each of the components of the transmitter of the first device (e.g., a channel coding block, a baseband encoding block, a modulation block, a waveform generation block, and an RF front end block).

[0407] As an example of the mode related to the above Channel coding block, the mode may include at least one of a first mode (CRC only), a second mode (FEC (+CRC)), and / or a third mode (None).

[0408] As an example of the mode related to the baseband encoding block, the mode may include at least one of the fourth mode (Line encoding method) and / or the fifth mode (PIE encoding).

[0409] As an example of the mode related to the above modulation block, the mode may include at least one of the sixth mode (ASK (including OOK)), the seventh mode (PSK) and / or the eighth mode (FSK).

[0410] As an example of the mode related to the Waveform generation block, the mode may include at least one of the 9th mode (Externally provided CW), the 10th mode (internal generated CW), the 11th mode (normal waveform), and / or the 12th mode (low-PAPR waveform).

[0411] The above mode is specifically described with reference to the embodiments described below.

[0412] In one embodiment, the mode may be determined based on at least one of: i) a device type associated with the first device, ii) a state associated with the first device, iii) a setting received from the second device or a preset associated with the mode, iv) a signal received from the second device or a type associated with the signal, v) a payload property associated with the signal, or vi) a transmission timing or number of transmissions associated with the signal.

[0413] For example, the mode may be determined for each component described above. As a specific example, based on at least one of the above i) to vi), the mode for the channel coding block may be determined as one of the first to third modes described above.

[0414] For example, the mode may include one or more modes among the modes related to the above-described components. As a specific example, one or more modes among the first to twelfth modes described above may be determined based on at least one of the above-described i) to vi).

[0415] For example, the mode may be determined based on one of i) to vi). As a specific example, the mode may be determined based on the device type. As a specific example, the mode may be determined based on the state. As a specific example, the mode may be determined based on the setting received from the second device. As a specific example, the mode may be determined based on the type associated with the signal (e.g., PRDCH) received from the second device. As a specific example, the mode may be determined based on a payload property associated with the signal (e.g., PDRCH). As a specific example, the mode may be determined based on the transmission timing or the number of transmissions associated with the signal (e.g., PDRCH).

[0416] For example, the mode may be determined based on a combination of two or more of i) to vi). As a specific example of i) and ii), the mode may be determined based on the device type and the state. As a specific example of i) and iii), the mode may be determined based on the device type and the settings received from the second device. As a specific example of i) and iii), the mode may be one of the modes pre-set / defined for each device type. However, the combination is not limited to the three examples described above.

[0417] In one embodiment, the device type may be one of a plurality of device types. The plurality of device types may be defined based on at least one of: i) presence or absence of energy storage, ii) energy storage capacity, ii) energy consumption level, iii) support for amplification operation, iii) amplification capability, v) presence or absence of a band pass filter (BPF) and / or v) BPF capability.

[0418] For example, the modes associated with the transmission by the first device may include modes associated with the plurality of device types.

[0419] For example, the plurality of device types may include at least one of the above-described Device A, Device B, Device C, Type 1, and / or Type 2.

[0420] In one embodiment, the state associated with the first device may be based on one of a plurality of states associated with Radio Resource Control (RRC) or Radio Frequency Identification (RFID).

[0421] For example, the modes associated with the transmission by the first device may include modes associated with the plurality of states.

[0422] For example, the state may be an idle state, an inactive state, or a connected state. For example, the state may be a ready state, an arbitrate state, a reply state, an acknowledged state, an open state, a secured state, or a killed state.

[0423] In one embodiment, the settings received from the second device may include a command indicating application of the mode. For example, the mode determined by the first device may be a mode indicated based on the command.

[0424] In one embodiment, the settings received from the second device may include information indicating modes supported by the second device. The mode may be determined from among the modes.

[0425] In one embodiment, the type associated with the signal may be based on i) a first type associated with a message or ii) a second type associated with a command. For example, the modes associated with the transmission by the first device may include i) a mode associated with the first type and ii) a mode associated with the second type.

[0426] In one embodiment, the payload property may be based on i) size, ii) importance, or iii) priority. For example, the modes associated with the transmission by the first device may include i) mode(s) defined by size associated with the payload, ii) mode(s) defined by importance associated with the payload, and / or iii) mode(s) defined by priority associated with the payload.

[0427] In one embodiment, the transmission timing may be related to a maximum response time allowed for transmission of the signal to the second device. For example, the modes associated with the transmission by the first device may include modes defined by the length of the maximum response time.

[0428] In one embodiment, the number of transmissions may be related to the maximum number of transmissions allowed for the signal to be transmitted to the second device. For example, the modes associated with the transmission by the first device may include modes defined by the maximum number of transmissions.

[0429] The above signal may be associated with multiple channels / sessions. This will be described in detail with reference to the embodiments described below.

[0430] In one embodiment, the signal may be associated with one of different procedures being performed simultaneously on different Ambient Internet of Things (IoT) devices. The signal may be based on i) one of multiple channels and / or ii) one of multiple sessions.

[0431] For example, the above procedures may include i) a paging procedure, ii) an inventory procedure, and / or iii) an access procedure. As a specific example, the inventory procedure may be performed by a reader to search for and collect identifiers of Ambient IoT devices. In the inventory procedure, the Ambient IoT device transmits an inventory result to the reader. The signal transmitted by the first device may be related to the inventory result.

[0432] For example, the multiple channels may be associated with different frequency resources.

[0433] For example, the multiple sessions may be associated with logical channels for the different procedures.

[0434] In one embodiment, the first device and the second device may be based on devices that operate based on one of four topologies related to Ambient IoT (see FIGS. 1 to 4). Specifically, the first device may be an Ambient IoT (Internet of Things) device. The second device may be i) a base station, ii) a user equipment (UE), iii) an intermediate node, or iv) an assisting node.

[0435] In one embodiment, the method may further include a configuration receiving step. Specifically, the first device may receive configurations related to the mode from the second device. For example, the configurations may include a command indicating application of the mode. For example, the configurations may include information indicating modes supported by the second device. The configuration receiving step may be performed prior to S610.

[0436] The operations based on the above-described S610 to S620 and the setup receiving steps can be implemented by the device of FIG. 8. For example, referring to FIG. 8, the first device / Ambient IoT device (200) can control one or more transceivers (230) and / or one or more memories (240) to perform operations based on S610 to S620 and the setup receiving steps.

[0437] The embodiments described below are specifically described in terms of the operation of the second device.

[0438] The S710 and setting transmission steps described below correspond to the S610 to S620 and setting reception steps described in FIG. 6. Considering the above correspondence, redundant descriptions are omitted. That is, the specific description of the second device operation described below may be replaced with the corresponding description / example of FIG. 6.

[0439] FIG. 7 is a flowchart illustrating a method according to another embodiment of the present specification.

[0440] Referring to FIG. 7, a method according to another embodiment of the present specification includes a step (S710) of receiving a signal based on a mode.

[0441] In S710, the second device receives a signal from the first device based on a mode associated with transmission by the first device.

[0442] For example, the mode may be determined based on a device type associated with the first device.

[0443] In one embodiment, the method may further include a configuration transmission step. Specifically, the second device may transmit configurations related to the mode to the first device. For example, the configurations may include a command indicating the application of the mode. For example, the configurations may include information indicating the modes supported by the second device. The configuration transmission step may be performed prior to S710.

[0444] The operations based on the above-described S710 and setup transmission steps can be implemented by the device of FIG. 8. For example, referring to FIG. 8, the second device / Reader / base station / terminal / intermediate node / auxiliary node (100) can control one or more transceivers (130) and / or one or more memories (140) to perform operations based on S710 and setup transmission steps.

[0445] Hereinafter, a device to which an embodiment of the present specification can be applied (a device that implements a method / operation according to an embodiment of the present specification) is described with reference to FIG. 8.

[0446] FIG. 8 is a drawing showing the configuration of the first device and the second device according to an embodiment of the present specification.

[0447] The first device (100) may include a processor (110), an antenna unit (120), a transceiver (130), and a memory (140).

[0448] The processor (110) performs baseband-related signal processing and may include a higher layer processing unit (111) and a physical layer processing unit (115). The higher layer processing unit (111) may process operations of a MAC layer, an RRC layer, or higher layers. The physical layer processing unit (115) may process operations of a PHY layer. For example, when the first device (100) is a base station device in base station-terminal communication, the physical layer processing unit (115) may perform uplink reception signal processing, downlink transmission signal processing, etc. For example, when the first device (100) is a first terminal device in terminal-to-terminal communication, the physical layer processing unit (115) may perform downlink reception signal processing, uplink transmission signal processing, sidelink transmission signal processing, etc. In addition to performing baseband-related signal processing, the processor (110) may also control the overall operation of the first device (100).

[0449] The antenna unit (120) may include one or more physical antennas, and when it includes multiple antennas, it may support MIMO transmission and reception. The transceiver (130) may include an RF (Radio Frequency) transmitter and an RF receiver. The memory (140) may store information processed by the processor (110), and software, an operating system, applications, etc. related to the operation of the first device (100), and may also include components such as a buffer.

[0450] The processor (110) of the first device (100) may be configured to implement the operation of the base station in the base station-to-terminal communication (or the operation of the first terminal device in the terminal-to-terminal communication) in the embodiments described in the present disclosure.

[0451] The second device (200) may include a processor (210), an antenna unit (220), a transceiver (230), and a memory (240).

[0452] The processor (210) performs baseband-related signal processing and may include a higher layer processing unit (211) and a physical layer processing unit (215). The higher layer processing unit (211) may process operations of a MAC layer, an RRC layer, or higher layers. The physical layer processing unit (215) may process operations of a PHY layer. For example, when the second device (200) is a terminal device in base station-terminal communication, the physical layer processing unit (215) may perform downlink reception signal processing, uplink transmission signal processing, etc. For example, when the second device (200) is a second terminal device in terminal-to-terminal communication, the physical layer processing unit (215) may perform downlink reception signal processing, uplink transmission signal processing, sidelink reception signal processing, etc. In addition to performing baseband-related signal processing, the processor (210) may also control the overall operation of the second device (210).

[0453] The antenna unit (220) may include one or more physical antennas, and when it includes multiple antennas, it may support MIMO transmission and reception. The transceiver (230) may include an RF transmitter and an RF receiver. The memory (240) may store information processed by the processor (210), software, an operating system, applications, etc. related to the operation of the second device (200), and may also include components such as a buffer.

[0454] The processor (210) of the second device (200) may be configured to implement operations of the terminal in base station-to-terminal communication (or operations of the second terminal device in terminal-to-terminal communication) in the embodiments described in the present disclosure.

[0455] In the operation of the first device (100) and the second device (200), the same explanations given for the base station and the terminal (or the first terminal and the second terminal in the terminal-to-terminal communication) in the examples of the present disclosure may be applied, and redundant explanations are omitted.

[0456] Here, the wireless communication technology implemented in the device of the present disclosure may include LTE, NR, and 6G, as well as Narrowband Internet of Things (NB-IoT) for low-power communication. For example, NB-IoT technology may be an example of LPWAN (Low Power Wide Area Network) technology and may be implemented in standards such as LTE Cat NB1 and / or LTE Cat NB2, and is not limited to the above-described names.

[0457] Additionally or alternatively, the wireless communication technology implemented in the device of the present disclosure may perform communication based on LTE-M technology. For example, LTE-M technology may be an example of LPWAN technology and may be called by various names such as eMTC (enhanced Machine Type Communication). For example, LTE-M technology may be implemented by at least one of various standards such as 1) LTE CAT 0, 2) LTE Cat M1, 3) LTE Cat M2, 4) LTE non-BL (non-Bandwidth Limited), 5) LTE-MTC, 6) LTE Machine Type Communication, and / or 7) LTE M, and is not limited to the above-described names.

[0458] Additionally or alternatively, the wireless communication technology implemented in the device of the present disclosure may include at least one of ZigBee, Bluetooth, and Low Power Wide Area Network (LPWAN), which take low-power communication into account, and is not limited to the above-described names. For example, ZigBee technology can create personal area networks (PANs) related to small / low-power digital communication based on various standards such as IEEE 802.15.4, and may be called by various names.

Claims

1. In the method, a step of determining a mode associated with transmission by the first device; and A step of transmitting a signal to a second device based on the above mode; including; A method characterized in that the above mode is determined based on a device type associated with the first device.

2. In paragraph 1, A method characterized in that the mode is determined based on at least one of i) the device type, ii) a state associated with the first device, iii) a setting received from the second device or a preset associated with the mode, iv) a signal received from the second device or a type associated with the signal, v) a payload property associated with the signal, or vi) a transmission timing or number of transmissions associated with the signal.

3. In paragraph 2, The above device type is one of multiple device types, A method characterized in that the above plurality of device types are defined based on at least one of i) presence or absence of energy storage, ii) energy storage capacity, ii) energy consumption level, iii) support for amplification operation, iii) amplification capability, v) presence or absence of a band pass filter (BPF) and / or v) BPF capability.

4. In paragraph 2, A method characterized in that the state associated with the first device is based on one of a plurality of states associated with RRC (Radio Resource Control) or RFID (Radio Frequency Identification).

5. In paragraph 2, A method characterized in that the settings received from the second device include a command indicating application of the mode.

6. In paragraph 2, The settings received from the second device include information indicating modes supported by the second device, A method characterized in that the above mode is determined from among the above modes.

7. In paragraph 2, A method characterized in that the type associated with the signal is based on i) a first type associated with a message or ii) a second type associated with a command.

8. In paragraph 2, A method characterized in that the above payload property is based on i) size, ii) importance or iii) priority.

9. In paragraph 2, A method characterized in that the above transmission timing is related to a maximum response time allowed for transmission of the signal to the second device.

10. In paragraph 2, A method characterized in that the number of transmissions is related to the maximum number of transmissions allowed for transmission of the signal to the second device.

11. In paragraph 1, The above signal relates to one of different procedures being performed simultaneously on different Ambient IoT (Internet of Things) devices, A method characterized in that the signal is based on i) one of multi channels and / or ii) one of multi sessions.

12. In paragraph 11, A method characterized in that the above multiple channels are associated with different frequency resources.

13. In paragraph 11, A method characterized in that the above multiple sessions are associated with logical channels for the different procedures.

14. In paragraph 1, The above first device is an Ambient IoT (Internet of Things) device, A method characterized in that the second device is i) a base station, ii) a user equipment, iii) an intermediate node, or iv) an assisting node.

15. In the first device, One or more transmitters and receivers; one or more processors; and One or more memories connected to said one or more processors and storing instructions, A first device characterized in that the instructions, based on being executed by the one or more processors, cause the first device to perform all steps of the method according to any one of claims 1 to 14.

16. In an electronic device comprising one or more memories and one or more processors connected to the one or more memories, An electronic device characterized in that said one or more memories store instructions that cause said electronic device to perform all steps of a method according to any one of claims 1 to 14, based on being executed by said one or more processors.

17. In a non-transitory computer-readable storage medium storing instructions, A non-transitory computer-readable storage medium characterized in that the instructions executable by one or more processors cause a first device to perform all steps of a method according to any one of claims 1 to 14.

18. In the method, A step of receiving a signal from a first device based on a mode associated with transmission by the first device; comprising: A method characterized in that the above mode is determined based on a device type associated with the first device.

19. In the second device, One or more transmitters and receivers; one or more processors; and One or more memories connected to said one or more processors and storing instructions, A second device characterized in that said instructions, based on being executed by said one or more processors, cause said second device to perform all steps of the method according to claim 18.

Images