Network observability and QOS provisioning using event-triggered server logic

Abstract

A method implemented by an asset administration shell, AAS, server (118) configured to operate in a network separate from a 3rd Generation Partnership Project, 3GPP, network is provided. The method includes receiving (801), via a first AAS network resource management, NRM, service API and from a device (102), first data for implementing a quality of service, QoS, change in the 3GPP network. The method further includes determining (803), using the first AAS NRM service API and the first data, one or more NRM service related APIs. The method further includes invoking (805) the one or more NRM service related APIs to implement the QoS change.

Description

Network Observability and QoS Provisioning Using Event- Triggered Server LogicTECHNICAL FIELD

[0001] The present disclosure relates generally to wireless communications and, in particular, to methods implemented by an asset administration shell (AAS) server for providing network observability and Quality of Service (QoS) provisioning using event-triggered server logic; and related methods and devices.BACKGROUND

[0002] Traditionally, cellular network configuration is managed through Operations and Maintenance (O&M) interfaces, such as command-line tools or NetConf (Network Configuration Protocol). These interfaces are primarily accessible to network operators, requiring factories to submit Customer Service Requests (CSRs) to Cloud Solution Providers (CSPs) for changes. Handling CSRs is a manual and time-consuming process, though some automation is possible using Network Exposure Function (NEF) APIs specified by the 3rd Generation Partnership Project (3GPP).

[0003] While NEF, introduced in 3GPP Release 15, enabled network programmability, it lacked API discovery support and led to fragmentation. To address this, Common API Framework (CAPIF) was introduced, providing a unified platform for 3GPP Northbound APIs. CAPIF is developed by Technical Specification Group Service and System Aspects (TSG SA) Working Group 6 (WG6), which defines application layer architecture for 3GPP verticals. Additionally, to enhance usability and provide a standardized capability set for 5G verticals, Service Enabler Architecture Layer (SEAL) was defined in 3GPP Technical Specification (TS) 23.434. SEAL APIs facilitate provisioning, connection management, device monitoring, and network resource management, improving system integration for industrial 5G applications, particularly when used with the Vertical Application Layer (VAL).SUMMARY

[0004] There currently exist certain challenges. SEAL enables network observability by providing APIs for real-time performance monitoring through interactions with 3GPP network functions (e.g., core network functions) such as Network Data Analytics Function (NWDAF) and Policy Control Function (PCF), allowing applications to access network insights and detectperformance anomalies. SEAL also supports Quality of Service (QoS) provisioning by allowing applications to dynamically request and adjust network parameters through Network Exposure Function (NEF), Session Management Function (SMF), and Policy Control Function (PCF), ensuring adaptive service quality based on industrial or mission-critical requirements. These capabilities enable seamless integration of 5G connectivity with enterprise applications, enhancing automation and network intelligence. However, implementing SEAL for network observability and QoS provisioning presents challenges related to the number of subscriptions needed, 3GPP traffic overhead, and scalability. Since observability requires continuous monitoring of network performance metrics, a large number of concurrent subscriptions may be required, particularly in industrial deployments with thousands of connected devices. The high volume of subscription requests and notifications can introduce significant signaling traffic, potentially leading to congestion in the core network. Additionally, frequent QoS adjustments through SEAL APIs, particularly in dynamic environments with fluctuating network conditions, may further increase control plane load and impact system performance. Also, while SEAL functions operate within the 3GPP domain, enterprises and factory operators may prefer to remain within the International Electrotechnical Commission (IEC) domain and / or avoid direct management of low-level network metrics, configurations, and functions.

[0005] Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges.

[0006] Some embodiments provide a method implemented by an asset administration shell (AAS) server configured to operate in a network (e.g., a private network, an International Electrotechnical Commission (IEC) network, etc.) separate from a 3rd Generation Partnership Project (3 GPP) network. The method includes receiving, via a first AAS network resource management (NRM) service API and from a device, first data for implementing a QoS change in the 3 GPP network. The method further includes determining, using the first AAS NRM service API and the first data, one or more NRM service related APIs. The method further includes invoking the one or more NRM service related APIs to implement the QoS change.

[0007] Some embodiments provide an AAS server configured to operate in a network separate from a 3GPP network. The AAS server comprises processing circuitry, and memory coupled with the processing circuitry. The memory includes instructions that when executed by the processing circuitry causes the wireless communications device to perform operations. The operations include receiving, via a first AAS NRM service API and from a device, first data for implementing a QoS change in the 3 GPP network. The operations further include determining, using the first AASNRM service API and the first data, one or more NRM service related APIs. The operations further include invoking the one or more NRM service related APIs to implement the QoS change.

[0008] Some embodiments provide a method implemented by a network node. The method includes receiving first data from a device indicating a QoS change to implement in a 3GPP network. The method further includes sending, to a common application programming interface (API) framework (CAPIF) core function, a discovery request for discovering a first AAS NRM service API to implement the QoS change. The method further includes receiving, from the CAPIF core function, a discovery response indicating the first AAS NRM service API. The method further includes invoking the first AAS NRM service API implemented by an AAS server operating a network separate from the 3GPP network to implement the QoS change.

[0009] Some embodiments provide a network node. The network node comprises a processing circuitry and memory coupled with the processing circuitry. The memory includes instructions that when executed by the processing circuitry causes the network node to perform operations. The operations include sending, to a CAPIF core function, a discovery request for discovering a first AAS NRM service API to implement the QoS change. The operations further include receiving, from the CAPIF core function, a discovery response indicating the first AAS NRM service API. The operations further include invoking the first AAS NRM service API implemented by an AAS server operating a network separate from the 3 GPP network to implement the QoS change.

[0010] Some embodiments provide a method implemented by a device configured to communicate with an AAS server configured to operate in a network separate from a 3 GPP network. The method includes obtaining information to communicate with the AAS server. The method further includes sending, to the AAS server, first data for implementing a QoS change in the 3GPP network. The method further includes receiving an indication that the QoS change is implemented in the 3 GPP network.

[0011] Some embodiments provide a device configured to communicate with an AAS server configured to operate in a network separate from a 3GPP network. The device comprises a processing circuitry and memory coupled with the processing circuitry. The memory includes instructions that when executed by the processing circuitry causes the network node to perform operations. The operations include obtaining information to communicate with the AAS server. The operations further include sending, to the AAS server, first data for implementing a QoS change in the 3 GPP network. The operations further include receiving an indication that the QoS change is implemented in the 3GPP network.

[0012] According to some embodiments, a computer program, a computer program product, a non-transitory computer readable medium is provided to perform one of the above methods.

[0013] Certain embodiments may provide one or more of the following technical advantages. In accordance with some embodiments, methods, systems, or mechanisms are provided to represent a mobile network, particularly a network as specified by 3GPP (e.g., a 5G core network, or any other generation of 3GPP networks, like a future 6G network) or related information using AAS or related functionality. For example, by using an AAS server, operators (e.g., a factory or industrial operator) can interact with such a mobile network via a uniform interface, facilitating seamless integration into the industrial domain, enhancing automation, and enabling interoperability across multi-vendor solutions.

[0014] Thereby, the number of monitoring subscriptions required for applications by centralizing logic in the AAS can be reduced, the number of NRM service API calls needed for QoS provisioning can be optimized, and the capabilities of an AAS can be leveraged which is inherently designed to handle a massive number of devices, ensuring scalability for industrial and large-scale deployments.

[0015] In accordance with some embodiments, by using event-triggered server logic (e.g., triggers, change streams, stored functions of an AAS database), an AAS server can perform or trigger network observability, QoS provisioning, or other functions. In accordance with some embodiments, by using an AAS server to perform or implement network observability, QoS provisioning, or other functions, some computational load and traffic from a 3GPP network (e.g., a core network) can be offloaded or reduced, the number of monitoring subscriptions required for various applications (e.g., vertical applications) can be reduced and the number of NRM service API calls needed for QoS provisioning can be reduced or optimized, e.g., in comparison to some other approaches. Further, in accordance with some embodiments, by leveraging an AAS server to perform or implement network observability, QoS provisioning, or other functions, scalability can be improved since AAS architecture is designed to handle a massive number of devices, ensuring scalability for industrial and large-scale deployments.BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The accompanying drawings, which are included to provide a further understanding of the disclosure and are incorporated in and constitute a part of this application, illustrate certain non-limiting embodiments of the present disclosure. In the drawings:

[0017] FIG. 1 is a block diagram of an example observability environment 100 illustrating a vertical application (VA) server (VAS) and a user equipment (UE) interacting with a 3rdGeneration Partnership Project (3 GPP) network via network exposure application programming interfaces (APIs) according to some embodiments;

[0018] FIG. 2 is a block diagram of an example Quality of Service (QoS) provisioning environment illustrating Vertical Application Service Enabling Architecture Layer (VASEAL) elements according to some embodiments;

[0019] FIG. 3 is a block diagram of an example communications environment illustrating an asset administration shell (AAS) server utilizing event-trigger server logic to perform various functions according to some embodiments;

[0020] FIG. 4 is a signal flow chart illustrating various example operations associated with the environment of FIG. 3 in accordance with some embodiments;

[0021] FIG. 5 is bar chart illustrating example traffic and computational loads of the environment of FIG. 1;

[0022] FIG. 6 is bar chart illustrating example traffic and computational loads of the environment of FIG. 2;

[0023] FIG. 7 is bar chart illustrating example traffic and computational loads of the environment of FIG. 3;

[0024] FIG. 8 is a flow chart illustrating an example of operations performed by an asset administration shell (AAS) server in accordance with some embodiments;

[0025] FIG. 9 is a flow chart illustrating an example of operations performed by a network node in accordance with some embodiments;

[0026] FIG. 10 is a flow chart illustrating an example of operations performed by a device in accordance with some embodiments;

[0027] FIG. 11 is a block diagram of a communication system in accordance with some embodiments;

[0028] FIG. 12 is a block diagram of another communication system in accordance with some embodiments;

[0029] FIG. 13 is a block diagram of a user equipment in accordance with some embodiments;

[0030] FIG. 14 is a block diagram of a network node in accordance with some embodiments; and

[0031] FIG. 15 is a block diagram of a virtualization environment in accordance with some embodiments.DETAILED DESCRIPTION

[0032] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art, in which examples of embodiments of the present disclosure are shown. Inventive concepts may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the present disclosure to those skilled in the art. It should also be noted that these embodiments are not mutually exclusive. Components from one embodiment may be tacitly assumed to be present / used in another embodiment.

[0033] SEAL enables network observability by providing APIs for real-time performance monitoring through interactions with 3GPP network functions (e.g., core network functions) such as Network Data Analytics Function (NWDAF) and Policy Control Function (PCF), allowing applications to access network insights and detect performance anomalies. SEAL also supports Quality of Service (QoS) provisioning by allowing applications to dynamically request and adjust network parameters through Network Exposure Function (NEF), Session Management Function (SMF), and Policy Control Function (PCF), ensuring adaptive service quality based on industrial or mission-critical requirements. These capabilities enable integration of 5G connectivity with enterprise applications, enhancing automation and network intelligence. However, implementing SEAL for network observability and QoS provisioning presents challenges related to the number of subscriptions needed, 3GPP traffic overhead, and scalability. Since observability requires continuous monitoring of network performance metrics, a large number of concurrent subscriptions may be required, particularly in industrial deployments with thousands of connected devices. The high volume of subscription requests and notifications can introduce significant signaling traffic, potentially leading to congestion in the core network. Additionally, frequent QoS adjustments through SEAL APIs, particularly in dynamic environments with fluctuating network conditions, may further increase control plane load and impact system performance. Also, while SEAL functions operate within the 3GPP domain, enterprises and factory operators may prefer to remain within the International Electrotechnical Commission (IEC) domain and / or avoid direct management of low-level network metrics, configurations, and functions.

