Method and system for handling selection of ambient internet of things (IOT) function

Abstract

A method for identifying an Ambient Internet of Things (AIoT) Function (AIoTF) by a Network Exposure Function (NEF) in a wireless communication system is provided. The method comprises receiving, from an Application Function (AF), a service operation request indicating at least one of an AF Identifier (ID) and an AIoT Device Permanent ID corresponding to one or more AIoT devices. The method further comprises transmitting, to an AIoT Data Management (ADM), a Nadm_DM_Query Request message to request serving AIoTF information for the one or more AIoT Devices. The method further comprises receiving, from the ADM, a Nadm_DM_Query Response message including last known AIoTF information. The method further comprises identifying the AIoTF based on the last known AIoTF information.

Description

METHOD AND SYSTEM FOR HANDLING SELECTION OF AMBIENT INTERNET OF THINGS (IOT) FUNCTION

[0001] The present disclosure relates to wireless communication systems for Ambient Internet of Things (AIoT) devices, and more particularly to methods and systems for handling selection of an Ambient IoT Function (AIoTF).

[0002] 5G mobile communication technologies define broad frequency bands such that high transmission rates and new services are possible, and can be implemented not only in "Sub 6GHz" bands such as 3.5GHz, but also in "Above 6GHz" bands referred to as mmWave including 28GHz and 39GHz. In addition, it has been considered to implement 6G mobile communication technologies (referred to as Beyond 5G systems) in terahertz bands (for example, 95GHz to 3THz bands) in order to accomplish transmission rates fifty times faster than 5G mobile communication technologies and ultra-low latencies one-tenth of 5G mobile communication technologies.

[0003] At the beginning of the development of 5G mobile communication technologies, in order to support services and to satisfy performance requirements in connection with enhanced Mobile BroadBand (eMBB), Ultra Reliable Low Latency Communications (URLLC), and massive Machine-Type Communications (mMTC), there has been ongoing standardization regarding beamforming and massive MIMO for mitigating radio-wave path loss and increasing radio-wave transmission distances in mmWave, supporting numerologies (for example, operating multiple subcarrier spacings) for efficiently utilizing mmWave resources and dynamic operation of slot formats, initial access technologies for supporting multi-beam transmission and broadbands, definition and operation of BandWidth Part (BWP), new channel coding methods such as a Low Density Parity Check (LDPC) code for large amount of data transmission and a polar code for highly reliable transmission of control information, L2 pre-processing, and network slicing for providing a dedicated network specialized to a specific service.

[0004] Currently, there are ongoing discussions regarding improvement and performance enhancement of initial 5G mobile communication technologies in view of services to be supported by 5G mobile communication technologies, and there has been physical layer standardization regarding technologies such as Vehicle-to-everything (V2X) for aiding driving determination by autonomous vehicles based on information regarding positions and states of vehicles transmitted by the vehicles and for enhancing user convenience, New Radio Unlicensed (NR-U) aimed at system operations conforming to various regulation-related requirements in unlicensed bands, NR UE Power Saving, Non-Terrestrial Network (NTN) which is UE-satellite direct communication for providing coverage in an area in which communication with terrestrial networks is unavailable, and positioning.

[0005] Moreover, there has been ongoing standardization in air interface architecture / protocol regarding technologies such as Industrial Internet of Things (IIoT) for supporting new services through interworking and convergence with other industries, Integrated Access and Backhaul (IAB) for providing a node for network service area expansion by supporting a wireless backhaul link and an access link in an integrated manner, mobility enhancement including conditional handover and Dual Active Protocol Stack (DAPS) handover, and two-step random access for simplifying random access procedure (2-step RACH for NR). There also has been ongoing standardization in system architecture / service regarding a 5G baseline architecture (for example, service based architecture or service based interface) for combining Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) for receiving services based on UE positions.

[0006] As 5G mobile communication systems are commercialized, connected devices that have been exponentially increasing will be connected to communication networks, and it is accordingly expected that enhanced functions and performances of 5G mobile communication systems and integrated operations of connected devices will be necessary. To this end, new research is scheduled in connection with eXtended Reality (XR) for efficiently supporting Augmented Reality (AR), Virtual Reality (VR), Mixed Reality (MR) and the like, 5G performance improvement and complexity reduction by utilizing Artificial Intelligence (AI) and Machine Learning (ML), AI service support, metaverse service support, and drone communication.

[0007] Furthermore, such development of 5G mobile communication systems will serve as a basis for developing not only new waveforms for providing coverage in terahertz bands of 6G mobile communication technologies, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), array antennas and large-scale antennas, metamaterial-based lenses and antennas for improving coverage of terahertz band signals, high-dimensional space multiplexing technology using Orbital Angular Momentum (OAM), and Reconfigurable Intelligent Surface (RIS), but also full-duplex technology for increasing frequency efficiency of 6G mobile communication technologies and improving system networks, AI-based communication technology for implementing system optimization by utilizing satellites and Artificial Intelligence (AI) from the design stage and internalizing end-to-end AI support functions, and next-generation distributed computing technology for implementing services at levels of complexity exceeding the limit of UE operation capability by utilizing ultra-high-performance communication and computing resources.

[0008] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

[0009] The present disclosure relates to methods and systems for handling the selection of an Ambient Internet of Things (AIoT) Function (AIoTF) by a Network Exposure Function (NEF) in a communication system. The present disclosure addresses the problem of AIoTF selection when target area information is not provided by an Application Function (AF), by enabling the NEF to query an AIoT Data Management (ADM) entity to obtain last known AIoTF information associated with AIoT Device identifiers.

[0010] In an embodiment, a method performed by a Network Exposure Function (NEF) in a communication system is provided. The method comprises receiving, from an Application Function (AF), a service operation request including at least one identifier (ID) of at least one Ambient Internet of Things (AIoT) device. The method further comprises transmitting, to an AIoT Data Management (ADM), a query request for requesting AIoT function (AIoTF) information associated the at least one AIoT device. The query request includes an AIoT device permanent ID associated with the at least one AIoT device. The method further comprises receiving, from the ADM, a query response including the AIoTF information associated with the at least one AIoT device. The method further comprises selecting an AIoTF based on the AIoTF information associated with the at least one AIoT device.

[0011] In an embodiment, a method for handling an Ambient Internet of Things (AIoT) service request by an AIoT Data Management (ADM) in a communication system is provided. The method comprises receiving, from a Network Exposure Function (NEF), a query request including an AIoT device permanent identifier (ID) associated with at least one AIoT device. The method further comprises retrieving, from a database, AIoT function (AIoTF) information associated with the at least one AIoT device. The method further comprises transmitting, to the NEF, a query response including the AIoTF information.

[0012] In an embodiment, an apparatus for a Network Exposure Function (NEF) in a communication system is provided. The apparatus comprises a memory and a processor coupled to the memory. The processor is configured to receive, from an Application Function (AF), a service operation request including at least one identifier (ID) of at least one Ambient Internet of Things (AIoT) device. The processor is further configured to transmit, to an AIoT Data Management (ADM), a query request for requesting AIoT function (AIoTF) information associated with the at least one AIoT device. The query request includes an AIoT device permanent ID associated with the at least one AIoT device. The processor is further configured to receive, from the ADM, a query response including the AIoTF information associated with the at least one AIoT device. The processor is further configured to select an AIoTF based on the AIoTF information associated with the at least one AIoT device.

[0013] In an embodiment, an apparatus for an Ambient Internet of Things (AIoT) Data Management (ADM) handling AIoT service requests in a communication system is provided. The apparatus comprises a memory and a processor coupled to the memory. The processor is configured to receive, from a Network Exposure Function (NEF), a query request including an AIoT device permanent identifier (ID) associated with at least one AIoT device. The processor is further configured to retrieve, from a database, AIoT function (AIoTF) information associated with the at least one AIoT device. The processor is further configured to transmit, to the NEF, a query response including the AIoTF information.

[0014] To further clarify the advantages and features of the present disclosure, a more particular description of the disclosure will be rendered by reference to specific embodiments thereof, which are illustrated in the appended drawing. It is appreciated that these drawings depict only typical embodiments of the disclosure and are therefore not to be considered limiting its scope. The disclosure will be described and explained with additional specificity and detail with the accompanying drawings.

[0015] These and other features, aspects, and advantages of the present disclosure will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:

[0016] FIG. 1 illustrates a sequence diagram for handling an inventory procedure in an Ambient Internet of Things (IoT) network, in accordance with prior art;

[0017] FIG. 2 illustrates a sequence diagram for handling command procedures in the Ambient IoT network, in accordance with prior art;

[0018] FIG. 3 illustrates an environment for Ambient IoT (AIoT) communication within a wireless communication system, in accordance with an embodiment of the present disclosure.

[0019] FIG. 4 illustrates a block diagram of a system for identifying an AIoT Function (AIoTF) by a Network Exposure Function (NEF) in the wireless communication system, in accordance with an embodiment of the present disclosure;

[0020] FIG. 5 illustrates a sequence diagram illustrating a process for retrieving AIoTF information from an AIoT Data Management (ADM) entity, in accordance with an embodiment of the present disclosure;

[0021] FIG. 6 illustrates a sequence diagram illustrating a process for handling selection of an AIoTF and Base Station (BS) reader, in accordance with an embodiment of the present disclosure;

[0022] FIGs. 7A-7B illustrate sequence diagrams depicting process for handling AIoTF selection by the NEF, in accordance with an embodiment of the present disclosure;

[0023] FIG. 8 illustrates a flow diagram depicting a method for identifying the AIoTF by the NEF in the wireless communication system, in accordance with an embodiment of the present disclosure;

[0024] FIG. 9 illustrates a block diagram of a system for handling AIoTF service requests in the wireless communication system, in accordance with an embodiment of the present disclosure;

[0025] FIG. 10 illustrates a flow diagram depicting a method for handling AIoTF service requests in the wireless communication system, in accordance with an embodiment of the present disclosure;

[0026] FIG. 11 depicts a User Equipment (UE) Configuration Update procedure for transparent UE Policy delivery, in accordance with prior art;

[0027] FIG. 12 illustrates a sequence diagram representing a subscription data notification procedure, in accordance with prior art; and

[0028] FIG. 13 is a sequence diagram depicting an Artificial Intelligence / Machine Learning (AI / ML) server configuration at UE via Operations Administration and Maintenance (OAM), in accordance with an embodiment of the present disclosure.

[0029] Further, skilled artisans will appreciate that those elements in the drawings are illustrated for simplicity and may not have necessarily been drawn to scale. For example, the flow charts illustrate the method in terms of the most prominent steps involved to help to improve understanding of aspects of the present disclosure. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding the embodiments of the present disclosure so as not to obscure the drawings with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

[0030] For the purpose of promoting an understanding of the principles of the present disclosure, reference will now be made to the various embodiments, and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of the present disclosure is thereby intended, such alterations and further modifications in the illustrated system, and such further applications of the principles of the present disclosure as illustrated therein, being contemplated as would normally occur to one skilled in the art to which the present disclosure relates.

[0031] It will be understood by those skilled in the art that the foregoing general description and the following detailed description are explanatory of the present disclosure and are not intended to be restrictive thereof.

[0032] Whether or not a certain feature or element was limited to being used only once, it may still be referred to as "one or more features" or "one or more elements," "at least one feature," or "at least one element." Furthermore, the use of the terms "one or more" or "at least one" feature or element does not preclude there being none of that feature or element, unless otherwise specified by limiting language, including, but not limited to, "there needs to be one or more..." or "one or more elements are required."

[0033] Reference is made herein to some "embodiments." It should be understood that an embodiment is an example of a possible implementation of any features and / or elements of the present disclosure. Some embodiments have been described for the purpose of explaining one or more of the potential ways in which the specific features and / or elements of the proposed disclosure fulfill the requirements of uniqueness, utility, and non-obviousness.

[0034] Use of the phrases and / or terms including, but not limited to, "a first embodiment," "a further embodiment," "an alternate embodiment," "one embodiment," "an embodiment," "multiple embodiments," "some embodiments," "other embodiments," "further embodiment", "furthermore embodiment", "additional embodiment" or other variants thereof do not necessarily refer to the same embodiments. Unless otherwise specified, one or more particular features and / or elements described in connection with one or more embodiments may be found in one embodiment, or may be found in more than one embodiment, or may be found in all embodiments, or may be found in no embodiments. Although one or more features and / or elements may be described herein in the context of only a single embodiment, or in the context of more than one embodiment, or in the context of all embodiments, the features and / or elements may instead be provided separately or in any appropriate combination or not at all. Conversely, any features and / or elements described in the context of separate embodiments may alternatively be realized as existing together in the context of a single embodiment.

[0035] Any particular and all details set forth herein are used in the context of some embodiments and therefore should not necessarily be taken as limiting factors to the proposed disclosure.

[0036] 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 process or method. Similarly, one or more devices or sub-systems or elements or structures or components preceded by "comprises... a" does not, without more constraints, preclude the existence of other devices or other sub-systems or other elements or other structures or other components or additional devices or additional sub-systems or additional elements or additional structures or additional components.

