Method and system for ambient internet of things management

Abstract

The disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. The present invention relates to a method and system for AIoT management. The method comprises generating AIoTNEFMapping information representing mapping information between a target area which is provided by an application function (AF) and an internal area and transmitting, to a network exposure function (NEF) entity, the AIoTMapping information.

Description

METHOD AND SYSTEM FOR AMBIENT INTERNET OF THINGS MANAGEMENT

[0001] The present disclosure relates to a communication network, and specifically related to a method and system for ambient internet of things management in a communication network.

[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 BWP (BandWidth Part), new channel coding methods such as a LDPC (Low Density Parity Check) 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 V2X (Vehicle-to-everything) 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, NR-U (New Radio Unlicensed) 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, IAB (Integrated Access and Backhaul) 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 DAPS (Dual Active Protocol Stack) handover, and two-step random access for simplifying random access procedures (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 AR (Augmented Reality), VR (Virtual Reality), MR (Mixed Reality) 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 OAM (Orbital Angular Momentum), and RIS (Reconfigurable Intelligent Surface), 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 AI (Artificial Intelligence) 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] In recent years, the Internet of Things (IoT) has garnered attention within the wireless communication sector. The concept of IoT envisions a world where a multitude of devices or "things" are interconnected to enhance productivity, efficiency, and overall quality of life. The potential for IoT is vast, with projections suggesting that tens or even hundreds of billions of IoT devices could be deployed across various applications. This growth is predicated on the continuous reduction in the size, complexity, and power consumption of IoT devices.

[0009] However, the widespread deployment of IoT devices presents several challenges. One of the primary issues is the reliance on batteries to power these devices. The necessity for manual replacement or recharging of batteries leads to high maintenance costs, environmental concerns due to battery disposal, and potential safety hazards in certain industries such as electrical power and petroleum. As industries move towards greater automation and digitization, there is an increasing demand for IoT technologies that support battery-less devices or devices with energy storage that do not require manual intervention for recharging or replacement.

[0010] One prevalent application of IoT technology is asset identification, which currently relies heavily on barcodes and Radio Frequency Identification (RFID) systems. While these technologies offer advantages such as ultra-low complexity and small form factors, they are also limited by a short reading range of a few meters. This limitation necessitates labor-intensive handheld scanning or the installation of costly RFID portals and gates. Further, the lack of an effective interference management scheme in the RFID systems leads to severe interference between RFID readers and capacity problems, particularly in dense deployment scenarios. This makes it challenging to support large-scale networks with seamless coverage using RFID technology.

[0011] Ambient IoT (AIoT) represents a new frontier in IoT technology, offering the potential to revolutionize the market within the 3rd Generation Partnership Project (3GPP) systems. The AIoT promises a higher number of connections and device density compared to existing 3GPP IoT technologies. Moreover, AIoT devices are designed to be ultra-low complexity and consume orders-of-magnitude less power than current Low Power Wide Area (LPWA) technologies such as Narrowband IoT (NB-IoT) and LTE-Machine Type Communication (LTE-MTC).

[0012] An Ambient IoT device is characterized by its ability to harvest energy, making it either battery-less or equipped with limited energy storage capabilities such as a capacitor. These devices are designed to be low complexity, small in size, and consume less power than traditional 3GPP IoT devices. The maintenance-free nature and extended lifespan (potentially exceeding 10 years, for example) of AIoT devices make them highly desirable for a wide range of applications.

[0013] The 5G System (5GS) architecture for AIoT encompasses core network functions, AIoT Radio Access Network (RAN) / Reader architecture, and AIoT devices. However, to enable AIoT services such as inventory service and command service as defined in the 3GPP SA2 specification 23.369, it is required to correctly identify the appropriate AIoT RAN node instance to ensure accurate identification of end-user AIoT devices for various procedures within a core network and a RAN network. This requires an effective mapping between the expected target area (provided by the Application Function (AF)) and the internal area served by the 5G Core (5GC) and RAN nodes. Currently, such mapping information is not available in Operations Administration and Maintenance (OAM) configurations.

[0014] The lack of this mapping information poses a challenge to the proper functioning of AIoT services within the communication network. Addressing this issue is crucial to unlocking the full potential of AIoT technology and ensuring seamless integration and operation within the 5GS architecture.

[0015] It is desired to address the above-mentioned disadvantages or other shortcomings or at least provide a useful alternative.

[0016] The present disclosure provides a method and a system for effectively managing Ambient Internet of Things (Ambient IoT) devices in a communication network, addressing challenges related to the connectivity and operational efficiency of numerous low-power IoT devices.

[0017] According to an aspect of the present disclosure, a method performed performed by a management entity for an ambient-Internet of Things (A-IoT) service in a wireless communication system is proviced. The method comprising generating AIoTNEFMapping information representing mapping information between a target area which is provided by an application function (AF) and an internal area and transmitting, to a network exposure function (NEF) entity, the AIoTMapping information.

[0018] According to another aspect of the present disclosure, a management entity for an ambient-Internet of Things (A-IoT) service in a wireless communication system is proviced. The management entity comprising a transceiver, and at least one processor, coupled to the transceiver and configured to generate AIoTNEFMapping information representing mapping information between a target area which is provided by an application function (AF) and an internal area, and transmit, to a network exposure function (NEF) entity via the transceiver, the AIoTMapping information.

[0019] According to various embodiments of the present disclosure, it is possible to improve the efficiency of managing Ambient IoT networks and optimize resource utilization, thereby supporting the large-scale deployment of energy-efficient IoT devices within a communication system.

[0020] These and other features, aspects, and advantages of the present invention are illustrated in the accompanying drawings, throughout which like reference letters indicate corresponding parts in the various figures. The embodiments herein will be better understood from the following description with reference to the drawings, in which:

[0021] FIG. 1 is a block diagram illustrating an MnS consumer device according to embodiments as disclosed herein.

[0022] FIG. 2 is a block diagram illustrating a first MnS producer device according to embodiments as disclosed herein.

[0023] FIG. 3 is a block diagram illustrating a second MnS producer device according to embodiments as disclosed herein.

[0024] FIG. 4 is a block diagram illustrating a third MnS producer device according to embodiments as disclosed herein.

[0025] FIG. 5a is a flow diagram illustrating a method implemented by the MnS consumer device for AIoT management according to embodiments as disclosed herein.

[0026] FIG. 5b is another flow diagram illustrating a method implemented by the MnS consumer device for AIoT management according to embodiments as disclosed herein.

[0027] FIG. 5c is another flow diagram illustrating a method implemented by the MnS consumer device for AIoT management according to embodiments as disclosed herein.

[0028] FIG. 6 is a flow diagram illustrating a method implemented by the first MnS producer device for AIoT management according to embodiments as disclosed herein.

[0029] FIG. 7 is a flow diagram illustrating a method implemented by the second MnS producer device for AIoT management according to embodiments as disclosed herein.

[0030] FIG. 8 is a flow diagram illustrating a method implemented by the third MnS producer device for AIoT management according to embodiments as disclosed herein.

[0031] FIG. 9a is example sequence diagrams that illustrate operations performed for AIoT management in a communication network according to embodiments as disclosed herein.

[0032] FIG. 9b is example sequence diagrams that illustrate operations performed for AIoT management in a communication network according to embodiments as disclosed herein.

[0033] The embodiments herein and the various features and advantageous details thereof are explained fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. Also, the various embodiments described herein are not necessarily mutually exclusive, as some embodiments can be combined with one or other embodiments to form new embodiments. The term "or" as used herein, refers to a non-exclusive or, unless otherwise indicated. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein can be practiced and to further enable those skilled in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.

[0034] As is traditional in the field, embodiments may be described and illustrated in terms of blocks which carry out a described function or functions. These blocks, which may be referred to herein as units or modules or the like, are physically implemented by anolog or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, or the like, and may optionally be driven by firmware. The circuits may, for example, be embodied in one or semiconductor chips, or on substrate supports such as printed circuit boards and the like. The circuits constituting a block may be implemented by dedicated hardware, or by a processor (e.g., one or programmed microprocessors and associated circuitry), or by a combination of dedicated hardware to perform some functions of the block and a processor to perform other functions of the block. Each block of the embodiments may be physically separated into two or interacting and discrete blocks without departing from the scope of the invention. Likewise, the blocks of the embodiments may be physically combined into complex blocks without departing from the scope of the invention

[0035] The accompanying drawings facilitate understanding of various technical features. The embodiments are not limited to these drawings and should be interpreted to include any alterations, equivalents, and substitutes. Terms like "first", "second" and "third" are used for distinction and do not limit the elements they describe.

[0036] The present invention relates to a method and system for IoT management within a communication network, specifically enhancing 5G Network Resource Management (NRM) for various configurations associated with Ambient IoT services.

[0037] The principal object of the invention herein is to provide a method and system for ambient Internet of Things management in a communication network. The proposed invention enhances 5G NRM for the various configurations related to Ambient IoT services.

[0038] Another object of the invention is to provide information where the information can be configured as a MOI of AIoTNEFMapping Information Object Class (IOC), which is name contained (in a UML composition relation with a Network Exposure Function (NEF)) by an NEF IOC, or the information can be configured directly as an attribute during the creation of MOI of NEFFunction IOC, or the information can be configured by updating an existing MOI of NEFFunction IOC.

[0039] Yet another object of the invention is to provide information where the information can be configured as a MOI of AIoTNRFMapping IOC, which is name contained (in UML composition relation with Network Repository Function (NRF)) by NRF IOC, or the information can be configured directly as an attribute during the creation of MOI of NRFFunction IOC, or the information can be configured by updating an existing MOI of NRFFunction IOC.

[0040] Yet another object of the invention is to provide information where the information can be configured as a MOI of AIoTRANinfo IOC, which is name contained (in UML composition relation with AIOTFFunction) by AIOTFFunction IOC, or the information can be configured directly as an attribute during the creation of MOI of AIOTFFunction IOC, or the information can be configured by updating an existing MOI of AIOTFFunction IOC.

[0041] Yet another object of the invention is to provide an ability for AIOTF to select AIoT RAN as per the provided RAN information.

[0042] In an aspect, the present invention provides a method for AIoT management. The method includes generating by a Management Service (MnS) consumer device a first request message including a first mapping information between an external target area provided by an AF and an internal target area that is to be provided to an NRF. Further, the method includes sending by the MnS consumer device the first request message to a provisioning MnS producer in a first MnS producer device for creating a model object instance (MOI) of a managed function IOC with the first mapping information or for modifying an existing MOI of a managed function IOC with the first mapping information. Further, the method includes receiving by the MnS consumer device a first response message from the MnS producer device as a response to the first request message where the first response message indicates creation or modification of the MOI.

[0043] In an embodiment, the first request message is one of a createMOI request message or modifyMOIAttributes request message. In an embodiment, the first response message is one of a createMOI response message or modifyMOIAttributes response message. In an embodiment, the first mapping information includes a target area AF attribute representing the external target area provided by the AF to a NEF for triggering A-IoT services. In another embodiment, the first mapping information includes an internal target area attribute representing the internal target area mapped to the external target area. The external target area can be, for example, but not limited to, a cell, a cell Identifier (ID) list, a Tracking Area Code (TAC), a Tracking Area Identity (TAI) list, Public Land Mobile Network (PLMN), Mobile Country Code (MCC), Mobile Network Code (MNC), latitude, longitude, Closed Access Group (CAG) cell, any geographical location coordinate, or area polygon. The internal target area can be, for example, but not limited to, a cell, a cell ID list, a TAC, a TAI list, a PLMN, a MCC, a MNC, latitude, longitude, the CAG cell list of AIoT areas, and any geographical location coordinate or area polygon.

[0044] In an embodiment, the method includes generating by the MnS consumer device a second request message including second mapping information between an internal target area and an AIOTF Distinguished Name (DN). Further, the method includes sending by the MnS consumer device the second request message to a provisioning MnS producer in a second MnS producer device for creating an MOI of a managed function IOC with the second mapping information or for modifying an existing MOI of a managed function IOC with the second mapping information. Further, the method includes receiving by the MnS consumer device a second response message from the MnS producer device as a response to the second request message where the second response message indicates creation or modification of the MOI.

[0045] In an embodiment, the second request message is one of a createMOI request message or modifyMOIAttributes request message. In an embodiment, the second response message is one of a createMOI response message or modifyMOIAttributes response message. In an embodiment, the second mapping information includes an AIOTF DN attribute representing a distinguished name identifier of the AIOTF that serves the internal target area provided by a NEF to the NRF. In another embodiment, the second mapping information includes an internal target area attribute mapped to AIOTF DN. The AIOTF DN attribute is of type DN.

[0046] In an aspect, the present invention provides a method for AIoT management. The method includes generating by a MnS consumer device a third request message including information that an AIOTF requires from an Operations Administration and Maintenance (OAM) system for selecting at least one of an A-IoT capable RAN node and readers for identification of AIoT devices by an AIoT RAN. Further, the method includes sending by the MnS consumer device the third request message to a provisioning MnS producer in a third MnS producer device for creating an MOI of a managed function IOC with the information or for modifying an existing MOI of a managed function IOC with the information. Further, the method includes receiving by the MnS consumer device a third response message from the third MnS producer device as a response to the third request message where the third response message indicates creation or modification of the MOI.

[0047] In an embodiment, the information includes at least one of an AIoT RAN serving area attribute representing the area served or supported by the AIoT RAN for AIoT services, a Readers information attribute representing a list of readers identifiers (IDs) of a reader in the AIoT RAN, locations of AIoT readers, and an AIoT RAN Node ID attribute representing the identifier of the AIoT RAN node. The area served or supported by the AIoT RAN for the AIoT services is defined by at least one of, but not limited to, the cell, the cell ID list, the TAC, the TAI list, the PLMN, the MCC, the MNC, the A-IoT Area IDs, the latitude, the longitude, the CAG cell, any geographical location, the coordinate, and the area polygon. The reader information includes at least one of a reader ID or reader location. The reader ID can be, for example, but not limited to, a reader index. The reader locations include at least one of, but not limited to, the cell, the cell ID list, the TAC, the TAI list, the PLMN, the MCC, the MNC, the latitude, the longitude, the CAG cell, any geographical location, the coordinate, and the area polygon. The reader location attribute is of type string. The AIoT RAN Node ID attribute can be, but not limited to, a gNB ID.

[0048] In an embodiment, the third request message is one of a createMOI request message or modifyMOIAttributes request message. In an embodiment, the third response message is one of a createMOI response message or a modifyMOIAttributes response message.

[0049] In an aspect, the present invention provides a method for AIoT management. The method includes receiving by a provisioning MnS producer in a first MnS producer device a first request message from a MnS consumer device for creating a MOI of a managed function IOC with the first mapping information or for modifying an existing MOI of a managed function IOC with the first mapping information. The first request message includes a first mapping information between an external target area provided by an AF and an internal target area that is to be provided to the NRF. Further, the method includes sending by the first MnS producer device a first response message to the MnS consumer device where the first response message indicates creation or modification of the MOI. Further, the method includes receiving by the first MnS producer device an AIoT service request from the AF. Further, the method includes determining by the first MnS producer device internal target area information based on the first mapping information after receiving the AIoT service request from the AF.

[0050] In an embodiment, the method includes sending by the first MnS producer device acting as a MnS consumer device a query message to a second MnS producer device to obtain serving AIOTF information based on the internal target area information. Further, the method includes receiving by the first MnS producer device AIOTF information as a response to the query message from the second MnS producer device. Further, the method includes forwarding by the first MnS producer device an AIoT service request to a third MnS producer device based on the AIOTF information received from the second MnS producer device.

[0051] In an aspect, the present invention provides a method for AIoT management. The method includes receiving by a provisioning MnS producer in a second MnS producer device a second request message from a MnS consumer device for creating a MOI of a managed function IOC with the second mapping information or for modifying an existing MOI of a managed function IOC with the second mapping information. The second request message includes second mapping information between an internal target area and an AIOTF DN. Further, the method includes sending by the second MnS producer device a second response message to the MnS consumer device where the second response message indicates creation or modification of the MOI. Further, the method includes receiving by the second MnS producer device a query message from a first MnS producer device acting as a MnS consumer to obtain serving AIOTF information. Further, the method includes determining by the second MnS producer device the AIOTF information based on the second mapping information. Further, the method includes sending by the second MnS producer device the AIOTF information as a response to the query message from the first MnS producer device.

[0052] In an aspect, the present invention provides a method for AIoT management. The method includes receiving by a provisioning MnS producer in a third MnS producer device a third request message from a MnS consumer device for creating a MOI of a managed function IOC with information or for modifying an existing MOI of a managed function IOC with the information. The information is required by an AIOTF from an Operations Administration and Maintenance (OAM) system for selecting at least one of an A-IoT capable RAN (AIoT RAN) node and readers for identification of AIoT devices by the AIoT RAN. Further, the method includes sending by the third MnS producer device a third response message to the MnS consumer device where the third response message indicates creation or modification of the MOI. Further, the method includes receiving by the third MnS producer device an AIoT service request forwarded by a first MnS producer device where the AIoT service request includes at least one of internal target area information, AIoT device ID, and a number of AIoT devices. Further, the method includes determining by the third MnS producer device at least one of an AIoT RAN serving area, a list of readers identifiers (IDs), locations of AIoT readers, and an AIoT RAN Node ID based on the information.

[0053] Further, the method includes selecting by the third MnS producer device an AIoT RAN node and optionally a list of RAN readers based on at least one of an AIoT RAN serving area, a list of readers identifiers (IDs), locations of AIoT readers, and an AIoT RAN Node ID. Further, the method includes determining by the third MnS producer device assistance information to be provided to the AIoT RAN node based on information received indirectly from an AF. Further, the method includes sending by the third MnS producer device the assistance information to the AIoT RAN node together with a service operation request where the service operation request includes at least one of the AIoT RAN serving area, Reader ID list, and AIoT device ID.

[0054] In an aspect, the present invention provides a MnS consumer device for AIoT management. The MnS consumer device includes a mapping information controller connected to a memory and a processor. The mapping information controller generates a first request message including a first mapping information between an external target area provided by an AF and an internal target area that is to be provided to an NRF. The mapping information controller sends the first request message to a provisioning MnS producer in a first MnS producer device for creating a MOI of a managed function IOC with the first mapping information or for modifying an existing MOI of a managed function IOC with the first mapping information. The mapping information controller receives a first response message from the MnS producer device as a response to the first request message where the first response message indicates creation or modification of a MOI.

[0055] In an embodiment, the mapping information controller generates a second request message including second mapping information between an internal target area and an AIOTF Distinguished Name (DN). Further, the mapping information controller sends the second request message to a provisioning MnS producer in a second MnS producer device for creating an MOI of a managed function IOC with the second mapping information or for modifying an existing MOI of a managed function IOC with the second mapping information. Further, the mapping information controller receives a second response message from the MnS producer device as a response to the second request message where the second response message indicates creation or modification of the MOI.

[0056] In an aspect, the present invention provides a MnS consumer device for AIoT management. The MnS consumer device includes a mapping information controller connected to a memory and a processor. In an embodiment, the mapping information controller generates a third request message including information that an AIOTF requires from an OAM system for selecting at least one of an A-IoT capable RAN node and readers for identification of AIoT devices by an AIoT RAN. Further, the mapping information controller sends the third request message to a provisioning MnS producer in a third MnS producer device for creating an MOI of a managed function IOC with the information or for modifying an existing MOI of a managed function IOC with the information. Further, the mapping information controller receives a third response message from the third MnS producer device as a response to the third request message where the third response message indicates creation or modification of the MOI.

[0057] In an aspect, the present invention provides a first MnS producer device for AIoT management. The first MnS producer device includes a managed function IOC controller connected to a memory and a processor. The managed function IOC controller receives by a provisioning MnS producer a first request message from a MnS consumer device for creating a MOI of a managed function IOC with the first mapping information or for modifying an existing MOI of a managed function IOC with the first mapping information. The first request message includes a first mapping information between an external target area provided by an AF and an internal target area that is to be provided to NRF. Further, the managed function IOC controller sends a first response message to the MnS consumer device where the first response message indicates creation or modification of the MOI. Further, the managed function IOC controller receives an AIoT service request from the AF. Further, the managed function IOC controller determines internal target area information based on the first mapping information after receiving the AIoT service request from the AF.

[0058] In an embodiment, the managed function IOC controller sends a query message to a second MnS producer device to obtain serving AIOTF information based on the internal target area information. The AIOTF information can be, for example, but not limited to, its DN. Further, the managed function IOC controller receives AIOTF information as a response to the query message from the second MnS producer device. Further, the managed function IOC controller forwards an AIoT service request to a third MnS producer device based on the AIOTF information received from the second MnS producer device.

[0059] In an aspect, the present invention provides a second MnS producer for AIoT management. The second MnS producer includes a managed function IOC controller connected to the memory and the processor. The managed function IOC controller receives by a provisioning MnS producer a second request message from a MnS consumer device for creating a MOI of a managed function IOC with the second mapping information or for modifying an existing MOI of a managed function IOC with the second mapping information. The second request message includes second mapping information between an internal target area and an AIOTF DN. The managed function IOC controller sends a second response message to the MnS consumer device where the second response message indicates creation or modification of the MOI. Further, the managed function IOC controller receives a query message from a first MnS producer device acting as a MnS consumer to obtain serving AIOTF information. Further, the managed function IOC controller determines the AIOTF information based on the second mapping information. Further, the managed function IOC controller sends the AIOTF information as a response to the query message from the first MnS producer device.

[0060] In an aspect, the present invention provides a third MnS producer for AIoT management. The third MnS producer includes a managed function IOC controller connected to a memory and a processor. The managed function IOC controller receives by a provisioning MnS producer a third request message from a MnS consumer device for creating a MOI of a managed function IOC with information or for modifying an existing MOI of a managed function IOC with the information. The information is required by an AIOTF from an OAM system for selecting at least one of an A-IoT capable RAN (AIoT RAN) node and readers for identification of AIoT devices by the AIoT RAN. Further, the managed function IOC controller sends a third response message to the MnS consumer device where the third response message indicates creation or modification of the MOI. Further, the managed function IOC controller receives an AIoT service request forwarded by a first MnS producer device. The AIoT service request includes at least one of internal target area information, AIoT device ID, and a number of AIoT devices. Further, the managed function IOC controller determines at least one of an AIoT RAN serving area, a list of readers identifiers (IDs), locations of AIoT readers, and an AIoT RAN Node ID based on the information.

[0061] In an embodiment, the managed function IOC controller selects an AIoT RAN node and optionally a list of RAN readers based on at least one of an AIoT RAN serving area, a list of readers identifiers (IDs), locations of AIoT readers, and an AIoT RAN Node ID. Further, the managed function IOC controller determines assistance information to be provided to the AIoT RAN node based on information received indirectly from an AF. Further, the managed function IOC controller sends the assistance information to the AIoT RAN node together with a service operation request. The service operation request includes at least one of the AIoT RAN serving area, Reader ID list, and AIoT device ID.

[0062] These and other aspects of the embodiments will be better understood with the following description and accompanying drawings. The descriptions, while indicating preferred embodiments and specific details, are for illustration and not limitation. Many modifications can be made within the scope of the embodiments, which include all such modifications.

[0063] Referring now to the drawings and more particularly to FIGS. 1 to 9b, where similar reference characters denote corresponding features throughout the figures, there are shown preferred embodiments.

[0064] FIG. 1 is a block diagram illustrating an MnS consumer device (100) according to embodiments as disclosed herein. The MnS consumer device (100) includes a mapping information controller (110), a processor (120), a memory (130), and a communicator (140) that communicate with each other.

[0065] The mapping information controller (110) generates a first request message including a first mapping information between an external target area provided by an AF (200) (as shown in FIG. 9a and FIG. 9b) and an internal target area that is to be provided to an NRF. In an embodiment, the first request message is one of a createMOI request message or modifyMOIAttributes request message. In an embodiment, the first mapping information includes a target area AF attribute representing the external target area provided by the AF (200) to the NEF for triggering A-IoT services. In another embodiment, the first mapping information includes an internal target area attribute representing the internal target area mapped to the external target area. The first mapping information can be configured as a MOI of AIoTNEFMapping Information Object Class (IOC), which is name contained (in UML composition relation with the NEF) by NEF IOC, or it can be configured directly as an attribute during the creation of MOI of NEFFunction IOC, or it can be configured by updating an existing MOI of NEFFunction IOC. The external target area can be, for example, but not limited to, a cell, a cell Identifier (ID) list, a Tracking Area Code (TAC), a Tracking Area Identity (TAI) list, Public Land Mobile Network (PLMN), Mobile Country Code (MCC), Mobile Network Code (MNC), latitude, longitude, Closed Access Group (CAG) cell, any geographical location coordinate, or area polygon. The internal target area can be, for example, but not limited to, a cell, a cell ID list, a TAC, a TAI list, a PLMN, a MCC, a MNC, latitude, longitude, the CAG cell list of AIoT areas, and any geographical location coordinate or area polygon.

[0066] Further, the mapping information controller (110) sends the first request message to a provisioning MnS producer (400) in a first MnS producer device (300) (as shown in FIG. 9a and FIG. 9b) for creating the MOI of the managed function IOC with the first mapping information or for modifying the existing MOI of the managed function IOC with the first mapping information.

[0067] Further, the mapping information controller (110) receives a first response message from the MnS producer device (300) as a response to the first request message. The first response message indicates the creation or modification of a MOI. In an embodiment, the first response message is one of a createMOI response message or modifyMOIAttributes response message.

[0068] Further, the mapping information controller (110) generates a second request message including second mapping information between an internal target area and an AIOTF DN. The second request message is one of a createMOI request message or modifyMOIAttributes request message. In an embodiment, the second mapping information includes an AIOTF DN attribute representing the distinguished name identifier of the AIOTF that serves the internal target area provided by the NEF to the NRF. In another embodiment, the second mapping information includes an internal target area attribute mapped to the AIOTF DN. The second mapping information can be configured as a MOI of AIoTNRFMapping Information Object Class (IOC), which is name contained (in UML composition relation with the NRF) by NRF IOC, or it can be configured directly as an attribute during the creation of MOI of NRFFunction IOC, or it can be configured by updating an existing MOI of NRFFunction IOC. The AIOTF DN attribute is of type DN.

[0069] Further, the mapping information controller (110) sends the second request message to a provisioning MnS producer (600) in a second MnS producer device (500) (as shown in FIG. 9a and FIG. 9b) for creating the MOI of a managed function IOC with the second mapping information or for modifying the existing MOI of a managed function IOC with the second mapping information. Further, the mapping information controller (110) receives a second response message from the MnS producer device as a response to the second request message. The second response message indicates the creation or modification of the MOI. The second response message is one of a createMOI response message or modifyMOIAttributes response message.

[0070] Further, the mapping information controller (110) generates the third request message including information that an AIOTF requires from an OAM system (not shown) for selecting at least one of an A-IoT capable RAN node and readers for identification of AIoT devices (1000) by an AIoT RAN (900). The third request message is one of a createMOI request message or modifyMOIAttributes request message. The information includes at least one of an AIoT RAN serving area attribute representing the area served or supported by the AIoT RAN for AIoT services, a Readers information attribute representing a list of readers IDs of a reader in the AIoT RAN, locations of AIoT readers, and an AIoT RAN Node ID attribute representing the identifier of the AIoT RAN node (900). The information can be configured as a MOI of AIoTRANinfo Information Object Class (IOC), which is name contained (in UML composition relation with AIOTFFunction) by AIOTFFunction IOC, or it can be configured directly as an attribute during the creation of MOI of AIOTFFunction IOC, or it can be configured by updating an existing MOI of AIOTFFunction IOC.

[0071] The area served or supported by the AIoT RAN for the AIoT services is defined by at least one of, but not limited to, the cell, the cell ID list, the TAC, the TAI list, the PLMN, the MCC, the MNC, the A-IoT Area IDs, the latitude, the longitude, the CAG cell, any geographical location, the coordinate, and the area polygon. The reader information includes at least one of a reader ID or reader location. The reader ID can be, for example, but not limited to, a reader index. The reader locations include at least one of, but not limited to, the cell, the cell ID list, the TAC, the TAI list, the PLMN, the MCC, the MNC, the latitude, the longitude, the CAG cell, any geographical location, the coordinate, and the area polygon. The reader location attribute is of type string. The AIoT RAN Node ID attribute can be, but not limited to, a gNB ID.

[0072] Further, the mapping information controller (110) sends the third request message to the provisioning MnS producer (800) in the third MnS producer device (700) (as shown in FIG. 9a and FIG. 9b) for creating the MOI of the managed function IOC with the information or for modifying an existing MOI of the managed function IOC with the information. Further, the mapping information controller (110) receives the third response message from the third MnS producer device (700) as a response to the third request message. The third response message indicates the creation or modification of the MOI. The third response message is one of a createMOI response message or a modifyMOIAttributes response message.

[0073] In an embodiment, the mapping information controller (110) is implemented as a dedicated integrated circuit or as a hardware logic block fabricated on a semiconductor substrate within the communication network (10000). The mapping information controller (110) includes, for example, one or more hardware processing units, control logic circuits, state machines, registers, and scheduling logic configured for AIoT management without reliance on general-purpose software execution. The mapping information controller (110) is operatively coupled to the processor (120), the memory (130), and the communicator (140) via one or more hardware interfaces, buses, or interconnects. The mapping information controller (110) implements the solution as described above with respect to FIG. 5a, FIG. 5b, FIG. 9a, and FIG. 9b. These enhancements improve the management of Ambient IoT services within the communication network (e.g., 5G network), enabling better resource allocation and service delivery.

[0074] The processor (120) executes instructions stored in the memory (130) and controls interactions among the memory (130), the communicator (140), and the mapping information controller (110). The processor (120) may include one or more processing units such as a Central Processing Unit (CPU), an Application Processor (AP), a Graphics Processing Unit (GPU), a Neural Processing Unit (NPU), or other hardware accelerators or any combination thereof to support scalable and latency-tolerant ML processing in a 3GPP network environment.

[0075] The memory (130) is configured to store an operating system, virtualization or container runtime components, application programs, configuration data, and operational data. The memory (130) may comprise one or more volatile and / or non-volatile computer-readable storage media including RAM, ROM, flash memory, magnetic or optical storage, EPROM, EEPROM, or any combination thereof, and may be implemented as a non-transitory computer-readable storage medium.

[0076] The communicator (140) is configured to support communication between the MnS consumer device (100) and MnS producer devices (300, 500, and 700) over standardized 3GPP management interfaces. The communicator (140) enables communication via service-based interfaces (SBI) and supports one or more communication protocols including, but not limited to, Hypertext Transfer Protocol (HTTP / HTTPS), Transmission Control Protocol / Internet Protocol (TCP / IP), User Datagram Protocol (UDP), and other protocols defined or referenced in 3GPP specifications. In some embodiments, the communicator (140) further supports communication over non-3GPP access networks or satellite and broadcast systems including Digital Video Broadcasting by Satellite (DVB-S2). The communicator (140) may include one or more transceivers, network interface controllers, protocol stacks, or virtualized communication functions implemented in hardware, software, or a combination thereof.

[0077] FIG. 2 is a block diagram illustrating the first MnS producer device (300) according to embodiments as disclosed herein. The first MnS producer device (300) includes a managed function IOC controller (310), a processor (320), a memory (330), and a communicator (340) that communicate with each other. The managed function IOC controller (310) receives the first request message from the MnS consumer device (100) for creating the MOI of the managed function IOC with the first mapping information or for modifying the existing MOI of the managed function IOC with the first mapping information. The first request message includes the first mapping information between the external target area provided by the AF (200) and the internal target area that is to be provided to the NRF. The first request message is one of a createMOI request message or modifyMOIAttributes request message. In an embodiment, the first mapping information includes the target area AF attribute representing the external target area provided by the AF (200) to the NEF for triggering A-IoT services. In another embodiment, the first mapping information includes the internal target area attribute representing the internal target area mapped to the external target area.

[0078] Further, the managed function IOC controller (310) sends the first response message to the MnS consumer device (100) where the first response message indicates the creation or modification of the MOI. The first response message is one of the createMOI response message or the modifyMOIAttributes response message. Further, the managed function IOC controller (310) receives the AIoT service request from the AF. Further, the managed function IOC controller (310) determines the internal target area information based on the first mapping information after receiving the AIoT service request from the AF.

[0079] In an embodiment, the first MnS producer device acts as a MnS consumer device. The managed function IOC controller (310) sends the query message to the second MnS producer device (500) to obtain serving AIOTF information based on the internal target area information. Further, the managed function IOC controller (310) receives the AIOTF information as a response to the query message from the second MnS producer device (500). Further, the managed function IOC controller (310) forwards the AIoT service request to the third MnS producer device (700) based on the AIOTF information received from the second MnS producer device (500).

[0080] In an embodiment, the managed function IOC controller (310) is implemented as a dedicated integrated circuit or as a hardware logic block fabricated on a semiconductor substrate within the communication network (10000). The managed function IOC controller (310) includes, for example, one or more hardware processing units, control logic circuits, state machines, registers, and scheduling logic configured for AIoT management without reliance on general-purpose software execution. The managed function IOC controller (310) is operatively coupled to the processor (320), the memory (330), and the communicator (340) via one or more hardware interfaces, buses, or interconnects. The managed function IOC controller (310) implements the solution as described above with respect to FIG. 6, FIG. 9a, and FIG. 9b. These enhancements improve the management of Ambient IoT services within the communication network, enabling better resource allocation and service delivery.

[0081] The processor (320) executes instructions stored in the memory (330) and controls interactions among the memory (330), the communicator (340), and the managed function IOC controller (310). The processor (320) may include one or more processing units such as a Central Processing Unit (CPU), an Application Processor (AP), a Graphics Processing Unit (GPU), a Neural Processing Unit (NPU), or other hardware accelerators or any combination thereof to support scalable and latency-tolerant ML processing in a 3GPP network environment.

[0082] The memory (330) is configured to store an operating system, virtualization or container runtime components, application programs, configuration data, and operational data. The memory (330) may comprise one or more volatile and / or non-volatile computer-readable storage media, including RAM, ROM, flash memory, magnetic or optical storage, EPROM, EEPROM, or any combination thereof, and may be implemented as a non-transitory computer-readable storage medium.

[0083] The communicator (340) is configured to support communication between the MnS consumer device (100) and MnS producer devices (300, 500, and 700) over standardized 3GPP management interfaces. The communicator (340) enables communication via service-based interfaces (SBI) and supports one or more communication protocols, including but not limited to Hypertext Transfer Protocol (HTTP / HTTPS), Transmission Control Protocol / Internet Protocol (TCP / IP), User Datagram Protocol (UDP), and other protocols defined or referenced in 3GPP specifications. In some embodiments, the communicator (340) further supports communication over non-3GPP access networks or satellite and broadcast systems, including Digital Video Broadcasting by Satellite (DVB-S2). The communicator (340) may include one or more transceivers, network interface controllers, protocol stacks, or virtualized communication functions implemented in hardware, software, or a combination thereof.

[0084] FIG. 3 is a block diagram illustrating the second MnS producer device (500) according to embodiments as disclosed herein. The second MnS producer device (500) includes a managed function IOC controller (510), a processor (520), a memory (530), and a communicator (540) that communicate with each other. The managed function IOC controller (510) receives, by the provisioning MnS producer (600), the second request message from the MnS consumer device (100) for creating the MOI of the managed function IOC with the second mapping information or for modifying an existing MOI of the managed function IOC with the second mapping information. The second request message includes second mapping information between the internal target area and the AIOTF DN. The second request message is one of a createMOI request message or modifyMOIAttributes request message. In an embodiment, the second mapping information includes the AIOTF DN attribute representing the distinguished name identifier of the AIOTF that serves the internal target area provided by the NEF to the NRF. In another embodiment, the second mapping information includes the internal target area attribute mapped to AIOTF DN.

[0085] Further, the managed function IOC controller (510) sends the second response message to the MnS consumer device (100). The second response message indicates the creation or modification of the MOI. Further, the managed function IOC controller (510) receives the query message from the first MnS producer device (300) acting as the MnS consumer to obtain serving AIOTF information. The second response message is one of a createMOI response message or modifyMOIAttributes response message. Further, the managed function IOC controller (510) determines the AIOTF information based on the second mapping information. Further, the managed function IOC controller (510) sends the AIOTF information as a response to the query message from the first MnS producer device (300).

[0086] In an embodiment, the managed function IOC controller (510) is implemented as a dedicated integrated circuit or as a hardware logic block fabricated on a semiconductor substrate within the communication network (10000). The managed function IOC controller (510) includes, for example, one or more hardware processing units, control logic circuits, state machines, registers, and scheduling logic configured for AIoT management without reliance on general-purpose software execution. The managed function IOC controller (510) is operatively coupled to the processor (520), the memory (530), and the communicator (540) via one or more hardware interfaces, buses, or interconnects. The managed function IOC controller (510) implements the solution as described above with respect to FIG. 7, FIG. 9a, and FIG. 9b. These enhancements improve the management of Ambient IoT services within the communication network, enabling better resource allocation and service delivery.

[0087] The processor (520) executes instructions stored in the memory (530) and controls interactions among the memory (530), the communicator (540), and the managed function IOC controller (510). The processor (520) may include one or more processing units such as a Central Processing Unit (CPU), an Application Processor (AP), a Graphics Processing Unit (GPU), a Neural Processing Unit (NPU), or other hardware accelerators or any combination thereof to support scalable and latency-tolerant ML processing in a 3GPP network environment.

[0088] The memory (530) is configured to store an operating system, virtualization or container runtime components, application programs, configuration data, and operational data. The memory (530) may comprise one or more volatile and / or non-volatile computer-readable storage media, including RAM, ROM, flash memory, magnetic or optical storage, EPROM, EEPROM, or any combination thereof, and may be implemented as a non-transitory computer-readable storage medium.

[0089] The communicator (540) is configured to support communication between the MnS consumer device (100) and MnS producer devices (300, 500, and 700) over standardized 3GPP management interfaces. The communicator (540) enables communication via service-based interfaces (SBI) and supports one or more communication protocols, including but not limited to Hypertext Transfer Protocol (HTTP / HTTPS), Transmission Control Protocol / Internet Protocol (TCP / IP), User Datagram Protocol (UDP), and other protocols defined or referenced in 3GPP specifications. In some embodiments, the communicator (540) further supports communication over non-3GPP access networks or satellite and broadcast systems, including Digital Video Broadcasting by Satellite (DVB-S2). The communicator (540) may include one or more transceivers, network interface controllers, protocol stacks, or virtualized communication functions implemented in hardware, software, or a combination thereof.

[0090] FIG. 4 is a block diagram illustrating the third MnS producer device (700) according to embodiments as disclosed herein. The third MnS producer device (700) includes a managed function IOC controller (710), a processor (720), a memory (730), and a communicator (740) that communicate with each other.

[0091] The managed function IOC controller (710) receives, by the provisioning MnS producer (800), the third request message from the MnS consumer device (100) for creating the MOI of the managed function IOC with information or for modifying the existing MOI of the managed function IOC with the information. The information is required by the AIOTF from the OAM system for selecting at least one of the AIoT RAN node and readers for identification of the AIoT devices (1000) by the AIoT RAN (900). The third request message is one of a createMOI request message or modifyMOIAttributes request message. The information comprises at least one of an AIoT RAN serving area attribute representing the area served or supported by the AIoT RAN for the AIoT services, a Readers information attribute representing a list of readers' identifiers (IDs) of a reader in the AIoT RAN, locations of AIoT readers, and an AIoT RAN Node ID attribute representing the identifier of the AIoT RAN node.

[0092] The managed function IOC controller (710) sends the third response message to the MnS consumer device (100) where the third response message indicates the creation or modification of the MOI. The third response message is one of a createMOI response message or a modifyMOIattributes response message. The managed function IOC controller (710) receives the AIoT service request forwarded by the first MnS producer device (300). The AIoT service request includes at least one of internal target area information, AIoT device ID, and a number of AIoT devices (1000). The managed function IOC controller (710) determines at least one of an AIoT RAN serving area, a list of readers' identifiers (IDs), locations of AIoT readers, and an AIoT RAN Node ID based on the information.

[0093] The managed function IOC controller (710) selects the AIoT RAN node and optionally a list of RAN readers based on at least one of an AIoT RAN serving area, a list of readers' identifiers (IDs), locations of AIoT readers, and an AIoT RAN Node ID. The managed function IOC controller (710) determines the assistance information to be provided to the AIoT RAN node based on information received indirectly from the AF. The managed function IOC controller (710) sends the assistance information to the AIoT RAN node together with a service operation request. The service operation request includes the AIoT RAN serving area, Reader ID list, and AIoT device ID.

[0094] The managed function IOC controller (710) is implemented as a dedicated integrated circuit or as a hardware logic block fabricated on a semiconductor substrate within the communication network (10000). The managed function IOC controller (710) includes, for example, one or more hardware processing units, control logic circuits, state machines, registers, and scheduling logic configured for AIoT management without reliance on general-purpose software execution. The managed function IOC controller (710) is operatively coupled to the processor (720), the memory (730), and the communicator (740) via one or more hardware interfaces, buses, or interconnects. The managed function IOC controller (710) implements the solution as described above with respect to FIG 8, FIG 9a, and FIG 9b. These enhancements improve the management of Ambient IoT services within the communication network, enabling better resource allocation and service delivery.

[0095] The processor (720) executes instructions stored in the memory (730) and manages interactions among the memory (730), communicator (740), and IOC controller (710). The processor (720) may include various processing units such as a CPU, AP, GPU, NPU, or other hardware accelerators, or any combination thereof, to support scalable and latency-tolerant ML processing in a 3GPP network environment.

[0096] The memory (730) stores the operating system, virtualization or container runtime components, application programs, configuration data, and operational data. It may comprise volatile and / or non-volatile computer-readable storage media, including RAM, ROM, flash memory, magnetic or optical storage, EPROM, EEPROM, or any combination thereof, and may be implemented as a non-transitory computer-readable storage medium.

[0097] The communicator (740) supports communication between the MnS consumer device (100) and MnS producer devices (300, 500, 700) over standardized 3GPP management interfaces. It enables communication via service-based interfaces (SBI) and supports various protocols including HTTP / HTTPS, TCP / IP, UDP, and other 3GPP-specified protocols. In some embodiments, the communicator (740) also supports communication over non-3GPP access networks or satellite and broadcast systems, including DVB-S2. The communicator (740) may include transceivers, network interface controllers, protocol stacks, or virtualized communication functions implemented in hardware, software, or a combination thereof.

[0098] FIG 5a is a flow diagram (S500a) illustrating a method implemented by the MnS consumer device (100) for the AIoT management according to embodiments as disclosed herein. The operations (S502-S506) are handled by the mapping information controller (110). At S502 the method includes generating the first request message including the first mapping information between the external target area provided by the AF (200) and the internal target area that is to be provided to the NRF. At S504 the method includes sending the first request message to the provisioning MnS producer (400) in the first MnS producer device (300) for creating the MOI of the managed function IOC with the first mapping information or for modifying the existing MOI of the managed function IOC with the first mapping information. At S506 the method includes receiving the first response message from the MnS producer device as a response to the first request message. The first response message indicates the creation or modification of the MOI.

[0099] FIG 5b is another flow diagram (S500b) illustrating a method implemented by the MnS consumer device (100) for the AIoT management according to embodiments as disclosed herein. The operations (S512-S516) are handled by the mapping information controller (110). At S512 the method includes generating the second request message including the second mapping information between the internal target area and the AIOTF DN. At S514 the method includes sending the second request message to the provisioning MnS producer (600) in the second MnS producer device (500) for creating the MOI of the managed function IOC with the second mapping information or for modifying the existing MOI of the managed function IOC with the second mapping information. At S516 the method includes receiving the second response message from the MnS producer device as a response to the second request message. The second response message indicates the creation or modification of the MOI.

[0100] FIG. 5c is another flow diagram (S500c) illustrating a method implemented by the MnS consumer device (100) for the AIoT management according to embodiments as disclosed herein. The operations (S522-S526) are handled by the mapping information controller (110). At S522, the method includes generating the third request message including information that the AIOTF requires from the OAM system for selecting at least one of the A-IoT capable RAN node and readers for identification of the AIoT devices (1000) by the AIoT RAN (900). At S524, the method includes sending the third request message to the provisioning MnS producer (800) in the third MnS producer device (700) for creating the MOI of the managed function IOC with the information or for modifying the existing MOI of the managed function IOC with the information. At S526, the method includes receiving the third response message from the third MnS producer device (700) as a response to the third request message. The third response message indicates creation or modification of the MOI.

[0101] FIG. 6 is a flow diagram (S600) illustrating a method implemented by the first MnS producer device (300) for AIoT management according to embodiments as disclosed herein. The operations (S602-S614) are handled by the managed function IOC controller (310). At S602, the method includes receiving by the provisioning MnS producer (400) the first request message from the MnS consumer device (100) for creating the MOI of the managed function IOC with the first mapping information or for modifying the existing MOI of the managed function IOC with the first mapping information. The first request message includes the first mapping information between the external target area provided by the AF (200) and the internal target area that is to be provided to the NRF. At S604, the method includes sending the first response message to the MnS consumer device (100) where the first response message indicates creation or modification of the MOI. At S606, the method includes receiving the AIoT service request from the AF (200). At S608, the method includes determining internal target area information based on the first mapping information after receiving the AIoT service request from the AF. At S610, the method includes sending the query message to the second MnS producer device (500) to obtain serving AIOTF information based on the internal target area information. At S612, the method includes receiving the AIOTF information as a response to the query message from the second MnS producer device (500). At S614, the method includes forwarding the AIoT service request to the third MnS producer device (700) based on the AIOTF information received from the second MnS producer device (500).

[0102] FIG. 7 is a flow diagram (S700) illustrating a method implemented by the second MnS producer device (500) for the AIoT management according to embodiments as disclosed herein. The operations (S702-S710) are handled by the managed function IOC controller (510). At S702, the method includes receiving by the provisioning MnS producer (600) the second request message from the MnS consumer device (100) for creating the MOI of the managed function IOC with the second mapping information or for modifying the existing MOI of the managed function IOC with the second mapping information. The second request message includes second mapping information between an internal target area and the AIOTF DN. At S704, the method includes sending the second response message to the MnS consumer device (100) where the second response message indicates creation or modification of the MOI. At S706, the method includes receiving the query message from the first MnS producer device (300) acting as the MnS consumer to obtain serving AIOTF information. At S708, the method includes determining the AIOTF information based on the second mapping information. At S710, the method includes sending the AIOTF information as a response to the query message from the first MnS producer device (300).

[0103] FIG. 8 is a flow diagram (S800) illustrating a method implemented by the third MnS producer device (700) for AIoT management according to embodiments as disclosed herein. The operations (S802-S814) are handled by the managed function IOC controller (710). At S802, the method includes receiving by the provisioning MnS producer (800) the third request message from the MnS consumer device (100) for creating the MOI of the managed function IOC with information or for modifying an existing MOI of the managed function IOC with the information. The information is required by the AIOTF from an OAM system for selecting at least one of an AIoT RAN node and readers for identification of the AIoT devices (1000) by the AIoT RAN (900). At S804, the method includes sending the third response message to the MnS consumer device (100) where the third response message indicates creation or modification of the MOI. At S806, the method includes receiving the AIoT service request forwarded by the first MnS producer device (300) where the AIoT service request includes the internal target area information, the AIoT device ID, and the number of AIoT devices (1000). At S808, the method includes determining at least one of the AIoT RAN serving area, the list of readers IDs, locations of AIoT readers, and the AIoT RAN Node ID based on the information. At S810, the method includes selecting the AIoT RAN node and optionally a list of RAN readers based on at least one of the AIoT RAN serving area, the list of readers IDs, the locations of AIoT readers, and the AIoT RAN Node ID. At S812, the method includes determining the assistance information to be provided to the AIoT RAN node based on information indirectly received from the AF. At S814, the method includes sending the assistance information to the AIoT RAN node together with a service operation request. The service operation request includes at least one of the AIoT RAN serving area, Reader ID list, and AIoT device ID.

[0104] FIG. 9a and FIG. 9b are sequence diagrams that illustrate operations performed for ambient Internet of Things management in a communication network (10000) according to embodiments as disclosed herein. In an example, the proposed method introduces four new Information Object Classes (IOCs) to facilitate this enhancement. The first IOC, AIOTF, represents an Ambient IoT Function within a 5G core as defined in 3GPP TS 23.369 and is contained by the ManagedElement IOC. The second IOC, AIoTNEFMapping, provides mapping information between the expected target area as specified by the AF and the 5G core internal area and is contained by the NEF IOC. This IOC includes attributes such as TargetArea and InternalArea, which can refer to various geographical and location identifiers. In another example, the information can be configured as the MOI of AIoTNEFMapping Information Object Class (IOC), which is name contained (in a UML composition relation with the NEF) by an NEF IOC, or the information can be configured directly as an attribute during the creation of MOI of NEFFunction IOC, or the information can be configured by updating an existing MOI of NEFFunction IOC.

[0105] The third IOC, AIoTNRFMapping, represents mapping information between the InternalArea and the AIOTF Distinguished Name (DN) and is contained by the NRF IOC. This IOC includes attributes such as InternalArea and AIOTF DN, the latter being a string identifier for the AIOTF. In another example, the information can be configured as a MOI of AIoTNRFMapping Information Object Class (IOC), which is name contained (in UML composition relation with the NRF) by NRF IOC, or the information can be configured directly as an attribute during the creation of MOI of NRFFunction IOC, or the information can be configured by updating an existing MOI of NRFFunction IOC.

[0106] The fourth IOC, AIoTRANinfo, includes information required by the AIOTF from the Operations Administration and Maintenance (OAM) for selecting AIoT RAN nodes or readers and for identifying AIoT devices by the AIoT RAN. This IOC includes attributes such as AIoT RAN serving area, ReadersInfo, and AIoT RAN Node ID and is contained by the AIOTF IOC. In another example, the information can be configured as a MOI of AIoTRANinfo Information Object Class (IOC), which is name contained (in UML composition relation with AIOTFFunction) by AIOTFFunction IOC, or the information can be configured directly as an attribute during the creation of MOI of AIOTFFunction IOC, or the information can be configured by updating an existing MOI of AIOTFFunction IOC.

[0107] These enhancements enable management of Ambient IoT services within a communication network (e.g., 5G network), facilitating better resource allocation and service delivery. The system introduces four new Information Object Classes (IOCs) providing information about such as Ambient IoT Function details, mapping information between the target area specified by the AF and the 5G core internal area with attributes like TargetArea (or external target area) and InternalArea (or internal target area), mapping information between the InternalArea and the AIOTF Distinguished Name (DN) with attributes like InternalArea and AIOTF DN, information required by the AIOTF from OAM for selecting AIoT RAN nodes or readers and identifying AIoT devices with attributes like AIoT RAN serving area, ReadersInfo, and AIoT RAN Node ID. All this information enables flawless working of the AIoT service operations with the help of configurations provided by Operations Administration and Management (OAM) and maintains the integrity and reliability of the ambient IoT networks.

[0108] In more details, the present invention includes enhancing 5G NRM for the various configurations related to Ambient IoT services. This includes defining four new IOCs:

[0109] 1) An IOC AIOTF which represents an AIOTF function of the 5G core as defined in 3GPP TS 23.369. This IOC is name contained (in Unified Modeling Language (UML) composition relation with ManagedElement) by ManagedElement IOC as defined in 3GPP TS 28.541.