[0034] One or more embodiments described herein utilize an AAS server (e.g., configured to operate in a network separate from a 3 GPP network or core network) with event-triggered server logic (also referred to as server side logic) to perform or implement network observability, QoSprovisioning, or other functions. In accordance with some embodiments, by using an AAS server to perform or implement network observability, QoS provisioning, or other functions, some computational load and traffic from a 3GPP network (e.g., a core network) may be offloaded or reduced, the number of monitoring subscriptions required for various applications (e.g., vertical applications) and the number of NRM service API calls needed for QoS provisioning can be reduced, e.g., in comparison to some other approaches. Further, in accordance with some embodiments, by leveraging an AAS server to perform or implement network observability, QoS provisioning, or other functions, scalability can be improved since AAS architecture is designed to handle a high number of devices, ensuring scalability for industrial and large-scale deployments.

[0035] It is noted that various embodiments reside primarily in combinations of apparatus components and processing steps. Accordingly, components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein. Like numbers refer to like elements throughout the description.

[0036] As used herein, relational terms, such as “first” and “second,” “top” and “bottom,” and the like, may be used solely to distinguish one entity or element from another entity or element without necessarily requiring or implying any physical or logical relationship or order between such entities or elements. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting to the concepts described herein. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes” and / or “including” when used herein, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0037] In embodiments described herein, the joining term, “in communication with” and the like, may be used to indicate electrical or data communication, which may be accomplished by physical contact, induction, electromagnetic radiation, radio signaling, infrared signaling or optical signaling, for example. One having ordinary skill in the art will appreciate that multiple components may interoperate and modifications and variations are possible of achieving the electrical and data communication.

[0038] In some embodiments described herein, the term “coupled,” “connected,” and the like, may be used herein to indicate a connection, although not necessarily directly, and may include wired and / or wireless connections.

[0039] The term “network node” used herein can be any kind of network node comprised in a network, particularly a network as defined by 3GPP, like a 5G network or future generations like 6G. Herein, this may particularly be a core network node, like NEF, PCF, NWDAF, SEAL server, ECS, or generally a network function provided in a 3GPP network.

[0040] In some embodiments, the non-limiting terms wireless device (WD), wireless communications device, or a user equipment (UE) are used interchangeably. The WD herein can be any type of wireless device capable of communicating with a network node or another WD over radio signals, such as a user equipment (UE). The WD / UE may also be a radio communication device, target device, device to device (D2D) WD, machine type WD or WD capable of machine to machine communication (M2M), low-cost and / or low-complexity WD, a sensor equipped with WD, Tablet, mobile terminals, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), USB dongles, Customer Premises Equipment (CPE), an Internet of Things (loT) device, or a Narrowband loT (NB-IOT) device etc.

[0041] Note that although terminology from one particular wireless system, such as, for example, 3GPP LTE and / or 5G, may be used in this disclosure, this should not be seen as limiting the scope of the disclosure to only the aforementioned system. Other networks, particularly future generations of 3GPP defined networks, may also benefit from the procedures described herein.

[0042] Note further, that functions described herein as being performed by a wireless device, a network node or a server may be distributed over a plurality of wireless devices, network nodes and / or servers. In other words, it is contemplated that the functions of the network node, server and wireless device described herein are not limited to performance by a single physical device and, in fact, can be distributed among several physical or virtual devices.

[0043] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. It will be further understood that terms used herein should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

[0044] I. INTRODUCTION

[0045] The latest Fifth generation of mobile communications (5G) standards (Releases 15-18) and the Industry 4.0 revolution have shifted 3GPP’s focus beyond traditional consumer needs(e.g., higher speeds, better coverage) toward enabling advanced communication capabilities for vertical industries such as public safety, automotive, drones, factories, and Internet of Things (loT). These enhancements aim to provide native support for industry specific requirements within the 5G system.

[0046] Therein, application enablement standards have gained prominence, allowing third-party developers and vertical-specific providers to fully leverage 3GPP capabilities. Within the Technical Specification Group Service and System Aspects (TSG SA), Working Group 6 (SA6) focuses on application-layer architecture for vertical markets, including critical communication applications, service frameworks, and vertical enablers.

[0047] SA6 standards provide two key features relevant to Vertical Application Layer (VAL) application (also known as vertical application (VA)) development: (a) network performance observability and (b) resource management functions, including QoS provisioning. These capabilities facilitate seamless integration and enhanced performance for vertical applications.

[0048] While these functions operate within the 3GPP domain, enterprises and factory operators typically prefer to remain within the IEC domain, avoiding direct management of low-level network metrics, configurations, and functions. Instead, they seek a simplified, abstracted view of the network with self-configuration capabilities to adapt dynamically to production requirements. By representing the 5G system through AAS - a standardized practice in the industrial ecosystem - factory operators can interact with 5G via a uniform interface, facilitating seamless integration into the industrial domain, enhancing automation, and enabling interoperability across multivendor solutions.

[0049] The present subject matter includes an examination of the Open Platform Communications (OPC) Unified Architecture (UA) industrial protocol as a case study, analyzing its capability to support real-time data transmission and identifying key bottlenecks. The examination of OPC UA highlights a potential need for an AAS extension in OPC UA-based deployments and explores the commonalities and differences between the two frameworks. From the 3GPP-defined VAL layer, the present subject matter demonstrates how 3GPP 5G networks can support real-time data transmission and provides application developers with options to reserve the required transmission channels. In some embodiments, a proposed system consolidates relevant features of current 3GPP SA6 standards, IEC AAS, the Target-X EU project, and other related works, focusing on network observability and QoS provisioning. Detailed diagrams are included to illustrate the distinctions among various network functions. Additionally, the present subject matter includes an extension to existing architectures incorporating event-triggered serverlogic. The present subject matter includes details about a proposed AAS-based NRM system implemented in a robotic scenario and evaluated to demonstrate its benefits.

[0050] II. RELATED WORK

[0051] “Using Digital Twins to Integrate 5G into Production Networks.” [Online], Available: https: / / 5g-acia.org / whitepapers / using-digitaltwins-to-integrate-5g-into-production-networks / (hereafter, “Digital Twins”) defines tentative submodels, parameters, and properties based on the current 5G definitions provided by 3GPP. It offers an initial list of attributes necessary for 5G AAS submodels, identifying key information required to describe a 5G network and 5G User Equipment (UE) throughout an industrial life cycle. The document also proposes additional interfaces between the 3GPP 5G system and AAS repositories.

[0052] T.-X. Project, “Design and Implementation of Required Submodels, Exposures, and Interfaces,” Tech. Rep., 2024. [Online], Available: https: / / target-x.eu / wp-content / uploads / 2024 / 02 / TARGETX D6.3 vl .O-Design-and-Implementation-of-Required-Submodels-Exposures-and-Interfaces.pdf (hereinafter, Target-X Deliverable 6.3) focuses on aligning the design phase of AAS with the data and service capabilities of networks and devices to enhance their utility. Target-X Deliverable 6.3 highlights the role of AAS in network automation and orchestration, detailing the use of common service exposure APIs and the associated network and device capabilities. The deliverable defines submodels for integration into 5G Network and 5GUE AAS instances, enabling knowledge exchange among AAS instances representing various assets. These submodels collectively support automated network management and orchestration. Additionally, the document underscores the role of AAS, leveraging its Digital Twin (DT) capabilities as a framework for enabling automated processes in network and asset orchestration.

[0053] III. OBSERVABILITY

[0054] This section discusses the network observability functions offered by various layers. An example observability environment is illustrated in FIG. 1.

[0055] FIG. 1 is a block diagram of an example observability environment 100 illustrating vertical application (VA) server (VAS) 114 and user equipment (UE) 102 interacting with a 3GPP network via network exposure application programming interfaces (APIs) according to some embodiments. As depicted in FIG. 1, the UE 102 includes vertical application (VA) client(s) (VACs) 104, an Open Platform Communications Unified Architecture (OPC UA) client 106, an Asset Administration Shell (AAS) client 108, an Application Data Analytics Enablement (ADAE) client 110, and a Service Enabler Architecture Layer (SEAL) Connection Monitoring Client 112. The OPC UA client 106 utilizes a Message Queuing Telemetry Transport (MQTT) Client 112 and obtains and references OPC UA information models 113 to facilitate data exchange. The VAS 114includes a VA Controller 116, an AAS Server 118, an ADAE Server 120, and a SEAL Connection Monitoring Server 122. The VA Controller 116 includes an OPC UA Server 124. The OPC UA client 106 utilizes an MQTT Broker 126 and OPC UA information models 127 to manage and distribute various data. The UE 102 and the VAS 114 communicate with the 3GPP network 130 via various network exposure application programming interfaces (APIs) 128, which provide or include SEAL connection monitoring 132, a Network Exposure Function (NEF) 134, a Service Capability Exposure Function (SCEF) 136, and ADAE services 138 for interaction with external applications. A Network Data Analytics Function (NWDAF) 140 obtains application server observability data, allowing generation of performance analytics that can be employed to optimize QoS or other resource management tasks. The lines and arrows indicate representative data or communications among elements, and the illustrated arrangement may be altered or substituted by equivalent functionality without departing from the inventive concepts.

[0056] In some embodiments, OPC UA client 106 includes a publisher element and an OPC UA to SEAL mapper element that automatically converts OPC UA data into a format compatible with SEAL Connection Monitoring Client 112. In some embodiments, the OPC UA Server 124 includes a subscriber element configured to retrieve or filter data from the OPC UA information models 127, thereby enabling flexible access to operational or device-level parameters. In some examples, the ADAE client 110 and ADAE Server 120 may facilitate application -level connection quality monitoring and analytics, whereas the SEAL Connection Monitoring Client 112 and the SEAL Connection Monitoring Server 122 may facilitate bearer-level connection quality monitoring and analytics. The NWDAF 140, in turn, may collect 3 GPP network performance metrics (e.g., core network performance metrics) or other operational statistics, incorporating this data into analytics that inform QoS or policy decisions. In some embodiments, the NWDAF 140 may write NWDAF-derived analytics into a submodel (e.g., a “Dispersion Analytics” submodel) for consumption by AAS server 118 and / or various industrial systems.

[0057] Additional aspects, embodiments, and / or details related to the observability environment 100 or elements therein are discussed below.

[0058] A. VAL Layer

[0059] 1) OPC UA: OPC UA is primarily developed for real-time communication and control in automation systems. OPC UA focuses on defining and structuring real-time process data (e.g., sensor values, operational states), making them particularly suitable for machine-to-machine communication and process control.

[0060] a) Communication: OPC UA has various operation modes. Its primary goals are interoperability, scalability, and security for industrial automation systems. However, recentextensions and features, such as the OPC UA PubSub model, aim to address some real-time communication requirements extended with QoS configurability support. OPC UA can address soft real-time communication, not hard-real timing like PROFINET or EtherCAT.

[0061] Using MQTT as the transport layer, the PubSub model provides a lightweight and efficient mechanism for data exchange, suitable for applications requiring low latency. However, MQTT does not guarantee deterministic behavior, which limits its use in strict real-time control systems.

