Content for TS 23.369 Word version: 19.1.0

1… 4… 5… 6… 7…

5 High level functionality and features p. 16

5.2 AIoT Services p. 16

The following AIoT Services are supported:

Inventory service;
Command service.

5.2.1 AIoT Inventory service p. 16

AIoT Inventory service is used to discover the AIoT devices, i.e. to obtain the AIoT device identifiers.

5.2.2 AIoT Command service p. 16

5.2.2.1 Overview p. 16

Three types of Command service operations are supported: Read, Write and Disable.

An AF uses the Command service Read operation to retrieve information from AIoT Device(s), and the AIOTF uses the commands described in clause 5.2.2.2 towards the AIoT Device for the operation.

An AF uses the Command service Write operation to write information to AIoT Device(s), and the AIOTF uses the commands described in clause 5.2.2.2 towards the AIoT Device for the operation.

An AF uses the Command service Disable operation to permanently disable the capability of AIoT Device(s) to transmit RF signals, and the AIOTF uses the commands described in clause 5.2.2.3 towards the AIoT Device for the operation.

5.2.2.2 Read and Write Commands p. 17

It is optional for an AIoT Device to support of Read and Write Commands. If supported, an AIoT Device contains User Memory that can be used to store application specific data and is accessed using AIoT NAS commands from an AIOTF. An AIoT Device implementation may have other storage outside of the User Memory that is used to store e.g. AIoT Device Permanent Identifier, etc.

The User Memory is accessed by the following commands and responses between the AIOTF and AIoT Device:

Read Request: used to read application data from User Memory.
Read Response: Response from the AIoT Device to Read Request, providing a status and the application data read from the User Memory.
Write Request: used to write application data to User Memory.
Write Response: Response from the AIoT Device to Write Request, providing a status for the Write Request.

The Read Request and Response, and Write Request and Response commands are used to access the User Memory when an authorized AF uses the Read or Write command service operations, as described in clause 5.2.2.1. The Read or Write Request is sent in the Command Request step and the Read or Write Response is sent in the Command Response step of the Command procedure described in clause 6.2.3.

The physical memory map of an AIoT Device and where the User Memory is within it is implementation specific.

The commands to access the User Memory include an offset from the start of the User Memory to indicate where to read application data from and where to write application data to. The offset and the application data transferred in the Read Request, Write Request, and Read Response has no special meaning to the network, and the AIOTF or other NFs do not attempt to interpret them.

Copy of original 3GPP image for 3GPP TS 23.369, Fig. 5.2.2.2-1: Logical AIoT Device User Memory

Figure 5.2.2.2-1: Logical AIoT Device User Memory
(⇒ copy of original 3GPP image)

The Write Request command is used to write application data into the User Memory and includes:

the application data to write and its length; and
the offset where to write the application data.

The AIoT Device responds with a Write Response indicating whether the Write Request was successful.

The Read command is used to read from the User Memory and includes:

the offset to read application data from; and
the length of the application data to read.

The application data is from the User Memory in the place indicated by the offset and the length.

The AIoT Device responds with a Read Response including whether the read was successful and the application data read from the User Memory.

If an AIoT Device does not support Read Request or Write Request commands, or the parameters in the commands are invalid the AIoT Device shall reject the command.

5.2.2.3 Permanent Disable Command p. 18

An AIoT Device may be permanently disabled. A permanently disabled AIoT Device does not respond to the Inventory Procedure, as described in clause 6.2.2.

An AIoT Device is permanently disabled by the Permanent Disable command sent by an AIOTF to the AIoT Device.

The Permanent Disable command is sent to an AIoT Device when an authorized AF uses the Permanent Disable command service operations as described in clause 5.2.2.1, or if the network determines to disable the AIoT Device. The Permanent Disable command is sent in the Command Request step and a response is sent in the Command Response step of the Command procedure described in clause 6.2.3. The AIoT Device responds indicating whether the Permanent Disable command was successful.

When the AIoT Device has received and verified a Permanent Disable command, it shall no longer respond to the inventory procedure.

5.3 Discovery and Selection of AIoT node(s) p. 18

5.3.1 AIOTF Discovery and Selection p. 18

The AIOTF discovery and selection functionality is to determine an AIOTF(s) to handle an AIoT service operation request.

The NEF determines AIOTF instances(s) by providing the NRF with Target Area information and the NRF returning AIOTF instance(s) that match the provided Target Area information, or by using local configuration.