[0110] 2) An IOC AIoTNEFMapping which represents mapping information between expected target area (as provided by AF (Application Function)) and 5G core internal area. This IOC is name contained (in UML composition relation with the NEF) by NEF IOC as defined in 3GPP TS 28.541. It consists of attributes:

[0111] i. TargetArea - This is the expected target area for locating AIoT device as provided by AF and could refer to any of, for example, but not limited to, a cell / cell ID(list), Tracking Area Code (TAC) / Tracking Area Identity (TAI) (list), Public Land Mobile Network (PLMN), Mobile Country Code (MCC) / Mobile Network Code (MNC), latitude / longitude, Closed Access Group (CAG) cell or any geographical location / coordinate / area polygon.

[0112] ii. InternalArea - This is the 5G core internal area mapped to TargetArea and could refer to any of, for example, but not limited to, cell / cell ID(list), TAC / TAI(list), PLMN, MCC / MNC, latitude / longitude, CAG cell or any geographical location / coordinate / area polygon.

[0113] In an embodiment, this information can also be included in the NEFFunction IOC directly.

[0114] 3)An IOC AIoTNRFMapping which represents mapping information between InternalArea and AIOTF DN. This IOC is name contained (in UML composition relation with the NRF) NRF IOC as defined in 3GPP TS 28.541. It consists of attributes -