[0037] The term "couple" and the derivatives thereof refer to any direct or indirect communication between two or more elements, whether or not those elements are in physical contact with each other. The terms "transmit", "receive", and "communicate", as well as the derivatives thereof, encompass both direct and indirect communication. The term "or" is an inclusive term meaning "and / or". The phrase "associated with," as well as derivatives thereof, refer to include, be included within, interconnect with, contain, be contained within, connect to or with, couple to or with, be communicable with, cooperate with, interleave, juxtapose, be proximate to, be bound to or with, have, have a property of, have a relationship to or with, or the like. The term "controller" refers to any device, system, or part thereof that controls at least one operation. The functionality associated with any particular controller may be centralized or distributed, whether locally or remotely. The phrase "at least one of," when used with a list of items, means that different combinations of one or more of the listed items may be used, and only one item in the list may be needed. For example, "at least one of A, B, and C" includes any of the following combinations: A, B, C, A and B, A and C, B and C, and A and B and C, and any variations thereof. As an additional example, the expression "at least one of a, b, or c" may indicate only a, only b, only c, both a and b, both a and c, both b and c, all of a, b, and c, or variations thereof. Similarly, the term "set" means one or more. Accordingly, the set of items may be a single item or a collection of two or more items.

[0038] Moreover, multiple functions described below may be implemented or supported by one or more computer programs, each of which is formed from computer-readable program code and embodied in a computer-readable medium. The terms "application" and "program" refer to one or more computer programs, software components, sets of instructions, procedures, functions, objects, classes, instances, related data, or a portion thereof adapted for implementation in a suitable computer-readable program code. The phrase "computer-readable program code" includes any type of computer code, including source code, object code, and executable code. The phrase "computer-readable medium" includes any type of medium capable of being accessed by a computer, such as Read Only Memory (ROM), Random Access Memory (RAM), a hard disk drive, a Compact Disc (CD), a Digital Video Disc (DVD), or any other type of memory. A "non-transitory" computer-readable medium excludes wired, wireless, optical, or other communication links that transport transitory electrical or other signals. A non-transitory computer-readable medium includes media where data may be permanently stored and media where data may be stored and later overwritten, such as a rewritable optical disc or an erasable memory device.

[0039] Common reference numerals are used throughout the figures to indicate similar features.

[0040] The Fifth-Generation (5G) system architecture for Ambient Intelligence of Things (AIoT) encompasses several critical functions and procedures. Such critical functions include AIoT Device identification, inventory management, data exchange with AIoT Device applications, and the ability to disable AIoT Devices. The 5G system architecture integrates core network functionalities, various AIoT reader configurations, and AIoT Devices as delineated in Technical Specification (TS) 23.369. The different AIoT reader architectures facilitate multiple deployment strategies, specifically through AIoT Radio Access Network (RAN) connectivity, which may be established via direct or indirect paths. Direct connectivity allows for a direct link between the AIoT RAN and the AIoT Function (AIoTF). On the other hand, indirect connectivity is facilitated through an Access and Mobility Management Function (AMF).

[0041] The 5G System (5GS) architecture also incorporates a Network Exposure Function (NEF). NEF utilizes reference point representation as defined in clause 4.2.3 of TS 23.501, featuring a southbound interface from the NEF to the AIoTF. The 5GS architecture supports direct and indirect pathways for accessing the AIoT RAN. The AIoTF is configured for terminating the AIoT Non-Access Stratum (NAS) protocol with AIoT Devices. The AIoTF also establishes connectivity with the AIoT RAN via a direct interface reference point or the AMF. The AIoTF also retrieves AIoT Device profile data and Application Function (AF) subscription data from the AIoT Data Management (ADM) system, and optionally manages AIoT Device context.

[0042] Furthermore, the AIoTF facilitates various service operations toward AIoT Devices. The AIoTF provides an interface to the AF, or via the NEF, for supporting AIoT services. The AIoTF authorizes service operation requests issued by a trusted AF. The AIoTF triggers the AIoT RAN to perform the required AIoT service operations toward the AIoT Device(s). The AIoTF may also determine and supply assistance information to the AIoT RAN when needed. The AIoTF reports the service operation results to the AF, or via the NEF, depending on local configuration or AF request. The AIoTF performs AIoT RAN selection, and may optionally perform RAN Reader selection, for supporting the service operation. The AIoTF performs AMF selection based on target area information when the AIoTF connects to the AIoT RAN indirectly through an AMF. The AIoTF also allocates a Correlation ID corresponding to the AF's service operation request.

[0043] In the context of AIoT Device profile management, as specified in TS 23.369, the ADM may retain operator subscription data for AIoT Devices within the network. If the AIoT Device is managed by the network, the associated profile data is required. Otherwise, relevant profile data, such as Device ID or credentials, is stored externally. The AIoT Device ID is utilized by the AIoTF, in conjunction with local configurations and third-party context, to identify the entity storing an AIoT Device's profile data. If the AIoT Device is network-managed, the AIoTF verifies the presence of profile data in the network and retrieves it accordingly. Notably, the profile data for AIoT Devices differs from User Equipment (UE) subscription data, as outlined in TS 23.502, clause 5.2.3 (shown in Table 1), and is specifically stored in the ADM, which is dedicated to managing AIoT Device profile data. An AIoT Device permanent ID is the primary key for AIoT Device profile data in the ADM.

[0044] [Table 1]

[0045]

[0046] In addition, the AIoTF supports three types of command service operations, i.e., read, write, and disable. The read operation allows an AF to retrieve information from a specific AIoT Device, while the write operation enables the configuration of information into the specific AIoT Device. The disable operation allows an AF to permanently disable the capability of AIoT Devices to transmit RF signals.

[0047] Moreover, the AIoTF selects AIoT RAN nodes and, optionally, a list of RAN Readers based on internal area information. The AF provides the expected target area information in the AIoT service request. The NEF converts the target area information received from the AF into internal area information. The NEF queries a Network Repository Function (NRF) to obtain serving AIoTF(s) based on this internal area information. Then, the NEF forwards the AIoT service request, including the internal area information, to the AIoTF. The AIoTF maintains AIoT RAN information and optional RAN Reader information. For direct path operation, the AIoTF obtains the information from the AIoT RAN via NGAP or OAM configuration. If an AIoT service request includes AIoT Device identifier(s), the AIoTF considers the last known serving RAN Reader(s) to determine targeted RAN Reader(s) directly.

[0048] However, several problems arise in existing wireless communication systems, as described below. For example, under the current framework, the NEF selects an AIoTF based on target area information for AIoT service operation and target AIoT Device information received from the AF. According to 3GPP TS 23.369, when no suitable AIoTF is identified, the NEF rejects the AIoT command request with an appropriate cause code. Each AIoTF locally stores and manages AIoT Device context information, including the AIoT Device permanent identifier and the last known Reader information associated with the AIoT Device. The last known Reader information supports the selection of a serving Reader for forwarding messages to a specific AIoT Device, as defined in TS 23.369. However, the selection procedure applied by the NEF remains unclear when the AIoT Device lacks stored Device context information. Furthermore, no defined mechanism specifies how the NEF determines a previously associated AIoTF when Device context information is unavailable.

[0049] In addition to the foregoing architectural and interaction issues between the AIoT framework and the NEF, ongoing integration of Artificial Intelligence (AI) and Machine Learning (ML) into 5G-based systems introduces further technical considerations. AI and ML technologies provide opportunities to enhance network performance, operational efficiency, and intelligent decision-making across AIoT deployments, including AIoT RAN optimization, interference management, predictive maintenance, and intelligent selection of AIoT RAN Readers or AIoTFs. Realization of AI / ML-driven enhancements requires a robust and standardized mechanism for uploading AIoT Device data over the user plane (UP) to support data collection. User plane data collection enables training, validation, and deployment of AI / ML models aligned with policies enforced by the AIoTF, NEF, AF, and Application Data Management (ADM) functions.

[0050] The current 5G System does not provide a dedicated user plane data collection framework optimized for AI / ML requirements in AIoT environments. Absence of such a framework creates multiple technical challenges. For example, no standardized procedure exists for uploading AIoT Device data over the user plane specifically for AI / ML purposes, resulting in inconsistent implementations that degrade AI / ML model performance supporting AIoT service operations.

[0051] Further, interaction procedures supporting AI / ML functionality remain undefined. No standardized coordination mechanism governs user plane data uploads and control plane signaling among AIoT Devices, the AIoT RAN, the Access and Mobility Management Function (AMF), the AIoTF, the NEF, and the AF. Lack of defined message exchanges introduces inefficiencies across both the user plane and control plane procedures.

[0052] Furthermore, configuration procedures for AI / ML support remain insufficiently specified. No clear framework defines provisioning timing, required configuration parameters, or responsible entities. Uncertainty persists regarding whether configuration management should be performed by the AIoTF, the NEF through AF policy exposure, or an alternative control mechanism.

[0053] Further, requirements relating to specific Public Land Mobile Networks (PLMNs) lack clarity. No defined rule determines whether AI / ML data collection obligations apply within a single PLMN, across multiple PLMNs, or across defined PLMN groups. Divergent operator policies concerning AIoTF and NEF implementations further complicate cross-PLMN deployments.

[0054] Also, the geographical scope of AI / ML data collection requirements remains ambiguous. The NEF translates AF-specified target area information into internal area information to enable AIoTF-based RAN or Reader selection. However, no clear definition specifies whether AI / ML data uploads must be restricted to designated geographical areas or applied throughout the full network coverage area.

[0055] Further, the temporal scope of AI / ML data collection lacks definition. No standardized guideline specifies whether AI / ML data collection must occur continuously or within defined time intervals. Undefined temporal boundaries affect AI / ML model responsiveness and alignment with AIoTF reporting intervals and AF-driven service cycles.

[0056] Hence, there is a need for improved techniques that overcome the above-discussed and other related problems.

[0057] FIG. 1 illustrates a sequence diagram 100 for handling an inventory procedure in an Ambient Internet of Things (IoT) network, in accordance with prior art. As shown, at step 116, the AF 114 sends an Nnef_AIoT_Inventory Request to the NEF 112. The Nnef_AIoT_Inventory Request 116 may include at least one of an AF Identifier (ID), target area information, AIoT Device ID identification information, an approximate number of AIoT Devices, or other parameters. Upon receiving the Nnef_AIoT_Inventory Request, at step 118, the NEF 112 performs an AIoTF selection to determine an appropriate AIoTF 108 to handle the inventory operation. The NEF 112 may select the AIoTF 108, taking into account target area information for AIoT service operation and target AIoT device information received from the AF 114.

[0058] Then, at step 120, the NEF 112 sends an Naiotf_AIoT_Inventory Request to the selected AIoTF 108. At step 122, the AIoTF 108 generates an Inventory Request and may communicate with the ADM 110. At step 124, the AIoTF 108 sends an Naiotf_AIoT_Inventory Response back toward the NEF 112 once the AIoTF 108 receives initial RAN information. At step 126, the NEF 112 sends an Nnef_AIoT_Inventory Response to the AF 114. At step 128, the AIoTF 108 sends an Inventory Request to the AIoT RAN 104. At step 130, the AIoT RAN 104 returns an Inventory Response to the AIoTF 108. At step 132, the RAN performs the Inventory Procedure. At step 134, the AIoT Device 102 sends an Inventory Report (AIoT NAS message). At step 134, the AIoT Device 102 sends an Inventory Report (AIoT NAS message). At step 136, the AIoTF 108 retrieves AIoT device profile data from the ADM 110. At step 138, the AIoTF 108 sends an Naiotf_AIoT_Inventory Notify to the NEF 112. At step 140, the NEF 112 sends an Nnef_AIoT_Inventory Notify to the AF 114, completing the process.

[0059] FIG. 2 illustrates a sequence diagram for handling command procedures in the Ambient IoT network, in accordance with prior art. As shown, at step 202, the AF 114 sends an Nnef_AIoT_Command Request to the NEF 112. At step 204, the NEF 112 selects the AIoTF. At step 206, the NEF 112 sends an Naiotf_AIoT_Command Request to the AIoTF 108. At step 208, the AIoTF 108 checks if the AF request is authorized. At step 210, the AIOTF 108 sends an Naiotf_AIoT_Command Response back to the NEF 112. At step 212, the NEF 112 then forwards an Nnef_AIoT_Command Response to the AF 114, completing the initial command request phase. Steps 214 to 222 of the Procedure for Inventory may be performed in accordance with clause 6.2.2.

[0060] At step 224a, the AIoTF 108 sends a Command Request to the AMF 106. At step 224b, the AMF 106 delivers the command to the AIoT RAN 104. At step 224c, the AIoT RAN 104 sends the Command Request to the AIoT Device 102. At step 226, the AIoT Device 102 sends a Command Response. At step 228, the RAN sends the response to the AMF 106. At step 230a, the AMF 106 returns the response to the AIoTF 108. At step 230b, the AIoTF 108 forwards the response, including an Naiotf_AIoT_Command Notify 230c, toward the NEF 112. At step 234, the NEF 112 sends an Nnef_AIoT_Command Notify to the AF 114.

[0061] Accordingly, in the context of AIoT service operations, the NEF selects AIoTF(s) taking into account target area information for AIoT service operation and target AIoT device information received from the AF. When the AF provides target area information along with the AIoT service request, the NEF may convert the target area information received from the AF to internal area information and query the NRF to obtain serving AIoTF(s) based on the internal area information. The NEF may then forward the AIoT service request, including the internal area information, to the AIoTF.

[0062] However, a problem arises when no target area information is provided by the AF, and there is no local configuration available at the NEF. In such scenarios, the NEF is not aware of which areas the targeted AIoT Device ID belongs to. Without knowledge of the location or area associated with the AIoT Device, the NEF lacks sufficient information to accurately select an appropriate AIoTF to handle the service request.

