Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x
Top   in Index   Prev   Next

TS 22.369
Service requirements for Ambient power-enabled IoT

V19.3.0 (Wzip)2024/09  18 p.
Rapporteur:
Mr. Xu, Weijie
Shenzhen Heytap

Content for  TS 22.369  Word version:  19.3.0

Here   Top

 

1  Scopep. 6

The present document describes service and performance requirements for ambient power-enabled Internet of Things (i.e. Ambient IoT). In the context of the present document, Ambient IoT device is an IoT device powered by energy harvesting, being either battery-less or with limited energy storage capability (e.g. using a capacitor) and the energy is provided through the harvesting of radio waves, light, motion, heat, or any other power source that could be seen suitable. An Ambient IoT device has low complexity, small size and lower capabilities and lower power consumption than previously defined 3GPP IoT devices (e.g. NB-IoT/eMTC devices). Ambient IoT devices can be maintenance free and can have long life span (e.g. more than 10 years).
The aspects addressed in this document include:
  • Overview of Ambient IoT service and operation,
  • Functional service requirements for Ambient IoT, including communication, positioning, management, exposure, charging, security and privacy.
  • Performance service requirements for Ambient IoT, including inventory, sensors, tracking, and actuator.
Up

2  Referencesp. 6

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
  • References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
  • For a specific reference, subsequent revisions do not apply.
  • For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]
TR 21.905: "Vocabulary for 3GPP Specifications".
[2]
TS 22.368: "Service requirements for Machine-Type Communications (MTC)".
[3]
TS 22.278: "Service requirements for the Evolved Packet System (EPS)".
[4]
TS 22.261: "Service requirements for the 5G system".
[5]
TS 22.011: "Service accessibility".
Up

3  Definitions of terms, symbols and abbreviationsp. 6

3.1  Termsp. 6

For the purposes of the present document, the terms given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.
Ambient IoT device:
As defined in TS 22.261.

3.2Void

3.3  Abbreviationsp. 7

For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.
eMTC
enhanced Machine-Type Communication
NB-IoT
NarrowBand Internet of Things
RedCap
Reduced Capability

4  Overviewp. 7

4.1  Introductionp. 7

In the 5G era, various IoT technologies [2] [3] [4] [5] such as eMTC, NB-IoT, and RedCap have been developed to fulfil the increasing demand from verticals. These IoT technologies have achieved low cost, low power and massive connections and can meet requirements of many applications. However, there are still some use cases and applications that can benefit from an IoT technology that requires less power and has lower cost than previous IoT technologies. Improvements can be made where maintenance-free devices are required (e.g. where the devices are inaccessible and it is not possible to replace the device battery) or for devices in extreme environmental conditions. Finally, ultra-low complexity, very small device size/form factor (e.g. thickness of mm), longer life cycle, etc. are required for some use cases. Ambient IoT is a technology to fulfil these market requirements.
This Technical Specification describes the Ambient IoT technology service requirements as part of the 5G system to enable new services and use cases. Ambient IoT has the potential to benefit a large number of vertical industries, e.g. smart manufacturing, logistics and warehousing, smart grid, agriculture, and smart home by providing functionalities that fulfil the needs of industrial use cases. Therefore, a new kind of IoT service for the vertical industries will be enabled by combining Ambient IoT with cellular networks, vastly benefitting the 3GPP ecosystem.
Up

4.2  Characteristics of Ambient IoTp. 7