[0115] i. InternalArea - This is the 5G core internal area mapped to TargetArea and could refer to any of, for example, but not limited to, cell / cell ID(list), TAC / TAI(list), PLMN, MCC / MNC, latitude / longitude, CAG cell or any geographical location / coordinate / area polygon.

[0116] ii. AIOTF DN - This represents the distinguished name identifier of the AIOTF that corresponds to InternalArea. It is of type string.

[0117] In an embodiment, this information can also be included in the NEFFunction IOC directly.

[0118] 4) An IOC AIoTRANinfo which represents following information that a AIOTF needs from OAM for selecting the AIoT RAN node and / or readers and for further identification of AIoT devices by the AIoT RAN. This IOC is name contained (in UML composition relation with AIOTF) by IOC AIOTF, which is defined as part of this invention. This IOC will include the following attributes-

[0119] i. AIoT RAN serving area - This represents the area served / supported by AIoT RAN. It could refer to any of, for example, but not limited to, the cell / cell ID(list), TAC / TAI(list), PLMN, MCC / MNC, latitude / longitude, CAG cell or any geographical location / coordinate / area polygon.

[0120] ii. ReadersInfo - This represents the list of identifiers (reader index) of the common reader function in AIoT RAN and their locations. Locations here could refer to any of for example, but not limited to, cell / cell ID(list), TAC / TAI(list), PLMN,MCC / MNC, latitude / longitude, CAG cell or any geographical location / coordinate / area polygon This can be of type string.