[0063] When the NEF cannot determine the appropriate AIoTF due to the absence of target area information, the NEF may be forced to send the request to all available AIoTF(s) and page in all areas of deployment. This approach results in inefficient network resource utilization, as paging throughout the entire system consumes network resources unnecessarily. Broadcasting requests to all AIoTF(s) across all deployment areas when the AIoT device may be located in a single area represents an undesirable operational scenario.

[0064] Additionally, the AIoTF may store and manage AIoT device-related information, also referred to as device context information, locally. The device context information may include the AIoT device permanent ID and the last known reader information of the AIoT device. The last known reader information may be used to support the AIoTF in selecting the serving reader to forward messages towards specific AIoT device(s). However, how the NEF selects the AIoTF when the AIoT Device lacks device context remains unclear. Furthermore, how the last known AIoTF is known to the NEF when there is no AIoT Device context is also not clear. These gaps in the existing procedures create challenges for efficient AIoTF selection by the NEF when target area information is unavailable.

[0065] Accordingly, the present disclosure provides a solution to the above-discussed problems.

[0066] In an embodiment, the present disclosure relates to methods and systems for handling the selection of an AIoTF by an NEF in a wireless communication system. The present disclosure may address scenarios where an AF sends an AIoT service operation request to the NEF without providing target area information. In such scenarios, the NEF may lack sufficient information to determine which AIoTF is serving the targeted AIoT Device(s), as the NEF may not be aware of the geographic area or network location associated with the AIoT Device identifier provided by the AF.

[0067] The present disclosure may provide a mechanism for the NEF to query an AIoT Data Management (ADM) entity to obtain serving AIoTF information for AIoT Device(s) when target area information is not available. The ADM may store AIoT device profile data that includes the last known AIoTF information associated with AIoT Device Permanent identifiers. The last known AIoTF information may indicate the AIoTF that previously served a particular AIoT Device during a prior service operation. By querying the ADM with the AIoT Device Permanent ID received from the AF, the NEF may obtain the last known AIoTF information and may use the last known AIoTF information to select an appropriate AIoTF for the current service operation request.

[0068] The present disclosure may enable the NEF to avoid sending AIoT service requests to all available AIoTFs across all deployment areas when target area information is not provided. Instead of broadcasting requests throughout the network, the NEF may query the ADM to identify the specific AIoTF that previously served the targeted AIoT Device and may forward the service operation request to the identified AIoTF. The present disclosure may thereby reduce network resource consumption and may improve efficiency of AIoT service operations by enabling targeted AIoTF selection based on historical service information maintained by the ADM.

[0069] FIG. 3 illustrates an environment for AIoT communication within a wireless communication system 300, in accordance with an embodiment of the present disclosure. The wireless communication system 300 comprises several components that facilitate AIoT service operations and device management within a wireless communication system.

[0070] The wireless communication system 300 includes an AIoT Device 302, which may represent an Ambient IoT device that may be powered by energy harvesting with limited energy storage capability. The AIoT Device 302 may connect to an AIoT Radio Access Network (RAN) 304, which may support AIoT Reader functionality and may provide radio access network capabilities for the AIoT Device 302. The AIoT RAN 304 may enable communication between the AIoT Device 302 and core network functions through either direct or indirect connectivity paths.

[0071] The wireless communication system 300 further includes an Access and Mobility Function (AMF) 306, which may be positioned to communicate with the AIoT RAN 304. The AMF 306 may facilitate indirect connectivity between the AIoT RAN 304 and other core network functions. In some cases, the AMF 306 may provide mobility management capabilities and may enable message delivery between the AIoT RAN 304 and an AIoTF 308.

[0072] The AIoTF 308 may be centrally positioned within the wireless communication system 300 and may connect to multiple components. The AIoTF 308 may communicate with the AIoT RAN 304, the AMF 306, an AIoT Data Management (ADM) 310, a NEF 312, and an AF 314. The AIoTF 308 may support functions including termination of the AIoT NAS protocol with the AIoT Device 302, connectivity with the AIoT RAN 304 either directly or via the AMF 306, and retrieval of AIoT device profile data from the ADM 310.

[0073] As further shown in FIG. 3, the ADM 310 may be connected to the AIoTF 308. The ADM 310 may store operator subscription data and profile data for AIoT devices managed by the network. The ADM 310 may hold information such as the AIoT Device Permanent ID and the last known AIoTF information. The last known AIoTF information may indicate the last known AIoTF that serves the AIoT device, or may indicate unknown if no prior service has occurred.

[0074] The NEF 312 may connect to the AIoTF 308 and may provide a southbound interface for AIoT service operations. The southbound interface from the NEF 312 to the AIoTF 308 may enable the NEF 312 to forward AIoT service operation requests to the AIoTF 308 and receive responses from the AIoTF 308. The NEF 312 may query the ADM 310 to obtain serving AIoTF information for AIoTF selection purposes. In some cases, the NEF 312 may select the AIoTF 308 based on a currently registered AIoTF, which optionally has a device context. The AIoTF details may be stored at the ADM 310 and / or a Network Repository Function (NRF) or any other network function in a core network, such as a 5G Core (5GC).

[0075] With continued reference to FIG. 3, the AF 314 may connect to both the AIoTF 308 and the NEF 312, enabling application-level requests for AIoT service operations such as inventory and command procedures. The AF 314 may provide target area information and AIoT Device identification information in service requests directed to the NEF 312. In some cases, the AF 314 may send service requests without target area information, in which case the NEF 312 may query the ADM 310 to obtain last known AIoTF information associated with the AIoT Device identifier provided by the AF 314.

[0076] FIG. 4 illustrates a block diagram of a system 400 for identifying the AIoTF 308 by the NEF 312 in the wireless communication system 300, in accordance with an embodiment of the present disclosure. In an embodiment, the system 400 may correspond to the NEF 312. It should be noted that FIGs. 3 and 4 have been explained in conjunction with each other for the sake of brevity of the disclosure.

[0077] The system 400 may include one or more processors 402 (hereinafter referred to as the processor 402), a memory 404, one or more modules 406, and a communication interface 408. The one or more processors 402 may be operatively coupled to the memory 404, the modules 406, and the communication interface 408.

[0078] In one embodiment, the processor 402 may include at least one data processor for executing processes in a Virtual Storage Area Network. The processor 402 may include specialized processing units such as integrated system (bus) controllers, memory management control units, floating point units, graphics processing units, digital signal processing units, etc. In one embodiment, the processor 402 may include a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), or both. The processor 402 may be one or more general processors, Digital Signal Processors (DSPs), application-specific integrated circuits, Field-Programmable Gate Arrays (FPGAs), servers, networks, digital circuits, analog circuits, combinations thereof, or other now known or later developed devices for analyzing and processing data. The processor 402 may execute a software program, such as code generated manually (i.e., programmed), to perform the desired operation. The processor 402 may implement various techniques, such as, but not limited to, image processing, data extraction, Artificial Intelligence (AI), Machine Learning (ML), Deep Learning (DL), and so forth, to achieve the desired objective.

[0079] In one embodiment, the processor 402 may be configured to perform the functions of the system 400 / the NEF 312.

[0080] The processor 402 may be disposed in communication with one or more Input / Output (I / O) devices, such as the AIoTF 308, the ADM 310, etc., via the communication interface 408. The interface 408 may employ communication Code-Division Multiple Access (CDMA), High-Speed Packet Access (HSPA+), Global System For Mobile Communications (GSM), Long-Term Evolution (LTE), 5G, Sixth Generation (6G), WiMax, or the like, etc.

[0081] In an embodiment, the processor 402 may be disposed in communication with a communication network via a network interface. In an embodiment, the network interface may be the communication interface 408. The network interface may connect to the communication network to enable connection of the system 400 with the outside environment and / or device / system. The network interface may employ connection protocols, including, without limitation, direct connect, Ethernet (e.g., twisted pair 10 / 300 / 3000 Base T), Transmission Control Protocol / Internet Protocol (TCP / IP), token ring, IEEE 802.11 / b / g / n / x, etc. The communication network may include, without limitation, a direct interconnection, Local Area Network (LAN), Wide Area Network (WAN), wireless network (e.g., using Wireless Application Protocol (WAP)), the Internet, etc. Using the network interface and the communication network, the system 400 may communicate with other devices. The network interface may employ connection protocols including, but not limited to, direct connect, Ethernet (e.g., twisted pair 10 / 300 / 3000 Base T), TCP / IP, token ring, IEEE 802.11 / b / g / n / x, etc.

[0082] The memory 404 may be communicatively coupled to the processor 402. The memory 404 may be configured to store data and instructions executable by the processor 402. In one embodiment, the memory 404 may communicate via a bus within the system 400. The memory 404 may include, but is not limited to, a non-transitory computer-readable storage media, such as various types of volatile and non-volatile storage media including, but not limited to, random access memory, read-only memory, programmable read-only memory, electrically programmable read-only memory, electrically erasable read-only memory, flash memory, magnetic tape or disk, optical media and the like. In one example, the memory 404 may include a cache or random-access memory for the processor 402. In alternative examples, the memory 404 is separate from the processor 402, such as a cache memory of a processor, the system memory, or other memory. The memory 404 may be an external storage device or database for storing data. The memory 404 may be operable to store instructions executable by the processor 402. The functions, acts, or tasks illustrated in the figures or described may be performed by the programmed processor 402 for executing the instructions stored in the memory 404. The functions, acts, or tasks are independent of the particular type of instruction set, storage media, processor, or processing strategy, and may be performed by software, hardware, integrated circuits, firmware, micro-code, and the like, operating alone or in combination. Likewise, processing strategies may include multiprocessing, multitasking, parallel processing, and the like. The memory 404 may further include a database to store the data. Further, the memory 404 may include an operating system for performing one or more tasks of the system 400, as performed by a generic operating system in the communications domain.

[0083] For the sake of brevity, the architecture and standard operations of the processor 402 and the memory 404 are not discussed in detail. In one embodiment, the memory 404 may be configured to store the information as required by the processor 402 to perform the techniques described herein.

[0084] The modules 406, amongst other things, include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement data types. The modules 406 may also be implemented as signal processor(s), state machine(s), logic circuitries, and / or any other device or component that manipulates signals based on operational instructions. The modules 406 may be configured to one or more operations of the system 400 and / or the processor 402.

[0085] Further, the modules 406 can be implemented in hardware, instructions executed by a processing unit, or by a combination thereof. The processing unit can comprise a computer, the processor 402, a state machine, a logic array, or any other suitable devices capable of processing instructions. The processing unit can be a general-purpose processor that executes instructions to cause the general-purpose processor to perform the required tasks, or the processing unit can be dedicated to performing the required functions. In another embodiment of the present disclosure, the modules 406 may be machine-readable instructions (software) that, when executed by a processor / processing unit, perform any of the described functionalities. Furthermore, the data serves, amongst other things, as a repository for storing data processed, received, and generated by one or more of the modules. The modules 406 may include a receiving module 410, a transmitting module 412, and an identifying module 414.

[0086] With continued reference to FIG. 4, the modules 406 include a receiving module 410, a transmitting module 412, and an identifying module 414. The receiving module 410, the transmitting module 412, and the identifying module 414 may work together to enable the system 400 to perform operations related to identifying an AIoTF based on information obtained from the ADM 310.

[0087] The receiving module 410 may be configured to receive, from the AF 314, a service operation request indicating at least one of an AF Identifier (ID) or an AIoT Device Permanent ID corresponding to one or more AIoT devices. In an embodiment, the service operation request may correspond to an Nnef_AIoT_Inventory Request and / or an Nnef_AIoT_Command Request. For example, the AF 314 may send the Nnef_AIoT_Inventory Request to the NEF 312 when the AF 314 desires to perform an inventory operation on one or more AIoT devices. The Nnef_AIoT_Inventory Request may include the AF ID that identifies the requesting AF 314 and the AIoT Device Permanent ID that uniquely identifies the targeted AIoT device. In some cases, the service operation request from the AF 314 may include target area information, an approximate number of AIoT Devices, and other parameters in addition to the AF ID and AIoT Device ID identification information.

[0088] When the AF 314 desires to retrieve information from a specific AIoT device or configure information into a specific AIoT device, the AF 314 may send the Nnef_AIoT_Command Request to the NEF 312. For example, the AF 314 may send the Nnef_AIoT_Command Request with a read operation type to retrieve application data stored on the AIoT device. In another embodiment, the AF 314 may send the Nnef_AIoT_Command Request with a write operation type to update configuration settings on the AIoT device.

[0089] The transmitting module 412 may be configured to transmit, to the ADM 310, an Nadm_DM_Query Request message corresponding to the service operation request to request serving AIoTF information for the one or more AIoT Devices. The Nadm_DM_Query Request message may comprise at least one of the AF ID or the AIoT Device Permanent ID. For example, when the NEF 312 receives the Nnef_AIoT_Inventory Request from the AF 314 that includes an AIoT Device Permanent ID but does not include target area information, the NEF 312 may query the ADM 310 with the AIoT device ID to determine which AIoTF previously served the AIoT device. The transmitting module 412 may include the AIoT Device Permanent ID in the Nadm_DM_Query Request message to enable the ADM 310 to retrieve the corresponding AIoTF information from a database maintained by the ADM 310.