A service operation request received by the NEF from an AF may include External Target Area information and the NEF uses it to determine the Target Area information that is provided to the AIOTF and NRF, if used. The External Target Area information is a pre-configured External Area Identifier or geographic area (e.g., a civic address or GAD shapes). The Target Area information is a list of AIoT Areas.

When an AIoT service operation request indicates individual AIoT Device(s), the AIOTF instance(s) may be selected by taking into account the last known AIOTF instance(s) (e.g. AIOTF ID/address) for those AIoT Device(s) obtained from the ADM.

5.3.2 ADM Discovery and Selection p. 18

The ADM discovery and selection function is supported by the AIOTF to select an ADM instance to retrieve the device profile data or update the last known AIOTF for the AIoT device. The AIOTF may also discover and select an ADM to retrieve AF authorization data. Similarly, the NEF uses the ADM discovery and selection function to select an ADM to obtain the last known AIOTF for the AIoT device.

When the ADM discovery is performed, the AIOTF or the NEF utilizes the NRF to discover the ADM instance(s) unless the ADM information is available by other means, e.g., locally configured. The AIOTF or the NEF selects an ADM instance based on the available ADM instances (obtained from the NRF or locally configured).

The following factors may be considered for the ADM discovery and selection for AIoT device profile retrieval or update:

The domain information or the AIoT device permanent ID.

The following factors may be considered for the ADM discovery and selection for AF authorization data retrieval:

The AF ID.

5.3.3 NG-RAN Node and RAN Reader Selection p. 19

The AIOTF selects NG-RAN node(s) and optionally RAN Readers based on the configured NG-RAN configuration information and the received AIoT service operation request. The AIOTF may also select a RAN Reader based on the stored last known RAN Reader information.

The AIOTF obtains the NG-RAN configuration information (NG-RAN node ID, AIoT Area ID list, optionally RAN Reader(s) associated with each AIoT area and, optionally, the location served by each RAN Reader) via OAM or local configuration.

When the AIOTF receives an AIoT service operation request, based on the received Target Area information in the AIoT service operation request and the NG-RAN configuration information, the AIOTF selects the NG-RAN node(s) and optionally RAN Reader(s) to handle the request and the AIOTF determines a Requested Service Area Information for each selected NG-RAN node. The Requested Service Area Information provided by the AIOTF to each selected NG-RAN node can be empty, or includes a list of AIoT Area IDs, a list of RAN Reader IDs, or both a list of AIoT Area IDs and a list of RAN Reader IDs. How the NG-RAN node determines RAN Readers based on the Requested Service Area Information is specified in TS 38.300.

The AIOTF sends the AIoT service operation request to each selected NG-RAN node, either directly or through the selected AMF, including the Requested Service Area Information for the NG-RAN node.

If an AIoT service operation request received by the AIOTF includes individual target AIoT Device Perminant ID(s), the AIOTF may consider the last known serving RAN Reader, if available from the AIoT Device context to determine the NG-RAN node and RAN Reader(s) for the request. In this case the last known serving RAN Reader ID is sent as the Requested Service Area to the selected NG-RAN node.

5.3.4 AMF Discovery and Selection p. 19

For indirect Connectivity via AMF (see clause 4.2), AMF discovery and selection functionality is implemented in AIOTF.

In this case, the AIOTF is locally configured with the information of the AMF corresponding NG-RAN node(s).

The AIOTF selects the AMF that is corresponding to the selected NG-RAN nodes based on the local configuration in order to forward the AIoT service operation messages towards the selected NG-RAN node(s) (see NG-RAN Node and RAN Reader Selection in clause 5.3.3) via the selected AMF.

5.4 Assistance information provided to NG-RAN node p. 20

The AIOTF provides the following assistance information to the NG-RAN together with the service operation requests.

For Inventory or Command service operation, following Inventory Assistance Information is included in the Inventory Request from AIOTF to NG-RAN:

Optionally, approximate number of AIoT devices based on AF request.

Size of the Inventory Response message from the AIoT Device.

Optionally, time interval for AIoT Device response aggregation used by the NG-RAN as specified in clause 5.9.

For Command service operation, following Command Assistance Information is included in the Command Request from AIOTF to NG-RAN:

Size of the Command Response message from the AIoT Device.