[0121] iii. AIoT RAN Node ID - This represents the identifier of the AIoT RAN node. This can be of type GgNBId <<dataType>> as defined in 3GPP TS 28.541or can be of type string.

[0122] In an embodiment, this information can also be included in the AIOTF IOC directly.

[0123] Examples of the communication network (10000) include, but are not limited to, Cellular Networks (such as 2G, 3G, 4G, 5G, Beyond 5G (B5G) / 6G, or advanced cellular networks), Local Area Networks (LANs) (such as Wi-Fi, Li-Fi, etc.), Personal Area Networks (PANs) (such as Bluetooth, Zigbee, Z-Wave, etc.), Wide Area Networks (WANs) (such as Satellite Communication Networks, Long Range Wide Area Network, Narrowband IoT, Low-bandwidth communication for IoT, etc.), Metropolitan Area Networks (MANs), Machine-to-Machine (M2M), Ad Hoc and Mesh Networks, Emerging and Advanced Networks. In addition, the communication network (10000) may include, in combination or alternatively, wireless local area networks and machine-type communication networks.

[0124] In an embodiment, the communication network (10000) includes a 3GPP Management System (e.g., provisioning MnS consumer device) (100), an AF (200), a first MnS producer device (300), a provisioning MnS Producer (400), a second MnS producer device (500), a provisioning MnS Producer (600), a third MnS producer device (700), a provisioning MnS Producer (800), an AIoT RAN (900), and an AIoT device (1000). The first MnS producer device (300) is associated with the provisioning MnS Producer (400). The second MnS producer device (500) is associated with the provisioning MnS Producer (600). The third MnS producer device (700) is associated with the provisioning MnS Producer (800). In an example, the first MnS producer device (300) is NEF. In an example, the second MnS producer device (500) is NRF. In an example, the third MnS producer device (700) is AIOTF.