[0062] In contrast, the user datagram protocol (UDP)-based PubSub model is better aligned with real-time requirements, as it offers lower latency due to its connectionless, peer-to-peer communication approach. When UDP is combined with Time- Sensitive Networking (TSN), OPC UA can achieve deterministic communication, making it viable for hard real-time applications. Moreover, the broker-less nature of UDP -based PubSub eliminates delays associated with centralized message brokers, further improving responsiveness.

[0063] OPC UA uses information models to define the structure, relationships, and semantics of data within an industrial system. These models provide a standardized way to represent devices, processes, and systems, facilitating interoperability and integration.

[0064] b) Data storage: There is an intrinsic storage capability of the protocol at the brokers. Though OPC UA itself does not define a standardized way for persistent storage within its framework. Instead, it enables real-time access to data through nodes that can be updated or queried. The actual data is typically stored in the underlying systems or devices (e.g., PLCs, databases) that the OPC UA server interfaces with.

[0065] c) Network Statistics: OPC UA provides a feature called Diagnosticinfo (see “OPC Foundation 7.8 Diagnosticinfo,” May 2023. [Online], Available: https: / / reference.opcfoundation.Org / Core / Part4 / vl04 / docs / 7.8), which provides details on the performance of the OPC UA communication. This includes information on the server, session, and subscription diagnostic information such as Publishinginterval -Count, TransferRequest-Count, Security RejectedSessi on-Count and many other information elements. Note that the certain nodes that provide the diagnostic information rely mostly on the underlying network layer if they populate the necessary information and, in certain configurations, the network may not provide these metrics, causing many of the diagnostic nodes to remain empty.

[0066] 2) AAS: The AAS or AAS server acts as a “digital nameplate” and central repository for all asset-related information, covering metadata, history, configuration, and operational data across an asset’s lifecycle. It uses a modular structure with submodels (e.g., condition monitoring,documentation, and usage data) which makes it ideal for representing comprehensive, high-level asset data across diverse use cases.

[0067] a) Communication: The AAS often relies on Hypertext Transfer Protocol (HTTP) / Representational State Transfer (REST) or MQTT for communication, aligning with general loT and Industry 4.0 requirements where flexibility and data sharing across various systems are key. In the AAS ecosystem, common information models are used to standardize the representation of assets, processes, and their interactions, similar to how OPC UA defines its information models. These models, called submodels, are modular and reusable structures that describe specific aspects or functions of an asset, ensuring interoperability in Industry 4.0 applications. The development and standardization of AAS models are driven by initiatives like Platform Industrie 4.0, VDI / VDE guidelines, and international standards bodies like IEC and ISO. These efforts ensure that submodels align with industrial requirements and remain interoperable across systems.

[0068] While AAS submodels share similarities with OPC UA information models - such as being modular, reusable, and designed for interoperability - they differ in focus. OPC UA models emphasize runtime communication and live data access, while AAS (sub)models concentrate on lifecycle management and integration with higher-level systems like Manufacturing Execution System (MES) and Enterprise Resource Planning (ERP). Together, they provide complementary solutions for Industry 4.0, ensuring seamless integration of assets across industrial ecosystems.

[0069] b) Data storage: AAS includes specifications for persistent storage, allowing it to act as a central repository of information about an asset. It can serve as a database for asset-related data, holding information across the asset’s lifecycle.

[0070] B. 3GPP network (e.g., 5G Core Network)

[0071] 1) SEAL Connection Monitoring (described e.g. in 3GPP TS 23.434): This function specifically focuses on monitoring the status and quality of network connections. It provides realtime insights into connectivity issues, such as connection setup times, quality degradation, and connection loss.

[0072] 2) ADAE (described e.g. in 3GPP TS 23.436): ADAE centers on application-level analytics, delivering insights on how applications are performing within the network. It covers metrics like application latency, response times, and Quality of Experience (QoE) specific to the application layer.

[0073] 3) Network Data Analytics Function (described e.g. in 3GPP TS 23.288): NWDAF operates at the core network level and collects data from network functions such as Access and Mobility Management Function (AMF), SMF, and PCF. Its insights primarily focus on networkconditions like user mobility, session management, and QoS optimization. NWDAF supports network slice management and resource allocation based on usage patterns and predicted demand. NWDAF’ s ability to analyze detailed application-level QoE metrics relies on collaboration with applications to expose such data. Without this, NWDAF primarily focuses on correlating networklevel QoS with user-level experiences.

[0074] Each function is accessible via 3GPP-defined exposure APIs and operates its own data collection, processing, and storage mechanisms. These functions are interconnected through interfaces that facilitate data sharing and contextualization across application and network layers as required. For instance, in a remote manufacturing environment, Connection Monitoring ensures network stability, while ADAE provides end-to-end application insights, enabling real-time optimization of both connection reliability and overall application performance.

[0075] However, a potential limitation of the environment 100 is that VAL developers must interact with multiple databases, each with distinct API sets, to obtain connectivity performance data. Additionally, the reliance on built-in persistent storage across various layers and the inherent storage mechanisms of loT protocols reduces the system’s capability to operate in real-time.

[0076] C. Relation of 3GPP and AAS

[0077] Target-X Deliverable 6.3 defines various AAS submodels, including a QoS submodel outlined in § 4.2.3; the general approach of populating the AAS with 3GPP network QoS-related information via network exposure interfaces can be used as basis for the present disclosure.

[0078] IV. QOS PROVISIONING

[0079] This section discusses the available functions for QoS provisioning. An example environment associated with QoS provisioning is depicted in FIG. 2.

[0080] FIG. 2 is a block diagram of an example Quality of Service (QoS) provisioning environment 200 illustrating Vertical Application Service Enabling Architecture Layer (VASEAL) elements according to some embodiments. As depicted in FIG. 2, a UE 102 includes VAC(s) 104, an OPC UA client 106, a SEALDD client 208, an application enabler client (AEC) 210, an edge enabler client (EEC) 211, and a SEAL network resource adaptation client 212. The OPC UA client 106 includes a VASEAL Resource Management element 202, a publisher 204, and an MQTT client 112. The environment 200 also includes a VAS 114. The VAS 114 includes a VA controller 116, a SEALDD server 218, an application enabler server (AES) 220, a SEAL network resource adaptation server 222, and an EES 224. The VA controller 116 includes an OPC UA server 124 with a subscriber 206 and an MQTT broker 126. The UE 102 and the VAS 114 communicate with the 3GPP network 130 via various network exposure APIs 128, e.g., SEAL services 226, aNEF 134, a SCEF 136, and an edge configuration server (ECS) 234. SEAL services226 include a NRM 228, a SEALDD 230, and a network slice adaptation 232. The NRM 228 or the SEAL network resource adaptation server 222 may include CAPIF functionality (e.g., an NRM API discovery function 244 and an NRM API invoker 246) for discovering and using NRM service related APIs. The environment 200 also includes a CAPIF core function 248 for providing a unified framework for exposing and managing APIs. Lines and arrows may indicate representative data or communications among elements, and the configuration may be modified or extended without departing from the underlying principles.

[0081] In some embodiments, VASEAL Resource Management element 202 coordinates QoS-related functions between the OPC UA client 106 and SEALDD client 208, allowing the publisher 204 to share data in a manner that reflects dynamic resource conditions. In other examples, subscriber 206 interacts with OPC UA server 124 to filter or retrieve information for the SEALDD server 218 or the AES 220. The SEAL network resource adaptation client 212 and server 222 can coordinate network resource adjustments, while EES 224 may provide additional edge-based functionalities. By leveraging SEAL services 226, including the NRM 228 and the SEALDD 230, the depicted architecture can adapt network slices or invoke APIs 128 exposed by NEF 134, SCEF 136, or ECS 234, ensuring flexible management of connectivity and computing resources.

[0082] Additional aspects, embodiments, and / or details related to the QoS provisioning environment 200 or elements therein are discussed below.

[0083] A. VAL Layer

[0084] G. Szabo, “Towards the automatic network resource management of OPC UA in 5G private networks,” (Computer Networks, vol. 250, p. 110581, 2024. [Online], Available: https : / / www.sciencedirect. com / science / article / pii / S1389128624004134) introduces a method for integrating VAL NRM capabilities into the 3GPP domain, enabling the discovery and management of VAL application NRM capabilities within the 3GPP network through the publication of these capabilities via CAPIF.

[0085] B. Core Network

[0086] a) EdgeApp Session with QoS (described e.g. in TS 23.548): The EdgeApp feature allows applications operating at the edge to establish sessions with specific QoS guarantees. Its scope spans the VAL and the Core Network, with a primary focus on session-specific QoS for edge-hosted applications.

[0087] b) SEAL Network Resource Adaptation (described e.g. in TS 23.434): SEAL functionality enables applications to request network resource adaptations to improveperformance. The focus is on application-driven QoS within both the VAL and the Core Network, leveraging dynamic resource management.

[0088] c) SEAL Network Slice Adaptation (described e.g. in TS 23.434): This method allows for dynamic adjustments of network slices to meet diverse application or service requirements. While its focus lies in the Core Network, it also has implications for the Radio Network.

[0089] d) SEALDD Data Transmission (described e.g. in TS 23.434): This feature ensures deterministic and reliable data delivery for SEAL applications, particularly in time-sensitive scenarios. It introduces mechanisms for achieving low-latency and highly reliable transmissions. The scope extends across the VAL, Core Network, and Radio Network, focusing on end-to-end QoS for data delivery.

[0090] e) SCEF-AS AS Session with QoS (described e.g. in TS 23.682): This functionality allows application servers, via the SCEF, to initiate sessions with specific QoS requirements. The focus domain includes external application servers and the Core Network, with session-specific QoS targeting external application needs.

[0091] The features in 3GPP Release 18 share the common goal of enhancing application and service performance, but they differ in scope and focus. EdgeApp and SCEF-AS primarily address session-level QoS management, enabling applications at the edge or application servers to guarantee specific quality requirements. In contrast, SEAL Network Resource Adaptation and SEALDD Data Transmission focus on optimizing SEAL applications, with SEALDD specifically targeting deterministic and reliable data delivery for time-sensitive use cases. Network Slice Adaptation, on the other hand, operates at a broader level by dynamically adjusting slice-wide configurations to meet the requirements of various services. While EdgeApp and SEALDD are more relevant for latency-sensitive and industrial applications, SCEF-AS provides a generic mechanism for QoS management applicable to diverse use cases.

[0092] V. SYSTEM WITH EVENT-TRIGGERED SERVER LOGIC

[0093] This section discusses an exemplary implementation of an AAS-based NRM system capable of performing QoS provisioning in accordance with various aspects described herein. The NRM system utilizes an AAS. The AAS is assumed to have collected all the necessary information required for QoS provisioning, e.g., it is aware of all application requirements and has access to the data reported by all relevant 3 GPP monitoring functions. In particular, the implemented NRM system leverages the AAS functionality by integrating the NRM business logic directly into the IEC domain, specifically within the AAS server. This centralization of decision-making in the AAS server streamlines the QoS provisioning process and enhances system efficiency.

[0094] The AAS server in the implemented NRM system serves as the central trigger for QoS provisioning by adding event-triggered server side logic (e.g., triggers, change streams, stored functions in short in server side SQL) to the AAS database to manage NRM processes or related functions. The implemented AAS-based NRM system is exemplarily shown in FIG. 3.