Not all Ambient IoT devices are the same. Nevertheless, Ambient IoT devices have the following characteristics.
  • Energy harvesting: An Ambient IoT device is an IoT device powered by energy harvesting, being either battery-less or with limited energy storage capability (e.g. using a capacitor). Energy is provided through harvesting of radio waves, light, motion, heat, or any other suitable power source. Energy harvesting can be continuous or incidental (e.g. based on the vibration that a vibration sensor has to report). It cannot be assumed that Ambient IoT devices always have enough power to initiate or receive communication.
  • Low complexity: Ambient IoT devices are expected to have lower complexity, smaller size, reduced capabilities and lower power consumption than previously defined 3GPP IoT devices (e.g. NB-IoT/eMTC devices). Low complexity of Ambient IoT devices is also expected to be reflected in efficient use of network resources. In general, Ambient IoT applications will deploy very large numbers of Ambient IoT devices.
  • Low data rates: Generally, Ambient IoT data transmissions contain only a low amount of data.
  • Life span: Ambient IoT devices can be maintenance free and can have long life span (e.g. more than 10 years). However, the life span of an Ambient IoT device can also be relatively short, e.g. when tracking a package through a logistics chain.
  • Communication characteristics: Ambient IoT devices can have a variety of communication characteristics, different from other IoT devices, based on how the Ambient IoT devices are powered by energy harvesting and whether / how the harvested energy can be stored. Ambient IoT devices will only be able to communicate when they have enough power. This can be an issue, especially when communication is initiated towards the Ambient IoT device, while it is not known whether the Ambient IoT device has enough power to receive this communication. For communications initiated by the Ambient IoT device, the Ambient IoT device cannot transmit data until it has harvested / stored enough energy. Some Ambient IoT devices can be powered on demand when they need to communicate. Additionally, some Ambient IoT devices will be able to communicate on a regular basis and have communication characteristics similar to regular IoT devices.
Up

4.3  Typical Ambient IoT use casesp. 8

Ambient IoT can support many different use cases. Nevertheless, in general the Ambient IoT use cases can be characterised in four different use case categories:
  • Inventory taking: With inventory taking, the main purpose is to discover what goods (e.g. boxes, containers, packages, tools) are present in a specific area. Upon request sent by the network within the specific area, Ambient IoT devices attached to these goods report an identifier associated with the good, possibly supplemented with other information such as status, measurement results and/or location.
  • Sensor data collection: With sensor data collection, the Ambient IoT device is associated with a sensor. Transfer of sensor data can be initiated by the Ambient IoT device, e.g. periodically or when the Ambient IoT device has power, or can be triggered by the network.
  • Asset tracking: With asset tracking, the main purpose is to determine the location of goods. Ambient IoT devices attached to these goods report an identifier associated with the good. This can then be combined with location information. Asset tracking can also be initiated by an Ambient IoT capable UE (i.e. a UE that can communicate with an Ambient IoT device), thus finding the location of Ambient IoT devices within a particular range of the UE.
  • Actuator control: With actuator control, the Ambient IoT device is associated with an actuator. Transfer of actuator commands is generally initiated by the network.
Up

4.4  Communication modesp. 8

Ambient IoT devices are expected to be able to communicate with the 5G network and/or Ambient IoT capable UE using the one or more of the following communication modes:
Ambient IoT Direct Network Communication:
represents communication between the Ambient IoT device and 5G network with no UE conveying information between the Ambient IoT device and the 5G network.
Ambient IoT Indirect Network Communication:
represents communication between the Ambient IoT device and the 5G network where there is an Ambient IoT capable UE helping in conveying information between the Ambient IoT device and the 5G network.
Ambient IoT device to UE direct Communication:
represents communication between an Ambient IoT device and an Ambient IoT capable UE with no network entity in the middle.
Figures depicting these communication modes are presented below:
Copy of original 3GPP image for 3GPP TS 22.369, Fig. 4.4-1: Ambient IoT Communication Modes
Figure 4.4-1: Ambient IoT Communication Modes
(⇒ copy of original 3GPP image)
Up

5  Functional service requirements of Ambient IoTp. 9

5.1  Generalp. 9

The functional requirement for Ambient IoT service includes 6 aspects, i.e.
  • Communication;
  • Positioning/location;
  • Management;
  • Collected information and network capability exposure;
  • Charging;
  • Security and privacy
The Ambient IoT devices have some special characteristics such as Energy harvesting, Low complexity, Low data rates, Life span, and Reachability, etc.
Ambient IoT capable UEs are 3GPP UEs with the capability to communicate with an Ambient IoT device.

5.2  Functional service requirements of Ambient IoTp. 10

5.2.1  Communication aspectsp. 10