[0090] Further, the receiving module 410 may be further configured to receive, from the ADM 310, an Nadm_DM_Query Response message. The Nadm_DM_Query Response message may include last known AIoTF information for at least one of the one or more AIoT Devices. For example, when the ADM 310 receives the Nadm_DM_Query Request message containing the AIoT Device Permanent ID, the ADM 310 may verify the AIoT Device Permanent ID and retrieve the corresponding AIoTF information from a database. The ADM 310 may then respond with the AIoTF ID in the Nadm_DM_Query Response message, enabling the NEF 312 to identify the AIoTF that previously served the AIoT device.

[0091] The identifying module 414 may be configured to identify, for the at least one AIoT device, the AIoTF based on the last known AIoTF information. The last known AIoTF information may include at least one of an AIoTF ID, an AIoTF name, a Fully Qualified Domain Name (FQDN), or an Internet Protocol (IP) address of the identified AIoTF. For example, the ADM 310 may provide the AIoTF ID in the Nadm_DM_Query Response message, and the identifying module 414 may use the AIoTF ID to select the AIoTF 308 indicated by the ADM 310. In some cases, the ADM 310 may provide the FQDN or IP address of the AIoTF, which may enable the NEF 312 to establish communication with the identified AIoTF directly.

[0092] As further shown in FIG. 4, the transmitting module 412 may be further configured to forward the service operation request to the identified AIoTF 308. For example, upon receiving the AIoTF ID from the ADM 310 and identifying the AIoTF 308, the NEF 312 may forward the Nnef_AIoT_Inventory Request or the Nnef_AIoT_Command Request to the identified AIoTF 308. The AIoTF 308 may then proceed with the inventory or command procedures as specified in the applicable standards.

[0093] In some cases, the NEF 312 may be allowed for an Nadm_DM_Update service operation in addition to the Nadm_DM_Query service operation with the ADM 310. The Nadm_DM_Update service operation may enable the NEF 312 to update AIoT device profile data stored at the ADM 310 based on information obtained during AIoT service operations.

[0094] The system 400 may enable the NEF 312 to avoid blind search in all the areas and efficiently select the AIOTF 308. For example, when the AF 314 sends an AIoT service request without target area information, the NEF 312 may query the ADM 310 with the AIoT device ID to check if the last known AIoTF information is available for the respective AIoT Device ID. If the ADM 310 provides the AIoTF information, the NEF 312 may use the AIoTF information to select the AIoTF 308, rather than sending the request to all available AIoTFs and paging in all areas of deployment. The system 400 may thereby reduce network resource consumption and improve efficiency of AIoT service operations by enabling targeted AIoTF selection based on historical service information maintained by the ADM 310.

[0095] FIG. 5 illustrates a sequence diagram illustrating a process 500 for retrieving AIoTF information from an AIoT Data Management (ADM) entity, in accordance with an embodiment of the present disclosure. The procedure 500 includes multiple steps that enable the NEF 312 to obtain serving AIoTF information from the ADM 310 when target area information is not provided by the AF 314.

[0096] At step 502, the ADM 310 stores the AIoT device profile data along with location information. The AIoT device profile data may include the AIoT Device Permanent ID that uniquely identifies the AIoT Device and the last known AIoTF information that indicates the last known AIOTF that serves the AIoT device. The ADM 310 may store the AIoT device profile data in a Unified Data Repository (UDR) and manage the AIoT device profile data. In some cases, when a request for the serving AIoTF is received from the NEF 312, the ADM 310 may retrieve the AIoT device profile from a Unified Data Management (UDM) or the UDR and identify the correct AIoTF to select.

[0097] At step 504, the AF 314 sends an Nnef_AIoT_Inventory Request to the NEF 312 to initiate an inventory service operation. The Nnef_AIoT_Inventory Request may include at least one of an AF ID, target area information, AIoT Device ID identification information, an approximate number of AIoT Devices, or other parameters. In some cases, the AF 314 may send the Nnef_AIoT_Inventory Request without target area information, in which case the NEF 312 may query the ADM 310 to obtain the last known AIoTF information associated with the AIoT Device identifier provided by the AF 314.

[0098] At step 506, the NEF 312 sends an Nadm_DM_Query Request to the ADM 310 to request serving AIoTF information for the AIoT device(s). The Nadm_DM_Query Request may include at least one of the AF ID, target area information, AIoT Device ID identification information, an approximate number of AIoT Devices, or other parameters. The NEF 312 may include the AIoT Device Permanent ID in the Nadm_DM_Query Request to enable the ADM 310 to retrieve the corresponding AIoTF information from a database maintained by the ADM 310.

[0099] At step 508, the ADM 310 performs optional AF authorization and verifies the AIoT device's permanent ID. Then, the ADM 310 retrieves the corresponding AIoTF ID from a database of the ADM 310. The ADM 310 may verify the AIoT Device Permanent ID received from the NEF 312 to confirm that the AIoT Device is registered in the network and has associated profile data. Upon successful verification, the ADM 310 may retrieve the last known AIoTF information from the AIoT device profile data stored in the database.

[0100] At step 510, the ADM 310 sends an Nadm_DM_Query Response message to the NEF 312, including the corresponding serving AIoTF information. The serving AIoTF information may include at least one of the AIoTF ID, the AIoTF name, the FQDN, the IP address, the identifier of the AIoTF 308, or other parameters for the AIoTF selection. The NEF 312 may use the received AIoTF information to identify the AIoTF 308 that previously served the AIoT device.

[0101] At step 512, the NEF 312 sends an Naiotf_AIoT_Inventory Request to the AIoTF 308. Upon receiving the AIoTF ID or any identifier that identifies the AIoTF 308 from the ADM 310, the NEF 312 may select the AIoTF 308 indicated by the ADM 310 and forward the inventory request to the selected AIoTF 308.

[0102] At step 514, the process 500 includes performing the inventory procedure as specified in TS 23.369. The AIoTF 308 may proceed with the inventory procedure by communicating with the AIoT RAN 304 and the AIoT Device 302 to obtain inventory information from the AIoT Device 302.

[0103] At step 516, the AIoTF 308 sends the Naiotf_AIoT_Inventory Response / Notify to the NEF 312 upon completion of the inventory procedure. The Naitof_AIoT_Inventory Response / Notify may include inventory results obtained from the AIoT Device 302 during the inventory procedure.

[0104] At step 518, the NEF 312 sends an Nnef_AIoT_Inventory Response / Notify to the AF 314 to complete process 500. The Nnef_AIoT_Inventory Response / Notify may include the inventory results to be provided to the AF 314.

[0105] In some cases, the NEF 312 may store the last contacted or registered AIoTF for a given one or more AIoT device IDs. The NEF 312 may store the last contacted or registered AIoTF when the NEF 312 contacts the AIoTF 308 and completes at least one service operation. Using this memorized operation, the NEF 312 may perform the AIoTF selection when the NEF 312 has to perform a service request, such as a command or inventory operation. The memorized operation may enable the NEF 312 to select the AIoTF 308 without querying the ADM 310 when the NEF 312 has previously completed a service operation with the AIoTF 308 for the same AIoT device.

[0106] FIG. 6 illustrates a sequence diagram illustrating a process 600 for handling selection of the AIoTF and Base Station (BS) reader, in accordance with an embodiment of the present disclosure. The process 600 includes the AF 314, the NEF 312, the ADM 310, and the AIoTF 308. Process 600 demonstrates the interaction flow between these network elements during BS reader selection for AIoT service operations.

[0107] At step 602, the ADM 310 stores AIoT device profile data, including BS reader ID. The AIoT device profile data may include the AIoT Device Permanent ID that uniquely identifies the AIoT Device, last known AIoTF information that indicates the last known AIoTF that serves the AIoT device, and last known BS reader information that indicates the reader to use for the service request. The BS reader ID may enable identification of the specific reader that previously served the AIoT device.

[0108] At step 604, the AF 314 sends the Nnef_AIoT_Inventory Request to the NEF 312. The Nnef_AIoT_Inventory Request may include at least one of the AF ID, target area information, AIoT Device ID identification information, the approximate number of AIoT Devices, or other parameters.

[0109] At step 606, the NEF 312 forwards the Nnef_AIoT_Inventory Request to the ADM 310. The NEF 312 may forward the request to the ADM 310 to obtain serving AIoTF information and BS reader information for the AIoT device(s) indicated in the request from the AF 314.

[0110] At step 608, the ADM 310 performs BS reader selection based on the stored AIoT device profile data. The ADM 310 may retrieve the last known BS reader information from the AIoT device profile data and may select the appropriate BS reader for the service request based on the stored BS reader ID.

[0111] At step 610, the ADM 310 sends the Nadm_DM_Query Request to the AIoTF 308. The Nadm_DM_Query Request may include the BS reader information selected by the ADM 310 based on the stored AIoT device profile data.

[0112] At step 612, the AIoTF 308 responds with the Nadm_DM_Query Response to the ADM 310. The Nadm_DM_Query Response may include confirmation of the BS reader selection or additional information related to the AIoT service operation.

[0113] At step 614, the process 600 includes performing the rest of the steps as specified in TS 23.369. The remaining procedures may follow the standard specification for completing the inventory operation between the AIoTF 308, the AIoT RAN 304, and the AIoT Device 302.

[0114] While performing the BS reader selection or AIoT RAN selection, the AIoTF 308 may query the ADM 310 to obtain the last known BS reader information and may select the appropriate BS Reader for the service request. Process 600 illustrates how the BS reader information stored in the ADM 310 may be utilized for selecting an appropriate BS reader during AIoT service operations. Any AIoTF preparing to connect to an AIoT device may use the BS reader ID stored at the ADM 310, enabling the AIoTF 308 to direct the service request to the specific BS reader that previously served the AIoT device, rather than broadcasting the request to all available BS readers.

[0115] FIGs. 7A-7B illustrate sequence diagrams depicting process FIGs. 7A-7B illustrate sequence diagrams illustrating a process for handling AIoTF selection by the NEF 312, in accordance with an embodiment of the present disclosure.

[0116] Referring to FIG. 7A, at step 702, the NRF 701 stores the AIoT Device profile along with the location information.

[0117] At step 704, the AF 314 sends the inventory request to the NEF 312. The inventory request may include at least one of the AF ID, target area information, AIoT Device identifier(s), the approximate number of devices, or other parameters. If target area information is missing, the NEF 312 may later query the ADM 310 to obtain the location information for the AIoT Device(s).

[0118] At step 706, upon receiving the inventory request, the NEF 312 sends the Nadm_DM_Query Request to the ADM 310 to obtain location information associated with the AIoT Device(s). The ADM 310 resolves location information based on the device identifier and other parameters included in the query.

[0119] At step 708, the ADM 310 resolves the 3rdGeneration Partnership Project (3GPP)-based location information for the received AIoT permanent ID and determines which AIoTF instance(s) are likely to serve the region where the AIoT Device is located.

[0120] In an embodiment, if the ADM 310 does not have current location information, the ADM 310 retrieves updated location information from the AMF 306 based on the Nadm_DM_Query Request from the NEF 312. The ADM 310 then determines the location information and any associated AIoTF information.

[0121] At step 710, the ADM 310 sends the Nadm_DM_Query Response to the NEF 312 that includes 3GPP-based location information such as Tracking Area(s), cell ID(s), or serving-area identifiers. The NEF 312 uses this location information for further discovery.

[0122] At step 712, the NEF 312 sends an Nnrf_NFDiscovery Service Request to the NRF 701. This request may include the resolved 3GPP-based location information (such as TA, cell ID, or serving area).

[0123] Referring to FIG. 7B, at step 714, the NRF 701 processes the request and identifies AIoTF instances serving that region.

[0124] At step 716, the NRF 701 responds with a Nnrf_NFDiscovery Service Response. The Nnrf_NFDiscovery Service Response may include preferred AIoTF ID and other possible parameters.

[0125] The use of the NRF 701 for discovering the AIoTF instances based on location information may enable the NEF 312 to leverage existing NF discovery mechanisms within the 5G Core network. The NRF 701 may maintain registration information for the AIoTF instances. The NRF 701 may provide discovery services to enable the NEF 312 to identify which AIoTF(s) are serving particular areas within the network. By using the NRF 701 for AIoTF discovery, the NEF 312 may obtain up-to-date information about available AIoTF instances and their serving areas.

[0126] In some cases, the NEF 312 may query a Location Management Function (LMF), a Unified Data Management (UDM), a Unified Data Repository (UDR), or any other network function as defined in 3GPP TS 23.501 to obtain the 3GPP-based location information. The 3GPP based location information may include at least one of Tracking Area Identifier(s) (TAI(s)), cell ID(s), area, location or geographical area, cell or cell ID, Tracking Area Code (TAC) or TAI, Public Land Mobile Network (PLMN), Mobile Country Code (MCC) or Mobile Network Code (MNC), Latitude or longitude, Closed Access Group (CAG) cell, or any geographical location or coordinate. The flexibility in querying different network functions for location information may enable the NEF 312 to obtain location data from the most appropriate source based on network configuration and availability.

[0127] At step 718, the NEF 312 may send the Naiotf_AIoT_Inventory Request to the AIoTF 308. The Naiotf_AIoT_Inventory Request may include internal area information. At step 720, the AIoTF 308 then triggers the inventory procedure per TS 23.369 between the AIoTF 308 and the ADM 310.

[0128] At step 722, the ADM 310 sends the Naiotf_AIoT_Inventory Response / Notify to the NEF 312.

[0129] At step 724, the NEF 312 forwards the Naiotf_AIoT_Inventory Response / Notify to the AF 314.

[0130] In an embodiment, if the ADM 310 does not have the current location information of the AIoT devices stored, based on the Nadm_DM_Query message from the NEF 312, the ADM 310 retrieves the information from the AMF 306 and provides the AIoTF information to the NEF 312.