[0095] FIG. 3 is a block diagram of an example communications environment 300 illustrating an AAS server 118 utilizing event-trigger server logic 302 to perform various functions according to some embodiments. As depicted in FIG. 3, a UE 102 includes VAC(s) 104, an OPC UA client 106, a SEALDD client 208, an AAS client 108, and a SEAL network resource adaptation client 212. The OPC UA client 106 includes a VASEAL Resource Management element 202, a publisher 204, and an MQTT client 112. The environment 300 also includes a VAS 114. The VAS 114 includes a VA controller 116, the AAS server 118 with event-triggered server logic 302, an AES 220, a SEALDD server 218, a SEAL network resource adaptation server 222, and an AAS registry 304. The VAS 114 and / or controller 116 includes CAPIF functionality (e.g., an NRM API discovery function 314 and an NRM API invoker 316) for discovering and using AAS NRM APIs or other NRM service related APIs. The AAS server includes CAPIF functionality to publish and facilitate usage of AAS NRM APIs for performing QoS provisioning or NRM related tasks and may also use CAPIF functionality for discovering and using other NRM service related APIs. The AAS server 118 includes an AAS NRM API publishing function 306, an AAS NRM API discovery function 308, an AAS NRM API invoker 310, and an AAS NRM service function 312. The VA controller 116 includes an OPC UA server 124 with a subscriber 206 and an MQTT broker 126. The UE 102 and the VAS 114 communicate with the 3 GPP network 130 via various network exposure APIs 128, e.g., SEAL services 226, aNEF 134, a SCEF 136, and an edge configuration server (ECS) 234. SEAL services 226 include the NRM 228, the SEALDD 230, and the network slice adaptation 232. The NRM 228 or the SEAL network resource adaptation server 222 may include CAPIF functionality (e.g., an NRM API discovery function 244 and an NRM API invoker 246) for discovering and using AAS NRM APIs or other NRM service related APIs. The environment 300 also includes a CAPIF core function 248 for providing a unified framework for exposing and managing APIs, including the AAS NRM APIs, to various nodes or devices.

[0096] In some embodiments, to provide QoS provisioning and / or NRM related tasks, the AAS server’s NRM capabilities may be published as AAS NRM APIs via the AAS NRM API publishing function 306. For example, the AAS NRM API publishing function 306 can provide information about the AAS NRM API publishing function 306 to the CAPIF core function 248. In some embodiments, each AAS NRM API may be associated with a particular event-trigger serverlogic 302 (e.g., an AAS database stored trigger or code) for performing a particular task or set of tasks.

[0097] In some embodiments, event-trigger server logic 302 or related code (e.g., a trigger) may be capable of collecting information (e.g., API endpoints, supported methods, capabilities, usage policies security requirements, metadata, etc.) for interacting with NRM-capable AFs and NRM-capable NFs (e.g., which are not registered by the AAS registry 304) via the AAS NRM API discovery function 308 and able to use the information to communicate with such entities and / or manage the interactions.

[0098] In some embodiments, event-trigger server logic 302 or related code (e.g., a trigger) may fire or utilize the AAS NRM API invoker 310, which can invoke the AAS NRM service function 312 or other services via one or more NRM related APIs. For example, in addition to the AAS NRM service API calls within the VAL layer, event-triggered server logic can also initiate 3GPP -related QoS provisioning services, e.g., initiating a “SEALDD Data Transmission” with appropriate QoS settings call towards the SEALDD server 218, initiating a “Session with QoS” API call towards the AES 220, issuing a “Network Resource Adaptation” call directed at the SEAL network resource adaptation server 222, initiating an “AS Session with QoS” call towards the SCEF, etc.

[0099] In some embodiments, an AAS or AAS database may be implemented using any suitable software platform or database system, including but not limited to MongoDB, PostgreSQL, or distributed ledger technologies, thereby allowing flexible configuration for scalability, redundancy, and data model representation. In some embodiments, event-triggered server logic may be used to handle incoming data streams or property updates, automatically generating notifications or invoking relevant subroutines when specific conditions are met. Such an approach permits responsive, on-demand processing of asset-related information, enhancing the overall reliability and efficiency of the AAS architecture. In some embodiments, triggers or change streams may be employed to monitor database events in real time. For example, MongoDB’s change streams can detect inserts or updates to relevant collections, while SQL triggers in relational systems can evaluate conditions and call specified code whenever those conditions are satisfied. An example of a event-triggered server logic is discussed below.

[0100] For example, consider the following MongoDB change stream trigger code. The code listens for updates to a collection and, upon detecting that a field named “UEl required bw” has been changed to the value 5 (Mbps), calls a function named NRM_API(“UE2”). In this example, the trigger code may be invoked when an operational camera (“UE2”) is required to release bandwidth in order to allow a different camera (“UE1”) to operate on a limited radio channel:const { MongoClient } = require('mongodb');async function main() {const client = new MongoClient('mongodb: / / localhost:27017');await client.connect();const db = client. db('yourDatabase');const collection = db.collection('yourCollection');const changeStream = collection.watch([{$match: {“updateDescription.updatedFields.UEl required bw”: 5}}]);changeStream. on(“change”, (change) => {console. log(“Detected change:”, change);NRM_API(“UE2”);});}function NRM_API(UE) {console. log(' Calling NRM_API with ${UE}'); / / Implement the actual API call logic here}main();

[0101] In the above example, the code connects to a MongoDB database and creates a change stream on the specified collection to watch for updates to the “UEl required bw” field. Whenever that field changes to 5, the script logs the detected event and calls the NRM_API(“UE2”) function. The NRM_API(“UE2”) function can be implemented to invoke a network resource management process, e.g., make the AAS server 118 or an application in the VAL layer adapt its traffic for an NRM request. For example, in some embodiments, the NRM_API(“UE2”) function may call or interact with a "Production cell resource management" module within VASEAL to reallocate bandwidth from UE2 to meet UEl’s operational requirements, while in some other embodiments, this function may call or interact with the URCapIF interface to achieve similar outcomes. By leveraging MongoDB’s change stream feature, the application can react in real time to database updates and seamlessly integrate external logic for bandwidth or traffic adaptation.

[0102] In some embodiments, to facilitate QoS provisioning, a desired VAL parameter (e.g., the VAL application speed) may be set or modified (e.g., by the AAS NRM API invoker 310 or another entity) via an AAS submodel in the AAS server 118. In some embodiments, e.g., when the AAS NRM API invoker 310 specifies the desired VAL application speed, predefined event-triggered server logic (e.g., trigger(s), code, etc.) may evaluate this value and subsequently invoke the AAS NRM service function 312. For example, the AAS NRM service function 312 may modify the local copy of the AAS submodel on the AAS client 108, which in turn may trigger the “VASEAL Resource Management” service API of the VAL application registered in the AAS registry.

[0103] FIG. 4 is a signal flow chart illustrating various example operations associated with the environment of FIG. 3 in accordance with some embodiments. In FIG. 4, a setup phase involving the AAS server 118 is depicted. The setup phase includes an AAS publish request (401) from the AAS client 108 to the AAS registry 304 for registering the AAS client 108 in the AAS registry 304; an API publishing request (403) from the AAS NRM API publishing function 306 (of AAS server 118) to the CAPIF core network 248 for publishing AAS NRM APIs; an API discovery request (405) from the AAS NRM API discovery function 308 (of AAS server 118) to the CAPIF core network 248 for requesting information about particular services or NRM related APIs published with the CAPIF core function 248; and an API discovery response (407) from the CAPIF core function 248 to the AAS NRM API discovery function 308 (of AAS server 118) for receiving information about particular services or NRM related APIs.

[0104] In FIG. 4, an AAS operation phase is also depicted. The AAS operation phase includes an update submodel request / command (409) sent from the AAS client 108 to the AAS server 118; a call (411) from the AAS server 118 to the AAS NRM API invoker 310; a call or command (413) from the AAS NRM API invoker 310 to the AAS NRM service function 312 for triggering 3 GPP-related QoS provisioning services; a “Network Resource Adaptation” call (415) from the AAS NRM service function 312 to the SEAL network resource adaptation server 222 (also may be referred to as a SEAL NRM server), a “Session with QoS” API call (417) from the AAS NRM service function 312 to the AES 220, and an “AS Session with QoS” call (419) from the AAS NRM service function 312 to the SCEF.

[0105] In FIG. 4, a VA Server / Controller example is also depicted. The VA Server / Controller example represents a scenario where the AAS NRM service API is triggered by directly calling it from other VAL applications e.g., a call from an NRM API invoker 316 of VAS 114 or controller 116. The VA Server / Controller example includes an API discovery request 421 from the NRM API discovery function 314 (of VAS 114) to the CAPIF core network 248 for requestinginformation about an AAS NRM API published with the CAPIF core function 248; and an API discovery response (423) from the CAPIF core network 248 to the NRM API discovery function 314 (of VAS 114) for receiving information about the requested AAS NRM API; and a call or command (425) from the AAS NRM API invoker 310 to the AAS NRM service function 312 for triggering the QoS provisioning and / or other task(s).

[0106] In FIG. 4, a SEAL NRM Server example is also depicted. The SEAL NRM Server example represents a scenario where the network or a node therein triggers or initiates a QoS change. For example, the NRM API invoker 246 of the SEAL network resource adaptation server 222 or NRM 228 may trigger the AAS NRM service function 312 of the AAS server 118 to perform a QoS change or provisioning task. The SEAL NRM Server example includes a QoS change indication (427) from SEAL network resource adaptation server 222 (or NRM 228) to an adaptation trigger (of server 222 / NRM 228); an API discovery request (429) from the NRM API discovery function 244 (of server 222 / NRM 228) to the CAPIF core network 248 for requesting information about an AAS NRM API published with the CAPIF core function 248; and an API discovery response (431) from the CAPIF core network 248 to the NRM API discovery function 244 (of server 222 / NRM 228) for receiving information about the requested AAS NRM API; and a call or command (433) from the NRM API invoker 246 (of server 222 / NRM 228) to the AAS NRM API invoker 310 for calling the AAS NRM service function 312 to trigger the QoS provisioning and / or other task(s).

[0107] As indicated herein, the implemented AAS-based NRM system or similar embodiments offer various advantages compared to other approaches. Firstly, an AAS-based NRM system in accordance with aspects described herein can significantly reduce the number of monitoring subscriptions required for the applications by centralizing the logic in the AAS. Also, an AAS-based NRM system in accordance with aspects described herein can optimize the number of NRM service API calls needed for QoS provisioning. Further, by leveraging the AAS, which is inherently designed to handle a massive number of devices, an AAS-based NRM system in accordance with aspects described herein can provide scalability for industrial and large-scale deployments.

[0108] VI. EVALUATION

[0109] This section includes an assessment of the performance of an implemented NRM system in accordance with various aspects described herein under various deployment scenarios.

[0110] A. Implementation[oni] The UE side and core network side implementations are discussed in the following subsections.

[0112] 1) UE side: The implemented system involved extending the URCapIF framework described in “OPC UA”. For the implementation of the AAS server, Eclipse BaSyx was used. The URCapIF framework is implemented using the URCap SDK, which is based on Java 6 and includes several prepackaged Java libraries. An example use case of the system is an AAS-controlled robot speed adjuster.

[0113] Integrating the AAS client SDK into the loT domain proved challenging due to significant Java version differences between URCap and Eclipse BaSyx. Many Java packages had to be imported manually to bridge these differences. While the REST API-based interface is functional and easy to use, difficulties were encountered incorporating the native Java AAS client into the URCap environment.

[0114] 2) Core network side: The AAS server in the tested NRM system was implemented using Eclipse BaSyx. It supports two ways of operation. One is an in-memory database, though it is a simple temp file based system, not optimized like other key -value in memory databases e.g., Redis. The other mode of operation is MongoDB based.

