[go: up one dir, main page]

WO2025033139A1 - Method of first communication apparatus, method of communication apparatus, first communication apparatus and communication apparatus - Google Patents

Method of first communication apparatus, method of communication apparatus, first communication apparatus and communication apparatus Download PDF

Info

Publication number
WO2025033139A1
WO2025033139A1 PCT/JP2024/025990 JP2024025990W WO2025033139A1 WO 2025033139 A1 WO2025033139 A1 WO 2025033139A1 JP 2024025990 W JP2024025990 W JP 2024025990W WO 2025033139 A1 WO2025033139 A1 WO 2025033139A1
Authority
WO
WIPO (PCT)
Prior art keywords
ambient
iot
service
communication apparatus
communication
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/JP2024/025990
Other languages
French (fr)
Inventor
Toshiyuki Tamura
Kundan Tiwari
Iskren Ianev
Hisashi Futaki
Sadafuku Hayashi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NEC Corp filed Critical NEC Corp
Publication of WO2025033139A1 publication Critical patent/WO2025033139A1/en
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50—Service provisioning or reconfiguring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H02—GENERATION; CONVERSION OR DISTRIBUTION OF ELECTRIC POWER
    • H02J—CIRCUIT ARRANGEMENTS OR SYSTEMS FOR SUPPLYING OR DISTRIBUTING ELECTRIC POWER; SYSTEMS FOR STORING ELECTRIC ENERGY
    • H02J50/00—Circuit arrangements or systems for wireless supply or distribution of electric power
    • H02J50/001—Energy harvesting or scavenging
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
    • H04W8/24—Transfer of terminal data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/04—Terminal devices adapted for relaying to or from another terminal or user
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/18—Service support devices; Network management devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/16—Interfaces between hierarchically similar devices
    • H04W92/18—Interfaces between hierarchically similar devices between terminal devices

Definitions

  • the present disclosure relates to a method of a first communication apparatus, a method of a communication apparatus, a first communication apparatus and a communication apparatus etc.
  • NPL 2 3GPP TR 22.840 (NPL 2), there is a strong market demand for the 3GPP system to support ambient power-enabled Internet of Things (i.e., Ambient IoT).
  • Ambient IoT ambient power-enabled Internet of Things
  • the Ambient IoT 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.
  • NPL 2 defines the automated warehouse inventory scenario, which is divided into verification and unloading, gate-in inventory, inventory, gate-out inventory and check & loading. Along with the transfer, storage and inventory of goods, a large amount of warehousing information will be generated.
  • NPL 2 defines that there are two gate inventory modes supported by both the management platform and the 5G system. ⁇ Manual-Triggered Mode: The inventory task is triggered by the command sent from the management platform, so the 5G system simply execute the command (e.g., start the inventory task).
  • ⁇ Auto-Triggered Mode The inventory management system set the gate inventory mode to "Auto-Triggered", the 5G network send discovery signal periodically to discover Ambient IoT devices within the gate area; if at least one Ambient IoT device is discovered, then the 5G system start inventory task automatically.
  • NPL 1 3GPP TR 21.905: "Vocabulary for 3GPP Specifications”.
  • NPL 2 3GPP TR 22.840: "Study on Ambient power-enabled Internet of Things”.
  • NPL 3 3GPP TR 38.848: "Study on Ambient IoT (Internet of Things) in RAN”.
  • NPL 4 3GPP TS 23.501: "System architecture for the 5G System (5GS)”.
  • NPL 5 3GPP TS 23.502: “Procedures for the 5G System (5GS)".
  • NPL 6 3GPP TS 23.503: "Policy and charging control framework for the 5G System (5GS) Stage 2".
  • NPL 7 3GPP TS 24.501: "Non-Access-Stratum (NAS) protocol for 5G System (5GS) Stage 3".
  • NPL 8 3GPP TS 33.501: "Security architecture and procedures for 5G system”.
  • NPL 9 3GPP TS 23.003: “Numbering, addressing and identification”.
  • NPL 10 IETF RFC 5580: "Carrying Location Objects in RADIUS and Diameter”.
  • NPL 11 3GPP TS 23.304: "Proximity based Services (ProSe) in the 5G System (5GS)”.
  • NPL 12 3GPP TS 23.247: "Architectural enhancements for 5G multicast-broadcast services Stage 2”.
  • 3GPP operators may lose business opportunities for goods managements using the Ambient IoT devices.
  • 3GPP operators may lose business opportunities for goods managements using the Ambient IoT devices.
  • a method of a first communication apparatus includes: sending information related to Ambient Internet of Things (IoT) to a second communication apparatus.
  • IoT Ambient Internet of Things
  • a method of a first communication apparatus includes: receiving information related to Ambient Internet of Things (IoT) from a second communication apparatus.
  • IoT Ambient Internet of Things
  • a method of a communication apparatus includes: performing a Registration procedure for Ambient Internet of Things (IoT).
  • IoT Ambient Internet of Things
  • a method of a first communication apparatus includes: sending information for activating Ambient Internet of Things (IoT) to a second communication apparatus.
  • IoT Ambient Internet of Things
  • a method of a first communication apparatus includes: receiving first information for activating Ambient Internet of Things (IoT) from a second communication apparatus.
  • IoT Ambient Internet of Things
  • a first communication apparatus includes: means for sending information related to Ambient Internet of Things (IoT) to a second communication apparatus.
  • IoT Ambient Internet of Things
  • a first communication apparatus includes: means for receiving information related to Ambient Internet of Things (IoT) from a second communication apparatus.
  • IoT Ambient Internet of Things
  • a communication apparatus includes: means for performing a Registration procedure for Ambient Internet of Things (IoT).
  • IoT Ambient Internet of Things
  • a first communication apparatus includes: means for sending information for activating Ambient Internet of Things (IoT) to a second communication apparatus.
  • IoT Ambient Internet of Things
  • a first communication apparatus includes: means for receiving first information for activating Ambient Internet of Things (IoT) from a second communication apparatus.
  • IoT Ambient Internet of Things
  • Fig. 1 is an Architecture supporting Ambient IoT devices of a First example of a First Aspect.
  • Fig. 2 is an Identity management model for Ambient IoT device of a First scenario in First example of the First Aspect.
  • Fig. 3 is a Signaling diagram of a Second scenario in First example of the First Aspect.
  • Fig. 4 is a Signaling diagram of a Third scenario in First example of the First Aspect.
  • Fig. 5 is a Signaling diagram of a Fourth scenario in First example of the First Aspect.
  • Fig. 6 is a Service management model for Ambient IoT device of a Fifth scenario in First example of the First Aspect.
  • Fig. 7 is a Signaling diagram of a Sixth scenario in First example of the First Aspect.
  • Fig. 1 is an Architecture supporting Ambient IoT devices of a First example of a First Aspect.
  • Fig. 2 is an Identity management model for Ambient IoT device of a First scenario in First example of the First A
  • Fig. 22 is a Signaling diagram of a Ninth scenario in Fourth example of the First Aspect.
  • Fig. 23 is an Overall network model supporting multiple Ambient IoT devices of a Second Aspect.
  • Fig. 24 is an ISO/IEC RFID related standard air interface as an example of the Second Aspect.
  • Fig. 25 is an Independent air interface of a First example of the Second Aspect.
  • Fig. 26 is a Signaling diagram of a First scenario in First example of the Second Aspect.
  • Fig. 27 is a Converged air interface of a Second example of the Second Aspect.
  • Fig. 28 is a Signaling diagram of a First scenario in Second example of the Second Aspect.
  • Fig. 38 is a block diagram illustrating an AMF.
  • Fig. 39 is a block diagram illustrating an SMF.
  • Fig. 40 is a block diagram illustrating a UPF.
  • Fig. 41 is a block diagram illustrating a PCF.
  • Fig. 42 is a block diagram illustrating an NWDAF.
  • Fig. 43 is a block diagram illustrating a UDM.
  • Fig. 44 is a block diagram illustrating an NSSF.
  • Fig. 45 is a block diagram illustrating an NSACF.
  • Fig. 46 is a block diagram illustrating an AUSF.
  • Fig. 47 is a block diagram illustrating a NEF.
  • Fig. 48 is a block diagram illustrating an AF.
  • NPL 1 abbreviations for the purposes of the present document, the abbreviations given in 3GPP TR 21.905 (NPL 1) and the following apply.
  • An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in NPL 1.
  • 4G-GUTI 4G Globally Unique Temporary UE Identity
  • 5GC 5G Core Network
  • 5GLAN 5G Local Area Network
  • 5G HE AV: 5G Home Environment Authentication Vector
  • 5G SE AV: 5G Serving Environment Authentication Vector
  • 5GS 5G System
  • 5G-AN 5G Access Network
  • 5G-AN 5G Access Network
  • PDB 5G Access Network Packet Delay Budget
  • 5G-EIR 5G-Equipment Identity Register
  • 5G-GUTI 5G Globally Unique Temporary Identifier
  • 5G-BRG 5G Broadband Residential Gateway 5G-CRG: 5G Cable Residential Gateway 5G GM: 5G Grand Master 5G-RG: 5G Residential Gateway 5G-S-TMSI: 5G S-Temporary Mobile Subscription Identifier
  • 5G VN 5G Virtual Network
  • 5QI 5G QoS Identifier
  • ABBA Anti-Bidding down Between Architectures AF: Application Function AMF: Access and Mobility Management
  • NPL 1 definitions for the purposes of the present document, the terms and definitions given in NPL 1 and the following apply.
  • a term defined in the present document takes precedence over the definition of the same term, if any, in NPL1.
  • each of Aspects and elements included in the each of Aspects described below may be implemented independently or in combination with any other. These Aspects include novel characteristics different from one another. Accordingly, these Aspects contribute to achieving objects or solving problems different from one another and contribute to obtaining advantages different from one another.
  • An example object of this disclosure is to provide a method and apparatus that can solve the above-mentioned problem.
  • Namf_Communication_NonUeN2InfoNotify ⁇ GTP-C messages Any UDM service-related messages (ex. Nudm_SDM_Notification) ⁇ DIAMETER messages 5G-GUTI ⁇ GUTI 5G-S-TMSI ⁇ S-TMSI
  • the above-mentioned service requirement (e.g. the automated warehouse inventory scenario) or a service achieved by the above-mentioned service requirement can be expressed as a support of ambient power-enabled Internet of Things, a support of Ambient IoT devices, a support of RFID devices, ambient power-enabled Internet of Things communication, Ambient IoT device communication, Ambient IoT device communication, Ambient IoT communication, Ambient IoT service etc.
  • the automated warehouse inventory scenario may be included in the Ambient IoT device communication, Ambient IoT device communication, Ambient IoT communication, or Ambient IoT service.
  • the Ambient IoT device may be expressed as a IoT device, a device for the Ambient IoT, a device for the Ambient IoT service, a device for the Ambient IoT communication, a UE for the Ambient IoT, a UE for the Ambient IoT service, a UE for the Ambient IoT communication etc.
  • a method of a first communication apparatus includes sending information related to Ambient Internet of Things (IoT) to a second communication apparatus.
  • IoT Ambient Internet of Things
  • a method of a first communication apparatus includes receiving information related to Ambient Internet of Things (IoT) from a second communication apparatus.
  • IoT Ambient Internet of Things
  • a method of a communication apparatus includes performing a Registration procedure for Ambient Internet of Things (IoT).
  • IoT Ambient Internet of Things
  • a method of a first communication apparatus includes sending information for activating Ambient Internet of Things (IoT) to a second communication apparatus.
  • IoT Ambient Internet of Things
  • a method of a first communication apparatus includes receiving first information for activating Ambient Internet of Things (IoT) from a second communication apparatus.
  • IoT Ambient Internet of Things
  • a first communication apparatus includes at least one memory, and at least one hardware processor coupled to the at least one memory.
  • the at least one hardware processor is configured to send information related to Ambient Internet of Things (IoT) to a second communication apparatus.
  • IoT Ambient Internet of Things
  • a first communication apparatus includes at least one memory, and at least one hardware processor coupled to the at least one memory.
  • the at least one hardware processor is configured to receive information related to Ambient Internet of Things (IoT) from a second communication apparatus.
  • IoT Ambient Internet of Things
  • a communication apparatus includes at least one memory, and at least one hardware processor coupled to the at least one memory.
  • the at least one hardware processor is configured to perform a Registration procedure for Ambient Internet of Things (IoT).
  • IoT Ambient Internet of Things
  • a first communication apparatus includes at least one memory, and at least one hardware processor coupled to the at least one memory.
  • the at least one hardware processor is configured to send information for activating Ambient Internet of Things (IoT) to a second communication apparatus.
  • IoT Ambient Internet of Things
  • a first communication apparatus includes at least one memory, and at least one hardware processor coupled to the at least one memory.
  • the at least one hardware processor is configured to receive first information for activating Ambient Internet of Things (IoT) from a second communication apparatus.
  • IoT Ambient Internet of Things
  • This aspect includes an architecture and mechanisms to realize the following two gate inventory modes by the 3GPP 5G system.
  • Manual-Triggered Mode The inventory task is triggered by the command sent from the management platform, so the 5G system simply execute the command (e.g., start the inventory task).
  • Auto-Triggered Mode The inventory management system set the gate inventory mode to "Auto-Triggered", the 5G network send discovery signal periodically to discover Ambient IoT devices within the gate area; if at least one Ambient IoT device is discovered, then the 5G system start inventory task automatically.
  • Fig. 1 includes an example of an architecture that supports ambient IoT devices.
  • the UE 3 in Fig. 1 represents an ambient IoT device.
  • the UE 3 may support a radio interface specific to the ambient IoT device communication.
  • the Radio Cell 50201 and Radio Cell 50202 support Uu interface, the Radio Cell 50201 and Radio Cell 50202 support the radio interface specific to the ambient IoT device communication.
  • the Radio Cell 50201 and Radio Cell 50202 may be controlled by the RAN 501.
  • the Radio Cell may be expressed as a cell.
  • the Radio Cell 50201 and the Radio Cell 50202 may be a repeater that forwards signal from the RAN 501 to the UE 3 and forwards signal from the UE 3 to the RAN 501.
  • the Radio Cell 50201 and the Radio Cell 50202 may be an RU connected to the RAN 501.
  • the RU may be a logical node defined in O-RAN ALLIANCE.
  • the Radio Cell 50201 and the Radio Cell 50202 may be a logical node collocated with the RAN 501.
  • the Radio Cell 50201 and the Radio Cell 50202 may be a logical node defined in some of the 3GPP specifications.
  • the Radio Cell 50201 and the Radio Cell 50202 may be a DU (e.g., gNB-DU).
  • the RAN 501 may be a CU (e.g., gNB-CU).
  • the Radio Cell 50201 and the Radio Cell 50202 may be a Road Side Unit (RSU).
  • RSU Road Side Unit
  • the AF 20101 represents an application server in the data network.
  • the AF 20101 may trigger a task to collect the status of the Ambient IoT devices.
  • the AF 20102 represents an application server in the data network.
  • the AF 20102 may be a server that collects the status of the Ambient IoT devices.
  • the AF 20101 and the AF 20102 may be combined as one Application Function.
  • the AF 20101 and the AF 20102 may be collocated at the same location or located at different locations and in different network domains.
  • the AF 20101 is located at an Ambient IoT device control centre while the AF 20102 is located at an Ambient IoT device data centre.
  • Fig. 2 includes an example of the Identity management model for Ambient IoT device.
  • the Identity management model for Ambient IoT device is characterized as the following features.
  • Ambient IoT device identity may be represented as GPSI.
  • GPSI is converted to a 3GPP Identity, e.g. SUPI, by the NEF 79.
  • the Ambient IoT device identity may have one or multiple TMGI(s).
  • the TMGI represents a group of the Ambident IoT device.
  • the TMGI may be preconfigured in the UE 3 by the Service provider.
  • the TMGI may be configured by the NAS procedure, for example, the Registration procedure or the UE Configuration update procedure.
  • the AF 201 at least one of the AF 20101 and the AF 20102
  • the AF 201 initiates a device trigger procedure to the 5GS using the TMGI.
  • the AF 201 may perform a procedure for communicating with the group members towards the 5GS using the TMGI.
  • the TMGI is used by the RAN 501 and the Radio Cell 502 (e.g. at least one of the Radio Cell 50201 and Radio Cell 50202) as the Group paging identity.
  • the UE 3 and RAN 501 execute paging procedure by replacing 5G-GUTI with the TMGI in the paging procedure as defined in NPL 12.
  • ⁇ TMGI may be called as Multicast MBS group.
  • Fig. 3 includes an example of the Ambient IoT device management procedure of the UE 3 that supports the Ambient IoT communication.
  • Step 1 The AF 201 triggers an Ambient IoT device management procedure.
  • the AF 201 adds at least one Ambient IoT device as the subject to the Ambient IoT service provided by the PLMN operators or NPN operators.
  • Step 2 The AF 201 sends the Nnef_ParameterProvision_Create message including Ambient IoT data.
  • the Ambient IoT data may include at least one of the following data: ⁇ GPSI: Generic Public Subscription Identifier.
  • This GPSI is an identity of the Ambient IoT device.
  • the GPSI may be provisioned to the Ambient IoT device by being preconfigured in the device or provisioned during the Registration procedure or provisioned by the UE Configuration Update procedure or the SoR procedure.
  • the GPSI may be called as Ambient IoT device ID, Tag-ID etc.
  • the GPSI may be the GPSI of the added Ambient IoT device.
  • ⁇ List of TMGI List of Temporary Mobile Group Identity. The TMGI is used to trigger the Ambient IoT device to start the Ambient IoT communication.
  • the TMGI represents a group of Ambient IoT devices. Each Ambient IoT device may be associated with one TMGI or multiple TMGIs.
  • the TMGI may be provisioned to the Ambient IoT device by preconfigured in the device or provisioned during the Registration procedure or provisioned by the UE Configuration Update procedure or the SoR procedure.
  • the TMGI may be called as Group paging identity, Device Short Tag or ProSe Layer-2 Group ID etc.
  • the List of TMGI may include at least one TMGI.
  • the TMGI may represent a group regarding the added Ambient IoT device.
  • the TMGI may represent a group that the added Ambient IoT device belongs.
  • the added Ambient IoT device may be associated with one TMGI or multiple TMGIs.
  • the Ambient IoT device may be associated with one TMGI or multiple TMGIs.
  • TMGI(s) in the List of TMGI may indicate the added Ambient IoT device.
  • TMGI(s) in the List of TMGI may indicate group(s) that the added Ambient IoT device belongs.
  • ⁇ List of PLMN List of PLMN indicates PLMN(s) that can provide the Ambient IoT service. This list may be referred by the home PLMN (where the UDM 75 is located) when the UE 3 (e.g. Ambient IoT device) roams to a visited PLMN (VPLMN).
  • the HPLMN may understand that the AF 201 has a business association with the VPLMN and may provide the Ambient IoT related data to the VPLMN.
  • the List of PLMN may be security protected by the AF 201.
  • the List of PLMN may be read by the UE 3 as the AF 201 and UE 3 has been pre-configured a security parameter. I.e., any node in 5GC or RAN may not be able to read the List of PLMN.
  • ⁇ Ambient IoT profile This is a profile of the Ambient IoT device.
  • the Ambient IoT profile defines an air interface between the UE 3 and network for the Ambient IoT communication.
  • the air interface may be expressed as the radio interface.
  • the Ambient IoT profile may be security protected by the AF 201.
  • the Ambient IoT profile may be read by the UE 3 as the AF 201 and UE 3 have been pre-configured a security parameter. I.e., any node in 5GC or RAN may not be able to read the Ambient IoT profile.
  • the Ambient IoT profile may include at least one of the following data: >Frequency band that is used for the radio interface specific to the Ambient IoT device communication.
  • the Frequency band may indicate frequency band(s) that the UE 3 supports or uses for the Ambient IoT device communication.
  • Air interface that is used for the radio interface specific to the Ambient IoT device communication.
  • Ambient IoT device identity format A format of the Ambient IoT device.
  • the Ambient IoT device identity format may be called as an RFID formation.
  • >Security parameter A Security parameter for an authentication and/or an authorization procedure between the Ambient IoT device and a network when the Ambient IoT device communicates with the network.
  • the authentication and/or the authorization procedure may be the Primary authentication that NPL 8 defines or a specific authentication and/or the authorization scheme to the radio interface between the Ambient IoT device and a network.
  • the authentication and/or the authorization procedure may be a UE authentication and/or authorization, or a mutual authentication and/or the authorization between the Ambient IoT device and the network.
  • the network may be called as a radio cell, a base station, a relay UE, a UE, an IAB node, a reader, a Tag-ID reader.
  • the Security parameter may be a pre-shared key or etc.
  • ⁇ Report to server address An address of server that the Ambient IoT device communicates with during the Ambient IoT communication.
  • the Report to server address may be called as a server, Ambient IoT data server, data centre or etc.
  • the Report to server address may be security protected by the AF 201.
  • the Report to server address may be read by the UE 3 as the AF 201 and UE 3 has been pre-configured a security parameter. I.e., any node in 5GC or RAN may not be able to read the Report to server address.
  • the Ambient IoT data may be expressed as information or data related to or regarding the Ambient IoT device.
  • the Ambient IoT data may be expressed as information or data related to or regarding the Ambient IoT.
  • Step 3 Upon reception of the Nnef_ParameterProvision_Create message from the AF 201, the NEF 79 converts the received GPSI to a SUPI.
  • the NEF 79 may store correspondence between the GPSI and the SUPI.
  • Step 4 The NEF 79 sends the Nudm_ParameterProvision_Create message to the UDM 75 including at least one of the SUPI, GPSI, List of TMGI, List of PLMNs, Ambient IoT profile and Report to server address.
  • Step 5 Upon reception of the Nudm_ParameterProvision_Create message from the NEF 79, the UDM 75 stores at least one of the GPSI and received data (e.g. the List of TMGI, List of PLMNs, Ambient IoT profile and Report to server address) to the subscription data for the received SUPI.
  • the GPSI and received data e.g. the List of TMGI, List of PLMNs, Ambient IoT profile and Report to server address
  • the UDM 75 may know that the received SUPI is related to the received data.
  • the UDM 75 sends the Nudm_ParameterProvision_Response message to the NEF 79 including List of TMGI.
  • the List of TMGI is a new TMGI assigned by the UDM 75.
  • the list of TMGI may include at least one of the new TMGI with an original TMGI (e.g. old TMGI).
  • the list of TMGI may include at least one of the new TMGI for the SUPI and an original TMGI (e.g. old TMGI) for the SUPI.
  • the UDM 75 may include the List of TMGI in the Nudm_ParameterProvision_Response message in a case where the new TMGI is assigned or created.
  • Step 7 Upon reception of the Nudm_ParameterProvision_Response from the UDM 75, the NEF 79 sends the Nnef_ParameterProvision_Response message to the AF 201 including the List of TMGI.
  • the list of TMGI may include at least one of the new TMGI with original TMGI. If the AF 201 receives the List of TMGI, the AF 201 may update the TMGI for the Ambient IoT device.
  • the NEF 79 may include Ambient IoT related data for multiple users (e.g. multiple SUPIs) in one Nudm_ParameterProvision_Create message in a case where all SUPIs in the message belong to the same UDM 75.
  • the AF 201 may send the List of TMGI for each PLMN or GPSI.
  • the UDM 75 may store the List of TMGI for each PLMN or GPSI. In one example, at least one GPSI may be assigned for each PLMN.
  • the UDM 75 may send the List of TMGI for per PLMN basis (e.g. via the NEF 79 to the AF 201), and the AF 201 may store the List of TMGI per PLMN basis.
  • the Network Function and AF 201 may use the GPSI of the PLMN where the UE 3 is currently registered.
  • the relation between the UE 3's GPSI and SUPI and the related List of TMGI may be pre-configured in the UDM 75.
  • the NEF 79 may use the Nudm_SDM_Get request message to retrieve the subscription information (e.g. SUPI(s)) from the UDM 75 and the related List of TMGI(s) using the GPSI parameter (e.g. the GPSI) as provided by the AF 201.
  • the UDM 75 may retrieve the SUPI and the TMGI list (e.g. the List of TMGI) for each GPSI and returns them in the Nudm_SDM_Get response message to the NEF 79.
  • Fig. 4 includes an example of the Registration procedure of the Ambient IoT device as represented as the UE 3.
  • This Registration procedure takes place by the UE 3 at any time if the UE 3 is able to communicate with 3GPP system.
  • the UE 3 has harvested enough energy over the radio interface specific to the ambient IoT device communication.
  • the enough energy for the Ambient IoT device e.g. the UE 3) to perform the procedure in Fig. 4 (or procedure(s) in Figure(s) of this disclosure) may be provided through the harvesting of radio waves, light, motion, heat, or any other power source that could be seen suitable.
  • the UE 3 has enough energy to perform the registration procedure.
  • the UE 3 has been fed or is being fed an energy by the mechanism as disclosed by the Second Aspect.
  • ⁇ User ID (e.g., the User ID may be expressed as User Identity) may be a 5G-GUTI, SUCI or SUPI.
  • ⁇ Ambient IoT device type The Ambient IoT device type indicates to the AMF 70 that the UE 3 is Ambient IoT device, e.g. the UE 3 supports communication with ambient IoT devices. The Ambient IoT device type may indicate that the UE 3 supports the Ambient IoT, the Ambient IoT communication or the Ambient IoT service.
  • the AMF 70 refers this parameter as the UE 3 may not be capable to send a periodic registration procedure or a mobility registration procedure in a case where the UE 3 does not have enough energy in the UE 3 or energy is not fed to the UE 3. Thus, the AMF 70 keeps the UE context of the UE 3 long enough to provide the Ambient IoT service. For example, the AMF 70 may maintain the UE context for one year even no contact from the UE 3 for one year.
  • ⁇ GPSI The GPSI is an acronym of Generic Public Subscription Identifier. This GPSI is an identity of the Ambient IoT device (e.g. the UE 3).
  • ⁇ List of active TMGI List of active TMGI indicates active TMGI(s) in the UE 3.
  • the list of active TMGI may be known by the AF 201 whether the UE 3 is able to communicate or not with a TMGI in the list. If the TMGI is listed in the list of TMGI, the TMGI may be used to trigger the UE 3 for the Ambient IoT communication.
  • the List of active TMGI may indicate TMGI(s) that is related to the UE 3.
  • the List of active TMGI may indicate TMGI(s) that is assigned to the UE 3.
  • the AF 201 may refer the List of active TMGI to know whether the UE 3 is able to communicate or not by using the TMGI(s) in the List of active TMGI.
  • the AF 201 may communicate with the UE 3 by using the TMGI(s) in the List of active TMGI.
  • the UE 3 may be identified by the TMGI(s) in the List of active TMGI.
  • the above-mentioned parameter(s) in step 1 may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 2 Upon reception of the Registration Request message in step 1, the AMF 70 sends the Nudm_UECM_Registration Request message to the UDM 75 including at least one of the User ID, GPSI and List of active TMGI. Refer to Step 1 for parameter details.
  • the above-mentioned parameter(s) in step 2 may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 3 Upon reception of the Nudm_UECM_Registration Request message in step 2, the UDM 75 sends the Nudm_UECM_Registration Response message to the AMF 70.
  • Step 4 After the completion of the Nudm_UECM_Registration service in steps 2 and 3, the AMF 70 sends the Nudm_SDM_Get Request message to the UDM 75 including at least one of the User ID, GPSI and List of active TMGI. Refer to Step 1 for parameter details.
  • the above-mentioned parameter(s) in step 4 may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • the UDM 75 finds Subscriber data for the UE 3 and sends the Nudm_SDM_Get Response message to the AMF 70 including the Subscriber data for the UE 3.
  • the Subscriber data includes at least one of the GPSI, List of TMGI, List of PLMN, Ambient IoT profile and the Report to server address.
  • the UDM 75 may store the AMF 70 as an Ambient IoT supporting AMF and received parameters in step 4 by associating with the AMF 70.
  • the above-mentioned parameter(s) in step 5 may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • the UDM 75 may send the Nudm_EventExposure_Notify message to the NEF 79 including at least one of the SUPI and List of active TMGI if the NEF 79 has subscribed to the Nudm_EventExposure service. Refer to step 1 for parameter details.
  • the above-mentioned parameter(s) in step 6 may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • the NEF 79 may send the Nnef_EventExposure_Notify message to the AF 201 including at least one of the SUPI, GPSI and List of active TMGI if the AF 201 has subscribed to the Nnef_EventExposure service.
  • the NEF 79 may find the corresponding GPSI to the received SUPI and may send the GPSI to the AF 201.
  • the above-mentioned parameter(s) in step 7 may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 8 The AMF 70 sends the Registration Accept message to the UE 3 including at least one of 5G-GUTI, the GPSI, the List of TMGI, List of PLMN, the Ambient IoT profile and the Report to server address.
  • the 5G-GUTI is a temporary user identifier for the UE 3. Refer to step 2 in Second scenario in First example of the First Aspect for parameter details.
  • the above-mentioned parameter(s) in step 8 may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 9 Upon reception of the Registration Accept message, the UE 3 stores the received data in the Registration Accept message in step 8. The UE 3 may store the received data in the Registration Accept message in step 8 into non-volatile memory in the UE 3.
  • Step 10 The UE 3 sends the Registration Complete message to the AMF 70.
  • the UE 3 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1, 8, 9 and 10.
  • the UE 3 may perform at least one of steps 1, 8, 9 and 10 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the AMF 70 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1 to 5, 8 and 10.
  • the AMF 70 may perform at least one of steps 1 to 5, 8 and 10 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the UDM 75 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 2 to 6.
  • the UDM 75 may perform at least one of steps 2 to 6 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the NEF 79 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 6 and 7.
  • the NEF 79 may perform at least one of steps 6 and 7 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the AF 201 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least step 7.
  • the AF 201 may perform at least step 7 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the UE 3 may be configured with list of TMGI for each PLMN or GPSI.
  • the UE 3 may only send the list of TMGI corresponding to the current PLMN.
  • the PLMN may broadcast in an existing MIB or SIB or in a new SIB a TMGI (or more than one TMGIs) and an indicator whether the UE 3 can get service for the TMGI (or an indicator for each of those TMGIs).
  • the UE 3 may camp on a cell of the PLMN, and the UE 3 may initiate the registration procedure to the PLMN only when the UE 3 is configured with at least one TMGI for which the service is allowed in the cell of the PLMN.
  • the UDM 75 may compare the received TMGI or GPSI from the UE 3 with the stored TMGI or GPSI. If the two don't match, then the UDM 75 may send the stored TMGI, GPSI(s) and other parameter to the AMF 70 for indicating the AMF 70 to configure the UE 3 using an existing NAS procedure.
  • the UDM 75 may also notify, to the AF 201 via the NEF 79, that the stored data (e.g. TMGI, GPSI etc) are not up to date.
  • the AF 201 may also update the UE database using O&M procedure i.e. without signalling in the network.
  • the AMF 70 may include, in the registration accept message, an information element such as TMGI service status indicating whether the service is allowed for the TMGI or not.
  • an information element such as TMGI service status indicating whether the service is allowed for the TMGI or not.
  • the UE 3 may store the information element.
  • the UE 3 may check whether the service is allowed for the TMGI. If the service is allowed then the UE 3 may send the AS or NAS signalling or user data otherwise the UE 3 may not initiate any NAS or AS procedure, except the deregistration procedure.
  • Variant 4 of Third scenario in First example of the First Aspect In another example, after the initial registration of the ambient IoT devices with its GPSI as per Fig. 4 (e.g. after the Registration procedure in Fig. 4 completes), it is possible that each ambient IoT device is assigned by a 3GPP identity (e.g. SUPI) and this 3GPP identity is provided back to the UE 3 by the Registration Accept message in step 8, and the UE 3 may create and maintain the relation between the ambient IoT device's GPSI and 3GPP identity.
  • 3GPP identity e.g. SUPI
  • the UE 3 may convert the ambient IoT device's GPSI to its 3GPP identity and the UE 3 may use the ambient IoT device's 3GPP identity in the communication with the network.
  • the 'Ambient IoT' parameter may be indicated by the UE 3 as a parameter of the RRC Connection Setup Complete message from the UE 3 to the RAN and again be used by the RAN node for the purpose of selecting AMF which is ambient IoT communication capable.
  • Fig. 5 includes an example of the Registration procedure of the Ambient IoT device as represented as the UE 3 with the Ambient IoT data communication.
  • Step 0. The UE 3 is registered to the AMF 70 and a dedicated PDU Session for the Ambient IoT service has been established with the SMF 71 and the UPF 72. For example, in step 0, the process(es) in Fig. 4 completes and the PDU Session has been established.
  • the AF 201 may trigger the Radio Cell 502 for Ambient IoT communication with list of TMGI.
  • the AF 201 may trigger the Ambient IoT communication (e.g. the automated warehouse inventory scenario) by using the list of TMGI.
  • the AF 201 may trigger the Ambient IoT communication for the UE 3 which is identified by TMGI(s) in the list of TMGI.
  • Steps 1 to 8 in the the Ambient IoT Service Activation procedure in Fig. 8 may take place.
  • Step. 1-2 The Radio Cell 502 broadcasts energy over the air.
  • the energy broadcasting may be trigged by the activation request in Step 1-1.
  • the energy broadcasting may be trigged by the process(es) in Step 1-1.
  • the expression "The Radio Cell 502 broadcasts" may mean "the RAN 501 broadcasts.".
  • the RAN 501 may receive the service trigger from the AF 201 directly or indirectly (e.g. via other network node(s)). Then the RAN 501 may control the Radio Cell 502 to broadcast the energy (e.g. the RAN 501 may broadcast the energy via the Radio Cell 502).
  • Step 1-3 The UE 3 has had enough energy to perform the registration procedure. For example, if the UE 3 has a battery, the battery in the UE 3 have been charged by harvesting energy by receiving the broadcasted energy by Step 1-2. For example, if the UE 3 does not have a battery, the UE 3 performs the Registration procedure using energy being harvested by receiving the broadcasted energy by Step 1-2.
  • the Radio Cell 502 broadcasts system information with a list of TMGI indicating that the UE 3 is requested to perform the Ambient IoT communication immediately if the UE 3 has an active TMGI in the list of TMGI.
  • the UE 3 initiates the Ambient IoT communication as far as the UE 3 has enough energy for performing the Registration procedure regardless of receiving the system information in Step 2.
  • the above-mentioned parameter(s) in step 2 may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • the RAN 501 may control the Radio Cell 502 to broadcast the system information including the list of TMGI.
  • the RAN 501 may broadcast the system information via the Radio Cell 502.
  • the system information may be expressed as a service request (e.g. a service request for the Ambient IoT, for the Ambient IoT communication or for the Ambient IoT service).
  • steps 1-2 and step 2 may be combined.
  • the energy feeding may be performed by the signal in step 2.
  • the energy feeding may be performed by the system information or the service request.
  • Step 3 The UE 3 sends the RRC Setup Request message to the RAN 501.
  • the UE 3 may send the RRC Setup Request message to the RAN 501.
  • the UE 3 may send the RRC Setup Request message to the RAN 501.
  • Step 4 Upon the reception of the RRC Setup Request message in Step 3, the RAN 501 sends the RRC Setup message to the UE 3 including List of TMGI for MO requested.
  • the List of TMGI for MO requested indicates to the UE 3 that the Ambient IoT communication associated with the TMGI (e.g. the broadcasted TMGI) is requested.
  • the RAN 501 may include the List of TMGI for MO requested parameter only if the Radio Cell 502 does not broadcast the system information with the list of TMGI in step 2. For example, the RAN 501 may know that which the list of TMGI is broadcasted by which Radio Cell(s).
  • the above-mentioned parameter(s) in step 4 may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • the UE 3 sends the RRC Message number 3 message to the RAN 501 including at least one of Ambient IoT device type, TMGI (e.g. the TMGI included in the list of TMGI in step 2) and Dedicated NAS.
  • the RRC Message number 3 message may be called as Message 5 (Msg5) in RRC connection establishment procedure.
  • the RRC Message number 3 message or the Msg5 may be an RRC Setup Complete message in this example.
  • the Ambient IoT device type indicates to the RAN 501 that the UE 3 is Ambient IoT device or belongs to a category mapped to Ambient IoT device.
  • the RAN 501 refers this Ambient IoT device type for Radio Resource Management to the UE 3. In a case where the AMF 70 is not yet associated with the UE 3, the Ambient IoT device type and TMGI are used for AMF selection.
  • the Dedicated NAS includes the Registration Request message.
  • the Registration Request message in step 5 includes the MO-data.
  • the MO-data may be embedded in the CIoT small data container or CIoT user data container.
  • the MO-data may be an Ambient IoT related data from the UE 3 for the Ambient IoT communication.
  • the MO-data may be data for the Ambient IoT.
  • the MO-data may be data for the Ambient IoT communication or for the Ambient IoT service.
  • the Ambient IoT application in the UE 3 provides the MO-data.
  • the above-mentioned parameter(s) in step 5 may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 6 Upon reception of the RRC Message number 3 message from the UE 3, the RAN 501 sends the Initial UE message to the AMF 70 including at least one of the Ambient IoT device type and NAS-PDU.
  • the NAS-PDU includes the Registration Request message that is received in the Dedicated NAS in Step 5.
  • the MO-data in the Registration Request message is security protected using the NAS security context.
  • the AMF 70 decodes the protected message using the NAS security context.
  • the above-mentioned parameter(s) in step 6 may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 7 Steps 2 to 7 in Fig. 4 take place.
  • Step 8 The AMF 70 sends the Nsmf_PDUSession_SendMOData message to the SMF 71 including the MO-data.
  • Step 9 The SMF 71 forwards the received MO-data to the UPF 72.
  • the UPF 72 communicates with the AF 201 or any server in data network for the Ambient IoT communication.
  • the UPF 72 sends the MO-data to the AF 201.
  • the AF 201 sends a MT-data to the UE 3.
  • the AF 201 sends, to the UPF 72, the MT-data for the UE 3.
  • the MT-data may be an Ambient IoT related data to the UE 3 for the Ambient IoT communication.
  • the UPF 72 may forward the MT-data if the UPF 72 receives the MT-data during the Ambient IoT communication. For example, the UPF 72 receives the MT-data as a reply to the MO-data. The UPF 72 may forward the MT-data to the SMF 71.
  • Step 12 The SMF 71 sends the Namf_Communication_N1N2MessageTransfer message to the AMF 70.
  • the Namf_Communication_N1N2MessageTransfer message may include the MT-data.
  • Step 13 The AMF 70 sends the Registration Accept message to the UE 3.
  • the Registration Accept message in step 13 includes the MT-data.
  • the MT-data may be an Ambient IoT related data to the UE 3 for the Ambient IoT communication.
  • the UE 3 If the UE 3 receives the MT-data in the Registration Accept message, the UE 3 sends the received MT-data to the Ambient IoT application in the UE 3.
  • the above-mentioned parameter(s) in step 13 may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 14 The UE 3 sends the Registration Complete message to the AMF 70.
  • the UE 3 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 0, 1-2, 1-3, 2 to 5, 13 and 14.
  • the UE 3 may perform at least one of steps 0, 1-2, 1-3, 2 to 5, 13 and 14 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the Radio Cell 502 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1-1, 1-2 and 2.
  • the Radio Cell 502 may perform at least one of steps 1-1, 1-2 and 2 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the RAN 501 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 3 to 6.
  • the RAN 501 may perform at least one of steps 3 to 6 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the AMF 70 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 6 to 8, 12 and 13.
  • the AMF 70 may perform at least one of steps 6 to 8, 12 and 13 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the SMF 71 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 8, 9, 11 and 12.
  • the SMF 71 may perform at least one of steps 8, 9, 11 and 12 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the UDM 75 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least step 7.
  • the UDM 75 may perform at least step 7 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the UPF 72 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 9 to 11.
  • the AF 201 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least step 10.
  • the AF 201 may perform at least step 10 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the UE 3 sends user data (e.g. the MO-data) without activating the PDU session.
  • the user data is encapsulated in a packet and SUPI or GPSI is added as an Identifier of the user.
  • the SUPI or GPSI corresponding to the user data is added in the user packet.
  • the UE 3 encrypts the user data using the NAS security parameters (e.g. at least one of Kausf, Kasme, CK and IK) created during authentication procedure.
  • the AMF 70 decrypts the user packet and sends it to the NEF 79 or UDM 75.
  • the NEF 79 or UDM 75 identifies the user packet using the GPSI, SUPI or TMGI and sends the user packet as it is to the AF 201.
  • the UDM 75 or NEF 79 sends GPSI corresponding to the SUPI.
  • the NEF 79 or UDM 75 also includes PLMN ID of the registered PLMN in the user packet.
  • the AF 201 receives the user packet containing GPSI and TMGI then the AF 201 identifies the user of the data packets.
  • the step 1-1 in Fig. 5 may be transmitted to or terminated at the RAN 501. Then, the RAN 501 may trigger the Radio Cell 502 to perform the step 1-2.
  • This example may be applicable to a case where the Radio Cell 502 is or represents the RU, the repeater, or the RSU. However, this is not limited to such the case only.
  • the Fig. 6 includes an example of the Service management model for Ambient IoT device.
  • the Service management model for Ambient IoT device is characterized as the following features.
  • the Service corresponds to the Ambient IoT service, for example, a gate-in inventory, Inventory at a warehouse, a gate-out inventory as described in NPL2.
  • the TMGI represents a group subject for the Service.
  • TMGI#1 represents all goods produced by company #1
  • TMGI#2 represents all goods produced by company #2.
  • the gate-in inventory for all goods produced by company #1 can be executed.
  • TMGI may be called as Multicast MBS group.
  • the Service order is an order from the AF 201 what kind of Service that AF 201 requests to the 5GS.
  • the Service order may include at least one of the following parameters: Service order:
  • the Service order indicates a service that the AF 201 requests to the 5GS.
  • the Service order may include at least one of the following Service orders:
  • One time report One time report is used by the AF 201 when the AF 201 needs IoT data from the Ambient IoT devices.
  • the Ambient IoT devices report IoT data when the Ambient IoT device receives this Service order.
  • Monitor Monitor is used by the AF 201 when the AF 201 needs IoT data or notification from the Ambient IoT devices for a specified condition with the Validity time.
  • the Validity time is associated in the Service order.
  • the Ambient IoT devices report IoT data during a period if a condition matches with the Validity time.
  • the Monitoring reporting or notification may only be applicable for when the ambient IoT device is in locations defined by the AF 201 via the location or service are parameter within the Service order.
  • Validity time This Validity time may be associated with the Service order.
  • the Validity time is referred as a time duration which the Service order is effective.
  • the Validity time may indicate a time duration which the above-mentioned "Service order" is applicable.
  • the Validity time may take at least one of the following expressions: Periodic service time indicator: it identifies whether the service time (e.g., duration or interval or time) when the above-mentioned "Service order" is updated periodically or not, for example, only on demand.
  • the Periodic service time indicator may indicate whether the service time is periodically or not.
  • Service duration time Duration interval time of Periodic service.
  • the Service duration time may indicate duration or interval or time when the above-mentioned "Service order" or a service indicated by the "Service order" is provided or when the service time is updated. This information may be used together with Periodic service time indicator.
  • Periodic time Interval Time of Periodic service. This information may be used together with Periodic service time indicator.
  • the Periodic time may indicate timing when the service time is updated or may indicate periodicity of the above-mentioned "Service order".
  • Scheduled service time Time zone and Day of the week when the service (e.g., the above-mentioned "Service order") is available.
  • Action The action indicates an action that the AF 201 requests to the 5GS. The action may not be used for the Service order set to "One time report".
  • the action may include at least one of the following actions: Start Service: It may indicate to start the service. Stop Service: It may indicate to stop the service.
  • the AF 201 may request the Ambient IoT service with Service, TMGI and a generic location information.
  • the 5GC converts the generic location information to the TAI list and uses the TMGI for page the group of Ambient IoT device(s) in all cell(s) that belong to the TAI list.
  • the 5GC manages the mapping between the Service and corresponding TAI(s).
  • a gate-in inventory for the Warehouse #A In this case, only one or a few cells that covers the gate of the Warehouse #A are subject for the Service.
  • the AF 201 may request the Ambient IoT service with Service and TMGI.
  • the 5GC converts the Service to specific TAI(s) and uses the TMGI for page the group of Ambient IoT device(s) in all cell(s) that belong to the TAI list.
  • TMGI may be called as Multicast MBS group.
  • Fig. 7 includes an example of the Ambient IoT configuration notification procedure. This procedure is used when the Radio Cell 502 or AMF 70 is configured or updated to support the Ambient IoT service.
  • the RAN configuration update includes an update in Radio Cell 502 and/or an update in RAN 501.
  • the 5GC update includes an update in AMF 70, SMF 71 and/or UPF 72.
  • the expression “A and/or B” may mean “at least one of A and B”.
  • Either RAN configuration update procedure or 5GC configuration update procedure may take place.
  • the Radio Cell 502 is configured or updated to support the Ambient IoT service.
  • the RAN 501 is configured or updated to support the Ambient IoT service.
  • Step 1-A2 The RAN 501 sends the RAN Configuration Update message to the AMF 70 including at least one of Ambient IoT support, Supported Ambient IoT profiles, Supported Service IDs, and Supported TMGIs.
  • the Ambient IoT support indicates that the RAN 501 or the Radio Cell 502 supports the Ambient IoT service and the Ambient IoT service-related procedures as disclosed by this disclosure.
  • the Ambient IoT support indicates that the RAN 501 or the Radio Cell 502 supports the Ambient IoT service and the Ambient IoT service-related procedures as disclosed by this disclosure.
  • more than one type of Ambient IoT devices e.g. in 3GPP specifications
  • more than one functions for Ambient IoT is defined, such indication may be sent or included per Ambient IoT device type or per Ambient IoT function.
  • the Ambient IoT service-related procedures may be procedure(s) disclosed in at least one Figures of this disclosure.
  • the Supported Ambient IoT profiles indicates that Supported Ambient IoT profiles that are supported by the RAN 501.
  • the Supported Ambient IoT profiles may be configured as a list of Supported Ambient IoT profiles.
  • the Supported Ambient IoT profiles may include at least one data in the Ambient IoT profile described in step 2 of Fig. 3.
  • the Supported Ambient IoT profiles may include the Ambient IoT profile regarding the RAN 501.
  • the Ambient IoT profile regarding the RAN 501 may include at least one of data in the Ambient IoT profile described in step 2 of Fig. 3.
  • the Supported Ambient IoT profiles may include the Ambient IoT profile(s) for the UE(s) 3 that the RAN 501 supports.
  • ⁇ Supported Service IDs The Supported Service IDs indicates that Service IDs that are supported by the RAN 501.
  • the Supported Service IDs may be configured as a list of Supported Service IDs.
  • the Service ID may be an identity for the Ambient IoT service.
  • the Ambient IoT service may be identified by the Service ID.
  • the Supported Service IDs may indicate Service ID(s) for the Service(s) (e.g. the Ambient IoT service(s)) that is supported by the RAN 501.
  • the Supported TMGIs indicates that TMGIs that are supported by the RAN 501.
  • the TMGIs may be configured as a list of TMGIs.
  • the TMGI may be called as Multicast MBS group.
  • the Supported TMGIs may indicate TMGI(s) indicating the group of the Ambident IoT device(s) (e.g. UE(s) 3) that is supported by the RAN 501.
  • the Supported TMGIs may indicate TMGI(s) regarding the group of the Ambident IoT device(s) (e.g. UE(s) 3) that is supported by the RAN 501.
  • the above-mentioned parameter(s) in step 1-A2 may be expressed as parameter(s) or data or information for the Ambient IoT or for the Ambient IoT communication or for the Ambient IoT service.
  • the above-mentioned parameter(s) in step 1-A2 may be expressed as parameter(s) or data or information related to the Ambient IoT or related to the Ambient IoT communication or related to the Ambient IoT service.
  • Step 1-A3 Upon reception of the RAN Configuration Update message in step 1-A2, the AMF 70 sends the RAN Configuration Update Acknowledge to the RAN 501 including at least one of Ambient IoT support, Supported Service IDs and Supported TMGIs.
  • ⁇ Ambient IoT support indicates that the AMF 70 and one or some associated SMF 71 and UPF 72 support the Ambient IoT service and the Ambient IoT service-related procedures as disclosed by this disclosure.
  • ⁇ Supported Service IDs The Supported Service IDs indicates that Service IDs that are supported by the AMF 70.
  • the Supported Service IDs may be configured as a list of Supported Service IDs.
  • the Supported Service IDs may indicate Service ID(s) for the Service(s) (e.g. the Ambient IoT service(s)) that is supported by the AMF 70.
  • the Supported TMGIs indicates that TMGIs that are supported by the AMF 70.
  • the TMGIs may be configured as a list of TMGIs.
  • the TMGI may be called as Multicast MBS group.
  • the Supported TMGIs may indicate TMGI(s) indicating the group of the Ambident IoT device(s) (e.g. UE(s) 3) that is supported by the AMF 70.
  • the Supported TMGIs may indicate TMGI(s) regarding the group of the Ambident IoT device(s) (e.g. UE(s) 3) that is supported by the AMF 70.
  • the above-mentioned parameter(s) in step 1-A3 may be expressed as parameter(s) or data or information for the Ambient IoT or for the Ambient IoT communication or for the Ambient IoT service.
  • the above-mentioned parameter(s) in step 1-A3 may be expressed as parameter(s) or data or information related to the Ambient IoT or related to the Ambient IoT communication or related to the Ambient IoT service.
  • the AMF 70 which is associated with the SMF 71 or UPF 72 is configured or updated to support the Ambient IoT service.
  • Step 1-B2 The AMF 70 sends the AMF Configuration Update message to the RAN 501 including at least one of Ambient IoT support, Supported Service IDs and Supported TMGIs.
  • ⁇ Ambient IoT support Refer to step 1-A3.
  • ⁇ Supported Service IDs Refer to step 1-A3.
  • ⁇ Supported TMGIs Refer to step 1-A3.
  • the above-mentioned parameter(s) in step 1-B2 may be expressed as parameter(s) or data or information for the Ambient IoT or for the Ambient IoT communication or for the Ambient IoT service.
  • the above-mentioned parameter(s) in step 1-B2 may be expressed as parameter(s) or data or information related to the Ambient IoT or related to the Ambient IoT communication or related to the Ambient IoT service.
  • Step 1-B3 Upon reception of the AMF Configuration Update message in step 1-B2, the RAN 501 sends the AMF Configuration Update Acknowledge to the AMF 70 including at least one of Ambient IoT support, Supported Ambient IoT profiles, Supported Service IDs, and Supported TMGIs.
  • ⁇ Ambient IoT support Refer to step 1-A2.
  • ⁇ Supported Ambient IoT profiles Refer to step 1-A2.
  • the above-mentioned parameter(s) in step 1-B3 may be expressed as parameter(s) or data or information for the Ambient IoT or for the Ambient IoT communication or for the Ambient IoT service.
  • the above-mentioned parameter(s) in step 1-B3 may be expressed as parameter(s) or data or information related to the Ambient IoT or related to the Ambient IoT communication or related to the Ambient IoT service.
  • the AMF 70 sends the Nudm_SDM_ModifySubscription message to the UDM 75 including at least one of Ambient IoT support, Supported Ambient IoT profiles, Supported Service IDs and Supported TMGIs.
  • the Ambient IoT support indicates that the AMF 70 and associated RAN 501 support the Ambient IoT service and the Ambient IoT service-related procedures as disclosed by this disclosure.
  • the Ambient IoT support in step 2 may include the Ambient IoT support in step 1-A2 or step 1-B3.
  • the Ambient IoT support in step 2 may include the Ambient IoT support in step 1-A3 or step 1-B2.
  • ⁇ Supported Ambient IoT profiles The Supported Ambient IoT profiles indicates that Supported Ambient IoT profiles that are supported by the AMF 70 and associated RAN 501.
  • the Supported Ambient IoT profiles may be configured as a list of Supported Ambient IoT profiles.
  • the Supported Ambient IoT profiles in step 2 may include the Supported Ambient IoT profiles in step 1-A2 or step 1-B3.
  • the Supported Ambient IoT profiles in step 2 may include the Supported Ambient IoT profiles that are supported by the AMF 70.
  • the Supported Ambient IoT profiles may include at least one data in the Ambient IoT profile described in step 2 of Fig. 3.
  • the Supported Ambient IoT profiles may include the Ambient IoT profile regarding the AMF 70 and the RAN 501.
  • the Ambient IoT profile regarding the AMF 70 and the RAN 501 may include at least one of data in the Ambient IoT profile described in step 2 of Fig. 3.
  • the Supported Ambient IoT profiles may include the Ambient IoT profile(s) for the UE(s) 3 that the AMF 70 supports.
  • the Supported Ambient IoT profiles may include the Ambient IoT profile(s) for the UE(s) 3 that the RAN 501 supports.
  • ⁇ Supported Service IDs The Supported Service IDs indicates that Service IDs that are supported by the AMF 70 and associated RAN 501.
  • the Supported Service IDs may be configured as a list of Supported Service IDs.
  • the Supported Service IDs in step 2 may include the Supported Service IDs in steps 1-A2 and step 1-A3.
  • the Supported Service IDs in step 2 may include the Supported Service IDs in steps 1-B2 and step 1-B3.
  • ⁇ Supported TMGIs The Supported TMGIs indicates that TMGIs that are supported by the AMF 70 and associated RAN 501.
  • the TMGIs may be configured as a list of TMGIs.
  • the TMGI may be called as Multicast MBS group.
  • the Supported TMGIs in step 2 may include the Supported TMGIs in steps 1-A2 and step 1-A3.
  • the Supported TMGIs in step 2 may include the Supported TMGIs in steps 1-B2 and step 1-B3.
  • the above-mentioned parameter(s) in step 2 may be expressed as parameter(s) or data or information for the Ambient IoT or for the Ambient IoT communication or for the Ambient IoT service.
  • the above-mentioned parameter(s) in step 2 may be expressed as parameter(s) or data or information related to the Ambient IoT or related to the Ambient IoT communication or related to the Ambient IoT service.
  • Step 3 The UDM 75 stores the AMF 70 as an Ambient IoT supporting AMF and received parameters by associating with the AMF 70.
  • the UDM 75 may send the Nnef_Config_Update message to the NEF 79 including at least one of Ambient IoT support, Supported Ambient IoT profiles, Supported Service IDs and Supported TMGIs.
  • ⁇ Ambient IoT support indicates that the UDM 75 supports the Ambient IoT service and the Ambient IoT service-related procedures as disclosed by this disclosure.
  • ⁇ Supported Ambient IoT profiles The Supported Ambient IoT profiles indicates that Supported Ambient IoT profiles that are supported by the UDM 75.
  • the Supported Ambient IoT profiles may be configured as a list of Supported Ambient IoT profiles.
  • the Supported Ambient IoT profiles may include at least one data in the Ambient IoT profile described in step 2 of Fig. 3.
  • the Supported Ambient IoT profiles may include the Ambient IoT profile regarding the UDM 75.
  • the Ambient IoT profile regarding the UDM 75 may include at least one of data in the Ambient IoT profile described in step 2 of Fig. 3.
  • the Supported Ambient IoT profiles may include the Ambient IoT profile(s) for the UE(s) 3 that the UDM 75 supports.
  • ⁇ Supported Service IDs The Supported Service IDs indicates that Service IDs that are supported by the UDM 75, The Supported Service IDs may be configured as a list of Supported Service IDs.
  • the Supported Service IDs may indicate Service ID(s) for the Service(s) (e.g. the Ambient IoT service(s)) that is supported by the UDM 75.
  • the Supported TMGIs indicates that TMGIs that are supported by the UDM 75.
  • the TMGIs may be configured as a list of TMGIs.
  • the TMGI may be called as Multicast MBS group.
  • the Supported TMGIs may indicate TMGI(s) indicating the group of the Ambident IoT device(s) (e.g. UE(s) 3) that is supported by the UDM 75.
  • the Supported TMGIs may indicate TMGI(s) regarding the group of the Ambident IoT device(s) (e.g. UE(s) 3) that is supported by the UDM 75.
  • the above-mentioned parameter(s) in step 4 may be expressed as parameter(s) or data or information for the Ambient IoT or for the Ambient IoT communication or for the Ambient IoT service.
  • the above-mentioned parameter(s) in step 4 may be expressed as parameter(s) or data or information related to the Ambient IoT or related to the Ambient IoT communication or related to the Ambient IoT service.
  • the NEF 79 stores UDM 75 as an Ambient IoT supporting UDM and received parameters by associating with the UDM 75.
  • Step 6 The NEF 79 sends the Nnef_Config_Update Response message to the UDM 75.
  • Step 7 The UDM 75 sends the Nudm_SDM_ModifySubscription Response message to the AMF 70.
  • the RAN 501 may perform a Radio configuration notification procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1-A1, 1-A2, 1-A3, 1-B2 and 1-B3.
  • the RAN 501 may perform at least one of steps 1-A1, 1-A2, 1-A3, 1-B2 and 1-B3 for the Radio configuration notification procedure.
  • the AMF 70 may perform a Radio configuration notification procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1-A2, 1-A3, 1-B1, 1-B2, 1-B3, 2 and 7.
  • the AMF 70 may perform at least one of steps 1-A2, 1-A3, 1-B1, 1-B2, 1-B3, 2 and 7 for the Radio configuration notification procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the UDM 75 may perform a Radio configuration notification procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one steps 2 to 4, 6 and 7.
  • the UDM 75 may perform at least one steps 2 to 4, 6 and 7 for the Radio configuration notification procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the NEF 79 may perform a Radio configuration notification procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 4 to 6.
  • the NEF 79 may perform at least one of steps 4 to 6 for the Radio configuration notification procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the message in step 1-A2 may be a NG Setup Request message.
  • the message in step 1-A3 may be a NG Setup Response message.
  • the message in steps 2 and 7 may be another existing UDM service message or new UDM service message.
  • the message in steps 4 and 6 may be another existing NEF service message or new NEF service message.
  • the step 1-A1 may be optionally performed (or omitted) depending on the type of Radio Cell 502.
  • the Radio Cell 502 may be the RU, the repeater or the RSU.
  • the RAN 501 may perform the necessary configuration update even without sending a message to the Radio Cell 502.
  • Fig. 8 includes an example of the Ambient IoT Service Activation procedure.
  • Step 0. The UE 3 is registered to the AMF 70 and a dedicated PDU Session for the Ambient IoT service has been established with the SMF 71 and the UPF 72.
  • the step 0 may be same to step 0 in Fig. 5.
  • the AF 201 decides to start the Ambient IoT service activation.
  • the AF 201 may decide to start the Ambient IoT service for example, a gate-in inventory, Inventory at a warehouse, a gate-out inventory as described in NPL 2.
  • Step 2 The AF 201 sends the Nnef_IoT_Service_Request message to the NEF 79 including at least one of TMGI, Service, Service order, Location and Ambient IoT profiles.
  • the Ambient IoT profiles may be included by the AF 201 if the Ambient IoT profile corresponds to the Service which has been updated lately.
  • TMGI Temporary Mobile Group Identity
  • the TMGI is used to trigger the Ambient IoT device to start the Ambient IoT communication.
  • the TMGI represents a group of Ambient IoT devices. Each Ambient IoT device may be associated with one TMGI or multiple TMGIs.
  • the TMGI may be called as Multicast MBS group.
  • ⁇ Service The Service corresponds to the Ambient IoT service. Refer to Fifth scenario in First example of the First Aspect.
  • ⁇ Service order Refer to Fifth scenario in First example of the First Aspect.
  • ⁇ Location The location indicates the location where the AF 201 requests to apply the Service. Location can be a geographical location.
  • Location can be a list of Tracking Area Identity (TAI), a list of NR Cell Global Identity (NCGI) as defined in NPL 9, a list of NR Cell Identity (NCI) as defined in NPL 9, a list of E-UTRAN Cell Global Identifier (ECGI) as defined in NPL 9, a list of Global Cable Identifier (GCI) as defined in NPL 9, a general City name, zip-code, formed with GPS location or a location expressed with civic and geospatial location formats as defined in NPL 10.
  • TAI Tracking Area Identity
  • NGI NR Cell Global Identity
  • NCI NR Cell Identity
  • ECGI E-UTRAN Cell Global Identifier
  • GCI Global Cable Identifier
  • ⁇ Ambient IoT profiles Refer to Second scenario in First example of the First Aspect for the Ambient IoT profile.
  • Ambient IoT profiles may be a list of Ambient IoT profile. Multiple Ambient IoT profiles are configured by the AF 201 when the AF 201 recognizes that Ambi
  • the above-mentioned parameter(s) in step 2 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • the parameter(s) in the message of step 2 may be related each other.
  • TMGI#1 and Service#1 are included in the message of step 2, it may mean that the service(s) (e.g. the Ambient IoT service(s)) indicated by Service#1 is requested for the group of Ambient IoT device(s) (e.g. the group of UE(s) 3) indicated by TMGI#1.
  • Step 3 Upon reception of the Nnef_IoT_Service_Request message from the AF 201 in step 2, the NEF 79 converts the received Service to a Service ID.
  • the Service ID may be a common value among operator networks or a unique value only valid in the PLMN or the NPN where the NEF 79 belongs to.
  • the NEF 79 may have information for converting the received Service to the Service ID in advance.
  • the NEF 79 may receive the information for converting the received Service to the Service ID from other network node(s).
  • Step 4 Upon the reception of the Nnef_IoT_Service_Request message from the AF 201 (or in a case where the NEF 79 converts the received Service to the Service ID), the NEF 79 sends the Nudm_SDM_Get Request message to the UDM 75 including at least one of the TMGI, Service ID, Location and Ambient IoT profiles.
  • the TMGI, Location and Ambient IoT profile in step 4 are ones received from the AF 201.
  • the Service ID in step 4 is one converted by the NEF 79 in step 3.
  • the above-mentioned parameter(s) in step 4 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 5 Upon the reception of the Nudm_SDM_Get Request message from the NEF 79, the UDM 75 performs at least one of the following actions: If the Location is received, the UDM 75 finds AMFs that covers the received Location. If the Location spans to areas where the PLMN of the UDM 75 does not cover, the UDM 75 finds VPLMNs where the PLMN has service agreement for the Ambient IoT Service represented by the received in the Service ID. In a case where the UDM 75 has been notified in advance a support of Service ID from the AMF 70 and the received Service ID corresponds to that Service ID (e.g.
  • the UDM 75 in a case where the UDM 75 has received the Service ID from the AMF 70 in advance, and the received Service ID from the AMF 70 corresponds to the received Service ID from the NEF 79 in step 4), the UDM 75 provides all notified AMF(s) 70 to the NEF 79 for the Service ID (e.g. the UDM 75 may provide, to the NEF 79, information regarding the AMF 70 which sends the Service ID to the UDM 75). If the received Ambient IoT profiles corresponding to the Service ID are different from one in the UDM 75, the UDM 75 updates the Ambient IoT profiles corresponding to the Service ID in the storage of the UDM 75.
  • the UDM 75 may store or receive from other network node(s) in advance information indicating correspondence between the Ambient IoT profiles and the Service ID.
  • the Ambient IoT profiles may be related to the Service ID.
  • the UDM 75 sends the Nudm_SDM_Get Response message to the NEF 79 including at least one of list of AMF(s), list of PLMN ID, Location and Ambient IoT profiles.
  • the Ambient IoT profiles may be provided if the NEF 79 does not provide the Ambient IoT profiles to the UDM 75 in step 4 and the UDM 75 holds the Ambient IoT profiles for the Service ID.
  • the list of AMF(s) may include AMF(s) which supports the Service ID or the Ambient IoT service indicated by the Service ID.
  • the list of AMF(s) may include AMF(s) which is found by the UDM 75.
  • the list of PLMN ID may include PLMN ID(s) of PLMN(s) which supports the Service ID or the Ambient IoT service indicated by the Service ID.
  • the above-mentioned parameter(s) in step 5 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 6 Upon reception of the Nudm_SDM_Get Response message from the UDM 75, the NEF 79 sends the Namf_Communication_NonUeN2MessageTransfer message to the AMF 70 (e.g. to the AMF 70 indicated by the list of AMF(s) in step 5) including at least one of the TMGI, Service ID, Service order, Location, Ambient IoT profiles.
  • the NEF 79 sends multiple Namf_Communication_NonUeN2MessageTransfer messages to all AMFs if the NEF 79 receives multiple AMFs from the UDM 75 in step 5.
  • the NEF 79 may send the Nnef_IoT_Service_Request message (e.g. the Nnef_IoT_Service_Request message may be one received from the AF 201), to an NEF in a PLMN that corresponds to the received PLMN ID from the UDM 75.
  • PLMN IDs e.g. the list of PLMN ID
  • the NEF 79 may send the Nnef_IoT_Service_Request message (e.g. the Nnef_IoT_Service_Request message may be one received from the AF 201), to an NEF in a PLMN that corresponds to the received PLMN ID from the UDM 75.
  • the NEF 79 may find appropriate AMF (e.g. the AMF 70) for the Service ID, and send the Namf_Communication_NonUeN2MessageTransfer message to the appropriate AMF.
  • appropriate AMF e.g. the AMF 70
  • the NEF 79 may store or receive in advance from other network node(s) information for finding the appropriate AMF.
  • the above-mentioned parameter(s) in step 6 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 7 Upon reception of the Namf_Communication_NonUeN2MessageTransfer message from the UDM 75, the AMF 70 finds the corresponding TAI(s) and associated RAN(s) 501 to the Service ID or TMGI or the Service ID and TMGI.
  • the AMF 70 may store or receive in advance from other network node(s) information for finding the corresponding TAI(s) and associated RAN(s) 501.
  • the AMF 70 sends a non-UE associated signalling, for example the DOWNLINK RAN CONFIGURATION TRANSFER message, to the RAN 501 (e.g. the associated RAN 501) including at least one of the TMGI, Service ID, Service order, TAI(s) (e.g. the corresponding TAI(s)), Ambient IoT profiles.
  • the AMF 70 sends multiple DOWNLINK RAN CONFIGURATION TRANSFER messages to all RANs 501 if the AMF 70 finds multiple RANs 501 that corresponds to the Service ID or TMGI or Service ID and TMGI.
  • the DOWNLINK RAN CONFIGURATION TRANSFER message may be a Class 2 procedure signaling message, and the DOWNLINK RAN CONFIGURATION TRANSFER message may be called as Group Page message, Ambient IoT Page message or Ambient IoT Group Page message.
  • the above-mentioned parameter(s) in step 7 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 8 Upon reception of the DOWNLINK RAN CONFIGURATION TRANSFER message from the AMF 70, the RAN 501 sends the Configuration update message to Radio Cell 502 including at least one of the TMGI, Service ID, Service order, TAI(s) and Ambient IoT profiles.
  • the RAN 501 sends multiple Configuration update messages to all Radio Cells 502 if the RAN 501 finds multiple Radio Cells 502 that corresponds to the Service ID or TMGI or Service ID and TMGI.
  • the RAN 501 sends the Configuration update message to Radio Cell(s) 502 that supports the received Ambient IoT profiles from the AMF 70.
  • the Configuration update message may be called as a Group Page message, Ambient IoT Page message or Ambient IoT Group Page message.
  • the above-mentioned parameter(s) in step 8 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 9 Steps 1-2 to 4 in Fig. 5 take place.
  • the RAN 501 may perform the energy feeding for the UE 3 via the Radio Cell 502, and may send at least one of the TMGI, Service ID, Service order, TAI(s) and Ambient IoT profiles to the UE 3 via the Radio Cell 502.
  • the sending at least one of the TMGI, Service ID, Service order, TAI(s) and Ambient IoT profiles may be corresponding to the Service request in step 2 of Fig. 5.
  • Step 10 The UE 3 sends the RRC Message number 3 message to the RAN 501 including at least one of Ambient IoT device type and Dedicated NAS.
  • the Ambient IoT device type indicates to the RAN 501 that the UE 3 is Ambient IoT device.
  • the Dedicated NAS includes the Control Plane Service Request message including MO-data.
  • the MO-data may be embedded in the CIoT small data container or CIoT user data container.
  • the MO-data may be an Ambient IoT related data from the UE 3 for the Ambient IoT communication.
  • the Ambient IoT application in the UE 3 provides the MO-data.
  • the RRC Message number 3 message may include the TMGI.
  • the Control Plane Service Request message may include at least one of the User ID (e.g. an identifier of the UE 3), Ambient IoT device type, GPSI, List of active TMGI.
  • the definition of the User ID in Fig. 4 may be applied to the User ID in step 10.
  • the above-mentioned parameter(s) in step 10 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • the above-mentioned parameter(s) in step 10 may be expressed as parameter(s) or data or information for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 11 Upon reception of the RRC Message number 3 message from the UE 3, the RAN 501 sends the Initial UE message to the AMF 70 including at least one of the Ambient IoT device type and NAS-PDU.
  • the NAS-PDU includes the Control Plane Service Request message that is received in the Dedicated NAS in Step 10.
  • the MO-data in the Control Plane Service Request message is security protected using the NAS security context.
  • the AMF 70 decodes the protected message using the NAS security context.
  • the above-mentioned parameter(s) in step 11 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • the above-mentioned parameter(s) in step 11 may be expressed as parameter(s) or data or information for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 12 Steps 8 to 12 in Fig. 5 take place.
  • the AMF 70 sends the Service Accept message to the UE 3 including MT-data.
  • the MT-data may be an Ambient IoT related data to the UE 3 for the Ambient IoT communication.
  • the UE 3 If the UE 3 receives the MT-data in the Service Accept message, the UE 3 sends the received MT-data to the Ambient IoT application in the UE 3.
  • the above-mentioned parameter(s) in step 13 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • the above-mentioned parameter(s) in step 13 may be expressed as parameter(s) or data or information for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • the UE 3 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 0, 9, 10 and 13.
  • the UE 3 may perform at least one of steps 0, 9, 10 and 13 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the Radio Cell 502 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 8 and 9.
  • the Radio Cell 502 may perform at least one of steps 8 and 9 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the RAN 501 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 7, 8, 10 and 11.
  • the RAN 501 may perform at least one of steps 7, 8, 10 and 11 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the AMF 70 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 6, 7, 11, 12 and 13.
  • the AMF 70 may perform at least one of steps 6, 7, 11, 12 and 13 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the UDM 75 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 4 and 5.
  • the UDM 75 may perform at least one of steps 4 and 5 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the NEF 79 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 2 to 6.
  • the NEF 79 may perform at least one of steps 2 to 6 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the AF 201 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1, 2 and 12.
  • the AF 201 may perform at least one of steps 1, 2 and 12 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • Variant 1 of Seventh scenario in First example of the First Aspect In a case where the AMF 70's control plane load from Ambient IoT Device communication reaches an overload threshold (which is indicated by the SMF 71 or the AMF 70 itself), the AMF 70 may decide to restrict the load caused by Ambient IoT Devices. In this case, the AMF 70 may send the Overload Start message to the RAN 501 including the Ambient IoT Communication overload. The Overload Start message including the Ambient IoT Communication overload may indicate that the overload occurs due to the Ambient IoT Device communication.
  • the RAN 501 may reject the RRC Message number 3 in step 10. In this case, the RAN 501 may send the RRC Connection Reject message or the RRC Connection Release message to the UE 3 including Ambient IoT back-off timer and a cause value indicating the Ambient IoT Communication overload (e.g. cause value indicating that the overload occurs due to the Ambient IoT Device communication).
  • a cause value indicating the Ambient IoT Communication overload e.g. cause value indicating that the overload occurs due to the Ambient IoT Device communication.
  • the UE 3 may restrict any communication towards the network for the Ambient IoT service for the duration of the Ambient IoT back-off timer.
  • the NEF 79 may initiate the Authentication and Authorization procedure with the UDM 75.
  • the message in step 2 may be another existing NEF service message or new NEF service message.
  • the message in steps 4 and step 5 may be another existing UDM service message or new UDM service message.
  • the message in step 6 may be another existing AMF service message or new AMF service message.
  • the step 8 may be optionally performed (or omitted) depending on the type of Radio Cell 502.
  • the Radio Cell 502 may be the RU, the repeater or the RSU.
  • the RAN 501 may perform the necessary configuration update even without sending a message to the Radio Cell 502.
  • Fig. 9 includes an example of the Ambient IoT device-initiated Service Activation procedure.
  • Step 0. The UE 3 is registered to the AMF 70 and a dedicated PDU Session for the Ambient IoT service has been established with the SMF 71 and the UPF 72.
  • the step 0 may be same to step 0 in Fig. 5.
  • the Ambient IoT Application in the UE 3 sends an uplink data (e.g. MO-data) to lower layer of the UE 3 and the uplink data is buffered in the UE 3.
  • the MO-data may be an Ambient IoT related data from the UE 3 for the Ambient IoT communication.
  • the MO-data may be data for the Ambient IoT.
  • the MO-data may be data for the Ambient IoT communication or for the Ambient IoT service.
  • Step 2 Step 2. Steps 9 to 13 in Fig. 8 take place.
  • the Radio Cell 502 may send a signal for feeding the energy for the UE 3.
  • the Radio Cell 502 may send a signal for feeding the energy for the UE 3 periodically.
  • the UE 3 may perform step 2.
  • the battery in the UE 3 have been charged by harvesting energy by receiving the signal from the Radio Cell 502.
  • the UE 3 performs step 2 using energy being harvested by receiving the signal from the Radio Cell 502.
  • the UE 3 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 0 to 2.
  • the UE 3 may perform at least one of steps 0 to 2 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • Fig. 10 includes an example of an architecture that supports ambient IoT devices.
  • the UE 301 in Fig. 10 represents an ambient IoT device.
  • the UE 301 may support a radio interface specific to the ambient IoT device communication.
  • the UE-to-Network Relay UE 303 e.g. the UE-to-Network Relay UE 30301 and the UE-to-Network Relay UE 30302 supports Uu interface
  • the UE-to-Network Relay UE 303 (e.g. the UE-to-Network Relay UE 30301 and the UE-to-Network Relay UE 30302) supports the radio interface specific to the ambient IoT device communication.
  • the radio interface specific to the Ambient IoT device communication is disclosed in the Second Aspect.
  • the UE-to-Network Relay UE 30301 and the UE-to-Network Relay UE 30302 are illustrated in the Warehouse #A as an example, the UE-to-Network Relay UE 30301 and the UE-to-Network Relay UE 30302 may be located in public space.
  • the UE 301 supports the PC 5 interface as defined in NPL 11.
  • the UE 301 communicates with the UE-to-Network Relay UE 30301 and the UE-to-Network Relay UE 30302 using the PC 5 interface.
  • the AF 20101 represents an application server in the data network.
  • the AF 20101 may trigger a task to collect status of the Ambient IoT devices.
  • the AF 20102 represents an application server in the data network.
  • the AF 20102 may be a server that collects status of the Ambient IoT devices.
  • the AF 20101 and the AF 20102 may be combined as one Application Function.
  • the AF 20101 and the AF 20102 may be collocated at the same location or located different location and different network domain.
  • the AF 20101 is located at an Ambient IoT device control centre while the AF 20102 is located at an Ambient IoT device data centre.
  • Fig. 11 includes an example of the Identity management model for Ambient IoT device using the Proximity based Services (ProSe) as defined in NPL 11.
  • ProSe Proximity based Services
  • the Identity management model for Ambient IoT device is characterized as the following features.
  • Ambient IoT device identity An Ambient IoT device identity may be represented as GPSI.
  • the Ambient IoT device identity may have one or multiple Application Layer Group ID(s).
  • the Application Layer Group ID represents a group of the Ambident IoT device.
  • the Application Layer Group ID may be preconfigured in the UE 301 by the Service provider.
  • the Application Layer Group ID may be preconfigured in the UE-to-Network Relay UE 303 (e.g. at least one of the UE-to-Network Relay UE 30301 and the UE-to-Network Relay UE 30302) by the PLMN or NPN operator.
  • the AF 201 When the AF 201 (at least one of the AF 20101 and the AF 20102) triggers a data communication with all group members represented by the Application Layer Group ID, the AF 201 communicates with the UE-to-Network Relay UE 303 for trigging the Ambient IoT communication. For example, in a case where the AF 201 wants to communication with the group members, the AF 201 may perform a procedure for communicating with the group members using the Application Layer Group ID.
  • the ProSe Layer-2 Group ID corresponds to the Application Layer Group ID.
  • the ProSe Layer-2 Group ID may be related to the Application Layer Group ID.
  • the ProSe Layer-2 Group ID may be preconfigured in the UE 301 by the Service provider.
  • the ProSe Layer-2 Group ID may be preconfigured in the UE-to-Network Relay UE 303 by the PLMN or NPN operator.
  • the Second scenario in Second example of the First Aspect discloses an example of the Ambient IoT device management procedures.
  • Fig. 12 includes the both procedures.
  • Step 0. The UE 301 is registered to the AMF 70 and a dedicated PDU Session for the Ambient IoT service has been established with the SMF 71 and the UPF 72.
  • the step 0 may be same to step 0 in Fig. 5.
  • the Ambient IoT management data provisioning Step 1 When the Ambient IoT Service application in the AF 201 determines to provide the Ambient IoT device management data to the UE-to-Network Relay UE 303, the AF 201 provides at least one of the Application Layer Group ID, ProSe Layer-2 Group IDs and Ambient IoT profiles to the UE-to-Network Relay UE 303 over user plane that is established in step 0.
  • ⁇ Application Layer Group ID Refer to First scenario in Second example of the First Aspect.
  • ⁇ ProSe Layer-2 Group IDs List of ProSe Layer-2 Group ID.
  • For ProSe Layer-2 Group ID refer to First scenario in Second example of the First Aspect.
  • ⁇ Ambient IoT profiles Refer to Second scenario in First example of the First Aspect for the Ambient IoT profile.
  • Ambient IoT profiles may be a list of Ambient IoT profile. Multiple Ambient IoT profiles are configured by the AF 201 when the AF 201 recognizes that Ambient IoT devices subject for the Service may support different air interface for the Ambient IoT communication.
  • the Ambient IoT device management data may include at least one of the Application Layer Group ID, ProSe Layer-2 Group IDs and Ambient IoT profiles.
  • the above-mentioned parameter(s) in step 1 may be expressed as parameter(s) or data or information for the Ambient IoT or for the Ambient IoT communication or for the Ambient IoT service.
  • the above-mentioned parameter(s) in step 1 may be expressed as parameter(s) or data or information related to the Ambient IoT or related to the Ambient IoT communication or related to the Ambient IoT service.
  • the Ambient IoT Service application in the AF 201 determines to start the Ambient IoT service activation. For example, one reason of this determination may be an inventory for goods. For example, the AF 201 may decide to start the Ambient IoT service for example, a gate-in inventory, Inventory at a warehouse, a gate-out inventory as described in NPL 2.
  • Step 3 The AF 201 provides at least one of the ProSe Layer-2 Group IDs, Service and Service order to the UE-to-Network Relay UE 303 over user plane that is established in step 0.
  • ProSe Layer-2 Group IDs List of ProSe Layer-2 Group ID.
  • For ProSe Layer-2 Group ID refer to First scenario in Second example of the First Aspect.
  • ⁇ Service Refer to Fifth scenario in First example of the First Aspect. Although not explicitly indicated in this scenario, the TMGI may be used for representing the Service.
  • Service order Refer to Fifth scenario in First example of the First Aspect.
  • the above-mentioned parameter(s) in step 3 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • the UE-to-Network Relay UE 303 may be expressed as a UE-to-Network Relay UE for the Ambient IoT or for the Ambient IoT communication or for the Ambient IoT service.
  • the UE-to-Network Relay UE 303 may perform a device management procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 0, 1 and 3.
  • the UE-to-Network Relay UE 303 may perform at least one of steps 0, 1 and 3 for the device management procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the AF 201 may perform a device management procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1 to 3.
  • the AF 201 may perform at least one of steps 1 to 3 for the device management procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the UE-to-Network Relay UE 303 may perform a procedure for the Ambient IoT management data provisioning by performing at least one of steps 0 and 1.
  • the UE-to-Network Relay UE 303 may perform at least one of steps 0 and 1 for the procedure for the Ambient IoT management data provisioning.
  • the AF 201 may perform a procedure for the Ambient IoT management data provisioning by performing at least step 1.
  • the AF 201 may perform at least step 1 for the procedure for the Ambient IoT management data provisioning.
  • the UE-to-Network Relay UE 303 may perform a procedure for the Ambient IoT Service Activation by performing at least step 3.
  • the UE-to-Network Relay UE 303 may perform at least step 3 for the procedure for the Ambient IoT Service Activation.
  • the AF 201 may perform a procedure for the Ambient IoT Service Activation by performing at least one of steps 2 and 3.
  • the AF 201 may perform at least one of steps 2 and 3 for the procedure for the Ambient IoT Service Activation.
  • the Third scenario in Second example of the First Aspect discloses an example of the Registration procedure for the UE 301.
  • the UE 301 represents the Ambident IoT device.
  • the Registration procedure for the UE 301 is the same as the Registration procedure as disclosed in the Third scenario in First example of the First Aspect with the following replacements.
  • the "UE 3" is replaced with the "UE 301".
  • the "Radio Cell 502" is replaced with the “Radio Cell 502 or the Radio Cell 502 and the UE-to-Network Relay UE 302" or the "UE-to-Network Relay UE 303".
  • the "List of active TMGI" is replaced with "List of active Service”.
  • the List of active Service may indicate active Service(s) for the UE 301.
  • the active Service may indicate the Ambient IoT service, for example, a gate-in inventory, Inventory at a warehouse, a gate-out inventory as described in NPL 2.
  • the list of active Service may be known by the AF 201 whether the UE 301 is able to communicate or not with the Service in the list. If the Service is listed in the list, the Service may be used to trigger the UE 301 for the Ambient IoT communication.
  • the List of active Service may indicate the Service(s) that is related to the UE 301.
  • the AF 201 may refer the List of active Service to know whether the UE 301 is able to communicate or not on the Service(s) in the List of active Service.
  • the AF 201 may communicate with the UE 301 by using the Service(s) in the List of active Service.
  • the AF 201 may perform the Ambient IoT, the Ambient IoT communication, the Ambient IoT service with the UE 301 by using the Service(s) in the List of active Service.
  • the Registration procedure includes additional processes and parameter handlings as described in section 6.6.2 of NPL 11.
  • the Fourth scenario in Second example of the First Aspect discloses an example of the Registration procedure for the UE-to-Network Relay UE 303.
  • the UE-to-Network Relay UE 303 represents a combined node including the UE-to-Network Relay UE as defined in NPL 11 and network node dedicated to communicate with the Ambident IoT devices.
  • the Registration procedure for the UE-to-Network Relay UE 303 is the same as the Registration procedure as described in section 6.6.2 of NPL 11.
  • Fig. 13 includes an example of the Ambient IoT Service Activation procedure.
  • the UE 301 is registered to the AMF 70 and a dedicated PDU Session for the Ambient IoT service has been established with the SMF 71 and the UPF 72.
  • step 0-1 the process(es) in the Third scenario in Second example of the First Aspect completes and the PDU Session has been established.
  • the AF 201 provides, to the UE 301, at least one of the GPSI, ProSe Layer-2 Group IDs, List of PLMN, Ambient IoT profile and Report to server address over user plane as disclosed in Fig. 12.
  • the GPSI may be the GPSI of the UE 301.
  • the definition of the List of PLMN, the Ambient IoT profile and the Report to server address in the Second scenario in First example of the First Aspect may be applied to the List of PLMN, the Ambient IoT profile and the Report to server address in step 0-2.
  • the above-mentioned parameter(s) in step 0-2 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • the UE-to-Network Relay UE 303 is registered to the AMF 70 and a dedicated PDU Session for the Ambient IoT service has been established with the SMF 71 and the UPF 72.
  • step 0-3 the process(es) in the Fourth scenario in Second example of the First Aspect completes and the PDU Session has been established.
  • the AF 201 provides, to the UE-to-Network Relay UE 303, at least one of the Application Layer Group ID, ProSe Layer-2 Group IDs and Ambient IoT profiles over user plane as disclosed in Fig. 12.
  • the above-mentioned parameter(s) in step 0-4 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 1 The AF 201 provides at least one of the ProSe Layer-2 Group IDs, Service and Service order to the UE-to-Network Relay UE 303 over user plane that is established in step 0-3.
  • Fig. 12 for parameter details.
  • the above-mentioned parameter(s) in step 1 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 2-1 Based on the received Service order in step 1, the UE-to-Network Relay UE 303 decides to start the Ambient IoT communication. For example, if the Validity time in the Service order indicates that the Ambient IoT communication is started at 12:00 the UE-to-Network Relay UE 303 decides to start the Ambient IoT communication at 12:00. For example, based on the received Service in step 1, the UE-to-Network Relay UE 303 may decide to start the Ambient IoT communication. For example, the UE-to-Network Relay UE 303 may decide to start the Ambient IoT communication indicated by the received Service.
  • the UE-to-Network Relay UE 303 may decide to start the Ambient IoT service indicated by the received Service. For example, the UE-to-Network Relay UE 303 may decide to start the Ambient IoT communication related to the Ambient IoT service which is indicated by the received Service.
  • the UE-to-Network Relay UE 303 may broadcast energy over the air. Refer to the Aspect 2 for detail of energy broadcasting.
  • Step 2-3 The UE 301 has had enough energy to perform the Ambient IoT communication. For example, if the UE 301 has a battery, the battery in the UE 301 have been charged by harvesting energy by receiving the broadcasted energy by Step 2-2. For example, if the UE 301 does not have a battery, the UE 301 performs the Ambient IoT communication using energy being harvested by receiving the broadcasted energy by Step 2-2.
  • Step 3 The UE-to-Network Relay UE 303 broadcasts the Group Member Discovery Solicitation message over the PC 5 interface including the ProSe Layer-2 Group ID.
  • the ProSe Layer-2 Group ID refer to the First scenario in Second example of the First Aspect.
  • the above-mentioned parameter(s) in step 3 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 4 If the UE 301 receives the Group Member Discovery Solicitation message over the PC 5 interface, the UE 301 sends the Group Member Discovery Response message to the UE-to-Network Relay UE 303 including at least one of Source Layer-2 ID, GPSI and MO-data.
  • ⁇ Source Layer-2 ID The Source Layer-2 ID is an identifier of the UE 301 over the PC5 interface.
  • ⁇ GPSI Refer to Fig. 3.
  • ⁇ MO-data The MO-data may be an Ambient IoT related data from the UE 301 for the Ambient IoT communication.
  • the above-mentioned parameter(s) in step 4 (e.g. the parameter(s) in the message of step 4) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • the above-mentioned parameter(s) in step 4 (e.g. the parameter(s) in the message of step 4) may be expressed as parameter(s) or data or information for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 5 The UE-to-Network Relay UE 303 sends the received data (e.g. at least one of the Source Layer-2 ID, GPSI and MO-data) from the UE 301 in step 4 to the AF 201 over the user plane that is established in step 0-3.
  • the received data e.g. at least one of the Source Layer-2 ID, GPSI and MO-data
  • the UE-to-Network Relay UE 303 may generate a data with agreed data format with the AF 201 based on the received data in Step 4 and send it to the AF 201.
  • Step 6 In a case where the UE-to-Network Relay UE 303 receives the MT-data from the AF 201 in step 5, the UE-to-Network Relay UE 303 sends the Unicast notification message to the UE 301 including at least one of Source Layer-2 ID and MT-data.
  • ⁇ Source Layer-2 ID Refer to Step 4.
  • ⁇ MT-data The MT-data may be an Ambient IoT related data from the AF 201 for the Ambient IoT communication.
  • the AF 201 may send the MT-data to the UE-to-Network Relay UE 303.
  • the UE 301 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 0-1, 0-2, 2-2, 2-3, 3, 4 and 6.
  • the UE 301 may perform at least one of steps 0-1, 0-2, 2-2, 2-3, 3, 4 and 6 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the UE-to-Network Relay UE 303 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 0-3, 0-4, 1, 2-1, 2-2, 3, 4, 5 and 6.
  • the UE-to-Network Relay UE 303 may perform at least one of steps 0-3, 0-4, 1, 2-1, 2-2, 3, 4, 5 and 6 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the AF 201 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 0-2, 0-4, 1 and 5.
  • the AF 201 may perform at least one of steps 0-2, 0-4, 1 and 5 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the UE 301 may communicate with the AF 201 using user plane between the UE 301 and AF 201.
  • the Steps 9 to 13 in Fig. 8 take place with the following replacements:
  • the "UE 3" is replaced with the "UE 301".
  • the "Radio Cell 502” is replaced with the "Radio Cell 502 or the Radio Cell 502 and the UE-to-Network Relay UE 303" or the "UE-to-Network Relay UE 303".
  • the "TMGI" is replaced with the "Application Layer Group ID" or the "ProSe Layer-2 Group ID".
  • the "List of active TMGI" is replaced with the "List of active Application Layer Group ID" or the "List of active ProSe Layer-2 Group ID”.
  • the List of active Application Layer Group ID indicates active Application Layer Group ID(s) in the UE 301.
  • the List of active Application Layer Group ID may be known by the AF 201 whether the UE 301 is able to communicate or not with an Application Layer Group ID in the list. If the Application Layer Group ID is listed in the List of active Application Layer Group ID, the Application Layer Group ID may be used to trigger the UE 301 for the Ambient IoT communication.
  • the List of active Application Layer Group ID may indicate Application Layer Group ID(s) that is related to the UE 301.
  • the List of active Application Layer Group ID may indicate Application Layer Group ID(s) that is assigned to the UE 301.
  • the AF 201 may refer the List of active Application Layer Group ID to know whether the UE 301 is able to communicate or not by using the Application Layer Group ID(s) in the List of active Application Layer Group ID.
  • the AF 201 may communicate with the UE 301 by using the Application Layer Group ID(s) in the List of active Application Layer Group ID.
  • the AF 201 may perform the Ambient IoT, the Ambient IoT communication, the Ambient IoT service with the UE 301 by using the Application Layer Group ID(s) in the List of active Application Layer Group ID.
  • the List of active ProSe Layer-2 Group ID indicates active ProSe Layer-2 Group ID(s) in the UE 301.
  • the List of active ProSe Layer-2 Group ID may be known by the AF 201 whether the UE 301 is able to communicate or not with a ProSe Layer-2 Group ID in the list. If the ProSe Layer-2 Group ID is listed in the List of active ProSe Layer-2 Group ID, the ProSe Layer-2 Group ID may be used to trigger the UE 301 for the Ambient IoT communication.
  • the List of active ProSe Layer-2 Group ID may indicate ProSe Layer-2 Group ID(s) that is related to the UE 301.
  • the List of active ProSe Layer-2 Group ID may indicate ProSe Layer-2 Group ID(s) that is assigned to the UE 301.
  • the AF 201 may refer the List of active ProSe Layer-2 Group ID to know whether the UE 301 is able to communicate or not by using the ProSe Layer-2 Group ID(s) in the List of active ProSe Layer-2 Group ID.
  • the AF 201 may communicate with the UE 301 by using the ProSe Layer-2 Group ID(s) in the List of active ProSe Layer-2 Group ID.
  • the AF 201 may perform the Ambient IoT, the Ambient IoT communication, the Ambient IoT service with the UE 301 by using the ProSe Layer-2 Group ID(s) in the List of active ProSe Layer-2 Group ID.
  • the UE-to-Network Relay UE 303 may collect MO-data from multiple UEs 301 and the UE-to-Network Relay UE 303 sends a bunch of collected data to the AF 201 over the user plane. With this way, user traffic between the UE-to-Network Relay UE 303 and the AF 201 may be decreased.
  • the Sixth scenario in Second example of the First Aspect discloses an example of the Ambient IoT device-initiated Service Activation procedure.
  • the Ambient IoT device-initiated Service Activation procedure is the same as the Ambient IoT device-initiated Service Activation procedure as disclosed in the Eighth scenario in First example of the First Aspect with the following replacements.
  • the "UE 3" is replaced with the "UE 301".
  • the "Radio Cell 502" is replaced with the "Radio Cell 502 or the Radio Cell 502 and the UE-to-Network Relay UE 303" or the "UE-to-Network Relay UE 303".
  • Fig. 14 includes an example of an architecture that supports ambient IoT devices.
  • the UE 3 in the figure represents an ambient IoT device.
  • the UE 3 may support a radio interface specific to the ambient IoT device communication.
  • the IAB Node 502 e.g. the IAB Node 50201 and the IAB Node 50202
  • the IAB Node 502 supports Uu interface
  • the IAB Node 502 supports the radio interface specific to the ambient IoT device communication.
  • the radio interface specific to the Ambient IoT device communication is disclosed in the Second Aspect.
  • the IAB Node 50201 and the IAB Node 50202 are illustrated in the Warehouse #A as an example, the IAB Node 50201 and the IAB Node 50202 may be located in public space.
  • the AF 20101 represents an application server in the data network.
  • the AF 20101 may trigger a task to collect status of the Ambient IoT devices.
  • the AF 20102 represents an application server in the data network.
  • the AF 20102 may be a server that collects status of the Ambient IoT devices.
  • the AF 20101 and the AF 20102 may be combined as one Application Function.
  • the AF 20101 and the AF 20102 may be collocated at the same location or located different location and different network domain.
  • the AF 20101 is located at an Ambient IoT device control centre while the AF 20102 is located at an Ambient IoT device data centre.
  • the First scenario in Third example of the First Aspect discloses an example of the Identity management model for Ambient IoT device.
  • the Identity management model for Ambient IoT device is the same as the Ambient IoT device-initiated Service Activation procedure as disclosed in the First scenario in First example of the First Aspect with the following replacements.
  • the "Radio Cell 502" is replaced with the "IAB Node 502".
  • the "RAN 501" is replaced with the "IAB Donor 501".
  • the Second scenario in Third example of the First Aspect discloses an example of the Ambient IoT device management procedure of the UE 3 that support the Ambient IoT communication.
  • the Ambient IoT device management procedure of the UE 3 that support the Ambient IoT communication is the same as the Ambient IoT device management procedure of the UE 3 that support the Ambient IoT communication as disclosed in the Second scenario in First example of the First Aspect with the following replacements.
  • the "Radio Cell 502" is replaced with the "IAB Node 502".
  • the "RAN 501" is replaced with the "IAB Donor 501".
  • the Third scenario in Third example of the First Aspect discloses an example of the Registration procedure of the Ambient IoT device as represented as the UE 3.
  • the Registration procedure of the UE 3 that support the Ambient IoT communication is the same as the Registration procedure of the UE 3 of the UE 3 that support the Ambient IoT communication as disclosed in the Third scenario in First example of the First Aspect with the following replacements.
  • the "Radio Cell 502" is replaced with the "IAB Node 502".
  • the "RAN 501" is replaced with the "IAB Donor 501".
  • the Fourth scenario in Third example of the First Aspect discloses an example of Registration procedure of the Ambient IoT device with the Ambient IoT data communication as represented as the UE 3.
  • the Registration procedure of the Ambient IoT device with the Ambient IoT data communication is the same as the Registration procedure of the Ambient IoT device with the Ambient IoT data communication as disclosed in the Fourth scenario in First example of the First Aspect with the following replacements.
  • the "Radio Cell 502" is replaced with the "IAB Node 502".
  • the "RAN 501" is replaced with the "IAB Donor 501".
  • Steps 1-2 to 4 are replaced with the steps 1 to 5 in Fig. 15.
  • Fig. 15 includes an example of the RRC setup procedure.
  • Step 1 The IAB Node 502 broadcasts energy over the air. Refer to the Aspect 2 for detail of energy broadcasting.
  • Step 2 The UE 3 has had enough energy to perform the registration procedure. For example, if the UE 3 has a battery, the battery in the UE 3 have been charged by harvesting energy by receiving the broadcasted energy by Step 1. For example, if the UE 3 does not have a battery, the UE 3 performs the Registration procedure using energy being harvested by receiving the broadcasted energy by Step 1.
  • the IAB Node 502 broadcasts system information with a list of TMGI indicating that the UE 3 is requested to perform the Ambient IoT communication immediately if the UE 3 has an active TMGI in the list of TMGI.
  • the UE 3 initiates the Ambient IoT communication as far as the UE 3 has enough energy for performing the Registration procedure regardless of receiving the system information in Step 2.
  • the above-mentioned parameter(s) in step 3 may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • the IAB Node 502 may broadcast the system information including the list of TMGI.
  • the system information may be expressed as a service request (e.g. a service request for the Ambient IoT, for the Ambient IoT communication or for the Ambient IoT service).
  • Step 4 The UE 3 sends the RRC Setup Request message to the IAB Node 502.
  • the UE 3 may send the RRC Setup Request message to the IAB Node 502.
  • the UE 3 may send the RRC Setup Request message to the IAB Node 502.
  • IAB Node 502 may send the RRC Setup Request message to the IAB Donor 501.
  • the UE 3 may send the RRC Setup Request message to the IAB Donor 501 via the IAB Node 502.
  • Step 5 Upon the reception of the RRC Setup Request message in Step 4, the IAB Donor 501 sends the RRC Setup message to the UE 3 including List of TMGI for MO requested.
  • the List of TMGI for MO requested indicates the UE 3 that the Ambient IoT communication associated to the TMGI (e.g. the broadcasted TMGI) is requested.
  • the IAB Donor 501 includes the List of TMGI for MO requested parameter only if the IAB Node 502 does not broadcast a system information with a list of TMGI in step 3.
  • the IAB Node 502 may send, to the IAB Donor 501, information indicating that the IAB Node 502 does not broadcast the system information.
  • the IAB Donor 501 may send the RRC Setup message to the UE 3 via the IAB Node 502.
  • the IAB Donor 501 may know that which the list of TMGI is broadcasted by which IAB Node(s).
  • the above-mentioned parameter(s) in step 5 may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • the UE 3 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1 to 5.
  • the UE 3 may perform at least one of steps 1 to 5 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the IAB Node 502 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1, 3, 4 and 5.
  • the IAB Node 502 may perform at least one of steps 1, 3, 4 and 5 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the IAB Donor 501 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 4 and 5.
  • the IAB Donor 501 may perform at least one of steps 4 and 5 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the Fifth scenario in Third example of the First Aspect discloses an example of the Service management model for Ambient IoT device.
  • the Service management model for Ambient IoT device is the same as the Service management model for Ambient IoT device as disclosed in the Fifth scenario in First example of the First Aspect with the following replacements.
  • the "Radio Cell 502" is replaced with the "IAB Node 502".
  • the "RAN 501" is replaced with the "IAB Donor 501".
  • the Sixth scenario in Third example of the First Aspect discloses an example of the Ambient IoT configuration notification procedure.
  • the Ambient IoT configuration notification procedure is the same as the Ambient IoT configuration notification procedure as disclosed in the Sixth scenario in First example of the First Aspect with the following replacements.
  • the "Radio Cell 502" is replaced with the "IAB Node 502".
  • the "RAN 501" is replaced with the "IAB Donor 501".
  • the Seventh scenario in Third example of the First Aspect discloses an example of the Ambient IoT Service Activation procedure.
  • the Ambient IoT Service Activation procedure is the same as the Ambient IoT Service Activation procedure as disclosed in the Seventh scenario in First example of the First Aspect with the following replacements.
  • the "Radio Cell 502" is replaced with the "IAB Node 502".
  • the "RAN 501" is replaced with the "IAB Donor 501".
  • the "Configuration update message" in step 8 is replaced with the "GNB-DU CONFIGURATION UPDATE message”.
  • Step 9 is replaced with Steps 1 to 5 in Fig. 15.
  • the Eighth scenario in Third example of the First Aspect discloses an example of the Ambient IoT device-initiated Service Activation procedure.
  • the Ambient IoT device-initiated Service Activation procedure is the same as the Ambient IoT device-initiated Service Activation procedure as disclosed in the Eighth scenario in First example of the First Aspect with the following replacements.
  • the "Radio Cell 502" is replaced with the "IAB Node 502".
  • the "RAN 501" is replaced with the "IAB Donor 501".
  • Step 2 is replaced with the following steps. Steps 1 to 5 in Fig. 15 take place. Steps 10 to 13 in Fig. 8 take place.
  • Fig. 16 includes an example of an architecture that supports ambient IoT devices.
  • the IoT Device 302 in Fig. 16 represents an ambient IoT device.
  • the IoT Device 302 supports a radio interface specific to the ambient IoT device communication.
  • the UE 301 (e.g. the UE 30101 and UE 30102) supports Uu interface
  • the UE 301 (e.g. the UE 30101 and UE 30102) supports the radio interface specific to the ambient IoT device communication. Both the UE 30101 and UE 30102 are able to communicate with the IoT Device 302 using the radio interface specific to the ambient IoT device communication.
  • the radio interface specific to the Ambient IoT device communication is disclosed in the Second Aspect.
  • the UE 30101 and UE 30102 are illustrated in the Warehouse #A as an example, the UE 30101 and UE 30102 may be located in public space as the same way with normal UEs.
  • the AF 20101 represents an application server in the data network.
  • the AF 20101 may trigger a task to collect status of the Ambient IoT devices.
  • the AF 20102 represents an application server in the data network.
  • the AF 20102 may be a server that collects status of the Ambient IoT devices.
  • the AF 20101 and the AF 20102 may be combined as one Application Function.
  • the AF 20101 and the AF 20102 may be collocated at the same location or located different location and different network domain.
  • the AF 20101 is located at an Ambient IoT device control centre while the AF 20102 is located at an Ambient IoT device data centre.
  • Fig. 17 includes an example of the Identity management model for Ambient IoT device.
  • the Identity management model for Ambient IoT device is characterized as the following features.
  • Ambient IoT device identity An Ambient IoT device identity may be represented as GPSI.
  • a Truncated GPSI is a short coded GPSI.
  • the Truncated GPSI may be expressed as T-GPSI.
  • the T-GPSI is used in the Page procedure.
  • the GPSI is converted to a SUPI and Truncated GPSI at the UDM 75.
  • the Ambient IoT device identity may have one or multiple TMGI(s).
  • the TMGI represents a group of the Ambident IoT device.
  • the TMGI may be called as Multicast MBS group.
  • the TMGI may be preconfigured in the IoT Device 302 by the Service provider.
  • the AF 201 triggers a data communication with all group members represented by the TMGI
  • the AF 201 initiates a device trigger procedure to the 5GS using the TMGI.
  • the AF 201 may perform a procedure for communicating with the group members towards the 5GS using the TMGI.
  • the TMGI is used by the RAN 5 as the Group paging identity.
  • the Second scenario in Fourth example of the First Aspect discloses an example of the Ambient IoT device management procedure of the IoT Device 302 that support the Ambient IoT communication.
  • the Ambient IoT device management procedure of the IoT Device 302 that supports the Ambient IoT communication is the same as the Ambient IoT device management procedure of the UE 3 that supports the Ambient IoT communication as disclosed in the Second scenario in First example of the First Aspect with the following replacements.
  • the "Radio Cell 502" is replaced with the "UE 301”.
  • the "UE 3" is replaced with the "IoT Device 302".
  • Fig. 18 includes an example of the Registration procedure of the Ambient IoT device as represented as the IoT Device 302.
  • This Registration procedure takes place by the IoT Device 302 at any time if the IoT Device 302 is able to communicate with the UE 301. For example, the IoT Device 302 has harvested enough energy over the radio interface specific to the ambient IoT device communication.
  • Step 1 The Ambient IoT device related data has been installed in the AF 201 and associated UDM 75 and NEF 79 may also be installed.
  • the Ambient IoT device management procedure as disclosed in the Second scenario in Fourth example of the First Aspect takes place.
  • the IoT Device 302 has enough energy to communicate with the UE 301 and the UE 301 decides for IoT Device 302 to register to the 5GC.
  • the IoT Device 302 may be fed energy to communicate with the UE 301 by the UE 301.
  • the UE 301 may send signal to feed the energy to communicate to the IoT Device 302.
  • the UE 301 may decide for IoT Device 302 to register to the 5GC, and proceed step 2.
  • the UE 301 sends the RRC Setup Request or RRC Connection Establishment Request message to the RAN 501 including Ambient IoT Support.
  • the Ambient IoT Support indicates that the UE 301 supports the Ambient IoT communication for the Ambient IoT devices (e.g. the IoT Device 302) that are associated with the UE 301.
  • the Ambient IoT Support indicates that the UE 301 is a UE that has a personal network with Ambient IoT devices.
  • the above-mentioned parameter(s) in step 2 may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 3 Upon the reception of the RRC Setup Request message in Step 2, the RAN 5 sends the RRC Setup message to the UE 301.
  • Step 4 The UE 301 sends the RRC Message number 3 message (e.g. RRC Connection Setup Complete message) to the RAN 5 including at least one of the Ambient IoT support and Dedicated NAS.
  • RRC Message number 3 message e.g. RRC Connection Setup Complete message
  • the RAN 5 including at least one of the Ambient IoT support and Dedicated NAS.
  • RRC Connection Setup Complete message e.g. RRC Connection Setup Complete message
  • the RAN 5 may refer to the received Ambient IoT support to select an AMF 70 (if not yet selected) which supports ambient IoT communication and management.
  • the Dedicated NAS includes the Registration Request message.
  • the Registration Request message to the AMF 70 includes at least one of User ID, Ambient IoT support, GPSI, List of active TMGI and Supported Ambient IoT profiles.
  • ⁇ User ID Refer to step 1 in Fig. 4.
  • the User ID may indicate or include at least one of the User ID of the IoT Device 302 and the User ID of the UE 301.
  • ⁇ Ambient IoT Support Refer to step 2.
  • the Ambient IoT support may indicate that at least one of the IoT Device 302 and the UE 301 support the Ambient IoT service and the Ambient IoT service-related procedures as disclosed by this disclosure.
  • ⁇ GPSI Refer to step 1 in Fig. 4.
  • the GPSI is a GPSI of at least one of the IoT Device 302 and the UE 301.
  • ⁇ List of active TMGI Refer to step 1 in Fig. 4.
  • the definition of the List of active TMGI of step 1 in Fig. 4 may be applied to the List of active TMGI in step 4.
  • the definition of the List of active TMGI of step 1 in Fig. 4 may be applied to the List of active TMGI in step 4, by replacing the UE 3 with the IoT Device 302.
  • ⁇ Supported Ambient IoT profiles The Supported Ambient IoT profiles indicates that Supported Ambient IoT profiles that are supported by both the IoT Device 302 and the UE 301 for IoT communication.
  • the Supported Ambient IoT profiles indicates that Supported Ambient IoT profiles that are supported by at least one of the IoT Device 302 and the UE 301 for IoT communication.
  • the Supported Ambient IoT profiles may include at least one data in the Ambient IoT profile described in step 2 of Fig. 3.
  • the Supported Ambient IoT profiles may include the Ambient IoT profile regarding the IoT Device 302 and the UE 301.
  • the Ambient IoT profile regarding the IoT Device 302 and the UE 301 may include at least one of data in the Ambient IoT profile described in step 2 of Fig. 3.
  • the Supported Ambient IoT profiles may include the Ambient IoT profile(s) for the IoT Device(s) 302 that the UE 3 supports.
  • the Supported Ambient IoT profiles may include the Ambient IoT profile(s) for the UE 3 supports.
  • the UE 301 may receive at least one of the User ID, Ambient IoT Support, GPSI, List of active TMGI and Supported Ambient IoT profiles regarding the IoT Device 302 in step 1 by communicating with the IoT Device 302.
  • the UE 301 may understand or know correspondence between the IoT Device 302 and at least one of the TMGI (or Service ID) and the Ambient IoT profile.
  • TMGI or Service ID
  • the UE 301 may understand or know which IoT Device(s) 302 is associated with which TMGI (or Service ID).
  • the UE 301 may understand or know which IoT Device(s) 302 is associated with which Ambient IoT profile.
  • the UE 301 may know or understand correspondence between TMGI(s) and Service ID.
  • the above-mentioned parameter(s) in step 4 may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 5 Upon reception of the RRC Message number 3 message from the UE 301, the RAN 5 sends the Initial UE message to the AMF 70 including at least one of the Ambient IoT support and NAS-PDU.
  • the NAS-PDU includes the Registration Request message that is received in the Dedicated NAS in Step 4.
  • the above-mentioned parameter(s) in step 5 may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 6 Upon reception of the Registration Request message in step 5, the AMF 70 sends the Nudm_UECM_Registration Request message to a UDM 75 including at least one of the SUPI, GPSI, List of active TMGI and Supported Ambient IoT profiles. Refer to Step 4 for parameter details.
  • the above-mentioned parameter(s) in step 6 may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 7 Upon reception of the Nudm_UECM_Registration Request message in step 6, the UDM 75 sends the Nudm_UECM_Registration Response message to the AMF 70.
  • Step 8 After the completion of the Nudm_UECM_Registration service in steps 6 and 7, the AMF 70 sends the Nudm_SDM_Get Request message to the UDM 75 including at least one of the SUPI, GPSI, List of active TMGI and Supported Ambient IoT profiles. Refer to Step 4 for parameter details.
  • the above-mentioned parameter(s) in step 8 may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 9 If the GPSI is received from the AMF 70, the UDM 75 assigns a Truncated GPSI (T-GPSI) to the received GPSI.
  • T-GPSI is a short type of data that can uniquely identify the Ambient IoT Device within the PLMN.
  • the UDM 75 finds Subscriber data for the UE 301 and sends the Nudm_SDM_Get Response message to the AMF 70 including the Subscriber data for the UE 301.
  • the Subscriber data includes at least one of the GPSI, T-GPSI, List of TMGI, List of PLMN, Ambient IoT profile and Report to server address. Refer to step 2 in Second scenario in First example of the First Aspect for parameter details.
  • the T-GPSI may be related to the GPSI, and related to at least one of the UE 301 and IoT Device 302.
  • the above-mentioned parameter(s) in step 9 may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 10 The UDM 75 sends the Nudm_EventExposure_Notify message to the NEF 79 including at least one of the SUPI, GPSI and List of active TMGI if the NEF 79 has subscribed to the Nudm_EventExposure service.
  • the above-mentioned parameter(s) in step 10 may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 11 The NEF 79 sends the Nnef_EventExposure_Notify message to the AF 201 including at least one of the SUPI, GPSI and List of active TMGI if the AF 201 has subscribed to the Nnef_EventExposure service.
  • the GPSI can be associated with the SUPI in the AF 201.
  • the above-mentioned parameter(s) in step 11 may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • the AMF 70 sends the Registration Accept message to the UE 301 including at least one of 5G-GUTI, the GPSI, the T-GPSI, the List of TMGI, the List of PLMN, the Ambient IoT profile and the Report to server address.
  • the 5G-GUTI is a temporary user identifier for the UE 301.
  • the above-mentioned parameter(s) in step 12 may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 13 Upon reception of the Registration Accept message, the UE 301 stores the received data in the Registration Accept message in step 12. The UE 301 may store the received data in the Registration Accept message in step 12 into non-volatile memory in the UE 301.
  • the UE 301 sends the Registration Complete message to the AMF 70.
  • Step 14 The UE 301 communicates with the IoT Device 302 and informs that the Registration procedure is successfully performed and the Ambient IoT service is available.
  • the UE 301 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1 to 4 and 12 to 14.
  • the UE 301 may perform at least one of steps 1 to 4 and 12 to 14 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the RAN 5 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 2 to 5.
  • the RAN 5 may perform at least one of steps 2 to 5 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the AMF 70 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 5 to 9, 12 and 13.
  • the AMF 70 may perform at least one of steps 5 to 9, 12 and 13 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the UDM 75 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 6 to 10.
  • the UDM 75 may perform at least one of steps 6 to 10 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the NEF 79 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 10 and 11.
  • the NEF 79 may perform at least one of steps 10 and 11 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the AF 201 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least step 11.
  • the AF 201 may perform at least step 11 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the UE 301 may include a new RRC Connection establishment cause within the RRC connection establishment cause parameter, called for example 'ambient IoT' cause or any other notation for RRC connection establishment cause to indicate that the data carried within the RRC Connection Establishment Request or RRC Connection Setup Request message is originated from an ambient IoT device. This may help the RAN 5 to select an AMF (if not selected yet) which supports management and communication of ambient IoT type.
  • a new RRC Connection establishment cause within the RRC connection establishment cause parameter called for example 'ambient IoT' cause or any other notation for RRC connection establishment cause to indicate that the data carried within the RRC Connection Establishment Request or RRC Connection Setup Request message is originated from an ambient IoT device.
  • This may help the RAN 5 to select an AMF (if not selected yet) which supports management and communication of ambient IoT type.
  • the new RRC connection establishment cause 'ambient IoT' may also help the RAN 5 and the AMF 70 with the decision whether to employ the normal data exchange (e.g., create data bearers) or deploy the Optimised CIoT Control plane data exchange for small data or to deploy the Early Data Exchange (EDT) procedure. Also, in case of a network overload from ambient IoT type of communication (e.g.
  • the RAN 5 may start to reject the RRC connection requests from all UEs which indicate the 'ambient IoT' RRC connection establishment cause in the RRC Establishment cause parameter within the RRC Connection Establishment Request or RRC Connection Setup Request message or the RAN 5 may release the already established RRC connections in order to reduce the overload from ambient IoT devices.
  • the RAN 5 may include a back-off timer called 'ambient IoT back-off timer' or any other notation for a back-off timer or a wait timer with the purpose to restrict the UEs coming back for data exchange for data from ambient IoT devices for the duration of the 'ambient IoT back-off timer'. If the UE 301 was rejected for RRC connection establishment for IoT communication or an already established RRC connection for IoT communication was released with an 'ambient IoT back-off timer', the UE 301 may not trigger another request for ambient IoT communication for the duration of the received 'ambient IoT back-off timer'. The 'ambient IoT back-off timer' may be reset if the UE 301 reregisters with another AMF (location update) or reselect another PLMN.
  • AMF location update
  • Fig. 19 includes an example of the Registration procedure of the Ambient IoT device with the Ambient IoT data communication as represented as the IoT Device 302.
  • Step 0. The UE 301 is registered to the AMF 70 and a dedicated PDU Session for the Ambient IoT service has been established with the SMF 71 and the UPF 72. For example, in step 0, the process(es) in Fig. 18 completes and the PDU Session has been established.
  • the AF 201 may trigger the UE 301 for Ambient IoT communication with list of TMGI over the user plane. In one example, the AF 201 may trigger the Ambient IoT communication by using the list of TMGI. For example, the AF 201 may trigger the Ambient IoT communication for at least one of the UE 301 and IoT Device 302 which is identified by TMGI(s) in the list of TMGI.
  • Steps 1 to 8 in the the Ambient IoT Service Activation procedure in the Fig. 8 may take place.
  • the replacements of the RAN 501 with the RAN 5 and the Radio Cell 502 with the UE 301 may be needed.
  • Step. 1-2 The UE 301 broadcasts energy over the air.
  • the energy broadcasting may be trigged by the activation request in Step 1-1.
  • the energy broadcasting may be trigged by the process(es) in Step 1-1.
  • Step 1-3 The IoT Device 302 has had enough energy to perform the registration procedure. For example, if the IoT Device 302 has a battery, the battery in the IoT Device 302 have been charged by harvesting energy by receiving the broadcasted energy by Step 1-2. For example, if the IoT Device 302 does not have a battery, the IoT Device 302 performs the Registration procedure using energy being harvested by receiving the broadcasted energy by Step 1-2.
  • Step 2-1 the UE 301 broadcasts a system information with a list of TMGI indicating that the UE 301 is requested to perform the Ambient IoT communication immediately if the IoT Device 302 has an active TMGI in the list of TMGI.
  • the IoT Device 302 holds the MO-data to send to the AF 201.
  • Step 2-2 The IoT Device 302 sends the MO-data to the UE 301 with a dedicated communication between the IoT Device 302 and UE 301.
  • the IoT Device 302 initiates the Ambient IoT communication as far as the IoT Device 302 has enough energy for performing the Registration procedure regardless of receiving the system information in Step 2.
  • the above-mentioned parameter(s) in step 2-1 or 2-2 may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • the UE 301 may broadcast the system information including the list of TMGI.
  • the system information may be expressed as a service request (e.g. a service request for the Ambient IoT, for the Ambient IoT communication or for the Ambient IoT service).
  • Step 3 After the UE 301 receives the MO-data from the IoT Device 302, the UE 301 sends the RRC Setup Request message to the RAN 5 including Ambient IoT Support.
  • the Ambient IoT Support indicates that the UE 301 supports the Ambient IoT communication for IoT devices on behalf of connected IoT Device 302(s). I.E., the Ambient IoT Support indicates that the IoT Device 302 is a UE that has a personal network with the UE 301.
  • the IoT Device 302 may send the MO-data to the UE 301. Then, the UE 301 may send the RRC Setup Request message to the RAN 5 after the UE 301 receives the MO-data from the IoT Device 302.
  • the IoT Device 302 may send the MO-data to the UE 301. Then, the UE 301 may send the RRC Setup Request message to the RAN 5 after the UE 301 receives the MO-data from the IoT Device 302.
  • the above-mentioned parameter(s) in step 3 may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 4 Upon the reception of the RRC Setup Request message in Step 3, the RAN 5 sends the RRC Setup message to the UE 301 including List of TMGI for MO requested.
  • the List of TMGI for MO requested indicates the IoT Device 302 that the Ambient IoT communication associated with the TMGI is requested.
  • the RAN 5 includes the List of TMGI for MO requested parameter only if the UE 301 does not broadcast the system information with the list of TMGI in step 2. For example, in step 0, the UE 301 may inform the RAN 5 that the UE 301 is not able to broadcast the system information. In this case, the RAN 5 may include the List of TMGI for MO requested in the RRC Setup message.
  • the above-mentioned parameter(s) in step 4 may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 5 The UE 301 sends the RRC Message number 3 message to the RAN 5 including at least one of the Ambient IoT support and Dedicated NAS.
  • the Dedicated NAS includes the Registration Request message.
  • the Registration Request message in step 5 includes the MO-data.
  • the MO-data may be embedded in the CIoT small data container or CIoT user data container.
  • the MO-data may be an Ambient IoT related data from the IoT Device 302 for the Ambient IoT communication.
  • the Ambient IoT application in the IoT Device 302 provides the MO-data.
  • the messages in steps 3 to 5 may be communicated between the IoT Device 302 and RAN 5 without intervening the UE 301.
  • the above-mentioned parameter(s) in step 5 may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 6 Upon reception of the RRC Message number 3 message from the UE 301, the RAN 5 sends the Initial UE message to the AMF 70 including at least one of the Ambient IoT device type and NAS-PDU.
  • the NAS-PDU includes the Registration Request message that is received in the Dedicated NAS in Step 5.
  • the MO-data in the Registration Request message is security protected using the NAS security context.
  • the AMF 70 decodes the protected message using the NAS security context.
  • the above-mentioned parameter(s) in step 6 may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 7 Steps 6 to 11 in Fig. 18 take place.
  • Step 8 The AMF 70 sends the Nsmf_PDUSession_SendMOData message to the SMF 71 including the MO-data.
  • Step 9 The SMF 71 forward the received MO-data to the UPF 72.
  • the UPF 72 communicates with the AF 201 or any server in data network for the Ambient IoT communication.
  • the UPF 72 sends the MO-data to the AF 201.
  • the AF 201 sends a MT-data to the IoT Device 302.
  • the AF 201 sends, to the UPF 72, the MT-data for the IoT Device 302.
  • the MT-data may be an Ambient IoT related data to the IoT Device 302 for the Ambient IoT communication.
  • the UPF 72 may forward the MT-data if the UPF 72 receives the MT-data during the Ambient IoT communication. For example, the UPF 72 receives the MT-data as a reply to the MO-data. The UPF 72 may forward the MT-data to the SMF 71.
  • Step 12 The SMF 71 sends the Namf_Communication_N1N2MessageTransfer message to the AMF 70.
  • the Namf_Communication_N1N2MessageTransfer message may include the MT-data.
  • Step 13 The AMF 70 sends the Registration Accept message to the UE 301.
  • the Registration Accept message in step 13 includes the MT-data.
  • the MT-data may be an Ambient IoT related data to the IoT Device 302 for the Ambient IoT communication.
  • the Registration Accept message may be transmitted to the IoT Device 302 via the UE 301.
  • the above-mentioned parameter(s) in step 13 may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 14 Upon reception of the Registration Accept message, the UE 301 stores the received data in the Registration Accept message in step 13. The UE 301 stores the received data in the Registration Accept message in step 13 into non-volatile memory in the UE 301.
  • the UE 301 sends the Registration Complete message to the AMF 70.
  • the Registration Complete message may be transmitted to the AMF 70 from the IoT Device 302 without intervening the UE 301.
  • Step 15 The UE 301 communicates with the IoT Device 302 and informs that the Registration procedure and IoT data transmission to the AF 201 are successfully performed.
  • the UE 301 If the MT-data is received from the AMF 70 in step 13, the UE 301 also communicates with the IoT Device 302 and informs the received MT-data.
  • the UE 301 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 0, 1-1, 1-2, 2 and 15.
  • the UE 301 may perform at least one of steps 0, 1-1, 1-2, 2 and 15 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the IoT Device 302 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1-2, 1-3, 2 to 5, 13, 14 and 15.
  • the IoT Device 302 may perform at least one of steps 1-2, 1-3, 2 to 5, 13, 14 and 15 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the RAN 5 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 3 to 6.
  • the RAN 5 may perform at least one of steps 3 to 6 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the AMF 70 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 6 to 8, 12 to 14.
  • the AMF 70 may perform at least one of steps 6 to 8, 12 to 14 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the SMF 71 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 8, 9, 11 and 12.
  • the SMF 71 may perform at least one of steps 8, 9, 11 and 12 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the UDM 75 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least step 7.
  • the UDM 75 may perform at least step 7 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the UPF 72 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 9 to 11.
  • the UPF 72 may perform at least one of steps 9 to 11 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the NEF 79 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least step 7.
  • the NEF 79 may perform at least step 7 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the AF 201 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 7 and 10.
  • the AF 201 may perform at least one of steps 7 and 10 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the Fifth scenario in Fourth example of the First Aspect discloses an example of the Service management model for Ambient IoT device.
  • the Service management model for Ambient IoT device is the same as Service management model for Ambient IoT device as disclosed in the Fifth scenario in First example of the First Aspect with the following replacements.
  • the "Radio Cell 502" is replaced with the "UE 301".
  • the "RAN 501" is replaced with the "RAN 5".
  • the Sixth scenario in Fourth example of the First Aspect discloses an example of the Ambient IoT configuration notification procedure.
  • the Ambient IoT configuration notification procedure is the same as the Ambient IoT configuration notification procedure as disclosed in the Sixth scenario in First example of the First Aspect with the following replacements.
  • the "Radio Cell 502" is replaced with the "UE 301”.
  • the "RAN 501" is replaced with the "RAN 5".
  • the "Radio Cell” is replaced with the "UE”.
  • the "UE 3" is replaced with the "IoT Device 302".
  • Fig. 20 includes an example of the Ambient IoT Service Activation procedure for Ambient IoT device procedure.
  • Step 0. The UE 3 is registered to the AMF 70 and a dedicated PDU Session for the Ambient IoT service has been established with the SMF 71 and the UPF 72.
  • the step 0 may be same to step 0 in Fig. 19.
  • Step 1 Steps 1 to 6 in Fig. 8 take place.
  • Step 2 Upon reception of the Namf_Communication_NonUeN2MessageTransfer message from the NEF 79, the AMF 70 finds RAN(s) 5 that have a coverage corresponding to the received Location. Then, the AMF 70 screens the found RAN(s) 5 by using the RAN configuration with regard to at least one of the Ambient IoT support, Supported Ambient IoT profiles, Supported Service IDs and Supported TMGIs.
  • the AMF 70 may find or select the RAN(s) 5 which indicates the Ambient IoT support (e.g. the AMF 70 may find or select the RAN(s) 5 which supports the Ambient IoT service and the Ambient IoT service-related procedures as disclosed by this disclosure).
  • the AMF 70 may take into account the Supported Ambient IoT profiles for the RAN(s) 5 for screening, finding or selecting the RAN(s) 5.
  • the AMF 70 may find or select the RAN(s) 5 which supports at least one of an appropriate Frequency band for the TMGI (e.g. the appropriate Frequency band for the Ambient IoT service related to the TMGI), an appropriate Air interface (or radio interface) for the TMGI (e.g. the appropriate Air interface or radio interface for the Ambient IoT service related to the TMGI) and an appropriate security parameter for the TMGI (e.g. the appropriate security parameter for the Ambient IoT service related to the TMGI).
  • an appropriate Frequency band for the TMGI e.g. the appropriate Frequency band for the Ambient IoT service related to the TMGI
  • an appropriate Air interface or radio interface
  • an appropriate security parameter for the TMGI e.g. the appropriate security parameter for the Ambient IoT service related to the TMGI
  • the AMF 70 may take into account the Supported Service IDs for the RAN(s) 5 for screening, finding or selecting the RAN(s) 5.
  • the AMF 70 may find or select the RAN(s) 5 which supports the Ambient IoT service(s) related to at least one of the TMGI received from the NEF 79 and the Supported Service ID(s).
  • the AMF 70 may screen, find or select the RAN(s) 5 which supports or is related to the TMGI received from the NEF 79 by referring to the Supported TMGI(s) for the RAN(s) 5 and the received TMGI from the NEF 79.
  • the AMF 70 may find or select the RAN(s) 5 which supports or is related to TMGI#1 based on the Supported TMGI(s).
  • the AMF 70 may take into account the Ambient IoT support for the RAN(s) 5 for screening, finding or selecting the RAN(s) 5.
  • the AMF 70 may find or select the RAN(s) 5 which supports the received Ambient IoT profiles.
  • the AMF 70 sends Page messages to all RAN(s) 5, that are found as target RAN(s) by the location coverage and capability point of view, including at least one of the received TMGI from the NEF 79 and TAI list that are found by converting the received Location to corresponding TAIs where that matches with the received Location.
  • the AMF 70 may send the Page message to the RAN(s) 5 which is found by the AMF 70 based on the above-mentioned description.
  • the Page message may be called as a Group Page message, Ambient IoT Page message or Ambient IoT Group Page message or any other notation for a paging message used for paging of ambient IoT devices.
  • the above-mentioned parameter(s) in step 2 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 3 The RAN 5 performs the page with the TMGI for all cells that corresponds to the received TAIs in step 2.
  • the Page may be called as a Group Page, Ambient IoT Page or Ambient IoT Group page.
  • the RAN 5 may perform the page (e.g. the paging procedure) by using the received TMGI for cell(s) corresponding to the received TAI(s) in step 2.
  • the page e.g. the paging procedure
  • the above-mentioned parameter(s) in step 3 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 4 If the UE 301 receives the TMGI over Paging channel that corresponds to the Ambient IoT service that one of IoT Device 302 engages to, the UE 301 sends the Service Request message to the AMF 70 including the TMGI.
  • the UE 301 may send the Service Request message to the AMF 70 including the TMGI.
  • the UE 301 may send the Service Request message to the AMF 70 including the TMGI.
  • the above-mentioned parameter(s) in step 4 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 5 Upon reception of the Service Request message from the UE 301, the AMF 70 sends the Configuration Update Command message to the UE 301 including at least one of the TMGI, Service ID and Ambient IoT profile.
  • the definition of the TMGI, Service ID and Ambient IoT profile in the above-mentioned other scenario or other example in this disclosure may be applied to the TMGI, Service ID and Ambient IoT profile in step 5.
  • the above-mentioned parameter(s) in step 5 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 6-1 Upon reception of the UE Configuration Update Command message from the AMF 70, the UE 301 finds the corresponding IoT Device(s) 302 to at least one of the TMGI and Service ID and supported Ambient IoT profile (e.g. the Ambient IoT profile), and performs the Ambient IoT communication between the UE 301 and the IoT Device(s) 302.
  • the security parameter in the Ambient IoT profile may be used by the UE 301 and the IoT Device(s) 302 for mutual or Ambient IoT device authentication and authorization.
  • the security parameter in the Ambient IoT profile may be used by the UE 301 and the IoT Device(s) 302 for integrity protection and confidentiality protection for the Ambient IoT communication over the dedicated Ambient IoT communication interface over the air.
  • the UE 301 may find the IoT Device(s) 302 based on at least one of the received TMGI, Service ID and Ambient IoT profile from the AMF 70 and at least one of the received List of TMGI and Ambient IoT profile from the AMF 70 in step 12 of Fig. 18 (i.e. at least one of the List of TMGI and Ambient IoT profile received during the Registration procedure in Fig. 18).
  • the UE 301 may find or select the IoT Device 302 corresponding to TMGI#1. Then the UE 301 may perform the Ambient IoT communication with the found IoT Device 302.
  • the UE 301 may find or select the IoT Device 302 corresponding to Ambient IoT profile#1. Then the UE 301 may perform the Ambient IoT communication with the found IoT Device 302.
  • the IoT Device 302 may send MO-data (e.g. the Ambient IoT data from the IoT Device 302) to the UE 301.
  • MO-data e.g. the Ambient IoT data from the IoT Device 302
  • the IoT Device 302 may receive MT-data (e.g. the Ambient IoT data to the IoT Device 302) from the UE 301.
  • MT-data e.g. the Ambient IoT data to the IoT Device 302
  • the UE 301 may send a signal to feed the energy to perform communication with the IoT Device 302.
  • the IoT Device 302 perform the Ambient IoT communication with the UE 301 by using the energy fed by the UE 301.
  • Step 6-2 The UE 301 takes a role of conveying the Ambient IoT data from the IoT Device 302 to an Ambient IoT server (e.g. the AF 201).
  • the Ambient IoT server may be found in the Report to server address in the received Ambient IoT profile.
  • the UE 301 takes a role of conveying the Ambient IoT data from the Ambient IoT server to the IoT Device 302.
  • the UE 301 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 0, 3 to 5, 6-1 and 6-2.
  • the UE 301 may perform at least one of steps 0, 3 to 5, 6-1 and 6-2 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the IoT Device 302 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least 6-1.
  • the IoT Device 302 may perform at least 6-1 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the RAN 5 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 2 and 3.
  • the RAN 501 may perform at least one of steps 2 and 3 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the AMF 70 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1, 2, 4 and 5.
  • the AMF 70 may perform at least one of steps 1, 2, 4 and 5 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the UDM 75 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least step 1.
  • the UDM 75 may perform at least step 1 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the NEF 79 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least step 1.
  • the NEF 79 may perform at least step 1 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the AF 201 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1 and 6-2.
  • the AF 201 may perform at least one of steps 1 and 6-2 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • Fig. 21 includes an example of the Ambient IoT Service Activation for Ambient IoT device procedure.
  • Step 0. The UE 301 is registered to the AMF 70 and a dedicated PDU Session for the Ambient IoT service has been established with the SMF 71 and the UPF 72.
  • the step 0 may be same to step 0 in Fig. 19.
  • the AF 201 decides to start the Ambient IoT service activation for Ambient IoT device.
  • the AF 201 may decide to start the Ambient IoT service for example, a gate-in inventory, Inventory at a warehouse, a gate-out inventory as described in NPL 2.
  • Step 2 The AF 201 sends an Nnef_IoT_Service_Request message to the NEF 79 including at least one of TMGI, GPSI, Service, Service order and Ambient IoT profiles.
  • the Ambient IoT profiles may be included by the AF 201 if the Ambient IoT profile corresponds to the Service which has been updated lately.
  • the replacement of the UE 3 with the IoT Device 302 or the UE 301 may be applied to the definition of the parameters below.
  • the definition of the TMGI, GPSI, Service, Service order and Ambient IoT profiles in above-mentioned other scenario or other example in this disclosure may be applied to the the TMGI, GPSI, Service, Service order and Ambient IoT profiles in step 2.
  • TMGI Refer to Step 2 in Fig. 8.
  • ⁇ GPSI Refer to Step 2 in Fig. 3.
  • ⁇ Service Refer to Step 2 in Fig. 8.
  • ⁇ Service order Refer to Step 2 in Fig. 8.
  • ⁇ Ambient IoT profiles Refer to Step 2 in Fig. 8.
  • the above-mentioned parameter(s) in step 2 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 3 Upon reception of the Nnef_IoT_Service_Request message from the AF 201 in step 2, the NEF 79 converts the received Service to a Service ID.
  • the Service ID may be a common value among operator networks or a unique value only valid in the PLMN or the NPN where the NEF 79 belongs to.
  • Step 4 Upon the reception of the Nnef_IoT_Service_Request message from the AF 201 (or in a case where the NEF 79 converts the received Service to the Service ID), the NEF 79 sends the Nudm_SDM_Get Request message to the UDM 75 including at least one of the TMGI, GPSI, Service ID, Location and Ambient IoT profiles.
  • the TMGI, Location and Ambient IoT profile in step 4 are ones received from the AF 201.
  • the Service ID in step 4 is one converted by the NEF 79 in step 3.
  • the above-mentioned parameter(s) in step 4 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 5 Upon the reception of the Nudm_SDM_Get Request message from the NEF 79, the UDM 75 performs at least one of the following actions: If the GPSI is received, the UDM 75 converts the GPSI to a Truncated GPSI (T-GPSI). For example, the UDM 75 may store or receive from other network node(s) in advance information for this conversion. If the GPSI is received, the UDM 75 finds an AMF and SUPI that the Ambient IoT Device 302 is associated with. For example, the UDM 75 may store or receive from other network node(s) in advance information for this finding.
  • T-GPSI Truncated GPSI
  • the UDM 75 may find the SUPI based on the received GPSI. For example, the UDM 75 may find the AMF based on the received GPSI. For example, in a case where the UDM 75 knows that received GPSI#1 is related to the AMF 70, the UDM 75 may find the AMF 70. For example, the UDM 75 may find the AMF based on the received TMGI. For example, in a case where the UDM 75 stores the Supported TMGIs regarding the AMF 70 including TMGI#1 and the UDM 75 receives TMGI#1 in step 4, the UDM 75 may find the AMF 70.
  • the UDM 75 In a case where the UDM 75 has been notified in advance a support of Service ID from the AMF 70 and the received Service ID corresponds to that Service ID (e.g. in a case where the UDM 75 has received the Service ID from the AMF 70 in advance, and the received Service ID from the AMF 70 corresponds to the received Service ID from the NEF 79 in step 4), the UDM 75 provides all notified AMF(s) 70 to the NEF 79 for the Service ID (e.g. the UDM 75 may provide, to the NEF 79, information regarding the AMF 70 which sends the Service ID to the UDM 75).
  • the UDM 75 updates the Ambient IoT profiles corresponding to the Service ID in the storage of the UDM 75.
  • the UDM 75 may store or receive from other network node(s) in advance information indicating correspondence between the Ambient IoT profiles and the Service ID.
  • the Ambient IoT profiles may be related to the Service ID.
  • the UDM 75 sends the Nudm_SDM_Get Response message to the NEF 79 including at least one of AMF (e.g. list of AMF(s)), the SUPI, the T-GPSI and the Ambient IoT profiles.
  • AMF e.g. list of AMF(s)
  • the Ambient IoT profiles may be provided if the NEF 79 does not provide the Ambient IoT profiles to the UDM 75 in step 4 and the UDM 75 holds the Ambient IoT profiles for the Service ID.
  • the list of AMF(s) may include AMF(s) which supports the Service ID or the Ambient IoT service indicated by the Service ID.
  • the list of AMF(s) may include AMF(s) which is found by the UDM 75.
  • the above-mentioned parameter(s) in step 5 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 6 Upon reception of the Nudm_SDM_Get Response message from the UDM75, the NEF 79 sends the Namf_Communication_NonUeN2MessageTransfer message to the AMF 70 (e.g. to the AMF 70 indicated by the list of AMF(s) in step 5) including at least one of the TMGI, SUPI, GPSI, T-GPSI, Service ID, Service order and Ambient IoT profiles.
  • the above-mentioned parameter(s) in step 6 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 7 Upon reception of the Namf_Communication_NonUeN2MessageTransfer message from the NEF 79, the AMF 70 sends Page message(s) to the RAN 5 that corresponds to the Registration Area for the SUPI.
  • the Page message includes at least one of 5G-S-TMSI, T-GPSI and TAI list.
  • the AMF 70 may send the Page message including the TMGI.
  • the above-mentioned parameter(s) in step 7 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 8 The RAN 5 performs the page by using the 5G-S-TMSI for all cell(s) that corresponds to the received TAI list in step 7.
  • This Page (e.g. the Page message sent in step 8) includes the T-GPSI.
  • the RAN 5 may perform the page by using the T-GPSI.
  • the RAN 5 may perform the Page by using the TMGI.
  • the above-mentioned parameter(s) in step 8 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 9 If the UE 301 receives the 5G-S-TMSI or T-GPSI or TMGI over Paging channel and a GPSI, that is converted from the received T-GPSI in the UE 301 and corresponds to the Ambient IoT service that one of IoT Device 302 engages to, the UE 301 sends the Service Request message to the AMF 70 including at least one of the 5G-S-TMSI or TMGI, T-GPSI and GPSI.
  • the UE 301 may send the Service Request message to the AMF 70 including at least one of the 5G-S-TMSI, TMGI, T-GPSI and GPSI.
  • the UE 301 may send the Service Request message to the AMF 70 including at least one of the T-GPSI and GPSI.
  • the UE 301 may send the Service Request message to the AMF 70 including at least one of the T-GPSI and GPSI.
  • the above-mentioned parameter(s) in step 9 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 10 Upon reception of the Service Request message from the UE 301, the AMF 70 sends the Configuration Update Command message to the UE 301 including at least one of the TMGI, Service ID and Ambient IoT profile.
  • the definition of the TMGI, Service ID and Ambient IoT profile in the above-mentioned other scenario or other example in this disclosure may be applied to the TMGI, Service ID and Ambient IoT profile in step 10.
  • the above-mentioned parameter(s) in step 10 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 11 Steps 6-1 and 6-2 in Fig. 20 take place.
  • the UE 301 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 0, 8 to 10 and 11.
  • the UE 301 may perform at least one of steps 0, 8 to 10 and 11 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the IoT Device 302 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least step 11.
  • the IoT Device 302 may perform at least step 11 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the RAN 5 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 7 and 8.
  • the RAN 5 may perform at least one of steps 7 and 8 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the AMF 70 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 6, 7, 9 and 10.
  • the AMF 70 may perform at least one of steps 6, 7, 9 and 10 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the UDM 75 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 4 and 5.
  • the UDM 75 may perform at least one of steps 4 and 5 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the NEF 79 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 2 to 6.
  • the NEF 79 may perform at least one of steps 2 to 6 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the AF 201 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1, 2 and 11.
  • the AF 201 may perform at least one of steps 1, 2 and 11 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the ambient IoT devices may be registered with the UDM 75 with an identity which is the UE identity (e.g. SUPI) plus a short extra identity or tag to identify the ambient IoT device connected to the UE 301 i.e. the ambient IoT device that has registered via that UE 301.
  • the UDM 75 would maintain the relation between the UE 301's GPSI and its 3GPP identity assigned during the initial registration of the ambient IoT device when the UE 301 provides the ambient IoT device's GPSI to the UDM 75.
  • the UDM 75 may retrieve the 3GPP internal identity for this ambient IoT device (e.g. SUPI plus the tag) using its GPSI provided by the NEF 79, and from step 5 in Fig. 21 may forward the IoT device's 3GPP identity (e.g. SUPI plus the tag).
  • the ambient IoT device's 3GPP identity may be used to page the ambient IoT device.
  • the paged UE 301 may use the ambient IoT device's 3GPP identity (e.g.
  • the UE 301 may maintain the relation between the ambient IoT device's GPSI and its 3GPP identity after the initial registration that the UDM 75 assigned the 3GPP internal identity (e.g. SUPI plus the tag) for the registering ambient IoT device).
  • the UDM 75 assigned the 3GPP internal identity (e.g. SUPI plus the tag) for the registering ambient IoT device).
  • Fig. 22 includes an example of the Ambient IoT device-initiated Service Activation procedure.
  • Step 0. The UE 301 is registered to the AMF 70 and a dedicated PDU Session for the Ambient IoT service has been established with the SMF 71 and the UPF 72.
  • the step 0 may be same to step 0 in Fig. 19.
  • Step 1 The IoT Device 302 has enough energy to communicate with the UE 301 and buffers MO-data to the AF 201 as the Ambient IoT Server. Then, the IoT Device 302 establishes a connection with the UE 301 over the Ambient IoT dedicated air interface and sends the MO-data to the UE 301.
  • Step 2 Step 2
  • Step 2 Step 2
  • Step 2 Step 2
  • Step 2 Step 2
  • Step 2 Step 2
  • Step 2 Step 2
  • Step 2 Step 2
  • Step 2 Step 2
  • Step 2 Step 2
  • Step 2 Step 2
  • Step 2 Step 2
  • Step 2 Step 2
  • Step 2 Step 2
  • Step 2 Step 2
  • Step 2 Step 2
  • Step 2 Step 2
  • Step 2 Step 2
  • Step 2 Step 2
  • Step 2 Step 2
  • the "UE 3" is replaced with the "UE 301"
  • the "RAN 501" is replaced with the "RAN 5"
  • the UE 301 receives the MT-data from the AMF 70, the UE 301 may send the MT-data to the IoT Device 302.
  • the UE 301 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 0 to 2.
  • the UE 301 may perform at least one of steps 0 to 2 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the IoT Device 302 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least step 1.
  • the UE 301 may perform at least step 1 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • At least one of disclosure(s) in First Aspect can solve the problem that as the current 5G system does not support the automated warehouse inventory scenario, 3GPP operators may lose business opportunities for goods managements using the Ambient IoT devices.
  • At least one of disclosure(s) in First Aspect can solve the problem that as the current 5G system supports neither Manual-Triggered Mode nor Auto-Triggered Mode, 3GPP operators may lose business opportunities for goods managements using the Ambient IoT devices.
  • This aspect includes an architecture and mechanisms to realize the air interface between the IoT Device and network.
  • the Ambient IoT devices may be characterized according to their energy storage capacity, and capability of generating RF signals for their transmissions.
  • Storage capacity 1 No storage at all Storage capacity 2: Up to E1 Joules
  • Storage capacity 3 Up to E2 Joules
  • One Ambient IoT Service represented by Service, Service ID or TMGI
  • Service ID or TMGI may work with multiple Ambient IoT devices that has different energy storage capacity.
  • One Ambient IoT Service represented by Service, Service ID or TMGI
  • TMGI may work with multiple Ambient IoT devices that support different Ambient IoT air interface standard.
  • One Ambient IoT Service represented by Service, Service ID or TMGI, may work among multiple PLMNs including NPN.
  • Fig. 23 includes an example of an Overall network model supporting multiple Ambient IoT devices taking the above-mentioned air interface into account.
  • Fig. 24 includes an RFID standard that can be considered as a candidate to the Ambient IoT communication.
  • Fig. 25 includes an example of an independent air interface architecture that supports Ambient IoT service.
  • the independent air interface architecture can be characterized with the following points: ⁇ The Ambient IoT device 1 and 3GPP defined UE 3 are combined.
  • An Interface 1 is used for communication between the Ambient IoT device 1 and 3GPP defined UE 3.
  • at least one of the Ambient IoT device 1 and 3GPP defined UE 3 may be the UE 3, UE 301, IoT Device 302 etc in the First Aspect.
  • the combined Ambient IoT device 1 and 3GPP defined UE 3 may be the UE 3, UE 301, IoT Device 302 etc in the First Aspect.
  • at least one of the Ambient IoT device 1 and 3GPP defined UE 3 may be expressed as the terminal node.
  • the combined Ambient IoT device 1 and 3GPP defined UE 3 may be expressed as the terminal node.
  • the Ambient IoT AP (Access Point) 1 and 3GPP defined logical node 1 are combined.
  • An Interface 2 is used for communication between the Ambient IoT AP (Access Point) 1 and 3GPP defined logical node 1.
  • 3GPP defined logical node 1 may be the Radio Cell 502 or the RAN 501 for the First scenario in First example of the First Aspect.
  • 3GPP defined logical node 1 may be the UE-to-Network Relay UE 303 for the First scenario in Second example of the First Aspect.
  • 3GPP defined logical node 1 may be the IAB Node 502 for the Third example of the First Aspect.
  • at least one of the Ambient IoT AP 1 and 3GPP defined logical node 1 may be the Radio Cell 502, RAN 501, UE-to-Network Relay UE 303, RAN 5, IAB Node 502, IAB donor 501, UE 301 etc in the First Aspect.
  • at least one of the Ambient IoT AP 1 and the 3GPP defined logical node 1 may be expressed as the network node.
  • the combined Ambient IoT AP 1 and the 3GPP defined logical node 1 may be expressed as the network node.
  • the combined Ambient IoT AP 1 and 3GPP defined logical node 1 may be the Radio Cell 502, RAN 501, UE-to-Network Relay UE 303, RAN 5, IAB Node 502, IAB donor 501, UE 301 etc in the First Aspect.
  • at least one of the Ambient IoT AP 1 and 3GPP defined logical node 1 may be expressed as the network node.
  • the combined Ambient IoT AP 1 and the 3GPP defined logical node 1 may be expressed as the network node.
  • the Uu interface may be a PC 5 interface for the Second example of the First Aspect.
  • the Uu interface may be a F1-AP interface for the Third example of the First Aspect (e.g. an interface between the IAB Node 50201 and the IAB donor 501 in Fig. 14).
  • Fig. 26 includes an example of the Ambient IoT Service Activation procedure between the Terminal node and Network node.
  • Step 1 The 3GPP defined logical node 1 receives the Service activation request message including at least one of TMGI and Ambient IoT profile from a 3GPP network.
  • the Ambient IoT profile may be referred by the 3GPP defined logical node 1 for determining whether the Ambient IoT AP 1 supports the Ambient IoT communication as indicated in the Ambient IoT profile. For example, at least one of a Frequency band and Air interface in the received Ambient IoT profile is not supported by the Ambient IoT AP 1, the 3GPP defined logical node 1 stops the process as there is no change to activate the Ambient IoT Service.
  • the 3GPP defined logical node 1 may stop the process (e.g. the 3GPP defined logical node 1 may not proceed step 2).
  • step 1 in Fig. 26 may be or may correspond to step 1-1 in Fig. 5.
  • the AF 201 may send the Ambient IoT profile regarding the Ambient IoT AP 1 or the Ambient IoT Device 1.
  • step 1 in Fig. 26 may be or may correspond to at least one of steps 1 to 7 in Fig. 8.
  • the Ambient IoT profile regarding the Ambient IoT AP 1 or the Ambient IoT Device 1 may be included in the parameter(s) that the each node communicates.
  • step 1 in Fig. 26 may be or may correspond to step 3 in Fig. 12.
  • the AF 201 may send the Ambient IoT profile regarding the Ambient IoT AP 1 or the Ambient IoT Device 1.
  • step 1 in Fig. 26 may be or may correspond to step 1 in Fig. 13.
  • the AF 201 may send the Ambient IoT profile regarding the Ambient IoT AP 1 or the Ambient IoT Device 1.
  • step 1 in Fig. 26 may be or may correspond to step 1-1 in Fig. 19.
  • the AF 201 may send the Ambient IoT profile regarding the Ambient IoT AP 1 or the Ambient IoT Device 1.
  • step 1 in Fig. 26 may be or may correspond to at least one of steps 1 to 7 in Fig. 21.
  • the Ambient IoT profile regarding the Ambient IoT AP 1 or the Ambient IoT Device 1 may be included in the parameter(s) that the each node communicates.
  • the above-mentioned parameter(s) in step 1 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 2 The 3GPP defined logical node 1 sends the Service activation request message to the Ambient IoT AP 1 including at least one of the TMGI and Ambient IoT profile over the Interface 2.
  • the communication in step 2 may be performed on an internal interface.
  • the above-mentioned parameter(s) in step 2 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • the Ambient IoT AP 1 broadcasts a Service activation message with the TMGI.
  • the Ambient IoT AP 1 may broadcast a Service activation message including at least the TMGI.
  • the Service activation message over the Ambient IoT interface may include a function of a Wireless Power Transfer (WPT) to feed an Energy to the Ambient IoT Device 1.
  • WPT Wireless Power Transfer
  • the Security parameter in the received Ambient IoT profile may be used by the Ambient IoT AP 1 and the Ambient IoT Device 1 for mutual or Ambient IoT device authentication and authorization.
  • the Security parameter in the Ambient IoT profile may be used by the Ambient IoT AP 1 and the Ambient IoT Device 1 for integrity protection and confidentiality protection for the Ambient IoT communication over the Ambient IoT interface.
  • the Ambient IoT profile may be referred by the Ambient IoT AP 1 for determining whether the Ambient IoT AP 1 supports the Ambient IoT communication as indicated in the Ambient IoT profile.
  • the Ambient IoT AP 1 may broadcast the Service activation message only on Frequency bands that are indicated in the received Ambient IoT profile.
  • the above-mentioned parameter(s) in step 3 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • step 3 in Fig. 26 may be or may correspond to at least one of steps 1-2 and 2 in Fig. 5.
  • step 3 in Fig. 26 may be or may correspond to step 9 in Fig. 8.
  • step 3 in Fig. 26 may be or may correspond to step 2-2 in Fig. 13.
  • the TMGI may not be included in the signal in step 2-2.
  • step 3 in Fig. 26 may be or may correspond to at least one of steps 1-2 and 2 in Fig. 19.
  • step 3 in Fig. 26 may be or may correspond to step 6-1 in Fig. 20.
  • step 3 in Fig. 26 may be or may correspond to step 11 in Fig. 21.
  • Step 4 In a case where the Ambient IoT Device 1 does not have any power supply, the Ambient IoT Device 1 harvests an energy from the radio signal in step 3.
  • a buttery or capacitor for energy saving and power supply may be common for both Ambient IoT Device 1 and the 3GPP defined UE 3.
  • Step 5 Upon reception of the Service activation request message in step 1, the 3GPP defined logical node 1 sends the Page message (in a case where the 3GPP defined UE 3 is in Idle state) or sends the Service Notification message (in a case where the 3GPP defined UE 3 is in Active state) to the 3GPP defined UE 3 including the TMGI.
  • the above-mentioned parameter(s) in step 5 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • the above-mentioned parameter(s) in step 5 may be expressed as parameter(s) or data or information for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • step 5 in Fig. 26 may be or may correspond to at least one of steps 1-2 and 2 in Fig. 5.
  • step 5 in Fig. 26 may be or may correspond to step 9 in Fig. 8.
  • step 5 in Fig. 26 may be or may correspond to step 2-2 in Fig. 13.
  • the TMGI may not be included in the signal in step 2-2.
  • step 5 in Fig. 26 may be or may correspond to at least one of steps 1-2 and 2 in Fig. 19.
  • step 5 in Fig. 26 may be or may correspond to step 6-1 in Fig. 20.
  • step 5 in Fig. 26 may be or may correspond to step 11 in Fig. 21.
  • Step 6 Upon reception of the Page message or Service Notification message in Step 5, the 3GPP defined UE 3 sends the IoT data request message to the Ambient IoT Device 1 for requesting the Ambient IoT data for the Ambient IoT service that corresponds to the TMGI over the Interface 1.
  • Step 7 The Ambient IoT Device 1 collects the Ambient IoT data (e.g. MO-data) for the Ambient IoT service that corresponds to the TMGI and sends it to the 3GPP defined UE 3.
  • the Ambient IoT data e.g. MO-data
  • Step 8 The 3GPP defined UE 3 sends the Service Request message to the 3GPP defined logical node 1 including the MO-data.
  • the Service Request message may be a new or existing NAS message or a new or existing AS message.
  • the above-mentioned parameter(s) in step 8 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • the above-mentioned parameter(s) in step 8 may be expressed as parameter(s) or data or information for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • step 8 in Fig. 26 may be or may correspond to step 5 in Fig. 5.
  • the 3GPP defined UE 3 may send the Registration Request message including the MO-data to the 3GPP defined logical node 1.
  • step 8 in Fig. 26 may be or may correspond to step 10 in Fig. 8.
  • the 3GPP defined UE 3 may send the Control Plane Service Request message including the MO-data to the 3GPP defined logical node 1.
  • step 8 in Fig. 26 may be or may correspond to step 4 in Fig. 13.
  • the 3GPP defined UE 3 may send the Group Member Discovery Response message including the MO-data to the 3GPP defined logical node 1.
  • step 8 in Fig. 26 may be or may correspond to step 5 in Fig. 19.
  • the 3GPP defined UE 3 may send the Registration Request message including the MO-data to the 3GPP defined logical node 1.
  • step 8 in Fig. 26 may be or may correspond to step 6-1 in Fig. 20.
  • the 3GPP defined UE 3 may send the MO-data to the 3GPP defined logical node 1.
  • step 8 in Fig. 26 may be or may correspond to step 11 in Fig. 21.
  • the 3GPP defined UE 3 may send the MO-data to the 3GPP defined logical node 1.
  • Step 9 Upon reception of the MO-data from the 3GPP defined UE 3, the 3GPP defined logical node 1 sends the Service Request message including the MO-data to the 3GPP network.
  • the Service Request message may be a new or existing NAS message or a new or existing AS message.
  • the above-mentioned parameter(s) in step 9 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • the above-mentioned parameter(s) in step 9 may be expressed as parameter(s) or data or information for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • step 9 in Fig. 26 may be or may correspond to step 6 in Fig. 5.
  • the 3GPP logical node 1 may send the Registration Request message including the MO-data to the 3GPP network (e.g. the AMF 70 etc).
  • step 9 in Fig. 26 may be or may correspond to step 11 in Fig. 8.
  • the 3GPP logical node 1 may send the Control Plane Service Request message including the MO-data to the 3GPP network (e.g. the AMF 70 etc).
  • step 9 in Fig. 26 may be or may correspond to step 5 in Fig. 13.
  • the 3GPP logical node 1 may send the MO-data to the 3GPP network (or to the AF 201).
  • step 9 in Fig. 26 may be or may correspond to step 5 or 6 in Fig. 19.
  • the 3GPP logical node 1 may send the Registration Request message including the MO-data to the 3GPP network (e.g. the RAN 5, the AMF 70 etc).
  • step 9 in Fig. 26 may be or may correspond to step 6-2 in Fig. 20.
  • the 3GPP logical node 1 may send the MO-data to the 3GPP network (or to the AF 201).
  • step 9 in Fig. 26 may be or may correspond to step 11 in Fig. 21.
  • the 3GPP logical node 1 may send the MO-data to the 3GPP network (or to the AF 201).
  • the Ambient IoT data (e.g. MT-data) for the Ambient IoT service may be sent to the Ambient IoT Device 1 in the same manner as the process(es) in Fig. 26.
  • the 3GPP defined logical node 1 may send the MT-data to the Ambient IoT AP 1 (e.g. the 3GPP defined logical node 1 may send a message including at least one of the TMGI, Ambient IoT profile and MT-data to the Ambient IoT AP 1).
  • the Ambient IoT AP 1 may perform the process(es) in step 3, and the Ambient IoT Device 1 may perform the process(es) in step 4.
  • the 3GPP defined logical node 1 may send the Page message or the Service Notification message to the 3GPP defined UE 3 including at least one of the TMGI and MT-data.
  • the 3GPP defined UE 3 may send the MT-data to the Ambient IoT Device 1.
  • the 3GPP defined logical node 1 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1, 2, 8 and 9.
  • the 3GPP defined logical node 1 may perform at least one of steps 1, 2, 8 and 9 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the Ambient IoT AP 1 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 2 and 3.
  • the Ambient IoT AP 1 may perform at least one of steps 2 and 3 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the Ambient IoT Device 1 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 3, 4, 6 and 7.
  • the Ambient IoT Device 1 may perform at least one of steps 3, 4, 6 and 7 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the 3GPP defined UE 3 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 5 to 8.
  • the 3GPP defined UE 3 may perform at least one of steps 5 to 8 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • Fig. 27 includes an example of a converged air interface architecture that supports Ambient IoT service.
  • the converged air interface architecture can be characterized with the following points: ⁇ The Ambient IoT device 1 and 3GPP defined UE 3 are combined.
  • An Interface 1 is used for communication between the Ambient IoT device 1 and 3GPP defined UE 3.
  • at least one of the Ambient IoT device 1 and 3GPP defined UE 3 may be the UE 3, UE 301, IoT Device 302 etc in the First Aspect.
  • the combined Ambient IoT device 1 and 3GPP defined UE 3 may be the UE 3, UE 301, IoT Device 302 etc in the First Aspect.
  • at least one of the Ambient IoT device 1 and 3GPP defined UE 3 may be expressed as the terminal node.
  • the combined Ambient IoT device 1 and 3GPP defined UE 3 may be expressed as the terminal node.
  • the 3GPP defined logical node 1 may be a radio cell for the 3GPP access technology.
  • 3GPP defined logical node 1 may be the Radio Cell 502 or the RAN 501 for the First scenario in First example of the First Aspect.
  • 3GPP defined logical node 1 may be the UE-to-Network Relay UE 303 for the First scenario in Second example of the First Aspect.
  • 3GPP defined logical node 1 may be the IAB Node 502 for the Third example of the First Aspect.
  • the 3GPP defined logical node 1 may be the Radio Cell 502, RAN 501, UE-to-Network Relay UE 303, RAN 5, IAB Node 502, IAB donor 501, UE 301 etc in the First Aspect.
  • the 3GPP defined logical node may be expressed as the network node.
  • the Uu interface may be a PC 5 interface for the Second example of the First Aspect.
  • the Uu interface may be a F1-AP interface for the Third example of the First Aspect (e.g. an interface between the IAB Node 50201 and the IAB donor 501 in Fig. 14).
  • Fig. 28 includes an example of the Ambient IoT Service Activation procedure between Terminal node and Network node.
  • Step 1 The 3GPP defined logical node 1 receives the Service activation request message including at least one of TMGI and Ambient IoT profile from a 3GPP network.
  • the Ambient IoT profile may be referred by the 3GPP defined logical node 1 for determining whether the Ambient IoT AP 1 supports the Ambient IoT communication as indicated in the Ambient IoT profile. For example, at least one of a Frequency band and Air interface in the received Ambient IoT profile is not supported by the Ambient IoT AP 1, the 3GPP defined logical node 1 stop the process as there is no change to activate the Ambient IoT Service.
  • Step 1 may be same to step 1 in Fig. 26.
  • the above-mentioned parameter(s) in step 1 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • the 3GPP defined logical node 1 broadcasts a Service activation message with the TMGI.
  • the 3GPP defined logical node 1 may broadcast a Service activation message including at least the TMGI.
  • the Service activation message over the Uu interface may include a function of a Wireless Power Transfer (WPT) to feed an Energy to the Ambient IoT Device 1.
  • WPT Wireless Power Transfer
  • the Security parameter in the received Ambient IoT profile may be used by the3GPP defined logical node 1 and the Ambient IoT Device 1 for mutual or Ambient IoT device authentication and authorization.
  • the Security parameter in the Ambient IoT profile may be used by the 3GPP defined logical node 1 and the Ambient IoT Device 1 for integrity protection and confidentiality protection for the Ambient IoT communication over the Uu interface.
  • the Ambient IoT air interface in the Uu interface may be new 3GPP defined physical interface with the following characteristics: New or existing BCCH may be used for an Ambient IoT communication related data (I.e., TMGI) distribution.
  • New physical channel is defined for the function of a Wireless Power Transfer (WPT).
  • New physical channel for the function of a Wireless Power Transfer (WPT) may be called as Power Physical Channel (PoP-CH, or PP-CH), Downlink Shared Power Physical Channel (DSPoP-CH or DSPP-CH).
  • the above-mentioned parameter(s) in step 2 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • the Ambient IoT profile may be referred by the 3GPP defined logical node 1 for determining whether the 3GPP defined logical node 1 supports the Ambient IoT communication as indicated in the Ambient IoT profile.
  • the 3GPP defined logical node 1 broadcasts the Service activation message only to Frequency bands that are indicated in the received Ambient IoT profile.
  • the above-mentioned parameter(s) in step 2 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • step 2 in Fig. 28 may be or may correspond to at least one of steps 1-2 and 2 in Fig. 5.
  • step 2 in Fig. 28 may be or may correspond to step 9 in Fig. 8.
  • step 2 in Fig. 28 may be or may correspond to step 2-2 in Fig. 13.
  • the TMGI may not be included in the signal in step 2-2.
  • step 2 in Fig. 28 may be or may correspond to at least one of steps 1-2 and 2 in Fig. 19.
  • step 2 in Fig. 28 may be or may correspond to step 6-1 in Fig. 20.
  • step 2 in Fig. 28 may be or may correspond to step 11 in Fig. 21.
  • Step 3 In case the Ambient IoT Device 1 does not have any power supply, the Ambient IoT Device 1 harvests an energy from the radio signal in step 2.
  • a buttery or capacitor for energy saving and power supply may be common for both Ambient IoT Device 1 and the 3GPP defined UE 3.
  • Step 4 Steps 5 to 9 in Fig. 26 take place.
  • the 3GPP defined logical node 1 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1, 2, and 4.
  • the 3GPP defined logical node 1 may perform at least one of steps 1, 2, and 4 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the Ambient IoT Device 1 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 2 and 4.
  • the Ambient IoT Device 1 may perform at least one of steps 2 and 4 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the 3GPP defined UE 3 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least step 4.
  • the 3GPP defined UE 3 may perform at least step 4 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • Fig. 29 includes an example that an Ambient IoT air interface is deployed in the UE 3 as the personal network of the UE 3 to support Ambient IoT service.
  • the Ambient IoT air interface which is deployed in the UE as the personal network can be characterized with the following points: ⁇ The Ambient IoT device 1 and Ambient IoT AP 1 are deployed in the personal network of the UE 3.
  • the Ambient IoT device 1 may be the UE 3, UE 301, IoT Device 302 etc in the First Aspect.
  • the Ambient IoT device 1 may be expressed as the terminal node.
  • the Ambient IoT air interface is used for communication between the Ambient IoT Device 1 and Ambient IoT AP 1.
  • the Ambient IoT AP 1 and 3GPP defined UE 3 may be combined.
  • An Interface 2 is used for communication between the Ambient IoT AP 1 and 3GPP defined logical node 1.
  • At least one of the Ambient IoT AP 1 and 3GPP defined UE 3 may be the Radio Cell 502, RAN 501, UE-to-Network Relay UE 303, RAN 5, IAB Node 502, IAB donor 501, UE 301 etc in the First Aspect.
  • the combined Ambient IoT AP 1 and the 3GPP defined UE 3 may be the Radio Cell 502, RAN 501, UE-to-Network Relay UE 303, RAN 5, IAB Node 502, IAB donor 501, UE 301 etc in the First Aspect.
  • At least one of the Ambient IoT AP 1 and the 3GPP defined logical node 1 may be expressed as the network node.
  • the combined Ambient IoT AP 1 and the 3GPP defined logical node 1 may be expressed as the network node.
  • the RAN may be the RAN 5, RAN 501, IAB donor 501 etc in the First Aspect.
  • Fig. 30 includes an example of the Ambient IoT Service Activation procedure between IoT Device and UE.
  • Step 1 The 3GPP defined UE 3 receives the Service activation request message including at least one of TMGI and Ambient IoT profile from a 3GPP network.
  • the Ambient IoT profile may be referred by the 3GPP defined UE 3 for determining whether the Ambient IoT AP 1 supports the Ambient IoT communication as indicated in the Ambient IoT profile. For example, at least one of a Frequency band and Air interface in the received Ambient IoT profile is not supported by the Ambient IoT AP 1, the 3GPP defined UE 3 stops the process as there is no change to activate the Ambient IoT Service.
  • the 3GPP defined UE 3 may stop the process (e.g. the 3GPP defined UE 3 may not proceed step 2).
  • step 1 in Fig. 30 may be or may correspond to step 1-1 in Fig. 5.
  • the AF 201 may send the Ambient IoT profile regarding the Ambient IoT AP 1 or the Ambient IoT Device 1.
  • step 1 in Fig. 30 may be or may correspond to at least one of steps 1 to 7 in Fig. 8.
  • the Ambient IoT profile regarding the Ambient IoT AP 1 or the Ambient IoT Device 1 may be included in the parameter(s) that the each node communicates.
  • step 1 in Fig. 30 may be or may correspond to step 3 in Fig. 12.
  • the AF 201 may send the Ambient IoT profile regarding the Ambient IoT AP 1 or the Ambient IoT Device 1.
  • step 1 in Fig. 30 may be or may correspond to step 1 in Fig. 13.
  • the AF 201 may send the Ambient IoT profile regarding the Ambient IoT AP 1 or the Ambient IoT Device 1.
  • step 1 in Fig. 30 may be or may correspond to step 1-1 in Fig. 19.
  • the AF 201 may send the Ambient IoT profile regarding the Ambient IoT AP 1 or the Ambient IoT Device 1.
  • step 1 in Fig. 30 may be or may correspond to at least one of steps 1 to 7 in Fig. 21.
  • the Ambient IoT profile regarding the Ambient IoT AP 1 or the Ambient IoT Device 1 may be included in the parameter(s) that the each node communicates.
  • the above-mentioned parameter(s) in step 1 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 2 The 3GPP defined UE 3 sends the Service activation request message to the Ambient IoT AP 1 including at least one of the TMGI and Ambient IoT profile over the Interface 2.
  • the communication in step 2 may be performed on an internal interface.
  • the above-mentioned parameter(s) in step 2 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • the Ambient IoT AP 1 broadcasts a Service activation message with the TMGI.
  • the Ambient IoT AP 1 may broadcast a Service activation message including at least the TMGI.
  • the Service activation message over the Ambient IoT interface may include a function of a Wireless Power Transfer (WPT) to feed an Energy to the Ambient IoT Device 1.
  • WPT Wireless Power Transfer
  • the Security parameter in the received Ambient IoT profile may be used by the Ambient IoT AP 1 and the Ambient IoT Device 1 for mutual or Ambient IoT device authentication and authorization.
  • the Security parameter in the Ambient IoT profile may be used by the Ambient IoT AP 1 and the Ambient IoT Device 1 for integrity protection and confidentiality protection for the Ambient IoT communication over the Ambient IoT interface.
  • the Ambient IoT profile may be referred by the Ambient IoT AP 1 for determining whether the Ambient IoT AP 1 supports the Ambient IoT communication as indicated in the Ambient IoT profile.
  • the Ambient IoT AP 1 may broadcast the Service activation message only on Frequency bands that are indicated in the received Ambient IoT profile.
  • the above-mentioned parameter(s) in step 3 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • step 3 in Fig. 30 may be or may correspond to at least one of steps 1-2 and 2 in Fig. 5.
  • step 3 in Fig. 30 may be or may correspond to step 9 in Fig. 8.
  • step 3 in Fig. 30 may be or may correspond to step 2-2 in Fig. 13.
  • the TMGI may not be included in the signal in step 2-2.
  • step 3 in Fig. 30 may be or may correspond to at least one of steps 1-2 and 2 in Fig. 19.
  • step 3 in Fig. 30 may be or may correspond to step 6-1 in Fig. 20.
  • step 3 in Fig. 30 may be or may correspond to step 11 in Fig. 21.
  • Step 4 In a case where the Ambient IoT Device 1 does not have any power supply, the Ambient IoT Device 1 harvests an energy from the radio signal in step 3.
  • Step 5 Requested data collection is performed over the Ambient IoT interface between the Ambient IoT Device 1 and Ambient IoT AP 1.
  • the Ambient IoT AP 1 upon reception of the Service activation request message in Step 2, the Ambient IoT AP 1 sends the IoT data request message to the Ambient IoT Device 1 for requesting the Ambient IoT data (e.g. MO-data) for the Ambient IoT service that corresponds to the TMGI over the Ambient IoT air interface. Then the Ambient IoT Device 1 may send the MO-data to the Ambient IoT AP 1.
  • the Ambient IoT data e.g. MO-data
  • the Ambient IoT AP 1 may collect the Ambient IoT data (e.g. MO-data) for the Ambient IoT service that corresponds to the TMGI from the Ambient IoT Device 1.
  • the Ambient IoT data e.g. MO-data
  • step 5 in Fig. 30 may be or may correspond to step 5 in Fig. 5.
  • the Ambient IoT Device 1 may send the Registration Request message including the MO-data to the Ambient IoT AP 1.
  • step 5 in Fig. 30 may be or may correspond to step 10 in Fig. 8.
  • the Ambient IoT Device 1 may send the Control Plane Service Request message including the MO-data to the Ambient IoT AP 1.
  • step 5 in Fig. 30 may be or may correspond to step 4 in Fig. 13.
  • the Ambient IoT Device 1 may send the Group Member Discovery Response message including the MO-data to the Ambient IoT AP 1.
  • step 5 in Fig. 30 may be or may correspond to step 5 in Fig. 19.
  • the Ambient IoT Device 1 may send the Registration Request message including the MO-data to the Ambient IoT AP 1.
  • step 5 in Fig. 30 may be or may correspond to step 6-1 in Fig. 20.
  • the Ambient IoT Device 1 may send the MO-data to the Ambient IoT AP 1.
  • step 5 in Fig. 30 may be or may correspond to step 11 in Fig. 21.
  • the Ambient IoT Device 1 may send the MO-data to the Ambient IoT AP 1.
  • the above-mentioned parameter(s) in step 5 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • the above-mentioned parameter(s) in step 5 may be expressed as parameter(s) or data or information for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 6 After the Ambient IoT AP 1 receives the Requested data (e.g. the MO-data) from the Ambient IoT Device 1, the Ambient IoT AP 1 sends the Service Request message to the 3GPP defined UE 3 including the MO-data.
  • the Requested data e.g. the MO-data
  • the Ambient IoT AP 1 sends the Service Request message to the 3GPP defined UE 3 including the MO-data.
  • the Service Request message may be a new or existing NAS message or a new or existing AS message.
  • the above-mentioned parameter(s) in step 6 may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • the above-mentioned parameter(s) in step 6 may be expressed as parameter(s) or data or information for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
  • Step 7 Upon reception of the MO-data from the Ambient IoT AP 1, the 3GPP defined UE 3 sends the Service Request message including MT-data to the 3GPP network.
  • the Service Request message may be a new or existing NAS message or a new or existing AS message.
  • step 7 in Fig. 30 may be or may correspond to step 6 in Fig. 5.
  • the 3GPP defined UE 3 may send the Registration Request message including the MO-data to the 3GPP network (e.g. the AMF 70 etc).
  • step 7 in Fig. 30 may be or may correspond to step 11 in Fig. 8.
  • the 3GPP defined UE 3 may send the Control Plane Service Request message including the MO-data to the 3GPP network (e.g. the AMF 70 etc).
  • step 7 in Fig. 30 may be or may correspond to step 5 in Fig. 13.
  • the 3GPP defined UE 3 may send the MO-data to the 3GPP network (or to the AF 201).
  • step 7 in Fig. 30 may be or may correspond to step 5 or 6 in Fig. 19.
  • the 3GPP defined UE 3 may send the Registration Request message including the MO-data to the 3GPP network (e.g. the RAN 5, the AMF 70 etc).
  • step 7 in Fig. 30 may be or may correspond to step 6-2 in Fig. 20.
  • the 3GPP defined UE 3 may send the MO-data to the 3GPP network (or to the AF 201).
  • step 7 in Fig. 30 may be or may correspond to step 11 in Fig. 21.
  • the 3GPP defined UE 3 may send the MO-data to the 3GPP network (or to the AF 201).
  • the Ambient IoT data (e.g. MT-data) for the Ambient IoT service may be sent to the Ambient IoT Device 1 in the same manner as the process(es) in Fig. 30.
  • the 3GPP defined UE 3 may send the MT-data to the Ambient IoT AP 1 (e.g. the 3GPP defined UE 3 may send a message including at least one of the TMGI, Ambient IoT profile and MT-data to the Ambient IoT AP 1).
  • the Ambient IoT AP 1 may perform the process(es) in step 3, and the Ambient IoT Device 1 may perform the process(es) in step 4. Then the Ambient IoT AP 1 may send the MT-data to the Ambient IoT Device 1.
  • the 3GPP defined UE 3 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1, 2, 6 and 7.
  • the 3GPP defined UE 3 may perform at least one of steps 1, 2, 6 and 7 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the Ambient IoT AP 1 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 2, 3, 5 and 6.
  • the Ambient IoT AP 1 may perform at least one of steps 2, 3, 5 and 6 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • the Ambient IoT Device 1 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 3 to 5.
  • the Ambient IoT Device 1 may perform at least one of steps 3 to 5 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
  • At least one of disclosure(s) in Second Aspect can solve the problem that as the current 5G system does not support the automated warehouse inventory scenario, 3GPP operators may lose business opportunities for goods managements using the Ambient IoT devices.
  • At least one of disclosure(s) in Second Aspect can solve the problem that as the current 5G system supports neither Manual-Triggered Mode nor Auto-Triggered Mode, 3GPP operators may lose business opportunities for goods managements using the Ambient IoT devices.
  • Fig. 31 schematically illustrates a telecommunication system 1 for a mobile (cellular or wireless) to which the above aspects are applicable.
  • the telecommunication system 1 represents a system overview in which an end-to-end communication is possible.
  • UE 3 or user equipment, 'mobile device' 3
  • the (R)AN node 5 supports any radio accesses including a 5G radio access technology (RAT), an E-UTRA radio access technology, a beyond 5G RAT, a 6G RAT and non-3GPP RAT including wireless local area network (WLAN) technology as defined by the Institute of Electrical and Electronics Engineers (IEEE).
  • RAT 5G radio access technology
  • E-UTRA E-UTRA
  • WLAN wireless local area network
  • the (R)AN node 5 may split into a Radio Unit (RU), Distributed Unit (DU) and Centralized Unit (CU).
  • each of the units may be connected to each other and structure the (R)AN node 5 by adopting an architecture as defined by the Open RAN (O-RAN) Alliance, where the units above are referred to as O-RU, O-DU and O-CU respectively.
  • O-RAN Open RAN
  • the (R)AN node 5 may be split into control plane function and user plane function. Further, multiple user plane functions can be allocated to support a communication. In some aspects, user traffic may be distributed to multiple user plane functions and user traffic over each user plane functions are aggregated in both the UE 3 and the (R)AN node 5. This split architecture may be called as 'dual connectivity' or 'Multi connectivity'.
  • the (R)AN node 5 can also support a communication using the satellite access.
  • the (R)AN node 5 may support a satellite access and a terrestrial access.
  • the (R)AN node 5 can also be referred as an access node for a non-wireless access.
  • the non-wireless access includes a fixed line access as defined by the Broadband Forum (BBF) and an optical access as defined by the innovative Optical and Wireless Network (IOWN).
  • BBF Broadband Forum
  • IOWN innovative Optical and Wireless Network
  • the core network 7 may include logical nodes (or 'functions') for supporting a communication in the telecommunication system 1.
  • the core network 7 may be 5G Core Network (5GC) that includes, amongst other functions, control plane functions and user plane functions.
  • 5GC 5G Core Network
  • Each function in logical nodes can be considered as a network function.
  • the network function may be provided to another node by adapting the Service Based Architecture (SBA).
  • SBA Service Based Architecture
  • a Network Function can be deployed as distributed, redundant, stateless, and scalable that provides the services from several locations and several execution instances in each location by adapting the network virtualization technology as defined by the European Telecommunications Standards Institute, Network Functions Virtualization (ETSI NFV).
  • ETSI NFV European Telecommunications Standards Institute, Network Functions Virtualization
  • the core network 7 may support the Non-Public Network (NPN).
  • NPN Non-Public Network
  • the NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
  • SNPN Stand-alone Non-Public Network
  • PNI-NPN Public Network Integrated NPN
  • a UE 3 may enter and leave the areas (i.e. radio cells) served by the (R)AN node 5 as the UE 3 is moving around in the geographical area covered by the telecommunication system 1.
  • the core network 7 comprises at least one access and mobility management function (AMF) 70.
  • the AMF 70 is in communication with the (R)AN node 5 coupled to the core network 7.
  • a mobility management entity (MME) or a mobility management node for beyond 5G or a mobility management node for 6G may be used instead of the AMF 70.
  • the core network 7 also includes, amongst others, a Session Management Function (SMF) 71, a User Plane Function (UPF) 72, a Policy Control Function (PCF) 73, a Network Data Analytics Function (NWDAF) 74, a Unified Data Management (UDM) 75, a Network Slice Selection Function (NSSF) 76, a Network Slice Admission Control Function (NSACF) 77, Authentication Server Function (AUSF) 78 and Network Exposure Function (NEF) 79.
  • SMF Session Management Function
  • UPF User Plane Function
  • PCF Policy Control Function
  • NWDAF Network Data Analytics Function
  • UDM Unified Data Management
  • NSSF Network Slice Selection Function
  • NSACF Network Slice Admission Control Function
  • AUSF Authentication Server Function
  • NEF Network Exposure Function
  • a home Public Land Mobile Network (HPLMN) of the UE 3 provides the UDM 75 and at least some of the functionalities of the SMF 71, UPF 72, PCF 73 and NSACF 77 for the roaming-out UE 3.
  • the UE 3 and a respective serving (R)AN node 5 are connected via an appropriate air interface (for example the so-called “Uu” interface and/or the like).
  • Neighboring (R)AN node 5 are connected to each other via an appropriate (R)AN node 5 to (R)AN node interface (such as the so-called “Xn” interface and/or the like).
  • Each (R)AN node 5 is also connected to nodes in the core network 7 (such as the so-called core network nodes) via an appropriate interface (such as the so-called "N2"/ "N3" interface(s) and/or the like). From the core network 7, connection to a data network 20 is also provided.
  • the data network 20 can be an internet, a public network, an external network, a private network or an internal network of the PLMN.
  • the IP Multimedia Subsystem (IMS) service may be provided by that data network 20.
  • the UE 3 can be connected to the data network 20 using IPv4, IPv6, IPv4v6, Ethernet or unstructured data type.
  • the data network may include an Application Function (AF) 201.
  • AF Application Function
  • the "Uu” interface may include a Control plane of Uu interface and User plane of Uu interface.
  • the User plane of Uu interface is responsible to convey user traffic between the UE 3 and a serving (R)AN node 5.
  • the User plane of Uu interface may have a layered structure with SDAP, PDCP, RLC and MAC sublayer over the physical connection (i.e. PHY sublayer).
  • the Control plane of Uu interface is responsible to establish, modify and release a connection between the UE 3 and a serving (R)AN node 5.
  • the Control plane of Uu interface may have a layered structure with RRC, PDCP, RLC and MAC sublayers over the physical connection.
  • RRC Setup Request message This message is sent from the UE 3 to the (R)AN node 5.
  • RRC Setup Request message This message is sent from the UE 3 to the (R)AN node 5.
  • establishmentCause and ue-Identity The ue-Identity may have a value of ng-5G-S-TMSI-Part1 or randomValue.
  • RRC Setup message This message is sent from the (R)AN node 5 to the UE 3.
  • masterCellGroup and radioBearerConfig This message is sent from the (R)AN node 5 to the UE 3.
  • RRC setup complete message This message is sent from the UE 3 to the (R)AN node 5.
  • RRC setup complete message In addition to the parameters that are disclosed by Aspects in this disclosure, following parameters may be included together in the RRC setup complete message. guami-Type, iab-NodeIndication, idleMeasAvailable, ue-MeasurementsAvailable, mobilityState, ng-5G-S-TMSI-Part2, registeredAMF, selectedPLMN-Identity, s-NSSAI-List , onboardingRequest.
  • the UE 3 and the AMF 70 are connected via an appropriate interface (for example the so-called N1 interface and/or the like).
  • the N1 interface is responsible to provide a communication between the UE 3 and the AMF 70 to support NAS signaling.
  • the N1 interface may be established over a 3GPP access and over a non-3GPP access. For example, the following messages are communicated over the N1 interface.
  • registration request message This message is sent from the UE 3 to the AMF 70.
  • following parameters may be included together in the registration request message.
  • 5GS registration type 5GS registration type, ngKSI, 5GS mobile identity, Non-current native NAS key set identifier, 5GMM capability, UE security capability, Requested NSSAI, Last visited registered TAI, S1 UE network capability, Uplink data status, PDU session status, MICO indication, UE status, Additional GUTI, Allowed PDU session status, UE's usage setting, Requested DRX parameters, EPS NAS message container, LADN indication, Payload container type, Payload container, Network slicing indication, 5GS update type, Mobile station classmark 2, Supported codecs, NAS message container, EPS bearer context status, Requested extended DRX parameters, T3324 value, UE radio capability ID, Requested mapped NSSAI, Additional information requested, Requested WUS assistance information, N5GC indication and Requested NB-N1 mode DRX parameters.
  • Registration accept message This message is sent from the AMF 70 to the UE 3.
  • 5GS registration result 5G-GUTI, Equivalent PLMNs, TAI list, Allowed NSSAI, Rejected NSSAI, Configured NSSAI, 5GS network feature support, PDU session status, PDU session reactivation result, PDU session reactivation result error cause, LADN information, MICO indication, Network slicing indication, Service area list, T3512 value, Non-3GPP de-registration timer value, T3502 value, Emergency number list, Extended emergency number list, SOR transparent container, EAP message, NSSAI inclusion mode, Operator-defined access category definitions, Negotiated DRX parameters, Non-3GPP NW policies, EPS bearer context status, Negotiated extended DRX parameters, T3447 value, T3448 value, T3324 value, UE radio capability ID, UE radio capability ID deletion indication, Pending NSSAI,
  • Registration Complete message This message is sent from the UE 3 to the AMF 70. In addition to the parameters that are disclosed by Aspects in this disclosure, following parameters may be included together in the Registration Complete message. SOR transparent container.
  • Authentication Request message This message is sent from the AMF 70 to the UE 3. In addition to the parameters that are disclosed by Aspects in this disclosure, following parameters may be included together in the Authentication Request message. ngKSI, ABBA, Authentication parameter RAND (5G authentication challenge), Authentication parameter AUTN (5G authentication challenge) and EAP message.
  • Authentication Response message This message is sent from the UE 3 to the AMF 70. In addition to the parameters that are disclosed by Aspects in this disclosure, following parameters may be populated together in the Authentication Response message.
  • Authentication response message identity Authentication response parameter and EAP message.
  • Authentication Result message This message is sent from the AMF 70 to the UE 3. In addition to the parameters that are disclosed by Aspects in this disclosure, following parameters may be populated together in the Authentication Result message. ngKSI, EAP message and ABBA.
  • Authentication Failure message This message is sent from the UE 3 to the AMF 70. In addition to the parameters that are disclosed by Aspects in this disclosure, following parameters may be populated together in the Authentication Failure message. Authentication failure message identity, 5GMM cause and Authentication failure parameter.
  • Authentication Reject message This message is sent from the AMF 70 to the UE 3.
  • Service Request message This message is sent from the UE 3 to the AMF 70.
  • Service Request message This message is sent from the UE 3 to the AMF 70.
  • Service Accept message This message is sent from the AMF 70 to the UE 3.
  • Service Accept message This message is sent from the AMF 70 to the UE 3.
  • Service Accept message This message is sent from the AMF 70 to the UE 3.
  • Service Reject message This message is sent from the AMF 70 to the UE 3. In addition to the parameters that are disclosed by Aspects in this disclosure, following parameters may be populated together in the Service Reject message. 5GMM cause, PDU session status, T3346 value, EAP message, T3448 value and CAG information list.
  • Configuration Update Command message This message is sent from the AMF 70 to the UE 3. In addition to the parameters that are disclosed by Aspects in this disclosure, following parameters may be populated together in the Configuration Update Command message.
  • Configuration update indication 5G-GUTI, TAI list, Allowed NSSAI, Service area list, Full name for network, Short name for network, Local time zone, Universal time and local time zone, Network daylight saving time, LADN information, MICO indication, Network slicing indication, Configured NSSAI, Rejected NSSAI, Operator-defined access category definitions, SMS indication, T3447 value, CAG information list, UE radio capability ID, UE radio capability ID deletion indication, 5GS registration result, Truncated 5G-S-TMSI configuration, Additional configuration indication and Extended rejected NSSAI.
  • Configuration Update Complete message This message is sent from the UE 3 to the AMF 70. In addition to the parameters that are disclosed by Aspects in this disclosure, following parameters may be populated together in the Configuration Update Complete message. Configuration update complete message identity.
  • UE Fig. 32 is a block diagram illustrating the main components of the UE 3 (mobile device 3).
  • the UE 3 includes a transceiver circuit 31 which is operable to transmit signals to and to receive signals from the connected node(s) via one or more antennas 32.
  • the UE 3 may include a user interface 34 for inputting information from outside or outputting information to outside.
  • the UE 3 may have all the usual functionality of a conventional mobile device and this may be provided by any one or any combination of hardware, software and firmware, as appropriate.
  • Software may be pre-installed in the memory and/or may be downloaded via the telecommunication network or from a removable data storage device (RMD), for example.
  • RMD removable data storage device
  • a controller 33 controls the operation of the UE 3 in accordance with software stored in a memory 36.
  • the software includes, among other things, an operating system 361 and a communications control module 362 having at least a transceiver control module 3621.
  • the communications control module 362 (using its transceiver control module 3621) is responsible for handling (generating/sending/receiving) signalling and uplink/downlink data packets between the UE 3 and other nodes, such as the (R)AN node 5 and the AMF 70.
  • Such signalling may include, for example, appropriately formatted signalling messages (e.g. a registration request message and associated response messages) relating to access and mobility management procedures (for the UE 3).
  • the controller 33 interworks with one or more Universal Subscriber Identity Module (USIM) 35. If there are multiple USIMs 35 equipped, the controller 33 may activate only one USIM 35 or may activate multiple USIMs 35 at the same time.
  • USIM Universal Subscriber Identity Module
  • the UE 3 may, for example, support the Non-Public Network (NPN).
  • NPN Non-Public Network
  • the NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
  • SNPN Stand-alone Non-Public Network
  • PNI-NPN Public Network Integrated NPN
  • the UE 3 may, for example, be an item of equipment for production or manufacture and/or an item of energy related machinery (for example equipment or machinery such as: boilers; engines; turbines; solar panels; wind turbines; hydroelectric generators; thermal power generators; nuclear electricity generators; batteries; nuclear systems and/or associated equipment; heavy electrical machinery; pumps including vacuum pumps; compressors; fans; blowers; oil hydraulic equipment; pneumatic equipment; metal working machinery; manipulators; robots and/or their application systems; tools; molds or dies; rolls; conveying equipment; elevating equipment; materials handling equipment; textile machinery; sewing machines; printing and/or related machinery; paper converting machinery; chemical machinery; mining and/or construction machinery and/or related equipment; machinery and/or implements for agriculture, forestry and/or fisheries; safety and/or environment preservation equipment; tractors; precision bearings; chains; gears; power transmission equipment; lubricating equipment; valves; pipe fittings; and/or application systems for any of the previously mentioned equipment or machinery etc.).
  • equipment or machinery such as: boilers
  • the UE 3 may, for example, be an item of transport equipment (for example transport equipment such as: rolling stocks; motor vehicles; motor cycles; bicycles; trains; buses; carts; rickshaws; ships and other watercraft; aircraft; rockets; satellites; drones; balloons etc.).
  • transport equipment for example transport equipment such as: rolling stocks; motor vehicles; motor cycles; bicycles; trains; buses; carts; rickshaws; ships and other watercraft; aircraft; rockets; satellites; drones; balloons etc.
  • the UE 3 may, for example, be an item of information and communication equipment (for example information and communication equipment such as: electronic computer and related equipment; communication and related equipment; electronic components etc.).
  • information and communication equipment such as: electronic computer and related equipment; communication and related equipment; electronic components etc.
  • the UE 3 may, for example, be a refrigerating machine, a refrigerating machine applied product, an item of trade and/or service industry equipment, a vending machine, an automatic service machine, an office machine or equipment, a consumer electronic and electronic appliance (for example a consumer electronic appliance such as: audio equipment; video equipment; a loud speaker; a radio; a television; a microwave oven; a rice cooker; a coffee machine; a dishwasher; a washing machine; a dryer; an electronic fan or related appliance; a cleaner etc.).
  • a consumer electronic appliance such as: audio equipment; video equipment; a loud speaker; a radio; a television; a microwave oven; a rice cooker; a coffee machine; a dishwasher; a washing machine; a dryer; an electronic fan or related appliance; a cleaner etc.
  • the UE 3 may, for example, be an electrical application system or equipment (for example an electrical application system or equipment such as: an x-ray system; a particle accelerator; radio isotope equipment; sonic equipment; electromagnetic application equipment; electronic power application equipment etc.).
  • an electrical application system or equipment such as: an x-ray system; a particle accelerator; radio isotope equipment; sonic equipment; electromagnetic application equipment; electronic power application equipment etc.
  • the UE 3 may, for example, be an electronic lamp, a luminaire, a measuring instrument, an analyzer, a tester, or a surveying or sensing instrument (for example a surveying or sensing instrument such as: a smoke alarm; a human alarm sensor; a motion sensor; a wireless tag etc.), a watch or clock, a laboratory instrument, optical apparatus, medical equipment and/or system, a weapon, an item of cutlery, a hand tool, or the like.
  • a surveying or sensing instrument such as: a smoke alarm; a human alarm sensor; a motion sensor; a wireless tag etc.
  • the UE 3 may, for example, be a wireless-equipped personal digital assistant or related equipment (such as a wireless card or module designed for attachment to or for insertion into another electronic device (for example a personal computer, electrical measuring machine)).
  • a wireless-equipped personal digital assistant or related equipment such as a wireless card or module designed for attachment to or for insertion into another electronic device (for example a personal computer, electrical measuring machine)).
  • the UE 3 may be a device or a part of a system that provides applications, services, and solutions described below, as to "internet of things (IoT)", using a variety of wired and/or wireless communication technologies.
  • IoT Internet of things
  • IoT devices may be equipped with appropriate electronics, software, sensors, network connectivity, and/or the like, which enable these devices to collect and exchange data with each other and with other communication devices.
  • IoT devices may comprise automated equipment that follow software instructions stored in an internal memory. IoT devices may operate without requiring human supervision or interaction. IoT devices might also remain stationary and/or inactive for a long period of time. IoT devices may be implemented as a part of a (generally) stationary apparatus. IoT devices may also be embedded in non-stationary apparatus (e.g. vehicles) or attached to animals or persons to be monitored/tracked.
  • IoT technology can be implemented on any communication devices that can connect to a communications network for sending/receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.
  • IoT devices are sometimes also referred to as Machine-Type Communication (MTC) devices or Machine-to-Machine (M2M) communication devices or Narrow Band-IoT UE (NB-IoT UE). It will be appreciated that a UE 3 may support one or more IoT or MTC applications.
  • MTC Machine-Type Communication
  • M2M Machine-to-Machine
  • NB-IoT UE Narrow Band-IoT UE
  • the UE 3 may be a smart phone or a wearable device (e.g. smart glasses, a smart watch, a smart ring, or a hearable device).
  • a wearable device e.g. smart glasses, a smart watch, a smart ring, or a hearable device.
  • the UE 3 may be a reduced capability device (RedCap).
  • the UE 3 may be a car, or a connected car, or an autonomous car, or a vehicle device, or a motorcycle or V2X (Vehicle to Everything) communication module (e.g. Vehicle to Vehicle communication module, Vehicle to Infrastructure communication module, Vehicle to People communication module and Vehicle to Network communication module).
  • V2X Vehicle to Everything
  • the UE 301, the UE-to-Network Relay UE 303, or the IoT Device 302 may have same components to the UE 3.
  • FIG. 33 is a block diagram illustrating the main components of an exemplary (R)AN node 5, for example a base station ('eNB' in LTE, 'gNB' in 5G, a base station for 5G beyond, a base station for 6G).
  • the (R)AN node 5 includes a transceiver circuit 51 which is operable to transmit signals to and to receive signals from connected UE(s) 3 via one or more antennas 52 and to transmit signals to and to receive signals from other network nodes (either directly or indirectly) via a network interface 53.
  • a controller 54 controls the operation of the (R)AN node 5 in accordance with software stored in a memory 55.
  • Software may be pre-installed in the memory and/or may be downloaded via the telecommunication network or from a removable data storage device (RMD), for example.
  • the software includes, among other things, an operating system 551 and a communications control module 552 having at least a transceiver control module 5521.
  • the communications control module 552 (using its transceiver control sub-module) is responsible for handling (generating/sending/receiving) signalling between the (R)AN node 5 and other nodes, such as the UE 3, another (R)AN node 5, the AMF 70 and the UPF 72 (e.g. directly or indirectly).
  • the signalling may include, for example, appropriately formatted signalling messages relating to a radio connection and a connection with the core network 7 (for a particular UE 3), and in particular, relating to connection establishment and maintenance (e.g. RRC connection establishment and other RRC messages), NG Application Protocol (NGAP) messages (i.e. messages by N2 reference point) and Xn application protocol (XnAP) messages (i.e. messages by Xn reference point), etc.
  • Such signalling may also include, for example, broadcast information (e.g. Master Information and System information) in a sending case.
  • the controller 54 is also configured (by software or hardware) to handle related tasks such as, when implemented, UE mobility estimation and/or moving trajectory estimation.
  • the (R)AN node 5 may support the Non-Public Network (NPN).
  • NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
  • SNPN Stand-alone Non-Public Network
  • PNI-NPN Public Network Integrated NPN
  • the RAN 501, the Radio Cell 502, the IAB Node 502, or the IAB donor 501 may have same components to the (R)AN node 5.
  • the (R)AN node 5 may be expressed as a RAN node, RAN, (R)AN, Radio Cell etc.
  • FIG. 34 schematically illustrates a (R)AN node 5 based on O-RAN architecture to which the (R)AN node 5 aspects are applicable.
  • the (R)AN node 5 based on O-RAN architecture represents a system overview in which the (R)AN node is split into a Radio Unit (RU) 60, Distributed Unit (DU) 61 and Centralized Unit (CU) 62.
  • each unit may be combined.
  • the RU 60 can be integrated/combined with the DU 61 as an integrated/combined unit
  • the DU 61 can be integrated/combined with the CU 62 as another integrated/combined unit.
  • Any functionality in the description for a unit e.g. one of RU 60, DU 61 and CU 62
  • CU 62 can separate into two functional units such as CU Control plane (CP) and CU User plane (UP).
  • the CU CP has a control plane functionality in the (R)AN node 5.
  • the CU UP has a user plane functionality in the (R)AN node 5.
  • Each CU CP is connected to the CU UP via an appropriate interface (such as the so-called "E1" interface and/or the like).
  • the UE 3 and a respective serving RU 60 are connected via an appropriate air interface (for example the so-called “Uu” interface and/or the like).
  • Each RU 60 is connected to the DU 61 via an appropriate interface (such as the so-called “Front haul”, “Open Front haul”, “F1” interface and/or the like).
  • Each DU 61 is connected to the CU 62 via an appropriate interface (such as the so-called “Mid haul”, “Open Mid haul", “E2" interface and/or the like).
  • Each CU 62 is also connected to nodes in the core network 7 (such as the so-called core network nodes) via an appropriate interface (such as the so-called “Back haul”, “Open Back haul”, “N2"/ “N3” interface(s) and/or the like).
  • an appropriate interface such as the so-called "Back haul”, “Open Back haul”, “N2"/ “N3” interface(s) and/or the like.
  • a user plane part of the DU 61 can also be connected to the core network nodes via an appropriate interface (such as the so-called “N3" interface(s) and/or the like).
  • each unit provides some of the functionality that is provided by the (R)AN node 5.
  • the RU 60 may provide a functionalities to communicate with a UE 3 over air interface
  • the DU 61 may provide functionalities to support MAC layer and RLC layer
  • the CU 62 may provide functionalities to support PDCP layer, SDAP layer and RRC layer.
  • RU Fig. 35 is a block diagram illustrating the main components of an exemplary RU 60, for example a RU part of base station ('eNB' in LTE, 'gNB' in 5G, a base station for 5G beyond, a base station for 6G).
  • the RU 60 includes a transceiver circuit 601 which is operable to transmit signals to and to receive signals from connected UE(s) 3 via one or more antennas 602 and to transmit signals to and to receive signals from other network nodes or network unit (either directly or indirectly) via a network interface 603.
  • a controller 604 controls the operation of the RU 60 in accordance with software stored in a memory 605.
  • Software may be pre-installed in the memory and/or may be downloaded via the telecommunication network or from a removable data storage device (RMD), for example.
  • the software includes, among other things, an operating system 6051 and a communications control module 6052 having at least a transceiver control module 60521.
  • the communications control module 6052 (using its transceiver control sub-module) is responsible for handling (generating/sending/receiving) signalling between the RU 60 and other nodes or units, such as the UE 3, another RU 60 and DU 61 (e.g. directly or indirectly).
  • the signalling may include, for example, appropriately formatted signalling messages relating to a radio connection and a connection with the RU 60 (for a particular UE 3), and in particular, relating to MAC layer and RLC layer.
  • the controller 604 is also configured (by software or hardware) to handle related tasks such as, when implemented, UE mobility estimation and/or moving trajectory estimation.
  • the RU 60 may support the Non-Public Network (NPN).
  • NPN Non-Public Network
  • the NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
  • SNPN Stand-alone Non-Public Network
  • PNI-NPN Public Network Integrated NPN
  • the RU 60 can be integrated/combined with the DU 61 as an integrated/combined unit. Any functionality in the description for the RU 60 can be implemented in the integrated/combined unit above.
  • FIG. 36 is a block diagram illustrating the main components of an exemplary DU 61, for example a DU part of a base station ('eNB' in LTE, 'gNB' in 5G, a base station for 5G beyond, a base station for 6G).
  • the apparatus includes a transceiver circuit 611 which is operable to transmit signals to and to receive signals from other nodes or units (including the RU 60) via a network interface 612.
  • a controller 613 controls the operation of the DU 61 in accordance with software stored in a memory 614.
  • Software may be pre-installed in the memory 614 and/or may be downloaded via the telecommunication network or from a removable data storage device (RMD), for example.
  • RMD removable data storage device
  • the software includes, among other things, an operating system 6141 and a communications control module 6142 having at least a transceiver control module 61421.
  • the communications control module 6142 (using its transceiver control module 61421) is responsible for handling (generating/sending/receiving) signalling between the DU 61 and other nodes or units, such as the RU 60 and other nodes and units.
  • the DU 61 may support the Non-Public Network (NPN).
  • NPN Non-Public Network
  • the NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
  • SNPN Stand-alone Non-Public Network
  • PNI-NPN Public Network Integrated NPN
  • the RU 60 can be integrated/combined with the DU 61 or CU 62 as an integrated/combined unit. Any functionality in the description for DU 61 can be implemented in one of the integrated/combined unit above.
  • FIG. 37 is a block diagram illustrating the main components of an exemplary CU 62, for example a CU part of base station ('eNB' in LTE, 'gNB' in 5G, a base station for 5G beyond, a base station for 6G).
  • the apparatus includes a transceiver circuit 621 which is operable to transmit signals to and to receive signals from other nodes or units (including the DU 61) via a network interface 622.
  • a controller 623 controls the operation of the CU 62 in accordance with software stored in a memory 624. Software may be pre-installed in the memory 624 and/or may be downloaded via the telecommunication network or from a removable data storage device (RMD), for example.
  • RMD removable data storage device
  • the software includes, among other things, an operating system 6241 and a communications control module 6242 having at least a transceiver control module 62421.
  • the communications control module 6242 (using its transceiver control module 62421) is responsible for handling (generating/sending/receiving) signalling between the CU 62 and other nodes or units, such as the DU 61 and other nodes and units.
  • the CU 62 may support the Non-Public Network (NPN).
  • NPN Non-Public Network
  • the NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
  • SNPN Stand-alone Non-Public Network
  • PNI-NPN Public Network Integrated NPN
  • the CU 62 can be integrated/combined with the DU 61 as an integrated/combined unit. Any functionality in the description for the CU 62 can be implemented in the integrated/combined unit above.
  • AMF Fig. 38 is a block diagram illustrating the main components of the AMF 70.
  • the apparatus includes a transceiver circuit 701 which is operable to transmit signals to and to receive signals from other nodes (including the UE 3) via a network interface 702.
  • a controller 703 controls the operation of the AMF 70 in accordance with software stored in a memory 704.
  • Software may be pre-installed in the memory 704 and/or may be downloaded via the telecommunication network or from a removable data storage device (RMD), for example.
  • the software includes, among other things, an operating system 7041 and a communications control module 7042 having at least a transceiver control module 70421.
  • the communications control module 7042 (using its transceiver control module 70421) is responsible for handling (generating/sending/receiving) signalling between the AMF 70 and other nodes, such as the UE 3 (e.g. via the (R)AN node 5) and other core network nodes (including core network nodes in the HPLMN of the UE 3 when the UE 3 is roaming-in).
  • signalling may include, for example, appropriately formatted signalling messages (e.g. a registration request message and associated response messages) relating to access and mobility management procedures (for the UE 3).
  • the AMF 70 may support the Non-Public Network (NPN).
  • NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
  • SNPN Stand-alone Non-Public Network
  • PNI-NPN Public Network Integrated NPN
  • SMF Fig. 39 is a block diagram illustrating the main components of the SMF 71.
  • the apparatus includes a transceiver circuit 711 which is operable to transmit signals to and to receive signals from other nodes (including the AMF 70) via a network interface 712.
  • a controller 713 controls the operation of the SMF 71 in accordance with software stored in a memory 714.
  • Software may be pre-installed in the memory 714 and/or may be downloaded via the telecommunication network or from a removable data storage device (e.g. a removable memory device (RMD)), for example.
  • the software includes, among other things, an operating system 7141 and a communications control module 7142 having at least a transceiver control module 71421.
  • the communications control module 7142 (using its transceiver control module 71421) is responsible for handling (generating/sending/receiving) signalling between the SMF 71 and other nodes, such as the AMF 70 and other core network nodes (including core network nodes in the HPLMN of the UE 3 when the UE 3 is roaming-in).
  • signalling may include, for example, appropriately formatted signalling messages (e.g. HTTP restful methods based on the service based interfaces) relating to policy management procedures (for the UE 3).
  • the SMF 71 may support the Non-Public Network (NPN).
  • NPN Non-Public Network
  • the NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
  • SNPN Stand-alone Non-Public Network
  • PNI-NPN Public Network Integrated NPN
  • UPF Fig. 40 is a block diagram illustrating the main components of the UPF 72.
  • the apparatus includes a transceiver circuit 721 which is operable to transmit signals to and to receive signals from other nodes (including the SMF 71) via a network interface 722.
  • a controller 723 controls the operation of the UPF 72 in accordance with software stored in a memory 724.
  • Software may be pre-installed in the memory 724 and/or may be downloaded via the telecommunication network or from a removable data storage device (e.g. a removable memory device (RMD)), for example.
  • the software includes, among other things, an operating system 7241 and a communications control module 7242 having at least a transceiver control module 72421.
  • the communications control module 7242 (using its transceiver control module 72421) is responsible for handling (generating/sending/receiving) signalling between the UPF 72 and other nodes, such as the SMF 71 and other core network nodes (including core network nodes in the HPLMN of the UE 3 when the UE 3 is roaming-in).
  • signalling may include, for example, appropriately formatted signalling messages (e.g. HTTP restful methods based on the service based interfaces) relating to policy management procedures (for the UE 3).
  • the UPF 72 may support the Non-Public Network (NPN).
  • NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
  • SNPN Stand-alone Non-Public Network
  • PNI-NPN Public Network Integrated NPN
  • PCF Fig. 41 is a block diagram illustrating the main components of the PCF 73.
  • the apparatus includes a transceiver circuit 731 which is operable to transmit signals to and to receive signals from other nodes (including the AMF 70) via a network interface 732.
  • a controller 733 controls the operation of the PCF 73 in accordance with software stored in a memory 734.
  • Software may be pre-installed in the memory 734 and/or may be downloaded via the telecommunication network or from a removable data storage device (e.g. a removable memory device (RMD)), for example.
  • the software includes, among other things, an operating system 7341 and a communications control module 7342 having at least a transceiver control module 73421.
  • the communications control module 7342 (using its transceiver control module 73421) is responsible for handling (generating/sending/receiving) signalling between the PCF 73 and other nodes, such as the AMF 70 and other core network nodes (including core network nodes in the HPLMN of the UE 3 when the UE 3 is roaming-in).
  • signalling may include, for example, appropriately formatted signalling messages (e.g. HTTP restful methods based on the service based interfaces) relating to policy management procedures (for the UE 3).
  • the PCF 73 may support the Non-Public Network (NPN).
  • NPN Non-Public Network
  • the NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
  • SNPN Stand-alone Non-Public Network
  • PNI-NPN Public Network Integrated NPN
  • NWDAF Fig. 42 is a block diagram illustrating the main components of the NWDAF 74.
  • the apparatus includes a transceiver circuit 741 which is operable to transmit signals to and to receive signals from other nodes (including the AMF 70 and the UDM 75) via a network interface 742.
  • a controller 743 controls the operation of the NWDAF 74 in accordance with software stored in a memory 744.
  • Software may be pre-installed in the memory 744 and/or may be downloaded via the telecommunication network or from a removable data storage device (e.g. a removable memory device (RMD)), for example.
  • the software includes, among other things, an operating system 7441 and a communications control module 7442 having at least a transceiver control module 74421.
  • the communications control module 7442 (using its transceiver control module 74421) is responsible for handling (generating/sending/receiving) signalling between the NWDAF 74 and other nodes, such as the AMF 70 and other core network nodes (including core network nodes in the HPLMN of the UE 3 when the UE 3 is roaming-in).
  • signalling may include, for example, appropriately formatted signalling messages (e.g. HTTP restful methods based on the service based interfaces) relating to policy management procedures (for the UE 3).
  • the NWDAF 74 may support the Non-Public Network (NPN).
  • NPN Non-Public Network
  • the NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
  • SNPN Stand-alone Non-Public Network
  • PNI-NPN Public Network Integrated NPN
  • UDM Fig. 43 is a block diagram illustrating the main components of the UDM 75.
  • the apparatus includes a transceiver circuit 751 which is operable to transmit signals to and to receive signals from other nodes (including the AMF 70) via a network interface 752.
  • a controller 753 controls the operation of the UDM 75 in accordance with software stored in a memory 754.
  • Software may be pre-installed in the memory 754 and/or may be downloaded via the telecommunication network or from a removable data storage device (RMD), for example.
  • the software includes, among other things, an operating system 7541 and a communications control module 7542 having at least a transceiver control module 75421.
  • the communications control module 7542 (using its transceiver control module 75421) is responsible for handling (generating/sending/receiving) signalling between the UDM 75 and other nodes, such as the AMF 70 and other core network nodes (including core network nodes in the VPLMN of the UE 3 when the UE 3 is roaming-out).
  • signalling may include, for example, appropriately formatted signalling messages (e.g. HTTP restful methods based on the service based interfaces) relating to mobility management procedures (for the UE 3).
  • the UDM 75 may support the Non-Public Network (NPN).
  • the NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
  • NSSF Fig. 44 is a block diagram illustrating the main components of the NSSF 76.
  • the apparatus includes a transceiver circuit 761 which is operable to transmit signals to and to receive signals from other nodes (including the AMF 70) via a network interface 762.
  • a controller 763 controls the operation of the NSSF 76 in accordance with software stored in a memory 764.
  • Software may be pre-installed in the memory 764 and/or may be downloaded via the telecommunication network or from a removable data storage device (RMD), for example.
  • the software includes, among other things, an operating system 7641 and a communications control module 7642 having at least a transceiver control module 76421.
  • the communications control module 7642 (using its transceiver control module 76421) is responsible for handling (generating/sending/receiving) signalling between the NSSF 76 and other nodes, such as the AMF 70 and other core network nodes (including core network nodes in the VPLMN of the UE 3 when the UE 3 is roaming-out).
  • signalling may include, for example, appropriately formatted signalling messages (e.g. HTTP restful methods based on the service based interfaces) relating to mobility management procedures (for the UE 3).
  • the NSSF 76 may support the Non-Public Network (NPN).
  • the NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
  • NSACF Fig. 45 is a block diagram illustrating the main components of the NSACF 77.
  • the apparatus includes a transceiver circuit 771 which is operable to transmit signals to and to receive signals from other nodes (including the AMF 70) via a network interface 772.
  • a controller 773 controls the operation of the NSACF 77 in accordance with the software stored in a memory 774.
  • the Software may be pre-installed in the memory 774 and/or may be downloaded via the telecommunication network or from a removable data storage device (e.g. a removable memory device (RMD)), for example.
  • the software includes, among other things, an operating system 7741 and a communications control module 7742 having at least a transceiver control module 77421.
  • the communications control module 7742 (using its transceiver control module 77421) is responsible for handling (generating/sending/receiving) signalling between the NSACF 77 and other nodes, such as the AMF 70 and other core network nodes (including core network nodes in the HPLMN of the UE 3 when the UE 3 is roaming-in).
  • signalling may include, for example, appropriately formatted signalling messages (e.g. HTTP restful methods based on the service based interfaces) relating to network data analytics function procedures (for the UE 3).
  • the NSACF 77 may support the Non-Public Network (NPN).
  • NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
  • SNPN Stand-alone Non-Public Network
  • PNI-NPN Public Network Integrated NPN
  • AUSF Fig. 46 is a block diagram illustrating the main components of the AUSF 78.
  • the apparatus includes a transceiver circuit 781 which is operable to transmit signals to and to receive signals from other nodes (including the AMF 70) via a network interface 782.
  • a controller 783 controls the operation of the AUSF 78 in accordance with the software stored in a memory 784.
  • the Software may be pre-installed in the memory 784 and/or may be downloaded via the telecommunication network or from a removable data storage device (e.g. a removable memory device (RMD)), for example.
  • the software includes, among other things, an operating system 7841 and a communications control module 7842 having at least a transceiver control module 78421.
  • the communications control module 7842 (using its transceiver control module 78421) is responsible for handling (generating/sending/receiving) signalling between the AUSF 78 and other nodes, such as the AMF 70 and other core network nodes (including core network nodes in the HPLMN of the UE 3 when the UE 3 is roaming-in).
  • signalling may include, for example, appropriately formatted signalling messages (e.g. HTTP restful methods based on the service based interfaces) relating to network data analytics function procedures (for the UE 3).
  • the AUSF 78 may support the Non-Public Network (NPN).
  • NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
  • SNPN Stand-alone Non-Public Network
  • PNI-NPN Public Network Integrated NPN
  • NEF Fig. 47 is a block diagram illustrating the main components of the NEF 79.
  • the apparatus includes a transceiver circuit 791 which is operable to transmit signals to and to receive signals from other nodes (including the UDM 75, the AF 201) via a network interface 792.
  • a controller 793 controls the operation of the NEF 79 in accordance with the software stored in a memory 794.
  • the Software may be pre-installed in the memory 794 and/or may be downloaded via the telecommunication network or from a removable data storage device (e.g. a removable memory device (RMD)), for example.
  • the software includes, among other things, an operating system 7941 and a communications control module 7942 having at least a transceiver control module 79421.
  • the communications control module 7942 (using its transceiver control module 79421) is responsible for handling (generating/sending/receiving) signalling between the NEF 79 and other nodes, such as the AMF 70 and other core network nodes (including core network nodes in the HPLMN of the UE 3 when the UE 3 is roaming-in).
  • signalling may include, for example, appropriately formatted signalling messages (e.g. HTTP restful methods based on the service based interfaces) relating to network data analytics function procedures (for the UE 3).
  • the NEF 79 may support the Non-Public Network (NPN).
  • NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
  • SNPN Stand-alone Non-Public Network
  • PNI-NPN Public Network Integrated NPN
  • AF Fig. 48 is a block diagram illustrating the main components of the AF 201.
  • the apparatus includes a transceiver circuit 2011 which is operable to transmit signals to and to receive signals from other nodes (including the UE 3, the NEF 79) via a network interface 2012.
  • a controller 2013 controls the operation of the AF 201 in accordance with software stored in a memory 2014.
  • Software may be pre-installed in the memory 2014 and/or may be downloaded via the telecommunication network or from a removable data storage device (e.g. a removable memory device (RMD)), for example.
  • the software includes, among other things, an operating system 20141 and a communications control module 20142 having at least a transceiver control module 201421.
  • the communications control module 20142 (using its transceiver control module 201421) is responsible for handling (generating/sending/receiving) signalling between the AF 201 and other nodes, such as the UE 3 and other core network nodes (including core network nodes in the HPLMN of the UE 3 when the UE 3 is roaming-in).
  • signalling may include, for example, appropriately formatted signalling messages (e.g. HTTP restful methods based on the service based interfaces) relating to policy management procedures (for the UE 3).
  • the AF 201 may support the Non-Public Network (NPN).
  • NPN Non-Public Network
  • the NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
  • SNPN Stand-alone Non-Public Network
  • PNI-NPN Public Network Integrated NPN
  • the UE 3 and the network apparatus are described for ease of understanding as having a number of discrete modules (such as the communication control modules). Whilst these modules may be provided in this way for certain applications, for example where an existing system has been modified to implement the disclosure, in other applications, for example in systems designed with the inventive features in mind from the outset, these modules may be built into the overall operating system or code and so these modules may not be discernible as discrete entities. These modules may also be implemented in software, hardware, firmware or a mix of these.
  • Each controller may comprise any suitable form of processing circuitry including (but not limited to), for example: one or more hardware implemented computer processors; microprocessors; central processing units (CPUs); arithmetic logic units (ALUs); input/output (IO) circuits; internal memories / caches (program and/or data); processing registers; communication buses (e.g. control, data and/or address buses); direct memory access (DMA) functions, hardware or software implemented counters, pointers and/or timers; and/or the like.
  • processors e.g. one or more hardware implemented computer processors; microprocessors; central processing units (CPUs); arithmetic logic units (ALUs); input/output (IO) circuits; internal memories / caches (program and/or data); processing registers; communication buses (e.g. control, data and/or address buses); direct memory access (DMA) functions, hardware or software implemented counters, pointers and/or timers; and/or the like.
  • CPUs central processing
  • the software modules may be provided in compiled or un-compiled form and may be supplied to the UE 3 and the network apparatus as a signal over a computer network, or on a recording medium. Further, the functionality performed by part or all of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred as it facilitates the updating of the UE 3 and the network apparatus in order to update their functionalities.
  • radio access radio access
  • any other radio communications technology e.g. WLAN, Wi-Fi, WiMAX, Bluetooth, etc.
  • other fix line communications technology e.g. BBF Access, Cable Access, optical access, etc.
  • Items of user equipment might include, for example, communication devices such as mobile telephones, smartphones, user equipment, personal digital assistants, laptop/tablet computers, web browsers, e-book readers and/or the like.
  • Such mobile (or even generally stationary) devices are typically operated by a user, although it is also possible to connect so-called 'Internet of Things' (IoT) devices and similar machine-type communication (MTC) devices to the network.
  • IoT Internet of Things
  • MTC machine-type communication
  • the present application refers to mobile devices (or UEs) in the description but it will be appreciated that the technology described can be implemented on any communication devices (mobile and/or generally stationary) that can connect to a communications network for sending/receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.
  • the present disclosure may be embodied as a method, and system. Accordingly, the present disclosure may take the form of an entirely hardware embodiment, a software embodiment or an embodiment combining software and hardware aspects.
  • each block of the block diagrams can be implemented by computer program instructions.
  • These computer program instructions may be provided to a processor of a general-purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
  • a general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine.
  • a processor may also be implemented as a combination of computing devices, e.g., a plurality of microprocessors, one or more microprocessors, or any other such configuration.
  • a software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
  • a storage medium may be coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor.
  • the processor and the storage medium may reside in an ASIC.
  • a method of a first communication apparatus comprising: sending information related to Ambient Internet of Things (IoT) to a second communication apparatus.
  • IoT Ambient Internet of Things
  • supplementary note 2 The method according to supplementary note 1, wherein the first communication apparatus is an Application Function (AF), and wherein the second communication apparatus is a Network Exposure Function (NEF).
  • AF Application Function
  • NEF Network Exposure Function
  • supplementary note 3 The method according to supplementary note 1, wherein the first communication apparatus is an Application Function (AF), and wherein the second communication apparatus is a UE-to-Network Relay UE for the Ambient IoT.
  • AF Application Function
  • a method of a first communication apparatus comprising: receiving information related to Ambient Internet of Things (IoT) from a second communication apparatus.
  • IoT Ambient Internet of Things

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

An aspect of this disclosure includes a method of a first communication apparatus. The method includes sending information related to Ambient Internet of Things (IoT) to a second communication apparatus.

Description

METHOD OF FIRST COMMUNICATION APPARATUS, METHOD OF COMMUNICATION APPARATUS, FIRST COMMUNICATION APPARATUS AND COMMUNICATION APPARATUS
　　The present disclosure relates to a method of a first communication apparatus, a method of a communication apparatus, a first communication apparatus and a communication apparatus etc.
　　According to 3GPP TR 22.840 (NPL 2), there is a strong market demand for the 3GPP system to support ambient power-enabled Internet of Things (i.e., Ambient IoT).
　　The Ambient IoT 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.
　　NPL 2 defines the automated warehouse inventory scenario, which is divided into verification and unloading, gate-in inventory, inventory, gate-out inventory and check & loading. Along with the transfer, storage and inventory of goods, a large amount of warehousing information will be generated. For gate-in operation, NPL 2 defines that there are two gate inventory modes supported by both the management platform and the 5G system.
　　・Manual-Triggered Mode: The inventory task is triggered by the command sent from the management platform, so the 5G system simply execute the command (e.g., start the inventory task).
　　・Auto-Triggered Mode: The inventory management system set the gate inventory mode to "Auto-Triggered", the 5G network send discovery signal periodically to discover Ambient IoT devices within the gate area; if at least one Ambient IoT device is discovered, then the 5G system start inventory task automatically.
NPL 1: 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". V17.1.0 (2021-12)
NPL 2: 3GPP TR 22.840: "Study on Ambient power-enabled Internet of Things". V1.2.0 (2023-05)
NPL 3: 3GPP TR 38.848: "Study on Ambient IoT (Internet of Things) in RAN". V0.2.0 (2023-06)
NPL 4: 3GPP TS 23.501: "System architecture for the 5G System (5GS)". V18.1.0 (2023-03)
NPL 5: 3GPP TS 23.502: "Procedures for the 5G System (5GS)". V18.1.1 (2023-04)
NPL 6: 3GPP TS 23.503: "Policy and charging control framework for the 5G System (5GS) Stage 2". V18.1.0 (2023-03)
NPL 7: 3GPP TS 24.501: "Non-Access-Stratum (NAS) protocol for 5G System (5GS) Stage 3". V18.2.1 (2023-03)
NPL 8: 3GPP TS 33.501: "Security architecture and procedures for 5G system". V18.2.0 (2023-06)
NPL 9: 3GPP TS 23.003: "Numbering, addressing and identification". V18.2.0 (2023-06)
NPL 10: IETF RFC 5580: "Carrying Location Objects in RADIUS and Diameter". (2009-08)
NPL 11: 3GPP TS 23.304: "Proximity based Services (ProSe) in the 5G System (5GS)". V18.2.0 (2023-06)
NPL 12: 3GPP TS 23.247: "Architectural enhancements for 5G multicast-broadcast services Stage 2". V18.2.0 (2023-06)
　　For example, as the current 5G system does not support the automated warehouse inventory scenario, 3GPP operators may lose business opportunities for goods managements using the Ambient IoT devices.
　　For example, as the current 5G system supports neither Manual-Triggered Mode nor Auto-Triggered Mode, 3GPP operators may lose business opportunities for goods managements using the Ambient IoT devices.
　　A method of a first communication apparatus according to an aspect of the present disclosure includes:
　　sending information related to Ambient Internet of Things (IoT) to a second communication apparatus.
　　A method of a first communication apparatus according to an aspect of the present disclosure includes:
　　receiving information related to Ambient Internet of Things (IoT) from a second communication apparatus.
　　A method of a communication apparatus according to an aspect of the present disclosure includes:
　　performing a Registration procedure for Ambient Internet of Things (IoT).
　　A method of a first communication apparatus according to an aspect of the present disclosure includes:
　　sending information for activating Ambient Internet of Things (IoT) to a second communication apparatus.
　　A method of a first communication apparatus according to an aspect of the present disclosure includes:
　　receiving first information for activating Ambient Internet of Things (IoT) from a second communication apparatus.
　　A first communication apparatus according to an aspect of the present disclosure includes:
　　means for sending information related to Ambient Internet of Things (IoT) to a second communication apparatus.
　　A first communication apparatus according to an aspect of the present disclosure includes:
　　means for receiving information related to Ambient Internet of Things (IoT) from a second communication apparatus.
　　A communication apparatus according to an aspect of the present disclosure includes:
　　means for performing a Registration procedure for Ambient Internet of Things (IoT).
　　A first communication apparatus according to an aspect of the present disclosure includes:
　　means for sending information for activating Ambient Internet of Things (IoT) to a second communication apparatus.
　　A first communication apparatus according to an aspect of the present disclosure includes:
　　means for receiving first information for activating Ambient Internet of Things (IoT) from a second communication apparatus.
Fig. 1 is an Architecture supporting Ambient IoT devices of a First example of a First Aspect. Fig. 2 is an Identity management model for Ambient IoT device of a First scenario in First example of the First Aspect. Fig. 3 is a Signaling diagram of a Second scenario in First example of the First Aspect. Fig. 4 is a Signaling diagram of a Third scenario in First example of the First Aspect. Fig. 5 is a Signaling diagram of a Fourth scenario in First example of the First Aspect. Fig. 6 is a Service management model for Ambient IoT device of a Fifth scenario in First example of the First Aspect. Fig. 7 is a Signaling diagram of a Sixth scenario in First example of the First Aspect. Fig. 8 is a Signaling diagram of a Seventh scenario in First example of the First Aspect. Fig. 9 is a Signaling diagram of an Eighth scenario in First example of the First Aspect. Fig. 10 is an Architecture supporting Ambient IoT devices of a Second example of a First Aspect. Fig. 11 is an Identity management model for Ambient IoT device of a First scenario in Second example of the First Aspect. Fig. 12 is a Signaling diagram of a Second scenario in Second example of the First Aspect. Fig. 13 is a Signaling diagram of a Fifth scenario in Second example of the First Aspect. Fig. 14 is an Architecture supporting Ambient IoT devices of a Third example of a First Aspect. Fig. 15 is a Signaling diagram of a Fourth scenario in Third example of the First Aspect. Fig. 16 is an Architecture supporting Ambient IoT devices of a Fourth example of a First Aspect. Fig. 17 is an Identity management model for Ambient IoT device of a First scenario in Fourth example of the First Aspect. Fig. 18 is a Signaling diagram of a Third scenario in Fourth example of the First Aspect. Fig. 19 is a Signaling diagram of a Fourth scenario in Fourth example of the First Aspect. Fig. 20 is a Signaling diagram of a Seventh scenario in Fourth example of the First Aspect. Fig. 21 is a Signaling diagram of an Eighth scenario in Fourth example of the First Aspect. Fig. 22 is a Signaling diagram of a Ninth scenario in Fourth example of the First Aspect. Fig. 23 is an Overall network model supporting multiple Ambient IoT devices of a Second Aspect. Fig. 24 is an ISO/IEC RFID related standard air interface as an example of the Second Aspect. Fig. 25 is an Independent air interface of a First example of the Second Aspect. Fig. 26 is a Signaling diagram of a First scenario in First example of the Second Aspect. Fig. 27 is a Converged air interface of a Second example of the Second Aspect. Fig. 28 is a Signaling diagram of a First scenario in Second example of the Second Aspect. Fig. 29 is an Ambient IoT air interface deployed in the UE as the personal network of the UE of a Third example of the Second Aspect. Fig. 30 is a Signaling diagram of a First scenario in Third example of the Second Aspect. Fig. 31 is a diagram illustrating a system overview. Fig. 32 is a block diagram illustrating a UE. Fig. 33 is a block diagram illustrating an (R)AN node. Fig. 34 is a diagram illustrating System overview of (R)AN node based on O-RAN architecture. Fig. 35 is a block diagram illustrating an RU. Fig. 36 is a block diagram illustrating a DU. Fig. 37 is a block diagram illustrating a CU. Fig. 38 is a block diagram illustrating an AMF. Fig. 39 is a block diagram illustrating an SMF. Fig. 40 is a block diagram illustrating a UPF. Fig. 41 is a block diagram illustrating a PCF. Fig. 42 is a block diagram illustrating an NWDAF. Fig. 43 is a block diagram illustrating a UDM. Fig. 44 is a block diagram illustrating an NSSF. Fig. 45 is a block diagram illustrating an NSACF. Fig. 46 is a block diagram illustrating an AUSF. Fig. 47 is a block diagram illustrating a NEF. Fig. 48 is a block diagram illustrating an AF.
Abbreviations
　　For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 (NPL 1) and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in NPL 1.
　　4G-GUTI: 4G Globally Unique Temporary UE Identity
　　5GC: 5G Core Network
　　5GLAN: 5G Local Area Network
　　5G HE AV: 5G Home Environment Authentication Vector
　　5G SE AV: 5G Serving Environment Authentication Vector
　　5GS: 5G System
　　5G-AN: 5G Access Network
　　5G-AN PDB: 5G Access Network Packet Delay Budget
　　5G-EIR: 5G-Equipment Identity Register
　　5G-GUTI: 5G Globally Unique Temporary Identifier
　　5G-BRG: 5G Broadband Residential Gateway
　　5G-CRG: 5G Cable Residential Gateway
　　5G GM: 5G Grand Master
　　5G-RG: 5G Residential Gateway
　　5G-S-TMSI: 5G S-Temporary Mobile Subscription Identifier
　　5G VN: 5G Virtual Network
　　5QI: 5G QoS Identifier
　　ABBA: Anti-Bidding down Between Architectures
　　AF: Application Function
　　AMF: Access and Mobility Management Function
　　AMF-G: Geographically selected Access and Mobility Management Function
　　AMF-NG: Non-Geographically selected Access and Mobility Management Function
　　ANDSF: Access Network Discovery and Selection Function
　　ARFCN: Absolute radio-frequency channel number
　　AS: Access Stratum
　　ASN: Abstract Syntax Notation
　　ATSSS: Access Traffic Steering, Switching, Splitting
　　ATSSS-LL: ATSSS Low-Layer
　　AuC: Authentication Centre
　　AUSF: Authentication Server Function
　　AUTN: Authentication token
　　BCCH: Broadcast Control Channel
　　BMCA: Best Master Clock Algorithm
　　BSF: Binding Support Function
　　CAG: Closed Access Group
　　CAPIF: Common API Framework for 3GPP northbound APIs
　　CHF: Charging Function
　　CN PDB: Core Network Packet Delay Budget
　　CP: Control Plane
　　DAPS: Dual Active Protocol Stacks
　　DL: Downlink
　　DN: Data Network
　　DNAI: DN Access Identifier
　　DNN: Data Network Name
　　DRX: Discontinuous Reception
　　DSATSSS: Dual Steer Access Traffic Steering, Switching, Splitting
　　DSATSSS-LL: Dual Steer Access Traffic Steering, Switching, Splitting- Low-Layer
　　DSMA: Dual Steer Multi Access
　　DS-TT: Device-side TSN translator
　　ePDG: evolved Packet Data Gateway
　　EBI: EPS Bearer Identity
　　ECGI: E-UTRAN Cell Global Identifier
　　EPS: Evolved Packet System
　　EUI: Extended Unique Identifier
　　FAR: Forwarding Action Rule
　　FN-BRG: Fixed Network Broadband RG
　　FN-CRG: Fixed Network Cable RG
　　FN-RG: Fixed Network RG
　　FQDN: Fully Qualified Domain Name
　　GCI: Global Cable Identifier
　　GEO: Geostationary Earth Orbit
　　GFBR: Guaranteed Flow Bit Rate
　　GMLC: Gateway Mobile Location Centre
　　G-PDU: GTP encapsulated user Plane Data Unit
　　GPS: Global Positioning System
　　GPSI: Generic Public Subscription Identifier
　　GSO: Geosynchronous Orbit
　　GUAMI: Globally Unique AMF Identifier
　　GUTI: Globally Unique Temporary UE Identity
　　HPLMN: Home Public Land Mobile Network
　　HR: Home Routed (roaming)
　　HSS: Home Subscriber Server
　　IAB: Integrated access and backhaul
　　IEC: International Electrotechnical Commission
　　IMEI/TAC: IMEI Type Allocation Code
　　IMSI: International Mobile Subscriber Identity
　　IPsec: Internet Protocol Security
　　IPUPS: Inter PLMN UP Security
　　I-SMF: Intermediate SMF
　　ISO: International Organization for Standardization
　　I-UPF: Intermediate UPF
　　LADN: Local Area Data Network
　　LBO: Local Break Out (roaming)
　　LCS: Location Service
　　LEO: Low Earth Orbit
　　LMF: Location Management Function
　　LoA: Level of Automation
　　LPP: LTE Positioning Protocol
　　LRF: Location Retrieval Function
　　MA: Multi Access
　　MCC: Mobile country code
　　MCX: Mission Critical Service
　　MDBV: Maximum Data Burst Volume
　　ME: Mobile Equipment
　　MFBR: Maximum Flow Bit Rate
　　MICO: Mobile Initiated Connection Only
　　MINT: Minimization of service interruption
　　MITM: Man In the Middle
　　MME: Mobility Management Entity
　　MN: Master Node
　　MNC: Mobile Network Code
　　MNO: Mobile Network Operator
　　MOCN: Multiple Operator Core Network
　　MPS: Multimedia Priority Service
　　MPTCP: Multi-Path TCP Protocol
　　MT: Mobile Termination, Mobile Terminating, Mobile terminated
　　N3IWF: Non-3GPP InterWorking Function
　　N3GPP: Non-3GPP access
　　N5CW: Non-5G-Capable over WLAN
　　NAI: Network Access Identifier
　　NAS: Non-Access-Stratum
　　NCGI: NR Cell Global Identity
　　NCI: NR Cell Identity
　　NEF: Network Exposure Function
　　NF: Network Function
　　NGAP: Next Generation Application Protocol
　　NGSO: Non-Geosynchronous Orbit
　　NID: Network identifier
　　NMEA: National Marine Electronics Association
　　NPN: Non-Public Network
　　NR: New Radio
　　NSAG: Network Slice Access Stratum Group
　　NRF: Network Repository Function
　　NSAC: Network Slice Admission Control
　　NSACF: Network Slice Admission Control Function
　　NSI ID: Network Slice Instance Identifier
　　NSSAA: Network Slice-Specific Authentication and Authorization
　　NSSAAF: Network Slice-Specific Authentication and Authorization Function
　　NSSAI: Network Slice Selection Assistance Information
　　NSSF: Network Slice Selection Function
　　NSSP: Network Slice Selection Policy
　　NSSRG: Network Slice Simultaneous Registration Group
　　NW-TT: Network-side TSN translator
　　NWDAF: Network Data Analytics Function
　　PCF: Policy Control Function
　　PCO: Protocol Configuration Options
　　PCRF: Policy and Charging Rules Function
　　PDB: Packet Delay Budget
　　PDR: Packet Detection Rule
　　PDU: Protocol Data Unit
　　PEI: Permanent Equipment Identifier
　　PER: Packet Error Rate
　　PFD: Packet Flow Description
　　PLMN: Public Land Mobile Network
　　PNI-NPN: Public Network Integrated Non-Public Network
　　PPD: Paging Policy Differentiation
　　PPF: Paging Proceed Flag
　　PPI: Paging Policy Indicator
　　ProSe: Proximity based Services
　　PSA: PDU Session Anchor
　　PTP: Precision Time Protocol
　　QFI: QoS Flow Identifier
　　QoE: Quality of Experience
　　RACS: Radio Capabilities Signalling optimisation
　　(R)AN: (Radio) Access Network
　　RAT: Radio Access Technology
　　RFID: Radio Frequency Identification
　　RG: Residential Gateway
　　RIM: Remote Interference Management
　　RQA: Reflective QoS Attribute
　　RQI: Reflective QoS Indication
　　RRC: Radio Resource Control
　　RSC: Relay Service Code
　　RSD: Route Selection Descriptor
　　RSN: Redundancy Sequence Number
　　RSRP: Reference Signal Received Power
　　RSRQ: Reference Signal Received Quality
　　RTT: Round-Trip Time
　　RU: Radio Unit
　　RVAS: Roaming Value Added Service
　　SA NR: Standalone New Radio
　　SBA: Service Based Architecture
　　SBI: Service Based Interface
　　SCP: Service Communication Proxy
　　SD: Slice Differentiator
　　SEAF: Security Anchor Functionality
　　SENSE: Signal Level Enhanced Network Selection
　　SEPP: Security Edge Protection Proxy
　　SGW: Serving Gateway
　　SIB: System Information Block
　　SINR: Signal to Interference plus Noise Ratio
　　SLA: Service Level Agreement
　　SMF: Session Management Function
　　SMS: Short Message Service
　　SMSF: Short Message Service Function
　　SN: Sequence Number
　　SN: Secondary Node
　　SN name: Serving Network Name
　　SNPN: Stand-alone Non-Public Network
　　S-NSSAI: Single Network Slice Selection Assistance Information
　　SOR: Steering of Roaming
　　SSC: Session and Service Continuity
　　SSCMSP: Session and Service Continuity Mode Selection Policy
　　SST: Slice/Service Type
　　SUCI: Subscription Concealed Identifier
　　SUPI: Subscription Permanent Identifier
　　SV: Software Version
　　TAI: Tracking Area Identity
　　TAU: Tracking Area Update
　　TEID: Tunnel Endpoint Identifier
　　TMGI: Temporary Mobile Group Identity
　　TMSI: Temporary Mobile Subscriber Identity
　　TNAN: Trusted Non-3GPP Access Network
　　TNAP: Trusted Non-3GPP Access Point
　　TNGF: Trusted Non-3GPP Gateway Function
　　TNL: Transport Network Layer
　　TNLA: Transport Network Layer Association
　　TSC: Time Sensitive Communication
　　TSCAI: TSC Assistance Information
　　TSN: Time Sensitive Networking
　　TSN GM: TSN Grand Master
　　TSP: Traffic Steering Policy
　　TT: TSN Translator
　　TWIF: Trusted WLAN Interworking Function
　　UCMF: UE radio Capability Management Function
　　UCU: UE Configuration Update
　　UDM: Unified Data Management
　　UDR: Unified Data Repository
　　UDSF: Unstructured Data Storage Function
　　UE: User Equipment
　　UL: Uplink
　　UL CL: Uplink Classifier
　　UPF: User Plane Function
　　UPSI: UE Policy Section Identifier
　　URLLC: Ultra Reliable Low Latency Communication
　　URRP-AMF: UE Reachability Request Parameter for AMF
　　URSP: UE Route Selection Policy
　　USIM: User Services Identity Module
　　VID: VLAN Identifier
　　VLAN: Virtual Local Area Network
　　VPLMN: Visited Public Land Mobile Network
　　W-5GAN: Wireline 5G Access Network
　　W-5GBAN: Wireline BBF Access Network
　　W-5GCAN: Wireline 5G Cable Access Network
　　W-AGF: Wireline Access Gateway Function
　　WPT: Wireless Power Transfer
Definitions
　　For the purposes of the present document, the terms and definitions given in NPL 1 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in NPL1.
General
　　Those skilled in the art will appreciate that elements in the figures are illustrated for simplicity and may not have necessarily been drawn to scale. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the figures by conventional symbols, and the figures may show only those specific details that are pertinent to understanding the Aspects of the present disclosure so as not to obscure the figures with details that will be readily apparent to those skilled in the art having the benefit of the description herein.
　　For the purpose of promoting an understanding of the principles of the disclosure, reference will now be made to the Aspect illustrated in the figures and specific language will be used to describe them. It will nevertheless be understood that no limitation of the scope of the disclosure is thereby intended. Such alterations and further modifications in the illustrated system, and such further applications of the principles of the disclosure as would normally occur to those skilled in the art are to be construed as being within the scope of the present disclosure.
　　The terms "comprises", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process or method that comprises a list of steps does not include only those steps but may include other steps not expressly listed or inherent to such a process or method. Similarly, one or more devices or entities or sub-systems or elements or structures or components preceded by "comprises... a" does not, without more constraints, preclude the existence of other devices, sub-systems, elements, structures, components, additional devices, additional sub-systems, additional elements, additional structures or additional components. Appearances of the phrase "in an Aspect", "in another Aspect" and similar language throughout this specification may, but not necessarily do, all refer to the same Aspect.
　　Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this disclosure belongs. The system, methods, and examples provided herein are only illustrative and not intended to be limiting.
　　In the following specification and the claims, reference will be made to a number of terms, which may be defined to have the following meanings. The singular forms "a", "an", and "the" include plural references unless the context clearly dictates otherwise.
　　As used herein, information is associated with data and knowledge, as data is meaningful information and represents the values attributed to parameters. Further knowledge signifies understanding of an abstract or concrete concept. Note that this example system is simplified to facilitate description of the disclosed subject matter and is not intended to limit the scope of this disclosure. Other devices, systems, and configurations may be used to implement the Aspects disclosed herein in addition to, or instead of, a system, and all such Aspects are contemplated as within the scope of the present disclosure.
　　Each of Aspects and elements included in the each of Aspects described below may be implemented independently or in combination with any other. These Aspects include novel characteristics different from one another. Accordingly, these Aspects contribute to achieving objects or solving problems different from one another and contribute to obtaining advantages different from one another.
　　Any lists described in following aspects include at least one parameter or multiple parameters.
　　An example object of this disclosure is to provide a method and apparatus that can solve the above-mentioned problem.
　　Although this disclosure discloses a mechanism to establish multiple data plane connections in the 5GS, all mechanisms in this disclosure can equally apply to the EPS and/or any other system as well. In case all mechanisms in this disclosure are to apply to the EPS, the following terminology conversions apply:
　　gNB →eNodeB
　　AMF → MME
　　SMF → SGW or PGW or combined SGW and PGW or SMF + PGW-C in the case of interworking with EPS
　　UPF → SGW-U or PGW-U or combined SGW-U and PGW-U or UPF + PGW-U in the case of interworking with EPS
　　NGAP → S1AP
　　XnAP → X2AP
　　Any NGAP messages → Respective S1AP messages
　　Any XnAP messages → Respective X2AP messages
　　Registration Request message → Attach Request message or TAU Request message
　　Any AMF service-related messages (ex. Namf_Communication_NonUeN2InfoNotify) → GTP-C messages
　　Any UDM service-related messages (ex. Nudm_SDM_Notification) → DIAMETER messages
　　5G-GUTI → GUTI
　　5G-S-TMSI → S-TMSI
　　In this disclosure, the above-mentioned service requirement (e.g. the automated warehouse inventory scenario) or a service achieved by the above-mentioned service requirement can be expressed as a support of ambient power-enabled Internet of Things, a support of Ambient IoT devices, a support of RFID devices, ambient power-enabled Internet of Things communication, Ambient IoT device communication, Ambient IoT device communication, Ambient IoT communication, Ambient IoT service etc. For example, the automated warehouse inventory scenario may be included in the Ambient IoT device communication, Ambient IoT device communication, Ambient IoT communication, or Ambient IoT service.
　　The Ambient IoT device may be expressed as a IoT device, a device for the Ambient IoT, a device for the Ambient IoT service, a device for the Ambient IoT communication, a UE for the Ambient IoT, a UE for the Ambient IoT service, a UE for the Ambient IoT communication etc.
　　A method of a first communication apparatus according to example aspect of this disclosure includes sending information related to Ambient Internet of Things (IoT) to a second communication apparatus.
　　A method of a first communication apparatus according to example aspect of this disclosure includes receiving information related to Ambient Internet of Things (IoT) from a second communication apparatus.
　　A method of a communication apparatus according to example aspect of this disclosure includes performing a Registration procedure for Ambient Internet of Things (IoT).
　　A method of a first communication apparatus according to example aspect of this disclosure includes sending information for activating Ambient Internet of Things (IoT) to a second communication apparatus.
　　A method of a first communication apparatus according to example aspect of this disclosure includes receiving first information for activating Ambient Internet of Things (IoT) from a second communication apparatus.
　　A first communication apparatus according to example aspect of this disclosure includes at least one memory, and at least one hardware processor coupled to the at least one memory. The at least one hardware processor is configured to send information related to Ambient Internet of Things (IoT) to a second communication apparatus.
　　A first communication apparatus according to example aspect of this disclosure includes at least one memory, and at least one hardware processor coupled to the at least one memory. The at least one hardware processor is configured to receive information related to Ambient Internet of Things (IoT) from a second communication apparatus.
　　A communication apparatus according to example aspect of this disclosure includes at least one memory, and at least one hardware processor coupled to the at least one memory. The at least one hardware processor is configured to perform a Registration procedure for Ambient Internet of Things (IoT).
　　A first communication apparatus according to example aspect of this disclosure includes at least one memory, and at least one hardware processor coupled to the at least one memory. The at least one hardware processor is configured to send information for activating Ambient Internet of Things (IoT) to a second communication apparatus.
　　A first communication apparatus according to example aspect of this disclosure includes at least one memory, and at least one hardware processor coupled to the at least one memory. The at least one hardware processor is configured to receive first information for activating Ambient Internet of Things (IoT) from a second communication apparatus.
　　Hereinafter, example embodiments will be described with reference to the drawings. Note that, in the present disclosure, the drawings may be associated with one or more example embodiments. Further, each element of the drawings may apply to one or more example embodiments.
<First Example Embodiment (First Aspect)>
　　This aspect includes an architecture and mechanisms to realize the following two gate inventory modes by the 3GPP 5G system.
　　Manual-Triggered Mode: The inventory task is triggered by the command sent from the management platform, so the 5G system simply execute the command (e.g., start the inventory task).
　　Auto-Triggered Mode: The inventory management system set the gate inventory mode to "Auto-Triggered", the 5G network send discovery signal periodically to discover Ambient IoT devices within the gate area; if at least one Ambient IoT device is discovered, then the 5G system start inventory task automatically.
　　This aspect refers to and relies on the Ambient IoT Radio interface as disclosed in the Second Aspect. The Ambient IoT Radio interface may be expressed as a radio interface specific to the ambient IoT device communication, an air interface between the UE 3 and network for the Ambient IoT communication etc.
First example of the First Aspect:
　　Fig. 1 includes an example of an architecture that supports ambient IoT devices.
　　The UE 3 in Fig. 1 represents an ambient IoT device. In addition that the UE 3 supports Uu interface, the UE 3 may support a radio interface specific to the ambient IoT device communication. Similarly, in addition that the Radio Cell 50201 and Radio Cell 50202 support Uu interface, the Radio Cell 50201 and Radio Cell 50202 support the radio interface specific to the ambient IoT device communication. For example, the Radio Cell 50201 and Radio Cell 50202 may be controlled by the RAN 501. The Radio Cell may be expressed as a cell.
　　The radio interface specific to the Ambient IoT device communication is disclosed in the Second Aspect. Although the Radio Cell 50201 and Radio Cell 50202 are illustrated in the Warehouse #A as an example, the Radio Cell 50201 and Radio Cell 50202 may be located in public space in the same way as with the normal Radio cells.
　　The Radio Cell 50201 and the Radio Cell 50202 may be a repeater that forwards signal from the RAN 501 to the UE 3 and forwards signal from the UE 3 to the RAN 501. Alternatively, the Radio Cell 50201 and the Radio Cell 50202 may be an RU connected to the RAN 501. The RU may be a logical node defined in O-RAN ALLIANCE. In addition to or alternatively, the Radio Cell 50201 and the Radio Cell 50202 may be a logical node collocated with the RAN 501. Furthermore, the Radio Cell 50201 and the Radio Cell 50202 may be a logical node defined in some of the 3GPP specifications. For example, the Radio Cell 50201 and the Radio Cell 50202 may be a DU (e.g., gNB-DU). In this case, the RAN 501 may be a CU (e.g., gNB-CU). Instead, the Radio Cell 50201 and the Radio Cell 50202 may be a Road Side Unit (RSU).
　　The AF 20101 represents an application server in the data network. For example, the AF 20101 may trigger a task to collect the status of the Ambient IoT devices.
　　The AF 20102 represents an application server in the data network. For example, the AF 20102 may be a server that collects the status of the Ambient IoT devices.
　　The AF 20101 and the AF 20102 may be combined as one Application Function.
　　The AF 20101 and the AF 20102 may be collocated at the same location or located at different locations and in different network domains. For example, the AF 20101 is located at an Ambient IoT device control centre while the AF 20102 is located at an Ambient IoT device data centre.
First scenario in First example of the First Aspect:
　　Fig. 2 includes an example of the Identity management model for Ambient IoT device.
　　The Identity management model for Ambient IoT device is characterized as the following features.
Ambient IoT device identity
　　・An Ambient IoT device identity may be represented as GPSI.
　　・The GPSI is converted to a 3GPP Identity, e.g. SUPI, by the NEF 79.
Group identity of the Ambient IoT device
　　・The Ambient IoT device identity may have one or multiple TMGI(s).
　　・The TMGI represents a group of the Ambident IoT device.
　　・The TMGI may be preconfigured in the UE 3 by the Service provider. The TMGI may be configured by the NAS procedure, for example, the Registration procedure or the UE Configuration update procedure.
　　・When the AF 201 (at least one of the AF 20101 and the AF 20102) triggers a data communication with all group members (e.g. at least one of Ambient IoT devices) represented by the TMGI, the AF 201 initiates a device trigger procedure to the 5GS using the TMGI. For example, in a case where the AF 201 wants to communication with the group members, the AF 201 may perform a procedure for communicating with the group members towards the 5GS using the TMGI.
　　・The TMGI is used by the RAN 501 and the Radio Cell 502 (e.g. at least one of the Radio Cell 50201 and Radio Cell 50202) as the Group paging identity.
　　・The UE 3 and RAN 501 execute paging procedure by replacing 5G-GUTI with the TMGI in the paging procedure as defined in NPL 12.
　　・TMGI may be called as Multicast MBS group.
Second scenario in First example of the First Aspect:
　　Fig. 3 includes an example of the Ambient IoT device management procedure of the UE 3 that supports the Ambient IoT communication.
　　The detailed processes of the Second scenario in First example of the First Aspect are described below with reference to Fig. 3.
　　Step 1. The AF 201 triggers an Ambient IoT device management procedure. For example, the AF 201 adds at least one Ambient IoT device as the subject to the Ambient IoT service provided by the PLMN operators or NPN operators.
　　Step 2. The AF 201 sends the Nnef_ParameterProvision_Create message including Ambient IoT data.
　　The Ambient IoT data may include at least one of the following data:
　　・GPSI: Generic Public Subscription Identifier. This GPSI is an identity of the Ambient IoT device. The GPSI may be provisioned to the Ambient IoT device by being preconfigured in the device or provisioned during the Registration procedure or provisioned by the UE Configuration Update procedure or the SoR procedure. The GPSI may be called as Ambient IoT device ID, Tag-ID etc. For example, the GPSI may be the GPSI of the added Ambient IoT device.
　　・List of TMGI: List of Temporary Mobile Group Identity. The TMGI is used to trigger the Ambient IoT device to start the Ambient IoT communication. The TMGI represents a group of Ambient IoT devices. Each Ambient IoT device may be associated with one TMGI or multiple TMGIs. The TMGI may be provisioned to the Ambient IoT device by preconfigured in the device or provisioned during the Registration procedure or provisioned by the UE Configuration Update procedure or the SoR procedure. The TMGI may be called as Group paging identity, Device Short Tag or ProSe Layer-2 Group ID etc. For example, the List of TMGI may include at least one TMGI. For example, the TMGI may represent a group regarding the added Ambient IoT device. For example, the TMGI may represent a group that the added Ambient IoT device belongs. For example, the added Ambient IoT device may be associated with one TMGI or multiple TMGIs. For example, the Ambient IoT device may be associated with one TMGI or multiple TMGIs. For example, TMGI(s) in the List of TMGI may indicate the added Ambient IoT device. TMGI(s) in the List of TMGI may indicate group(s) that the added Ambient IoT device belongs.
　　・List of PLMN: List of PLMN indicates PLMN(s) that can provide the Ambient IoT service. This list may be referred by the home PLMN (where the UDM 75 is located) when the UE 3 (e.g. Ambient IoT device) roams to a visited PLMN (VPLMN). If the roamed VPLMN is included in the List of PLMN, the HPLMN may understand that the AF 201 has a business association with the VPLMN and may provide the Ambient IoT related data to the VPLMN.
　　The List of PLMN may be security protected by the AF 201. The List of PLMN may be read by the UE 3 as the AF 201 and UE 3 has been pre-configured a security parameter. I.e., any node in 5GC or RAN may not be able to read the List of PLMN.
　　・Ambient IoT profile: This is a profile of the Ambient IoT device. The Ambient IoT profile defines an air interface between the UE 3 and network for the Ambient IoT communication. It may be defined by 3GPP or different standardization body. The air interface may be expressed as the radio interface.
　　The Ambient IoT profile may be security protected by the AF 201. The Ambient IoT profile may be read by the UE 3 as the AF 201 and UE 3 have been pre-configured a security parameter. I.e., any node in 5GC or RAN may not be able to read the Ambient IoT profile. The Ambient IoT profile may include at least one of the following data:
　　　　>Frequency band that is used for the radio interface specific to the Ambient IoT device communication. For example, the Frequency band may indicate frequency band(s) that the UE 3 supports or uses for the Ambient IoT device communication.
　　　　>Air interface that is used for the radio interface specific to the Ambient IoT device communication.
　　　　>Ambient IoT device identity format: A format of the Ambient IoT device. The Ambient IoT device identity format may be called as an RFID formation.
　　　　>Security parameter: A Security parameter for an authentication and/or an authorization procedure between the Ambient IoT device and a network when the Ambient IoT device communicates with the network. The authentication and/or the authorization procedure may be the Primary authentication that NPL 8 defines or a specific authentication and/or the authorization scheme to the radio interface between the Ambient IoT device and a network. The authentication and/or the authorization procedure may be a UE authentication and/or authorization, or a mutual authentication and/or the authorization between the Ambient IoT device and the network. The network may be called as a radio cell, a base station, a relay UE, a UE, an IAB node, a reader, a Tag-ID reader. The Security parameter may be a pre-shared key or etc.
　　・Report to server address: An address of server that the Ambient IoT device communicates with during the Ambient IoT communication. The Report to server address may be called as a server, Ambient IoT data server, data centre or etc.
　　The Report to server address may be security protected by the AF 201. The Report to server address may be read by the UE 3 as the AF 201 and UE 3 has been pre-configured a security parameter. I.e., any node in 5GC or RAN may not be able to read the Report to server address.
　　The Ambient IoT data may be expressed as information or data related to or regarding the Ambient IoT device.
　　The Ambient IoT data may be expressed as information or data related to or regarding the Ambient IoT.
　　Step 3. Upon reception of the Nnef_ParameterProvision_Create message from the AF 201, the NEF 79 converts the received GPSI to a SUPI. For example, the NEF 79 may store correspondence between the GPSI and the SUPI.
　　Step 4. The NEF 79 sends the Nudm_ParameterProvision_Create message to the UDM 75 including at least one of the SUPI, GPSI, List of TMGI, List of PLMNs, Ambient IoT profile and Report to server address.
　　Step 5. Upon reception of the Nudm_ParameterProvision_Create message from the NEF 79, the UDM 75 stores at least one of the GPSI and received data (e.g. the List of TMGI, List of PLMNs, Ambient IoT profile and Report to server address) to the subscription data for the received SUPI.
　　For example, the UDM 75 may know that the received SUPI is related to the received data.
　　Step 6. The UDM 75 sends the Nudm_ParameterProvision_Response message to the NEF 79 including List of TMGI. The List of TMGI is a new TMGI assigned by the UDM 75. The list of TMGI may include at least one of the new TMGI with an original TMGI (e.g. old TMGI). The list of TMGI may include at least one of the new TMGI for the SUPI and an original TMGI (e.g. old TMGI) for the SUPI.
　　The UDM 75 may include the List of TMGI in the Nudm_ParameterProvision_Response message in a case where the new TMGI is assigned or created.
　　Step 7. Upon reception of the Nudm_ParameterProvision_Response from the UDM 75, the NEF 79 sends the Nnef_ParameterProvision_Response message to the AF 201 including the List of TMGI. The list of TMGI may include at least one of the new TMGI with original TMGI.
If the AF 201 receives the List of TMGI, the AF 201 may update the TMGI for the Ambient IoT device.
Variant 1 of First scenario in First example of the First Aspect:
　　In Step 4, the NEF 79 may include Ambient IoT related data for multiple users (e.g. multiple SUPIs) in one Nudm_ParameterProvision_Create message in a case where all SUPIs in the message belong to the same UDM 75.
Variant 2 of First scenario in First example of the First Aspect:
　　In step 2, the AF 201 may send the List of TMGI for each PLMN or GPSI. The UDM 75 may store the List of TMGI for each PLMN or GPSI. In one example, at least one GPSI may be assigned for each PLMN. In step 6, the UDM 75 may send the List of TMGI for per PLMN basis (e.g. via the NEF 79 to the AF 201), and the AF 201 may store the List of TMGI per PLMN basis. The Network Function and AF 201 may use the GPSI of the PLMN where the UE 3 is currently registered.
Variant 3 of First scenario in First example of the First Aspect:
　　In one example, the relation between the UE 3's GPSI and SUPI and the related List of TMGI may be pre-configured in the UDM 75. In this case, in step 3 if the AF 201 targeted UE(s) (e.g. UE(s) subject to he Ambient IoT device management procedure) is identified by GPSI(s) only, the NEF 79 may use the Nudm_SDM_Get request message to retrieve the subscription information (e.g. SUPI(s)) from the UDM 75 and the related List of TMGI(s) using the GPSI parameter (e.g. the GPSI) as provided by the AF 201. The UDM 75 may retrieve the SUPI and the TMGI list (e.g. the List of TMGI) for each GPSI and returns them in the Nudm_SDM_Get response message to the NEF 79.
Third scenario in First example of the First Aspect:
　　Fig. 4 includes an example of the Registration procedure of the Ambient IoT device as represented as the UE 3.
　　This is an initial Registration or mobility Registration procedure of the UE 3. This Registration procedure takes place by the UE 3 at any time if the UE 3 is able to communicate with 3GPP system. For example, the UE 3 has harvested enough energy over the radio interface specific to the ambient IoT device communication. For example, the enough energy for the Ambient IoT device (e.g. the UE 3) to perform the procedure in Fig. 4 (or procedure(s) in Figure(s) of this disclosure) may be provided through the harvesting of radio waves, light, motion, heat, or any other power source that could be seen suitable.
　　The detailed processes of the Third scenario in First example of the First Aspect are described below with reference to Fig. 4.
　　Step 0-1. The Ambient IoT device related data has been installed in the UDM 75. For example, the Ambient IoT device management procedure as disclosed in the Second scenario in First example of the First Aspect takes place.
　　Step 0-2. The UE 3 has enough energy to perform the registration procedure. For example, the UE 3 has been fed or is being fed an energy by the mechanism as disclosed by the Second Aspect.
　　Step 1. The UE 3 sends a Registration Request message to the AMF 70 including at least one of User ID, Ambient IoT device type, GPSI and List of active TMGI.
　　The following bullets explain each parameter in detail.
　　　　・User ID: User ID (e.g., the User ID may be expressed as User Identity) may be a 5G-GUTI, SUCI or SUPI.
　　　　・Ambient IoT device type: The Ambient IoT device type indicates to the AMF 70 that the UE 3 is Ambient IoT device, e.g. the UE 3 supports communication with ambient IoT devices. The Ambient IoT device type may indicate that the UE 3 supports the Ambient IoT, the Ambient IoT communication or the Ambient IoT service. The AMF 70 refers this parameter as the UE 3 may not be capable to send a periodic registration procedure or a mobility registration procedure in a case where the UE 3 does not have enough energy in the UE 3 or energy is not fed to the UE 3. Thus, the AMF 70 keeps the UE context of the UE 3 long enough to provide the Ambient IoT service. For example, the AMF 70 may maintain the UE context for one year even no contact from the UE 3 for one year.
　　　　・GPSI: The GPSI is an acronym of Generic Public Subscription Identifier. This GPSI is an identity of the Ambient IoT device (e.g. the UE 3).
　　　　・List of active TMGI: List of active TMGI indicates active TMGI(s) in the UE 3. The list of active TMGI may be known by the AF 201 whether the UE 3 is able to communicate or not with a TMGI in the list. If the TMGI is listed in the list of TMGI, the TMGI may be used to trigger the UE 3 for the Ambient IoT communication. For example, the List of active TMGI may indicate TMGI(s) that is related to the UE 3. For example, the List of active TMGI may indicate TMGI(s) that is assigned to the UE 3. For example, the AF 201 may refer the List of active TMGI to know whether the UE 3 is able to communicate or not by using the TMGI(s) in the List of active TMGI. For example, the AF 201 may communicate with the UE 3 by using the TMGI(s) in the List of active TMGI. The UE 3 may be identified by the TMGI(s) in the List of active TMGI.
　　The above-mentioned parameter(s) in step 1 (e.g. the parameter(s) in the message of step 1) may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 2. Upon reception of the Registration Request message in step 1, the AMF 70 sends the Nudm_UECM_Registration Request message to the UDM 75 including at least one of the User ID, GPSI and List of active TMGI. Refer to Step 1 for parameter details.
　　The above-mentioned parameter(s) in step 2 (e.g. the parameter(s) in the message of step 2) may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 3. Upon reception of the Nudm_UECM_Registration Request message in step 2, the UDM 75 sends the Nudm_UECM_Registration Response message to the AMF 70.
　　Step 4. After the completion of the Nudm_UECM_Registration service in steps 2 and 3, the AMF 70 sends the Nudm_SDM_Get Request message to the UDM 75 including at least one of the User ID, GPSI and List of active TMGI. Refer to Step 1 for parameter details.
　　The above-mentioned parameter(s) in step 4 (e.g. the parameter(s) in the message of step 4) may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 5. The UDM 75 finds Subscriber data for the UE 3 and sends the Nudm_SDM_Get Response message to the AMF 70 including the Subscriber data for the UE 3. The Subscriber data includes at least one of the GPSI, List of TMGI, List of PLMN, Ambient IoT profile and the Report to server address. Refer to step 2 in Second scenario in First example of the First Aspect for parameter details. For example, the UDM 75 may store the AMF 70 as an Ambient IoT supporting AMF and received parameters in step 4 by associating with the AMF 70.
　　The above-mentioned parameter(s) in step 5 (e.g. the parameter(s) in the message of step 5) may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 6. The UDM 75 may send the Nudm_EventExposure_Notify message to the NEF 79 including at least one of the SUPI and List of active TMGI if the NEF 79 has subscribed to the Nudm_EventExposure service. Refer to step 1 for parameter details.
　　The above-mentioned parameter(s) in step 6 (e.g. the parameter(s) in the message of step 6) may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 7. The NEF 79 may send the Nnef_EventExposure_Notify message to the AF 201 including at least one of the SUPI, GPSI and List of active TMGI if the AF 201 has subscribed to the Nnef_EventExposure service. Refer to step 1 for parameter details. In a case where the NEF 79 stores correspondence between the SUPI and the GPSI, the NEF 79 may find the corresponding GPSI to the received SUPI and may send the GPSI to the AF 201.
　　The above-mentioned parameter(s) in step 7 (e.g. the parameter(s) in the message of step 7) may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 8. The AMF 70 sends the Registration Accept message to the UE 3 including at least one of 5G-GUTI, the GPSI, the List of TMGI, List of PLMN, the Ambient IoT profile and the Report to server address. The 5G-GUTI is a temporary user identifier for the UE 3. Refer to step 2 in Second scenario in First example of the First Aspect for parameter details.
　　The above-mentioned parameter(s) in step 8 (e.g. the parameter(s) in the message of step 8) may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 9. Upon reception of the Registration Accept message, the UE 3 stores the received data in the Registration Accept message in step 8. The UE 3 may store the received data in the Registration Accept message in step 8 into non-volatile memory in the UE 3.
　　Step 10. The UE 3 sends the Registration Complete message to the AMF 70.
　　For example, the UE 3 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1, 8, 9 and 10.
　　For example, the UE 3 may perform at least one of steps 1, 8, 9 and 10 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the AMF 70 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1 to 5, 8 and 10.
　　For example, the AMF 70 may perform at least one of steps 1 to 5, 8 and 10 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the UDM 75 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 2 to 6.
　　For example, the UDM 75 may perform at least one of steps 2 to 6 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the NEF 79 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 6 and 7.
　　For example, the NEF 79 may perform at least one of steps 6 and 7 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the AF 201 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least step 7.
　　For example, the AF 201 may perform at least step 7 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
Variant 1 of Third scenario in First example of the First Aspect:
　　In one example, the UE 3 may be configured with list of TMGI for each PLMN or GPSI. In step 1, the UE 3 may only send the list of TMGI corresponding to the current PLMN. In one example, the PLMN may broadcast in an existing MIB or SIB or in a new SIB a TMGI (or more than one TMGIs) and an indicator whether the UE 3 can get service for the TMGI (or an indicator for each of those TMGIs). The UE 3 may camp on a cell of the PLMN, and the UE 3 may initiate the registration procedure to the PLMN only when the UE 3 is configured with at least one TMGI for which the service is allowed in the cell of the PLMN.
　　Table 1 illustrates an example of the TMGI and its status broadcasted in the MIB or exiting SIB X (X= 1,2,3,4………21).
Figure JPOXMLDOC01-appb-I000001
Variant 2 of Third scenario in First example of the First Aspect:
　　In step 2 the UDM 75 may compare the received TMGI or GPSI from the UE 3 with the stored TMGI or GPSI. If the two don't match, then the UDM 75 may send the stored TMGI, GPSI(s) and other parameter to the AMF 70 for indicating the AMF 70 to configure the UE 3 using an existing NAS procedure.
　　In this case (e.g. in a case where the received TMGI or GPSI from the UE 3 and the stored TMGI or GPSI don't match), in step 6, the UDM 75 may also notify, to the AF 201 via the NEF 79, that the stored data (e.g. TMGI, GPSI etc) are not up to date. When the AF 201 receives this notification, the AF 201 may also update the UE database using O&M procedure i.e. without signalling in the network.
Variant 3 of Third scenario in First example of the First Aspect:
　　In one example, the AMF 70 may include, in the registration accept message, an information element such as TMGI service status indicating whether the service is allowed for the TMGI or not. When the UE 3 receives the information element, the UE 3 may store the information element. When the UE 3 has a NAS or AS signalling or user data to send corresponding to a particular TMGI, the UE 3 may check whether the service is allowed for the TMGI. If the service is allowed then the UE 3 may send the AS or NAS signalling or user data otherwise the UE 3 may not initiate any NAS or AS procedure, except the deregistration procedure.
Variant 4 of Third scenario in First example of the First Aspect:
　　In another example, after the initial registration of the ambient IoT devices with its GPSI as per Fig. 4 (e.g. after the Registration procedure in Fig. 4 completes), it is possible that each ambient IoT device is assigned by a 3GPP identity (e.g. SUPI) and this 3GPP identity is provided back to the UE 3 by the Registration Accept message in step 8, and the UE 3 may create and maintain the relation between the ambient IoT device's GPSI and 3GPP identity. Then, for any following ambient IoT device re-registration or any trigger by the ambient IoT device for communication with the network, the UE 3 may convert the ambient IoT device's GPSI to its 3GPP identity and the UE 3 may use the ambient IoT device's 3GPP identity in the communication with the network.
Variant 5 of Third scenario in First example of the First Aspect:
　　In one example, when the UE 3 is establishing RRC connection, the UE 3 sets the RRC establishment cause to "Ambient IoT' or any other notation for RRC establishment cause in order to indicate that the UE 3 intends to establish RRC connection for the purpose of communication from Ambient IoT device or communication to Ambient IoT device. The RAN node (or the RAN) uses this RRC establishment cause to find the AMF handling ambient IoT devices. The RAN node sends the initial UE message or the Uplink NAS Transport message containing the NAS container to the selected AMF. Alternatively, the 'Ambient IoT' parameter may be indicated by the UE 3 as a parameter of the RRC Connection Setup Complete message from the UE 3 to the RAN and again be used by the RAN node for the purpose of selecting AMF which is ambient IoT communication capable.
Fourth scenario in First example of the First Aspect:
　　Fig. 5 includes an example of the Registration procedure of the Ambient IoT device as represented as the UE 3 with the Ambient IoT data communication.
　　It is assumed that this Registration procedure takes place after a successful Registration procedure with the AMF 70 has been taken place so that a NAS security context has been established between the UE 3 and the AMF 70.
　　The detailed processes of the Fourth scenario in First example of the First Aspect are described below with reference to Fig 5.
　　Step 0. The UE 3 is registered to the AMF 70 and a dedicated PDU Session for the Ambient IoT service has been established with the SMF 71 and the UPF 72. For example, in step 0, the process(es) in Fig. 4 completes and the PDU Session has been established.
　　Step 1-1. In one example, the AF 201 may trigger the Radio Cell 502 for Ambient IoT communication with list of TMGI. In one example, the AF 201 may trigger the Ambient IoT communication (e.g. the automated warehouse inventory scenario) by using the list of TMGI. For example, the AF 201 may trigger the Ambient IoT communication for the UE 3 which is identified by TMGI(s) in the list of TMGI.
　　In one example, Steps 1 to 8 in the the Ambient IoT Service Activation procedure in Fig. 8 may take place.
　　Step. 1-2. The Radio Cell 502 broadcasts energy over the air. Refer to the Aspect 2 for detail of energy broadcasting. The energy broadcasting may be trigged by the activation request in Step 1-1. The energy broadcasting may be trigged by the process(es) in Step 1-1. In this disclosure, the expression "The Radio Cell 502 broadcasts..." may mean "the RAN 501 broadcasts...".
　　For example, the RAN 501 may receive the service trigger from the AF 201 directly or indirectly (e.g. via other network node(s)). Then the RAN 501 may control the Radio Cell 502 to broadcast the energy (e.g. the RAN 501 may broadcast the energy via the Radio Cell 502).
　　Step 1-3. The UE 3 has had enough energy to perform the registration procedure. For example, if the UE 3 has a battery, the battery in the UE 3 have been charged by harvesting energy by receiving the broadcasted energy by Step 1-2. For example, if the UE 3 does not have a battery, the UE 3 performs the Registration procedure using energy being harvested by receiving the broadcasted energy by Step 1-2.
　　Step 2. In one example, the Radio Cell 502 broadcasts system information with a list of TMGI indicating that the UE 3 is requested to perform the Ambient IoT communication immediately if the UE 3 has an active TMGI in the list of TMGI.
　　In another example, the UE 3 initiates the Ambient IoT communication as far as the UE 3 has enough energy for performing the Registration procedure regardless of receiving the system information in Step 2.
　　The above-mentioned parameter(s) in step 2 (e.g. the parameter(s) in the message of step 2) may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　For example, the RAN 501 may control the Radio Cell 502 to broadcast the system information including the list of TMGI. For example, the RAN 501 may broadcast the system information via the Radio Cell 502. The system information may be expressed as a service request (e.g. a service request for the Ambient IoT, for the Ambient IoT communication or for the Ambient IoT service).
　　For example, steps 1-2 and step 2 may be combined. For example, the energy feeding may be performed by the signal in step 2. For example, in this disclosure, the energy feeding may be performed by the system information or the service request.
　　Step 3. The UE 3 sends the RRC Setup Request message to the RAN 501.
　　For example, in a case where the UE 3 receives the system information including TMGI 1 in step 2 and the UE 3 has the list of TMGI including TMGI 1, the UE 3 may send the RRC Setup Request message to the RAN 501.
　　For example, in a case where the UE 3 has enough energy for performing the Registration procedure regardless of receiving the system information in step 2, the UE 3 may send the RRC Setup Request message to the RAN 501.
　　Step 4. Upon the reception of the RRC Setup Request message in Step 3, the RAN 501 sends the RRC Setup message to the UE 3 including List of TMGI for MO requested. The List of TMGI for MO requested indicates to the UE 3 that the Ambient IoT communication associated with the TMGI (e.g. the broadcasted TMGI) is requested. In one example, the RAN 501 may include the List of TMGI for MO requested parameter only if the Radio Cell 502 does not broadcast the system information with the list of TMGI in step 2. For example, the RAN 501 may know that which the list of TMGI is broadcasted by which Radio Cell(s).
　　The above-mentioned parameter(s) in step 4 (e.g. the parameter(s) in the message of step 4) may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 5. The UE 3 sends the RRC Message number 3 message to the RAN 501 including at least one of Ambient IoT device type, TMGI (e.g. the TMGI included in the list of TMGI in step 2) and Dedicated NAS. The RRC Message number 3 message may be called as Message 5 (Msg5) in RRC connection establishment procedure. The RRC Message number 3 message or the Msg5 may be an RRC Setup Complete message in this example. The Ambient IoT device type indicates to the RAN 501 that the UE 3 is Ambient IoT device or belongs to a category mapped to Ambient IoT device. The RAN 501 refers this Ambient IoT device type for Radio Resource Management to the UE 3. In a case where the AMF 70 is not yet associated with the UE 3, the Ambient IoT device type and TMGI are used for AMF selection.
　　The Dedicated NAS includes the Registration Request message.
　　In addition to contents of the Registration request message in Step 1 in Fig. 4, the Registration Request message in step 5 includes the MO-data. The MO-data may be embedded in the CIoT small data container or CIoT user data container. The MO-data may be an Ambient IoT related data from the UE 3 for the Ambient IoT communication. The MO-data may be data for the Ambient IoT. The MO-data may be data for the Ambient IoT communication or for the Ambient IoT service.
　　In one example, the Ambient IoT application in the UE 3 provides the MO-data.
　　The above-mentioned parameter(s) in step 5 (e.g. the parameter(s) in the message of step 5) may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 6. Upon reception of the RRC Message number 3 message from the UE 3, the RAN 501 sends the Initial UE message to the AMF 70 including at least one of the Ambient IoT device type and NAS-PDU. The NAS-PDU includes the Registration Request message that is received in the Dedicated NAS in Step 5.
　　In one example, the MO-data in the Registration Request message is security protected using the NAS security context. In this case, the AMF 70 decodes the protected message using the NAS security context.
　　The above-mentioned parameter(s) in step 6 (e.g. the parameter(s) in the message of step 6) may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 7. Steps 2 to 7 in Fig. 4 take place.
　　Step 8. The AMF 70 sends the Nsmf_PDUSession_SendMOData message to the SMF 71 including the MO-data.
　　Step 9. The SMF 71 forwards the received MO-data to the UPF 72.
　　Step 10. The UPF 72 communicates with the AF 201 or any server in data network for the Ambient IoT communication. For example, the UPF 72 sends the MO-data to the AF 201. For example, the AF 201 sends a MT-data to the UE 3. For example, the AF 201 sends, to the UPF 72, the MT-data for the UE 3. The MT-data may be an Ambient IoT related data to the UE 3 for the Ambient IoT communication.
　　Step 11. The UPF 72 may forward the MT-data if the UPF 72 receives the MT-data during the Ambient IoT communication. For example, the UPF 72 receives the MT-data as a reply to the MO-data. The UPF 72 may forward the MT-data to the SMF 71.
　　Step 12. The SMF 71 sends the Namf_Communication_N1N2MessageTransfer message to the AMF 70. The Namf_Communication_N1N2MessageTransfer message may include the MT-data.
　　Step 13. The AMF 70 sends the Registration Accept message to the UE 3.
　　In addition to contents of the Registration Accept message in Step 8 in Fig. 4, the Registration Accept message in step 13 includes the MT-data. The MT-data may be an Ambient IoT related data to the UE 3 for the Ambient IoT communication.
　　If the UE 3 receives the MT-data in the Registration Accept message, the UE 3 sends the received MT-data to the Ambient IoT application in the UE 3.
　　The above-mentioned parameter(s) in step 13 (e.g. the parameter(s) in the message of step 13) may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 14. The UE 3 sends the Registration Complete message to the AMF 70.
　　For example, the UE 3 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 0, 1-2, 1-3, 2 to 5, 13 and 14.
　　For example, the UE 3 may perform at least one of steps 0, 1-2, 1-3, 2 to 5, 13 and 14 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the Radio Cell 502 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1-1, 1-2 and 2.
　　For example, the Radio Cell 502 may perform at least one of steps 1-1, 1-2 and 2 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the RAN 501 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 3 to 6.
　　For example, the RAN 501 may perform at least one of steps 3 to 6 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the AMF 70 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 6 to 8, 12 and 13.
　　For example, the AMF 70 may perform at least one of steps 6 to 8, 12 and 13 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the SMF 71 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 8, 9, 11 and 12.
　　For example, the SMF 71 may perform at least one of steps 8, 9, 11 and 12 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the UDM 75 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least step 7.
　　For example, the UDM 75 may perform at least step 7 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the UPF 72 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 9 to 11.
　　For example, the UPF 72 may perform at least one of steps 9 to 11 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the AF 201 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least step 10.
　　For example, the AF 201 may perform at least step 10 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
Variant 1 of Fourth scenario in First example of the First Aspect:
　　In one example, the UE 3 sends user data (e.g. the MO-data) without activating the PDU session. In this case, the user data is encapsulated in a packet and SUPI or GPSI is added as an Identifier of the user. In one example, the SUPI or GPSI corresponding to the user data is added in the user packet. The UE 3 encrypts the user data using the NAS security parameters (e.g. at least one of Kausf, Kasme, CK and IK) created during authentication procedure. When the AMF 70 receives the user packet, the AMF 70 decrypts the user packet and sends it to the NEF 79 or UDM 75. The NEF 79 or UDM 75 identifies the user packet using the GPSI, SUPI or TMGI and sends the user packet as it is to the AF 201. When the user packet contains the SUPI, then the UDM 75 or NEF 79 sends GPSI corresponding to the SUPI. The NEF 79 or UDM 75 also includes PLMN ID of the registered PLMN in the user packet. When the AF 201 receives the user packet containing GPSI and TMGI then the AF 201 identifies the user of the data packets.
Variant 2 of Fourth scenario in First example of the First Aspect:
　　In one example, the step 1-1 in Fig. 5 may be transmitted to or terminated at the RAN 501. Then, the RAN 501 may trigger the Radio Cell 502 to perform the step 1-2. This example may be applicable to a case where the Radio Cell 502 is or represents the RU, the repeater, or the RSU. However, this is not limited to such the case only.
Fifth scenario in First example of the First Aspect:
　　The Fig. 6 includes an example of the Service management model for Ambient IoT device.
　　The Service management model for Ambient IoT device is characterized as the following features.
Service for the Ambient IoT communication
　　The Service corresponds to the Ambient IoT service, for example, a gate-in inventory, Inventory at a warehouse, a gate-out inventory as described in NPL2.
　　The TMGI represents a group subject for the Service. For example, TMGI#1 represents all goods produced by company #1, TMGI#2 represents all goods produced by company #2.
　　For example, in a case where the AF 201 indicates a service corresponding to the gate-in inventory together with TMGI#1, the gate-in inventory for all goods produced by company #1 can be executed.
　　TMGI may be called as Multicast MBS group.
Service order
　　The Service order is an order from the AF 201 what kind of Service that AF 201 requests to the 5GS.
　　The Service order may include at least one of the following parameters:
　　　　Service order: The Service order indicates a service that the AF 201 requests to the 5GS. The Service order may include at least one of the following Service orders:
　　　　　　One time report: One time report is used by the AF 201 when the AF 201 needs IoT data from the Ambient IoT devices. The Ambient IoT devices report IoT data when the Ambient IoT device receives this Service order.
　　　　　　Monitor: Monitor is used by the AF 201 when the AF 201 needs IoT data or notification from the Ambient IoT devices for a specified condition with the Validity time. If the Service order is the Monitor, the Validity time is associated in the Service order. The Ambient IoT devices report IoT data during a period if a condition matches with the Validity time. Also, the Monitoring reporting or notification may only be applicable for when the ambient IoT device is in locations defined by the AF 201 via the location or service are parameter within the Service order.
　　　　Validity time: This Validity time may be associated with the Service order. The Validity time is referred as a time duration which the Service order is effective. For example, the Validity time may indicate a time duration which the above-mentioned "Service order" is applicable. The Validity time may take at least one of the following expressions:
　　　　　　Periodic service time indicator: it identifies whether the service time (e.g., duration or interval or time) when the above-mentioned "Service order" is updated periodically or not, for example, only on demand. The Periodic service time indicator may indicate whether the service time is periodically or not.
　　　　　　Service duration time: Duration interval time of Periodic service. The Service duration time may indicate duration or interval or time when the above-mentioned "Service order" or a service indicated by the "Service order" is provided or when the service time is updated. This information may be used together with Periodic service time indicator. Example: 8 hours.
　　　　　　Periodic time: Interval Time of Periodic service. This information may be used together with Periodic service time indicator. The Periodic time may indicate timing when the service time is updated or may indicate periodicity of the above-mentioned "Service order". Example: every hour.
　　　　　　Scheduled service time: Time zone and Day of the week when the service (e.g., the above-mentioned "Service order") is available. Example: Time: 12:00-22:00, Day: Sunday.
　　　　Action: The action indicates an action that the AF 201 requests to the 5GS. The action may not be used for the Service order set to "One time report". The action may include at least one of the following actions:
　　　　　　Start Service: It may indicate to start the service.
　　　　　　Stop Service: It may indicate to stop the service.
Service area
　　The AF 201 may request the Ambient IoT service with Service, TMGI and a generic location information. In this case, the 5GC converts the generic location information to the TAI list and uses the TMGI for page the group of Ambient IoT device(s) in all cell(s) that belong to the TAI list.
　　If a Service is tightly related to a specific location, the 5GC manages the mapping between the Service and corresponding TAI(s). One example of this use case is that a gate-in inventory for the Warehouse #A. In this case, only one or a few cells that covers the gate of the Warehouse #A are subject for the Service.
　　The AF 201 may request the Ambient IoT service with Service and TMGI. In this case, the 5GC converts the Service to specific TAI(s) and uses the TMGI for page the group of Ambient IoT device(s) in all cell(s) that belong to the TAI list.
　　TMGI may be called as Multicast MBS group.
Sixth scenario in First example of the First Aspect:
　　Fig. 7 includes an example of the Ambient IoT configuration notification procedure. This procedure is used when the Radio Cell 502 or AMF 70 is configured or updated to support the Ambient IoT service.
　　The detailed processes of the Sixth scenario in First example of the First Aspect are described below with reference to Fig. 7.
　　There are two triggers for the Ambient IoT configuration notification procedures, one is triggered by updating RAN configuration another one is triggered by updating 5GC configuration.
　　The RAN configuration update includes an update in Radio Cell 502 and/or an update in RAN 501.
　　The 5GC update includes an update in AMF 70, SMF 71 and/or UPF 72. In this disclosure, the expression "A and/or B" may mean "at least one of A and B".
　　Either RAN configuration update procedure or 5GC configuration update procedure may take place.
RAN configuration update procedure
　　Step 1-A1. The Radio Cell 502 is configured or updated to support the Ambient IoT service. Alternatively, the RAN 501 is configured or updated to support the Ambient IoT service.
　　Step 1-A2. The RAN 501 sends the RAN Configuration Update message to the AMF 70 including at least one of Ambient IoT support, Supported Ambient IoT profiles, Supported Service IDs, and Supported TMGIs.
　　The following bullets explain each parameter in detail.
　　　　・Ambient IoT support: The Ambient IoT support indicates that the RAN 501 or the Radio Cell 502 supports the Ambient IoT service and the Ambient IoT service-related procedures as disclosed by this disclosure. In a case where more than one type of Ambient IoT devices is defined (e.g. in 3GPP specifications) or more than one functions for Ambient IoT is defined, such indication may be sent or included per Ambient IoT device type or per Ambient IoT function. The Ambient IoT service-related procedures may be procedure(s) disclosed in at least one Figures of this disclosure.
　　　　・Supported Ambient IoT profiles: The Supported Ambient IoT profiles indicates that Supported Ambient IoT profiles that are supported by the RAN 501. The Supported Ambient IoT profiles may be configured as a list of Supported Ambient IoT profiles. For example, the Supported Ambient IoT profiles may include at least one data in the Ambient IoT profile described in step 2 of Fig. 3. For example, the Supported Ambient IoT profiles may include the Ambient IoT profile regarding the RAN 501. The Ambient IoT profile regarding the RAN 501 may include at least one of data in the Ambient IoT profile described in step 2 of Fig. 3.
　　　　For example, the Supported Ambient IoT profiles may include the Ambient IoT profile(s) for the UE(s) 3 that the RAN 501 supports.
　　　　・Supported Service IDs: The Supported Service IDs indicates that Service IDs that are supported by the RAN 501. The Supported Service IDs may be configured as a list of Supported Service IDs. The Service ID may be an identity for the Ambient IoT service. The Ambient IoT service may be identified by the Service ID. For example, the Supported Service IDs may indicate Service ID(s) for the Service(s) (e.g. the Ambient IoT service(s)) that is supported by the RAN 501.
　　　　・Supported TMGIs: The Supported TMGIs indicates that TMGIs that are supported by the RAN 501. The TMGIs may be configured as a list of TMGIs. The TMGI may be called as Multicast MBS group. For example, the Supported TMGIs may indicate TMGI(s) indicating the group of the Ambident IoT device(s) (e.g. UE(s) 3) that is supported by the RAN 501. For example, the Supported TMGIs may indicate TMGI(s) regarding the group of the Ambident IoT device(s) (e.g. UE(s) 3) that is supported by the RAN 501.
　　The above-mentioned parameter(s) in step 1-A2 (e.g. the parameter(s) in the message of step 1-A2) may be expressed as parameter(s) or data or information for the Ambient IoT or for the Ambient IoT communication or for the Ambient IoT service.
　　The above-mentioned parameter(s) in step 1-A2 (e.g. the parameter(s) in the message of step 1-A2) may be expressed as parameter(s) or data or information related to the Ambient IoT or related to the Ambient IoT communication or related to the Ambient IoT service.
　　Step 1-A3. Upon reception of the RAN Configuration Update message in step 1-A2, the AMF 70 sends the RAN Configuration Update Acknowledge to the RAN 501 including at least one of Ambient IoT support, Supported Service IDs and Supported TMGIs.
　　The following bullets explain each parameter in detail.
　　　　・Ambient IoT support: The Ambient IoT support indicates that the AMF 70 and one or some associated SMF 71 and UPF 72 support the Ambient IoT service and the Ambient IoT service-related procedures as disclosed by this disclosure.
　　　　・Supported Service IDs: The Supported Service IDs indicates that Service IDs that are supported by the AMF 70. The Supported Service IDs may be configured as a list of Supported Service IDs. For example, the Supported Service IDs may indicate Service ID(s) for the Service(s) (e.g. the Ambient IoT service(s)) that is supported by the AMF 70.
　　　　・Supported TMGIs: The Supported TMGIs indicates that TMGIs that are supported by the AMF 70. The TMGIs may be configured as a list of TMGIs. The TMGI may be called as Multicast MBS group. For example, the Supported TMGIs may indicate TMGI(s) indicating the group of the Ambident IoT device(s) (e.g. UE(s) 3) that is supported by the AMF 70. For example, the Supported TMGIs may indicate TMGI(s) regarding the group of the Ambident IoT device(s) (e.g. UE(s) 3) that is supported by the AMF 70.
　　The above-mentioned parameter(s) in step 1-A3 (e.g. the parameter(s) in the message of step 1-A3) may be expressed as parameter(s) or data or information for the Ambient IoT or for the Ambient IoT communication or for the Ambient IoT service.
　　The above-mentioned parameter(s) in step 1-A3 (e.g. the parameter(s) in the message of step 1-A3) may be expressed as parameter(s) or data or information related to the Ambient IoT or related to the Ambient IoT communication or related to the Ambient IoT service.
5GC configuration update procedure
　　Step 1-B1. The AMF 70 which is associated with the SMF 71 or UPF 72 is configured or updated to support the Ambient IoT service.
　　Step 1-B2. The AMF 70 sends the AMF Configuration Update message to the RAN 501 including at least one of Ambient IoT support, Supported Service IDs and Supported TMGIs.
　　The following bullets explain each parameter in detail.
　　　　・Ambient IoT support: Refer to step 1-A3.
　　　　・Supported Service IDs: Refer to step 1-A3.
　　　　・Supported TMGIs: Refer to step 1-A3.
　　The above-mentioned parameter(s) in step 1-B2 (e.g. the parameter(s) in the message of step 1-B2) may be expressed as parameter(s) or data or information for the Ambient IoT or for the Ambient IoT communication or for the Ambient IoT service.
　　The above-mentioned parameter(s) in step 1-B2 (e.g. the parameter(s) in the message of step 1-B2) may be expressed as parameter(s) or data or information related to the Ambient IoT or related to the Ambient IoT communication or related to the Ambient IoT service.
　　Step 1-B3. Upon reception of the AMF Configuration Update message in step 1-B2, the RAN 501 sends the AMF Configuration Update Acknowledge to the AMF 70 including at least one of Ambient IoT support, Supported Ambient IoT profiles, Supported Service IDs, and Supported TMGIs.
　　The following bullets explain each parameter in detail.
　　　　・Ambient IoT support: Refer to step 1-A2.
　　　　・Supported Ambient IoT profiles: Refer to step 1-A2.
　　　　・Supported Service IDs: Refer to step 1-A2.
　　　　・Supported TMGIs: Refer to step 1-A2.
　　The above-mentioned parameter(s) in step 1-B3 (e.g. the parameter(s) in the message of step 1-B3) may be expressed as parameter(s) or data or information for the Ambient IoT or for the Ambient IoT communication or for the Ambient IoT service.
　　The above-mentioned parameter(s) in step 1-B3 (e.g. the parameter(s) in the message of step 1-B3) may be expressed as parameter(s) or data or information related to the Ambient IoT or related to the Ambient IoT communication or related to the Ambient IoT service.
　　Step 2. The AMF 70 sends the Nudm_SDM_ModifySubscription message to the UDM 75 including at least one of Ambient IoT support, Supported Ambient IoT profiles, Supported Service IDs and Supported TMGIs.
　　The following bullets explain each parameter in detail.
　　　　・Ambient IoT support: The Ambient IoT support indicates that the AMF 70 and associated RAN 501 support the Ambient IoT service and the Ambient IoT service-related procedures as disclosed by this disclosure. For example, the Ambient IoT support in step 2 may include the Ambient IoT support in step 1-A2 or step 1-B3. For example, the Ambient IoT support in step 2 may include the Ambient IoT support in step 1-A3 or step 1-B2.
　　　　・Supported Ambient IoT profiles: The Supported Ambient IoT profiles indicates that Supported Ambient IoT profiles that are supported by the AMF 70 and associated RAN 501. The Supported Ambient IoT profiles may be configured as a list of Supported Ambient IoT profiles.
　　　　For example, the Supported Ambient IoT profiles in step 2 may include the Supported Ambient IoT profiles in step 1-A2 or step 1-B3.
　　　　For example, the Supported Ambient IoT profiles in step 2 may include the Supported Ambient IoT profiles that are supported by the AMF 70.
　　　　For example, the Supported Ambient IoT profiles may include at least one data in the Ambient IoT profile described in step 2 of Fig. 3. For example, the Supported Ambient IoT profiles may include the Ambient IoT profile regarding the AMF 70 and the RAN 501. The Ambient IoT profile regarding the AMF 70 and the RAN 501 may include at least one of data in the Ambient IoT profile described in step 2 of Fig. 3.
　　　　For example, the Supported Ambient IoT profiles may include the Ambient IoT profile(s) for the UE(s) 3 that the AMF 70 supports.
　　　　For example, the Supported Ambient IoT profiles may include the Ambient IoT profile(s) for the UE(s) 3 that the RAN 501 supports.
　　　　・Supported Service IDs: The Supported Service IDs indicates that Service IDs that are supported by the AMF 70 and associated RAN 501. The Supported Service IDs may be configured as a list of Supported Service IDs.
　　　　For example, the Supported Service IDs in step 2 may include the Supported Service IDs in steps 1-A2 and step 1-A3.
　　　　For example, the Supported Service IDs in step 2 may include the Supported Service IDs in steps 1-B2 and step 1-B3.
　　　　・Supported TMGIs: The Supported TMGIs indicates that TMGIs that are supported by the AMF 70 and associated RAN 501. The TMGIs may be configured as a list of TMGIs. The TMGI may be called as Multicast MBS group.
　　　　For example, the Supported TMGIs in step 2 may include the Supported TMGIs in steps 1-A2 and step 1-A3.
　　　　For example, the Supported TMGIs in step 2 may include the Supported TMGIs in steps 1-B2 and step 1-B3.
　　The above-mentioned parameter(s) in step 2 (e.g. the parameter(s) in the message of step 2) may be expressed as parameter(s) or data or information for the Ambient IoT or for the Ambient IoT communication or for the Ambient IoT service.
　　The above-mentioned parameter(s) in step 2 (e.g. the parameter(s) in the message of step 2) may be expressed as parameter(s) or data or information related to the Ambient IoT or related to the Ambient IoT communication or related to the Ambient IoT service.
　　Step 3. The UDM 75 stores the AMF 70 as an Ambient IoT supporting AMF and received parameters by associating with the AMF 70.
　　Step 4. The UDM 75 may send the Nnef_Config_Update message to the NEF 79 including at least one of Ambient IoT support, Supported Ambient IoT profiles, Supported Service IDs and Supported TMGIs.
　　The following bullets explain each parameter in detail.
　　　　・Ambient IoT support: The Ambient IoT support indicates that the UDM 75 supports the Ambient IoT service and the Ambient IoT service-related procedures as disclosed by this disclosure.
　　　　・Supported Ambient IoT profiles: The Supported Ambient IoT profiles indicates that Supported Ambient IoT profiles that are supported by the UDM 75. The Supported Ambient IoT profiles may be configured as a list of Supported Ambient IoT profiles. For example, the Supported Ambient IoT profiles may include at least one data in the Ambient IoT profile described in step 2 of Fig. 3. For example, the Supported Ambient IoT profiles may include the Ambient IoT profile regarding the UDM 75. The Ambient IoT profile regarding the UDM 75 may include at least one of data in the Ambient IoT profile described in step 2 of Fig. 3.
　　　　For example, the Supported Ambient IoT profiles may include the Ambient IoT profile(s) for the UE(s) 3 that the UDM 75 supports.
　　　　・Supported Service IDs: The Supported Service IDs indicates that Service IDs that are supported by the UDM 75, The Supported Service IDs may be configured as a list of Supported Service IDs. For example, the Supported Service IDs may indicate Service ID(s) for the Service(s) (e.g. the Ambient IoT service(s)) that is supported by the UDM 75.
　　　　・Supported TMGIs: The Supported TMGIs indicates that TMGIs that are supported by the UDM 75. The TMGIs may be configured as a list of TMGIs. The TMGI may be called as Multicast MBS group. For example, the Supported TMGIs may indicate TMGI(s) indicating the group of the Ambident IoT device(s) (e.g. UE(s) 3) that is supported by the UDM 75. For example, the Supported TMGIs may indicate TMGI(s) regarding the group of the Ambident IoT device(s) (e.g. UE(s) 3) that is supported by the UDM 75.
　　The above-mentioned parameter(s) in step 4 (e.g. the parameter(s) in the message of step 4) may be expressed as parameter(s) or data or information for the Ambient IoT or for the Ambient IoT communication or for the Ambient IoT service.
　　The above-mentioned parameter(s) in step 4 (e.g. the parameter(s) in the message of step 4) may be expressed as parameter(s) or data or information related to the Ambient IoT or related to the Ambient IoT communication or related to the Ambient IoT service.
　　Step 5. The NEF 79 stores UDM 75 as an Ambient IoT supporting UDM and received parameters by associating with the UDM 75.
　　Step 6. The NEF 79 sends the Nnef_Config_Update Response message to the UDM 75.
　　Step 7. The UDM 75 sends the Nudm_SDM_ModifySubscription Response message to the AMF 70.
　　For example, the RAN 501 may perform a Radio configuration notification procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1-A1, 1-A2, 1-A3, 1-B2 and 1-B3.
　　For example, the RAN 501 may perform at least one of steps 1-A1, 1-A2, 1-A3, 1-B2 and 1-B3 for the Radio configuration notification procedure.
　　For example, the AMF 70 may perform a Radio configuration notification procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1-A2, 1-A3, 1-B1, 1-B2, 1-B3, 2 and 7.
　　For example, the AMF 70 may perform at least one of steps 1-A2, 1-A3, 1-B1, 1-B2, 1-B3, 2 and 7 for the Radio configuration notification procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the UDM 75 may perform a Radio configuration notification procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one steps 2 to 4, 6 and 7.
　　For example, the UDM 75 may perform at least one steps 2 to 4, 6 and 7 for the Radio configuration notification procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the NEF 79 may perform a Radio configuration notification procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 4 to 6.
　　For example, the NEF 79 may perform at least one of steps 4 to 6 for the Radio configuration notification procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
Variant 1 of Sixth scenario in First example of the First Aspect:
　　The message in step 1-A2 may be a NG Setup Request message.
　　The message in step 1-A3 may be a NG Setup Response message.
Variant 2 of Sixth scenario in First example of the First Aspect:
　　The message in steps 2 and 7 may be another existing UDM service message or new UDM service message.
Variant 3 of Sixth scenario in First example of the First Aspect:
　　The message in steps 4 and 6 may be another existing NEF service message or new NEF service message.
Variant 4 of Sixth scenario in First example of the First Aspect:
　　The step 1-A1 may be optionally performed (or omitted) depending on the type of Radio Cell 502. In one example of a case where the step 1-A1 is omitted, the Radio Cell 502 may be the RU, the repeater or the RSU. In this case, the RAN 501 may perform the necessary configuration update even without sending a message to the Radio Cell 502.
Seventh scenario in First example of the First Aspect:
　　Fig. 8 includes an example of the Ambient IoT Service Activation procedure.
　　The detailed processes of the Seventh scenario in First example of the First Aspect are described below with reference to Fig. 8.
　　Step 0. The UE 3 is registered to the AMF 70 and a dedicated PDU Session for the Ambient IoT service has been established with the SMF 71 and the UPF 72. The step 0 may be same to step 0 in Fig. 5.
　　Step 1. The AF 201 decides to start the Ambient IoT service activation. For example, the AF 201 may decide to start the Ambient IoT service for example, a gate-in inventory, Inventory at a warehouse, a gate-out inventory as described in NPL 2.
　　Step 2. The AF 201 sends the Nnef_IoT_Service_Request message to the NEF 79 including at least one of TMGI, Service, Service order, Location and Ambient IoT profiles. The Ambient IoT profiles may be included by the AF 201 if the Ambient IoT profile corresponds to the Service which has been updated lately.
　　The following bullets explain each parameter in detail.
　　　　・TMGI: The TMGI is an acronym of Temporary Mobile Group Identity. The TMGI is used to trigger the Ambient IoT device to start the Ambient IoT communication. The TMGI represents a group of Ambient IoT devices. Each Ambient IoT device may be associated with one TMGI or multiple TMGIs. The TMGI may be called as Multicast MBS group.
　　　　・Service: The Service corresponds to the Ambient IoT service. Refer to Fifth scenario in First example of the First Aspect.
　　　　・Service order: Refer to Fifth scenario in First example of the First Aspect.
　　　　・Location: The location indicates the location where the AF 201 requests to apply the Service. Location can be a geographical location. For example, Location can be a list of Tracking Area Identity (TAI), a list of NR Cell Global Identity (NCGI) as defined in NPL 9, a list of NR Cell Identity (NCI) as defined in NPL 9, a list of E-UTRAN Cell Global Identifier (ECGI) as defined in NPL 9, a list of Global Cable Identifier (GCI) as defined in NPL 9, a general City name, zip-code, formed with GPS location or a location expressed with civic and geospatial location formats as defined in NPL 10.
　　　　・Ambient IoT profiles: Refer to Second scenario in First example of the First Aspect for the Ambient IoT profile. Ambient IoT profiles may be a list of Ambient IoT profile. Multiple Ambient IoT profiles are configured by the AF 201 when the AF 201 recognizes that Ambient IoT devices subject for the Service may support different air interface for the Ambient IoT communication.
　　The above-mentioned parameter(s) in step 2 (e.g. the parameter(s) in the message of step 2) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　The parameter(s) in the message of step 2 may be related each other. For example, in a case where TMGI#1 and Service#1 are included in the message of step 2, it may mean that the service(s) (e.g. the Ambient IoT service(s)) indicated by Service#1 is requested for the group of Ambient IoT device(s) (e.g. the group of UE(s) 3) indicated by TMGI#1.
　　Step 3. Upon reception of the Nnef_IoT_Service_Request message from the AF 201 in step 2, the NEF 79 converts the received Service to a Service ID. The Service ID may be a common value among operator networks or a unique value only valid in the PLMN or the NPN where the NEF 79 belongs to.
　　For example, in this disclosure, the NEF 79 may have information for converting the received Service to the Service ID in advance.
　　For example, in this disclosure, the NEF 79 may receive the information for converting the received Service to the Service ID from other network node(s).
　　Step 4. Upon the reception of the Nnef_IoT_Service_Request message from the AF 201 (or in a case where the NEF 79 converts the received Service to the Service ID), the NEF 79 sends the Nudm_SDM_Get Request message to the UDM 75 including at least one of the TMGI, Service ID, Location and Ambient IoT profiles. The TMGI, Location and Ambient IoT profile in step 4 are ones received from the AF 201. The Service ID in step 4 is one converted by the NEF 79 in step 3.
　　The above-mentioned parameter(s) in step 4 (e.g. the parameter(s) in the message of step 4) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 5. Upon the reception of the Nudm_SDM_Get Request message from the NEF 79, the UDM 75 performs at least one of the following actions:
　　　　If the Location is received, the UDM 75 finds AMFs that covers the received Location. If the Location spans to areas where the PLMN of the UDM 75 does not cover, the UDM 75 finds VPLMNs where the PLMN has service agreement for the Ambient IoT Service represented by the received in the Service ID.
　　　　In a case where the UDM 75 has been notified in advance a support of Service ID from the AMF 70 and the received Service ID corresponds to that Service ID (e.g. in a case where the UDM 75 has received the Service ID from the AMF 70 in advance, and the received Service ID from the AMF 70 corresponds to the received Service ID from the NEF 79 in step 4), the UDM 75 provides all notified AMF(s) 70 to the NEF 79 for the Service ID (e.g. the UDM 75 may provide, to the NEF 79, information regarding the AMF 70 which sends the Service ID to the UDM 75).
　　　　If the received Ambient IoT profiles corresponding to the Service ID are different from one in the UDM 75, the UDM 75 updates the Ambient IoT profiles corresponding to the Service ID in the storage of the UDM 75. The UDM 75 may store or receive from other network node(s) in advance information indicating correspondence between the Ambient IoT profiles and the Service ID. The Ambient IoT profiles may be related to the Service ID.
　　The UDM 75 sends the Nudm_SDM_Get Response message to the NEF 79 including at least one of list of AMF(s), list of PLMN ID, Location and Ambient IoT profiles. The Ambient IoT profiles may be provided if the NEF 79 does not provide the Ambient IoT profiles to the UDM 75 in step 4 and the UDM 75 holds the Ambient IoT profiles for the Service ID.
　　For example, the list of AMF(s) may include AMF(s) which supports the Service ID or the Ambient IoT service indicated by the Service ID.
　　For example, the list of AMF(s) may include AMF(s) which is found by the UDM 75.
　　For example, the list of PLMN ID may include PLMN ID(s) of PLMN(s) which supports the Service ID or the Ambient IoT service indicated by the Service ID.
　　The above-mentioned parameter(s) in step 5 (e.g. the parameter(s) in the message of step 5) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 6. Upon reception of the Nudm_SDM_Get Response message from the UDM 75, the NEF 79 sends the Namf_Communication_NonUeN2MessageTransfer message to the AMF 70 (e.g. to the AMF 70 indicated by the list of AMF(s) in step 5) including at least one of the TMGI, Service ID, Service order, Location, Ambient IoT profiles. The NEF 79 sends multiple Namf_Communication_NonUeN2MessageTransfer messages to all AMFs if the NEF 79 receives multiple AMFs from the UDM 75 in step 5.
　　If the NEF 79 receives PLMN IDs (e.g. the list of PLMN ID) from the UDM 75, the NEF 79 may send the Nnef_IoT_Service_Request message (e.g. the Nnef_IoT_Service_Request message may be one received from the AF 201), to an NEF in a PLMN that corresponds to the received PLMN ID from the UDM 75.
　　For example, in a case where the NEF 79 does not receive the list of AMF in step 5 from the UDM 75, the NEF 79 may find appropriate AMF (e.g. the AMF 70) for the Service ID, and send the Namf_Communication_NonUeN2MessageTransfer message to the appropriate AMF.
　　For example, the NEF 79 may store or receive in advance from other network node(s) information for finding the appropriate AMF.
　　The above-mentioned parameter(s) in step 6 (e.g. the parameter(s) in the message of step 6) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 7. Upon reception of the Namf_Communication_NonUeN2MessageTransfer message from the UDM 75, the AMF 70 finds the corresponding TAI(s) and associated RAN(s) 501 to the Service ID or TMGI or the Service ID and TMGI. The AMF 70 may store or receive in advance from other network node(s) information for finding the corresponding TAI(s) and associated RAN(s) 501.
　　The AMF 70 sends a non-UE associated signalling, for example the DOWNLINK RAN CONFIGURATION TRANSFER message, to the RAN 501 (e.g. the associated RAN 501) including at least one of the TMGI, Service ID, Service order, TAI(s) (e.g. the corresponding TAI(s)), Ambient IoT profiles. The AMF 70 sends multiple DOWNLINK RAN CONFIGURATION TRANSFER messages to all RANs 501 if the AMF 70 finds multiple RANs 501 that corresponds to the Service ID or TMGI or Service ID and TMGI.
　　In one example, the DOWNLINK RAN CONFIGURATION TRANSFER message may be a Class 2 procedure signaling message, and the DOWNLINK RAN CONFIGURATION TRANSFER message may be called as Group Page message, Ambient IoT Page message or Ambient IoT Group Page message.
　　The above-mentioned parameter(s) in step 7 (e.g. the parameter(s) in the message of step 7) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 8. Upon reception of the DOWNLINK RAN CONFIGURATION TRANSFER message from the AMF 70, the RAN 501 sends the Configuration update message to Radio Cell 502 including at least one of the TMGI, Service ID, Service order, TAI(s) and Ambient IoT profiles. The RAN 501 sends multiple Configuration update messages to all Radio Cells 502 if the RAN 501 finds multiple Radio Cells 502 that corresponds to the Service ID or TMGI or Service ID and TMGI.
　　In one example, the RAN 501 sends the Configuration update message to Radio Cell(s) 502 that supports the received Ambient IoT profiles from the AMF 70.
　　In one another example, the Configuration update message may be called as a Group Page message, Ambient IoT Page message or Ambient IoT Group Page message.
　　The above-mentioned parameter(s) in step 8 (e.g. the parameter(s) in the message of step 8) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 9. Steps 1-2 to 4 in Fig. 5 take place.
　　For example, in a case where the RAN 501 receives the message in step 7, the RAN 501 may perform the energy feeding for the UE 3 via the Radio Cell 502, and may send at least one of the TMGI, Service ID, Service order, TAI(s) and Ambient IoT profiles to the UE 3 via the Radio Cell 502. The sending at least one of the TMGI, Service ID, Service order, TAI(s) and Ambient IoT profiles may be corresponding to the Service request in step 2 of Fig. 5.
　　Step 10. The UE 3 sends the RRC Message number 3 message to the RAN 501 including at least one of Ambient IoT device type and Dedicated NAS. The Ambient IoT device type indicates to the RAN 501 that the UE 3 is Ambient IoT device.
　　The Dedicated NAS includes the Control Plane Service Request message including MO-data. The MO-data may be embedded in the CIoT small data container or CIoT user data container. The MO-data may be an Ambient IoT related data from the UE 3 for the Ambient IoT communication.
　　In one example, the Ambient IoT application in the UE 3 provides the MO-data.
　　The RRC Message number 3 message may include the TMGI.
　　The Control Plane Service Request message may include at least one of the User ID (e.g. an identifier of the UE 3), Ambient IoT device type, GPSI, List of active TMGI. The definition of the User ID in Fig. 4 may be applied to the User ID in step 10.
　　The above-mentioned parameter(s) in step 10 (e.g. the parameter(s) in the message of step 10) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　The above-mentioned parameter(s) in step 10 (e.g. the parameter(s) in the message of step 10) may be expressed as parameter(s) or data or information for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 11. Upon reception of the RRC Message number 3 message from the UE 3, the RAN 501 sends the Initial UE message to the AMF 70 including at least one of the Ambient IoT device type and NAS-PDU. The NAS-PDU includes the Control Plane Service Request message that is received in the Dedicated NAS in Step 10.
　　In one example, the MO-data in the Control Plane Service Request message is security protected using the NAS security context. In this case, the AMF 70 decodes the protected message using the NAS security context.
　　The above-mentioned parameter(s) in step 11 (e.g. the parameter(s) in the message of step 11) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　The above-mentioned parameter(s) in step 11 (e.g. the parameter(s) in the message of step 11) may be expressed as parameter(s) or data or information for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 12. Steps 8 to 12 in Fig. 5 take place.
　　Steps 13. The AMF 70 sends the Service Accept message to the UE 3 including MT-data. The MT-data may be an Ambient IoT related data to the UE 3 for the Ambient IoT communication.
　　If the UE 3 receives the MT-data in the Service Accept message, the UE 3 sends the received MT-data to the Ambient IoT application in the UE 3.
　　The above-mentioned parameter(s) in step 13 (e.g. the parameter(s) in the message of step 13) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　The above-mentioned parameter(s) in step 13 (e.g. the parameter(s) in the message of step 13) may be expressed as parameter(s) or data or information for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　For example, the UE 3 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 0, 9, 10 and 13.
　　For example, the UE 3 may perform at least one of steps 0, 9, 10 and 13 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the Radio Cell 502 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 8 and 9.
　　For example, the Radio Cell 502 may perform at least one of steps 8 and 9 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the RAN 501 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 7, 8, 10 and 11.
　　For example, the RAN 501 may perform at least one of steps 7, 8, 10 and 11 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the AMF 70 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 6, 7, 11, 12 and 13.
　　For example, the AMF 70 may perform at least one of steps 6, 7, 11, 12 and 13 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the UDM 75 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 4 and 5.
　　For example, the UDM 75 may perform at least one of steps 4 and 5 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the NEF 79 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 2 to 6.
　　For example, the NEF 79 may perform at least one of steps 2 to 6 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the AF 201 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1, 2 and 12.
　　For example, the AF 201 may perform at least one of steps 1, 2 and 12 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
Variant 1 of Seventh scenario in First example of the First Aspect:
　　In a case where the AMF 70's control plane load from Ambient IoT Device communication reaches an overload threshold (which is indicated by the SMF 71 or the AMF 70 itself), the AMF 70 may decide to restrict the load caused by Ambient IoT Devices. In this case, the AMF 70 may send the Overload Start message to the RAN 501 including the Ambient IoT Communication overload. The Overload Start message including the Ambient IoT Communication overload may indicate that the overload occurs due to the Ambient IoT Device communication.
　　If the Overload Start message includes the Ambient IoT Communication overload, the RAN 501 may reject the RRC Message number 3 in step 10. In this case, the RAN 501 may send the RRC Connection Reject message or the RRC Connection Release message to the UE 3 including Ambient IoT back-off timer and a cause value indicating the Ambient IoT Communication overload (e.g. cause value indicating that the overload occurs due to the Ambient IoT Device communication).
　　When the UE 3 receives the RRC Connection Reject message or the RRC Connection Release message from the RAN 501, the UE 3 may restrict any communication towards the network for the Ambient IoT service for the duration of the Ambient IoT back-off timer.
Variant 2 of Seventh scenario in First example of the First Aspect:
　　After step 3, the NEF 79 may initiate the Authentication and Authorization procedure with the UDM 75.
Variant 3 of Seventh scenario in First example of the First Aspect:
　　The message in step 2 may be another existing NEF service message or new NEF service message.
Variant 4 of Seventh scenario in First example of the First Aspect:
　　The message in steps 4 and step 5 may be another existing UDM service message or new UDM service message.
Variant 5 of Seventh scenario in First example of the First Aspect:
　　The message in step 6 may be another existing AMF service message or new AMF service message.
Variant 6 of Seventh scenario in First example of the First Aspect:
　　The step 8 may be optionally performed (or omitted) depending on the type of Radio Cell 502. In one example of a case where the step 8 is omitted, the Radio Cell 502 may be the RU, the repeater or the RSU. In this case, the RAN 501 may perform the necessary configuration update even without sending a message to the Radio Cell 502.
Eighth scenario in First example of the First Aspect:
　　Fig. 9 includes an example of the Ambient IoT device-initiated Service Activation procedure.
　　The detailed processes of the Eighth scenario in First example of the First Aspect are described below with reference to Fig. 9.
　　Step 0. The UE 3 is registered to the AMF 70 and a dedicated PDU Session for the Ambient IoT service has been established with the SMF 71 and the UPF 72. The step 0 may be same to step 0 in Fig. 5.
　　Step 1. The Ambient IoT Application in the UE 3 sends an uplink data (e.g. MO-data) to lower layer of the UE 3 and the uplink data is buffered in the UE 3. The MO-data may be an Ambient IoT related data from the UE 3 for the Ambient IoT communication. The MO-data may be data for the Ambient IoT. The MO-data may be data for the Ambient IoT communication or for the Ambient IoT service.
　　Step 2. Steps 9 to 13 in Fig. 8 take place.
　　For example, the Radio Cell 502 may send a signal for feeding the energy for the UE 3. For example, the Radio Cell 502 may send a signal for feeding the energy for the UE 3 periodically.
　　For example, in a case where the UE 3 has had enough energy to perform step 2, the UE 3 may perform step 2. For example, in a case where the UE 3 has a battery, the battery in the UE 3 have been charged by harvesting energy by receiving the signal from the Radio Cell 502. For example, in a case where the UE 3 does not have a battery, the UE 3 performs step 2 using energy being harvested by receiving the signal from the Radio Cell 502.
　　For example, the UE 3 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 0 to 2.
　　For example, the UE 3 may perform at least one of steps 0 to 2 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
Second example of the First Aspect:
　　Fig. 10 includes an example of an architecture that supports ambient IoT devices.
　　The UE 301 in Fig. 10 represents an ambient IoT device. In addition that the UE 301 supports Uu interface, the UE 301 may support a radio interface specific to the ambient IoT device communication. Similarly, in addition that the UE-to-Network Relay UE 303 (e.g. the UE-to-Network Relay UE 30301 and the UE-to-Network Relay UE 30302) supports Uu interface, the UE-to-Network Relay UE 303 (e.g. the UE-to-Network Relay UE 30301 and the UE-to-Network Relay UE 30302) supports the radio interface specific to the ambient IoT device communication.
　　The radio interface specific to the Ambient IoT device communication is disclosed in the Second Aspect. Although the UE-to-Network Relay UE 30301 and the UE-to-Network Relay UE 30302 are illustrated in the Warehouse #A as an example, the UE-to-Network Relay UE 30301 and the UE-to-Network Relay UE 30302 may be located in public space.
　　The UE 301 supports the PC 5 interface as defined in NPL 11. The UE 301 communicates with the UE-to-Network Relay UE 30301 and the UE-to-Network Relay UE 30302 using the PC 5 interface.
　　The AF 20101 represents an application server in the data network. For example, the AF 20101 may trigger a task to collect status of the Ambient IoT devices.
　　The AF 20102 represents an application server in the data network. For example, the AF 20102 may be a server that collects status of the Ambient IoT devices.
　　The AF 20101 and the AF 20102 may be combined as one Application Function.
　　The AF 20101 and the AF 20102 may be collocated at the same location or located different location and different network domain. For example, the AF 20101 is located at an Ambient IoT device control centre while the AF 20102 is located at an Ambient IoT device data centre.
First scenario in Second example of the First Aspect:
　　Fig. 11 includes an example of the Identity management model for Ambient IoT device using the Proximity based Services (ProSe) as defined in NPL 11.
　　The Identity management model for Ambient IoT device is characterized as the following features.
Ambient IoT device identity
　　An Ambient IoT device identity may be represented as GPSI.
Group identity of the Ambient IoT device
　　The Ambient IoT device identity may have one or multiple Application Layer Group ID(s).
　　The Application Layer Group ID represents a group of the Ambident IoT device.
　　The Application Layer Group ID may be preconfigured in the UE 301 by the Service provider.
　　The Application Layer Group ID may be preconfigured in the UE-to-Network Relay UE 303 (e.g. at least one of the UE-to-Network Relay UE 30301 and the UE-to-Network Relay UE 30302) by the PLMN or NPN operator.
　　When the AF 201 (at least one of the AF 20101 and the AF 20102) triggers a data communication with all group members represented by the Application Layer Group ID, the AF 201 communicates with the UE-to-Network Relay UE 303 for trigging the Ambient IoT communication. For example, in a case where the AF 201 wants to communication with the group members, the AF 201 may perform a procedure for communicating with the group members using the Application Layer Group ID.
　　The ProSe Layer-2 Group ID corresponds to the Application Layer Group ID. For example, the ProSe Layer-2 Group ID may be related to the Application Layer Group ID.
　　The ProSe Layer-2 Group ID may be preconfigured in the UE 301 by the Service provider.
　　The ProSe Layer-2 Group ID may be preconfigured in the UE-to-Network Relay UE 303 by the PLMN or NPN operator.
Second scenario in Second example of the First Aspect:
　　The Second scenario in Second example of the First Aspect discloses an example of the Ambient IoT device management procedures.
　　There are two management procedures between the AF 201 and the UE-to-Network Relay UE 303, one is an Ambient IoT management data provisioning to the UE-to-Network Relay UE 303 and another one is an Ambient IoT Service Activation.
　　Fig. 12 includes the both procedures.
　　The detailed processes of the Second scenario in Second example of the First Aspect are described below with reference to Fig. 12.
　　Step 0. The UE 301 is registered to the AMF 70 and a dedicated PDU Session for the Ambient IoT service has been established with the SMF 71 and the UPF 72. The step 0 may be same to step 0 in Fig. 5.
Ambient IoT management data provisioning
　　Step 1. When the Ambient IoT Service application in the AF 201 determines to provide the Ambient IoT device management data to the UE-to-Network Relay UE 303, the AF 201 provides at least one of the Application Layer Group ID, ProSe Layer-2 Group IDs and Ambient IoT profiles to the UE-to-Network Relay UE 303 over user plane that is established in step 0.
　　The following bullets explain each parameter in detail.
　　　　・Application Layer Group ID: Refer to First scenario in Second example of the First Aspect.
　　　　・ProSe Layer-2 Group IDs: List of ProSe Layer-2 Group ID. For ProSe Layer-2 Group ID, refer to First scenario in Second example of the First Aspect.
　　　　・Ambient IoT profiles: Refer to Second scenario in First example of the First Aspect for the Ambient IoT profile. Ambient IoT profiles may be a list of Ambient IoT profile. Multiple Ambient IoT profiles are configured by the AF 201 when the AF 201 recognizes that Ambient IoT devices subject for the Service may support different air interface for the Ambient IoT communication.
　　The Ambient IoT device management data may include at least one of the Application Layer Group ID, ProSe Layer-2 Group IDs and Ambient IoT profiles.
　　The above-mentioned parameter(s) in step 1 (e.g. the parameter(s) in the message of step 1) may be expressed as parameter(s) or data or information for the Ambient IoT or for the Ambient IoT communication or for the Ambient IoT service.
　　The above-mentioned parameter(s) in step 1 (e.g. the parameter(s) in the message of step 1) may be expressed as parameter(s) or data or information related to the Ambient IoT or related to the Ambient IoT communication or related to the Ambient IoT service.
Ambient IoT Service Activation
　　Step 2. The Ambient IoT Service application in the AF 201 determines to start the Ambient IoT service activation. For example, one reason of this determination may be an inventory for goods. For example, the AF 201 may decide to start the Ambient IoT service for example, a gate-in inventory, Inventory at a warehouse, a gate-out inventory as described in NPL 2.
　　Step 3. The AF 201 provides at least one of the ProSe Layer-2 Group IDs, Service and Service order to the UE-to-Network Relay UE 303 over user plane that is established in step 0.
　　The following bullets explain each parameter in detail.
　　　　・ProSe Layer-2 Group IDs: List of ProSe Layer-2 Group ID. For ProSe Layer-2 Group ID, refer to First scenario in Second example of the First Aspect.
　　　　・Service: Refer to Fifth scenario in First example of the First Aspect. Although not explicitly indicated in this scenario, the TMGI may be used for representing the Service.
　　　　・Service order: Refer to Fifth scenario in First example of the First Aspect.
　　The above-mentioned parameter(s) in step 3 (e.g. the parameter(s) in the message of step 3) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　The UE-to-Network Relay UE 303 may be expressed as a UE-to-Network Relay UE for the Ambient IoT or for the Ambient IoT communication or for the Ambient IoT service.
　　For example, the UE-to-Network Relay UE 303 may perform a device management procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 0, 1 and 3.
　　For example, the UE-to-Network Relay UE 303 may perform at least one of steps 0, 1 and 3 for the device management procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the AF 201 may perform a device management procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1 to 3.
　　For example, the AF 201 may perform at least one of steps 1 to 3 for the device management procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the UE-to-Network Relay UE 303 may perform a procedure for the Ambient IoT management data provisioning by performing at least one of steps 0 and 1.
　　For example, the UE-to-Network Relay UE 303 may perform at least one of steps 0 and 1 for the procedure for the Ambient IoT management data provisioning.
　　For example, the AF 201 may perform a procedure for the Ambient IoT management data provisioning by performing at least step 1.
　　For example, the AF 201 may perform at least step 1 for the procedure for the Ambient IoT management data provisioning.
　　For example, the UE-to-Network Relay UE 303 may perform a procedure for the Ambient IoT Service Activation by performing at least step 3.
　　For example, the UE-to-Network Relay UE 303 may perform at least step 3 for the procedure for the Ambient IoT Service Activation.
　　For example, the AF 201 may perform a procedure for the Ambient IoT Service Activation by performing at least one of steps 2 and 3.
　　For example, the AF 201 may perform at least one of steps 2 and 3 for the procedure for the Ambient IoT Service Activation.
Third scenario in Second example of the First Aspect:
　　The Third scenario in Second example of the First Aspect discloses an example of the Registration procedure for the UE 301. For example, the UE 301 represents the Ambident IoT device.
　　The Registration procedure for the UE 301 is the same as the Registration procedure as disclosed in the Third scenario in First example of the First Aspect with the following replacements.
　　　　The "UE 3" is replaced with the "UE 301".
　　　　The "Radio Cell 502" is replaced with the "Radio Cell 502 or the Radio Cell 502 and the UE-to-Network Relay UE 302" or the "UE-to-Network Relay UE 303".
　　　　The "List of active TMGI" is replaced with "List of active Service". The List of active Service may indicate active Service(s) for the UE 301. The active Service may indicate the Ambient IoT service, for example, a gate-in inventory, Inventory at a warehouse, a gate-out inventory as described in NPL 2. The list of active Service may be known by the AF 201 whether the UE 301 is able to communicate or not with the Service in the list. If the Service is listed in the list, the Service may be used to trigger the UE 301 for the Ambient IoT communication. For example, the List of active Service may indicate the Service(s) that is related to the UE 301. For example, the AF 201 may refer the List of active Service to know whether the UE 301 is able to communicate or not on the Service(s) in the List of active Service. For example, the AF 201 may communicate with the UE 301 by using the Service(s) in the List of active Service. For example, the AF 201 may perform the Ambient IoT, the Ambient IoT communication, the Ambient IoT service with the UE 301 by using the Service(s) in the List of active Service.
　　In addition, the Registration procedure includes additional processes and parameter handlings as described in section 6.6.2 of NPL 11.
Fourth scenario in Second example of the First Aspect:
　　The Fourth scenario in Second example of the First Aspect discloses an example of the Registration procedure for the UE-to-Network Relay UE 303. For example, the UE-to-Network Relay UE 303 represents a combined node including the UE-to-Network Relay UE as defined in NPL 11 and network node dedicated to communicate with the Ambident IoT devices.
　　The Registration procedure for the UE-to-Network Relay UE 303 is the same as the Registration procedure as described in section 6.6.2 of NPL 11.
Fifth scenario in Second example of the First Aspect:
　　Fig. 13 includes an example of the Ambient IoT Service Activation procedure.
　　The detailed processes of the Fifth scenario in Second example of the First Aspect are described below with reference to Fig. 13.
　　Step 0-1. The UE 301 is registered to the AMF 70 and a dedicated PDU Session for the Ambient IoT service has been established with the SMF 71 and the UPF 72.
　　For example, in step 0-1, the process(es) in the Third scenario in Second example of the First Aspect completes and the PDU Session has been established.
　　Step 0-2. The AF 201 provides, to the UE 301, at least one of the GPSI, ProSe Layer-2 Group IDs, List of PLMN, Ambient IoT profile and Report to server address over user plane as disclosed in Fig. 12. The GPSI may be the GPSI of the UE 301. The definition of the List of PLMN, the Ambient IoT profile and the Report to server address in the Second scenario in First example of the First Aspect may be applied to the List of PLMN, the Ambient IoT profile and the Report to server address in step 0-2.
　　The above-mentioned parameter(s) in step 0-2 (e.g. the parameter(s) in the message of step 0-2) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 0-3. The UE-to-Network Relay UE 303 is registered to the AMF 70 and a dedicated PDU Session for the Ambient IoT service has been established with the SMF 71 and the UPF 72.
　　For example, in step 0-3, the process(es) in the Fourth scenario in Second example of the First Aspect completes and the PDU Session has been established.
　　Step 0-4. The AF 201 provides, to the UE-to-Network Relay UE 303, at least one of the Application Layer Group ID, ProSe Layer-2 Group IDs and Ambient IoT profiles over user plane as disclosed in Fig. 12.
　　The above-mentioned parameter(s) in step 0-4 (e.g. the parameter(s) in the message of step 0-4) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 1. The AF 201 provides at least one of the ProSe Layer-2 Group IDs, Service and Service order to the UE-to-Network Relay UE 303 over user plane that is established in step 0-3. Refer to Fig. 12 for parameter details.
　　The above-mentioned parameter(s) in step 1 (e.g. the parameter(s) in the message of step 1) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 2-1. Based on the received Service order in step 1, the UE-to-Network Relay UE 303 decides to start the Ambient IoT communication. For example, if the Validity time in the Service order indicates that the Ambient IoT communication is started at 12:00 the UE-to-Network Relay UE 303 decides to start the Ambient IoT communication at 12:00. For example, based on the received Service in step 1, the UE-to-Network Relay UE 303 may decide to start the Ambient IoT communication. For example, the UE-to-Network Relay UE 303 may decide to start the Ambient IoT communication indicated by the received Service. For example, the UE-to-Network Relay UE 303 may decide to start the Ambient IoT service indicated by the received Service. For example, the UE-to-Network Relay UE 303 may decide to start the Ambient IoT communication related to the Ambient IoT service which is indicated by the received Service.
　　Step. 2-2. The UE-to-Network Relay UE 303 may broadcast energy over the air. Refer to the Aspect 2 for detail of energy broadcasting.
　　Step 2-3. The UE 301 has had enough energy to perform the Ambient IoT communication. For example, if the UE 301 has a battery, the battery in the UE 301 have been charged by harvesting energy by receiving the broadcasted energy by Step 2-2. For example, if the UE 301 does not have a battery, the UE 301 performs the Ambient IoT communication using energy being harvested by receiving the broadcasted energy by Step 2-2.
　　Step 3. The UE-to-Network Relay UE 303 broadcasts the Group Member Discovery Solicitation message over the PC 5 interface including the ProSe Layer-2 Group ID. For the ProSe Layer-2 Group ID, refer to the First scenario in Second example of the First Aspect.
　　The above-mentioned parameter(s) in step 3 (e.g. the parameter(s) in the message of step 3) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 4. If the UE 301 receives the Group Member Discovery Solicitation message over the PC 5 interface, the UE 301 sends the Group Member Discovery Response message to the UE-to-Network Relay UE 303 including at least one of Source Layer-2 ID, GPSI and MO-data.
　　The following bullets explain each parameter in detail.
　　　　・Source Layer-2 ID: The Source Layer-2 ID is an identifier of the UE 301 over the PC5 interface.
　　　　・GPSI: Refer to Fig. 3.
　　　　・MO-data: The MO-data may be an Ambient IoT related data from the UE 301 for the Ambient IoT communication.
　　　　・The above-mentioned parameter(s) in step 4 (e.g. the parameter(s) in the message of step 4) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
The above-mentioned parameter(s) in step 4 (e.g. the parameter(s) in the message of step 4) may be expressed as parameter(s) or data or information for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 5. The UE-to-Network Relay UE 303 sends the received data (e.g. at least one of the Source Layer-2 ID, GPSI and MO-data) from the UE 301 in step 4 to the AF 201 over the user plane that is established in step 0-3.
　　In one example, the UE-to-Network Relay UE 303 may generate a data with agreed data format with the AF 201 based on the received data in Step 4 and send it to the AF 201.
　　Step 6. In a case where the UE-to-Network Relay UE 303 receives the MT-data from the AF 201 in step 5, the UE-to-Network Relay UE 303 sends the Unicast notification message to the UE 301 including at least one of Source Layer-2 ID and MT-data.
　　The following bullets explain each parameter in detail.
　　　　・Source Layer-2 ID: Refer to Step 4.
　　　　・MT-data: The MT-data may be an Ambient IoT related data from the AF 201 for the Ambient IoT communication.
　　For example, in step 5, the AF 201 may send the MT-data to the UE-to-Network Relay UE 303.
　　For example, the UE 301 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 0-1, 0-2, 2-2, 2-3, 3, 4 and 6.
　　For example, the UE 301 may perform at least one of steps 0-1, 0-2, 2-2, 2-3, 3, 4 and 6 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the UE-to-Network Relay UE 303 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 0-3, 0-4, 1, 2-1, 2-2, 3, 4, 5 and 6.
　　For example, the UE-to-Network Relay UE 303 may perform at least one of steps 0-3, 0-4, 1, 2-1, 2-2, 3, 4, 5 and 6 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the AF 201 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 0-2, 0-4, 1 and 5.
　　For example, the AF 201 may perform at least one of steps 0-2, 0-4, 1 and 5 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
Variant 1 of Fifth scenario in Second example of the First Aspect:
　　Instead of Steps 3 to 5, the UE 301 may communicate with the AF 201 using user plane between the UE 301 and AF 201. In this case, the Steps 9 to 13 in Fig. 8 take place with the following replacements:
　　　　The "UE 3" is replaced with the "UE 301".
　　　　The "Radio Cell 502" is replaced with the "Radio Cell 502 or the Radio Cell 502 and the UE-to-Network Relay UE 303" or the "UE-to-Network Relay UE 303".
　　　　The "TMGI" is replaced with the "Application Layer Group ID" or the "ProSe Layer-2 Group ID".
　　　　The "List of active TMGI" is replaced with the "List of active Application Layer Group ID" or the "List of active ProSe Layer-2 Group ID".
　　　　The List of active Application Layer Group ID indicates active Application Layer Group ID(s) in the UE 301. The List of active Application Layer Group ID may be known by the AF 201 whether the UE 301 is able to communicate or not with an Application Layer Group ID in the list. If the Application Layer Group ID is listed in the List of active Application Layer Group ID, the Application Layer Group ID may be used to trigger the UE 301 for the Ambient IoT communication. For example, the List of active Application Layer Group ID may indicate Application Layer Group ID(s) that is related to the UE 301. For example, the List of active Application Layer Group ID may indicate Application Layer Group ID(s) that is assigned to the UE 301. For example, the AF 201 may refer the List of active Application Layer Group ID to know whether the UE 301 is able to communicate or not by using the Application Layer Group ID(s) in the List of active Application Layer Group ID. For example, the AF 201 may communicate with the UE 301 by using the Application Layer Group ID(s) in the List of active Application Layer Group ID. For example, the AF 201 may perform the Ambient IoT, the Ambient IoT communication, the Ambient IoT service with the UE 301 by using the Application Layer Group ID(s) in the List of active Application Layer Group ID.
　　　　The List of active ProSe Layer-2 Group ID indicates active ProSe Layer-2 Group ID(s) in the UE 301. The List of active ProSe Layer-2 Group ID may be known by the AF 201 whether the UE 301 is able to communicate or not with a ProSe Layer-2 Group ID in the list. If the ProSe Layer-2 Group ID is listed in the List of active ProSe Layer-2 Group ID, the ProSe Layer-2 Group ID may be used to trigger the UE 301 for the Ambient IoT communication. For example, the List of active ProSe Layer-2 Group ID may indicate ProSe Layer-2 Group ID(s) that is related to the UE 301. For example, the List of active ProSe Layer-2 Group ID may indicate ProSe Layer-2 Group ID(s) that is assigned to the UE 301. For example, the AF 201 may refer the List of active ProSe Layer-2 Group ID to know whether the UE 301 is able to communicate or not by using the ProSe Layer-2 Group ID(s) in the List of active ProSe Layer-2 Group ID. For example, the AF 201 may communicate with the UE 301 by using the ProSe Layer-2 Group ID(s) in the List of active ProSe Layer-2 Group ID. For example, the AF 201 may perform the Ambient IoT, the Ambient IoT communication, the Ambient IoT service with the UE 301 by using the ProSe Layer-2 Group ID(s) in the List of active ProSe Layer-2 Group ID.
Variant 2 of Fifth scenario in Second example of the First Aspect:
　　In step 5, the UE-to-Network Relay UE 303 may collect MO-data from multiple UEs 301 and the UE-to-Network Relay UE 303 sends a bunch of collected data to the AF 201 over the user plane. With this way, user traffic between the UE-to-Network Relay UE 303 and the AF 201 may be decreased.
Sixth scenario in Second example of the First Aspect:
　　The Sixth scenario in Second example of the First Aspect discloses an example of the Ambient IoT device-initiated Service Activation procedure.
　　The Ambient IoT device-initiated Service Activation procedure is the same as the Ambient IoT device-initiated Service Activation procedure as disclosed in the Eighth scenario in First example of the First Aspect with the following replacements.
　　　　The "UE 3" is replaced with the "UE 301".
　　　　The "Radio Cell 502" is replaced with the "Radio Cell 502 or the Radio Cell 502 and the UE-to-Network Relay UE 303" or the "UE-to-Network Relay UE 303".
Third example of the First Aspect:
　　Fig. 14 includes an example of an architecture that supports ambient IoT devices.
　　The UE 3 in the figure represents an ambient IoT device. In addition that the UE 3 supports Uu interface, the UE 3 may support a radio interface specific to the ambient IoT device communication. Similarly, in addition that the IAB Node 502 (e.g. the IAB Node 50201 and the IAB Node 50202) supports Uu interface, the IAB Node 502 (e.g. the IAB Node 50201 and the IAB Node 50202) supports the radio interface specific to the ambient IoT device communication.
　　The radio interface specific to the Ambient IoT device communication is disclosed in the Second Aspect. Although the IAB Node 50201 and the IAB Node 50202 are illustrated in the Warehouse #A as an example, the IAB Node 50201 and the IAB Node 50202 may be located in public space.
　　The AF 20101 represents an application server in the data network. For example, the AF 20101 may trigger a task to collect status of the Ambient IoT devices.
　　The AF 20102 represents an application server in the data network. For example, the AF 20102 may be a server that collects status of the Ambient IoT devices.
　　The AF 20101 and the AF 20102 may be combined as one Application Function.
　　The AF 20101 and the AF 20102 may be collocated at the same location or located different location and different network domain. For example, the AF 20101 is located at an Ambient IoT device control centre while the AF 20102 is located at an Ambient IoT device data centre.
First scenario in Third example of the First Aspect:
　　The First scenario in Third example of the First Aspect discloses an example of the Identity management model for Ambient IoT device.
　　The Identity management model for Ambient IoT device is the same as the Ambient IoT device-initiated Service Activation procedure as disclosed in the First scenario in First example of the First Aspect with the following replacements.
　　　　The "Radio Cell 502" is replaced with the "IAB Node 502".
　　　　The "RAN 501" is replaced with the "IAB Donor 501".
Second scenario in Third example of the First Aspect:
　　The Second scenario in Third example of the First Aspect discloses an example of the Ambient IoT device management procedure of the UE 3 that support the Ambient IoT communication.
　　The Ambient IoT device management procedure of the UE 3 that support the Ambient IoT communication is the same as the Ambient IoT device management procedure of the UE 3 that support the Ambient IoT communication as disclosed in the Second scenario in First example of the First Aspect with the following replacements.
　　　　The "Radio Cell 502" is replaced with the "IAB Node 502".
　　　　The "RAN 501" is replaced with the "IAB Donor 501".
Third scenario in Third example of the First Aspect:
　　The Third scenario in Third example of the First Aspect discloses an example of the Registration procedure of the Ambient IoT device as represented as the UE 3.
　　The Registration procedure of the UE 3 that support the Ambient IoT communication is the same as the Registration procedure of the UE 3 of the UE 3 that support the Ambient IoT communication as disclosed in the Third scenario in First example of the First Aspect with the following replacements.
　　　　The "Radio Cell 502" is replaced with the "IAB Node 502".
　　　　The "RAN 501" is replaced with the "IAB Donor 501".
Fourth scenario in Third example of the First Aspect:
　　The Fourth scenario in Third example of the First Aspect discloses an example of Registration procedure of the Ambient IoT device with the Ambient IoT data communication as represented as the UE 3.
　　The Registration procedure of the Ambient IoT device with the Ambient IoT data communication is the same as the Registration procedure of the Ambient IoT device with the Ambient IoT data communication as disclosed in the Fourth scenario in First example of the First Aspect with the following replacements.
　　　　The "Radio Cell 502" is replaced with the "IAB Node 502".
　　　　The "RAN 501" is replaced with the "IAB Donor 501".
　　　　Steps 1-2 to 4 are replaced with the steps 1 to 5 in Fig. 15.
　　Fig. 15 includes an example of the RRC setup procedure.
　　The detailed processes of the RRC setup procedure.
　　Step 1. The IAB Node 502 broadcasts energy over the air. Refer to the Aspect 2 for detail of energy broadcasting.
　　Step 2. The UE 3 has had enough energy to perform the registration procedure. For example, if the UE 3 has a battery, the battery in the UE 3 have been charged by harvesting energy by receiving the broadcasted energy by Step 1. For example, if the UE 3 does not have a battery, the UE 3 performs the Registration procedure using energy being harvested by receiving the broadcasted energy by Step 1.
　　Step 3. In one example, the IAB Node 502 broadcasts system information with a list of TMGI indicating that the UE 3 is requested to perform the Ambient IoT communication immediately if the UE 3 has an active TMGI in the list of TMGI.
　　In another example, the UE 3 initiates the Ambient IoT communication as far as the UE 3 has enough energy for performing the Registration procedure regardless of receiving the system information in Step 2.
　　The above-mentioned parameter(s) in step 3 (e.g. the parameter(s) in the message of step 3) may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　For example, the IAB Node 502 may broadcast the system information including the list of TMGI. The system information may be expressed as a service request (e.g. a service request for the Ambient IoT, for the Ambient IoT communication or for the Ambient IoT service).
　　Step 4. The UE 3 sends the RRC Setup Request message to the IAB Node 502.
　　For example, in a case where the UE 3 receives the system information including TMGI 1 in step 3 and the UE 3 has the list of TMGI including TMGI 1, the UE 3 may send the RRC Setup Request message to the IAB Node 502.
　　For example, in a case where the UE 3 has enough energy for performing the Registration procedure regardless of receiving the system information in step 2, the UE 3 may send the RRC Setup Request message to the IAB Node 502.
　　For example, IAB Node 502 may send the RRC Setup Request message to the IAB Donor 501.
　　For example, the UE 3 may send the RRC Setup Request message to the IAB Donor 501 via the IAB Node 502.
　　Step 5. Upon the reception of the RRC Setup Request message in Step 4, the IAB Donor 501 sends the RRC Setup message to the UE 3 including List of TMGI for MO requested. The List of TMGI for MO requested indicates the UE 3 that the Ambient IoT communication associated to the TMGI (e.g. the broadcasted TMGI) is requested. In one example, the IAB Donor 501 includes the List of TMGI for MO requested parameter only if the IAB Node 502 does not broadcast a system information with a list of TMGI in step 3. For example, in step 4, the IAB Node 502 may send, to the IAB Donor 501, information indicating that the IAB Node 502 does not broadcast the system information.
　　For example, the IAB Donor 501 may send the RRC Setup message to the UE 3 via the IAB Node 502. For example, the IAB Donor 501 may know that which the list of TMGI is broadcasted by which IAB Node(s).
　　The above-mentioned parameter(s) in step 5 (e.g. the parameter(s) in the message of step 5) may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　For example, the UE 3 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1 to 5.
　　For example, the UE 3 may perform at least one of steps 1 to 5 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the IAB Node 502 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1, 3, 4 and 5.
　　For example, the IAB Node 502 may perform at least one of steps 1, 3, 4 and 5 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the IAB Donor 501 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 4 and 5.
　　For example, the IAB Donor 501 may perform at least one of steps 4 and 5 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
Fifth scenario in Third example of the First Aspect:
　　The Fifth scenario in Third example of the First Aspect discloses an example of the Service management model for Ambient IoT device.
　　The Service management model for Ambient IoT device is the same as the Service management model for Ambient IoT device as disclosed in the Fifth scenario in First example of the First Aspect with the following replacements.
　　　　The "Radio Cell 502" is replaced with the "IAB Node 502".
　　　　The "RAN 501" is replaced with the "IAB Donor 501".
Sixth scenario in Third example of the First Aspect:
　　The Sixth scenario in Third example of the First Aspect discloses an example of the Ambient IoT configuration notification procedure.
　　The Ambient IoT configuration notification procedure is the same as the Ambient IoT configuration notification procedure as disclosed in the Sixth scenario in First example of the First Aspect with the following replacements.
　　　　The "Radio Cell 502" is replaced with the "IAB Node 502".
　　　　The "RAN 501" is replaced with the "IAB Donor 501".
Seventh scenario in Third example of the First Aspect:
　　The Seventh scenario in Third example of the First Aspect discloses an example of the Ambient IoT Service Activation procedure.
　　The Ambient IoT Service Activation procedure is the same as the Ambient IoT Service Activation procedure as disclosed in the Seventh scenario in First example of the First Aspect with the following replacements.
　　　　The "Radio Cell 502" is replaced with the "IAB Node 502".
　　　　The "RAN 501" is replaced with the "IAB Donor 501".
　　　　The "Configuration update message" in step 8 is replaced with the "GNB-DU CONFIGURATION UPDATE message".
　　　　Step 9 is replaced with Steps 1 to 5 in Fig. 15.
Eighth scenario in Third example of the First Aspect:
　　The Eighth scenario in Third example of the First Aspect discloses an example of the Ambient IoT device-initiated Service Activation procedure.
　　The Ambient IoT device-initiated Service Activation procedure is the same as the Ambient IoT device-initiated Service Activation procedure as disclosed in the Eighth scenario in First example of the First Aspect with the following replacements.
　　　　The "Radio Cell 502" is replaced with the "IAB Node 502".
　　　　The "RAN 501" is replaced with the "IAB Donor 501".
　　　　Step 2 is replaced with the following steps.
　　　　　　Steps 1 to 5 in Fig. 15 take place.
　　　　　　Steps 10 to 13 in Fig. 8 take place.
Fourth example of the First Aspect:
　　Fig. 16 includes an example of an architecture that supports ambient IoT devices.
　　The IoT Device 302 in Fig. 16 represents an ambient IoT device. In addition that the IoT Device 302 supports a radio interface specific to the ambient IoT device communication.
　　In addition that the UE 301 (e.g. the UE 30101 and UE 30102) supports Uu interface, the UE 301 (e.g. the UE 30101 and UE 30102) supports the radio interface specific to the ambient IoT device communication. Both the UE 30101 and UE 30102 are able to communicate with the IoT Device 302 using the radio interface specific to the ambient IoT device communication.
　　The radio interface specific to the Ambient IoT device communication is disclosed in the Second Aspect. Although the UE 30101 and UE 30102 are illustrated in the Warehouse #A as an example, the UE 30101 and UE 30102 may be located in public space as the same way with normal UEs.
　　The AF 20101 represents an application server in the data network. For example, the AF 20101 may trigger a task to collect status of the Ambient IoT devices.
　　The AF 20102 represents an application server in the data network. For example, the AF 20102 may be a server that collects status of the Ambient IoT devices.
　　The AF 20101 and the AF 20102 may be combined as one Application Function.
　　The AF 20101 and the AF 20102 may be collocated at the same location or located different location and different network domain. For example, the AF 20101 is located at an Ambient IoT device control centre while the AF 20102 is located at an Ambient IoT device data centre.
First scenario in Fourth example of the First Aspect:
　　Fig. 17 includes an example of the Identity management model for Ambient IoT device.
　　The Identity management model for Ambient IoT device is characterized as the following features.
Ambient IoT device identity
　　An Ambient IoT device identity may be represented as GPSI.
　　A Truncated GPSI is a short coded GPSI. The Truncated GPSI may be expressed as T-GPSI. The T-GPSI is used in the Page procedure.
　　The GPSI is converted to a SUPI and Truncated GPSI at the UDM 75.
Group identity of the Ambient IoT device
　　The Ambient IoT device identity may have one or multiple TMGI(s).
　　The TMGI represents a group of the Ambident IoT device. The TMGI may be called as Multicast MBS group.
　　The TMGI may be preconfigured in the IoT Device 302 by the Service provider.
　　When the AF 201 triggers a data communication with all group members represented by the TMGI, the AF 201 initiates a device trigger procedure to the 5GS using the TMGI. For example, in a case where the AF 201 wants to communication with the group members, the AF 201 may perform a procedure for communicating with the group members towards the 5GS using the TMGI.
　　The TMGI is used by the RAN 5 as the Group paging identity.
Second scenario in Fourth example of the First Aspect:
　　The Second scenario in Fourth example of the First Aspect discloses an example of the Ambient IoT device management procedure of the IoT Device 302 that support the Ambient IoT communication.
　　The Ambient IoT device management procedure of the IoT Device 302 that supports the Ambient IoT communication is the same as the Ambient IoT device management procedure of the UE 3 that supports the Ambient IoT communication as disclosed in the Second scenario in First example of the First Aspect with the following replacements.
　　　　The "Radio Cell 502" is replaced with the "UE 301".
　　　　The "UE 3" is replaced with the "IoT Device 302".
Third scenario in Fourth example of the First Aspect:
　　Fig. 18 includes an example of the Registration procedure of the Ambient IoT device as represented as the IoT Device 302.
　　This is an initial Registration or mobility Registration procedure of the IoT Device 302. This Registration procedure takes place by the IoT Device 302 at any time if the IoT Device 302 is able to communicate with the UE 301. For example, the IoT Device 302 has harvested enough energy over the radio interface specific to the ambient IoT device communication.
　　The detailed processes of the Third scenario in Fourth example of the First Aspect are described below with reference to Fig. 18.
　　Step 0. The Ambient IoT device related data has been installed in the AF 201 and associated UDM 75 and NEF 79 may also be installed. For example, the Ambient IoT device management procedure as disclosed in the Second scenario in Fourth example of the First Aspect takes place.
　　Step 1. The IoT Device 302 has enough energy to communicate with the UE 301 and the UE 301 decides for IoT Device 302 to register to the 5GC. For example, the IoT Device 302 may be fed energy to communicate with the UE 301 by the UE 301. For example, the UE 301 may send signal to feed the energy to communicate to the IoT Device 302. For example, in a case where the UE 301 sends the signal, the UE 301 may decide for IoT Device 302 to register to the 5GC, and proceed step 2.
　　Step 2. The UE 301 sends the RRC Setup Request or RRC Connection Establishment Request message to the RAN 501 including Ambient IoT Support. The Ambient IoT Support indicates that the UE 301 supports the Ambient IoT communication for the Ambient IoT devices (e.g. the IoT Device 302) that are associated with the UE 301. I.E., the Ambient IoT Support indicates that the UE 301 is a UE that has a personal network with Ambient IoT devices.
　　The above-mentioned parameter(s) in step 2 (e.g. the parameter(s) in the message of step 2) may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 3. Upon the reception of the RRC Setup Request message in Step 2, the RAN 5 sends the RRC Setup message to the UE 301.
　　Step 4. The UE 301 sends the RRC Message number 3 message (e.g. RRC Connection Setup Complete message) to the RAN 5 including at least one of the Ambient IoT support and Dedicated NAS. For Ambient IoT support, refer to Step 2.
　　The RAN 5 may refer to the received Ambient IoT support to select an AMF 70 (if not yet selected) which supports ambient IoT communication and management.
　　The Dedicated NAS includes the Registration Request message. The Registration Request message to the AMF 70 includes at least one of User ID, Ambient IoT support, GPSI, List of active TMGI and Supported Ambient IoT profiles.
　　The following bullets explain each parameter in detail.
　　　　・User ID: Refer to step 1 in Fig. 4. The User ID may indicate or include at least one of the User ID of the IoT Device 302 and the User ID of the UE 301.
　　　　・Ambient IoT Support: Refer to step 2. The Ambient IoT support may indicate that at least one of the IoT Device 302 and the UE 301 support the Ambient IoT service and the Ambient IoT service-related procedures as disclosed by this disclosure.
　　　　・GPSI: Refer to step 1 in Fig. 4. For example, the GPSI is a GPSI of at least one of the IoT Device 302 and the UE 301.
　　　　・List of active TMGI: Refer to step 1 in Fig. 4. The definition of the List of active TMGI of step 1 in Fig. 4 may be applied to the List of active TMGI in step 4. The definition of the List of active TMGI of step 1 in Fig. 4 may be applied to the List of active TMGI in step 4, by replacing the UE 3 with the IoT Device 302.
　　　　・Supported Ambient IoT profiles: The Supported Ambient IoT profiles indicates that Supported Ambient IoT profiles that are supported by both the IoT Device 302 and the UE 301 for IoT communication. The Supported Ambient IoT profiles indicates that Supported Ambient IoT profiles that are supported by at least one of the IoT Device 302 and the UE 301 for IoT communication. For example, the Supported Ambient IoT profiles may include at least one data in the Ambient IoT profile described in step 2 of Fig. 3. For example, the Supported Ambient IoT profiles may include the Ambient IoT profile regarding the IoT Device 302 and the UE 301. The Ambient IoT profile regarding the IoT Device 302 and the UE 301 may include at least one of data in the Ambient IoT profile described in step 2 of Fig. 3.
　　　　For example, the Supported Ambient IoT profiles may include the Ambient IoT profile(s) for the IoT Device(s) 302 that the UE 3 supports.
　　　　For example, the Supported Ambient IoT profiles may include the Ambient IoT profile(s) for the UE 3 supports.
　　For example, the UE 301 may receive at least one of the User ID, Ambient IoT Support, GPSI, List of active TMGI and Supported Ambient IoT profiles regarding the IoT Device 302 in step 1 by communicating with the IoT Device 302.
　　For example, by communicating with the IoT Device 302 in step 1, the UE 301 may understand or know correspondence between the IoT Device 302 and at least one of the TMGI (or Service ID) and the Ambient IoT profile.
　　For example, by communicating with the IoT Device 302 in step 1, the UE 301 may understand or know which IoT Device(s) 302 is associated with which TMGI (or Service ID).
　　For example, by communicating with the IoT Device 302 in step 1, the UE 301 may understand or know which IoT Device(s) 302 is associated with which Ambient IoT profile.
　　For example, the UE 301 may know or understand correspondence between TMGI(s) and Service ID.
　　The above-mentioned parameter(s) in step 4 (e.g. the parameter(s) in the message of step 4) may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 5. Upon reception of the RRC Message number 3 message from the UE 301, the RAN 5 sends the Initial UE message to the AMF 70 including at least one of the Ambient IoT support and NAS-PDU. The NAS-PDU includes the Registration Request message that is received in the Dedicated NAS in Step 4.
　　The above-mentioned parameter(s) in step 5 (e.g. the parameter(s) in the message of step 5) may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 6. Upon reception of the Registration Request message in step 5, the AMF 70 sends the Nudm_UECM_Registration Request message to a UDM 75 including at least one of the SUPI, GPSI, List of active TMGI and Supported Ambient IoT profiles. Refer to Step 4 for parameter details.
　　The above-mentioned parameter(s) in step 6 (e.g. the parameter(s) in the message of step 6) may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 7. Upon reception of the Nudm_UECM_Registration Request message in step 6, the UDM 75 sends the Nudm_UECM_Registration Response message to the AMF 70.
　　Step 8. After the completion of the Nudm_UECM_Registration service in steps 6 and 7, the AMF 70 sends the Nudm_SDM_Get Request message to the UDM 75 including at least one of the SUPI, GPSI, List of active TMGI and Supported Ambient IoT profiles. Refer to Step 4 for parameter details.
　　The above-mentioned parameter(s) in step 8 (e.g. the parameter(s) in the message of step 8) may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 9. If the GPSI is received from the AMF 70, the UDM 75 assigns a Truncated GPSI (T-GPSI) to the received GPSI. The T-GPSI is a short type of data that can uniquely identify the Ambient IoT Device within the PLMN. The UDM 75 finds Subscriber data for the UE 301 and sends the Nudm_SDM_Get Response message to the AMF 70 including the Subscriber data for the UE 301. The Subscriber data includes at least one of the GPSI, T-GPSI, List of TMGI, List of PLMN, Ambient IoT profile and Report to server address. Refer to step 2 in Second scenario in First example of the First Aspect for parameter details.
　　For example, the T-GPSI may be related to the GPSI, and related to at least one of the UE 301 and IoT Device 302.
　　The above-mentioned parameter(s) in step 9 (e.g. the parameter(s) in the message of step 9) may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 10. The UDM 75 sends the Nudm_EventExposure_Notify message to the NEF 79 including at least one of the SUPI, GPSI and List of active TMGI if the NEF 79 has subscribed to the Nudm_EventExposure service.
　　The above-mentioned parameter(s) in step 10 (e.g. the parameter(s) in the message of step 10) may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 11. The NEF 79 sends the Nnef_EventExposure_Notify message to the AF 201 including at least one of the SUPI, GPSI and List of active TMGI if the AF 201 has subscribed to the Nnef_EventExposure service.
　　At this point, the GPSI can be associated with the SUPI in the AF 201.
　　The above-mentioned parameter(s) in step 11 (e.g. the parameter(s) in the message of step 11) may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 12. The AMF 70 sends the Registration Accept message to the UE 301 including at least one of 5G-GUTI, the GPSI, the T-GPSI, the List of TMGI, the List of PLMN, the Ambient IoT profile and the Report to server address. The 5G-GUTI is a temporary user identifier for the UE 301. Refer to step 2 in Second scenario in First example of the First Aspect for parameter details.
　　The above-mentioned parameter(s) in step 12 (e.g. the parameter(s) in the message of step 12) may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 13. Upon reception of the Registration Accept message, the UE 301 stores the received data in the Registration Accept message in step 12. The UE 301 may store the received data in the Registration Accept message in step 12 into non-volatile memory in the UE 301.
　　The UE 301 sends the Registration Complete message to the AMF 70.
　　Step 14. The UE 301 communicates with the IoT Device 302 and informs that the Registration procedure is successfully performed and the Ambient IoT service is available.
　　For example, the UE 301 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1 to 4 and 12 to 14.
　　For example, the UE 301 may perform at least one of steps 1 to 4 and 12 to 14 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the RAN 5 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 2 to 5.
　　For example, the RAN 5 may perform at least one of steps 2 to 5 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the AMF 70 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 5 to 9, 12 and 13.
　　For example, the AMF 70 may perform at least one of steps 5 to 9, 12 and 13 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the UDM 75 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 6 to 10.
　　For example, the UDM 75 may perform at least one of steps 6 to 10 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the NEF 79 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 10 and 11.
　　For example, the NEF 79 may perform at least one of steps 10 and 11 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the AF 201 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least step 11.
　　For example, the AF 201 may perform at least step 11 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
Variant 1 of Third scenario in Fourth example of the First Aspect:
　　In one example, in step 2 in Fig. 18 the UE 301 may include a new RRC Connection establishment cause within the RRC connection establishment cause parameter, called for example 'ambient IoT' cause or any other notation for RRC connection establishment cause to indicate that the data carried within the RRC Connection Establishment Request or RRC Connection Setup Request message is originated from an ambient IoT device. This may help the RAN 5 to select an AMF (if not selected yet) which supports management and communication of ambient IoT type. The new RRC connection establishment cause 'ambient IoT' may also help the RAN 5 and the AMF 70 with the decision whether to employ the normal data exchange (e.g., create data bearers) or deploy the Optimised CIoT Control plane data exchange for small data or to deploy the Early Data Exchange (EDT) procedure. Also, in case of a network overload from ambient IoT type of communication (e.g. the AMF 70 has indicated to RAN 5 within the Overload Start message an overload from ambient IoT type communication) the RAN 5 may start to reject the RRC connection requests from all UEs which indicate the 'ambient IoT' RRC connection establishment cause in the RRC Establishment cause parameter within the RRC Connection Establishment Request or RRC Connection Setup Request message or the RAN 5 may release the already established RRC connections in order to reduce the overload from ambient IoT devices. The RAN 5 may include a back-off timer called 'ambient IoT back-off timer' or any other notation for a back-off timer or a wait timer with the purpose to restrict the UEs coming back for data exchange for data from ambient IoT devices for the duration of the 'ambient IoT back-off timer'. If the UE 301 was rejected for RRC connection establishment for IoT communication or an already established RRC connection for IoT communication was released with an 'ambient IoT back-off timer', the UE 301 may not trigger another request for ambient IoT communication for the duration of the received 'ambient IoT back-off timer'. The 'ambient IoT back-off timer' may be reset if the UE 301 reregisters with another AMF (location update) or reselect another PLMN.
Fourth scenario in Fourth example of the First Aspect:
　　Fig. 19 includes an example of the Registration procedure of the Ambient IoT device with the Ambient IoT data communication as represented as the IoT Device 302.
　　It is assumed that this Registration procedure takes place after a successful Registration procedure with the AMF 70 has been taken place so that a NAS security context has been established between the UE 301 and the AMF 70.
　　The detailed processes of the Fourth scenario in Fourth example of the First Aspect are described below with reference to Fig. 19.
　　Step 0. The UE 301 is registered to the AMF 70 and a dedicated PDU Session for the Ambient IoT service has been established with the SMF 71 and the UPF 72. For example, in step 0, the process(es) in Fig. 18 completes and the PDU Session has been established.
　　Step 1-1. In one example, the AF 201 may trigger the UE 301 for Ambient IoT communication with list of TMGI over the user plane. In one example, the AF 201 may trigger the Ambient IoT communication by using the list of TMGI. For example, the AF 201 may trigger the Ambient IoT communication for at least one of the UE 301 and IoT Device 302 which is identified by TMGI(s) in the list of TMGI.
　　In one example, Steps 1 to 8 in the the Ambient IoT Service Activation procedure in the Fig. 8 may take place. In a case where Steps 1 to 8 in the the Ambient IoT Service Activation procedure in the Fig. 8 take place, the replacements of the RAN 501 with the RAN 5, and the Radio Cell 502 with the UE 301 may be needed.
　　Step. 1-2. The UE 301 broadcasts energy over the air. Refer to the Aspect 2 for detail of energy broadcasting. The energy broadcasting may be trigged by the activation request in Step 1-1. The energy broadcasting may be trigged by the process(es) in Step 1-1.
　　Step 1-3. The IoT Device 302 has had enough energy to perform the registration procedure. For example, if the IoT Device 302 has a battery, the battery in the IoT Device 302 have been charged by harvesting energy by receiving the broadcasted energy by Step 1-2. For example, if the IoT Device 302 does not have a battery, the IoT Device 302 performs the Registration procedure using energy being harvested by receiving the broadcasted energy by Step 1-2.
　　Step 2-1. In one example, the UE 301 broadcasts a system information with a list of TMGI indicating that the UE 301 is requested to perform the Ambient IoT communication immediately if the IoT Device 302 has an active TMGI in the list of TMGI.
　　In another example, the IoT Device 302 holds the MO-data to send to the AF 201.
　　Step 2-2. The IoT Device 302 sends the MO-data to the UE 301 with a dedicated communication between the IoT Device 302 and UE 301.
　　In another example, the IoT Device 302 initiates the Ambient IoT communication as far as the IoT Device 302 has enough energy for performing the Registration procedure regardless of receiving the system information in Step 2.
　　The above-mentioned parameter(s) in step 2-1 or 2-2 (e.g. the parameter(s) in the message of step 2-1 or 2-2) may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　For example, the UE 301 may broadcast the system information including the list of TMGI. The system information may be expressed as a service request (e.g. a service request for the Ambient IoT, for the Ambient IoT communication or for the Ambient IoT service).
　　Step 3. After the UE 301 receives the MO-data from the IoT Device 302, the UE 301 sends the RRC Setup Request message to the RAN 5 including Ambient IoT Support. The Ambient IoT Support indicates that the UE 301 supports the Ambient IoT communication for IoT devices on behalf of connected IoT Device 302(s). I.E., the Ambient IoT Support indicates that the IoT Device 302 is a UE that has a personal network with the UE 301.
　　For example, in a case where the IoT Device 302 receives the system information including TMGI 1 in step 2-1 and the IoT Device 302 has the list of TMGI including TMGI 1, the IoT Device 302 may send the MO-data to the UE 301. Then, the UE 301 may send the RRC Setup Request message to the RAN 5 after the UE 301 receives the MO-data from the IoT Device 302.
　　For example, in a case where the IoT Device 302 has enough energy for performing the MO-data sending to the UE 301 regardless of receiving the system information in step 2-1, the IoT Device 302 may send the MO-data to the UE 301. Then, the UE 301 may send the RRC Setup Request message to the RAN 5 after the UE 301 receives the MO-data from the IoT Device 302.
　　The above-mentioned parameter(s) in step 3 (e.g. the parameter(s) in the message of step 3) may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 4. Upon the reception of the RRC Setup Request message in Step 3, the RAN 5 sends the RRC Setup message to the UE 301 including List of TMGI for MO requested. The List of TMGI for MO requested indicates the IoT Device 302 that the Ambient IoT communication associated with the TMGI is requested. In one example, the RAN 5 includes the List of TMGI for MO requested parameter only if the UE 301 does not broadcast the system information with the list of TMGI in step 2. For example, in step 0, the UE 301 may inform the RAN 5 that the UE 301 is not able to broadcast the system information. In this case, the RAN 5 may include the List of TMGI for MO requested in the RRC Setup message.
　　The above-mentioned parameter(s) in step 4 (e.g. the parameter(s) in the message of step 4) may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 5. The UE 301 sends the RRC Message number 3 message to the RAN 5 including at least one of the Ambient IoT support and Dedicated NAS.
　　The Dedicated NAS includes the Registration Request message.
　　In addition to contents of the Registration request message in Step 4 in Fig. 18, the Registration Request message in step 5 includes the MO-data. The MO-data may be embedded in the CIoT small data container or CIoT user data container. The MO-data may be an Ambient IoT related data from the IoT Device 302 for the Ambient IoT communication.
　　In one example, the Ambient IoT application in the IoT Device 302 provides the MO-data.
　　The messages in steps 3 to 5 may be communicated between the IoT Device 302 and RAN 5 without intervening the UE 301.
　　The above-mentioned parameter(s) in step 5 (e.g. the parameter(s) in the message of step 5) may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 6. Upon reception of the RRC Message number 3 message from the UE 301, the RAN 5 sends the Initial UE message to the AMF 70 including at least one of the Ambient IoT device type and NAS-PDU. The NAS-PDU includes the Registration Request message that is received in the Dedicated NAS in Step 5.
　　In one example, the MO-data in the Registration Request message is security protected using the NAS security context. In this case, the AMF 70 decodes the protected message using the NAS security context.
　　The above-mentioned parameter(s) in step 6 (e.g. the parameter(s) in the message of step 6) may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 7. Steps 6 to 11 in Fig. 18 take place.
　　Step 8. The AMF 70 sends the Nsmf_PDUSession_SendMOData message to the SMF 71 including the MO-data.
　　Step 9. The SMF 71 forward the received MO-data to the UPF 72.
　　Step 10. The UPF 72 communicates with the AF 201 or any server in data network for the Ambient IoT communication. For example, the UPF 72 sends the MO-data to the AF 201. For example, the AF 201 sends a MT-data to the IoT Device 302. For example, the AF 201 sends, to the UPF 72, the MT-data for the IoT Device 302. The MT-data may be an Ambient IoT related data to the IoT Device 302 for the Ambient IoT communication.
　　Step 11. The UPF 72 may forward the MT-data if the UPF 72 receives the MT-data during the Ambient IoT communication. For example, the UPF 72 receives the MT-data as a reply to the MO-data. The UPF 72 may forward the MT-data to the SMF 71.
　　Step 12. The SMF 71 sends the Namf_Communication_N1N2MessageTransfer message to the AMF 70. The Namf_Communication_N1N2MessageTransfer message may include the MT-data.
　　Step 13. The AMF 70 sends the Registration Accept message to the UE 301.
　　In addition to contents of the Registration Accept message in Step 12 in Fig. 18, the Registration Accept message in step 13 includes the MT-data. The MT-data may be an Ambient IoT related data to the IoT Device 302 for the Ambient IoT communication.
　　The Registration Accept message may be transmitted to the IoT Device 302 via the UE 301.
　　The above-mentioned parameter(s) in step 13 (e.g. the parameter(s) in the message of step 13) may be expressed as parameter(s) or data or information for performing a Registration procedure for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 14. Upon reception of the Registration Accept message, the UE 301 stores the received data in the Registration Accept message in step 13. The UE 301 stores the received data in the Registration Accept message in step 13 into non-volatile memory in the UE 301.
　　The UE 301 sends the Registration Complete message to the AMF 70.
　　The Registration Complete message may be transmitted to the AMF 70 from the IoT Device 302 without intervening the UE 301.
　　Step 15. The UE 301 communicates with the IoT Device 302 and informs that the Registration procedure and IoT data transmission to the AF 201 are successfully performed.
　　If the MT-data is received from the AMF 70 in step 13, the UE 301 also communicates with the IoT Device 302 and informs the received MT-data.
　　For example, the UE 301 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 0, 1-1, 1-2, 2 and 15.
　　For example, the UE 301 may perform at least one of steps 0, 1-1, 1-2, 2 and 15 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the IoT Device 302 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1-2, 1-3, 2 to 5, 13, 14 and 15.
　　For example, the IoT Device 302 may perform at least one of steps 1-2, 1-3, 2 to 5, 13, 14 and 15 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the RAN 5 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 3 to 6.
　　For example, the RAN 5 may perform at least one of steps 3 to 6 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the AMF 70 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 6 to 8, 12 to 14.
　　For example, the AMF 70 may perform at least one of steps 6 to 8, 12 to 14 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the SMF 71 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 8, 9, 11 and 12.
　　For example, the SMF 71 may perform at least one of steps 8, 9, 11 and 12 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the UDM 75 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least step 7.
　　For example, the UDM 75 may perform at least step 7 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the UPF 72 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 9 to 11.
　　For example, the UPF 72 may perform at least one of steps 9 to 11 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the NEF 79 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least step 7.
　　For example, the NEF 79 may perform at least step 7 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the AF 201 may perform a Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 7 and 10.
　　For example, the AF 201 may perform at least one of steps 7 and 10 for the Registration procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
Fifth scenario in Fourth example of the First Aspect:
　　The Fifth scenario in Fourth example of the First Aspect discloses an example of the Service management model for Ambient IoT device.
　　The Service management model for Ambient IoT device is the same as Service management model for Ambient IoT device as disclosed in the Fifth scenario in First example of the First Aspect with the following replacements.
　　　　The "Radio Cell 502" is replaced with the "UE 301".
　　　　The "RAN 501" is replaced with the "RAN 5".
Sixth scenario in Fourth example of the First Aspect:
　　The Sixth scenario in Fourth example of the First Aspect discloses an example of the Ambient IoT configuration notification procedure.
　　The Ambient IoT configuration notification procedure is the same as the Ambient IoT configuration notification procedure as disclosed in the Sixth scenario in First example of the First Aspect with the following replacements.
　　　　The "Radio Cell 502" is replaced with the "UE 301".
　　　　The "RAN 501" is replaced with the "RAN 5".
　　　　The "Radio Cell" is replaced with the "UE".
　　　　The "UE 3" is replaced with the "IoT Device 302".
Seventh scenario in Fourth example of the First Aspect:
　　Fig. 20 includes an example of the Ambient IoT Service Activation procedure for Ambient IoT device procedure.
　　The detailed processes of the Seventh scenario in Fourth example of the First Aspect are described below with reference to Fig. 20.
　　Step 0. The UE 3 is registered to the AMF 70 and a dedicated PDU Session for the Ambient IoT service has been established with the SMF 71 and the UPF 72. The step 0 may be same to step 0 in Fig. 19.
　　Step 1. Steps 1 to 6 in Fig. 8 take place.
　　Step 2. Upon reception of the Namf_Communication_NonUeN2MessageTransfer message from the NEF 79, the AMF 70 finds RAN(s) 5 that have a coverage corresponding to the received Location. Then, the AMF 70 screens the found RAN(s) 5 by using the RAN configuration with regard to at least one of the Ambient IoT support, Supported Ambient IoT profiles, Supported Service IDs and Supported TMGIs.
　　For example, the AMF 70 may find or select the RAN(s) 5 which indicates the Ambient IoT support (e.g. the AMF 70 may find or select the RAN(s) 5 which supports the Ambient IoT service and the Ambient IoT service-related procedures as disclosed by this disclosure).
　　For example, the AMF 70 may take into account the Supported Ambient IoT profiles for the RAN(s) 5 for screening, finding or selecting the RAN(s) 5.
　　For example, by referring to the Supported Ambient IoT profiles, the AMF 70 may find or select the RAN(s) 5 which supports at least one of an appropriate Frequency band for the TMGI (e.g. the appropriate Frequency band for the Ambient IoT service related to the TMGI), an appropriate Air interface (or radio interface) for the TMGI (e.g. the appropriate Air interface or radio interface for the Ambient IoT service related to the TMGI) and an appropriate security parameter for the TMGI (e.g. the appropriate security parameter for the Ambient IoT service related to the TMGI).
　　For example, the AMF 70 may take into account the Supported Service IDs for the RAN(s) 5 for screening, finding or selecting the RAN(s) 5.
　　For example, by referring to the Supported Service IDs, the AMF 70 may find or select the RAN(s) 5 which supports the Ambient IoT service(s) related to at least one of the TMGI received from the NEF 79 and the Supported Service ID(s).
　　For example, the AMF 70 may screen, find or select the RAN(s) 5 which supports or is related to the TMGI received from the NEF 79 by referring to the Supported TMGI(s) for the RAN(s) 5 and the received TMGI from the NEF 79.
　　For example, in a case where the AMF 70 receives TMGI#1 from the NEF 79, the AMF 70 may find or select the RAN(s) 5 which supports or is related to TMGI#1 based on the Supported TMGI(s).
　　For example, the AMF 70 may take into account the Ambient IoT support for the RAN(s) 5 for screening, finding or selecting the RAN(s) 5.
　　For example, the AMF 70 may find or select the RAN(s) 5 which supports the received Ambient IoT profiles.
　　Then, the AMF 70 sends Page messages to all RAN(s) 5, that are found as target RAN(s) by the location coverage and capability point of view, including at least one of the received TMGI from the NEF 79 and TAI list that are found by converting the received Location to corresponding TAIs where that matches with the received Location. For example, the AMF 70 may send the Page message to the RAN(s) 5 which is found by the AMF 70 based on the above-mentioned description.
　　In one example, the Page message may be called as a Group Page message, Ambient IoT Page message or Ambient IoT Group Page message or any other notation for a paging message used for paging of ambient IoT devices.
　　The above-mentioned parameter(s) in step 2 (e.g. the parameter(s) in the message of step 2) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 3. The RAN 5 performs the page with the TMGI for all cells that corresponds to the received TAIs in step 2.
　　In one example, the Page may be called as a Group Page, Ambient IoT Page or Ambient IoT Group page.
　　For example, in a case where the RAN 5 receives the Page message from the AMF 70 in step 2, the RAN 5 may perform the page (e.g. the paging procedure) by using the received TMGI for cell(s) corresponding to the received TAI(s) in step 2.
　　The above-mentioned parameter(s) in step 3 (e.g. the parameter(s) in the message of step 3) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 4. If the UE 301 receives the TMGI over Paging channel that corresponds to the Ambient IoT service that one of IoT Device 302 engages to, the UE 301 sends the Service Request message to the AMF 70 including the TMGI.
　　For example, in a case where the UE 301 receives the TMGI over Paging channel that corresponds to the Ambient IoT service that is related to the IoT Device 302, the UE 301 may send the Service Request message to the AMF 70 including the TMGI.
　　For example, in a case where the UE 301 receives the TMGI over Paging channel that corresponds to the IoT Device 302, the UE 301 may send the Service Request message to the AMF 70 including the TMGI.
　　The above-mentioned parameter(s) in step 4 (e.g. the parameter(s) in the message of step 4) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 5. Upon reception of the Service Request message from the UE 301, the AMF 70 sends the Configuration Update Command message to the UE 301 including at least one of the TMGI, Service ID and Ambient IoT profile. The definition of the TMGI, Service ID and Ambient IoT profile in the above-mentioned other scenario or other example in this disclosure may be applied to the TMGI, Service ID and Ambient IoT profile in step 5.
　　The above-mentioned parameter(s) in step 5 (e.g. the parameter(s) in the message of step 5) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 6-1. Upon reception of the UE Configuration Update Command message from the AMF 70, the UE 301 finds the corresponding IoT Device(s) 302 to at least one of the TMGI and Service ID and supported Ambient IoT profile (e.g. the Ambient IoT profile), and performs the Ambient IoT communication between the UE 301 and the IoT Device(s) 302. The security parameter in the Ambient IoT profile may be used by the UE 301 and the IoT Device(s) 302 for mutual or Ambient IoT device authentication and authorization. In addition, the security parameter in the Ambient IoT profile may be used by the UE 301 and the IoT Device(s) 302 for integrity protection and confidentiality protection for the Ambient IoT communication over the dedicated Ambient IoT communication interface over the air.
　　For example, the UE 301 may find the IoT Device(s) 302 based on at least one of the received TMGI, Service ID and Ambient IoT profile from the AMF 70 and at least one of the received List of TMGI and Ambient IoT profile from the AMF 70 in step 12 of Fig. 18 (i.e. at least one of the List of TMGI and Ambient IoT profile received during the Registration procedure in Fig. 18).
　　For example, in a case where the UE 301 knows that TMGI#1 (or Service ID#1) is associated with the IoT Device 302 in step 1 of Fig. 18 and the UE 301 receives TMGI#1 (or Service ID#1) from the AMF 70 in step 5 of Fig. 20, the UE 301 may find or select the IoT Device 302 corresponding to TMGI#1. Then the UE 301 may perform the Ambient IoT communication with the found IoT Device 302.
　　For example, in a case where the UE 301 knows that Ambient IoT profile#1 is associated with the IoT Device 302 in step 1 of Fig. 18 and the UE 301 receives Ambient IoT profile#1 from the AMF 70 in step 5 of Fig. 20, the UE 301 may find or select the IoT Device 302 corresponding to Ambient IoT profile#1. Then the UE 301 may perform the Ambient IoT communication with the found IoT Device 302.
　　For example, in step 6-1, the IoT Device 302 may send MO-data (e.g. the Ambient IoT data from the IoT Device 302) to the UE 301.
　　For example, in step 6-1, the IoT Device 302 may receive MT-data (e.g. the Ambient IoT data to the IoT Device 302) from the UE 301.
　　For example, in step 6-1, the UE 301 may send a signal to feed the energy to perform communication with the IoT Device 302. For example, in step 6-1, the IoT Device 302 perform the Ambient IoT communication with the UE 301 by using the energy fed by the UE 301.
　　Step 6-2. The UE 301 takes a role of conveying the Ambient IoT data from the IoT Device 302 to an Ambient IoT server (e.g. the AF 201). The Ambient IoT server may be found in the Report to server address in the received Ambient IoT profile. Similarly, the UE 301 takes a role of conveying the Ambient IoT data from the Ambient IoT server to the IoT Device 302.
　　For example, the UE 301 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 0, 3 to 5, 6-1 and 6-2.
　　For example, the UE 301 may perform at least one of steps 0, 3 to 5, 6-1 and 6-2 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the IoT Device 302 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least 6-1.
　　For example, the IoT Device 302 may perform at least 6-1 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the RAN 5 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 2 and 3.
　　For example, the RAN 501 may perform at least one of steps 2 and 3 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the AMF 70 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1, 2, 4 and 5.
　　For example, the AMF 70 may perform at least one of steps 1, 2, 4 and 5 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the UDM 75 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least step 1.
　　For example, the UDM 75 may perform at least step 1 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the NEF 79 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least step 1.
　　For example, the NEF 79 may perform at least step 1 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the AF 201 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1 and 6-2.
　　For example, the AF 201 may perform at least one of steps 1 and 6-2 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
Eighth scenario in Fourth example of the First Aspect:
　　Fig. 21 includes an example of the Ambient IoT Service Activation for Ambient IoT device procedure.
　　The detailed processes of the Eighth scenario in Fourth example of the First Aspect are described below with reference to Fig. 21.
　　Step 0. The UE 301 is registered to the AMF 70 and a dedicated PDU Session for the Ambient IoT service has been established with the SMF 71 and the UPF 72. The step 0 may be same to step 0 in Fig. 19.
　　Step 1. The AF 201 decides to start the Ambient IoT service activation for Ambient IoT device. For example, the AF 201 may decide to start the Ambient IoT service for example, a gate-in inventory, Inventory at a warehouse, a gate-out inventory as described in NPL 2.
　　Step 2. The AF 201 sends an Nnef_IoT_Service_Request message to the NEF 79 including at least one of TMGI, GPSI, Service, Service order and Ambient IoT profiles. The Ambient IoT profiles may be included by the AF 201 if the Ambient IoT profile corresponds to the Service which has been updated lately.
　　The following bullets explain each parameter in detail. The replacement of the UE 3 with the IoT Device 302 or the UE 301 may be applied to the definition of the parameters below. With the replacement of the UE 3 with the IoT Device 302 or the UE 301, the definition of the TMGI, GPSI, Service, Service order and Ambient IoT profiles in above-mentioned other scenario or other example in this disclosure may be applied to the the TMGI, GPSI, Service, Service order and Ambient IoT profiles in step 2.
　　　　・TMGI: Refer to Step 2 in Fig. 8.
　　　　・GPSI: Refer to Step 2 in Fig. 3.
　　　　・Service: Refer to Step 2 in Fig. 8.
　　　　・Service order: Refer to Step 2 in Fig. 8.
　　　　・Ambient IoT profiles: Refer to Step 2 in Fig. 8.
　　The above-mentioned parameter(s) in step 2 (e.g. the parameter(s) in the message of step 2) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 3. Upon reception of the Nnef_IoT_Service_Request message from the AF 201 in step 2, the NEF 79 converts the received Service to a Service ID. The Service ID may be a common value among operator networks or a unique value only valid in the PLMN or the NPN where the NEF 79 belongs to.
　　Step 4. Upon the reception of the Nnef_IoT_Service_Request message from the AF 201 (or in a case where the NEF 79 converts the received Service to the Service ID), the NEF 79 sends the Nudm_SDM_Get Request message to the UDM 75 including at least one of the TMGI, GPSI, Service ID, Location and Ambient IoT profiles. The TMGI, Location and Ambient IoT profile in step 4 are ones received from the AF 201. The Service ID in step 4 is one converted by the NEF 79 in step 3.
　　The above-mentioned parameter(s) in step 4 (e.g. the parameter(s) in the message of step 4) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 5. Upon the reception of the Nudm_SDM_Get Request message from the NEF 79, the UDM 75 performs at least one of the following actions:
　　　　If the GPSI is received, the UDM 75 converts the GPSI to a Truncated GPSI (T-GPSI). For example, the UDM 75 may store or receive from other network node(s) in advance information for this conversion.
　　　　If the GPSI is received, the UDM 75 finds an AMF and SUPI that the Ambient IoT Device 302 is associated with. For example, the UDM 75 may store or receive from other network node(s) in advance information for this finding. For example, in a case where the UDM 75 knows that the received GPSI is related to the SUPI, the UDM 75 may find the SUPI based on the received GPSI.
　　　　For example, the UDM 75 may find the AMF based on the received GPSI. For example, in a case where the UDM 75 knows that received GPSI#1 is related to the AMF 70, the UDM 75 may find the AMF 70.
　　　　For example, the UDM 75 may find the AMF based on the received TMGI. For example, in a case where the UDM 75 stores the Supported TMGIs regarding the AMF 70 including TMGI#1 and the UDM 75 receives TMGI#1 in step 4, the UDM 75 may find the AMF 70.
　　　　In a case where the UDM 75 has been notified in advance a support of Service ID from the AMF 70 and the received Service ID corresponds to that Service ID (e.g. in a case where the UDM 75 has received the Service ID from the AMF 70 in advance, and the received Service ID from the AMF 70 corresponds to the received Service ID from the NEF 79 in step 4), the UDM 75 provides all notified AMF(s) 70 to the NEF 79 for the Service ID (e.g. the UDM 75 may provide, to the NEF 79, information regarding the AMF 70 which sends the Service ID to the UDM 75).
　　　　If the received Ambient IoT profiles corresponding to the Service ID are different from one in the UDM 75, the UDM 75 updates the Ambient IoT profiles corresponding to the Service ID in the storage of the UDM 75. The UDM 75 may store or receive from other network node(s) in advance information indicating correspondence between the Ambient IoT profiles and the Service ID. The Ambient IoT profiles may be related to the Service ID.
　　The UDM 75 sends the Nudm_SDM_Get Response message to the NEF 79 including at least one of AMF (e.g. list of AMF(s)), the SUPI, the T-GPSI and the Ambient IoT profiles. The Ambient IoT profiles may be provided if the NEF 79 does not provide the Ambient IoT profiles to the UDM 75 in step 4 and the UDM 75 holds the Ambient IoT profiles for the Service ID.
For example, the list of AMF(s) may include AMF(s) which supports the Service ID or the Ambient IoT service indicated by the Service ID.
　　For example, the list of AMF(s) may include AMF(s) which is found by the UDM 75.
　　The above-mentioned parameter(s) in step 5 (e.g. the parameter(s) in the message of step 5) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 6. Upon reception of the Nudm_SDM_Get Response message from the UDM75, the NEF 79 sends the Namf_Communication_NonUeN2MessageTransfer message to the AMF 70 (e.g. to the AMF 70 indicated by the list of AMF(s) in step 5) including at least one of the TMGI, SUPI, GPSI, T-GPSI, Service ID, Service order and Ambient IoT profiles.
　　The above-mentioned parameter(s) in step 6 (e.g. the parameter(s) in the message of step 6) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 7. Upon reception of the Namf_Communication_NonUeN2MessageTransfer message from the NEF 79, the AMF 70 sends Page message(s) to the RAN 5 that corresponds to the Registration Area for the SUPI. The Page message includes at least one of 5G-S-TMSI, T-GPSI and TAI list.
　　In one example, the AMF 70 may send the Page message including the TMGI.
　　The above-mentioned parameter(s) in step 7 (e.g. the parameter(s) in the message of step 7) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 8. The RAN 5 performs the page by using the 5G-S-TMSI for all cell(s) that corresponds to the received TAI list in step 7. This Page (e.g. the Page message sent in step 8) includes the T-GPSI. For example, the RAN 5 may perform the page by using the T-GPSI.
　　In one example, the RAN 5 may perform the Page by using the TMGI.
　　The above-mentioned parameter(s) in step 8 (e.g. the parameter(s) in the message of step 8) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 9. If the UE 301 receives the 5G-S-TMSI or T-GPSI or TMGI over Paging channel and a GPSI, that is converted from the received T-GPSI in the UE 301 and corresponds to the Ambient IoT service that one of IoT Device 302 engages to, the UE 301 sends the Service Request message to the AMF 70 including at least one of the 5G-S-TMSI or TMGI, T-GPSI and GPSI.
　　For example, in a case where the UE 301 receives at least one of the 5G-S-TMSI, T-GPSI and TMGI over Paging channel that correspond to the Ambient IoT service that is related to the IoT Device 302, the UE 301 may send the Service Request message to the AMF 70 including at least one of the 5G-S-TMSI, TMGI, T-GPSI and GPSI.
　　For example, in a case where the UE 301 receives the T-GPSI over Paging channel and converts the T-GPSI to the GPSI that corresponds to the Ambient IoT service that is related to the IoT Device 302, the UE 301 may send the Service Request message to the AMF 70 including at least one of the T-GPSI and GPSI.
　　For example, in a case where the UE 301 receives the T-GPSI over Paging channel and converts the T-GPSI to the GPSI that corresponds to the IoT Device 302, the UE 301 may send the Service Request message to the AMF 70 including at least one of the T-GPSI and GPSI.
　　The above-mentioned parameter(s) in step 9 (e.g. the parameter(s) in the message of step 9) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 10. Upon reception of the Service Request message from the UE 301, the AMF 70 sends the Configuration Update Command message to the UE 301 including at least one of the TMGI, Service ID and Ambient IoT profile. The definition of the TMGI, Service ID and Ambient IoT profile in the above-mentioned other scenario or other example in this disclosure may be applied to the TMGI, Service ID and Ambient IoT profile in step 10.
　　The above-mentioned parameter(s) in step 10 (e.g. the parameter(s) in the message of step 10) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 11. Steps 6-1 and 6-2 in Fig. 20 take place.
　　For example, the UE 301 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 0, 8 to 10 and 11.
　　For example, the UE 301 may perform at least one of steps 0, 8 to 10 and 11 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the IoT Device 302 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least step 11.
　　For example, the IoT Device 302 may perform at least step 11 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the RAN 5 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 7 and 8.
　　For example, the RAN 5 may perform at least one of steps 7 and 8 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the AMF 70 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 6, 7, 9 and 10.
　　For example, the AMF 70 may perform at least one of steps 6, 7, 9 and 10 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the UDM 75 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 4 and 5.
　　For example, the UDM 75 may perform at least one of steps 4 and 5 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the NEF 79 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 2 to 6.
　　For example, the NEF 79 may perform at least one of steps 2 to 6 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the AF 201 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1, 2 and 11.
　　For example, the AF 201 may perform at least one of steps 1, 2 and 11 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
Variant 1 of Eight scenario in Fourth example of the First Aspect:
　　In one example, the ambient IoT devices (e.g. the IoT Device 302) may be registered with the UDM 75 with an identity which is the UE identity (e.g. SUPI) plus a short extra identity or tag to identify the ambient IoT device connected to the UE 301 i.e. the ambient IoT device that has registered via that UE 301. In this case the UDM 75 would maintain the relation between the UE 301's GPSI and its 3GPP identity assigned during the initial registration of the ambient IoT device when the UE 301 provides the ambient IoT device's GPSI to the UDM 75. Then at step 5 of Fig. 21, when the UDM 75 receives the GPSI of the ambient IoT device to be triggered or paged from the NEF 79, the UDM 75 may retrieve the 3GPP internal identity for this ambient IoT device (e.g. SUPI plus the tag) using its GPSI provided by the NEF 79, and from step 5 in Fig. 21 may forward the IoT device's 3GPP identity (e.g. SUPI plus the tag). The ambient IoT device's 3GPP identity may be used to page the ambient IoT device. Then at step 8, the paged UE 301 may use the ambient IoT device's 3GPP identity (e.g. the SUPI plus the tag) to retrieve its GPSI (the UE 301 may maintain the relation between the ambient IoT device's GPSI and its 3GPP identity after the initial registration that the UDM 75 assigned the 3GPP internal identity (e.g. SUPI plus the tag) for the registering ambient IoT device).
Ninth scenario in Fourth example of the First Aspect:
　　Fig. 22 includes an example of the Ambient IoT device-initiated Service Activation procedure.
　　The detailed processes of the Ninth scenario in Fourth example of the First Aspect are described below with reference to Fig. 22.
　　Step 0. The UE 301 is registered to the AMF 70 and a dedicated PDU Session for the Ambient IoT service has been established with the SMF 71 and the UPF 72. The step 0 may be same to step 0 in Fig. 19.
　　Step 1. The IoT Device 302 has enough energy to communicate with the UE 301 and buffers MO-data to the AF 201 as the Ambient IoT Server. Then, the IoT Device 302 establishes a connection with the UE 301 over the Ambient IoT dedicated air interface and sends the MO-data to the UE 301.
　　Step 2. Steps 10 to 13 in Fig. 8 take place with the following replacements.
　　　　The "UE 3" is replaced with the "UE 301"
　　　　The "RAN 501" is replaced with the "RAN 5"
　　For example, the UE 301 receives the MT-data from the AMF 70, the UE 301 may send the MT-data to the IoT Device 302.
　　For example, the UE 301 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 0 to 2.
　　For example, the UE 301 may perform at least one of steps 0 to 2 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the IoT Device 302 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least step 1.
　　For example, the UE 301 may perform at least step 1 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　According to at least one of disclosure(s) in First Aspect, it can solve at least one of the above-mentioned problem(s).
　　For example, at least one of disclosure(s) in First Aspect can solve the problem that as the current 5G system does not support the automated warehouse inventory scenario, 3GPP operators may lose business opportunities for goods managements using the Ambient IoT devices.
　　For example, at least one of disclosure(s) in First Aspect can solve the problem that as the current 5G system supports neither Manual-Triggered Mode nor Auto-Triggered Mode, 3GPP operators may lose business opportunities for goods managements using the Ambient IoT devices.
　　For example, according to at least one of disclosure(s) in First Aspect, it provides mechanism(s) or procedure(s) for the Ambient IoT or Ambient IoT communication or Ambient IoT service. Therefore, it can solve at least one of the above-mentioned problem(s).
<Second Example Embodiment (Second Aspect)>
　　This aspect includes an architecture and mechanisms to realize the air interface between the IoT Device and network.
　　The Ambient IoT devices may be characterized according to their energy storage capacity, and capability of generating RF signals for their transmissions.
　　The Ambient IoT may be categorized as following three categories with respect to the energy storage capacities according to NPL 3, where Values of E1 and E2 may be defined later and it is possible that E1 = E2, in which case storage 2 and 3 could be replaced by a single description such as "limited energy storage".
　　　　Storage capacity 1: No storage at all
　　　　Storage capacity 2: Up to E1 Joules
　　　　Storage capacity 3: Up to E2 Joules
　　In addition, there are multiple standards for IoT communication in general, for example, RFID standard as defined in ISO/IEC.
　　In order to complaint to new use cases as defined in NPL 2, for example the automated warehouse inventory scenario, the following air interface aspects needs to be clarified.
　　　　One Ambient IoT Service, represented by Service, Service ID or TMGI, may work with multiple Ambient IoT devices that has different energy storage capacity.
　　　　One Ambient IoT Service, represented by Service, Service ID or TMGI, may work with multiple Ambient IoT devices that support different Ambient IoT air interface standard.
　　　　One Ambient IoT Service, represented by Service, Service ID or TMGI, may work among multiple PLMNs including NPN.
　　Fig. 23 includes an example of an Overall network model supporting multiple Ambient IoT devices taking the above-mentioned air interface into account.
　　As an example, Fig. 24 includes an RFID standard that can be considered as a candidate to the Ambient IoT communication.
　　If the Ambient IoT service adapts the existing air interface standards that are widely deployed in the market, smooth adaptation to the Ambient IoT service can be achieved.
First example of the Second Aspect:
　　Fig. 25 includes an example of an independent air interface architecture that supports Ambient IoT service.
　　The independent air interface architecture can be characterized with the following points:
　　　　・The Ambient IoT device 1 and 3GPP defined UE 3 are combined. An Interface 1 is used for communication between the Ambient IoT device 1 and 3GPP defined UE 3.
　　　　For example, at least one of the Ambient IoT device 1 and 3GPP defined UE 3 may be the UE 3, UE 301, IoT Device 302 etc in the First Aspect.
　　　　For example, the combined Ambient IoT device 1 and 3GPP defined UE 3 may be the UE 3, UE 301, IoT Device 302 etc in the First Aspect.
　　　　For example, at least one of the Ambient IoT device 1 and 3GPP defined UE 3 may be expressed as the terminal node.
　　　　For example, the combined Ambient IoT device 1 and 3GPP defined UE 3 may be expressed as the terminal node.
　　　　・The Ambient IoT AP (Access Point) 1 and 3GPP defined logical node 1 are combined. An Interface 2 is used for communication between the Ambient IoT AP (Access Point) 1 and 3GPP defined logical node 1.
　　　　　　For example, 3GPP defined logical node 1 may be the Radio Cell 502 or the RAN 501 for the First scenario in First example of the First Aspect.
　　　　　　For example, 3GPP defined logical node 1 may be the UE-to-Network Relay UE 303 for the First scenario in Second example of the First Aspect.
　　　　　　For example, 3GPP defined logical node 1 may be the IAB Node 502 for the Third example of the First Aspect.
　　　　For example, at least one of the Ambient IoT AP 1 and 3GPP defined logical node 1 may be the Radio Cell 502, RAN 501, UE-to-Network Relay UE 303, RAN 5, IAB Node 502, IAB donor 501, UE 301 etc in the First Aspect.
　　　　For example, at least one of the Ambient IoT AP 1 and the 3GPP defined logical node 1 may be expressed as the network node.
　　　　For example, the combined Ambient IoT AP 1 and the 3GPP defined logical node 1 may be expressed as the network node.
　　　　For example, the combined Ambient IoT AP 1 and 3GPP defined logical node 1 may be the Radio Cell 502, RAN 501, UE-to-Network Relay UE 303, RAN 5, IAB Node 502, IAB donor 501, UE 301 etc in the First Aspect.
　　　　For example, at least one of the Ambient IoT AP 1 and 3GPP defined logical node 1 may be expressed as the network node.
　　　　For example, the combined Ambient IoT AP 1 and the 3GPP defined logical node 1 may be expressed as the network node.
　　　　・For example, the Uu interface may be a PC 5 interface for the Second example of the First Aspect.
　　　　・For example, the Uu interface may be a F1-AP interface for the Third example of the First Aspect (e.g. an interface between the IAB Node 50201 and the IAB donor 501 in Fig. 14).
First scenario in First example of the Second Aspect:
　　Fig. 26 includes an example of the Ambient IoT Service Activation procedure between the Terminal node and Network node.
　　The detailed processes of the First scenario in First example of the Second Aspect are described below with reference to Fig. 26.
　　Step 1. The 3GPP defined logical node 1 receives the Service activation request message including at least one of TMGI and Ambient IoT profile from a 3GPP network.
　　The Ambient IoT profile may be referred by the 3GPP defined logical node 1 for determining whether the Ambient IoT AP 1 supports the Ambient IoT communication as indicated in the Ambient IoT profile. For example, at least one of a Frequency band and Air interface in the received Ambient IoT profile is not supported by the Ambient IoT AP 1, the 3GPP defined logical node 1 stops the process as there is no change to activate the Ambient IoT Service.
　　For example, in a case where the 3GPP defined logical node 1 determines that the Ambient IoT AP 1 does not support the Ambient IoT service based on the received Ambient IoT profile (e.g. in a case where the 3GPP defined logical node 1 determines that the Ambient IoT AP 1 does not support at least one of the Frequency band and Air interface for Ambient IoT service based on the received Ambient IoT profile), the 3GPP defined logical node 1 may stop the process (e.g. the 3GPP defined logical node 1 may not proceed step 2).
　　For example, step 1 in Fig. 26 may be or may correspond to step 1-1 in Fig. 5. In step 1-1 in Fig. 5, the AF 201 may send the Ambient IoT profile regarding the Ambient IoT AP 1 or the Ambient IoT Device 1.
　　For example, step 1 in Fig. 26 may be or may correspond to at least one of steps 1 to 7 in Fig. 8. In steps 1 to 7 in Fig. 8, the Ambient IoT profile regarding the Ambient IoT AP 1 or the Ambient IoT Device 1 may be included in the parameter(s) that the each node communicates.
　　For example, step 1 in Fig. 26 may be or may correspond to step 3 in Fig. 12. In step 3 in Fig. 12, the AF 201 may send the Ambient IoT profile regarding the Ambient IoT AP 1 or the Ambient IoT Device 1.
　　For example, step 1 in Fig. 26 may be or may correspond to step 1 in Fig. 13. In step 1 in Fig. 13, the AF 201 may send the Ambient IoT profile regarding the Ambient IoT AP 1 or the Ambient IoT Device 1.
　　For example, step 1 in Fig. 26 may be or may correspond to step 1-1 in Fig. 19. In step 1-1 in Fig. 19, the AF 201 may send the Ambient IoT profile regarding the Ambient IoT AP 1 or the Ambient IoT Device 1.
　　For example, step 1 in Fig. 26 may be or may correspond to at least one of steps 1 to 7 in Fig. 21. In steps 1 to 7 in Fig. 21, the Ambient IoT profile regarding the Ambient IoT AP 1 or the Ambient IoT Device 1 may be included in the parameter(s) that the each node communicates.
　　The above-mentioned parameter(s) in step 1 (e.g. the parameter(s) in the message of step 1) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 2. The 3GPP defined logical node 1 sends the Service activation request message to the Ambient IoT AP 1 including at least one of the TMGI and Ambient IoT profile over the Interface 2.
　　In a case where the 3GPP defined logical node 1 and the Ambient IoT AP 1 are combined, the communication in step 2 may be performed on an internal interface.
　　The above-mentioned parameter(s) in step 2 (e.g. the parameter(s) in the message of step 2) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 3. The Ambient IoT AP 1 broadcasts a Service activation message with the TMGI. For example, the Ambient IoT AP 1 may broadcast a Service activation message including at least the TMGI. The Service activation message over the Ambient IoT interface may include a function of a Wireless Power Transfer (WPT) to feed an Energy to the Ambient IoT Device 1.
　　The Security parameter in the received Ambient IoT profile may be used by the Ambient IoT AP 1 and the Ambient IoT Device 1 for mutual or Ambient IoT device authentication and authorization. In addition, the Security parameter in the Ambient IoT profile may be used by the Ambient IoT AP 1 and the Ambient IoT Device 1 for integrity protection and confidentiality protection for the Ambient IoT communication over the Ambient IoT interface.
　　The Ambient IoT profile may be referred by the Ambient IoT AP 1 for determining whether the Ambient IoT AP 1 supports the Ambient IoT communication as indicated in the Ambient IoT profile. For example, the Ambient IoT AP 1 may broadcast the Service activation message only on Frequency bands that are indicated in the received Ambient IoT profile.
　　The above-mentioned parameter(s) in step 3 (e.g. the parameter(s) in the message of step 3) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　For example, step 3 in Fig. 26 may be or may correspond to at least one of steps 1-2 and 2 in Fig. 5.
　　For example, step 3 in Fig. 26 may be or may correspond to step 9 in Fig. 8.
　　For example, step 3 in Fig. 26 may be or may correspond to step 2-2 in Fig. 13. In this case, the TMGI may not be included in the signal in step 2-2.
　　For example, step 3 in Fig. 26 may be or may correspond to at least one of steps 1-2 and 2 in Fig. 19.
　　For example, step 3 in Fig. 26 may be or may correspond to step 6-1 in Fig. 20.
　　For example, step 3 in Fig. 26 may be or may correspond to step 11 in Fig. 21.
　　Step 4. In a case where the Ambient IoT Device 1 does not have any power supply, the Ambient IoT Device 1 harvests an energy from the radio signal in step 3.
　　In one example, a buttery or capacitor for energy saving and power supply may be common for both Ambient IoT Device 1 and the 3GPP defined UE 3.
　　Step 5. Upon reception of the Service activation request message in step 1, the 3GPP defined logical node 1 sends the Page message (in a case where the 3GPP defined UE 3 is in Idle state) or sends the Service Notification message (in a case where the 3GPP defined UE 3 is in Active state) to the 3GPP defined UE 3 including the TMGI.
　　The above-mentioned parameter(s) in step 5 (e.g. the parameter(s) in the message of step 5) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　The above-mentioned parameter(s) in step 5 (e.g. the parameter(s) in the message of step 5) may be expressed as parameter(s) or data or information for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　For example, step 5 in Fig. 26 may be or may correspond to at least one of steps 1-2 and 2 in Fig. 5.
　　For example, step 5 in Fig. 26 may be or may correspond to step 9 in Fig. 8.
　　For example, step 5 in Fig. 26 may be or may correspond to step 2-2 in Fig. 13. In this case, the TMGI may not be included in the signal in step 2-2.
　　For example, step 5 in Fig. 26 may be or may correspond to at least one of steps 1-2 and 2 in Fig. 19.
　　For example, step 5 in Fig. 26 may be or may correspond to step 6-1 in Fig. 20.
　　For example, step 5 in Fig. 26 may be or may correspond to step 11 in Fig. 21.
　　Step 6. Upon reception of the Page message or Service Notification message in Step 5, the 3GPP defined UE 3 sends the IoT data request message to the Ambient IoT Device 1 for requesting the Ambient IoT data for the Ambient IoT service that corresponds to the TMGI over the Interface 1.
　　Step 7. The Ambient IoT Device 1 collects the Ambient IoT data (e.g. MO-data) for the Ambient IoT service that corresponds to the TMGI and sends it to the 3GPP defined UE 3.
　　Step 8. The 3GPP defined UE 3 sends the Service Request message to the 3GPP defined logical node 1 including the MO-data.
　　In one example, the Service Request message may be a new or existing NAS message or a new or existing AS message.
　　The above-mentioned parameter(s) in step 8 (e.g. the parameter(s) in the message of step 8) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　The above-mentioned parameter(s) in step 8 (e.g. the parameter(s) in the message of step 8) may be expressed as parameter(s) or data or information for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　For example, step 8 in Fig. 26 may be or may correspond to step 5 in Fig. 5. For example, the 3GPP defined UE 3 may send the Registration Request message including the MO-data to the 3GPP defined logical node 1.
　　For example, step 8 in Fig. 26 may be or may correspond to step 10 in Fig. 8. For example, the 3GPP defined UE 3 may send the Control Plane Service Request message including the MO-data to the 3GPP defined logical node 1.
　　For example, step 8 in Fig. 26 may be or may correspond to step 4 in Fig. 13. For example, the 3GPP defined UE 3 may send the Group Member Discovery Response message including the MO-data to the 3GPP defined logical node 1.
　　For example, step 8 in Fig. 26 may be or may correspond to step 5 in Fig. 19. For example, the 3GPP defined UE 3 may send the Registration Request message including the MO-data to the 3GPP defined logical node 1.
　　For example, step 8 in Fig. 26 may be or may correspond to step 6-1 in Fig. 20. For example, the 3GPP defined UE 3 may send the MO-data to the 3GPP defined logical node 1.
　　For example, step 8 in Fig. 26 may be or may correspond to step 11 in Fig. 21. For example, the 3GPP defined UE 3 may send the MO-data to the 3GPP defined logical node 1.
　　Step 9. Upon reception of the MO-data from the 3GPP defined UE 3, the 3GPP defined logical node 1 sends the Service Request message including the MO-data to the 3GPP network.
　　In one example, the Service Request message may be a new or existing NAS message or a new or existing AS message.
　　The above-mentioned parameter(s) in step 9 (e.g. the parameter(s) in the message of step 9) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　The above-mentioned parameter(s) in step 9 (e.g. the parameter(s) in the message of step 9) may be expressed as parameter(s) or data or information for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　For example, step 9 in Fig. 26 may be or may correspond to step 6 in Fig. 5. For example, the 3GPP logical node 1 may send the Registration Request message including the MO-data to the 3GPP network (e.g. the AMF 70 etc).
　　For example, step 9 in Fig. 26 may be or may correspond to step 11 in Fig. 8. For example, the 3GPP logical node 1 may send the Control Plane Service Request message including the MO-data to the 3GPP network (e.g. the AMF 70 etc).
　　For example, step 9 in Fig. 26 may be or may correspond to step 5 in Fig. 13. For example, the 3GPP logical node 1 may send the MO-data to the 3GPP network (or to the AF 201).
　　For example, step 9 in Fig. 26 may be or may correspond to step 5 or 6 in Fig. 19. For example, the 3GPP logical node 1 may send the Registration Request message including the MO-data to the 3GPP network (e.g. the RAN 5, the AMF 70 etc).
　　For example, step 9 in Fig. 26 may be or may correspond to step 6-2 in Fig. 20. For example, the 3GPP logical node 1 may send the MO-data to the 3GPP network (or to the AF 201).
　　For example, step 9 in Fig. 26 may be or may correspond to step 11 in Fig. 21. For example, the 3GPP logical node 1 may send the MO-data to the 3GPP network (or to the AF 201).
　　For example, the Ambient IoT data (e.g. MT-data) for the Ambient IoT service may be sent to the Ambient IoT Device 1 in the same manner as the process(es) in Fig. 26.
　　For example, in a case where the 3GPP defined logical node 1 receives the MT-data from a 3GPP network (e.g. in a case where the 3GPP defined logical node 1 receives a message including at least one of the TMGI, Ambient IoT profile and MT-data from a 3GPP network), the 3GPP defined logical node 1 may send the MT-data to the Ambient IoT AP 1 (e.g. the 3GPP defined logical node 1 may send a message including at least one of the TMGI, Ambient IoT profile and MT-data to the Ambient IoT AP 1). Then the Ambient IoT AP 1 may perform the process(es) in step 3, and the Ambient IoT Device 1 may perform the process(es) in step 4. Then the 3GPP defined logical node 1 may send the Page message or the Service Notification message to the 3GPP defined UE 3 including at least one of the TMGI and MT-data. Then the 3GPP defined UE 3 may send the MT-data to the Ambient IoT Device 1.
　　For example, the 3GPP defined logical node 1 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1, 2, 8 and 9.
　　For example, the 3GPP defined logical node 1 may perform at least one of steps 1, 2, 8 and 9 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the Ambient IoT AP 1 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 2 and 3.
　　For example, the Ambient IoT AP 1 may perform at least one of steps 2 and 3 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the Ambient IoT Device 1 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 3, 4, 6 and 7.
　　For example, the Ambient IoT Device 1 may perform at least one of steps 3, 4, 6 and 7 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the 3GPP defined UE 3 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 5 to 8.
　　For example, the 3GPP defined UE 3 may perform at least one of steps 5 to 8 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
Second example of the Second Aspect:
　　Fig. 27 includes an example of a converged air interface architecture that supports Ambient IoT service.
　　The converged air interface architecture can be characterized with the following points:
　　　　・The Ambient IoT device 1 and 3GPP defined UE 3 are combined. An Interface 1 is used for communication between the Ambient IoT device 1 and 3GPP defined UE 3.
　　　　For example, at least one of the Ambient IoT device 1 and 3GPP defined UE 3 may be the UE 3, UE 301, IoT Device 302 etc in the First Aspect.
　　　　For example, the combined Ambient IoT device 1 and 3GPP defined UE 3 may be the UE 3, UE 301, IoT Device 302 etc in the First Aspect.
　　　　For example, at least one of the Ambient IoT device 1 and 3GPP defined UE 3 may be expressed as the terminal node.
　　　　For example, the combined Ambient IoT device 1 and 3GPP defined UE 3 may be expressed as the terminal node.
　　　　・The 3GPP defined logical node 1 may be a radio cell for the 3GPP access technology.
　　　　　　For example, 3GPP defined logical node 1 may be the Radio Cell 502 or the RAN 501 for the First scenario in First example of the First Aspect.
　　　　　　For example, 3GPP defined logical node 1 may be the UE-to-Network Relay UE 303 for the First scenario in Second example of the First Aspect.
　　　　　　For example, 3GPP defined logical node 1 may be the IAB Node 502 for the Third example of the First Aspect.
　　　　For example, the 3GPP defined logical node 1 may be the Radio Cell 502, RAN 501, UE-to-Network Relay UE 303, RAN 5, IAB Node 502, IAB donor 501, UE 301 etc in the First Aspect.
　　　　For example, the 3GPP defined logical node may be expressed as the network node.
　　　　・For example, the Uu interface may be a PC 5 interface for the Second example of the First Aspect.
　　　　・For example, the Uu interface may be a F1-AP interface for the Third example of the First Aspect (e.g. an interface between the IAB Node 50201 and the IAB donor 501 in Fig. 14).
First scenario in Second example of the Second Aspect:
　　Fig. 28 includes an example of the Ambient IoT Service Activation procedure between Terminal node and Network node.
　　The detailed processes of the First scenario in Second example of the Second Aspect are described below with reference to Fig. 28.
　　Step 1. The 3GPP defined logical node 1 receives the Service activation request message including at least one of TMGI and Ambient IoT profile from a 3GPP network.
　　The Ambient IoT profile may be referred by the 3GPP defined logical node 1 for determining whether the Ambient IoT AP 1 supports the Ambient IoT communication as indicated in the Ambient IoT profile. For example, at least one of a Frequency band and Air interface in the received Ambient IoT profile is not supported by the Ambient IoT AP 1, the 3GPP defined logical node 1 stop the process as there is no change to activate the Ambient IoT Service.
　　Step 1 may be same to step 1 in Fig. 26.
　　The above-mentioned parameter(s) in step 1 (e.g. the parameter(s) in the message of step 1) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 2. The 3GPP defined logical node 1 broadcasts a Service activation message with the TMGI. For example, the 3GPP defined logical node 1 may broadcast a Service activation message including at least the TMGI. The Service activation message over the Uu interface may include a function of a Wireless Power Transfer (WPT) to feed an Energy to the Ambient IoT Device 1.
　　The Security parameter in the received Ambient IoT profile may be used by the3GPP defined logical node 1 and the Ambient IoT Device 1 for mutual or Ambient IoT device authentication and authorization. In addition, the Security parameter in the Ambient IoT profile may be used by the 3GPP defined logical node 1 and the Ambient IoT Device 1 for integrity protection and confidentiality protection for the Ambient IoT communication over the Uu interface.
　　In one example, the Ambient IoT air interface in the Uu interface may be new 3GPP defined physical interface with the following characteristics:
　　　　New or existing BCCH may be used for an Ambient IoT communication related data (I.e., TMGI) distribution.
　　　　New physical channel is defined for the function of a Wireless Power Transfer (WPT). New physical channel for the function of a Wireless Power Transfer (WPT) may be called as Power Physical Channel (PoP-CH, or PP-CH), Downlink Shared Power Physical Channel (DSPoP-CH or DSPP-CH).
　　The above-mentioned parameter(s) in step 2 (e.g. the parameter(s) in the message of step 2) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　The Ambient IoT profile may be referred by the 3GPP defined logical node 1 for determining whether the 3GPP defined logical node 1 supports the Ambient IoT communication as indicated in the Ambient IoT profile. For example, the 3GPP defined logical node 1 broadcasts the Service activation message only to Frequency bands that are indicated in the received Ambient IoT profile.
　　The above-mentioned parameter(s) in step 2 (e.g. the parameter(s) in the message of step 2) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　For example, step 2 in Fig. 28 may be or may correspond to at least one of steps 1-2 and 2 in Fig. 5.
　　For example, step 2 in Fig. 28 may be or may correspond to step 9 in Fig. 8.
　　For example, step 2 in Fig. 28 may be or may correspond to step 2-2 in Fig. 13. In this case, the TMGI may not be included in the signal in step 2-2.
　　For example, step 2 in Fig. 28 may be or may correspond to at least one of steps 1-2 and 2 in Fig. 19.
　　For example, step 2 in Fig. 28 may be or may correspond to step 6-1 in Fig. 20.
　　For example, step 2 in Fig. 28 may be or may correspond to step 11 in Fig. 21.
　　Step 3. In case the Ambient IoT Device 1 does not have any power supply, the Ambient IoT Device 1 harvests an energy from the radio signal in step 2.
　　In one example, a buttery or capacitor for energy saving and power supply may be common for both Ambient IoT Device 1 and the 3GPP defined UE 3.
　　Step 4. Steps 5 to 9 in Fig. 26 take place.
　　For example, the 3GPP defined logical node 1 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1, 2, and 4.
　　For example, the 3GPP defined logical node 1 may perform at least one of steps 1, 2, and 4 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the Ambient IoT Device 1 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 2 and 4.
　　For example, the Ambient IoT Device 1 may perform at least one of steps 2 and 4 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the 3GPP defined UE 3 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least step 4.
　　For example, the 3GPP defined UE 3 may perform at least step 4 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
Third example of the Second Aspect:
　　Fig. 29 includes an example that an Ambient IoT air interface is deployed in the UE 3 as the personal network of the UE 3 to support Ambient IoT service.
　　The Ambient IoT air interface which is deployed in the UE as the personal network can be characterized with the following points:
　　　　・The Ambient IoT device 1 and Ambient IoT AP 1 are deployed in the personal network of the UE 3.
　　For example, the Ambient IoT device 1 may be the UE 3, UE 301, IoT Device 302 etc in the First Aspect. The Ambient IoT device 1 may be expressed as the terminal node.
　　The Ambient IoT air interface is used for communication between the Ambient IoT Device 1 and Ambient IoT AP 1.
　　The Ambient IoT AP 1 and 3GPP defined UE 3 may be combined. An Interface 2 is used for communication between the Ambient IoT AP 1 and 3GPP defined logical node 1.
　　For example, at least one of the Ambient IoT AP 1 and 3GPP defined UE 3 may be the Radio Cell 502, RAN 501, UE-to-Network Relay UE 303, RAN 5, IAB Node 502, IAB donor 501, UE 301 etc in the First Aspect.
　　For example, the combined Ambient IoT AP 1 and the 3GPP defined UE 3 may be the Radio Cell 502, RAN 501, UE-to-Network Relay UE 303, RAN 5, IAB Node 502, IAB donor 501, UE 301 etc in the First Aspect.
　　For example, at least one of the Ambient IoT AP 1 and the 3GPP defined logical node 1 may be expressed as the network node.
　　For example, the combined Ambient IoT AP 1 and the 3GPP defined logical node 1 may be expressed as the network node.
　　For example, the RAN may be the RAN 5, RAN 501, IAB donor 501 etc in the First Aspect.
First scenario in Third example of the Second Aspect:
　　Fig. 30 includes an example of the Ambient IoT Service Activation procedure between IoT Device and UE.
　　The detailed processes of the First scenario in Third example of the Second Aspect are described below with reference to Fig. 30.
　　Step 1. The 3GPP defined UE 3 receives the Service activation request message including at least one of TMGI and Ambient IoT profile from a 3GPP network.
　　The Ambient IoT profile may be referred by the 3GPP defined UE 3 for determining whether the Ambient IoT AP 1 supports the Ambient IoT communication as indicated in the Ambient IoT profile. For example, at least one of a Frequency band and Air interface in the received Ambient IoT profile is not supported by the Ambient IoT AP 1, the 3GPP defined UE 3 stops the process as there is no change to activate the Ambient IoT Service.
　　For example, in a case where the 3GPP defined UE 3 determines that the Ambient IoT AP 1 does not support the Ambient IoT service based on the received Ambient IoT profile (e.g. in a case where the 3GPP defined UE 3 determines that the Ambient IoT AP 1 does not support at least one of the Frequency band and Air interface for Ambient IoT service based on the received Ambient IoT profile), the 3GPP defined UE 3 may stop the process (e.g. the 3GPP defined UE 3 may not proceed step 2).
　　For example, step 1 in Fig. 30 may be or may correspond to step 1-1 in Fig. 5. In step 1-1 in Fig. 5, the AF 201 may send the Ambient IoT profile regarding the Ambient IoT AP 1 or the Ambient IoT Device 1.
　　For example, step 1 in Fig. 30 may be or may correspond to at least one of steps 1 to 7 in Fig. 8. In steps 1 to 7 in Fig. 8, the Ambient IoT profile regarding the Ambient IoT AP 1 or the Ambient IoT Device 1 may be included in the parameter(s) that the each node communicates.
　　For example, step 1 in Fig. 30 may be or may correspond to step 3 in Fig. 12. In step 3 in Fig. 12, the AF 201 may send the Ambient IoT profile regarding the Ambient IoT AP 1 or the Ambient IoT Device 1.
　　For example, step 1 in Fig. 30 may be or may correspond to step 1 in Fig. 13. In step 1 in Fig. 13, the AF 201 may send the Ambient IoT profile regarding the Ambient IoT AP 1 or the Ambient IoT Device 1.
　　For example, step 1 in Fig. 30 may be or may correspond to step 1-1 in Fig. 19. In step 1-1 in Fig. 19, the AF 201 may send the Ambient IoT profile regarding the Ambient IoT AP 1 or the Ambient IoT Device 1.
　　For example, step 1 in Fig. 30 may be or may correspond to at least one of steps 1 to 7 in Fig. 21. In steps 1 to 7 in Fig. 21, the Ambient IoT profile regarding the Ambient IoT AP 1 or the Ambient IoT Device 1 may be included in the parameter(s) that the each node communicates.
　　The above-mentioned parameter(s) in step 1 (e.g. the parameter(s) in the message of step 1) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 2. The 3GPP defined UE 3 sends the Service activation request message to the Ambient IoT AP 1 including at least one of the TMGI and Ambient IoT profile over the Interface 2.
　　In a case where the 3GPP defined UE 3 and the Ambient IoT AP 1 are combined, the communication in step 2 may be performed on an internal interface.
　　The above-mentioned parameter(s) in step 2 (e.g. the parameter(s) in the message of step 2) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 3. The Ambient IoT AP 1 broadcasts a Service activation message with the TMGI. For example, the Ambient IoT AP 1 may broadcast a Service activation message including at least the TMGI. The Service activation message over the Ambient IoT interface may include a function of a Wireless Power Transfer (WPT) to feed an Energy to the Ambient IoT Device 1.
　　The Security parameter in the received Ambient IoT profile may be used by the Ambient IoT AP 1 and the Ambient IoT Device 1 for mutual or Ambient IoT device authentication and authorization. In addition, the Security parameter in the Ambient IoT profile may be used by the Ambient IoT AP 1 and the Ambient IoT Device 1 for integrity protection and confidentiality protection for the Ambient IoT communication over the Ambient IoT interface.
　　The Ambient IoT profile may be referred by the Ambient IoT AP 1 for determining whether the Ambient IoT AP 1 supports the Ambient IoT communication as indicated in the Ambient IoT profile. For example, the Ambient IoT AP 1 may broadcast the Service activation message only on Frequency bands that are indicated in the received Ambient IoT profile.
　　The above-mentioned parameter(s) in step 3 (e.g. the parameter(s) in the message of step 3) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　For example, step 3 in Fig. 30 may be or may correspond to at least one of steps 1-2 and 2 in Fig. 5.
　　For example, step 3 in Fig. 30 may be or may correspond to step 9 in Fig. 8.
　　For example, step 3 in Fig. 30 may be or may correspond to step 2-2 in Fig. 13. In this case, the TMGI may not be included in the signal in step 2-2.
　　For example, step 3 in Fig. 30 may be or may correspond to at least one of steps 1-2 and 2 in Fig. 19.
　　For example, step 3 in Fig. 30 may be or may correspond to step 6-1 in Fig. 20.
　　For example, step 3 in Fig. 30 may be or may correspond to step 11 in Fig. 21.
　　Step 4. In a case where the Ambient IoT Device 1 does not have any power supply, the Ambient IoT Device 1 harvests an energy from the radio signal in step 3.
　　Step 5. Requested data collection is performed over the Ambient IoT interface between the Ambient IoT Device 1 and Ambient IoT AP 1.
　　For example, upon reception of the Service activation request message in Step 2, the Ambient IoT AP 1 sends the IoT data request message to the Ambient IoT Device 1 for requesting the Ambient IoT data (e.g. MO-data) for the Ambient IoT service that corresponds to the TMGI over the Ambient IoT air interface. Then the Ambient IoT Device 1 may send the MO-data to the Ambient IoT AP 1.
　　The Ambient IoT AP 1 may collect the Ambient IoT data (e.g. MO-data) for the Ambient IoT service that corresponds to the TMGI from the Ambient IoT Device 1.
　　For example, step 5 in Fig. 30 may be or may correspond to step 5 in Fig. 5. For example, the Ambient IoT Device 1 may send the Registration Request message including the MO-data to the Ambient IoT AP 1.
　　For example, step 5 in Fig. 30 may be or may correspond to step 10 in Fig. 8. For example, the Ambient IoT Device 1 may send the Control Plane Service Request message including the MO-data to the Ambient IoT AP 1.
　　For example, step 5 in Fig. 30 may be or may correspond to step 4 in Fig. 13. For example, the Ambient IoT Device 1 may send the Group Member Discovery Response message including the MO-data to the Ambient IoT AP 1.
　　For example, step 5 in Fig. 30 may be or may correspond to step 5 in Fig. 19. For example, the Ambient IoT Device 1 may send the Registration Request message including the MO-data to the Ambient IoT AP 1.
　　For example, step 5 in Fig. 30 may be or may correspond to step 6-1 in Fig. 20. For example, the Ambient IoT Device 1 may send the MO-data to the Ambient IoT AP 1.
　　For example, step 5 in Fig. 30 may be or may correspond to step 11 in Fig. 21. For example, the Ambient IoT Device 1 may send the MO-data to the Ambient IoT AP 1.
　　The above-mentioned parameter(s) in step 5 (e.g. the parameter(s) in the message of step 5) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　The above-mentioned parameter(s) in step 5 (e.g. the parameter(s) in the message of step 5) may be expressed as parameter(s) or data or information for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 6. After the Ambient IoT AP 1 receives the Requested data (e.g. the MO-data) from the Ambient IoT Device 1, the Ambient IoT AP 1 sends the Service Request message to the 3GPP defined UE 3 including the MO-data.
　　In one example, the Service Request message may be a new or existing NAS message or a new or existing AS message.
　　The above-mentioned parameter(s) in step 6 (e.g. the parameter(s) in the message of step 6) may be expressed as parameter(s) or data or information for activating or for starting the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　The above-mentioned parameter(s) in step 6 (e.g. the parameter(s) in the message of step 6) may be expressed as parameter(s) or data or information for the Ambient IoT or the Ambient IoT communication or the Ambient IoT service.
　　Step 7. Upon reception of the MO-data from the Ambient IoT AP 1, the 3GPP defined UE 3 sends the Service Request message including MT-data to the 3GPP network.
　　One example, the Service Request message may be a new or existing NAS message or a new or existing AS message.
　　For example, step 7 in Fig. 30 may be or may correspond to step 6 in Fig. 5. For example, the 3GPP defined UE 3 may send the Registration Request message including the MO-data to the 3GPP network (e.g. the AMF 70 etc).
　　For example, step 7 in Fig. 30 may be or may correspond to step 11 in Fig. 8. For example, the 3GPP defined UE 3 may send the Control Plane Service Request message including the MO-data to the 3GPP network (e.g. the AMF 70 etc).
　　For example, step 7 in Fig. 30 may be or may correspond to step 5 in Fig. 13. For example, the 3GPP defined UE 3 may send the MO-data to the 3GPP network (or to the AF 201).
　　For example, step 7 in Fig. 30 may be or may correspond to step 5 or 6 in Fig. 19. For example, the 3GPP defined UE 3 may send the Registration Request message including the MO-data to the 3GPP network (e.g. the RAN 5, the AMF 70 etc).
　　For example, step 7 in Fig. 30 may be or may correspond to step 6-2 in Fig. 20. For example, the 3GPP defined UE 3 may send the MO-data to the 3GPP network (or to the AF 201).
　　For example, step 7 in Fig. 30 may be or may correspond to step 11 in Fig. 21. For example, the 3GPP defined UE 3 may send the MO-data to the 3GPP network (or to the AF 201).
　　For example, the Ambient IoT data (e.g. MT-data) for the Ambient IoT service may be sent to the Ambient IoT Device 1 in the same manner as the process(es) in Fig. 30.
　　For example, in a case where the 3GPP defined UE 3 receives the MT-data from a 3GPP network (e.g. in a case where the 3GPP defined UE 3 receives a message including at least one of the TMGI, Ambient IoT profile and MT-data from a 3GPP network), the 3GPP defined UE 3 may send the MT-data to the Ambient IoT AP 1 (e.g. the 3GPP defined UE 3 may send a message including at least one of the TMGI, Ambient IoT profile and MT-data to the Ambient IoT AP 1). Then the Ambient IoT AP 1 may perform the process(es) in step 3, and the Ambient IoT Device 1 may perform the process(es) in step 4. Then the Ambient IoT AP 1 may send the MT-data to the Ambient IoT Device 1.
　　For example, the 3GPP defined UE 3 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 1, 2, 6 and 7.
　　For example, the 3GPP defined UE 3 may perform at least one of steps 1, 2, 6 and 7 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the Ambient IoT AP 1 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 2, 3, 5 and 6.
　　For example, the Ambient IoT AP 1 may perform at least one of steps 2, 3, 5 and 6 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　For example, the Ambient IoT Device 1 may perform a Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication by performing at least one of steps 3 to 5.
　　For example, the Ambient IoT Device 1 may perform at least one of steps 3 to 5 for the Service Activation procedure for the Ambient IoT or Ambient IoT service or Ambient IoT communication.
　　According to at least one of disclosure(s) in Second Aspect, it can solve at least one of the above-mentioned problem(s).
　　For example, at least one of disclosure(s) in Second Aspect can solve the problem that as the current 5G system does not support the automated warehouse inventory scenario, 3GPP operators may lose business opportunities for goods managements using the Ambient IoT devices.
　　For example, at least one of disclosure(s) in Second Aspect can solve the problem that as the current 5G system supports neither Manual-Triggered Mode nor Auto-Triggered Mode, 3GPP operators may lose business opportunities for goods managements using the Ambient IoT devices.
　　For example, according to at least one of disclosure(s) in Second Aspect, it provides mechanism(s) or procedure(s) for the Ambient IoT or Ambient IoT communication or Ambient IoT service. Therefore, it can solve at least one of the above-mentioned problem(s).
<System overview>
　　Fig. 31 schematically illustrates a telecommunication system 1 for a mobile (cellular or wireless) to which the above aspects are applicable.
　　The telecommunication system 1 represents a system overview in which an end-to-end communication is possible. For example, UE 3 (or user equipment, 'mobile device' 3) communicates with other UEs 3 or service servers in the data network 20 via respective (R)AN nodes 5 and a core network 7.
　　The (R)AN node 5 supports any radio accesses including a 5G radio access technology (RAT), an E-UTRA radio access technology, a beyond 5G RAT, a 6G RAT and non-3GPP RAT including wireless local area network (WLAN) technology as defined by the Institute of Electrical and Electronics Engineers (IEEE).
　　The (R)AN node 5 may split into a Radio Unit (RU), Distributed Unit (DU) and Centralized Unit (CU). In some aspects, each of the units may be connected to each other and structure the (R)AN node 5 by adopting an architecture as defined by the Open RAN (O-RAN) Alliance, where the units above are referred to as O-RU, O-DU and O-CU respectively.
　　The (R)AN node 5 may be split into control plane function and user plane function. Further, multiple user plane functions can be allocated to support a communication. In some aspects, user traffic may be distributed to multiple user plane functions and user traffic over each user plane functions are aggregated in both the UE 3 and the (R)AN node 5. This split architecture may be called as 'dual connectivity' or 'Multi connectivity'.
　　The (R)AN node 5 can also support a communication using the satellite access. In some aspects, the (R)AN node 5 may support a satellite access and a terrestrial access.
　　In addition, the (R)AN node 5 can also be referred as an access node for a non-wireless access. The non-wireless access includes a fixed line access as defined by the Broadband Forum (BBF) and an optical access as defined by the Innovative Optical and Wireless Network (IOWN).
　　The core network 7 may include logical nodes (or 'functions') for supporting a communication in the telecommunication system 1. For example, the core network 7 may be 5G Core Network (5GC) that includes, amongst other functions, control plane functions and user plane functions. Each function in logical nodes can be considered as a network function. The network function may be provided to another node by adapting the Service Based Architecture (SBA).
　　A Network Function can be deployed as distributed, redundant, stateless, and scalable that provides the services from several locations and several execution instances in each location by adapting the network virtualization technology as defined by the European Telecommunications Standards Institute, Network Functions Virtualization (ETSI NFV).
　　The core network 7 may support the Non-Public Network (NPN). The NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
　　As is well known, a UE 3 may enter and leave the areas (i.e. radio cells) served by the (R)AN node 5 as the UE 3 is moving around in the geographical area covered by the telecommunication system 1. In order to keep track of the UE 3 and to facilitate movement between the different (R)AN nodes 5, the core network 7 comprises at least one access and mobility management function (AMF) 70. The AMF 70 is in communication with the (R)AN node 5 coupled to the core network 7. In some core networks, a mobility management entity (MME) or a mobility management node for beyond 5G or a mobility management node for 6G may be used instead of the AMF 70.
　　The core network 7 also includes, amongst others, a Session Management Function (SMF) 71, a User Plane Function (UPF) 72, a Policy Control Function (PCF) 73, a Network Data Analytics Function (NWDAF) 74, a Unified Data Management (UDM) 75, a Network Slice Selection Function (NSSF) 76, a Network Slice Admission Control Function (NSACF) 77, Authentication Server Function (AUSF) 78 and Network Exposure Function (NEF) 79. When the UE 3 is roaming to a visited Public Land Mobile Network (VPLMN), a home Public Land Mobile Network (HPLMN) of the UE 3 provides the UDM 75 and at least some of the functionalities of the SMF 71, UPF 72, PCF 73 and NSACF 77 for the roaming-out UE 3.
　　The UE 3 and a respective serving (R)AN node 5 are connected via an appropriate air interface (for example the so-called "Uu" interface and/or the like). Neighboring (R)AN node 5 are connected to each other via an appropriate (R)AN node 5 to (R)AN node interface (such as the so-called "Xn" interface and/or the like). Each (R)AN node 5 is also connected to nodes in the core network 7 (such as the so-called core network nodes) via an appropriate interface (such as the so-called "N2"/ "N3" interface(s) and/or the like). From the core network 7, connection to a data network 20 is also provided. The data network 20 can be an internet, a public network, an external network, a private network or an internal network of the PLMN. In case that the data network 20 is provided by a PLMN operator or Mobile Virtual Network Operator (MVNO), the IP Multimedia Subsystem (IMS) service may be provided by that data network 20. The UE 3 can be connected to the data network 20 using IPv4, IPv6, IPv4v6, Ethernet or unstructured data type. The data network may include an Application Function (AF) 201.
　　The "Uu" interface may include a Control plane of Uu interface and User plane of Uu interface.
　　The User plane of Uu interface is responsible to convey user traffic between the UE 3 and a serving (R)AN node 5. The User plane of Uu interface may have a layered structure with SDAP, PDCP, RLC and MAC sublayer over the physical connection (i.e. PHY sublayer).
　　The Control plane of Uu interface is responsible to establish, modify and release a connection between the UE 3 and a serving (R)AN node 5. The Control plane of Uu interface may have a layered structure with RRC, PDCP, RLC and MAC sublayers over the physical connection.
　　For example, the following messages are communicated over the RRC layer to support AS signaling.
　　　　RRC Setup Request message: This message is sent from the UE 3 to the (R)AN node 5. In addition to the parameters that are disclosed by Aspects in this disclosure, following parameters may be included together in the RRC Setup Request message.
　　　　　　establishmentCause and ue-Identity. The ue-Identity may have a value of ng-5G-S-TMSI-Part1 or randomValue.
　　　　RRC Setup message: This message is sent from the (R)AN node 5 to the UE 3. In addition to the parameters that are disclosed by Aspects in this disclosure, following parameters may be included together in the RRC Setup message.
　　　　　　masterCellGroup and radioBearerConfig.
　　　　RRC setup complete message: This message is sent from the UE 3 to the (R)AN node 5. In addition to the parameters that are disclosed by Aspects in this disclosure, following parameters may be included together in the RRC setup complete message.
　　　　　　guami-Type, iab-NodeIndication, idleMeasAvailable, ue-MeasurementsAvailable, mobilityState, ng-5G-S-TMSI-Part2, registeredAMF, selectedPLMN-Identity, s-NSSAI-List , onboardingRequest.
　　The UE 3 and the AMF 70 are connected via an appropriate interface (for example the so-called N1 interface and/or the like). The N1 interface is responsible to provide a communication between the UE 3 and the AMF 70 to support NAS signaling. The N1 interface may be established over a 3GPP access and over a non-3GPP access. For example, the following messages are communicated over the N1 interface.
　　　　registration request message: This message is sent from the UE 3 to the AMF 70. In addition to the parameters that are disclosed by Aspects in this disclosure, following parameters may be included together in the registration request message.
　　　　　　5GS registration type, ngKSI, 5GS mobile identity, Non-current native NAS key set identifier, 5GMM capability, UE security capability, Requested NSSAI, Last visited registered TAI, S1 UE network capability, Uplink data status, PDU session status, MICO indication, UE status, Additional GUTI, Allowed PDU session status, UE's usage setting, Requested DRX parameters, EPS NAS message container, LADN indication, Payload container type, Payload container, Network slicing indication, 5GS update type, Mobile station classmark 2, Supported codecs, NAS message container, EPS bearer context status, Requested extended DRX parameters, T3324 value, UE radio capability ID, Requested mapped NSSAI, Additional information requested, Requested WUS assistance information, N5GC indication and Requested NB-N1 mode DRX parameters.
　　　　registration accept message: This message is sent from the AMF 70 to the UE 3. In addition to the parameters that are disclosed by Aspects in this disclosure, following parameters may be included together in the registration accept message.
　　　　　　5GS registration result, 5G-GUTI, Equivalent PLMNs, TAI list, Allowed NSSAI, Rejected NSSAI, Configured NSSAI, 5GS network feature support, PDU session status, PDU session reactivation result, PDU session reactivation result error cause, LADN information, MICO indication, Network slicing indication, Service area list, T3512 value, Non-3GPP de-registration timer value, T3502 value, Emergency number list, Extended emergency number list, SOR transparent container, EAP message, NSSAI inclusion mode, Operator-defined access category definitions, Negotiated DRX parameters, Non-3GPP NW policies, EPS bearer context status, Negotiated extended DRX parameters, T3447 value, T3448 value, T3324 value, UE radio capability ID, UE radio capability ID deletion indication, Pending NSSAI, Ciphering key data, CAG information list, Truncated 5G-S-TMSI configuration, Negotiated WUS assistance information, Negotiated NB-N1 mode DRX parameters and Extended rejected NSSAI.
　　　　Registration Complete message: This message is sent from the UE 3 to the AMF 70. In addition to the parameters that are disclosed by Aspects in this disclosure, following parameters may be included together in the Registration Complete message.
　　　　　　SOR transparent container.
　　　　Authentication Request message: This message is sent from the AMF 70 to the UE 3. In addition to the parameters that are disclosed by Aspects in this disclosure, following parameters may be included together in the Authentication Request message.
　　　　　　ngKSI, ABBA, Authentication parameter RAND (5G authentication challenge), Authentication parameter AUTN (5G authentication challenge) and EAP message.
　　　　Authentication Response message: This message is sent from the UE 3 to the AMF 70. In addition to the parameters that are disclosed by Aspects in this disclosure, following parameters may be populated together in the Authentication Response message.
　　　　　　Authentication response message identity, Authentication response parameter and EAP message.
　　　　Authentication Result message: This message is sent from the AMF 70 to the UE 3. In addition to the parameters that are disclosed by Aspects in this disclosure, following parameters may be populated together in the Authentication Result message.
　　　　　　ngKSI, EAP message and ABBA.
　　　　Authentication Failure message: This message is sent from the UE 3 to the AMF 70. In addition to the parameters that are disclosed by Aspects in this disclosure, following parameters may be populated together in the Authentication Failure message.
　　　　　　Authentication failure message identity, 5GMM cause and Authentication failure parameter.
　　　　Authentication Reject message: This message is sent from the AMF 70 to the UE 3. In addition to the parameters that are disclosed by Aspects in this disclosure, following parameters may be populated together in the Authentication Reject message.
　　　　　　EAP message.
　　　　Service Request message: This message is sent from the UE 3 to the AMF 70. In addition to the parameters that are disclosed by Aspects in this disclosure, following parameters may be populated together in the Service Request message.
　　　　　　ngKSI, Service type, 5G-S-TMSI, Uplink data status, PDU session status, Allowed PDU session status, NAS message container.
　　　　Service Accept message: This message is sent from the AMF 70 to the UE 3. In addition to the parameters that are disclosed by Aspects in this disclosure, following parameters may be populated together in the Service Accept message.
　　　　　　PDU session status, PDU session reactivation result, PDU session reactivation result error cause, EAP message and T3448 value.
　　　　Service Reject message: This message is sent from the AMF 70 to the UE 3. In addition to the parameters that are disclosed by Aspects in this disclosure, following parameters may be populated together in the Service Reject message.
　　　　　　5GMM cause, PDU session status, T3346 value, EAP message, T3448 value and CAG information list.
　　　　Configuration Update Command message: This message is sent from the AMF 70 to the UE 3. In addition to the parameters that are disclosed by Aspects in this disclosure, following parameters may be populated together in the Configuration Update Command message.
　　　　　　Configuration update indication,5G-GUTI, TAI list, Allowed NSSAI, Service area list, Full name for network, Short name for network, Local time zone, Universal time and local time zone, Network daylight saving time, LADN information, MICO indication, Network slicing indication, Configured NSSAI, Rejected NSSAI, Operator-defined access category definitions, SMS indication, T3447 value, CAG information list, UE radio capability ID, UE radio capability ID deletion indication, 5GS registration result, Truncated 5G-S-TMSI configuration, Additional configuration indication and Extended rejected NSSAI.
　　　　Configuration Update Complete message: This message is sent from the UE 3 to the AMF 70. In addition to the parameters that are disclosed by Aspects in this disclosure, following parameters may be populated together in the Configuration Update Complete message.
　　　　　　Configuration update complete message identity.
User equipment (UE)
　　Fig. 32 is a block diagram illustrating the main components of the UE 3 (mobile device 3). As shown, the UE 3 includes a transceiver circuit 31 which is operable to transmit signals to and to receive signals from the connected node(s) via one or more antennas 32. Further, the UE 3 may include a user interface 34 for inputting information from outside or outputting information to outside. Although not necessarily shown in the Figure, the UE 3 may have all the usual functionality of a conventional mobile device and this may be provided by any one or any combination of hardware, software and firmware, as appropriate. Software may be pre-installed in the memory and/or may be downloaded via the telecommunication network or from a removable data storage device (RMD), for example. A controller 33 controls the operation of the UE 3 in accordance with software stored in a memory 36. The software includes, among other things, an operating system 361 and a communications control module 362 having at least a transceiver control module 3621. The communications control module 362 (using its transceiver control module 3621) is responsible for handling (generating/sending/receiving) signalling and uplink/downlink data packets between the UE 3 and other nodes, such as the (R)AN node 5 and the AMF 70. Such signalling may include, for example, appropriately formatted signalling messages (e.g. a registration request message and associated response messages) relating to access and mobility management procedures (for the UE 3). The controller 33 interworks with one or more Universal Subscriber Identity Module (USIM) 35. If there are multiple USIMs 35 equipped, the controller 33 may activate only one USIM 35 or may activate multiple USIMs 35 at the same time.
　　The UE 3 may, for example, support the Non-Public Network (NPN). The NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
　　The UE 3 may, for example, be an item of equipment for production or manufacture and/or an item of energy related machinery (for example equipment or machinery such as: boilers; engines; turbines; solar panels; wind turbines; hydroelectric generators; thermal power generators; nuclear electricity generators; batteries; nuclear systems and/or associated equipment; heavy electrical machinery; pumps including vacuum pumps; compressors; fans; blowers; oil hydraulic equipment; pneumatic equipment; metal working machinery; manipulators; robots and/or their application systems; tools; molds or dies; rolls; conveying equipment; elevating equipment; materials handling equipment; textile machinery; sewing machines; printing and/or related machinery; paper converting machinery; chemical machinery; mining and/or construction machinery and/or related equipment; machinery and/or implements for agriculture, forestry and/or fisheries; safety and/or environment preservation equipment; tractors; precision bearings; chains; gears; power transmission equipment; lubricating equipment; valves; pipe fittings; and/or application systems for any of the previously mentioned equipment or machinery etc.).
　　The UE 3 may, for example, be an item of transport equipment (for example transport equipment such as: rolling stocks; motor vehicles; motor cycles; bicycles; trains; buses; carts; rickshaws; ships and other watercraft; aircraft; rockets; satellites; drones; balloons etc.).
　　The UE 3 may, for example, be an item of information and communication equipment (for example information and communication equipment such as: electronic computer and related equipment; communication and related equipment; electronic components etc.).
　　The UE 3 may, for example, be a refrigerating machine, a refrigerating machine applied product, an item of trade and/or service industry equipment, a vending machine, an automatic service machine, an office machine or equipment, a consumer electronic and electronic appliance (for example a consumer electronic appliance such as: audio equipment; video equipment; a loud speaker; a radio; a television; a microwave oven; a rice cooker; a coffee machine; a dishwasher; a washing machine; a dryer; an electronic fan or related appliance; a cleaner etc.).
　　The UE 3 may, for example, be an electrical application system or equipment (for example an electrical application system or equipment such as: an x-ray system; a particle accelerator; radio isotope equipment; sonic equipment; electromagnetic application equipment; electronic power application equipment etc.).
　　The UE 3 may, for example, be an electronic lamp, a luminaire, a measuring instrument, an analyzer, a tester, or a surveying or sensing instrument (for example a surveying or sensing instrument such as: a smoke alarm; a human alarm sensor; a motion sensor; a wireless tag etc.), a watch or clock, a laboratory instrument, optical apparatus, medical equipment and/or system, a weapon, an item of cutlery, a hand tool, or the like.
　　The UE 3 may, for example, be a wireless-equipped personal digital assistant or related equipment (such as a wireless card or module designed for attachment to or for insertion into another electronic device (for example a personal computer, electrical measuring machine)).
　　The UE 3 may be a device or a part of a system that provides applications, services, and solutions described below, as to "internet of things (IoT)", using a variety of wired and/or wireless communication technologies.
　　Internet of Things devices (or "things") may be equipped with appropriate electronics, software, sensors, network connectivity, and/or the like, which enable these devices to collect and exchange data with each other and with other communication devices. IoT devices may comprise automated equipment that follow software instructions stored in an internal memory. IoT devices may operate without requiring human supervision or interaction. IoT devices might also remain stationary and/or inactive for a long period of time. IoT devices may be implemented as a part of a (generally) stationary apparatus. IoT devices may also be embedded in non-stationary apparatus (e.g. vehicles) or attached to animals or persons to be monitored/tracked.
　　It will be appreciated that IoT technology can be implemented on any communication devices that can connect to a communications network for sending/receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.
　　It will be appreciated that IoT devices are sometimes also referred to as Machine-Type Communication (MTC) devices or Machine-to-Machine (M2M) communication devices or Narrow Band-IoT UE (NB-IoT UE). It will be appreciated that a UE 3 may support one or more IoT or MTC applications.
　　The UE 3 may be a smart phone or a wearable device (e.g. smart glasses, a smart watch, a smart ring, or a hearable device). For a wearable device, the UE 3 may be a reduced capability device (RedCap).
　　The UE 3 may be a car, or a connected car, or an autonomous car, or a vehicle device, or a motorcycle or V2X (Vehicle to Everything) communication module (e.g. Vehicle to Vehicle communication module, Vehicle to Infrastructure communication module, Vehicle to People communication module and Vehicle to Network communication module).
　　The UE 301, the UE-to-Network Relay UE 303, or the IoT Device 302 may have same components to the UE 3.
(R)AN node
　　Fig. 33 is a block diagram illustrating the main components of an exemplary (R)AN node 5, for example a base station ('eNB' in LTE, 'gNB' in 5G, a base station for 5G beyond, a base station for 6G). As shown, the (R)AN node 5 includes a transceiver circuit 51 which is operable to transmit signals to and to receive signals from connected UE(s) 3 via one or more antennas 52 and to transmit signals to and to receive signals from other network nodes (either directly or indirectly) via a network interface 53. A controller 54 controls the operation of the (R)AN node 5 in accordance with software stored in a memory 55. Software may be pre-installed in the memory and/or may be downloaded via the telecommunication network or from a removable data storage device (RMD), for example. The software includes, among other things, an operating system 551 and a communications control module 552 having at least a transceiver control module 5521.
　　The communications control module 552 (using its transceiver control sub-module) is responsible for handling (generating/sending/receiving) signalling between the (R)AN node 5 and other nodes, such as the UE 3, another (R)AN node 5, the AMF 70 and the UPF 72 (e.g. directly or indirectly). The signalling may include, for example, appropriately formatted signalling messages relating to a radio connection and a connection with the core network 7 (for a particular UE 3), and in particular, relating to connection establishment and maintenance (e.g. RRC connection establishment and other RRC messages), NG Application Protocol (NGAP) messages (i.e. messages by N2 reference point) and Xn application protocol (XnAP) messages (i.e. messages by Xn reference point), etc. Such signalling may also include, for example, broadcast information (e.g. Master Information and System information) in a sending case.
　　The controller 54 is also configured (by software or hardware) to handle related tasks such as, when implemented, UE mobility estimation and/or moving trajectory estimation.
　　The (R)AN node 5 may support the Non-Public Network (NPN). The NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
　　The RAN 501, the Radio Cell 502, the IAB Node 502, or the IAB donor 501 may have same components to the (R)AN node 5. The (R)AN node 5 may be expressed as a RAN node, RAN, (R)AN, Radio Cell etc.
System overview of (R)AN node 5 based on O-RAN architecture
　　Fig. 34 schematically illustrates a (R)AN node 5 based on O-RAN architecture to which the (R)AN node 5 aspects are applicable.
　　The (R)AN node 5 based on O-RAN architecture represents a system overview in which the (R)AN node is split into a Radio Unit (RU) 60, Distributed Unit (DU) 61 and Centralized Unit (CU) 62. In some aspects, each unit may be combined. For example, the RU 60 can be integrated/combined with the DU 61 as an integrated/combined unit, the DU 61 can be integrated/combined with the CU 62 as another integrated/combined unit. Any functionality in the description for a unit (e.g. one of RU 60, DU 61 and CU 62) can be implemented in the integrated/combined unit above. Further, CU 62 can separate into two functional units such as CU Control plane (CP) and CU User plane (UP). The CU CP has a control plane functionality in the (R)AN node 5. The CU UP has a user plane functionality in the (R)AN node 5. Each CU CP is connected to the CU UP via an appropriate interface (such as the so-called "E1" interface and/or the like).
　　The UE 3 and a respective serving RU 60 are connected via an appropriate air interface (for example the so-called "Uu" interface and/or the like). Each RU 60 is connected to the DU 61 via an appropriate interface (such as the so-called "Front haul", "Open Front haul", "F1" interface and/or the like). Each DU 61 is connected to the CU 62 via an appropriate interface (such as the so-called "Mid haul", "Open Mid haul", "E2" interface and/or the like). Each CU 62 is also connected to nodes in the core network 7 (such as the so-called core network nodes) via an appropriate interface (such as the so-called "Back haul", "Open Back haul", "N2"/ "N3" interface(s) and/or the like). In addition, a user plane part of the DU 61 can also be connected to the core network nodes via an appropriate interface (such as the so-called "N3" interface(s) and/or the like).
　　Depending on functionality split among the RU 60, DU 61 and CU 62, each unit provides some of the functionality that is provided by the (R)AN node 5. For example, the RU 60 may provide a functionalities to communicate with a UE 3 over air interface, the DU 61 may provide functionalities to support MAC layer and RLC layer, the CU 62 may provide functionalities to support PDCP layer, SDAP layer and RRC layer.
Radio Unit (RU)
　　Fig. 35 is a block diagram illustrating the main components of an exemplary RU 60, for example a RU part of base station ('eNB' in LTE, 'gNB' in 5G, a base station for 5G beyond, a base station for 6G). As shown, the RU 60 includes a transceiver circuit 601 which is operable to transmit signals to and to receive signals from connected UE(s) 3 via one or more antennas 602 and to transmit signals to and to receive signals from other network nodes or network unit (either directly or indirectly) via a network interface 603. A controller 604 controls the operation of the RU 60 in accordance with software stored in a memory 605. Software may be pre-installed in the memory and/or may be downloaded via the telecommunication network or from a removable data storage device (RMD), for example. The software includes, among other things, an operating system 6051 and a communications control module 6052 having at least a transceiver control module 60521.
　　The communications control module 6052 (using its transceiver control sub-module) is responsible for handling (generating/sending/receiving) signalling between the RU 60 and other nodes or units, such as the UE 3, another RU 60 and DU 61 (e.g. directly or indirectly). The signalling may include, for example, appropriately formatted signalling messages relating to a radio connection and a connection with the RU 60 (for a particular UE 3), and in particular, relating to MAC layer and RLC layer.
　　The controller 604 is also configured (by software or hardware) to handle related tasks such as, when implemented, UE mobility estimation and/or moving trajectory estimation.
　　The RU 60 may support the Non-Public Network (NPN). The NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
　　As described above, the RU 60 can be integrated/combined with the DU 61 as an integrated/combined unit. Any functionality in the description for the RU 60 can be implemented in the integrated/combined unit above.
Distributed Unit (DU)
　　Fig. 36 is a block diagram illustrating the main components of an exemplary DU 61, for example a DU part of a base station ('eNB' in LTE, 'gNB' in 5G, a base station for 5G beyond, a base station for 6G). As shown, the apparatus includes a transceiver circuit 611 which is operable to transmit signals to and to receive signals from other nodes or units (including the RU 60) via a network interface 612. A controller 613 controls the operation of the DU 61 in accordance with software stored in a memory 614. Software may be pre-installed in the memory 614 and/or may be downloaded via the telecommunication network or from a removable data storage device (RMD), for example. The software includes, among other things, an operating system 6141 and a communications control module 6142 having at least a transceiver control module 61421. The communications control module 6142 (using its transceiver control module 61421) is responsible for handling (generating/sending/receiving) signalling between the DU 61 and other nodes or units, such as the RU 60 and other nodes and units.
　　The DU 61 may support the Non-Public Network (NPN). The NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
　　As described above, the RU 60 can be integrated/combined with the DU 61 or CU 62 as an integrated/combined unit. Any functionality in the description for DU 61 can be implemented in one of the integrated/combined unit above.
Centralized Unit (CU)
　　Fig. 37 is a block diagram illustrating the main components of an exemplary CU 62, for example a CU part of base station ('eNB' in LTE, 'gNB' in 5G, a base station for 5G beyond, a base station for 6G). As shown, the apparatus includes a transceiver circuit 621 which is operable to transmit signals to and to receive signals from other nodes or units (including the DU 61) via a network interface 622. A controller 623 controls the operation of the CU 62 in accordance with software stored in a memory 624. Software may be pre-installed in the memory 624 and/or may be downloaded via the telecommunication network or from a removable data storage device (RMD), for example. The software includes, among other things, an operating system 6241 and a communications control module 6242 having at least a transceiver control module 62421. The communications control module 6242 (using its transceiver control module 62421) is responsible for handling (generating/sending/receiving) signalling between the CU 62 and other nodes or units, such as the DU 61 and other nodes and units.
　　The CU 62 may support the Non-Public Network (NPN). The NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
　　As described above, the CU 62 can be integrated/combined with the DU 61 as an integrated/combined unit. Any functionality in the description for the CU 62 can be implemented in the integrated/combined unit above.
AMF
　　Fig. 38 is a block diagram illustrating the main components of the AMF 70. As shown, the apparatus includes a transceiver circuit 701 which is operable to transmit signals to and to receive signals from other nodes (including the UE 3) via a network interface 702. A controller 703 controls the operation of the AMF 70 in accordance with software stored in a memory 704. Software may be pre-installed in the memory 704 and/or may be downloaded via the telecommunication network or from a removable data storage device (RMD), for example. The software includes, among other things, an operating system 7041 and a communications control module 7042 having at least a transceiver control module 70421. The communications control module 7042 (using its transceiver control module 70421) is responsible for handling (generating/sending/receiving) signalling between the AMF 70 and other nodes, such as the UE 3 (e.g. via the (R)AN node 5) and other core network nodes (including core network nodes in the HPLMN of the UE 3 when the UE 3 is roaming-in). Such signalling may include, for example, appropriately formatted signalling messages (e.g. a registration request message and associated response messages) relating to access and mobility management procedures (for the UE 3).
　　The AMF 70 may support the Non-Public Network (NPN). The NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
SMF
　　Fig. 39 is a block diagram illustrating the main components of the SMF 71. As shown, the apparatus includes a transceiver circuit 711 which is operable to transmit signals to and to receive signals from other nodes (including the AMF 70) via a network interface 712. A controller 713 controls the operation of the SMF 71 in accordance with software stored in a memory 714. Software may be pre-installed in the memory 714 and/or may be downloaded via the telecommunication network or from a removable data storage device (e.g. a removable memory device (RMD)), for example. The software includes, among other things, an operating system 7141 and a communications control module 7142 having at least a transceiver control module 71421. The communications control module 7142 (using its transceiver control module 71421) is responsible for handling (generating/sending/receiving) signalling between the SMF 71 and other nodes, such as the AMF 70 and other core network nodes (including core network nodes in the HPLMN of the UE 3 when the UE 3 is roaming-in). Such signalling may include, for example, appropriately formatted signalling messages (e.g. HTTP restful methods based on the service based interfaces) relating to policy management procedures (for the UE 3).
　　The SMF 71 may support the Non-Public Network (NPN). The NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
UPF
　　Fig. 40 is a block diagram illustrating the main components of the UPF 72. As shown, the apparatus includes a transceiver circuit 721 which is operable to transmit signals to and to receive signals from other nodes (including the SMF 71) via a network interface 722. A controller 723 controls the operation of the UPF 72 in accordance with software stored in a memory 724. Software may be pre-installed in the memory 724 and/or may be downloaded via the telecommunication network or from a removable data storage device (e.g. a removable memory device (RMD)), for example. The software includes, among other things, an operating system 7241 and a communications control module 7242 having at least a transceiver control module 72421. The communications control module 7242 (using its transceiver control module 72421) is responsible for handling (generating/sending/receiving) signalling between the UPF 72 and other nodes, such as the SMF 71 and other core network nodes (including core network nodes in the HPLMN of the UE 3 when the UE 3 is roaming-in). Such signalling may include, for example, appropriately formatted signalling messages (e.g. HTTP restful methods based on the service based interfaces) relating to policy management procedures (for the UE 3).
　　The UPF 72 may support the Non-Public Network (NPN). The NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
PCF
　　Fig. 41 is a block diagram illustrating the main components of the PCF 73. As shown, the apparatus includes a transceiver circuit 731 which is operable to transmit signals to and to receive signals from other nodes (including the AMF 70) via a network interface 732. A controller 733 controls the operation of the PCF 73 in accordance with software stored in a memory 734. Software may be pre-installed in the memory 734 and/or may be downloaded via the telecommunication network or from a removable data storage device (e.g. a removable memory device (RMD)), for example. The software includes, among other things, an operating system 7341 and a communications control module 7342 having at least a transceiver control module 73421. The communications control module 7342 (using its transceiver control module 73421) is responsible for handling (generating/sending/receiving) signalling between the PCF 73 and other nodes, such as the AMF 70 and other core network nodes (including core network nodes in the HPLMN of the UE 3 when the UE 3 is roaming-in). Such signalling may include, for example, appropriately formatted signalling messages (e.g. HTTP restful methods based on the service based interfaces) relating to policy management procedures (for the UE 3).
　　The PCF 73 may support the Non-Public Network (NPN). The NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
NWDAF
　　Fig. 42 is a block diagram illustrating the main components of the NWDAF 74. As shown, the apparatus includes a transceiver circuit 741 which is operable to transmit signals to and to receive signals from other nodes (including the AMF 70 and the UDM 75) via a network interface 742. A controller 743 controls the operation of the NWDAF 74 in accordance with software stored in a memory 744. Software may be pre-installed in the memory 744 and/or may be downloaded via the telecommunication network or from a removable data storage device (e.g. a removable memory device (RMD)), for example. The software includes, among other things, an operating system 7441 and a communications control module 7442 having at least a transceiver control module 74421. The communications control module 7442 (using its transceiver control module 74421) is responsible for handling (generating/sending/receiving) signalling between the NWDAF 74 and other nodes, such as the AMF 70 and other core network nodes (including core network nodes in the HPLMN of the UE 3 when the UE 3 is roaming-in). Such signalling may include, for example, appropriately formatted signalling messages (e.g. HTTP restful methods based on the service based interfaces) relating to policy management procedures (for the UE 3).
　　The NWDAF 74 may support the Non-Public Network (NPN). The NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
UDM
　　Fig. 43 is a block diagram illustrating the main components of the UDM 75. As shown, the apparatus includes a transceiver circuit 751 which is operable to transmit signals to and to receive signals from other nodes (including the AMF 70) via a network interface 752. A controller 753 controls the operation of the UDM 75 in accordance with software stored in a memory 754. Software may be pre-installed in the memory 754 and/or may be downloaded via the telecommunication network or from a removable data storage device (RMD), for example. The software includes, among other things, an operating system 7541 and a communications control module 7542 having at least a transceiver control module 75421. The communications control module 7542 (using its transceiver control module 75421) is responsible for handling (generating/sending/receiving) signalling between the UDM 75 and other nodes, such as the AMF 70 and other core network nodes (including core network nodes in the VPLMN of the UE 3 when the UE 3 is roaming-out). Such signalling may include, for example, appropriately formatted signalling messages (e.g. HTTP restful methods based on the service based interfaces) relating to mobility management procedures (for the UE 3).
　　The UDM 75 may support the Non-Public Network (NPN). The NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
NSSF
　　Fig. 44 is a block diagram illustrating the main components of the NSSF 76. As shown, the apparatus includes a transceiver circuit 761 which is operable to transmit signals to and to receive signals from other nodes (including the AMF 70) via a network interface 762. A controller 763 controls the operation of the NSSF 76 in accordance with software stored in a memory 764. Software may be pre-installed in the memory 764 and/or may be downloaded via the telecommunication network or from a removable data storage device (RMD), for example. The software includes, among other things, an operating system 7641 and a communications control module 7642 having at least a transceiver control module 76421. The communications control module 7642 (using its transceiver control module 76421) is responsible for handling (generating/sending/receiving) signalling between the NSSF 76 and other nodes, such as the AMF 70 and other core network nodes (including core network nodes in the VPLMN of the UE 3 when the UE 3 is roaming-out). Such signalling may include, for example, appropriately formatted signalling messages (e.g. HTTP restful methods based on the service based interfaces) relating to mobility management procedures (for the UE 3).
　　The NSSF 76 may support the Non-Public Network (NPN). The NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
NSACF
　　Fig. 45 is a block diagram illustrating the main components of the NSACF 77. As shown, the apparatus includes a transceiver circuit 771 which is operable to transmit signals to and to receive signals from other nodes (including the AMF 70) via a network interface 772. A controller 773 controls the operation of the NSACF 77 in accordance with the software stored in a memory 774. The Software may be pre-installed in the memory 774 and/or may be downloaded via the telecommunication network or from a removable data storage device (e.g. a removable memory device (RMD)), for example. The software includes, among other things, an operating system 7741 and a communications control module 7742 having at least a transceiver control module 77421. The communications control module 7742 (using its transceiver control module 77421) is responsible for handling (generating/sending/receiving) signalling between the NSACF 77 and other nodes, such as the AMF 70 and other core network nodes (including core network nodes in the HPLMN of the UE 3 when the UE 3 is roaming-in). Such signalling may include, for example, appropriately formatted signalling messages (e.g. HTTP restful methods based on the service based interfaces) relating to network data analytics function procedures (for the UE 3).
　　The NSACF 77 may support the Non-Public Network (NPN). The NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
AUSF
　　Fig. 46 is a block diagram illustrating the main components of the AUSF 78. As shown, the apparatus includes a transceiver circuit 781 which is operable to transmit signals to and to receive signals from other nodes (including the AMF 70) via a network interface 782. A controller 783 controls the operation of the AUSF 78 in accordance with the software stored in a memory 784. The Software may be pre-installed in the memory 784 and/or may be downloaded via the telecommunication network or from a removable data storage device (e.g. a removable memory device (RMD)), for example. The software includes, among other things, an operating system 7841 and a communications control module 7842 having at least a transceiver control module 78421. The communications control module 7842 (using its transceiver control module 78421) is responsible for handling (generating/sending/receiving) signalling between the AUSF 78 and other nodes, such as the AMF 70 and other core network nodes (including core network nodes in the HPLMN of the UE 3 when the UE 3 is roaming-in). Such signalling may include, for example, appropriately formatted signalling messages (e.g. HTTP restful methods based on the service based interfaces) relating to network data analytics function procedures (for the UE 3).
　　The AUSF 78 may support the Non-Public Network (NPN). The NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
NEF
　　Fig. 47 is a block diagram illustrating the main components of the NEF 79. As shown, the apparatus includes a transceiver circuit 791 which is operable to transmit signals to and to receive signals from other nodes (including the UDM 75, the AF 201) via a network interface 792. A controller 793 controls the operation of the NEF 79 in accordance with the software stored in a memory 794. The Software may be pre-installed in the memory 794 and/or may be downloaded via the telecommunication network or from a removable data storage device (e.g. a removable memory device (RMD)), for example. The software includes, among other things, an operating system 7941 and a communications control module 7942 having at least a transceiver control module 79421. The communications control module 7942 (using its transceiver control module 79421) is responsible for handling (generating/sending/receiving) signalling between the NEF 79 and other nodes, such as the AMF 70 and other core network nodes (including core network nodes in the HPLMN of the UE 3 when the UE 3 is roaming-in). Such signalling may include, for example, appropriately formatted signalling messages (e.g. HTTP restful methods based on the service based interfaces) relating to network data analytics function procedures (for the UE 3).
　　The NEF 79 may support the Non-Public Network (NPN). The NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
AF
　　Fig. 48 is a block diagram illustrating the main components of the AF 201. As shown, the apparatus includes a transceiver circuit 2011 which is operable to transmit signals to and to receive signals from other nodes (including the UE 3, the NEF 79) via a network interface 2012. A controller 2013 controls the operation of the AF 201 in accordance with software stored in a memory 2014. Software may be pre-installed in the memory 2014 and/or may be downloaded via the telecommunication network or from a removable data storage device (e.g. a removable memory device (RMD)), for example. The software includes, among other things, an operating system 20141 and a communications control module 20142 having at least a transceiver control module 201421. The communications control module 20142 (using its transceiver control module 201421) is responsible for handling (generating/sending/receiving) signalling between the AF 201 and other nodes, such as the UE 3 and other core network nodes (including core network nodes in the HPLMN of the UE 3 when the UE 3 is roaming-in). Such signalling may include, for example, appropriately formatted signalling messages (e.g. HTTP restful methods based on the service based interfaces) relating to policy management procedures (for the UE 3).
　　The AF 201 may support the Non-Public Network (NPN). The NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
<Modifications and Alternatives>
　　Detailed aspects have been described above. As those skilled in the art will appreciate, a number of modifications and alternatives can be made to the above aspects whilst still benefiting from the disclosures embodied therein. By way of illustration only a number of these alternatives and modifications will now be described.
　　In the above description, the UE 3 and the network apparatus are described for ease of understanding as having a number of discrete modules (such as the communication control modules). Whilst these modules may be provided in this way for certain applications, for example where an existing system has been modified to implement the disclosure, in other applications, for example in systems designed with the inventive features in mind from the outset, these modules may be built into the overall operating system or code and so these modules may not be discernible as discrete entities. These modules may also be implemented in software, hardware, firmware or a mix of these.
　　Each controller may comprise any suitable form of processing circuitry including (but not limited to), for example: one or more hardware implemented computer processors; microprocessors; central processing units (CPUs); arithmetic logic units (ALUs); input/output (IO) circuits; internal memories / caches (program and/or data); processing registers; communication buses (e.g. control, data and/or address buses); direct memory access (DMA) functions, hardware or software implemented counters, pointers and/or timers; and/or the like.
　　In the above aspects, a number of software modules were described. As those skilled in the art will appreciate, the software modules may be provided in compiled or un-compiled form and may be supplied to the UE 3 and the network apparatus as a signal over a computer network, or on a recording medium. Further, the functionality performed by part or all of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred as it facilitates the updating of the UE 3 and the network apparatus in order to update their functionalities.
　　In the above aspects, a 3GPP radio communications (radio access) technology is used. However, any other radio communications technology (e.g. WLAN, Wi-Fi, WiMAX, Bluetooth, etc.) and other fix line communications technology (e.g. BBF Access, Cable Access, optical access, etc.) may also be used in accordance with the above aspects.
　　Items of user equipment might include, for example, communication devices such as mobile telephones, smartphones, user equipment, personal digital assistants, laptop/tablet computers, web browsers, e-book readers and/or the like. Such mobile (or even generally stationary) devices are typically operated by a user, although it is also possible to connect so-called 'Internet of Things' (IoT) devices and similar machine-type communication (MTC) devices to the network. For simplicity, the present application refers to mobile devices (or UEs) in the description but it will be appreciated that the technology described can be implemented on any communication devices (mobile and/or generally stationary) that can connect to a communications network for sending/receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.
　　Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.
　　As will be appreciated by one of skill in the art, the present disclosure may be embodied as a method, and system. Accordingly, the present disclosure may take the form of an entirely hardware embodiment, a software embodiment or an embodiment combining software and hardware aspects.
　　It will be understood that each block of the block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general-purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a plurality of microprocessors, one or more microprocessors, or any other such configuration.
　　The methods or algorithms described in connection with the examples disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. A storage medium may be coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC.
　　The previous description of the disclosed examples is provided to enable any person skilled in the art to make or use the present disclosure. Various modifications to these examples will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other examples without departing from the spirit or scope of the disclosure. Thus, the present disclosure is not intended to be limited to the examples shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
　　While the disclosure has been particularly shown and described with reference to exemplary Aspects thereof, the disclosure is not limited to these Aspects. It will be understood by those of ordinary skill in the art that various changes in form and details may be made therein without departing from the spirit and scope of the present disclosure as defined by this document. For example, the Aspects above are not limited to 5GS, and the Aspects are also applicable to communication system other than 5GS (e.g., 6G system, 5G beyond system).
<Supplementary notes>
　　The whole or part of the example Aspects disclosed above can be described as, but not limited to, the following supplementary notes.
(supplementary note 1)
　　A method of a first communication apparatus comprising:
　　sending information related to Ambient Internet of Things (IoT) to a second communication apparatus.
(supplementary note 2)
　　The method according to supplementary note 1,
　　wherein the first communication apparatus is an Application Function (AF), and
　　wherein the second communication apparatus is a Network Exposure Function (NEF).
(supplementary note 3)
　　The method according to supplementary note 1,
　　wherein the first communication apparatus is an Application Function (AF), and
　　wherein the second communication apparatus is a UE-to-Network Relay UE for the Ambient IoT.
(supplementary note 4)
　　A method of a first communication apparatus comprising:
　　receiving information related to Ambient Internet of Things (IoT) from a second communication apparatus.
(supplementary note 5)
　　The method according to supplementary note 4,
　　wherein the first communication apparatus is a Unified Data Management (UDM), and
　　wherein the second communication apparatus is a Network Exposure Function (NEF).
(supplementary note 6)
　　The method according to supplementary note 4, further comprising:
　　sending the information to a third communication apparatus.
(supplementary note 7)
　　The method according to supplementary note 6,
　　wherein the first communication apparatus is a Network Exposure Function (NEF),
　　wherein the second communication apparatus is an Application Function (AF), and
　　wherein the third communication apparatus is a Unified Data Management (UDM).
(supplementary note 8)
　　The method according to supplementary note 4,
　　wherein the first communication apparatus is a UE-to-Network Relay UE for the Ambient IoT, and
　　wherein the second communication apparatus is an Application Function (AF).
(supplementary note 9)
　　A method of a communication apparatus comprising:
　　performing a Registration procedure for Ambient Internet of Things (IoT).
(supplementary note 10)
　　The method according to supplementary note 9,
　　wherein the communication apparatus is a User Equipment (UE) for Ambient Internet of Things (IoT).
(supplementary note 11)
　　The method according to supplementary note 10, further comprising:
　　sending data for the Ambient IoT during the Registration procedure.
(supplementary note 12)
　　The method according to supplementary note 9,
　　wherein the communication apparatus is an Access and Mobility Management Function (AMF).
(supplementary note 13)
　　The method according to supplementary note 9,
　　wherein the communication apparatus is a Unified Data Management (UDM).
(supplementary note 14)
　　The method according to supplementary note 9,
　　wherein the communication apparatus is a Network Exposure Function (NEF).
(supplementary note 15)
　　The method according to supplementary note 9,
　　wherein the communication apparatus is an Application Function (AF).
(supplementary note 16)
　　The method according to supplementary note 9,
　　wherein the communication apparatus is a Session Management Function (SMF).
(supplementary note 17)
　　The method according to supplementary note 9,
　　wherein the communication apparatus is a User Plane Function (UPF).
(supplementary note 18)
　　The method according to supplementary note 9,
　　wherein the communication apparatus is a Radio Access Network (RAN) node.
(supplementary note 19)
　　The method according to supplementary note 9,
　　wherein the communication apparatus is an Integrated access and backhaul (IAB) donor.
(supplementary note 20)
　　A method of a first communication apparatus comprising:
　　sending information for activating Ambient Internet of Things (IoT) to a second communication apparatus.
(supplementary note 21)
　　The method according to supplementary note 20,
　　wherein the first communication apparatus is an Application Function (AF), and
　　wherein the second communication apparatus is a Network Exposure Function (NEF).
(supplementary note 22)
　　The method according to supplementary note 20,
　　wherein the first communication apparatus is a User Equipment (UE) for Ambient Internet of Things (IoT), and
　　wherein the second communication apparatus is a Radio Access Network (RAN) node.
(supplementary note 23)
　　The method according to supplementary note 20,
　　wherein the first communication apparatus is an Application Function (AF), and
　　wherein the second communication apparatus is a UE-to-Network Relay UE for the Ambient IoT.
(supplementary note 24)
　　A method of a first communication apparatus comprising:
　　receiving first information for activating Ambient Internet of Things (IoT) from a second communication apparatus.
(supplementary note 25)
　　The method according to supplementary note 24, further comprising:
　　sending second information for activating the Ambient IoT to a third communication apparatus,
　　wherein the first communication apparatus is a Network Exposure Function (NEF),
　　wherein the second communication apparatus is an Application Function (AF), and
　　wherein the third communication apparatus is a Unified Data Management (UDM).
(supplementary note 26)
　　The method according to supplementary note 25, further comprising:
　　receiving third information for activating the Ambient IoT from the third communication apparatus, and
　　sending fourth information for activating the Ambient IoT to a fourth communication apparatus,
　　wherein the fourth communication apparatus is an Access and Mobility Management Function (AMF).
(supplementary note 27)
　　The method according to supplementary note 24, further comprising:
　　sending second information for activating the Ambient IoT to a third communication apparatus,
　　wherein the first communication apparatus is an Access and Mobility Management Function (AMF),
　　wherein the second communication apparatus is a Network Exposure Function (NEF), and
　　wherein the third communication apparatus is a Radio Access Network (RAN) node.
(supplementary note 28)
　　The method according to supplementary note 24, further comprising:
　　sending second information for activating the Ambient IoT to a third communication apparatus,
　　wherein the first communication apparatus is a Radio Access Network (RAN) node,
　　wherein the second communication apparatus is an Access and Mobility Management Function (AMF), and
　　wherein the third communication apparatus is a Radio Cell.
(supplementary note 29)
　　The method according to supplementary note 24,
　　wherein the first communication apparatus is a UE-to-Network Relay UE for the Ambient IoT, and
　　wherein the second communication apparatus is an Application Function (AF).
(supplementary note 30)
　　The method according to supplementary note 24,
　　wherein the first communication apparatus is a User Equipment (UE) for the Ambient IoT, and
　　wherein the second communication apparatus is an Application Function (AF).
(supplementary note 31)
　　A first communication apparatus comprising:
　　means for sending information related to Ambient Internet of Things (IoT) to a second communication apparatus.
(supplementary note 32)
　　The first communication apparatus according to supplementary note 31,
　　wherein the first communication apparatus is an Application Function (AF), and
　　wherein the second communication apparatus is a Network Exposure Function (NEF).
(supplementary note 33)
　　The first communication apparatus according to supplementary note 31,
　　wherein the first communication apparatus is an Application Function (AF), and
　　wherein the second communication apparatus is a UE-to-Network Relay UE for the Ambient IoT.
(supplementary note 34)
　　A first communication apparatus comprising:
　　means for receiving information related to Ambient Internet of Things (IoT) from a second communication apparatus.
(supplementary note 35)
　　The first communication apparatus according to supplementary note 34,
　　wherein the first communication apparatus is a Unified Data Management (UDM), and
　　wherein the second communication apparatus is a Network Exposure Function (NEF).
(supplementary note 36)
　　The first communication apparatus according to supplementary note 34, further comprising:
　　means for sending the information to a third communication apparatus.
(supplementary note 37)
　　The first communication apparatus according to supplementary note 36,
　　wherein the first communication apparatus is a Network Exposure Function (NEF),
　　wherein the second communication apparatus is an Application Function (AF), and
　　wherein the third communication apparatus is a Unified Data Management (UDM).
(supplementary note 38)
　　The first communication apparatus according to supplementary note 34,
　　wherein the first communication apparatus is a UE-to-Network Relay UE for the Ambient IoT, and
　　wherein the second communication apparatus is an Application Function (AF).
(supplementary note 39)
　　A communication apparatus comprising:
　　means for performing a Registration procedure for Ambient Internet of Things (IoT).
(supplementary note 40)
　　The communication apparatus according to supplementary note 39,
　　wherein the communication apparatus is a User Equipment (UE) for Ambient Internet of Things (IoT).
(supplementary note 41)
　　The communication apparatus according to supplementary note 40, further comprising:
　　means for sending data for the Ambient IoT during the Registration procedure.
(supplementary note 42)
　　The communication apparatus according to supplementary note 39,
　　wherein the communication apparatus is an Access and Mobility Management Function (AMF).
(supplementary note 43)
　　The communication apparatus according to supplementary note 39,
　　wherein the communication apparatus is a Unified Data Management (UDM).
(supplementary note 44)
　　The communication apparatus according to supplementary note 39,
　　wherein the communication apparatus is a Network Exposure Function (NEF).
(supplementary note 45)
　　The communication apparatus according to supplementary note 39,
　　wherein the communication apparatus is an Application Function (AF).
(supplementary note 46)
　　The communication apparatus according to supplementary note 39,
　　wherein the communication apparatus is a Session Management Function (SMF).
(supplementary note 47)
　　The communication apparatus according to supplementary note 39,
　　wherein the communication apparatus is a User Plane Function (UPF).
(supplementary note 48)
　　The communication apparatus according to supplementary note 39,
　　wherein the communication apparatus is a Radio Access Network (RAN) node.
(supplementary note 49)
　　The communication apparatus according to supplementary note 39,
　　wherein the communication apparatus is an Integrated access and backhaul (IAB) donor.
(supplementary note 50)
　　A first communication apparatus comprising:
　　means for sending information for activating Ambient Internet of Things (IoT) to a second communication apparatus.
(supplementary note 51)
　　The first communication apparatus according to supplementary note 50,
　　wherein the first communication apparatus is an Application Function (AF), and
　　wherein the second communication apparatus is a Network Exposure Function (NEF).
(supplementary note 52)
　　The first communication apparatus according to supplementary note 50,
　　wherein the first communication apparatus is a User Equipment (UE) for Ambient Internet of Things (IoT), and
　　wherein the second communication apparatus is a Radio Access Network (RAN) node.
(supplementary note 53)
　　The first communication apparatus according to supplementary note 50,
　　wherein the first communication apparatus is an Application Function (AF), and
　　wherein the second communication apparatus is a UE-to-Network Relay UE for the Ambient IoT.
(supplementary note 54)
　　A first communication apparatus comprising:
　　means for receiving first information for activating Ambient Internet of Things (IoT) from a second communication apparatus.
(supplementary note 55)
　　The first communication apparatus according to supplementary note 54, further comprising:
　　means for sending second information for activating the Ambient IoT to a third communication apparatus,
　　wherein the first communication apparatus is a Network Exposure Function (NEF),
　　wherein the second communication apparatus is an Application Function (AF), and
　　wherein the third communication apparatus is a Unified Data Management (UDM).
(supplementary note 56)
　　The first communication apparatus according to supplementary note 55, further comprising:
　　means for receiving third information for activating the Ambient IoT from the third communication apparatus, and
　　means for sending fourth information for activating the Ambient IoT to a fourth communication apparatus,
　　wherein the fourth communication apparatus is an Access and Mobility Management Function (AMF).
(supplementary note 57)
　　The first communication apparatus according to supplementary note 54, further comprising:
　　means for sending second information for activating the Ambient IoT to a third communication apparatus,
　　wherein the first communication apparatus is an Access and Mobility Management Function (AMF),
　　wherein the second communication apparatus is a Network Exposure Function (NEF), and
　　wherein the third communication apparatus is a Radio Access Network (RAN) node.

(supplementary note 58)
　　The first communication apparatus according to supplementary note 54, further comprising:
　　means for sending second information for activating the Ambient IoT to a third communication apparatus,
　　wherein the first communication apparatus is a Radio Access Network (RAN) node,
　　wherein the second communication apparatus is an Access and Mobility Management Function (AMF), and
　　wherein the third communication apparatus is a Radio Cell.
(supplementary note 59)
　　The first communication apparatus according to supplementary note 54,
　　wherein the first communication apparatus is a UE-to-Network Relay UE for the Ambient IoT, and
　　wherein the second communication apparatus is an Application Function (AF).
(supplementary note 60)
　　The first communication apparatus according to supplementary note 54,
　　wherein the first communication apparatus is a User Equipment (UE) for the Ambient IoT, and
　　wherein the second communication apparatus is an Application Function (AF).
　　This application is based upon and claims the benefit of priority from Indian provisional patent application No. 202311053372, filed on August 9, 2023, the disclosure of which is incorporated herein in its entirety by reference.
1 TELECOMMUNICATION SYSTEM
20 DATA NETWORK
201, 20101, 20102 APPLICATION FUNCTION (AF)
2011 TRANSCEIVER CIRCUIT
2012 NETWORK INTERFACE
2013 CONTROLLER
2014 MEMORY
20141 OPERATING SYSTEM
20142 COMMUNICATIONS CONTROL MODULE
201421 TRANSCEIVER CONTROL MODULE
3, 301, 30101, 30102 UE
302 IoT DEVICE
303, 30301, 30302 UE-to-NETWORK RELAY UE
31 TRANSCEIVER CIRCUIT
32 ANTENNAS
33 CONTROLLER
34 USER INTERFACE
35 USIM
36 MEMORY
361 OPERATING SYSTEM
362 COMMUNICATIONS CONTROL MODULE
3621 TRANSCEIVER CONTROL MODULE
5 (R)AN NODE
51 TRANSCEIVER CIRCUIT
52 ANTENNAS
53 NETWORK INTERFACE
54 CONTROLLER
55 MEMORY
551 OPERATING SYSTEM
552 COMMUNICATIONS CONTROL MODULE
5521 TRANSCEIVER CONTROL MODULE
501 RAN
502, 50201, 50202 RADIO CELL
501 IAB DONOR
502, 50201 IAB NODE
60 RU
601 TRANSCEIVER CIRCUIT
602 ANTENNAS
603 NETWORK INTERFACE
604 CONTROLLER
605 MEMORY
6051 OPERATING SYSTEM
6052 COMMUNICATIONS CONTROL MODULE
60521 TRANSCEIVER CONTROL MODULE
61 DU
611 TRANSCEIVER CIRCUIT
612 NETWORK INTERFACE
613 CONTROLLER
614 MEMORY
6141 OPERATING SYSTEM
6142 COMMUNICATIONS CONTROL MODULE
61421 TRANSCEIVER CONTROL MODULE
62 CU
621 TRANSCEIVER CIRCUIT
622 NETWORK INTERFACE
623 CONTROLLER
624 MEMORY
6241 OPERATING SYSTEM
6242 COMMUNICATIONS CONTROL MODULE
62421 TRANSCEIVER CONTROL MODULE
7 CORE NETWORK
70 AMF
701 TRANSCEIVER CIRCUIT
702 NETWORK INTERFACE
703 CONTROLLER
704 MEMORY
7041 OPERATING SYSTEM
7042 COMMUNICATIONS CONTROL MODULE
70421 TRANSCEIVER CONTROL MODULE
71 SMF
711 TRANSCEIVER CIRCUIT
712 NETWORK INTERFACE
713 CONTROLLER
714 MEMORY
7141 OPERATING SYSTEM
7142 COMMUNICATIONS CONTROL MODULE
71421 TRANSCEIVER CONTROL MODULE
72 UPF
721 TRANSCEIVER CIRCUIT
722 NETWORK INTERFACE
723 CONTROLLER
724 MEMORY
7241 OPERATING SYSTEM
7242 COMMUNICATIONS CONTROL MODULE
72421 TRANSCEIVER CONTROL MODULE
73 PCF
731 TRANSCEIVER CIRCUIT
732 NETWORK INTERFACE
733 CONTROLLER
734 MEMORY
7341 OPERATING SYSTEM
7342 COMMUNICATIONS CONTROL MODULE
73421 TRANSCEIVER CONTROL MODULE
74 NWDAF
741 TRANSCEIVER CIRCUIT
742 NETWORK INTERFACE
743 CONTROLLER
744 MEMORY
7441 OPERATING SYSTEM
7442 COMMUNICATIONS CONTROL MODULE
74421 TRANSCEIVER CONTROL MODULE
75 UDM
751 TRANSCEIVER CIRCUIT
752 NETWORK INTERFACE
753 CONTROLLER
754 MEMORY
7541 OPERATING SYSTEM
7542 COMMUNICATIONS CONTROL MODULE
75421 TRANSCEIVER CONTROL MODULE
76 NSSF
761 TRANSCEIVER CIRCUIT
762 NETWORK INTERFACE
763 CONTROLLER
764 MEMORY
7641 OPERATING SYSTEM
7642 COMMUNICATIONS CONTROL MODULE
76421 TRANSCEIVER CONTROL MODULE
77 NSACF
771 TRANSCEIVER CIRCUIT
772 NETWORK INTERFACE
773 CONTROLLER
774 MEMORY
7741 OPERATING SYSTEM
7742 COMMUNICATIONS CONTROL MODULE
77421 TRANSCEIVER CONTROL MODULE
78 AUSF
781 TRANSCEIVER CIRCUIT
782 NETWORK INTERFACE
783 CONTROLLER
784 MEMORY
7841 OPERATING SYSTEM
7842 COMMUNICATIONS CONTROL MODULE
78421 TRANSCEIVER CONTROL MODULE
79 NEF
791 TRANSCEIVER CIRCUIT
792 NETWORK INTERFACE
793 CONTROLLER
794 MEMORY
7941 OPERATING SYSTEM
7942 COMMUNICATIONS CONTROL MODULE
79421 TRANSCEIVER CONTROL MODULE

Claims (60)

  1. 　　A method of a first communication apparatus comprising:
    　　sending information related to Ambient Internet of Things (IoT) to a second communication apparatus.
  2. 　　The method according to claim 1,
    　　wherein the first communication apparatus is an Application Function (AF), and
    　　wherein the second communication apparatus is a Network Exposure Function (NEF).
  3. 　　The method according to claim 1,
    　　wherein the first communication apparatus is an Application Function (AF), and
    　　wherein the second communication apparatus is a UE-to-Network Relay UE for the Ambient IoT.
  4. 　　A method of a first communication apparatus comprising:
    　　receiving information related to Ambient Internet of Things (IoT) from a second communication apparatus.
  5. 　　The method according to claim 4,
    　　wherein the first communication apparatus is a Unified Data Management (UDM), and
    　　wherein the second communication apparatus is a Network Exposure Function (NEF).
  6. 　　The method according to claim 4, further comprising:
    　　sending the information to a third communication apparatus.
  7. 　　The method according to claim 6,
    　　wherein the first communication apparatus is a Network Exposure Function (NEF),
    　　wherein the second communication apparatus is an Application Function (AF), and
    　　wherein the third communication apparatus is a Unified Data Management (UDM).
  8. 　　The method according to claim 4,
    　　wherein the first communication apparatus is a UE-to-Network Relay UE for the Ambient IoT, and
    　　wherein the second communication apparatus is an Application Function (AF).
  9. 　　A method of a communication apparatus comprising:
    　　performing a Registration procedure for Ambient Internet of Things (IoT).
  10. 　　The method according to claim 9,
    　　wherein the communication apparatus is a User Equipment (UE) for Ambient Internet of Things (IoT).
  11. 　　The method according to claim 10, further comprising:
    　　sending data for the Ambient IoT during the Registration procedure.
  12. 　　The method according to claim 9,
    　　wherein the communication apparatus is an Access and Mobility Management Function (AMF).
  13. 　　The method according to claim 9,
    　　wherein the communication apparatus is a Unified Data Management (UDM).
  14. 　　The method according to claim 9,
    　　wherein the communication apparatus is a Network Exposure Function (NEF).
  15. 　　The method according to claim 9,
    　　wherein the communication apparatus is an Application Function (AF).
  16. 　　The method according to claim 9,
    　　wherein the communication apparatus is a Session Management Function (SMF).
  17. 　　The method according to claim 9,
    　　wherein the communication apparatus is a User Plane Function (UPF).
  18. 　　The method according to claim 9,
    　　wherein the communication apparatus is a Radio Access Network (RAN) node.
  19. 　　The method according to claim 9,
    　　wherein the communication apparatus is an Integrated access and backhaul (IAB) donor.
  20. 　　A method of a first communication apparatus comprising:
    　　sending information for activating Ambient Internet of Things (IoT) to a second communication apparatus.
  21. 　　The method according to claim 20,
    　　wherein the first communication apparatus is an Application Function (AF), and
    　　wherein the second communication apparatus is a Network Exposure Function (NEF).
  22. 　　The method according to claim 20,
    　　wherein the first communication apparatus is a User Equipment (UE) for Ambient Internet of Things (IoT), and
    　　wherein the second communication apparatus is a Radio Access Network (RAN) node.
  23. 　　The method according to claim 20,
    　　wherein the first communication apparatus is an Application Function (AF), and
    　　wherein the second communication apparatus is a UE-to-Network Relay UE for the Ambient IoT.
  24. 　　A method of a first communication apparatus comprising:
    　　receiving first information for activating Ambient Internet of Things (IoT) from a second communication apparatus.
  25. 　　The method according to claim 24, further comprising:
    　　sending second information for activating the Ambient IoT to a third communication apparatus,
    　　wherein the first communication apparatus is a Network Exposure Function (NEF),
    　　wherein the second communication apparatus is an Application Function (AF), and
    　　wherein the third communication apparatus is a Unified Data Management (UDM).
  26. 　　The method according to claim 25, further comprising:
    　　receiving third information for activating the Ambient IoT from the third communication apparatus, and
    　　sending fourth information for activating the Ambient IoT to a fourth communication apparatus,
    　　wherein the fourth communication apparatus is an Access and Mobility Management Function (AMF).
  27. 　　The method according to claim 24, further comprising:
    　　sending second information for activating the Ambient IoT to a third communication apparatus,
    　　wherein the first communication apparatus is an Access and Mobility Management Function (AMF),
    　　wherein the second communication apparatus is a Network Exposure Function (NEF), and
    　　wherein the third communication apparatus is a Radio Access Network (RAN) node.
  28. 　　The method according to claim 24, further comprising:
    　　sending second information for activating the Ambient IoT to a third communication apparatus,
    　　wherein the first communication apparatus is a Radio Access Network (RAN) node,
    　　wherein the second communication apparatus is an Access and Mobility Management Function (AMF), and
    　　wherein the third communication apparatus is a Radio Cell.
  29. 　　The method according to claim 24,
    　　wherein the first communication apparatus is a UE-to-Network Relay UE for the Ambient IoT, and
    　　wherein the second communication apparatus is an Application Function (AF).
  30. 　　The method according to claim 24,
    　　wherein the first communication apparatus is a User Equipment (UE) for the Ambient IoT, and
    　　wherein the second communication apparatus is an Application Function (AF).
  31. 　　A first communication apparatus comprising:
    　　means for sending information related to Ambient Internet of Things (IoT) to a second communication apparatus.
  32. 　　The first communication apparatus according to claim 31,
    　　wherein the first communication apparatus is an Application Function (AF), and
    　　wherein the second communication apparatus is a Network Exposure Function (NEF).
  33. 　　The first communication apparatus according to claim 31,
    　　wherein the first communication apparatus is an Application Function (AF), and
    　　wherein the second communication apparatus is a UE-to-Network Relay UE for the Ambient IoT.
  34. 　　A first communication apparatus comprising:
    　　means for receiving information related to Ambient Internet of Things (IoT) from a second communication apparatus.
  35. 　　The first communication apparatus according to claim 34,
    　　wherein the first communication apparatus is a Unified Data Management (UDM), and
    　　wherein the second communication apparatus is a Network Exposure Function (NEF).
  36. 　　The first communication apparatus according to claim 34, further comprising:
    　　means for sending the information to a third communication apparatus.
  37. 　　The first communication apparatus according to claim 36,
    　　wherein the first communication apparatus is a Network Exposure Function (NEF),
    　　wherein the second communication apparatus is an Application Function (AF), and
    　　wherein the third communication apparatus is a Unified Data Management (UDM).
  38. 　　The first communication apparatus according to claim 34,
    　　wherein the first communication apparatus is a UE-to-Network Relay UE for the Ambient IoT, and
    　　wherein the second communication apparatus is an Application Function (AF).
  39. 　　A communication apparatus comprising:
    　　means for performing a Registration procedure for Ambient Internet of Things (IoT).
  40. 　　The communication apparatus according to claim 39,
    　　wherein the communication apparatus is a User Equipment (UE) for Ambient Internet of Things (IoT).
  41. 　　The communication apparatus according to claim 40, further comprising:
    　　means for sending data for the Ambient IoT during the Registration procedure.
  42. 　　The communication apparatus according to claim 39,
    　　wherein the communication apparatus is an Access and Mobility Management Function (AMF).
  43. 　　The communication apparatus according to claim 39,
    　　wherein the communication apparatus is a Unified Data Management (UDM).
  44. 　　The communication apparatus according to claim 39,
    　　wherein the communication apparatus is a Network Exposure Function (NEF).
  45. 　　The communication apparatus according to claim 39,
    　　wherein the communication apparatus is an Application Function (AF).
  46. 　　The communication apparatus according to claim 39,
    　　wherein the communication apparatus is a Session Management Function (SMF).
  47. 　　The communication apparatus according to claim 39,
    　　wherein the communication apparatus is a User Plane Function (UPF).
  48. 　　The communication apparatus according to claim 39,
    　　wherein the communication apparatus is a Radio Access Network (RAN) node.
  49. 　　The communication apparatus according to claim 39,
    　　wherein the communication apparatus is an Integrated access and backhaul (IAB) donor.
  50. 　　A first communication apparatus comprising:
    　　means for sending information for activating Ambient Internet of Things (IoT) to a second communication apparatus.
  51. 　　The first communication apparatus according to claim 50,
    　　wherein the first communication apparatus is an Application Function (AF), and
    　　wherein the second communication apparatus is a Network Exposure Function (NEF).
  52. 　　The first communication apparatus according to claim 50,
    　　wherein the first communication apparatus is a User Equipment (UE) for Ambient Internet of Things (IoT), and
    　　wherein the second communication apparatus is a Radio Access Network (RAN) node.
  53. 　　The first communication apparatus according to claim 50,
    　　wherein the first communication apparatus is an Application Function (AF), and
    　　wherein the second communication apparatus is a UE-to-Network Relay UE for the Ambient IoT.
  54. 　　A first communication apparatus comprising:
    　　means for receiving first information for activating Ambient Internet of Things (IoT) from a second communication apparatus.
  55. 　　The first communication apparatus according to claim 54, further comprising:
    　　means for sending second information for activating the Ambient IoT to a third communication apparatus,
    　　wherein the first communication apparatus is a Network Exposure Function (NEF),
    　　wherein the second communication apparatus is an Application Function (AF), and
    　　wherein the third communication apparatus is a Unified Data Management (UDM).
  56. 　　The first communication apparatus according to claim 55, further comprising:
    　　means for receiving third information for activating the Ambient IoT from the third communication apparatus, and
    　　means for sending fourth information for activating the Ambient IoT to a fourth communication apparatus,
    　　wherein the fourth communication apparatus is an Access and Mobility Management Function (AMF).
  57. 　　The first communication apparatus according to claim 54, further comprising:
    　　means for sending second information for activating the Ambient IoT to a third communication apparatus,
    　　wherein the first communication apparatus is an Access and Mobility Management Function (AMF),
    　　wherein the second communication apparatus is a Network Exposure Function (NEF), and
    　　wherein the third communication apparatus is a Radio Access Network (RAN) node.
  58. 　　The first communication apparatus according to claim 54, further comprising:
    　　means for sending second information for activating the Ambient IoT to a third communication apparatus,
    　　wherein the first communication apparatus is a Radio Access Network (RAN) node,
    　　wherein the second communication apparatus is an Access and Mobility Management Function (AMF), and
    　　wherein the third communication apparatus is a Radio Cell.
  59. 　　The first communication apparatus according to claim 54,
    　　wherein the first communication apparatus is a UE-to-Network Relay UE for the Ambient IoT, and
    　　wherein the second communication apparatus is an Application Function (AF).
  60. 　　The first communication apparatus according to claim 54,
    　　wherein the first communication apparatus is a User Equipment (UE) for the Ambient IoT, and
    　　wherein the second communication apparatus is an Application Function (AF).
PCT/JP2024/025990 2023-08-09 2024-07-19 Method of first communication apparatus, method of communication apparatus, first communication apparatus and communication apparatus Pending WO2025033139A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IN202311053372 2023-08-09
IN202311053372 2023-08-09

Publications (1)

Publication Number Publication Date
WO2025033139A1 true WO2025033139A1 (en) 2025-02-13

Family

ID=94533996

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2024/025990 Pending WO2025033139A1 (en) 2023-08-09 2024-07-19 Method of first communication apparatus, method of communication apparatus, first communication apparatus and communication apparatus

Country Status (1)

Country Link
WO (1) WO2025033139A1 (en)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115428479A (en) * 2022-07-29 2022-12-02 北京小米移动软件有限公司 Device positioning method, system and device, communication device and storage medium

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115428479A (en) * 2022-07-29 2022-12-02 北京小米移动软件有限公司 Device positioning method, system and device, communication device and storage medium

Similar Documents

Publication Publication Date Title
WO2022270258A1 (en) Method of access and mobility management function (amf) apparatus, method of user equipment (ue), method of network slice admission control function (nsacf) apparatus, method of radio access network (ran) node, method of policy control function (pcf) apparatus, amf apparatus, ue, nsacf apparatus, ran node and pcf apparatus
WO2023032529A1 (en) METHOD OF COMMUNICATION APPARATUS, METHOD OF gNB-CU-CP APPARATUS, METHOD OF AMF APPARATUS, METHOD OF SMF APPARATUS, METHOD OF gNB-DU APPARATUS, METHOD OF UPF APPARATUS, COMMUNICATION APPARATUS, gNB-CU-CP APPARATUS, AMF APPARATUS, SMF APPARATUS, gNB-DU APPARATUS AND UPF APPARATUS
WO2023286779A1 (en) Method performed by radio terminal and radio terminal
WO2023080057A1 (en) Method of access and mobility management function (amf) apparatus, method of next generation-radio access network (ng-ran) node, method of user equipment (ue), method of master node (mn), amf apparatus, ng-ran node, ue, and mn
WO2022270386A1 (en) Method of first access and mobility management function (amf) apparatus, method of user equipment (ue), first access and mobility management function (amf) apparatus, and user equipment (ue)
US20250071668A1 (en) Method of user equipment (ue), method of communication apparatus, and ue
WO2023145526A1 (en) Method of user equipment (ue), method of communication apparatus, ue and communication apparatus
US20250184261A1 (en) Method for policy control function (pcf) and pcf
WO2024162185A1 (en) Access and mobility management function, amf, shared radio access network, ran, and method
WO2024248116A1 (en) Method of first communication apparatus, first communication apparatus, method of edge node, method of first core network node, method of first edge node, edge node, first core network node and first edge node
EP4659490A1 (en) Method of communication apparatus, method of user equipment (ue), communication apparatus and ue
EP4585002A1 (en) Method in user equipment (ue), method in access and mobility management function (amf), method in unified data management (udm), ue, amf, and udm
WO2025033139A1 (en) Method of first communication apparatus, method of communication apparatus, first communication apparatus and communication apparatus
WO2025052804A1 (en) Method of user equipment, method of network node, user equipment, and network node
WO2025041507A1 (en) Method of radio access network node, method of user equipment, radio access network node, and user equipment
WO2025052803A1 (en) Method of user equipment, method of network node, user equipment, and network node
WO2025041508A1 (en) Method of first core network node and first core network node
WO2025018243A1 (en) Radio terminal, first core network node, second core network node, third core network node, fourth core network node, method for a radio terminal, method for a first core network node, method for a second core network node, method for a third core network node, and method for a fourth core network node
WO2025018245A1 (en) Radio terminal, master first core network node, secondary first core network node, second core network node, fourth core network node, method for radio terminal, method for master first core network node, method for secondary first core network node, method for second core network node, and method for fourth core network node
WO2025018276A1 (en) Method of user equipment (ue), method of communication apparatus, ue and communication apparatus
WO2025018277A1 (en) Method of user equipment (ue) and ue
WO2025018268A1 (en) Method of user equipment (ue), method of core network apparatus, ue and core network apparatus
WO2025018242A1 (en) Method of user equipment (ue), method of communication apparatus, ue and communication apparatus
WO2025018244A1 (en) Method of user equipment (ue), method of communication apparatus, ue and communication apparatus
WO2025211350A1 (en) Method performed by user equipment (ue), method performed by first core network (cn) device, user equipment (ue), and first core network (cn) device

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24851568

Country of ref document: EP

Kind code of ref document: A1