[0131] For example, consider that the AIoTF 308 has sent an AIoT message to the AMF 306. The AMF 306 forwards the AIoT message to the AIoT RAN 304. The AIoT RAN 304 interacts with the UE and receives the response. The AIoT RAN 304 forwards the response to the AMF 306. At this point, more than one AIoTF may be connected to the AMF 306.

[0132] However, the prior art does not define how the AMF 306 selects the correct AIoTF so that the response reaches the AIoTF 308 that initiated the request.

[0133] Similarly, in a direct network architecture, the AIoTF 308 sends an AIoT message to the AIoT RAN 304. The AIoT RAN 304 then interacts with the UE and receives the corresponding response. At this point, more than one AIoTF may be connected to the AIoT RAN 304. However, the prior art does not define how the AIoT RAN 304 selects the correct AIoTF so that the response reaches the AIoTF that initiated the request.

[0134] To solve this problem, there is a need to assign a unique identifier for each transaction. This unique identifier may be assigned by the AIoTF 308, the BS reader, or the AMF 306. Using this uniquely assigned identifier, also referred to as a "Unique AIoTF Transaction ID", the AIoT RAN 304 can select the correct AMF. The AMF can then select the correct AIoTF. In a direct architecture, the AIoT RAN 304 may also directly select the correct AIoTF using the same unique identifier.

[0135] The Unique AIoTF Transaction ID or RAN / BS reader ID can be assigned by at least one of the AIoTF 308, the AIoT RAN 304, the AMF 306, or any other NF, such as NRF, ADM, or UDM, etc.

[0136] In an embodiment, the AIoTF 308 should be uniquely identifiable. Accordingly, the AIoTF 308 has to assign the Unique AIoTF Transaction ID. This assignment is important so that the AIoT RAN 304, the NEF 312, or the AF 314 can select the correct AIoTF. The mechanism to assign a unique AIoTF Transaction ID is at least one of the following, in any combination of them:

[0137] a) AIoTFs should be in different ranges: Each AIoTF is assigned a range that is different from other AIoTFs in the core network. For example, AIoTF-1 is assigned with a range of 1-1000 ID, and AIoTF-2 is assigned with a range of 1001-2000, and so on.

[0138] b) AIoTF ID (ID assigned to AIoTF itself) or any other identifier of AIoTF(e.g., FQDN / IP Address, etc.) is part of the Unique AIoTF Transaction ID e.g., correlation ID.

[0139] c) AIoTF ID or AF ID is input to derive the correlation ID.

[0140] d) RAN / BS reader ID or any other identifier of RAN / BS reader ID(e.g., FQDN / IP Address, etc.)is part of the Unique AIoTF Transaction ID.

[0141] Similarly, it's important to assign a unique RAN / BS reader ID so that it can be selected from the entity (e.g., AIoTF or AMF) that wants to select the RAN / BS reader ID. Uniqueness is maintained at least in one of the following methods in any combination:

[0142] a) RAN / BS reader ID should be in a different range: Each RAN / BS reader ID is assigned a range that is different from other RAN / BS readers in the system. e.g., core network or RAN. For example, RAN / BS reader ID-1 is assigned with a range of 1-1000 ID, and RAN / BS reader ID-2 is assigned with a range of 1001-2000, and so on.

[0143] b) RAN / BS reader ID (ID assigned to RAN / BS reader ID itself) or any other identifier of RAN / BS reader ID (e.g., FQDN / IP Address, etc.) is part of Unique RAN / BS reader ID, e.g., can be called as Transaction ID or correlation ID.

[0144] c) RAN / BS reader ID is input to derive the Unique ID.

[0145] d) AIoTF ID or any other identifier of AIoTF ID (e.g., FQDN / IP Address, etc.) is part of the Unique RAN / BS reader ID.

[0146] AIoTF ID or any other identifier of AIoTF ID (e.g., FQDN / IP Address, etc.) is part of the Unique RAN / BS reader ID.

[0147] In an embodiment, to ensure that each transaction between the AIoT RAN 304 and the UE is uniquely identifiable, the AIoT RAN 304 inserts a unique identifier, such as a transaction ID or a correlation ID, into every AIoT message it sends to the UE. When the UE responds, it includes the same transaction ID provided by the AIoT RAN 304. This allows the AIoT RAN 304, upon receiving the response, to correctly correlate the message with the corresponding transaction.

[0148] For example, the AIoT RAN 304 sends a Command Request message together with Transaction ID 1. The RAN sends an Inventory Request message together with Transaction ID 2. When responding to the Command Request message, the UE includes Transaction ID 1 or a procedure-specific transaction identity derived from Transaction ID 1, allowing the AIoT RAN 304 to match the response to the correct request. Similarly, when responding to the Inventory Request message, the UE includes Transaction ID 2 or a procedure-specific transaction identity derived from Transaction ID 2, ensuring the response is associated with the correct Inventory Request.

[0149] FIG. 8 illustrates a flow diagram depicting a method 800 for identifying the AIoTF 308 by the NEF 312 in the wireless communication system 300, in accordance with an embodiment of the present disclosure. At step 802, the method 800 includes receiving the service operation request. The service operation request indicates at least one of an AF Identifier (ID) or an AIoT Device Permanent ID corresponding to one or more AIoT devices. The service operation request is one of an Nnef_AIoT_Inventory Request and an Nnef_AIoT_Command Request.

[0150] At step 804, the method 800 includes transmitting the Nadm_DM_Query Request message corresponding to the service operation request, to request serving AIoTF information for the one or more AIoT Devices. The Nadm_DM_Query Request message comprises at least one of the AF ID or the AIoT Device Permanent ID.

[0151] At step 806, the method 800 includes receiving the Nadm_DM_Query Response message. The Nadm_DM_Query Response message includes the last known AIoTF information for at least one of the one or more AIoT Devices.

[0152] At step 808, the method 800 includes identifying, for the at least one AIoT device, the AIoTF based on the last known AIoTF information.

[0153] FIG. 9 illustrates a block diagram of a system 900 for handling AIoTF service requests in the wireless communication system 300, in accordance with an embodiment of the present disclosure. In an embodiment, the system 900 may correspond to the ADM 310.

[0154] The system 900 may include one or more processors 902 (hereinafter referred to as the processor 902), a memory 904, one or more modules 906, and a communication interface 408. The one or more processors 902 may be operatively coupled to the memory 904, the modules 906, and the communication interface 408.

[0155] In one embodiment, the processor 902 may include at least one data processor for executing processes in a Virtual Storage Area Network. The processor 902 may include specialized processing units such as integrated system (bus) controllers, memory management control units, floating point units, graphics processing units, digital signal processing units, etc. In one embodiment, the processor 902 may include a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), or both. The processor 902 may be one or more general processors, Digital Signal Processors (DSPs), application-specific integrated circuits, Field-Programmable Gate Arrays (FPGAs), servers, networks, digital circuits, analog circuits, combinations thereof, or other now known or later developed devices for analyzing and processing data. The processor 902 may execute a software program, such as code generated manually (i.e., programmed), to perform the desired operation. The processor 902 may implement various techniques, such as, but not limited to, image processing, data extraction, Artificial Intelligence (AI), Machine Learning (ML), Deep Learning (DL), and so forth, to achieve the desired objective.

[0156] In one embodiment, the processor 902 may be configured to perform the functions of the system 900 / the ADM 310.

[0157] The processor 902 may be disposed in communication with one or more Input / Output (I / O) devices, such as the AIoTF 308, the NEF 312, etc., via the communication interface 408. The interface 408 may employ communication Code-Division Multiple Access (CDMA), High-Speed Packet Access (HSPA+), Global System For Mobile Communications (GSM), Long-Term Evolution (LTE), 5G, Sixth Generation (6G), WiMax, or the like, etc.

[0158] In an embodiment, the processor 902 may be disposed in communication with a communication network via a network interface. In an embodiment, the network interface may be the communication interface 408. The network interface may connect to the communication network to enable connection of the system 900 with the outside environment and / or device / system. The network interface may employ connection protocols, including, without limitation, direct connect, Ethernet (e.g., twisted pair 10 / 300 / 3000 Base T), Transmission Control Protocol / Internet Protocol (TCP / IP), token ring, IEEE 802.11 / b / g / n / x, etc. The communication network may include, without limitation, a direct interconnection, Local Area Network (LAN), Wide Area Network (WAN), wireless network (e.g., using Wireless Application Protocol (WAP)), the Internet, etc. Using the network interface and the communication network, the system 900 may communicate with other devices. The network interface may employ connection protocols including, but not limited to, direct connect, Ethernet (e.g., twisted pair 10 / 300 / 3000 Base T), TCP / IP, token ring, IEEE 802.11 / b / g / n / x, etc.

[0159] The memory 904 may be communicatively coupled to the processor 902. The memory 904 may be configured to store data and instructions executable by the processor 902. In one embodiment, the memory 904 may communicate via a bus within the system 900. The memory 904 may include, but is not limited to, a non-transitory computer-readable storage media, such as various types of volatile and non-volatile storage media including, but not limited to, random access memory, read-only memory, programmable read-only memory, electrically programmable read-only memory, electrically erasable read-only memory, flash memory, magnetic tape or disk, optical media and the like. In one example, the memory 904 may include a cache or random-access memory for the processor 902. In alternative examples, the memory 904 is separate from the processor 902, such as a cache memory of a processor, the system memory, or other memory. The memory 904 may be an external storage device or database for storing data. The memory 904 may be operable to store instructions executable by the processor 902. The functions, acts, or tasks illustrated in the figures or described may be performed by the programmed processor 902 for executing the instructions stored in the memory 904. The functions, acts, or tasks are independent of the particular type of instruction set, storage media, processor, or processing strategy, and may be performed by software, hardware, integrated circuits, firmware, micro-code, and the like, operating alone or in combination. Likewise, processing strategies may include multiprocessing, multitasking, parallel processing, and the like. The memory 904 may further include a database to store the data. Further, the memory 904 may include an operating system for performing one or more tasks of the system 900, as performed by a generic operating system in the communications domain.

[0160] For the sake of brevity, the architecture and standard operations of the processor 902 and the memory 904 are not discussed in detail. In one embodiment, the memory 904 may be configured to store the information as required by the processor 902 to perform the techniques described herein.

[0161] The modules 906, amongst other things, include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement data types. The modules 906 may also be implemented as signal processor(s), state machine(s), logic circuitries, and / or any other device or component that manipulates signals based on operational instructions. The modules 906 may be configured to one or more operations of the system 900 and / or the processor 902.

[0162] Further, the modules 906 can be implemented in hardware, instructions executed by a processing unit, or by a combination thereof. The processing unit can comprise a computer, the processor 902, a state machine, a logic array, or any other suitable devices capable of processing instructions. The processing unit can be a general-purpose processor that executes instructions to cause the general-purpose processor to perform the required tasks, or the processing unit can be dedicated to performing the required functions. In another embodiment of the present disclosure, the modules 906 may be machine-readable instructions (software) that, when executed by a processor / processing unit, perform any of the described functionalities. Furthermore, the data serves, amongst other things, as a repository for storing data processed, received, and generated by one or more of the modules. The modules 906 may include a receiving module 910, a retrieving module 912, and a transmitting module 914.

[0163] The receiving module 910 may be configured to receive, from the NEF 312, an Nadm_DM_Query Request message. The Nadm_DM_Query Request message may include an Application Function (AF) Identifier (ID) and an AIoT Device Permanent ID corresponding to one or more AIoT devices connected to the AF 314. For example, when the NEF 312 receives an AIoT service operation request from the AF 314 that includes an AIoT Device Permanent ID but does not include target area information, the NEF 312 may send an Nadm_DM_Query Request message to the ADM 310. The receiving module 910 of the ADM 310 may receive the Nadm_DM_Query Request message containing the AF ID and the AIoT Device Permanent ID to enable the ADM 310 to retrieve the corresponding AIoTF information.

[0164] As further shown in FIG. 9, the retrieving module 912 may be configured to retrieve, from a database, AIoTF information associated with the one or more AIoT devices. For example, when the ADM 310 receives the Nadm_DM_Query Request message containing the AIoT Device Permanent ID, the retrieving module 912 may access a database maintained by the ADM 310 and retrieve the last known AIoTF ID associated with the AIoT Device Permanent ID. The database may store AIoT device profile data that includes the AIoT Device Permanent ID and last known AIoTF information for each AIoT device managed by the network. The retrieving module 912 may verify the AIoT Device Permanent ID received from the NEF 312 and retrieve the corresponding AIoTF information upon successful verification.

[0165] With continued reference to FIG. 9, the transmitting module 914 may be configured to transmit an Nadm_DM_Query Response message to the NEF 312. The Nadm_DM_Query Response message may include the AIoTF information retrieved by the retrieving module 912. For example, the ADM 310 may respond to the NEF 312 with the Nadm_DM_Query Response message containing at least one of an AIoTF ID, an AIoTF name, a Fully Qualified Domain Name (FQDN), or an Internet Protocol (IP) address of the AIoTF that previously served the AIoT device. The transmitting module 914 may transmit the Nadm_DM_Query Response message to enable the NEF 312 to identify and select the appropriate AIoTF 308 for the AIoT service operation.