[0115] The AAS server subscribed to all the monitoring data of the assets. Note that the resource monitoring can be done not just by subscribing one by one for each VAL UEs, but a set of UEs or a VAL group can also be monitored at once. The 3 GPP exposure emulator in “OPC UA” provided monitoring data to the AAS monitoring submodels. The implementation of the 3GPP exposure emulator is a Node.JS based dameon which subscribed to all assets’ monitoring data. To evaluate the AAS-triggered QoS provisioning functionality within the Basyx environment one option involved adding Node. RED event handlers onto the AAS events, and utilized the MongoDB event handlers mechanism. The tested AAS server-based NRM system was implemented using the Change Streams feature as well as calling a function implemented in Node.JS that sets the desired speed of the UR robot asset to a specified value. Eclipse Basyx has no implemented function to update the local asset copies from the AAS server, thus we used the same NRM API as in “OPC UA”.

[0116] B. Evaluated scenarios

[0117] An NRM system was evaluated by comparing deployments across three scenarios, demonstrating its impact on system performance. The scenarios are deployed in the 3 GPP emulator described in “OPC UA”. There are two namespaces used, one for the VAL client and one for the VAL server. During testing, 10 URCapIF instances were used with each of them being triggered every tenth sec by setting the measured link delay to 5 and 50 milliseconds (ms) back and forth.

[0118] FIG. 5 is bar chart illustrating example traffic and computational loads of the environment 100 of FIG. 1. As indicated in FIG. 5, 3GPP network exposure and AAS functionindependently in the environment 100. During network initialization, VAL applications or VAs reserve their required channels, issuing all provisioning commands. This process generates significant uplink traffic and results in high computational load on the core network to process and fulfill the requests. Additionally, VAL applications periodically retrieve their required observability data from the core network via downlink communication. Load represents both network and computational load for the given namespace and process normalized with the measured maximum load.

[0119] FIG. 6 is bar chart illustrating example traffic and computational loads of the environment 200 of FIG. 2. As indicated in FIG. 6, in the VASEAL based environment 200 illustrated in FIG. 2, the initial computational loads for core network NRM and AAS remain the same as in FIG. 5. However, for NRM requests, the network can include the VAL applications in the NRM functionality, thus low-volume, sporadic provisioning commands on the radio uplink occur. These commands do not affect all the users but just those which require NRM (it is assumed that these are 50% of the total applications). The provisioning commands imply NRM service API calls for each affected VAL application that are individually registered in the CAPIF core and that is why there is considerable computational load in the core network (e.g., the 3GPP network 130).

[0120] FIG. 7 is bar chart illustrating example traffic and computational loads of the environment 300 of FIG. 3. As indicated in FIG. 7, in the environment 300 illustrated in FIG. 3, the initialization computational loads for core network NRM and AAS are consistent with the environments 100 and 200. Notably, there is no observability data transmitted over the radio downlink. Instead, this traffic occurs between the AAS server and the core network within the edge cloud over wired connections. Since the AAS event-triggered server logic handles VASEAL-related NRM instead of the core network, the computational load shifts from the core network to the AAS domain. However, the core network still initiates NRM calls to the VAL applications, meaning that provisioning commands on the radio downlink remain present.

[0121] As indicated by the assessments of environments 100, 200, and 200, each deployment option offers different advantages. Increasing deployment complexity, like in the example of Figure 3, enhances scalability, which is beneficial for scenarios demanding higher levels of scalability. For use cases where such scalability is unnecessary, simpler deployment options, like shown in Fig. 1 or 2, may suffice.

[0122] FIG. 8 is a flow chart illustrating an example of operations performed by the AAS server 118 in accordance with some embodiments. In some embodiments, the AAS server 118 may be configured to operate in a network (e.g., a private network, an IEC network, etc.) separate from the 3GPP network 130 (e.g., a 4G / 5G core network). In some embodiments, the AAS server118 may publish AAS NRM service APIs via CAPIF to perform or implement network observability, QoS provisioning, or other functions. In some embodiments, the AAS server 118 may utilize event-triggered server logic (e.g., triggers, change streams, stored functions associated with an AAS database) to facilitate NRM, QoS provisioning, network observability, or other functions. In some embodiments, by using the AAS server 118 to perform or implement network observability, QoS provisioning, or other functions, some computational load and traffic from a 3GPP network (e.g., a core network) can be offloaded or reduced, the number of monitoring subscriptions required for various applications (e.g., vertical applications) can be reduced, and the number of NRM service API calls needed for QoS provisioning may be reduced or optimized, e.g., in comparison to some other approaches.

[0123] Referring to FIG. 8, in block 801, the method includes receiving, via a first AAS NRM service API and from a device, first data for implementing a QoS change in the 3GPP network. In block 803, the method further includes determining, using the first AAS NRM service API and the first data, one or more NRM service related APIs. In block 805, the method further includes invoking the one or more NRM service related APIs to implement the QoS change.

[0124] In some embodiments, the method includes, prior to receiving the first data, sending, to a common API framework, CAPIF, core function in the 3GPP network, information about a set of AAS NRM service APIs for API registration at the CAPIF core function, wherein the set of AAS NRM service APIs includes the first AAS NRM service API.

[0125] In some embodiments, determining the one or more NRM service related APIs includes identifying, in an AAS database, event-triggered server logic indicating the one or more NRM service related APIs to invoke.

[0126] In some embodiments, at least one of the one or more NRM service related APIs is implemented by a VA server, a SEAL service server, a VASEAL service server, a SEAL NRM server, a SEAL network resource adaptation server, an AES, a SEAL for data delivery, SEALDD, server, a network exposure function, NEF, or an SCEF.

[0127] In some embodiments, the device is an AAS client, a user device, UE, an loT device, a VA server, a VA client, a VA controller, a SEAL service server, a VASEAL service server, a SEAL NRM server, a SEAL network resource adaptation server, an AES, a SEALDD server, a NEF, or an SCEF.

[0128] In some embodiments, the VA server includes the AAS server.

[0129] In some embodiments, invoking the one or more NRM service related APIs includes sending, via a first NRM service related API, a network resource adaptation request to a SEAL NRM server.

[0130] In some embodiments, invoking the one or more NRM service related APIs includes sending, via a second NRM service related API, a session with QoS request to an AES.

[0131] In some embodiments, invoking the one or more NRM service related APIs includes sending, via a third NRM service related API, an application server, AS, session with QoS request to an SCEF.

[0132] In some embodiments, invoking the one or more NRM service related APIs includes sending, via a fourth NRM service related API, a SEALDD data transmission request to a SEALDD server.

[0133] FIG. 9 is a flow chart illustrating an example of operations performed by a network node in accordance with some embodiments. In some embodiments, a network node (e.g., a base station, a 3 GPP network function, a VA server, a VA controller, etc.) may be configured to communicate with the AAS server 118 that operates in a network (e.g., a private network, an IEC network, etc.) separate from the 3GPP network 130 (e.g., a 4G / 5G core network).

[0134] Referring to FIG. 9, in block 901, the method includes receiving first data from a device indicating a QoS change to implement in a 3 GPP network. In block 903, the method further includes sending, to a CAPIF core function, a discovery request for discovering a first AAS NRM service API to implement the QoS change. In block 905, the method further includes receiving, from the CAPIF core function, a discovery response indicating the first AAS NRM service API. In block 907, the method further includes invoking the first AAS NRM service API implemented by an AAS server operating a network separate from the 3 GPP network to implement the QoS change.

[0135] In some embodiments, the device is an AAS client, a user device, UE, an loT device, a VA server, a VA client, a VA controller, a SEAL service server, a VASEAL service server, a SEAL NRM server, a SEAL network resource adaptation server, an AES, a SEALDD server, a NEF, or an SCEF.

[0136] In some embodiments, the VA server includes the AAS server.

[0137] In some embodiments, the network node includes the AAS server, the VA server, or the device.

[0138] FIG. 10 is a flow chart illustrating an example of operations performed by a device in accordance with some embodiments. In some embodiments, a device (e.g., a VAC 104, UE 102, an loT device, etc.) may be configured to communicate (e.g., directly or indirectly) with the AAS server 118 that operates in a network (e.g., a private network, an IEC network, etc.) separate from the 3GPP network 130 (e.g., a 4G / 5G core network).

[0139] Referring to FIG. 10, in block 1001, the method includes obtaining information to communicate with the AAS server. In block 1003, the method further includes sending, to the AAS server, first data for implementing a QoS change in the 3GPP network. In block 1005, the method further includes receiving an indication that the QoS change is implemented in the 3GPP network.

[0140] In some embodiments, the device is a user device, UE, an loT device, a VA server, a VA client, a VA controller, a SEAL service server, a VASEAL service server, a SEAL NRM server, a SEAL network resource adaptation server, an AES, a SEALDD server, a NEF, or an SCEF.

[0141] In some embodiments, the VA server includes the AAS server.

[0142] In some embodiments, obtaining the information to communicate with the AAS server includes sending, to a common application programming interface, API, framework, CAPIF, core function, a discovery request for discovering a first asset administration shell, AAS, network resource management, NRM, service API to implement the QoS change and receiving, from the CAPIF core function, a discovery response indicating the first AAS NRM service API. In such embodiments, sending, to the AAS server, the first data for implementing the QOS change in the 3 GPP network includes invoking the first AAS NRM service API implemented by the AAS server to implement the QoS change. In such embodiments, receiving the indication that the QoS change is implemented in the 3GPP network includes receiving a AAS NRM service response indicating that the QoS change is implemented.

[0143] In some embodiments, the device includes an AAS client registered with the AAS server.

[0144] In some embodiments (e.g., where the device includes an AAS client registered with the AAS server), obtaining the information to communicate with the AAS server includes sending a request to obtain information about a submodel of an asset, and receiving a response indicating the information about the submodel of the asset. In such embodiments, sending, to the AAS server, the first data for implementing the QoS change in the 3 GPP network includes sending an AAS update request for changing the submodel. In such embodiments, receiving the indication that the QoS change is implemented in the 3GPP network includes receiving an AAS acknowledgement response indicating that the update was performed successfully.

[0145] FIG. 11 shows an example of a communication system 1100 in accordance with some embodiments.

[0146] In the example, communication system 1100 includes a telecommunications network 1102 that includes an access network 1104, such as a radio access network (RAN), and a corenetwork 1106, which includes one or more core network nodes 1108. The access network 1104 includes one or more access network nodes or base stations of various types, access network nodes 1110A and 1110B are depicted (which may be collectively referred to as network nodes 1110), or any other similar 3rdGeneration Partnership Project (3GPP) access nodes or non-3GPP access points (APs). Some embodiments of the access network 1104 may include more than one access network technology. The network nodes 1110 of access network 1104 facilitate direct or indirect connection of wireless devices, also referred to as user equipments (UEs), such as by connecting UEs 1112A, 1112B, 1112C, and 1112D (one or more of which may be generally referred to as UEs 1112) to the core network 1106 over one or more wireless connections.

[0147] Moreover, aa access network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, the telecommunications network 1102 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a network node in the telecommunications network 1102 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other network nodes to implement one or more functionalities of any network node in the telecommunications network 1102, including one or more access network nodes 1110 and / or core network nodes 1108.