Bullet b) is determined by AIOTF based on the AIoT Device ID length for the AIoT Devices that are expected to respond to Inventory.

If not provided by the AF, bullet c) in the above assistance information provided by the AIOTF may be based on local configuration based on SLA between the AIoT service provider represented by an AF and the operator.

The assistance information is used by the NG-RAN for performing service operations, e.g., radio resource allocation by using bullets a), b) and d), AIoT Device responses aggregation by using bullet c).

5.5 AIoT Device Profile Management p. 20

The ADM may hold operator's subscription data for the AIoT Device used in the network. If the AIoT Device is managed by the network, then the profile data for an AIoT Device is required in the network, otherwise the corresponding profile data (e.g. AIoT Device Permanent ID or credentials) is stored external to the network.

The AIoT Device Permanent ID is used by the AIOTF together with local configuration, 3rd party related context to locate the entity which stores the profile data of an AIoT Device.

In case the AIoT Device is managed by the network, the AIOTF checks whether the AIoT Device Permanent ID from AIoT Device has the profile data in the network and retrieves the profile data. The profile data for AIoT Device is different with UE subscription data as defined in clause 5.2.3 of TS 23.502, it is stored in the ADM network entity that exclusively supports management of AIoT Device's profile data. The AIoT Device Permanent ID is the primary key for AIoT device profile data in the ADM.

The Table 5.5-1 below describes information storage structures for AIoT device profile data.

Table 5.5-1: AIoT Device Profile Data

Field	Description
AIoT Device Permanent ID	Uniquely identifies the AIoT Device.
Last known AIOTF information	Indicate the last known AIOTF that serves the AIoT device, or unknown.

5.6 AF authorization for the AIoT Services p. 20

The information needed to support the authorization of the AF for performing the AIoT service is stored as the authorization data for 3rd party AF in the ADM, or locally configured in the AIOTF.

Table 5.6-1 below describes items stored as AF authorization data for the AIoT.

Table 5.6-1: AF Authorization Data for AIoT

AF Authorization Data	Description
AF ID	Identifier used to identify the AF.
Allowed area	Indicate the allowed area for the indicated AF to perform the AIoT services operations.
Allowed service operations	Indicate the allowed service operation (s) for the indicated AF, e.g. inventory, read, write, permanent disable.
Allowed target AIoT Devices	Indicate the allowed AIoT Device(s) for the indicated AF. The information indicating the allowed target AIoT Devices is a list of the permanent AIoT Device ID (see clause 5.7) or the filtering information (see clause 5.8).

The authorization of the AF for the AIoT includes two parts:

NEF performs AIoT AF request authorization based on the service level agreement (SLA) between the 3rd party AF and the 5GS of the mobile network operator, the operator policy and local configuration as in TS 33.501.
AIOTF may perform authorization of AIoT service requested by the AF, using the AF authorization data retrieved from n the ADM or configured locally as described in above Table 5.6-1. When ADM is used, the AIOTF also subscribes to changes of AF authorization data in the ADM for synchronization.

5.7 Identifiers p. 21

5.7.1 General p. 21

Void

5.7.2 AIoT Device Permanent Identifier p. 21

In order to support the AIoT feature in 5G System, a globally unique AIoT Device Permanent Identifier shall be allocated to each AIoT Device. An AIoT Device Permanent Identifier is assigned either by an operator or by a third party. The AIoT Device Permanent Identifier is used to identify an AIoT Device and locate the entity where the AIoT Device related information is stored.

The AIoT Device Permanent Identifier includes the following components:

The ID Type, including:
- Information indicating whether a PLMN ID is included.
- Information indicating whether a NID is included.
- Information indicating whether a third party identifier is included.
- Identification Information Type, indicating whether the Identification Information contains an EPC or unstructured information.
The Domain Information includes none, one or more of the following:
- A PLMN Identifier (i.e., MCC and MNC) as specified in TS 23.003 when the information in the ID type indicates it is included
- A Network Identifier (NID) as specified in TS 23.003 when the information in the ID type indicates it is included.
- A third party identifier used to identify a third party when the information in the ID type indicates it is included.
The Identification Information is used to distinguish different AIoT Devices within the scope identified by Domain Information (if available) and can contain either:
- An EPC, as defined in clause 14 of GS1 TDS Release 2.1 [7].
- Unstructured information, where the contents is defined by the allocator.