[0125] The first MnS producer device (300), the second MnS producer device (500), and the third MnS producer device (700) are associated with a network apparatus (not shown). Examples of the network apparatus can include, but are not limited to, Base Stations (such as macro cells, small cells, femtocells, picocells) for wireless communication, antennas and radio frequency (RF) Units (e.g., MIMO, beamforming) to enhance signal coverage and data throughput, Core Network Equipment (e.g., MMEs, HSS, S-GWs, P-GWs in 4G, AMFs, UPFs, AIoT RAN, AIOTF, NEF, AF, etc.) for data routing, mobility and session control, Network Function Virtualization (NFV) and Software-Defined Networking (SDN) for dynamic resource allocation and scalability, Edge Computing Nodes (e.g., MEC servers) for low-latency processing, Backhaul and Transport Equipment (e.g., fiber-optic links, microwave relays, Ethernet switches) to connect base stations to the core network, Network Management Systems (NMS) and Operation Support Systems (OSS) for network configuration, fault management, and optimization, Radio Network Controllers (RNCs) in 3G, Distributed Units (DUs) and Centralized Units (CUs) in 5G, Network Slicing Components for virtualized resource allocation, Security elements (e.g., Firewalls, IDS, AAA Servers) for secure communication.

[0126] Examples of the AIoT device (1000) can include, but are not limited to, smart home devices like switches and locks, asset trackers, RFID tags, sensors for smart buildings and agriculture, wearables, etc.

