Tech-invite  3GPPspace  IETFspace
◀  ▶  21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 38.300  Word version:  19.0.0

Top   Top   Up   Prev   Next
1…   4…   4.7…   5…   5.3…   5.4…   6…   6.2…   6.6…   7…   8…   9…   9.2.2…   9.2.2.5…   9.2.3…   9.2.3.2…   9.2.3.3…   9.2.4…   9.2.6…   9.3…   10…   11…   15…   15.5…   16…   16.2…   16.3…   16.4…   16.8…   16.9…   16.10…   16.12…   16.12.5…   16.12.6…   16.12.6.3   16.12.7   16.13…   16.14…   16.15…   16.18…   16.19…   16.21…   16.22   16.23…   17…   18…   19   20…   21…   22…   A…   B…   C…   G… 
16.23 Support of Ambient IoT  16.23.1 General  16.23.2 Architecture  16.23.3 Radio Protocol Architecture for A-IoT Communication  16.23.4 A-IoT Physical Layer Functions  16.23.4.1 Waveform, numerology, time and frequency domain structure  16.23.4.2 R2D  16.23.4.3 D2R  16.23.5 A-IoT MAC Layer Functions  16.23.5.1 Services and functions  16.23.5.2 A-IoT Paging  16.23.5.3 A-IoT Access Procedure  16.23.5.4 A-IoT Upper-layer Data Transmission  16.23.5.5 AS ID  16.23.6 Inventory Procedure  16.23.7 Command Procedure  16.23.8 A-IoT CN node initiated A-IoT Session Release procedure  16.23.9 gNB initiated A-IoT Session Release procedure  16.23.10 Locating A-IoT devices 
...

 

16.23  Support of Ambient IoT |R19|  p. 260

16.23.1  General  p. 260

A-IoT radio interface provides the communication between A-IoT device(s) and A-IoT reader, as illustrated in Figure 16.23.1-1. In this release, the A-IoT reader is a gNB-reader. A-IoT radio interface can support both inventory procedure and command procedure as defined in TS 23.369. An A-IoT device monitors the R2D message as long as it has sufficient energy.
Reproduction of 3GPP TS 38.300, Fig. 16.23.1-1: Architecture supporting the A-IoT radio interface
Figure 16.23.1-1: Architecture supporting the A-IoT radio interface
Up

16.23.2  Architecture  p. 261

The NG-RAN overall architecture as depicted in section 4.1 is applicable for Ambient IoT along the following adaptations and additions:
  • For the sake of supporting the provision of A-IoT services, the involved gNBs are enabled to support A-IoT, specifically, the gNB supports communication with A-IoT devices by means of A-IoT radio.
  • A gNB may or may not only support communication with A-IoT devices by means of A-IoT radio.
  • A gNB serves one or multiple readers.
  • A gNB is aware of the mapping relationship between A-IoT Areas and readers by means of OAM configuration.
  • An A-IoT Area may include readers belonging to the same or different gNB.
  • One reader only belongs to one gNB.
  • One reader can be mapped to one or multiple A-IoT Areas.
  • As specified in TS 23.369, the A-IoT CN node which the gNB connects to is either the AIOTF (in case of direct connectivity with the AIOTF) or the AMF (in case of indirect connectivity with the AIOTF). A gNB is aware of direct connectivity with the AIOTF via OAM.
  • In this version of the specification, A-IoT specific information is transported between the gNB and the A-IoT CN node via the NG-C interface, the protocol stack in section 4.3.1.2 applies. In case of indirect connectivity with the AIOTF, A-IoT specific information is transferred transparently via the AMF.
  • In this version of the specification, no A-IoT specific communication takes place between gNBs.
  • In this version of the specification, split gNB architecture is not supported.
The AIOTF may request the gNB to perform an A-IoT operation within a specific area (requested service area). The requested service area may be indicated by means of a list of A-IoT Areas and/or a list of readers. The A-IoT Area is represented by an A-IoT Area ID.
The AIOTF is aware of the area within which the gNB supports provision of A-IoT services by means of OAM configuration. This area may be represented as A-IoT Areas and/or the readers supported by the gNB.
The AIOTF may also be aware of the reader's location by means of OAM configuration.
The AIOTF is aware of the mapping relationship among gNBs, readers and A-IoT areas by means of OAM configuration, as needed.
Up