[0148] The access network nodes 1110 facilitate direct or indirect connection of one or more UEs 1112 to the core network 1106 over one or more wireless connections. Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. In different embodiments, communication system 1100 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. Communication system 1100 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0149] UEs 1112 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with the network nodes 1110 and other communication devices. Similarly, the network nodes 1108, 1110 are arranged, capable, configured, and / or operable to communicate directly or indirectly (e.g., via other devices of telecommunications network 1102) with the UEs 1112 and / or with other network nodes orequipment in the telecommunications network 1102 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunications network 1102. More specifically, UEs 1112 may send messages, data, and / or other signals to network nodes 1108, 1110 or other elements of the telecommunications network 1102 by transmitting such signals to the relevant device directly without the signals passing through any intervening devices or by transmitting such signals to the relevant device indirectly through an intervening device (or multiple intervening devices) that then transmit the signal to the relevant device. Similarly, network nodes 1108, 1110 may send messages, data, and other signals to UEs 11122, other network nodes 1108, 1110, and other devices in telecommunications network 1102 directly or indirectly. As one specific example, a core network node 1108 may transmit a particular message to a UE 1112 by transmitting the message to an access network node 1110 that will then transmit the message to the intended UE 1112. Similarly, a core network node 108 may receive a particular message from a UE 1112 by receiving the message from an access network node 1110 that itself received the message from the UE 1112.

[0150] In the depicted example, the core network 1106 connects elements of the access network 1104 (e.g., one or more of the network nodes 1110) to one or more host computing systems, such as host 1116. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 1106 includes one or more core network nodes (e.g., core network node 1108) of various types, one or more of which may be generally referred to as network nodes 1108. Network nodes 1108 are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, access network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 1108. Example core network nodes provide functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User Plane Function (UPF), and in the context of this disclosure particularly network exposure function (NEF), Edge Configuration Server (ECS), Service Capability Exposure Function (SCEF), SEAL / SEALDD server or Application Enabler Server (AES).

[0151] The host 1116 may be under the ownership or control of a service provider other than an operator or provider of the access network 1104 and / or the telecommunications network 1102.The host 1116 may be operated by the service provider or on behalf of the service provider. The host 1116 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio / video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server. In the context of this disclosure, the host may be exemplified by elements like VA or VAL Server or Asset Administration Shell (AAS) server.

[0152] As a whole, the communication system 1100 of FIG. 11 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system 1100 may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (Wi-Fi); and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (Wi-Max), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, Li-Fi, and / or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox. Moreover, the communication system 1100 may be configured to support multiple different standards, protocols, or other rule sets, with individual components supporting all of the relevant rule sets or with different components or sub-systems within the communication system 1100 supporting different standards, protocols, or rule sets.

[0153] As one example, in certain embodiments, access network 1104 may contain some access network nodes 1110 that support 3GPP radio access technologies (RAT), such as LTE or NR, while other access network nodes 1110 support (or the same access network nodes 1110 additionally support) non-3GPP RATs, such as Wi-Fi or a proprietary RAT. As another example, telecommunications network 1102 may support multiple generations of related communication standards (e.g., 4G and 5G 3GPP communication standards) and, as a result, may include an access network 104 and / or a core network 106 that supports multiple different standard generations or may include multiple access networks 104 and / or multiple core networks 106 with individual networks 104, 106 supporting different standard generations.

[0154] Telecommunications network 1102 may support network slicing to provide different logical networks to different devices that are connected to the telecommunications network 1102. For example, the telecommunications network 1102 may provide Ultra Reliable Low LatencyCommunication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC) / Massive loT services to yet further UEs.

[0155] In some examples, one or more of the UEs 1112 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 1104 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 1104. Additionally, a UE may be configured for operating in single- or multi-RAT or multi -standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).

[0156] In the example, the hub 1114 communicates with the access network 1104 to facilitate indirect communication between one or more UEs (e.g., UE 1112C and / or 1112D) and network nodes (e.g., network node 1110B). In some examples, the hub 1114 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 1114 may be a broadband router enabling access to the core network 1106 for the UEs. As another example, the hub 1114 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 1110, or by executable code, script, process, or other instructions in the hub 1114.

[0157] As another example, hub 1114 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, hub 1114 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub 1114 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 1114 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, hub 1114 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy loT devices.

[0158] The hub 1114 may have a constant / persistent or intermittent connection to the network node 1 HOB. The hub 1114 may also allow for a different communication scheme and / or schedule between the hub 1114 and UEs (e.g., UE 1112C and / or 1112D), and between the hub 1114 and the core network 1106. In other examples, hub 1114 is connected to the core network 1106 and / or one or more UEs via a wired connection. Moreover, hub 1114 may be configured to connect to an M2M service provider over the access network 1104 and / or to another UE over a direct connection.In some scenarios, UEs may establish a wireless connection with the network nodes 1110 while still connected via the hub 1114 via a wired or wireless connection. In some embodiments, the hub 1114 may be a dedicated hub - that is, a hub whose primary function is to route communications to / from the UEs from / to the network node 1110B. In other embodiments, the hub 1114 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 1110B, but which is additionally capable of operating as a communication start and / or end point for certain data channels.

[0159] FIG. 12 is another example of a communication system 1200 according to some embodiments. As used herein, the communication system 1200 includes multiple access points (APs) 1210 (with four exemplary APs 1210A, 1210B, 1210C, and 1210D being depicted) and multiple wireless devices, referred to in the context of communication system 1200 as stations (STAs) 1212 (referred to individually as STA 1212A, STA 1212B, STA 1212C, STA 1212D, and STA 1212E). STA 1212A is served by AP 1210A in a first basic service set (BSS) 1220A. STA 1210B and STA 1210C are served by AP 1210B in a second BSS, BSS 1220B. STA 1212D is served by AP 1210C in a third BSS, BSS 1220C. STA 1212E is served by AP 1210D in a fourth BSS, BSS 1220D. Stations 1212 may be non-AP STAs and correspond to various kinds of wireless devices, for example, user terminals, such as mobile or stationary computing devices like smartphones, laptop computers, desktop computers, tablet computers, gaming devices, headmounted displays (HMDs) for Augmented Reality (AR) or Virtual Reality (VR), or the like. Further, stations 1212 could, for example, correspond to other kinds of equipment like smart home devices, printers, multimedia devices, data storage devices, or the like.

[0160] Each of STAs 1212 may connect through a radio link to one of APs 1210. For example, depending on location or channel conditions experienced by a given STA 1212, the STA may select an appropriate AP and BSS for establishing the radio link. The radio link may be based on one or more orthogonal frequency-division multiplexing (OFDM) carriers from a frequency spectrum that is shared on the basis of a contention-based mechanism, e.g., an unlicensed or license exempt band like 2.4 GHz Industrial, Scientific, and Medical (ISM) band, the 5 GHz band, the 6 GHz band, or the 60 GHz band.

[0161] Each AP 1210 may provide data connectivity to STAs 1212 connected to a particular AP 1210. As illustrated, APs 1210 may be connected to a data network 1230. In this way, APs 1210 may also provide data connectivity between STAs 1212 and other entities, e.g., to one or more servers, service providers, data sources, data sinks, user terminals, or the like. Accordingly, the radio link established between a given STA 1212 and its serving AP 1210 may be used for providing various kinds of services to STA 1212, e.g., a voice service, a multimedia service, orother data service. Such services may be based on applications that are executed on STA 1212 and / or on a device linked to STA 1212. By way of example, FIG. 12 illustrates an application service platform 1232 provided in data network 1230. The application(s) executed on STA 1212 and / or on one or more other devices linked to STA 1212 may use the radio link for data communication with one or more other STA 1212 and / or the application service platform 1232, thereby enabling utilization of the corresponding service(s) at STA 1212.

[0162] FIG. 13 shows a wireless device 1300, which may be configured to operate in communication system 1100 of FIG. 11 or in communication system 1200 of FIG. 120. The wireless device 1300 may be alternatively referred to as a UE 1300, like a UE 1112 within the context of communication system 1100, or as a station (STA) 1300 or as a non-access-point station (non-AP STA) 1300, like a STA 1212 within the context of the communication system 1200, in accordance with respective embodiments. As used herein, a wireless device refers to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes and / or other wireless devices. Examples of a wireless device include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), smart device, wireless customer-premise equipment (CPE), vehicle, vehicle-mounted or vehicle embedded / integrated wireless device, and wireless terminal. Other examples include any type of UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE. In some embodiments, wireless device 1300 may include UE 102, AAS client 108, and / or other elements or functionality described above with regard to FIG. 3.

[0163] A wireless device 1300 may support device-to-device (D2D) communication, for example by implementing a 3 GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, wireless device 1300 may not necessarily have a user in the sense of a human user who owns and / or operates the relevant device. Instead, wireless device 1300 may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, wireless device 1300 may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter).

[0164] In particular embodiments, wireless device 1300 includes processing circuitry 1302 that is operatively coupled via a bus 1304 to an input / output interface 1306, a power source 1308, a memory 1310, a communication interface 1312, and / or any other component, or any combination thereof. Certain embodiments of wireless device 1300 may include all or a subset of the components shown in FIG. 13. The level of integration between the components may vary from one embodiment of wireless device 1300 to another. In general, in a particular embodiment of wireless device 1300, processing circuitry 1302, input / output interface 1306, power source 1308, memory 1310, and communication interface 1312 may, in whole or in part, represent or include physical components common to or shared by one or more of the other elements of wireless device 1300. Further, certain embodiments of wireless devices 1300 may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0165] The processing circuitry 1302 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory 1310, thereby for example performing methods as described above. The processing circuitry 1302 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general -purpose processors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, the processing circuitry 1302 may include multiple central processing units (CPUs).

[0166] In some embodiments, the power source 1308 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used to supply power to circuitry or to charge an associated battery. The power source 1308 may further include power circuitry for delivering power from the power source 1308 itself, and / or an external power source, to the various parts of wireless device 1300 via input circuitry or an interface such as an electrical power cable.

[0167] The memory 1310 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, memory 1310 includes one or more programs 1314, such as an operating system, web browser application, a widget, gadget engine, or other application, andcorresponding data 1316. The memory 1310 may store, for use by wireless device 1300, any of a variety of various operating systems or combinations of operating systems.

[0168] The memory 1310 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs), such as a USIM and / or ISIM, other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUICC), integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card.’ The memory 1310 may allow wireless device 1300 to access instructions, programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory 1310, which may be or comprise a device-readable storage medium.

[0169] The processing circuitry 1302 may be configured to communicate with an access network or other network via or using the communication interface 1312. The communication interface 1312 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 1322. The communication interface 1312 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another wireless device or a network node in an access network). Each transceiver may include a transmitter 1318 and / or a receiver 1320 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter 1318 and receiver 1320 may be coupled to one or more antennas (e.g., antenna 1322) and may share circuit components, software or firmware, or alternatively be implemented separately.