[0127] The proposed method includes the following technical features as illustrated in the FIG. 1and FIG. 1b:

[0128] 1. An operator decides to configure AIoT.

[0129] 2. The MnS consumer device (100) (referred to as the MnS Consumer from now on) sends a CreateMOI request (e.g, CreateMOI (AIoTNEFMapping) Request) to a MnS producer (400) (implemented inside NEF (Network Exposure Function) (300)) for creating a MOI of AIoTNEFMapping. This includes information as defined in its definition above.

[0130] 3. The MnS producer (400) sends a CreateMOI response (e.g, CreateMOI (AIoTNEFMapping) Response) to the MnS consumer device (100).

[0131] 4. The MnS consumer device (100) sends a CreateMOI request (e.g., CreateMOI (AIoTNRFMapping) Request) to a MnS producer (600) (implemented inside the NRF (500)) for creating a MOI of AIoTNRFMapping. This includes information as defined in its definition above.

[0132] 5. The MnS producer (600) sends a CreateMOI response (e.g., CreateMOI (AIoTNRFMapping) Response) to the MnS consumer device (100).

[0133] 6. The MnS consumer device (100) sends a CreateMOI request (e.g., CreateMOI (AIoTRANinfo) Request) to a MnS producer (800) (implemented as AIOTF (700)) for creating a MOI of AIoTRANInfo. This includes information as defined in its definition above.