The 5G system shall be able to support 5G network or an Ambient IoT capable UE to communicate with a group of Ambient IoT devices simultaneously.
The 5G network shall support a mechanism to authorize an Ambient IoT capable UE to communicate with an Ambient IoT device.
The 5G system shall be able to support mechanisms to communicate:
  • between an Ambient IoT device and the 5G network using Ambient IoT direct network communication or Ambient IoT indirect network communication, or
  • between an Ambient IoT device and Ambient IoT capable UE using Ambient IoT device to UE communication.
The 5G system shall provide suitable mechanisms to support communication between a trusted and authorized 3rd party and an Ambient IoT device or group of Ambient devices.
Up

5.2.2  Positioningp. 10

The 5G system shall support location services for Ambient IoT devices (e.g., to locate Ambient IoT devices using absolute or relative positioning methods)

5.2.3  Managementp. 10

The 5G network shall support suitable management mechanisms for an Ambient IoT device or a group of Ambient IoT devices.
The 5G system shall support a mechanism to:
  • disable the capability to transmit RF signals for one or more Ambient IoT device that is / are currently able to transmit RF signals
  • enable the capability to transmit RF signals for one or more Ambient IoT device that is / are currently disabled to transmit RF signals
Based on operator policy, the 5G system shall provide a suitable mechanism to permanently disable the capability of an Ambient IoT device or a group of Ambient IoT devices to transmit RF signals.
Subject to operator policy and regulatory requirements, the 5G system shall support suitable mechanisms for the Ambient IoT device to move between one or more networks and countries.
Up

5.2.4  Exposurep. 10

Subject to user consent, operator policy and 3rd party request, the 5G system shall be able to obtain data from Ambient IoT devices (e.g. sensor data) and provide it to a trusted 3rd party via the 5G network.
Subject to user consent, operator's policy and 3rd party request, the 5G system shall provide information about an Ambient IoT device or a group of Ambient IoT devices (e.g. position) to the trusted 3rd party via the 5G network.
The 5G system shall enable an authorized 3rd party to instruct the 5G network to trigger a group of Ambient IoT devices in an specific area and which action the Ambient IoT devices need to perform when triggered (e.g. send ID, receive further information, send measurement value).
Up

5.2.5  Chargingp. 11

The 5G system shall be able to collect charging information in a suitable way for using Ambient IoT services on per Ambient IoT device basis or a group of Ambient IoT devices (e.g., total number of communications per charging period).

5.2.6  Security and privacyp. 11

The 5G system shall enable security protection suitable for Ambient IoT, without compromising overall 5G security protection.
The 5G system shall be able to provide a mechanism to protect the privacy of information (e.g., location and identity) exchanged during communication between an Ambient IoT device and the 5G network or an Ambient IoT capable UE.
Based on subscription and operator policies, the 5G system shall authorize an Ambient IoT capable UE to communicate with a specific Ambient IoT device or with a group of Ambient IoT devices.
Up

6  Performance service requirements of Ambient IoTp. 11

6.1  Generalp. 11

Ambient IoT service can be categorized into 4 categories, namely inventory, sensor data collection, tracking and actuator control. The corresponding performance services requirements are listed in the following subclauses.

6.2  Performance service requirements for Inventoryp. 11

Scenarios Max. allowed end-to-end latency Communi­cation service availa­bility Reliability User-expe­rienced data rate Message size Device density Communi­cation range (Note 1) Service area dimen­sion Device speed Trans­fer inter­val Posi­tioning service latency Posi­tioning service availa­bility Posi­tioning accu­racy
Inven­tory or asset mana­gementTypi­cally, seconds level 99%NA<2 kbit/s96/256 bits<1.5 million devices/km² indoor only (Note 2)30 m - 50 m indoor, 200 m - 400 m outdoor1 km² - 10 km²3 km/h - 10 km/hNANANA3 m indoor, cell-level outdoor
NOTE 1:
The communication range is the communication distance between the ambient IoT device and the 5G network or between the ambient IoT device and an ambient IoT capable UE.
NOTE 2:
The device density is much lower in outdoors as only a subset of assets (e.g., stored indoors) will be in transit, and a much larger area for transit applies.
Up