[0170] In the illustrated embodiment, communication functions of the communication interface 1312 may include cellular communication, Wi-Fi communication (e.g., according to an IEEE 802.11 family standard), LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented according to one or more communication protocolsand / or standards, such as IEEE 802.11, Code Division Multiplexing Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, transmission control protocol / internet protocol (TCP / IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth.

[0171] In particular embodiments, wireless device 1300 may provide an output of data captured via a sensor, through its communication interface 1312, via a wireless connection to a network node, and / or in any appropriate manner. Data captured by sensors of a wireless device 1300 can be communicated through a wireless connection to a network node via another wireless device 1300. In particular embodiments, such output may be periodic (e.g., once every 15 minutes if it reports the sensed temperature), random (e.g., to even out the load from reporting from several sensors), in response to a triggering event (e.g., when moisture is detected an alert is sent), in response to a request (e.g., a user initiated request), or a continuous stream (e.g., a live video feed).

[0172] As another example, wireless device 1300 comprises an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, wireless device 1300 may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input.

[0173] Wireless device 1300, when in the form of an Internet of Things (loT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, wearable technology, extended industrial application and healthcare. Non-limiting examples of such an loT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a flood / moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or item -tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. In particular embodiments, wireless device 1300 represents an loT device that comprises circuitry and / or software independence of the intended application of the loT device in addition to other components as described in relation to the example embodiment of wireless device 1300 shown in FIG. 13.

[0174] As yet another specific example, in an loT scenario, wireless device 1300 may represent a machine or other device that performs monitoring and / or measurements, and transmits the results of such monitoring and / or measurements to another wireless device and / or a network node. Wireless device 1300 may in this case be an M2M device, which may in a 3GPP context be referred to as an MTC device. As one particular example, wireless device 1300 may implement the 3GPP NB-IoT standard. In other scenarios, wireless device 1300 may represent a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipment that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation.

[0175] In practice, any number of wireless devices 1300 may be used together with respect to a single use case. For example, a first wireless device 1300 might be or be integrated in a drone and provide the drone’s speed information (obtained through a speed sensor) to a second wireless device 1300 that is a remote controller operating the drone. When a user makes changes from the remote controller, the first wireless device 1300 may adjust the throttle on the drone (e.g., by controlling an actuator) to increase or decrease the drone’s speed. The first and / or the second wireless device 1300 can also include more than one of the functionalities described above. For example, wireless device 1300 might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.

[0176] FIG. 14 shows a network node 1400 in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or equipment, in a telecommunications network. In accordance with respective embodiments, network node 1400 may be configured to operate in communication system 1100 of FIG. 11, like network nodes 1108 or 1110, or in communication system 1200 of FIG. 12, like an AP 1210 or a station 1212. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)), 0-RAN nodes or components of an 0-RAN node (e.g., 0-RU, 0-DU, O-CU). In some embodiments, network node 1400 may include AAS server 118, VAS 114, and / or other elements or functionality described above with regard to FIG. 3.

[0177] Other examples of network nodes 1400 include Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and / or Minimization of Drive Tests (MDTs).

[0178] In particular embodiments, network node 1400 includes a processing circuitry 1402, a memory 1404, a communication interface 1406, and a power source 1408. In general, in a particular embodiment of network node 1400, processing circuitry 1402, memory 1404, communication interface 1406, and power source 1408 may, in whole or in part, represent or include physical components common to or shared by one or more of the other elements of network node 1400.

[0179] The network node 1400 may be composed of multiple distinct network entities (e.g., a NodeB entity and a RNC entity, or a BTS entity and a BSC entity, etc.), which may each have or utilize their own respective physical components. In certain scenarios in which the network node 1400 comprises multiple such entities (e.g., BTS and BSC), one or more of the separate entities may be shared among several network nodes.

[0180] The processing circuitry 1402 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic operable to provide, either alone or in conjunction with other components, such as the memory 1404, to provide network node 1400 functionality.

[0181] In some embodiments, the processing circuitry 1402 includes a system on a chip (SOC). In some embodiments, the processing circuitry 1402 includes one or more of radio frequency (RF) transceiver circuitry 1412 and baseband processing circuitry 1414. In some embodiments, the RF transceiver circuitry 1412 and the baseband processing circuitry 1414 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 1412 and baseband processing circuitry 1414 may be on the same chip or set of chips, boards, or units.

[0182] The memory 1404 may comprise any form of volatile or non-volatile computer-readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory devices that store information, data, and / or instructions that may be used by the processing circuitry 1402. Memory 1404 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and / or other instructions capable of being executed by the processing circuitry 1402 and utilizedby the network node 1400. The memory 1404 may be used to store any calculations made by the processing circuitry 1402 and / or any data received via the communication interface 1406. In some embodiments, the processing circuitry 1402 and memory 1404 is integrated.

[0183] The communication interface 1406 is used in wired or wireless communication of signaling and / or data with UEs, other network nodes, and / or any other network equipment. In the illustrated embodiment, communication interface 1406 comprises port(s) / terminal(s) 1416 to send and receive data, for example to and from a network over a wired connection. In particular embodiments, network node 1300 may be capable of wireless communication and communication interface 1406 may also include radio front-end circuitry 1418 that may be coupled to, or in certain embodiments a part of, an antenna 1410. Particular embodiments of radio front-end circuitry 1418 include filter(s) 1420 and amplifier(s) 1422. The radio front-end circuitry 1418 may be connected to an antenna 1410 and processing circuitry 1402. The radio front-end circuitry may be configured to condition signals communicated between antenna 1410 and processing circuitry 1402. The radio front-end circuitry 1418 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry 1418 may convert the digital data into a radio signal(s) having the appropriate channel and bandwidth parameters using a combination of filters 1420 and / or amplifiers 1422. The radio signal(s) may then be transmitted via the antenna 1410. Similarly, when receiving data, the antenna 1410 may collect radio signals which are then converted into digital data by the radio front-end circuitry 1418. The digital data may be passed to the processing circuitry 1402. In other embodiments, the communication interface may comprise different components and / or different combinations of components.

[0184] The antenna 1410 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. The antenna 1410 may be coupled to the radio front-end circuitry 1418 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, the antenna 1410 is separate from the network node 1400 and connectable to the network node 1400 through one or more interfaces or ports.

[0185] The antenna 1410, communication interface 1406, and / or the processing circuitry 1402 may be configured to perform some or all of the receiving operations and / or obtaining operations described herein as being performed by the network node 1400. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, the antenna 1410, the communication interface 1406, and / or the processing circuitry 1402 may be configured to perform some or all of the transmitting or sending operations described herein as being performed by the network node 1400. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment.

[0186] Power source 1408 provides power to the various components of network node 1400 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). Power source 1408 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 1400 with power for performing the functionality described herein. For example, the network node 1400 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 1408. As a further example, the power source 1408 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power if the external power source fails.

[0187] Embodiments of the network node 1400 may include additional components beyond those shown in FIG. 14 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, the network node 1400 may include user interface equipment to allow input of information into the network node 1400 and to allow output of information from the network node 1400. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 1400.

[0188] FIG. 15 is a block diagram illustrating a virtualization environment 1500 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 1500 hosted by one or more of hardware nodes, such as a hardware computing device that operates as an access network node, UE, core network node, or host. Further, in embodiments in which a virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized. In some embodiments, the virtualization environment 1500 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an O-2 interface.

[0189] Applications 1502 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment Q400 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.

[0190] Hardware 1504 includes processing circuitry, memory that stores software and / or instructions executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 1506 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VM 1508 A and VM 1508B (which may be collectively referred to as VMs 1508), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer 1506 may present a virtual operating platform that appears like networking hardware to one or more of the VMs 1508.

[0191] The VMs 1508 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by virtualization layer 1506. Different embodiments of the instance of a virtual appliance 1502 may be implemented on one or more of VMs 1508, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

[0192] In the context of NFV, each of the VMs 1508 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 1508, and that part of hardware 1504 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more of the VMs 1508 on top of the hardware 1504 and corresponds to an application 1502.

[0193] Hardware 1504 may be implemented in a standalone network node with generic or specific components. Hardware 1504 may implement some functions via virtualization. Alternatively, hardware 1504 may be part of a larger cluster of hardware (e.g., such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 1510, which, among others, oversees lifecycle management of applications 1502. In some embodiments, hardware 1504 is coupled to one or more radio units that each include one ormore transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system 1512 which may alternatively be used for communication between hardware nodes and radio units.

[0194] Although the computing devices described herein (e.g., UEs, network nodes, hosts) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0195] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processingcircuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.

[0196] Further definitions and embodiments are discussed below.

[0197] In the above-description of certain embodiments of the present disclosure, it is to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the present disclosure. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which concepts of the present disclosure belong. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

[0198] When an element is referred to as being “connected”, “coupled”, “responsive”, or variants thereof to another element, it can be directly connected, coupled, or responsive to the other element or intervening elements may be present. In contrast, when an element is referred to as being “directly connected”, “directly coupled”, “directly responsive”, or variants thereof to another element, there are no intervening elements present. Like numbers refer to like elements throughout. Furthermore, “coupled”, “connected”, “responsive”, or variants thereof as used herein may include wirelessly coupled, connected, or responsive. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. Well-known functions or constructions may not be described in detail for brevity and / or clarity. The term “and / or” (abbreviated “ / ”) includes any and all combinations of one or more of the associated listed items.

[0199] It will be understood that although the terms first, second, third, etc. may be used herein to describe various elements / operations, these elements / operations should not be limited by these terms. These terms are only used to distinguish one element / operation from another element / operation. Thus a first element / operation in some embodiments could be termed a second element / operation in other embodiments without departing from the teachings of concepts of the present disclosure. The same reference numerals or the same reference designators denote the same or similar elements throughout the specification.

[0200] As used herein, the terms “comprise”, “comprising”, “comprises”, “include”, “including”, “includes”, “have”, “has”, “having”, or variants thereof are open-ended, and include one or more stated features, integers, elements, steps, components, or functions but does not preclude the presence or addition of one or more other features, integers, elements, steps,components, functions, or groups thereof. Furthermore, as used herein, the common abbreviation “e.g ”, which derives from the Latin phrase “exempli gratia,” may be used to introduce or specify a general example or examples of a previously mentioned item, and is not intended to be limiting of such item. The common abbreviation “i.e ”, which derives from the Latin phrase “id est,” may be used to specify a particular item from a more general recitation.

[0201] Example embodiments are described herein with reference to block diagrams and / or flowchart illustrations of computer-implemented methods, apparatus (systems and / or devices) and / or computer program products. It is understood that a block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, can be implemented by computer program instructions that are performed by one or more computer circuits. These computer program instructions may be provided to a processor circuit of a general purpose computer circuit, special purpose computer circuit, and / or other programmable data processing circuit to produce a machine, such that the instructions, which execute via the processor of the computer and / or other programmable data processing apparatus, transform and control transistors, values stored in memory locations, and other hardware components within such circuitry to implement the functions / acts specified in the block diagrams and / or flowchart block or blocks, and thereby create means (functionality) and / or structure for implementing the functions / acts specified in the block diagrams and / or flowchart block(s).

[0202] These computer program instructions may also be stored in a tangible computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instructions which implement the functions / acts specified in the block diagrams and / or flowchart block or blocks. Accordingly, embodiments of the present disclosure may be embodied in hardware and / or in software (including firmware, resident software, micro-code, etc.) that runs on a processor such as a digital signal processor, which may collectively be referred to as “circuitry,” “a module” or variants thereof.

[0203] It should also be noted that in some alternate implementations, the functions / acts noted in the blocks may occur out of the order noted in the flowcharts. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality / acts involved. Moreover, the functionality of a given block of the flowcharts and / or block diagrams may be separated into multiple blocks and / or the functionality of two or more blocks of the flowcharts and / or block diagrams may be at least partially integrated. Finally, other blocks may be added / inserted between the blocks that are illustrated, and / or blocks / operations may be omitted without departing from thescope of the present disclosure. Moreover, although some of the diagrams include arrows on communication paths to show a primary direction of communication, it is to be understood that communication may occur in the opposite direction to the depicted arrows.

[0204] As will be appreciated by one of skill in the art, the concepts described herein may be embodied as a method, data processing system, computer program product and / or computer storage media storing an executable computer program. Accordingly, the concepts described herein may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects all generally referred to herein as a “circuit” or “module.” Any process, step, action and / or functionality described herein may be performed by, and / or associated to, a corresponding module, which may be implemented in software and / or firmware and / or hardware. Furthermore, the disclosure may take the form of a computer program product on a tangible computer usable storage medium having computer program code embodied in the medium that can be executed by a computer. Any suitable tangible computer readable medium may be utilized including hard disks, CD-ROMs, electronic storage devices, optical storage devices, or magnetic storage devices.