[0134] 7. The MnS producer (800) sends a CreateMOI response (e.g., CreateMOI (AIoTRANinfo) Response) to the MnS consumer device (100).

[0135] 8. The AF (200) sends an AIoT service request (e.g., inventory command, etc.) to the NEF (300).

[0136] 9. The NEF (300) obtains (or extracts) the Internal Area information as per AIoTNEFMapping IOC configuration.

[0137] 10. The NEF (300) queries the NRF (500) to obtain serving AIOTF(s) based on internal area information.

[0138] 11. The NRF (500) obtains the AIOTF information (i.e., DN) as per AIoTNRFMapping IOC configuration.

[0139] 12. The NRF (500) provides AIOTF DN to the NEF (300).

[0140] 13. The NEF (300) forwards the AIoT service request, including the internal area information, AIoT device ID, and number of the AIoT devices to the AIOTF.

[0141] 14. The AIOTF (700) obtains AIoT / Service Area Reader ID list, Reader location, etc., as per AIoTRANinfo IOC config.

[0142] 15. The AIOTF (700) selects AIoT RAN node(s) and optionally a list of the RAN readers based on this information of step 14.

[0143] 16. The AIOTF (700) determines the assistance information provided to the AIoT RAN (900) based on the information indirectly received from the AF (200) via the NEF (300).