16.23.3  Radio Protocol Architecture for A-IoT Communication  p. 262

The AS protocol stack for A-IoT radio interface contains A-IoT MAC layer and A-IoT physical layer as shown in Figure 16.23.3-1. The AS layer control information and data are handled by A-IoT MAC layer and A-IoT physical layer. For A-IoT radio interface, there is no differentiation between the control plane and the user plane.
Reproduction of 3GPP TS 38.300, Fig. 16.23.3-1: AS protocol stack for A-IoT
Figure 16.23.3-1: AS protocol stack for A-IoT
Up

16.23.4  A-IoT Physical Layer Functions  p. 262

16.23.4.1  Waveform, numerology, time and frequency domain structure  p. 262

The R2D transmission is a DFT-s-OFDM-based OOK waveform with subcarrier spacing Δf=15 ∙ 103 Hz and normal cyclic prefix. The R2D transmission in each OFDM symbol is described by a number of resource blocks, NRBR2D, and one resource block consists of 12 consecutive subcarriers. In each OFDM symbol, there are a number of chips to which modulated symbols are mapped. For in-band operation, the starting position of a A-IoT R2D transmission is aligned in time with the starting position of an NR OFDM symbol.
The D2R transmission is described by a set of chips to which modulated symbols are mapped, and based on backscattering on a carrier wave. The carrier wave is a single-tone sinusoid signal.
Up

16.23.4.2  R2D  p. 262

16.23.4.2.1  Physical reader-to-device channel  p. 262
The Physical Reader-to-Device Channel (PRDCH) carries an R2D transport block originating from the A-IoT MAC layer. The physical-layer processing of PRDCH consists of the following steps:
  • CRC attachment;
  • Line encoding with OOK modulation;
  • Mapping to chips and OFDM symbols.
16.23.4.2.2  Timing acquisition signal  p. 262
An R2D timing acquisition signal (R-TAS) is transmitted immediately before a PRDCH, and consists of a start indicator part (SIP) followed by a clock acquisition part (CAP). The device determines that an R2D transmission begins upon determining that a SIP of R-TAS has been received. The CAP indicates the number of chips per OFDM symbol and chip duration for PRDCH.
16.23.4.2.3  Postamble  p. 262
An R2D postamble is transmitted immediately after the PRDCH.

16.23.4.3  D2R  p. 262

16.23.4.3.1  Physical device-to-reader channel  p. 262
The Physical Device-to-Reader Channel (PDRCH) carries the D2R transport block originating from the A-IoT MAC layer. The physical-layer processing of PDRCH consists of the following steps:
  • CRC attachment;
  • Block repetition;
  • Channel coding, which may be omitted;
  • Modulation of OOK or BPSK, resulting in small frequency shift;
  • Mapping to chips.
16.23.4.3.2  D2R amble signals  p. 263
A D2R preamble signal for timing acquisition, timing tracking and channel estimation, and zero or more D2R midamble signal(s) for timing tracking and channel estimation, are inserted in a D2R transmission. A D2R preamble signal is transmitted immediately before a PDRCH.

16.23.5  A-IoT MAC Layer Functions  p. 263

16.23.5.1  Services and functions  p. 263

The main services and functions of A-IoT MAC layer include (see TS 38.391):
  • Paging;
  • Access;
  • Transfer of upper layer data;
  • Construct MAC PDUs to be mapped onto D2R transport blocks and delivered to the physical layer;
  • MAC padding;
  • D2R segmentation;
  • Process MAC PDUs from R2D transport blocks delivered from the physical layer;
  • Failure detection.

16.23.5.2  A-IoT Paging  p. 263

A-IoT paging allows the A-IoT reader to trigger one, multiple or all A-IoT device(s) to perform A-IoT CBRA or A-IoT CFA. The A-IoT paging message is transmitted on PRDCH. The A-IoT paging message may include zero or one paging identifier, i.e., AIoT Device Permanent Identifier or Filtering Information as specified in TS 23.369. If a paging identifier is included, the A-IoT paging message may be addressed to a single A-IoT device or a group of A-IoT devices. If no paging identifier is included, the A-IoT paging message is addressed to all A-IoT devices. The A-IoT paging message also provides configuration for A-IoT access procedure.
Up

