Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TR 38.848  Word version:  18.0.0

Top   Top   Up   Prev   Next
0…   4…   5…   6…   7…

 

6  Comparison and assessmentp. 19

6.1  Preliminary feasibility assessmentp. 19

6.1.1  Device power consumptionp. 19

Feasibility of power consumption for Device A at ≤1 μW level has been reported by reference to [3], [4], [5], [6], and at ≤ 10 μW level by [7] depending on component choices such as in [8]. Feasibility of power consumption for Device C at ≤1 mW level has been reported by reference to [9], [10], [11], [12], [13], and by reference in part to the receiver architectures discussed in the Rel-18 SI on low-power wake up signal/receiver [14] [15] at ≤10 mW level. For Device B, which adds energy storage to Device A and has been described as also potentially including (without limitation), e.g. reflection amplification, feasibility of power consumption in the order of hundreds of uW has been reported by [7] depending on component choices such as in [16].
Up

6.1.2  Device complexityp. 19

Feasibility assessment for this aspect was presented on a qualitative basis by companies describing exemplary waveform, and/or transmitter, and/or receiver architectures which, according to their analysis, would satisfy the device power consumption design target. It was also observed that the amount of energy storage could affect device complexity. Examples of considered waveforms include OOK/FSK, and ASK. Examples of considered transmitter architectures for Device A/B include those based on backscattering technology, and receiver architectures based on envelope detection, while for Device C, very low power consumption heterodyne/homodyne architectures were reported as satisfying the complexity design target.
On the other hand, aspects such as the memory required for security, authentication, etc., and hardware used for encryption processing would add to the complexity of the device. There were also discussions of the quality required in circuitry such as energy harvesting, backscattering, and PAs which, as their efficiency increases, tend to have higher complexity.
Detailed analysis of designs which meet the device complexity requirement is considered to require WG-level technical expertise.
Up

6.1.3  Coveragep. 19

Feasibility of a coverage target was assessed by sources differently for Devices A, B, C. In addition to typical elements comprising a 3GPP coverage evaluation, such as BS/intermediate/assistant node transmit power and receive sensitivity, device receiver sensitivity, propagation losses, etc. (which vary according to the specific calculation method), aspects particular to Ambient IoT devices were added. These include:
  • Device A/B backscattering activation power threshold
  • Device B amplification (if any)
  • Device A/B reflection loss
  • Distance from carrier wave source to Ambient IoT device, for Device A/B
  • Power of carrier wave source and/or incident power at Device A/B from carrier wave source
Although different evaluation methodologies were adopted by sources [17] - [25], the coverage of Device A is reported as less than Device B (with or without amplification), which is less than Device C. The coverage of Ambient IoT devices relying on backscattering technology was reported to increase as the carrier wave source gets closer to the Ambient IoT device, due to the higher incident power on the device.
Up

6.1.4  User experienced data ratep. 19

Full user-experienced data rate assessment was noted as requiring WG-level technical expertise, and detailed assumptions on air interface design. For TSG-level purposes, companies used simplified approximants. Peak data rate was one such approximant, where companies reported values above 5 kbps for uplink and downlink to be achievable according to various sets of assumptions including sufficient bandwidth, and in one case noted that the components assumed by reference to [26] would need further investigation whether the device power consumption target could be simultaneously met. One source [17] estimated data rate by accounting for device charging time and operation time, resulting in data rates 0.14 - 2.24 kbps for uplink and downlink.
Up

6.1.5  Maximum message sizep. 20

Companies' study of the feasibility of this design requirement was by reference to e.g. RFID which supports message sizes larger than about 1000 bits. It was also observed that the different Devices could be regarded as feasible for different maximum message sizes.

6.1.6  Latencyp. 20

Feasibility of latency was reported typically by comparing a message size to a data rate, for example 5 kbps / 1000 bit = 200 ms latency for the largest message size at the target peak rate. Feasibility would also depend on a consideration of signalling procedures and possible random access-like procedure.

6.1.7  Positioning accuracyp. 20