[0144] 17. The AIOTF (700) provides the assistance information to the AIoT RAN (900) together with the service operation requests containing information such as the AIoT service Area Reader ID list and AIoT device ID.

[0145] 18. Upon reception of the service request message from the AIOTF (700), the AIoT RAN (900) / Reader(s) execute the related service (inventory or command) operations (e.g., paging in RAN, etc.).

[0146] NRM Enhancements: The following text provides the NRM definitions required for the solution depicted above. The AIOTF IOC will be created as per below. This IOC is name contained by ManagedElement IOC as defined in 3GPP TS 28.541 as shown in Table 1.

[0147] Attribute NameSupportCardinalityDescriptionadministrativeStateM (Mandatory)1It determines the administration status of the AIOTF MOI. It is defined in 3GPP TS 28.622operationalStateM1It determines the operations status of the AIOTF MOI. It is defined in 3GPP TS 28.622

[0148] The AIoTNEFMapping IOC is created as per below. This IOC is name contained by NEF IOC as defined in 3GPP TS 28.541 as shown in Table 2.

[0149] Attribute NameSupportCardinalityDescriptionadministrativeStateM1It determines the administration status of the MOI. It is defined in 3GPP TS 28.622operationalStateM1It determines the operations status of the MOI. It is defined in 3GPP TS 28.622TargetAreaM1This is the expected target area as provided by AF and could refer to any of cell / cell ID(list), TAC / TAI(list), PLMN, MCC / MNC, latitude / longitude, CAG cell or any geographical location / coordinate / area polygon.InternalAreaM1This is the 5G core internal area mapped to TargetArea and could refer to any of for example, but not limited to, cell / cell ID(list), TAC / TAI(list), PLMN, MCC / MNC, latitude / longitude, CAG cell or any geographical location / coordinate / area polygon.

[0150] The AIoTNRFMapping IOC is created as per below. This IOC is name contained by NRF IOC as defined in 3GPP TS 28.541 as shown in Table 3.

[0151] Attribute NameSupportCardinalityDescriptionAdmin stateM1It determines the administration status of the MOIOperational stateM1It determines the operations status of the MOIAIOTFdNM1This represents the distinguished name identifier of the AIOTF. It is of type stringInternalAreaM1This is the 5G core internal area mapped to TargetArea and could refer to any of for example, but not limited to, cell / cell ID(list), TAC / TAI(list), PLMN, MCC / MNC, latitude / longitude, CAG cell or any geographical location / coordinate / area polygon.

[0152] The AIoTRANinfo IOC is created as per below. This IOC is name contained by AIOTF IOC as defined as part of this invention as shown in Table 4.

[0153] Attribute NameSupportCardinalityDescriptionAdmin stateM1It determines the administration status of the MOIOperational stateM1It determines the operations status of the MOIAIoTRanServingAreaM1This represents the area served / supported by AIoT RAN. It could refer to any of for example, but not limited to, cell / cell ID(list), TAC / TAI(list), PLMN,MCC / MNC, latitude / longitude, CAG cell or any geographical location / coordinate / area polygonReadersInfoM1...*This represents the list of identifiers (reader index) of the common reader function in AIoT RAN and their locations. Locations here could refer to any of for example, but not limited to, cell / cell ID(list), TAC / TAI(list), PLMN,MCC / MNC, latitude / longitude, CAG cell or any geographical location / coordinate / area polygon This can be of type string.AIoTRanNodeIDM1This represents the identifier of the AIoT RAN node. This can be of type GgNBId <<dataType>> as defined in 3GPP TS 28.541 or can be of type string.

[0154] The proposed method can be used for mapping the targeted area given by the AF (200) to the internal area in the 5G Core via the NEF (300). This mapping is facilitated by the AIoTNEFMapping IOC. Further, the AIoTNRFMapping IOC is designed to facilitate the NRF (500) to provide the AIOTF information such as a DN corresponding to the internal area obtained earlier. Further, the AIoTRANinfo IOC defines the AIoT RAN information that needs to be provided to the AIOTF (700). This enables the AIOTF (700) to select the appropriate AIoT RAN (900) based on the provided RAN information. By leveraging these mappings and information, the AIOTF (700) can ensure that it is interacting with the relevant and optimized network segments, thereby enhancing the efficiency and reliability of ambient IoT service operations.

[0155] The AIoT service operations can now work flawlessly with the help of configurations provided by Operations Administration and Management (OAM). The NEF can obtain internal area mapping corresponding to the target area from OAM and use it for further processes. This ensures that the NEF can accurately identify and interact with the correct internal network segments, leading to targeted service delivery. Further, the NRF can obtain the AIOTF DN corresponding to the internal area for sending service requests to the correct AIOTF. This mapping ensures that data and service requests are routed accurately, reducing latency and improving the overall performance of IoT applications.

[0156] Further, the AIOTF can obtain all AIoT RAN-related information from OAM and can select the correct AIoT RAN nodes / readers for the accurate identification of AIoT devices (1000). This capability maintains the integrity and reliability of the ambient IoT networks as it allows the AIOTF to dynamically adapt to changing network conditions or configurations and ensure that ambient IoT devices are always connected to the suitable RAN nodes. This dynamic selection process not only improves the connectivity and performance of ambient IoT devices but also enhances the overall robustness and scalability of ambient IoT networks within the 5G core.

[0157] The proposed method can be used to enhance their NOS (Network Operations Suite) products with these OAM features related to A-IoT for flawless AIoT service operations and maintain the integrity and reliability of the ambient IoT networks. The proposed method can be used to provide the mapping information between the target area specified by the AF (200) and the 5G core internal area, the mapping information between the Internal Area and the AIOTF DN, and the information required by the AIOTF from OAM (such as AIoT RAN serving area, reader's identifiers (reader index), reader's locations, AIoT RAN Node ID) for selecting AIoT RAN nodes or readers. All this information via OAM configuration enables flawless working of the AIoT service operations and maintains the integrity and reliability of the ambient IoT networks.

[0158] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and / or adapt for various applications such specific embodiments without departing from the generic concept, and therefore such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the scope of the embodiments as described herein.

Claims

1.A method performed by a management entity for an ambient-Internet of Things (A-IoT) service in a wireless communication system, the method comprising:generating AIoTNEFMapping information representing mapping information between a target area which is provided by an application function (AF) and an internal area; andtransmitting, to a network exposure function (NEF) entity, the AIoTMapping information.2.The method of claim 1, wherein the AIoTNEFMapping includes at least one of target area information associated with the A-IoT service, and internal area information which is mapped to the target area.3.The method of claim 1, further comprises:transmitting, to network repository function (NRF) entity, AIoTNRFMapping information representing mapping information between the internal area which is provided by the NEF entity and an ambient IoT function (AIOTF) distinguished name (DN).4.The method of claim 3, wherein the AIoTNRFMapping information includes at least one of internal area information and aIOTFdN information representing a DN identifier of an AIOTF entity corresponding to the internal area.5.The method of claim 1, further comprising:transmitting, to an AIOTF entity, AIoTgNB information for selecting at least one of a base station supporting an A-IoT service and a reader.6.The method of claim 5, wherein the AIoTgNB information includes at least one of an identity of the base station, an identity of the reader served by the base station, information on an area served of the base station and the reader, or information on a reader location.7.A management entity for an ambient-Internet of Things (A-IoT) service in a wireless communication system, the management entity comprising:a transceiver, andat least one processor, coupled to the transceiver and configured to:generate AIoTNEFMapping information representing mapping information between a target area which is provided by an application function (AF) and an internal area, andtransmit, to a network exposure function (NEF) entity via the transceiver, the AIoTMapping information.8.The management entity of claim 7, wherein the AIoTNEFMapping includes at least one of target area information associated with the A-IoT service, and internal area information which is mapped to the target area.9.The management entity of claim 7, wherein the at least one processor is further configured to:transmit, to network repository function (NRF) entity via the transceiver, AIoTNRFMapping information representing mapping information between the internal area which is provided by the NEF entity and an ambient IoT function (AIOTF) distinguished name (DN).10.The management entity of claim 9, wherein the AIoTNRFMapping information includes at least one of internal area information and aIOTFdN information representing a DN identifier of an AIOTF entity corresponding to the internal area.11.The management entity of claim 7, wherein the at least one processor is further configured to:transmitting, to an AIOTF entity, AIoTgNB information for selecting at least one of a base station supporting an A-IoT service and a reader.12.The management entity of claim 11, wherein the AIoTgNB information includes at least one of an identity of the base station, an identity of the reader served by the base station, information on an area served of the base station and the reader, or information on a reader location.

Images