6.3  Performance service requirements for sensor data collectionp. 13

Deploy­ment Scena­rios Max. allowed end-to-end la­tency Communi­cation service availa­bility Relia­bility User-expe­rienced data rate Message size Device den­sity Communi­cation range (Note 1) Service area dimen­sion Device speed Trans­fer interval Posi­tioning service laten­cy Posi­tioning service availa­bility Posi­tioning accu­racy
IndoorRoom envi­ronment moni­toring (e.g. domicile, machinery)20 s - 30 s99 %NA<1 kbit/s<100 bits1.5 devices/m²10 m - 30 m NAStatio­naryNANANANA
Indoor agricul­ture and husbandry>10 s99.9%NA<1 kbit/sTypically, <1,000 bits1 device /m²30 m - 200 m 6,000 m² - 30,000 m²Quasi-statio­nary15 mins - 30 minsNANANA
OutdoorSmart grid1 s99%NA<1 kbit/s Typi­cally, <800 bits< 10,000 devices /km² Typi­cally, 50 m - 200 m[several km² up to 100,000 km²]Statio­nary5 mins - 15 minsNANAseveral 10 m
Outdoor husban­dry and logisticsTypically, > tens of seconds99%NA<0.5 kbit/s Typically, [<800 bits]<5,200 devices/ km²[300 m - 500 m] 430,000 m²≤ 3 km/h15 minsNANANA
Smart city10 s - 30 s99%NA<1 kbit/sTypi­cally, <800 bits<1,000 devices/ km²300 m - 500 m City wide inclu­ding rural areasStatio­nary15 minsNANANA
NOTE:
The communication range is the communication distance between the ambient IoT device and the 5G network or between the ambient IoT device and an ambient IoT capable UE.
Up

6.4  Performance service requirements for trackingp. 14

Deploy­ment Scena­rios Max. allowed end-to-end laten­cy Communi­cation service availa­bility Relia­bility User-expe­rienced data rate Message size Device density Communi­cation range (Note 1) Service area dimen­sion Device speed Trans­fer interval Posi­tioning service laten­cy Posi­tioning service availa­bility Posi­tioning accu­racy
IndoorIndoor tracking1 s99.9%NA<1 kbit/s<1 kbits25 devices /100 m² - 250 devices /100 m²10 m200 m²up to 3km/h60 mins1 s90%1 m - 3 m, 90% availa­bility
OutdoorOutdoor tracking1 s99.9%NA<1 kbit/s<1 kbits ≤10 devices/ 100 m²500 mUp to the whole PLMNup to 10 km/h60 mins1 s95%several 10 m
NOTE:
The communication range is the communication distance between the ambient IoT device and the 5G network or between the ambient IoT device and an ambient IoT capable UE.
Up

6.5  Performance service requirements for actuator controlp. 14

Deploy­ment Scena­rios Max. allowed end-to-end laten­cy Communi­cation service availa­bility Relia­bility User-expe­rienced data rate Message size Device densi­ty Communi­cation range (Note 1) Service area dimen­sion Device speed Trans­fer interval Posi­tioning service laten­­cy Posi­­tioning service availa­bility Posi­tioning accu­racy
IndoorIndoor actuator controlSeveral seconds99%NA2 kbit/s<100 Bytes<1.5 million/km²50 m<250 m² for home, and 15,800 square meters for super­marketstationary20 mins - 120 minsNANA3 m to 5 m indoor
OutdoorOutdoor actuator control for large coverageSeveral seconds99%N/ANA128 bit (DL)NA[500] m outdoors40,000 m2 - 4,000,000 m2 StaticNANANANA
Outdoor actuator control for medium coverage Several seconds99%NA<2 kbit/s<200 bits <20 devices/ 100 m²200 mCity wide including rural areasStaticNANANANA
NOTE:
The communication range is the communication distance between the ambient IoT device and the 5G network or between the ambient IoT device and an ambient IoT capable UE.
Up

$  Change historyp. 17


Up   Top