Feasibility assessment for this aspect has been reported by reference to technologies of a similar complexity level, such as UHF RFID achieving 2-3 m accuracy in [27], [28], [29] indoors, and ultra-narrow IoT achieving from several tens to 100 or 150 m in [30], [31], [32] outdoors. It is also observed that Device A and B need to have a carrier wave source in an appropriate distance to be able to transmit signals for positioning.
Up

6.1.8  Connection/device densityp. 20

Feasibility of the target was discussed from the basis of assuming cell access procedures, and device addressing. It was discussed as applying a requirement on the design of such procedures, identities, etc. rather than being a matter for feasibility assessment before starting such designs.

6.1.9  Moving speed of devicep. 20

The feasibility aspects that were reported related to the impact of Doppler shift or channel coherence on the possible types of modulation contemplated by companies for especially Device A and B. It was observed, without limiting RAN WG design scope, that at least for low-order non-OFDM modulation, Doppler impacts at the low moving-speed level implied in Clause 5.9 would likely be acceptable, although the impact on transmission times potentially a multiple of the coherence time should also be studied in RAN WGs.
Up

6.2  Required RAN functionalitiesp. 20

The assumptions on required functionality have been studied on the basis of supporting certain RAN design targets as well as other requirements. At least the following potential functionalities are identified in different sets, respectively, according to the purpose of each functionality assumed to be mainly used for. An entry in the tables below neither implies nor precludes RAN specification impact.
Design target Functionality
Device power and complexity
  • Ultra-low power transceiver / Device architecture
  • Transmitting based on backscattering (including carrier wave provision for backscattering) for Device A and Device B
  • Low-complexity waveform / modulation / coding / signal / channel / synchronization scheme, if applicable to Device, robust to frequency error and timing error
  • Compact protocol stack and lightweight signaling procedure
Coverage
  • Techniques for the required coverage with low device complexity (e.g., forward error correction, enough receiver sensitivity and transmitted power, reflection gain enhancement), if applicable and needed to the Device type
User experienced data rate
  • Compact protocol stack and lightweight signaling procedure
  • Potential schemes as applicable, such as, e.g. flexible modulation/code rate, resource allocation, multiple
Maximum message size
  • Compact protocol stack and lightweight signaling procedure
  • Signal/channel design which can deliver the maximum message size access methods
Latency
  • Access mechanisms and signaling procedures which allow meeting the latency target
Positioning support
  • Positioning method(s) applicable to the connectivity topologies for the required positioning accuracy for Ambient IoT device
Connection density
  • Efficient multiple access methods and contention handling
  • Ability to control the operation for one or more of the Ambient IoT devices, within the applicable area, including e.g. the selection of devices
Moving speed of device
  • Physical layer design (low-order modulation, reference signal etc. and others) robust to the appropriate ranges of moving speeds
Requirement Functionality
Device management
  • RAN aspects of identification, activation/deactivation, and other management functionalities of Ambient IoT devices and other involved devices (e.g. readers) if applicable, and related signalling to/from the CN if any/needed
Security*
  • Authentication (when needed), encryption, data integrity, authorization (when needed)
Mobility
  • Mobility management (at least cell selection/re-selection -like function) for device C
  • Handling for Devices A and B
Interference management and coexistence
  • Interference management/coordination scheme
  • Potential full duplex capability of BS/UE, including self-interference suppression, may be required for BS/UE to communicate with Device A and Device B, if carrier wave transmission and backscatter reception is performed simultaneously at least on the same band by the same BS/UE.
  • Coexistence with existing and adjacent network infrastructure, and possibility to reuse existing network deployments or use new network deployments.
CN connectivity
  • RAN functionality for Ambient IoT to support CN (when present), with possibility of potential lightweight protocol stack architecture and simplified signaling procedures.
Compatibility among connectivity topologies
  • From the perspective of the Ambient IoT device, strive for operation to be agnostic to RAN connectivity topologies.
The required functionalities may not all be addressed in the same Release.
In the above, both existing and new techniques may be considered.
Up

Up   Top   ToC