[0166] The receiving module 910 may be further configured to receive updated AIoT device profile data from the corresponding AIoTF 308 using an Nadm_DM_Update service operation upon completion of at least one service operation by the AIoTF 308 based on the AIoT Device Permanent ID. The AIoT device profile data may comprise the last known AIoTF information. For example, when the AIoTF 308 completes an inventory or command service operation for an AIoT device, the AIoTF 308 may send an Nadm_DM_Update message to the ADM 310 to update the AIoT device profile data with the current AIoTF information. The receiving module 910 may receive the Nadm_DM_Update message and store the updated AIoT device profile data in the database.

[0167] As further shown in FIG. 9, the retrieving module 912 may retrieve the AIoTF information based on the updated AIoT device profile data. By receiving updated AIoT device profile data from the AIoTF 308 upon completion of service operations, the ADM 310 may maintain up-to-date AIoTF information for accurate selection. The updated AIoT device profile data may enable the ADM 310 to provide the current last known AIoTF information to the NEF 312 in subsequent Nadm_DM_Query Response messages, thereby enabling the NEF 312 to select the most recently serving AIoTF 308 for future AIoT service operation requests.

[0168] FIG. 10 illustrates a flow diagram depicting a method 1000 for handling AIoTF service requests in the wireless communication system 300, in accordance with an embodiment of the present disclosure. At step 1002, the method 1000 includes receiving the Nadm_DM_Query Request message. The Nadm_DM_Query Request message includes the Application Function (AF) Identifier (ID) and the AIoT Device Permanent ID corresponding to one or more AIoT devices connected to the AF.

[0169] At step 1004, the method 1000 includes retrieving, from a database, AIoTF information associated with the one or more AIoT devices.

[0170] At step 1006, the method 1000 includes transmitting the Nadm_DM_Query Response message to the NEF 312. The Nadm_DM_Query Response message includes the AIoTF information.

[0171] In a further embodiment, the present disclosure relates to a system and method for configuring a User Equipment (UE) to transfer standardized data for Artificial Intelligence / Machine Learning (AI / ML) enhancement. The present disclosure involves an AI / ML service entity (AI / ML server) to which the UE communicates and uploads standardized data over the User Plane (UP). This enables AI / ML-driven enhancement at the AI / ML server by storing, hosting, aggregating, analyzing, and processing the uploaded UE data to refine AI / ML models, trigger network actions, or perform model training. The UE is configured with parameters provided by network functions such as Access and Mobility Management Function (AMF), Session Management Function (SMF), User Plane Function (UPF), Unified Data Management (UDM), or similar entities in the core network, Operations Administration and Maintenance (OAM), or Radio Access Network (RAN) nodes like eNodeB (eNB) or gNodeB (gNB). The OAM address (IP or FQDN) is pre-configured in the UE, which retrieves necessary configuration information to establish the required Protocol Data Unit (PDU) session. The UE sends a request to the OAM to fetch configuration details, including location, PLMN IDs, time slots for data upload, and intention to send data. The OAM responds with security credentials, server configurations, allowed areas and time windows for communication, and traffic descriptors. The configuration information can be pre-configured in the UE or provided by the serving or home PLMN. If the UE cannot obtain the necessary configuration, it will not upload standardized data. The disclosure allows for flexible and efficient AI / ML model enhancement using UE data in New Radio (NR) air interface operations.

[0172] In an embodiment, the present disclosure pertains to a wireless system, such as 5G with satellite access, which must meet specific requirements. The 5G system shall support service continuity between NR terrestrial access networks and NR satellite access networks, whether owned by the same operator or by two different operators with an agreement. The Non-Terrestrial Network (NTN) and Terrestrial Network (TN) may operate in either different frequency bands (e.g., Frequency Range 1 (FR1) vs. FR2) or the same frequency band (e.g., FR1 or FR2).

[0173] The terms Satellite 3GPP access, Satellite access, Satellite Access Network, NR Satellite Access Network, Satellite NG-RAN Access Technology, and NR Satellite access are used interchangeably and have the same meaning. Methods, issues, or solutions disclosed herein are explained using NR satellite access or Satellite NG-RAN Access Technology as examples. However, the solutions are not restricted to NR Satellite access only; they are also applicable to Satellite E-UTRAN access Technology, including NB (Narrow Band)-S1 mode or WB (Wide Band)-S1 mode via Satellite E-UTRAN access and / or NB-IOT (NarrowBand Internet Of Things) or WB-IOT (WideBand Internet Of Things) Satellite Access / Architecture.

[0174] The term data and standardized data are used interchangeably and are for same purpose.

[0175] Solutions defined for NR (5GC) are also applicable to legacy RATs like E-UTRA / LTE. The corresponding CN entities need to be replaced by LTE entities, such as AMF with MME, gNodeB with eNodeB, UDM with HSS, etc. However, the principles of the solution remain the same.

[0176] An example list of NAS messages includes, but is not limited to, REGISTRATION REQUEST message, the DEREGISTRATION REQUEST message, the SERVICE REQUEST message, the CONTROL PLANE SERVICE REQUEST, the IDENTITY REQUEST, the AUTHENTICATION REQUEST, the AUTHENTICATION RESULT, the AUTHENTICATION REJECT, the REGISTRATION REJECT, the DEREGISTRATION ACCEPT, the SERVICE REJECT, the SERVICE ACCEPT, and so on.

[0177] Any 5G Core Network Function, such as AMF, is used to explain the network herein. The network could be any 5G / EUTRAN Core Network Entities like AMF / SMF / MME / UPF, or it could be any 5G / EUTRAN RAN Entity like eNB, gNB, or NG-RAN, etc.

[0178] Messages used or indicated herein are shown as examples. These messages could be any signalling messages between the UE and the Network Functions / Entities or between different Network functions / entities.

[0179] The terms "camp" and "register" are used interchangeably and have the same meaning.

[0180] The term "area" as used herein may refer to any of the following: cell / cell ID, TAC / TAI, PLMN, MCC / MNC, Latitude / longitude, any CAG / CAG identifier, or any geographical location / coordinate.

[0181] For the list of possible NAS messages, please refer to 3GPP TS 24501 or 3GPP TS 24301. For the list of AS messages, please refer to 3GPP TS 38331 or 3GPP TS 36331.

[0182] Cause names herein are for illustration purposes and can have any name. The non-access stratum (NAS) messages and access stratum (AS) messages described herein are only for illustration purposes and can be any NAS or AS messages as per the defined protocol between UE and AMF / MME or UE and gNB (NG-RAN / any RAN node) / eNB.

[0183] Further, User Route Selection Policies (URSP) are a set of policies configured in the User Equipment (UE) that assist applications running on the UE in determining the specific paths to use for sending uplink (UL) data for a matching data type. These policies enable the UE to decide how to route outgoing traffic. Traffic can be routed to an established Protocol Data Unit (PDU) session, offloaded to non-3GPP access outside a PDU session, routed via a Proximity Services (ProSe) Layer-3 UE-to-Network Relay outside a PDU session, or trigger the establishment of a new PDU session.

[0184] Each User Route Selection Policy (URSP) rule includes a Traffic Descriptor, which contains one or more components described in Table 6621-2, that determines when the rule is applicable. A URSP rule is deemed applicable when every component in the Traffic Descriptor (excluding the Personal IoT Network (PIN) ID) matches the corresponding information from the application, matches the information configured for a PIN (if the URSP rule includes a PIN ID Traffic Descriptor component), or matches the information configured for a Connectivity Group (if the URSP rule includes a Connectivity Group ID Traffic Descriptor).

[0185] When a URSP rule is provided with a Traffic Descriptor containing two or more components, it is recommended to also provide URSP rules with lower precedence and a Traffic Descriptor with fewer components. This increases the likelihood of URSP rule matching for a particular application.

[0186] Each URSP rule contains a list of Route Selection Descriptors, each having one or multiple Route Selection Descriptors with different Route Selection Descriptor Precedence values. The Route Selection Descriptor is defined as follows in Table 2.

[0187] [Table 2]

[0188]

[0189] The traffic descriptor parameters used in the embodiments herein are at least one of the following in Table 3.

[0190] [Table 3]

[0191]

[0192] In an embodiment, the network may update the UE configuration at any time using the UE Configuration Update procedure. UE configuration may include AMF-related parameters decided and provided by the AMF. This includes the Configured NSSAI and its mapping to the Subscribed S-NSSAIs, the Allowed NSSAI and its mapping to Subscribed S-NSSAIs.

[0193] The UE Policy may be provided by a Policy Control Function (PCF). When the AMF wants to change the UE configuration for access and mobility management-related parameters, the AMF initiates the procedure. The PCF initiates the procedure when the PCF wants to change or provide new UE Policies in the UE. If the UE Configuration Update procedure requires the UE to initiate a Registration procedure, the AMF indicates this to the UE explicitly.

[0194] FIG. 11 depicts a UE Configuration Update procedure 1100 for transparent UE Policy delivery, in accordance with prior art. The procedure 1100 involves several key elements, i.e., UE 1101, (R)AN 1103, AMF 1105, and PCF 1107. The sequence of interactions between these elements is crucial for updating the UE configuration.

[0195] At step 1102, the PCF 1107 decides to update the UE Policy.

[0196] At step 1104, the PCF 1107 sends Namf_Communication_N1N2MessageTransfer to the AMF 1105. This message contains the updated UE Policy information that needs to be delivered to the UE 1101.

[0197] At step 1106, the AMF 1105 initiates Network Triggered Service Request towards the UE 1101 via the (R)AN 1103. This request is essential for establishing the communication channel required for delivering the updated UE policies to the UE 1101.

[0198] At step 1108, the AMF 1105 delivers UE policies to the UE 1101. This delivery ensures that the UE 1101 is configured with the latest policy information as decided by the PCF 1107.

[0199] At step 1110, the AMF 1105 receives the result of the delivery of UE policies from the UE 1101. This result indicates whether the delivery was successful or if any issues were encountered during the process.

[0200] At step 1112, the AMF 1105 sends Namf_N1MessageNotify to the PCF 1107. This notification contains the outcome of the UE policy delivery, allowing the PCF 1107 to confirm that the UE configuration update has been completed.

[0201] FIG. 12 illustrates a sequence diagram representing a subscription data notification procedure 1200, in accordance with prior art. The sequence diagram depicts the flow of messages and actions that occur when subscription data changes need to be communicated within the wireless communication system 300.

[0202] The subscription data notification procedure 1200 begins with the UDM 1201 sending an Nudm_SDM_Notification message to the AMF 1105, at step 1202. The Nudm_SDM_Notification message may indicate that there has been a change in subscription data managed by the UDM 1201 that is relevant to the UE 1101. The subscription data change may include updates to service parameters, access restrictions, or other subscriber-related information maintained by the UDM 1201.

[0203] With continued reference to FIG. 12, upon receiving the Nudm_SDM_Notification message from the UDM 1201, at step 1204, the AMF 1105 initiates communication with the UE 1101 by sending a DL NAS TRANSPORT message. The DL NAS TRANSPORT message may be a downlink Non-Access Stratum transport message that conveys relevant information from the network to the UE 1101. The DL NAS TRANSPORT message may carry the subscription data change information or instructions related to the subscription data update.

[0204] At step 1206, the UE 1101 responds to the AMF 1105 with a UL NAS TRANSPORT message. The UL NAS TRANSPORT message may be an uplink Non-Access Stratum transport message that carries the UE's response back through the network. The UL NAS TRANSPORT message may include acknowledgment of the received subscription data information or other response data from the UE 1101.

[0205] As further shown in FIG. 12, following the exchange with the UE 1101, at step 1208, the AMF 1105 sends an Nudm_SDM_Info message to the UDM 1201. The Nudm_SDM_Info message may provide information back to the UDM 1201 regarding the outcome of the notification procedure. The Nudm_SDM_Info message may indicate whether the subscription data notification was successfully delivered to the UE 1101 and whether the UE 1101 acknowledged the notification.

[0206] Further, at step 1210, the UE 1101 may initiate re-registration if requested by the UDM 1201. The re-registration may occur based on the content of the subscription data notification and may represent a scenario where the UDM 1201 requires the UE 1101 to perform a new registration procedure to update the network registration status of the UE 1101 based on the changed subscription data. The re-registration procedure may enable the network to apply the updated subscription data to the UE's active session and services.

[0207] The solutions defined for New Radio (NR) within a 5G Core (5GC) network may also apply to legacy Radio Access Technologies (RATs) such as Evolved Universal Terrestrial Radio Access (E-UTRA) and Long Term Evolution (LTE). When applying the solutions to legacy RATs, corresponding core network entities may be replaced by LTE entities. For example, the AMF may be replaced by a Mobility Management Entity (MME), a gNodeB may be replaced by an eNodeB, and the UDM may be replaced by a Home Subscriber Server (HSS). The principles of the solutions may remain the same when applied to legacy RATs, with the network entity replacements enabling compatibility with existing LTE network deployments.

[0208] In an embodiment, the configurations regarding the server include at least one of the following, or any combination thereof, provided by network functions (NF) such as AMF, Session Management Function (SMF), User Plane Function (UPF), UDM, or similar entities in the core network, Operations, Administration, and Maintenance (OAM), or RAN nodes like Evolved NodeB (eNB) or gNodeB (gNB). These configurations can be communicated using at least one of the AS messages, NAS messages, or data paths (to be defined).

[0209] The configurations may include IP address of the server, FQDN of the server, Data Network Name (DNN) to be used for Protocol Data Unit (PDU) session establishment, Single Network Slice Selection Assistance Information (S-NSSAI) to be used for PDU session establishment, Allowed area (as defined in an embodiment) where the UE is permitted to connect to the server, Allowed time during which the UE is permitted to connect to the server, and Allowed Visited Public Land Mobile Network (VPLMN) or Home Public Land Mobile Network (HPLMN) (on which the UE is camped or registered) where the UE is permitted to connect to the server.