Copy of original 3GPP image for 3GPP TS 23.369, Fig. 5.7.2-1: AIoT Device Permanent Identifier Structure

Figure 5.7.2-1: AIoT Device Permanent Identifier Structure
(⇒ copy of original 3GPP image)

An operator allocated AIoT Device Permanent Identifier should include the identifier of the network for the operator. The identifier of the network is present as either a PLMN Identifier, NID or both in the AIoT Device Permanent Identifier.

A third party allocated AIoT Device Permanent Identifier may include none of the following information or include any combination of at least one kind of the following information: a PLMN Identifier, NID or the third party identifier.

The following lengths are supported for the Identification Information in an AIoT Device Permanent Identifier: 96 bits, and 128 bits.

5.7.3 Correlation ID p. 22

Correlation ID is generated by AIOTF corresponding to an AF service operation request. It is used together with AIOTF ID to uniquely identify an AIoT Session between the NG-RAN and AIOTF which is corresponding to an AF service operation request. Correlation ID shall be unique within an AIOTF.

5.8 Filtering Information p. 22

The Filtering Information is used to identify or filter one or multiple AIoT Device(s). The Filtering Information is constructed by one or multiple filtering elements and each filtering element corresponds to a component (i.e. ID Type, PLMN Identifier, NID, Third Party Identifier or Identification Information) of the AIoT Device Permanent Identifier as defined in clause 5.7.

Each filtering element shall include:

Component Type Information indicating a component of the AIoT Device Permanent Identifier that is used to match the bitstring.
A bitstring which is used to compare with the component.
An Offset from the beginning of the indicated component of the AIoT Device Permanent Identifier, which indicates the start location in the indicated component to be used to compare with the corresponding bitstring.

When the Component Type Information of a filtering element indicates a PLMN ID, NID or Third Party Identifier component, then the Offset is not included in the filtering element, i.e. the whole component is compared with the bitstring.

When the Component Type Information of the filtering element indicates an Identification Information component, the Offset is always included, i.e. the component from the start location indicated by the corresponding Offset is compared with the bitstring.

There may be multiple filtering elements corresponding to the component Identification Information of the AIoT Device Permanent Identifier.

Copy of original 3GPP image for 3GPP TS 23.369, Fig. 5.8-1: The example of the comparing the bitstring to the component

Figure 5.8-1: The example of the comparing the bitstring to the component
(⇒ copy of original 3GPP image)

To determine whether an AIoT Device Permanent Identifier matches the Filtering Information, the bitstring of every filtering element within the Filtering Information is compared with the indicated component of the AIoT Device Permanent Identifier. If all the compared bitstrings match the corresponding component of the AIoT Device Permanent Identifier, then an AIoT Device Permanent Identifier matches the Filtering Information. If an AIoT Device Permanent Identifier does not contain an indicated component then it does not match the Filtering Information.

5.9 AIoT Service Operation Result Aggregation p. 23

An AIoT service operation may involve many AIoT Devices. The NG-RAN may perform AIoT service operation result aggregation with a specific Correlation ID based on the aggregation assistance information received from the AIOTF for a service operation request as specified in clause 5.4.

The AIOTF determines the aggregation assistance information based on the request from the AF or local configuration, which includes:

Time interval: the fixed time interval for which NG-RAN collects multiple AIoT Devices' operation responses before reporting the aggregated AIoT response to the AIOTF. The reporting based on time interval may potentially happen multiple times until the NG-RAN completes the request operation.

If the AF has provided a time interval, then the AIOTF should signal a time interval to the NG-RAN that is equal or shorter than the time interval received from the AF.

If the AIOTF does not provide aggregation assistance information, the aggregation process in the NG-RAN may be determined by implementation.

The AIOTF may also aggregate the results of a requested service operation before sending them to the NEF or trusted AF.

5.10 AIoT Device Location p. 24

5.10.1 Overview p. 24

During inventory procedure (see clause 6.2.2) or command procedure (see clause 6.2.3), the AIOTF may be requested to report AIoT Device Locations. Based on operator policy, the AIOTF determines whether to provide the AIoT Device Location to the AF.

The Inventory Report(s) sent by NG-RAN include a RAN Reader ID for each reported AIoT Device. The location of each RAN Reader may be configured in the AIOTF. If configured, the AIOTF uses the location of RAN Reader to determine the location of the AIoT Device.