16.23.5.3  A-IoT Access Procedure  p. 263

Both A-IoT CBRA procedure and A-IoT CFA procedure are supported for A-IoT access. The A-IoT device initiates either A-IoT CBRA or A-IoT CFA based on an explicit indication in the A-IoT paging message, if the device is paged.
For CBRA, the A-IoT device randomly selects one access occasion among access occasions configured in A-IoT paging message. The A-IoT device may then monitor the Access Trigger message(s) to determine the start of the selected access occasion and transmits the A-IoT MSG1 (i.e. the Access Random ID message) on this access occasion as described in TS 38.391. The start of the first set of A-IoT MSG1 resources is indicated by A-IoT Paging message directly instead of the Access Trigger message. After A-IoT MSG1 transmission, the device monitors A-IoT MSG2 (i.e. the Random ID Response message) from the A-IoT reader for contention resolution until it has received the configured number of Access Trigger messages or subsequent A-IoT Paging message (i.e., the device does not process the A-IoT MSG2 received after that). Upon successful reception of A-IoT MSG2 which contains the matched frequency index (if present) as used and same random ID as transmitted in A-IoT MSG1, the A-IoT device considers the contention resolution as successful, as shown in Figure 16.23.5.3-1 (a). Otherwise, the A-IoT device considers the contention resolution as failed. If contention resolution is successful, the A-IoT device transmits the D2R Upper Layer Data Transfer message in the resource provided in A-IoT MSG2. If the A-IoT device considers the contention resolution as failed, the A-IoT device shall perform re-access if an A-IoT Paging message with the same transaction ID is received.
For CFA, the A-IoT device shall use the dedicated resource provided in A-IoT paging message to send the D2R Upper Layer Data Transfer message as shown in Figure 16.23.5.3-1 (b). The A-IoT device does not need to monitor the Access Trigger message.
Reproduction of 3GPP TS 38.300, Fig. 16.23.5.3-1: A-IoT Access Procedures
Figure 16.23.5.3-1: A-IoT Access Procedures
Up

16.23.5.4  A-IoT Upper-layer Data Transmission  p. 264

16.23.5.4.1  R2D and D2R data transmission  p. 264
The A-IoT MAC sublayer supports R2D reception and D2R transmission of upper layer data, including inventory response, command and command response. A D2R A-IoT MAC PDU can include padding bit(s). An A-IoT device adds padding bit(s) to a D2R Upper Layer Data Transfer message so that the scheduled TB size of the A-IoT MAC PDU equals to the size of D2R Upper Layer Data Transfer message. After transmitting a D2R Upper Layer Data Transfer message following the reception of A-IoT MSG2, if an A-IoT MSG2 containing its AS ID is received, the A-IoT device retransmits the D2R Upper Layer Data Transfer message. If a NACK message containing its AS ID is received before receiving subsequent A-IoT paging message or a R2D Upper Layer Data Transfer message addressed to it, the A-IoT device shall initiate re-access as specified in clause 16.23.5.3, after receiving an A-IoT Paging message with the same transaction ID.
The A-IoT reader may detect the upper layer response as not available yet through the D2R Upper Layer Data Transfer message with no SDU included. Then the A-IoT reader may send a follow-up R2D Upper Layer Data Transfer message at a later time to schedule another D2R Upper Layer Data Transfer message from the A-IoT device. The follow-up R2D Upper Layer Data Transfer message includes the Received Data Size field, which is set to 0, and excludes the upper layer data.
Up
16.23.5.4.2  Segmentation  p. 264
A D2R upper layer data SDU except for inventory response can be segmented in A-IoT MAC layer so that the size of the D2R Upper Layer Data Transfer message is equal to the scheduled TB size.
Segmentation of R2D upper layer data SDU in A-IoT MAC layer is not supported.

16.23.5.5  AS ID  p. 265