[0205] Many variations and modifications can be made to the embodiments without substantially departing from the principles of the present disclosure. All such variations and modifications are intended to be included herein within the scope of present disclosure. Accordingly, the above disclosed subject matter is to be considered illustrative, and not restrictive, and the examples of embodiments are intended to cover all such modifications, enhancements, and other embodiments, which fall within the spirit and scope of the present disclosure. Thus, to the maximum extent allowed by law, the scope of the present disclosure is to be determined by the broadest permissible interpretation of the present disclosure including the examples of embodiments and their equivalents, and shall not be restricted or limited by the foregoing detailed description.

[0206] Abbreviations that may be used in the preceding description include:

Claims

Claims:

1. A method for network resource management, comprising:sending (903), by a network node (1400) or a device, to a common API framework, CAPIF, core function, a discovery request for discovering a first asset administration shell, AAS, network resource management, NRM, service API to implement a quality of service, QoS, change in a 3rdGeneration Partnership Project, 3GPP, network;receiving (905), by the network node (1400) or the device, from the CAPIF core function, a discovery response indicating the first AAS NRM service API; andinvoking (907), by the network node (1400) or the device, the first AAS NRM service API implemented by an AAS server operating in a network separate from the 3 GPP network to provide first data for implementing the QoS change to the AAS server;determining (803), by the AAS server using the first AAS NRM service API and the first data, one or more NRM service related APIs; andinvoking (805) the one or more NRM service related APIs to implement the QoS change.

2. The method of claim 1, comprising receiving (901), by the network node (1400), the first data indicating the quality of service, QoS, change from a device.

3. The method of claim 1, comprising receiving, by the device, an AAS NRM service response indicating that the QoS change is implemented.

4. A method implemented by an asset administration shell, AAS, server (118, 1400) configured to operate in a network separate from a 3rdGeneration Partnership Project, 3GPP, network (130), the method comprising:receiving (801), from a device or a network node, via a first AAS network resource management, NRM, service application programming interface, API, first data for implementing a quality of service, QoS, change in the 3 GPP network;determining (803), using the first AAS NRM service API and the first data, one or more NRM service related APIs; andinvoking (805) the one or more NRM service related APIs to implement the QoS change.

475. The method of Claim 4, comprising:prior to receiving the first data:sending, to a common API framework, CAPIF, core function in the 3 GPP network, information about a set of AAS NRM service APIs for API registration at the CAPIF core function, wherein the set of AAS NRM service APIs includes the first AAS NRM service API.

6. The method of any of Claims 1 to 5, wherein determining the one or more NRM service related APIs includes identifying, in an AAS database, event-triggered server logic indicating the one or more NRM service related APIs to invoke.

7. The method of any of Claims 1-6, wherein at least one of the one or more NRM service related APIs is implemented by a vertical application, VA, server; a Service Enabler Architecture Layer, SEAL, service server; a Vertical Application Service Enabling Architecture Layer, VASEAL, service server; a SEAL NRM server; a SEAL network resource adaptation server; an application enabler server, AES; a SEAL for data delivery, SEALDD, server; a network exposure function, NEF; or a service capability exposure function, SCEF.

8. The method of any of Claims 1-7, wherein the device is an AAS client; a user device; a user equipment; an internet of things, loT, device; a vertical application, VA, server; a VA client; a VA controller; a Service Enabler Architecture Layer, SEAL, service server; a Vertical Application Service Enabling Architecture Layer, VASEAL, service server; a SEAL network resource management (NRM) server; a SEAL network resource adaptation server; an application enabler server, AES; a SEAL for data delivery, SEALDD, server; a network exposure function, NEF; or a service capability exposure function, SCEF.

9. The method of Claim 8, wherein the VA server includes the AAS server.

10. The method of any one of Claims 1-9, wherein invoking the one or more NRM service related APIs includes:sending, via a first NRM service related API, a network resource adaptation request to a SEAL NRM server.4811. The method of any one of Claims 1-10, wherein invoking the one or more NRM service related APIs includes:sending, via a second NRM service related API, a session with QoS request to an application enabler server, AES.

12. The method of any one of Claims 1-11, wherein invoking the one or more NRM service related APIs includes:sending, via a third NRM service related API, an application server, AS, session with QoS request to an SCEF.

13. The method of any of Claims 1-12, wherein invoking the one or more NRM service related APIs includes:sending, via a fourth NRM service related API, a SEALDD data transmission request to a SEALDD server.

14. The method of any of claims 1-13, wherein the AAS server subscribes to monitoring data from multiple assets simultaneously, particularly including individual Vertical Application Layer, VAL, UEs and groups of VAL UEs.

15. An asset administration shell, AAS, server (118, 1400) configured to operate in a network separate from a 3rdGeneration Partnership Project, 3GPP, network (130), the AAS server comprising processing circuitry (1402) configured to perform operations comprising: receiving (801), from a device or a network node, via a first AAS network resource management, NRM, service application programming interface, API, first data for implementing a quality of service, QoS, change in the 3 GPP network;determining (803), using the first AAS NRM service API and the first data, one or more NRM service related APIs; andinvoking (805) the one or more NRM service related APIs to implement the QoS change.

16. The AAS server of Claim 15, the processing circuitry configured to perform any of the operations of Claims 5-14 when dependent, directly or indirectly, on claim 4.4917. A method implemented by a network node (1400), the method comprising: receiving (901) first data from a device indicating a quality of service, QoS, change to implement in a 3rdGeneration Partnership Project, 3 GPP, network;sending (903), to a common API framework, CAPIF, core function, a discovery request for discovering a first asset administration shell, AAS, network resource management, NRM, service API to implement the QoS change;receiving (905), from the CAPIF core function, a discovery response indicating the first AAS NRM service API; andinvoking (907) the first AAS NRM service API implemented by an AAS server operating in a network separate from the 3 GPP network to implement the QoS change.

18. The method of Claim 17, wherein the device is an AAS client; a user device; user equipment; an internet of things, loT, device; a vertical application, VA, server; a VA client; a VA controller; a Service Enabler Architecture Layer, SEAL, service server; a Vertical Application Service Enabling Architecture Layer, VASEAL, service server; a SEAL network resource management (NRM) server; a SEAL network resource adaptation server; an application enabler server, AES; a SEAL for data delivery, SEALDD, server; a network exposure function, NEF; or a service capability exposure function, SCEF.

19. The method of Claim 18, wherein the VA server includes the AAS server.

20. The method of any of Claims 17-19, wherein the network node includes the AAS server, the VA server, or the device.

21. A network node (1400) comprising processing circuitry (1402) configured to perform operations comprising:Receiving (901) first data from a device indicating a quality of service, QoS, change to implement in a 3rdGeneration Partnership Project, 3 GPP, network;sending (903), to a common application programming interface, API, framework, CAPIF, core function, a discovery request for discovering a first asset administration shell, AAS, network resource management, NRM, service API to implement the QoS change;receiving (905), from the CAPIF core function, a discovery response indicating the first AAS NRM service API; and50invoking (907) the first AAS NRM service API implemented by an AAS server operating a network separate from the 3 GPP network to implement the QoS change.

22. The network node of Claim 20, the processing circuitry configured to perform any of the operations of Claims 18-20.

23. A method implemented by a device (1300, 102, 1112) configured to communicate with an asset administration shell, AAS, server (118, 1400) configured to operate in a network separate from a 3rdGeneration Partnership Project, 3GPP, network, the method comprising: obtaining information to communicate with the AAS server;sending, to the AAS server, first data for implementing a quality of service, QoS, change in the 3 GPP network; andreceiving an indication that the QoS change is implemented in the 3GPP network.

24. The method of Claim 23, wherein the device is a user device; user equipment; an internet of things, loT, device; a vertical application, VA, server; a VA client; a VA controller; a Service Enabler Architecture Layer, SEAL, service server; a Vertical Application Service Enabling Architecture Layer, VASEAL, service server; a SEAL network resource management (NRM) server; a SEAL network resource adaptation server; an application enabler server, AES; a SEAL for data delivery, SEALDD, server; a network exposure function, NEF; or a service capability exposure function, SCEF.

25. The method of Claim 24, wherein the VA server includes the AAS server.

26. The method of any of Claims 23-25, wherein obtaining the information to communicate with the AAS server includes:sending, to a common application programming interface, API, framework, CAPIF, core function, a discovery request for discovering a first asset administration shell, AAS, network resource management, NRM, service API to implement the QoS change;receiving, from the CAPIF core function, a discovery response indicating the first AAS NRM service API;wherein sending, to the AAS server, the first data for implementing the QOS change in the 3GPP network includes:invoking the first AAS NRM service API implemented by the AAS server to implementthe QoS change; andwherein receiving the indication that the QoS change is implemented in the 3GPP network includes:receiving a AAS NRM service response indicating that the QoS change is implemented.

27. The method of any of Claims 23-26, wherein the device includes an AAS client registered with the AAS server.

28. The method of Claim 27, wherein obtaining the information to communicate with the AAS server includes:sending a request to obtain information about a submodel of an asset, andreceiving a response indicating the information about the submodel of the asset; wherein sending, to the AAS server, the first data for implementing the QoS change in the 3 GPP network includes:sending an AAS update request for changing the submodel; andwherein receiving the indication that the QoS change is implemented in the 3GPP network includes:receiving an AAS acknowledgement response indicating that the update was performed successfully.

29. A device (1300, 102, 1112) comprising processing circuitry (1302) configured to perform operations comprising:obtaining (1001) information to communicate with the AAS server;sending (1003), to the AAS server, first data for implementing a quality of service, QoS, change in the 3 GPP network; andreceiving (1005) an indication that the QoS change is implemented in the 3GPP network.

30. The device of Claim 29, the processing circuitry being configured to perform any of the operations of Claims 23-28.

31. A system for network resource management, comprising:An asset administration shell, AAS, server (118, 1400) according to claim 15 or 16; and A network node (1400) according to claim 20 or 21 or a device according to claim 29 or 30.

32. A computer program comprising program code to be executed by processing circuitry (1402) of an asset administration shell, AAS, server (118, 1400) configured to operate in a network separate from a 3rdGeneration Partnership Project, 3GPP, network (130), whereby execution of the program code causes the AAS Server to perform any of the operations of Claims 4-14.

33. A computer program product comprising a non-transitory storage medium including program code to be executed by processing circuitry (1402) of an asset administration shell, AAS, server (118, 1400) configured to operate in a network separate from a 3rdGeneration Partnership Project, 3 GPP, network (130), whereby execution of the program code causes the AAS server to perform any of the operations of Claims 4-14.

34. A computer program comprising program code to be executed by processing circuitry (1402) of a network node (1400), whereby execution of the program code causes the network node to perform any of the operations of Claims 17-20.

35. A computer program product comprising a non-transitory storage medium including program code to be executed by processing circuitry (1402) of a network node (1400), whereby execution of the program code causes the network node to perform any of the operations of Claims 17-20.

36. A computer program comprising program code to be executed by processing circuitry (1302) of a device (1300, 102, 1112), whereby execution of the program code causes the device to perform any of the operations of Claims 23-28.

37. A computer program product comprising a non-transitory storage medium including program code to be executed by processing circuitry (1302) of a device (1300, 102, 112), whereby execution of the program code causes the device to perform any of the operations of Claims 23-28.53

Images