[0210] The network (HPLMN or VPLMN) and gNB / Central Node (CN) can explicitly indicate in at least one Access Stratum (AS) message or Non-Access Stratum (NAS) message whether the UE is allowed to send data to the AI / ML server. Only if the UE is allowed to send data will it connect to the server and upload data to the AI / ML server. If the UE is not configured with the server details, it shall not upload standardized data over UP for UE data collection to meet requirements for AI / ML for NR air interface operation with UE-side model training.

[0211] The UE may trigger NAS procedures such as the registration request procedure, UCU procedure, or session management procedure, and indicate to the network function (e.g., AMF, SMF, or OAM) that it needs the server configuration details. Optionally, this can be done for the currently camped / registered Public Land Mobile Network (PLMN). In response to this request, the network function / OAM / AF will configure the server details.

[0212] The URSP-related aspects include the configuration of Time Division (TD) in the UE, allowing the UE to select the Route Selection Descriptor (RSD) part to choose the PDU session parameters to connect to the AI / ML server.

[0213] The integration of Artificial Intelligence (AI) and Machine Learning (ML) into 5G New Radio (NR) necessitates mechanisms to upload standardized data over the User-Plane (UP) for User Equipment (UE) data collection. This is essential to meet the requirements for AI / ML in NR air interface operations and to enable AI / ML-driven enhancements in 5G networks. The current 5G Core (5GC) architecture lacks a dedicated UP data collection framework optimized for AI / ML requirements and use cases. The interaction between UE and network entities, including any message exchanges to support AI / ML enhancements, needs to be defined. Additionally, the configuration of the UE with information to support AI / ML enhancements requires clarification. It is not known whether and how a UE can fulfil AI / ML requirements for a specific Public Land Mobile Network (PLMN) or a group of PLMNs. The geographical scope, whether it pertains to a particular area or is applicable everywhere, is also undefined. Furthermore, the temporal aspect, whether it applies to a specific time window or all the time, remains uncertain.

[0214] Accordingly, the present disclosure provides a solution to the above-discussed and other related problems.

[0215] In an embodiment, the disclosed techniques require having an AI / ML service entity (such as an AI / ML server) to which the UE communicates and uploads the standardized data over UP. This enables the AI / ML-driven enhancement at the AI / ML server by storing and hosting the AI / ML models, aggregating, analyzing, and processing the uploaded UE standardized data to refine the model, trigger network actions, or perform model training.

[0216] The UE communicates with the AI / ML server based on the configuration parameters provided to the UE. It is proposed that all necessary information with respect to the configuration of a UE to connect to the AI / ML server on how, where, when, for which PLMNs, etc., can be provided by NF, like AMF / SMF / UPF / UDM or similar entities in the core network, or the OAM or the RAN node, like eNB or gNB, using at least one of the AS messages or NAS messages or using data path or broadcast messages.

[0217] The OAM address, for example, IP address, FQDN, etc., will be pre-configured in the UE. This can be configured by means of NAS or other signalling messages from the home network or serving network to UE pre-configuration in SIM / USIM or other mechanisms where the address is sent over the air from OAM to UE.

[0218] The UE reaches out to the required IP address / FQDN to retrieve the required configuration-related information. The DNN S-NSSAI used to establish the required PDU session is derived from the URSP rules configured in the UE.

[0219] To get the necessary information, the UE sends a request to the OAM to fetch the information and provides the following parameters in the request:

[0220] a. Location of the UE could be TA / cell / CAG / area / geolocation of the UE. This could be different / same for different PLMNs. For example, the UE could indicate information such as the TA location, i.e., PLMN-A TAC-A cell-ID A or geo-location, which will be geo-location coordinates.

[0221] b. At least one or more PLMN ID(s) where the UE is registered.

[0222] c. Time duration or specific slots of time during which the UE can upload UP data. This could be different / same for different PLMNs. For example, UE can indicate a specific date and time, such as 20th June 2025, 4 pm to 10 pm of the day, or periodic timestamps such as 20th June 2025 to 20th July 2025, 10 am to 5 pm every day, etc.

[0223] d. Intention of the UE to send the standardized data over UP or the support of this feature.

[0224] The OAM responds to the above request based on the inputs of Request, local configuration, and operator policy, and includes at least one of the following pieces of information for the UE:

[0225] a. Security credentials if there is a security gateway between the UE and the AI / ML server.

[0226] b. The configurations of the AI / ML server accept or reject based on information provided by the UE.

[0227] c. Area where the UE can communicate to the server and update the UP data, or optionally area where the UE cannot upload the UP data (restricted or non-allowed area). For example, if the OAM indicates that the UE can communicate with the server and upload standardized data in allowed areas, it uploads standardized data only in the allowed area and does not communicate with the server in the restricted or non-allowed area.

[0228] d. Time window for which the UE can communicate (i.e., allowed time window) or cannot communicate (i.e., restricted or non-allowed time window) to the server. For example, if the allowed time window / validity indicates 20th June 10 am to 5 pm of the day, the UE can only communicate and upload standardized data to the server during 20th June 10 am to 4 pm of the day, and does not communicate with the server at any other time.

[0229] e. The one or more PLMN(s) for which the UE is allowed to communicate and upload standardized data to the server, or PLMNs for which the UE is strictly not allowed to communicate and upload standardized data to the server. For example, if allowed PLMN(s) are PLMN-A and PLMN-B, then the UE can communicate and upload standardized data to the server only for these 2 PLMNs.

[0230] f. The traffic descriptor of URSP rules configured in the UE to select the correct DNN, S-NSSAI, or the PDU session (i.e., already established PDU session / a new PDU session) to communicate to the server.

[0231] g. Optionally, all the required information from step 5 can be:

[0232] a. Configured / pre-configured in the UE;

[0233] b. Configured / Pre-configured by the serving PLMN in the UE using at least one of the NAS messages or the AS, i.e., PLMN the UE is registered to;

[0234] c. Configured / Pre-configured by HPLMN / E-HPLMN of the UE using a secure message sent from HPLMN, which is transparently sent to the UE. E.g., using the UPU procedure or the UCU procedure;

[0235] If the UE cannot get this necessary configuration information (i.e., this is not stored in the UE) about the server details / cannot reach out to the OAM server / rejected, then the UE shall not upload standardized data over UP for UE data collection to meet requirements for AI / ML for NR air interface operation with UE-side model training.

[0236] The OAM in this solution / embodiment is described only for illustration purposes. The UE can connect to any other server, NF, or RAN node to fetch the parameters listed above to receive the configuration of the server details. In yet another embodiment, this information can be pushed into the UE by CN, OAM, or RAN without the UE making any request.

[0237] All the above information in step 5 can be configured, pre-configured, or provided on a per PLMN basis, a group of PLMNs (multiple PLMN IDs), or equivalent PLMNs.

[0238] In an embodiment, the configurations about the server details (e.g., AI / ML server details) are at least one of the following or in any combination below:

[0239] -　IP address of the server,

[0240] -　FQDN of the server,

[0241] -　DNN to be used for PDU session establishment,

[0242] -　S-NSSAI to be used for PDU session establishment, allowed area (term as defined in an embodiment) where the UE is allowed to connect to the server and upload the data,

[0243] -　allowed time where the UE is allowed to connect to the server and upload the data, and

[0244] -　allowed VPLMN or HPLMN (on which the UE is camped or registered with), where the UE is allowed to connect to the server and upload the data.

[0245] Based on the above configuration parameters, the UE decides how, when, and where the UE should upload the data or not upload the data.

[0246] In an embodiment, to receive the configuration details about the server (e.g., AI / ML server), the UE may also trigger any NAS procedure, like registration request procedure, UE Configuration Update (UCU) procedure, or session management procedure, and indicate to the network function (e.g., AMF or SMF) that it needs the configurations about the server details. In response to this request, the network function will configure the configurations about the server details (e.g., AI / ML server details). Any network function like AMF / SMF / UPF / UDM / PCF or similar in the core network, or the OAM, or the RAN node like eNB or gNB using at least one of the AS message or NAS message, or using the data path, can provide the UE with configuration details necessary to connect to the AI / ML server.

[0247] The OAM in an embodiment is described only for illustration purposes. UE can connect to any other server, NF, or RAN node to fetch the parameters listed above to receive the configuration of the server details. In yet another embodiment, this information can be pushed into the UE by CN, OAM, or RAN without the UE making any request.

[0248] In an embodiment, configurations about the server details (e.g., AI / ML server details) are received either in NAS messages like 5GMM, 5GSM, or PCO / ePCO in 5GSM messages, etc.

[0249] The configurations about the server details can be configured or pre-configured in the SIM / USIM / ESIM or ME or UE.

[0250] These DNN / S-NSSAI parts of the configurations about the server details may be configured in the UE in URSP rules. One or more UE DNNs may be added to the DNN selection list in the Route Selection Descriptor (RSD), and / or one or more UE N-SSAI may be added to the Network Slice Selection list in the Route Selection Descriptor, i.e., the Traffic descriptor (one or more parameters) part of URSP rules is configured such that the UE selects the RSD component to determine the PDU session parameters to establish the PDU session over which the UE uploads the standardized data.

[0251] In yet another embodiment, these UE DNN and / or S-NSSAI parts of configurations may be explicitly configured and / or pre-configured in the SIM / USIM / ESIM and / or ME and / or UE. In yet another embodiment, these configurations about the server details can be explicitly configured using at least one of the NAS / AS messages and / or pre-configured in the UE. Optionally, these configurations can be configured per PLMN and / or per PLMN per area per time and / or per PLMN per area and / or per PLMN per time. The PLMN can be VPLMN or HPLMN.

[0252] In yet another embodiment, the UE connects to an OAM server over the data path (i.e., through PDU session connectivity), which provides the configurations about the server details (e.g., AI / ML server details). The details to connect to such an OAM server can be at least one of the following:

[0253] -　IP address of the server.

[0254] -　FQDN of the server.

[0255] -　DNN to be used for PDU session establishment.

[0256] -　S-NSSAI to be used for PDU session establishment.

[0257] -　Allowed area (term as defined in the embodiments herein) where UE is allowed to connect to the server.

[0258] -　Allowed time where UE is allowed to connect to the server.

[0259] -　Allowed VPLMN or HPLMN (on which the UE is camped or registered with) where the UE is allowed to connect to the server.

[0260] If OAM server details to fetch configurations about the server details are not available, then UE should not upload standardized data on the AI / ML server. The details to connect to such a server over the data path can be provided to the UE following the same mechanisms as described herein to provide the configurations about the server details (e.g., AI / ML server details), i.e., either in NAS messages like 5G Mobility Management (5GMM), 5G Session Management (5GSM), or Protocol Configuration Options (PCO) / Extended Protocol Configuration Options (ePCO) in 5GSM messages, etc.

[0261] At least one of the following traffic descriptor parameters is configured in the UE with an indication that this is an AI / ML server app. Details within the UE or access stratum part transfer the collected standardized data to the respective app in the UE. Then the app initiates the transfer of the data using the data path that uses the PDU session / user plane resources as discussed herein. The parameters can be provided in priority order.

[0262] FIG. 13 is a sequence diagram 1300 depicting an AI / ML server configuration at UE via OAM, in accordance with an embodiment of the present disclosure.

[0263] At step 1302, the UE 1301 sends a registration request to the AMF 1305.

[0264] At step 1304, the OAM 1309 share address with the AMF 1305 and the SMF 1307.

[0265] At step 1306, the AMF 1305 sends a Registration Accept message and the OAM address to the UE 1301. Optionally, at step 1306a, the OAM address may be pre-configured in the UE 1301.

[0266] At step 1308, the UE 1301 sends PDU ESTABLISHMENT REQUEST, with correct DNN / S-NSSAI from URSP.

[0267] At step 1310, the UE 1301 receives PDU ESTABLISHMENT ACCEPT. Hence, the UE 1301 is connected to the OAM 1309 to fetch the required configuration. Further, if the UE 1301 is not configured with AI / ML server details, the UE 1301 proceeds to fetch the configuration.

[0268] At step 1312, the UE 1301 sends an OAM request or other signalling. The signalling may include the following:

[0269] a. Location of the UE 1301. The location could be TA / cell / geolocation of the UE, where the UE wants upload standardized data;

[0270] b. The PLMN ID where the UE 1301 is registered;

[0271] c. Time, duration Serving PLMN ID / set of PLMN IDs in which the UE 1301 wants to connect to the server and upload standardized data; and

[0272] d. Specific slots of time during which the UE 1301 wants to connect to the server and upload standardized data.

[0273] At step 1314, the UE 1301 is not configured with the details of the AI / ML server 1311.

[0274] At step 1316, the UE 1301 receives OAM response or some other signalling based on the at least one parameter received with: Security credentials if there is a security gateway between UE 1301 and AI / ML server 111; Authorization, accept or reject based on information provided by the UE 101; Area where the UE 1301 connect to the server and upload standardized data; Time window for which the UE 1301 connect to the server and upload standardized data; The PLMN(s) where the UE 101 can connect to the server and upload standardized data; and The traffic descriptor of URSP rules configured in the UE 1301 to select correct DNN, S-NSSAI to connect to AI / ML server 1311.

[0275] At step 1318, the UE 1301 is configured with the details of the AI / ML server 1311.