An A-IoT device can be assigned an AS ID or indicated to reuse the random ID transmitted in A-IoT MSG1 of A-IoT CBRA as the AS ID. The AS ID is used by the A-IoT reader to address a specific A-IoT device for R2D reception and scheduling resource for the device to perform D2R transmission. An A-IoT MSG2 of A-IoT CBRA procedure can assign an AS ID or indicate the A-IoT device to reuse the random ID transmitted in A-IoT MSG1 as the AS ID for the device. For A-IoT CFA, an A-IoT device can be assigned an AS ID by a R2D Upper Layer Data Transfer message.
An A-IoT device is not expected to maintain both AS ID and random ID simultaneously, and it maintains at most one AS ID at a time. The A-IoT device does not expect the reader to assign a different AS ID corresponding to a random ID when A-IoT MSG2 is retransmitted.
The A-IoT device releases the stored AS ID, when any of the following conditions is met:
  • It is out of energy;
  • It receives a NACK message addressed to it as specified in TS 38.391;
  • It receives an A-IoT Paging message for A-IoT CBRA, which includes the same transaction ID as the stored one, and the previous procedure was determined to be failed for this transaction ID as specified in TS 38.391;
  • It receives an A-IoT Paging message for A-IoT CBRA, which includes a different transaction ID from the stored one, as specified in TS 38.391;
  • It receives an A-IoT Paging message for A-IoT CFA as specified in TS 38.391.
Up

16.23.6  Inventory Procedure  p. 265

Figure 16.23.6-1 depicts the basic communication between the gNB and the A-IoT CN node for the Inventory procedure.
Reproduction of 3GPP TS 38.300, Fig. 16.23.6-1: Inventory procedure
Figure 16.23.6-1: Inventory procedure
Up
Step 1.
The A-IoT CN node initiates the Inventory procedure over NG-C by sending the Inventory Request message to the gNB. The Inventory Request message includes a Correlation ID and A-IOTF Identifier to identify the inventory session. The Inventory Request message also includes an A-IoT Device Identification Requested corresponding to the A-IoT device(s) which are targeted for the inventory. The A-IoT Device Identification Requested may indicate inventory for a single device, a group of devices or for all devices.
The Inventory Request message also includes Requested Service Area Information (list of A-IoT Area IDs and/or reader list). If the Requested Service Area Information contains:
  • Neither the Requested AIoT Area List nor the Requested Reader List, the gNB shall select all readers it serves;
  • The Requested AIoT Area List, the gNB shall select readers within the indicated AIoT Area(s);
  • The Requested Reader List, the gNB shall take the reader list into account to perform inventory.
The Inventory Request message also includes the Inventory Assistance Information. The Inventory Assistance Information includes the expected D2R message size and may also include e.g., approximate number of Target A-IoT devices, time interval.
The Inventory Request message may also include a follow-on command indicator to indicate that at least for one of the targeted A-IoT device(s) a Command procedure will follow.
Step 2.
The gNB allocates and co-ordinates the usage of A-IoT radio resources.
Step 3.
The gNB confirms the request from the A-IoT CN node by replying with the Inventory Response message. The Inventory Response message includes the AIOTF Identifier and the Correlation ID received in the Inventory Request message.
Step 4.
The Inventory procedure over the A-IoT radio interface is performed, i.e., A-IoT paging, A-IoT Access Procedure and D2R data transmission, as specified in clause 16.23.5.
Step 5./6.
Upon receiving the response(s) from the A-IoT device(s), the gNB sends the Inventory Report message to the A-IoT CN node. If the Inventory procedure concerns multiple A-IoT devices, multiple Inventory Report messages may be sent to the A-IoT CN node.
The Inventory Report message includes the AIOTF Identifier and the Correlation ID received in the Inventory Request message and further includes the A-IoT NAS PDU(s) carrying the inventoried A-IoT device ID(s).
If a follow-on Command indicator was received at step 1, the Inventory Report message also includes a RAN A-IoT device NGAP ID for each A-IoT device which was inventoried.
Upon completion of the inventory procedure the gNB sends an Inventory Complete Indication in the Inventory Report message.
Step 7.
If there is no follow-on command, the A-IOT CN triggers the A-IoT CN node initiated A-IoT Session Release procedure as defined in clause 16.23.8.
Up

16.23.7  Command Procedure  p. 266

Figure 16.23.7-1 depicts the basic communication between the gNB and the A-IoT CN node for the Command procedure.
Reproduction of 3GPP TS 38.300, Fig. 16.23.7-1: Command procedure
Figure 16.23.7-1: Command procedure
Up
The Command procedure addresses only one A-IoT device.
Step 1.
Prior to the Command procedure, the Inventory procedure is performed involving the concerned device and potentially other A-IoT devices.
Step 2.
The A-IoT CN node initiates the Command procedure over NG-C by sending the Command Request message to the gNB in order to send a command to a single A-IoT device. The Command Request message includes the same Correlation ID and AIOTF Identifier as the ones used in its corresponding inventory procedure.
The Command Request also includes the RAN A-IoT device NGAP ID and the A-IoT NAS PDU corresponding to the targeted A-IoT device and may include some command assistance information. This command assistance information may contain the estimate of expected D2R message size.
Step 3.
The gNB allocates and co-ordinates the usage of A-IoT radio resources and performs the command procedure over the A-IoT radio interface, i.e., R2D and D2R data transmission, as specified in section 16.23.5.
Step 4.
The gNB replies to the Command Request with the Command Response message including the AIOTF Identifier the Correlation ID and the RAN A-IoT device NGAP ID received in the Command Request, and the A-IoT NAS PDU received from the device.
Step 5.
Upon completion of all the command transmission for all related devices within the session, the A-IOT CN triggers the A-IoT CN node initiated A-IoT Session Release procedure as defined in clause 16.23.8.
Up

16.23.8  A-IoT CN node initiated A-IoT Session Release procedure  p. 267

Figure 16.23.8-1 depicts the A-IoT CN node initiated A-IoT Session Release procedure, which enables the A-IoT CN node to initiate the release of the A-IoT session context and resources related to a previously established A-IoT Session at the gNB.
Reproduction of 3GPP TS 38.300, Fig. 16.23.8-1: A-IoT CN node initiated A-IoT Session Release procedure
Figure 16.23.8-1: A-IoT CN node initiated A-IoT Session Release procedure
Up
Step 1.
The A-IoT CN node initiates the A-IoT Session Release procedure over NG-C by sending the A-IoT Session Release Command message to the gNB. The A-IoT Session Release Command message includes the Correlation ID and the AIOTF Identifier to identify the session to be released.
Step 2.
The gNB releases the A-IoT session context, the associated NG resources and the A-IoT radio resources.
Step 3.
The gNB confirms the release to the A-IoT CN node by replying with the A-IoT Session Release Complete message. The A-IoT Session Release Complete message includes the AIOTF Identifier and the Correlation ID received in the A-IoT Session Release Command message.
Up

16.23.9  gNB initiated A-IoT Session Release procedure  p. 267

Figure 16.23.9-1 depicts the gNB initiated A-IoT Session Release Request procedure, which enables the gNB to request the A-IoT CN node to release the A-IoT session context and resources related to a previously established A-IoT Session.
Reproduction of 3GPP TS 38.300, Fig. 16.23.9-1: gNB initiated A-IoT Session Release procedure
Figure 16.23.9-1: gNB initiated A-IoT Session Release procedure
Up
Step 1.
The gNB initiates the A-IoT Session Release Request procedure over NG-C by sending the A-IoT Session Release Request message to the A-IoT CN node in order to request the release of an A-IoT session. The A-IoT Session Release Request message includes the Correlation ID and the AIOTF Identifier to identify the session requested to be released.
Step 2.
The A-IoT CN node accepts the request and triggers the A-IoT CN node initiated A-IoT Session Release procedure.
Step 3.
The A-IoT CN node initiated A-IoT Session Release procedure is performed as described in section 16.23.8.
Up

16.23.10  Locating A-IoT devices  p. 268

In this version of specification, the A-IoT device location is reported by the gNB at Reader ID granularity to the AIOTF via Inventory Report procedure. The AIOTF may use the A-IoT device location information in performing A-IoT operations.

Up   Top   ToC