[0276] At step 1320, the UE 1301 connects to the AI / ML server 1311 as per the configuration provided by the network and uploads standardized data for AI / ML requirements.

[0277] The OAM 1309 in this embodiment is described only for illustrative purposes. The UE 1301 can connect to any other server, NF, or RAN node to fetch the parameters listed above to receive the configuration of the server details. In yet another embodiment, this information can be pushed into the UE by CN, OAM, or RAN without the UE making any request. For example, the UE 1301 may trigger NAS procedures like registration request procedure, UCU procedure, or session management procedure. The UE 1301 may also indicate the network function (e.g., AMF, SMF, or OAM) that the UE 1301 needs the configurations for the server details. In response to this request, the network function / OAM / AF will configure the configurations about the server details.

[0278] To upload standardized data, the UE 1301 may indicate the intention / criteria to do so or indicate support of this feature (which indicates the intention / criteria of the UE to send the standardized data from the UE 1301 to the AI / ML server 1311) to at least one of the NF or to the RAN node. If the UE 1301 does not want to send the standardized data, the UE 1301 indicates that the UE 1301 will not be able to send the data. Alternatively, the UE 1301 indicates the feature is not supported by at least one of the NF, like AMF / SMF / UPF / PCF / UDM or any other NF using at least one of the NAS message or to the eNB / gNB using at least one of the AS message.

[0279] In an embodiment, the criteria can be at least one of the time when the UE 1301 can send the data, the location where the UE 1301 can send the data, PLMN(s) over which the UE 1301 can send the data, HPLMN over which the UE 1301 can send the data, or on a specific event.

[0280] The CN, based on the received intention / support indication from the UE 1301, or based on local configuration, or based on subscription (as stored in the HSS / UDM / UDR), or any combination of them, determines whether the UE should be allowed / requested or not allowed / not requested to upload the standardized data. The CN indicates the determination (allowed / requested or not allowed / not requested) to the UE (using at least one of the NAS message or the AS message) and to the RAN node (e.g., eNB or gNB).

[0281] The RAN node based on UE indication of intention / criteria or indication of the support of this feature or based on the CN determination of allowed / requested or not allowed / not requested or based on local configuration or based on subscription (as stored in the HSS / UDM / UDR) or any combination of them determines whether UE should be allowed / requested or not allowed / not requested to upload the standardized data. The RAN indicates the determination (allowed / requested or not allowed / not requested) to the UE (using at least one of the AS messages) to the UE or the CN. The RAN node, if it determines that the UE is allowed / requested to upload the data, then the RAN node configures in the UE the RAN configuration, indicating to the UE what type of data or events the UE has to upload to the AI / ML server.

[0282] The CN may indicate to the UE that upload of data is allowed only on the HPLMN or specific one or more PLMN IDs, or this information can be pre-configured / configured in the Subscriber Identity Module (SIM) / Universal SIM (USIM) / Embedded SIM (ESIM) / Mobile Equipment (ME), based on which the UE 1301 determines which PLMNs the UE can upload the standardized data.

[0283] In summary, the UE 1301 indicates its intention / support indication to CN / RAN, CN / RAN determines if UE 1301 is allowed to upload the data based on this determines CN / RAN indicates to the UE 1301 whether it is allowed to send (also called as upload) the data or criteria or what type of data the UE 1301 has to upload to the server. Based on these indications / parameters, the UE 1301 decides whether it is allowed to upload the data, and when and what to upload.

[0284] In an embodiment, the purpose of connecting to the server is to upload the data (also called standardized data).

[0285] In an embodiment, the term data and standardized data are used interchangeably and are for same purpose.

[0286] The data or standardized data is data sent over UP for UE data collection to meet requirements for AI / ML for NR air interface operation with model training (e.g., UE-side or network side).

[0287] The server / AI / ML server in this embodiment is the server where the UE 1301 uploads the standardized data.

[0288] The present disclosure may provide several advantages in the context of Ambient Internet of Things (AIoT) service operations within wireless communication systems. The methods and systems described herein may enable efficient selection of an Ambient IoT Function (AIoTF) by a Network Exposure Function (NEF) when target area information is not provided by an Application Function (AF).

[0289] One advantage of the present disclosure is that the NEF may avoid a blind search in all areas by querying an AIoT Data Management (ADM) entity with the AIoT device ID to check if the last known AIoTF information is available for the respective AIoT Device ID. By querying the ADM for the last known AIoTF information associated with a specific AIoT Device Permanent ID, the NEF may obtain targeted information about which AIoTF previously served the AIoT device. The targeted query approach may enable the NEF to identify the appropriate AIoTF without broadcasting requests to all available AIoTFs across all deployment areas.

[0290] Another advantage of the present disclosure is that if the ADM provides the AIoTF information, the NEF may use the AIoTF information to select the AIoTF efficiently. The ADM may store AIoT device profile data that includes the last known AIoTF information, and the NEF may leverage this stored information to perform accurate AIoTF selection. The efficient selection mechanism may reduce the processing overhead at the NEF and may enable faster service operation request handling.

[0291] Without the present disclosure, every time an AF triggers an AIoT request without target area information, the network may have to page throughout the system. Paging throughout the entire system may consume network resources unnecessarily and may result in inefficient network operation. The present disclosure may address this inefficiency by enabling the NEF to query the ADM for last known AIoTF information and select the appropriate AIoTF based on the query response, thereby avoiding system-wide paging when the AIoT device may be located in a single area.

[0292] The solutions described in the present disclosure may be adopted in standards, including 3GPP Technical Specification (TS) 23.369, and may be agreed upon in 3GPP TSG-WG SA2 Meeting #168. The standardization of the solutions may enable interoperability between network equipment from different vendors and may facilitate the deployment of the AIoTF selection mechanisms in commercial wireless communication networks.

[0293] The ADM may store base station (BS) reader information, which may allow any AIoTF preparing to connect to an AIoT device to use the BS reader ID stored at the ADM. The storage of BS reader information at the ADM may enable the AIoTF to select the appropriate BS reader for service requests without querying all available BS readers. The BS reader selection based on stored information may improve the efficiency of AIoT service operations by directing requests to specific BS readers that previously served the targeted AIoT devices.

[0294] The solutions defined for New Radio (NR) within a 5G Core (5GC) network may also apply to legacy Radio Access Technologies (RATs) such as Evolved Universal Terrestrial Radio Access (E-UTRA) and Long Term Evolution (LTE). When applying the solutions to legacy RATs, corresponding core network entities may be replaced by LTE entities. For example, an Access and Mobility Function (AMF) may be replaced by a Mobility Management Entity (MME), a gNodeB may be replaced by an eNodeB, and a Unified Data Management (UDM) may be replaced by a Home Subscriber Server (HSS). The applicability of the solutions to legacy RATs may enable deployment of the AIoTF selection mechanisms in existing LTE network deployments and may facilitate migration paths from legacy networks to 5G networks.

[0295] The systems and methods described herein may be implemented in any form of computing or electronic device. The term "computer," as used herein, encompasses any device with processing capabilities sufficient to execute instructions. This includes, but is not limited to, personal computers, servers, mobile devices, personal digital assistants, and similar devices.

[0296] Such devices may include one or more processors, such as microprocessors, controllers, or other suitable types of processors, capable of executing instructions to control the device's operation. For example, in some implementations using a system-on-a-chip architecture, the processors may include fixed-function blocks (hardware accelerators) that perform parts of the method in hardware rather than software or firmware. Platform software, such as an operating system or similar, may be installed to support the execution of application software.

[0297] The described functionality may be implemented in hardware, software, or any combination thereof. When implemented in software, the instructions or code can be stored on or transmitted via a computer-readable medium. Such media include computer-readable storage media, which may be volatile or non-volatile, removable or non-removable, and implemented using any technology for storing information such as program code, data structures, or other data. Examples include, but are not limited to, ROM, EEPROM, RAM, magnetic or optical storage, flash memory, or any other storage medium accessible by a computer. Communication media that facilitate the transfer of software, such as via coaxial cables, fiber optics, DSL, or wireless signals, may also be considered part of computer-readable media.

[0298] Alternatively, or in addition, some or all of the described functionality may be implemented using hardware logic components. Examples include, but are not limited to, application-specific integrated circuits, system-on-a-chip systems, field-programmable gate arrays, application-specific standard products, and complex programmable logic devices. In some cases, software instructions may also be implemented in dedicated circuits, such as programmable logic arrays or digital signal processors.

[0299] The computing device may operate as a standalone system or as part of a distributed system, where tasks are performed collectively by multiple devices connected via a network. Such devices may communicate over a network connection to perform the described functionality. For instance, software may be stored on a remote computer and accessed by a local device, which may download and execute portions of the software as needed. Similarly, some instructions may be processed locally, while others may execute on remote systems or networks. In some cases, the computing device may be remote and accessible via a communication interface.　Storage of program instructions may also be distributed across a network or stored in a combination of local and remote locations. For example, software may reside on a remote computer and be accessed by a local terminal, or the system may execute some software locally while other components operate on remote servers.

[0300] Features of any of the examples or embodiments outlined above may be combined to create additional examples or embodiments without losing the intended effect. It should be understood that the description of an embodiment or example provided above is by way of example only, and various modifications could be made by one skilled in the art. Furthermore, one skilled in the art will recognise that numerous further modifications and combinations of various aspects are possible. Accordingly, the described aspects are intended to encompass all such alterations, modifications, and variations that fall within the scope of the appended claims.

Claims

1.A method performed by a Network Exposure Function (NEF) in a communication system, the method comprising:receiving, from an Application Function (AF), a service operation request including at least one identifier (ID) of at least one Ambient Internet of Things (AIoT) device;transmitting, to an AIoT Data Management (ADM), a query request for requesting AIoT function (AIoTF) information associated with the at least one AIoT device, wherein the query request includes an AIoT device permanent ID associated with the at least one AIoT device;receiving, from the ADM, a query response including the AIoTF information associated with the at least one AIoT device; andselecting an AIoTF based on the AIoTF information associated with the at least one AIoT device.2.The method of claim 1, wherein the AIoTF information includes at least one of an AIoTF ID, an AIoTF name, a fully qualified domain name (FQDN), or an AIoTF address.3.The method of claim 1, wherein the AIoTF information is last known AIoTF information indicating a last known AIoTF that serves the at least one AIoT device.4.The method of claim 1, wherein the service operation request is an Nnef_AIoT_Inventory Request, the query request is an Nadm_DM_Query Request, and the query response is an Nadm_DM_Query Response.5.A method for handling an Ambient Internet of Things (AIoT) service request by an AIoT Data Management (ADM) in a communication system, the method comprising:receiving, from a Network Exposure Function (NEF), a query request including an AIoT device permanent identifier (ID) associated with at least one AIoT device;retrieving, from a database, AIoT function (AIoTF) information associated with the at least one AIoT device; andtransmitting, to the NEF, a query response including the AIoTF information.6.The method of claim 5, further comprising:receiving updated AIoT device profile data from an AIoTF using update service operation upon completion of at least one service operation by the AIoTF based on the AIoT Device Permanent ID, wherein the updated AIoT device profile data includes last known AIoTF information; andretrieving the AIoTF information based on the updated AIoT device profile data.7.The method of claim 5, wherein the AIoTF information is last known AIoTF information indicating a last known AIoTF that serves the at least one AIoT device.8.The method of claim 5, wherein the query request is an Nadm_DM_Query Request, and the query response is an Nadm_DM_Query Response.9.An apparatus for a Network Exposure Function (NEF) in a communication system, the apparatus comprising:a memory; anda processor coupled to the memory and configured to:receive, from an Application Function (AF), a service operation request including at least one identifier (ID) of at least one Ambient Internet of Things (AIoT) device;transmit, to an AIoT Data Management (ADM), a query request for requesting AIoT function (AIoTF) information associated with the at least one AIoT device, wherein the query request includes an AIoT device permanent ID associated with the at least one AIoT device;receive, from the ADM, a query response including the AIoTF information associated with the at least one AIoT device; andselect an AIoTF based on the AIoTF information associated with the at least one AIoT device.10.The apparatus of claim 9, wherein the AIoTF information includes at least one of an AIoTF ID, an AIoTF name, a fully qualified domain name (FQDN), or an AIoTF address.11.The apparatus of claim 9, wherein the AIoTF information is last known AIoTF information indicating a last known AIoTF that serves the at least one AIoT device.12.The apparatus of claim 9, wherein the service operation request is an Nnef_AIoT_Inventory Request, the query request is an Nadm_DM_Query Request, and the query response is an Nadm_DM_Query Response.13.An apparatus for an Ambient Internet of Things (AIoT) Data Management (ADM) handling AIoT service requests in a communication system, the apparatus comprising:a memory; anda processor coupled to the memory and configured to:receive, from a Network Exposure Function (NEF), a query request including an AIoT device permanent identifier (ID) associated with at least one AIoT device;retrieve, from a database, AIoT function (AIoTF) information associated with the at least one AIoT device; andtransmit, to the NEF, a query response including the AIoTF information.14.The apparatus of claim 13, wherein the processor is configured to:receive updated AIoT device profile data from an AIoTF using update service operation upon completion of at least one service operation by the AIoTF based on the AIoT Device Permanent ID, wherein the updated AIoT device profile data includes last known AIoTF information; andretrieve the AIoTF information based on the updated AIoT device profile data.15.The method of claim 13, wherein the AIoTF information is last known AIoTF information indicating a last known AIoTF that serves the at least one AIoT device.

Images