Controlling application topic subscriptions

Abstract

Disclosed herein is a method performed by one or more network devices implementing a subscription manager of a service management and orchestration platform. The method includes obtaining a machine learning model that was trained to predict output data of an application from input data of the application, wherein the machine learning model has a plurality of input features that corresponds to a plurality of topics that the application reads data from, determining a relevance score for each of the plurality of input features using the machine learning model, determining that the application can unsubscribe from one or more of the plurality of topics that the application reads data from based on the relevance scores of the input features that correspond to the one or more topics, and causing the application to unsubscribe from the one or more topics.

Description

SPECIFICATIONCONTROLLING APPLICATION TOPIC SUBSCRIPTIONSTECHNICAL FIELD

[0001] Embodiments disclosed herein relate to the field of computer networks, and more specifically, to controlling application topic subscriptions.BACKGROUND

[0002] Open radio access network (0-RAN or Open RAN) is a nonproprietary version of the radio access network (RAN) system that allows interoperation between network equipment provided by different vendors. The 0-RAN architecture introduces a new type of automation application called rApp. An rApp is an application / software that is designed to run on a non-real time intelligent controller to realize different RAN automation and management use cases, with control loops on a time scale of one second and longer. An rApp may communicate with various services provided by a service management and orchestration (SMO) platform using a publish-subscribe messaging model. For example, an rApp may send a subscription request to the SMO platform to subscribe to a particular topic (e.g., the request may be sent via an R1 interface with the SMO platform). Once the rApp is subscribed to a particular topic, the SMO platform may send messages related to the particular topic to the rApp when there is updated information to send. As an example, if an rApp subscribes to the “EnergyMeter.pmConsumedEnergy” topic, the SMO platform may send messages to the rApp when the energy consumption of a radio unit changes.

[0003] An rApp, and particularly an rApp that leverages machine learning (ML) models, might be subscribed to topics that are not that important for its operation. This can happen due to an rApp developer over-engineering the rApp to cater to several different features that relate to the rApp’s task and / or due to the rAPP developer not knowing in advance which topics are relevant for the rApp to perform its task. The rApp’s oversubscription to topics can result in an increased amount of data transfers across the message bus between the rApp and the SMO platform. In some situations, an rApp requires access to data at a higher rate than the message bus between the rApp and the SMO platform can practically support.

[0004] If the message bus does not have sufficient capacity to support all of the topic subscriptions, then the message bus may become a bottleneck or a single point of failure. The message bus and / or the SMO platform may be operating in a shared resource environment (e.g., a cloud computing environment), in which case it is not always guaranteed that there will besufficient resource capacity (e.g., computing, storage, and / or network resource capacity) available to support all of the topic subscriptions. When there is insufficient resource capacity, the rApp consumes data from topics at reduced rates, which may degrade the performance of the rApp, or worse yet, cause the rApp to shut down.SUMMARY

[0005] Disclosed herein is a method performed by one or more network devices implementing a subscription manager of a service management and orchestration platform to control application topic subscriptions. The method includes obtaining a machine learning model that was trained to predict output data of an application from input data of the application, wherein the machine learning model has a plurality of input features that corresponds to a plurality of topics that the application reads data from, determining a relevance score for each of the plurality of input features using the machine learning model, determining that the application can unsubscribe from one or more of the plurality of topics that the application reads data from based on the relevance scores of the input features that correspond to the one or more topics, and causing the application to unsubscribe from the one or more topics.

[0006] Disclosed herein is a non-transitory machine-readable medium comprising computer program code which when executed by a network device functioning as a subscription manager of a service management and orchestration platform carries out operations for controlling application topic subscriptions. The operations include obtaining a machine learning model that was trained to predict output data of an application from input data of the application, wherein the machine learning model has a plurality of input features that corresponds to a plurality of topics that the application reads data from, determining a relevance score for each of the plurality of input features using the machine learning model, determining that the application can unsubscribe from one or more of the plurality of topics that the application reads data from based on the relevance scores of the input features that correspond to the one or more topics, and causing the application to unsubscribe from the one or more topics.

[0007] Disclosed herein is a network device that is to function as a subscription manager of a service management and orchestration platform. The network device includes one or more processors and a non-transitory machine-readable storage medium that stores instructions, which when executed by the one or more processors, causes the subscription manager to perform operations for controlling application topic subscriptions. The operations include obtaining a machine learning model that was trained to predict output data of an application from input data of the application, wherein the machine learning model has a plurality of input features that corresponds to a plurality of topics that the application reads data from, determining a relevancescore for each of the plurality of input features using the machine learning model, determining that the application can unsubscribe from one or more of the plurality of topics that the application reads data from based on the relevance scores of the input features that correspond to the one or more topics, and causing the application to unsubscribe from the one or more topics.BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The invention may best be understood by referring to the following description and accompanying drawings that are used to illustrate particular embodiments of the invention. In the drawings:

[0009] Figure 1 is a diagram showing an environment in which application topic subscription can be controlled, according to some embodiments.

[0010] Figure 2 is a diagram showing component interactions to control application topic subscriptions, according to some embodiments.

[0011] Figure 3 is a diagram showing a federated learning approach to training a ML model, according to some embodiments.

[0012] Figure 4 is a diagram showing a cart pole example to demonstrate the effectiveness of some embodiments.

[0013] Figure 5 is a flow diagram of a method for controlling application topic subscriptions, according to some embodiments.

[0014] Figure 6 is a diagram showing a mobile network that includes network devices that can implement embodiments.

[0015] Figure 7 is a diagram showing specific examples of how a network device may be implemented in certain embodiments.DETAILED DESCRIPTION

[0016] The following description describes methods and apparatus for controlling application topic subscriptions. In the following description, numerous specific details such as logic implementations, opcodes, means to specify operands, resource partitioning / sharing / duplication implementations, types and interrelationships of system components, and logic partitioning / integration choices are set forth in order to provide a more thorough understanding of embodiments. It will be appreciated, however, by one skilled in the art that embodiments may be practiced without such specific details. In other instances, control structures, gate level circuits and full software instruction sequences have not been shown in detail in order not to obscure the description. Those of ordinary skill in the art, with the included descriptions, will be able to implement appropriate functionality without undue experimentation.

[0017] References in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0018] Bracketed text and blocks with dashed borders (e.g., large dashes, small dashes, dotdash, and dots) may be used herein to illustrate optional operations that add additional features to embodiments. However, such notation should not be taken to mean that these are the only options or optional operations, and / or that blocks with solid borders are not optional in certain embodiments.

[0019] In the following description and claims, the terms “coupled” and “connected,” along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. “Coupled” is used to indicate that two or more elements, which may or may not be in direct physical or electrical contact with each other, co-operate or interact with each other. “Connected” is used to indicate the establishment of communication between two or more elements that are coupled with each other.

[0020] An electronic device stores and transmits (internally and / or with other electronic devices over a network) code (which is composed of software instructions and which is sometimes referred to as computer program code or a computer program) and / or data using machine-readable media (also called computer-readable media), such as machine-readable storage media (e.g., magnetic disks, optical disks, solid state drives, read only memory (ROM), flash memory devices, phase change memory) and machine-readable transmission media (also called a carrier) (e.g., electrical, optical, radio, acoustical or other form of propagated signals - such as carrier waves, infrared signals). Thus, an electronic device (e.g., a computer) includes hardware and software, such as a set of one or more processors (e.g., wherein a processor is a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, other electronic circuitry, a combination of one or more of the preceding) coupled to one or more machine-readable storage media to store code for execution on the set of processors and / or to store data. For instance, an electronic device may include non-volatile memory containing the code since the non-volatile memory can persist code / data even when the electronic device is turned off (when power is removed), and while the electronic device is turned on that part of the code that is to beexecuted by the processor(s) of that electronic device is typically copied from the slower nonvolatile memory into volatile memory (e.g., dynamic random access memory (DRAM), static random access memory (SRAM)) of that electronic device. Typical electronic devices also include a set of one or more physical network interface(s) (NI(s)) to establish network connections (to transmit and / or receive code and / or data using propagating signals) with other electronic devices. For example, the set of physical NIs (or the set of physical NI(s) in combination with the set of processors executing code) may perform any formatting, coding, or translating to allow the electronic device to send and receive data whether over a wired and / or a wireless connection. In some embodiments, a physical NI may comprise radio circuitry capable of receiving data from other electronic devices over a wireless connection and / or sending data out to other devices via a wireless connection. This radio circuitry may include transmitter(s), receiver(s), and / or transceiver(s) suitable for radiofrequency communication. The radio circuitry may convert digital data into a radio signal having the appropriate parameters (e.g., frequency, timing, channel, bandwidth, etc.). The radio signal may then be transmitted via antennas to the appropriate recipient(s). In some embodiments, the set of physical NI(s) may comprise network interface controller(s) (NICs), also known as a network interface card, network adapter, or local area network (LAN) adapter. The NIC(s) may facilitate in connecting the electronic device to other electronic devices allowing them to communicate via wire through plugging in a cable to a physical port connected to a NIC. One or more parts of an embodiment o may be implemented using different combinations of software, firmware, and / or hardware.

[0021] A network device (ND) is an electronic device that communicatively interconnects other electronic devices on the network (e.g., other network devices, end-user devices). Some network devices are “multiple services network devices” that provide support for multiple networking functions (e.g., routing, bridging, switching, Layer 2 aggregation, session border control, Quality of Service, and / or subscriber management), and / or provide support for multiple application services (e.g., data, voice, and video).

[0022] As mentioned above, an rApp may be oversubscribed to topics. That is, the rApp may be subscribed to topics that have little or no impact on the output of the rApp. Also, an rApp might be designed to perform many tasks (e.g., turn a radio frequency (RF) port on / off or adjust the transmission power of a base station), but there might be situations where it is only possible to perform a subset of the tasks, which makes inputs related to the other tasks unnecessary. An rApp’s subscription to a topic remains active even if the topic has little or no impact on the output of the rApp. Topic oversubscription can result in an increased amount of data transfers across the message bus between the rApp and the service management and orchestration (SMO) platform. If the message bus does not have sufficient capacity to support all of the topicsubscriptions, then the message bus may become a bottleneck or a single point of failure. The message bus and / or the SMO platform may be operating in a shared resource environment, in which case it is not always guaranteed that there will be sufficient resource capacity available to support all of the topic subscriptions. When there is insufficient resource capacity, the rApp consumes data from topics at reduced rates, which may degrade the performance of the rApp, or worse yet, cause the rApp to shut down.

[0023] Embodiments are disclosed herein that are able to control application topic subscriptions to reduce resource consumption when needed. Embodiments can determine which topics have little or no impact on the output of an application (e.g., an rApp) and allow the application to unsubscribe from such topics (e.g., when there is a need to reduce resource consumption), at least temporarily (e.g., until more resource capacity becomes available). According to an embodiment, a subscription module of a SMO platform obtains a machine learning (ML) model that is trained to predict the output data of the application from input data of the application. The ML model may have input features that correspond to the topics that the application reads data from. The subscription module may determine a relevance score for each of the ML model’s input features. The relevance score for an input feature of a ML model may indicate how relevant the input feature is to the output of the ML model (and thus how relevant the topic corresponding to the input feature is to the output of the application). In an embodiment, the subscription module determines the relevance scores for the input features based on applying a feature importance algorithm (e.g., Shapley Value algorithm) or similar algorithm to the ML model. The subscription module may determine that the application can unsubscribe from one or more of the topics that the application reads data from based on the relevance scores of the input features that correspond to those one or more topics. Lor example, the subscription module may determine that the application can unsubscribe from topics that are determined to be less impactful to the output of the application according to the relevance scores (e.g., a topic corresponding to an input feature having a relevance score that is below a predefined threshold score may be considered to be less impactful to the output of the application). In an embodiment, the predefined threshold score is preconfigured in the subscription manager or SMO platform by an administrator or other personnel. In an embodiment, the predefined threshold score can be configured on a per-application basis (i.e., different thresholds can be used for different applications). The subscription manager may then cause the application to unsubscribe from the less impactful topics. In an embodiment, if a condition for resubscribing to a topic is met (e.g., sufficient resource capacity becomes available to support topic subscription), then the subscription manager may cause the application toresubscribe to the topic. Thus, the unsubscription from the topic can be permanent or temporary.

[0024] The ML model may be trained using historical information regarding the inputs and the outputs of the application. For example, the subscription module may monitor the input data of the application and the output data of the application, where the input data is associated with the topics that the application reads data from (e.g., the topics that the application has subscribed to and has read-only access) and the output data is associated with the topics that the application writes to (the topics that the application has subscribed to and has write access). The subscription module may then generate a dataset based on the monitored input data and the monitored output data. The subscription module may train the ML model using the generated dataset. The ML model can be trained until it is deemed to have sufficient prediction accuracy (e.g., based on mean squared error (MSE), mean absolute error (MAE), area under curve (e.g., for binary classification tasks), or accuracy tests (e.g., for classification tasks)).

[0025] Advantageously, embodiments can be used to reduce resource consumption (e.g., in terms of computing, storage, network, and / or energy resources) in a SMO platform (or other type of platform that communicates with applications using a publish-subscribe messaging model), while still providing applications with sufficient data that allows the applications to perform their respective tasks without sacrificing much performance / accuracy. Topic subscriptions are typically maintained in the form of UNIX sockets, of which there are a finite amount (typically 65,536). Using embodiments, sockets for less impactful topics can be released and be made available for other processes. Also, in an embodiment, if a topic becomes free of subscriptions after an application unsubscribes from the topic, then the SMO platform can pause data collection for that topic, which can further reduce resource consumption. Embodiments can be used to control application topic subscriptions to reduce unnecessary data transfers (e.g., when the SMO platform has low resource capacity).

[0026] Embodiments can be viewed as expanding the SMO platform architecture to support two variants of the same application: (1) a first variant that provides better performance / accuracy but consumes more resources; and (2) a second variant that consumes less resources than the first variant but manages to achieve similar performance / accuracy. With embodiments, the second variant does not need to be manually engineered / developed, thus reducing development costs.

[0027] There could be privacy concerns with observing the inputs and outputs of an application. However, identifying which topics are not critical for the proper functioning of an application based on the application’s input and output may not be a significant concern. In a different technological field of interpreted programming languages, garbage collectiontechniques release memory of unused (or unreferenced) variables, and in the process can learn something sensitive about the inner workings of an application in the process. However, such technique has come to be expected and not considered to be invasive. In a similar vein, observing the inputs and outputs of an application for the purpose of pruning topic subscriptions to reduce resource consumption may not be considered to be invasive. In an embodiment, the SMO platform (or other platform hosting / supporting the application) may explicitly state what it is doing (e.g., reading input data of an application) and for what purpose (e.g., for controlling application topic subscription) to provide transparency and allow an application developer to opt out or configure the amount / duration of data that is collected by the SMO platform, if desired.

[0028] Embodiments are further described with reference to the accompanying figures.

[0029] Figure 1 is a diagram showing an environment in which application topic subscription can be controlled, according to some embodiments.

[0030] As shown in the diagram, the environment includes applications 110A-K, a SMO platform 120, network management systems 170A-X, and RANs 180A-X. A particular arrangement of components is shown in the diagram to help illustrate an embodiment. It should be appreciated that the diagram shows one example arrangement of components and that other embodiments can have a different arrangement of components that achieves the same / similar functionality.

[0031] The SMO platform 120 may be a platform that provides services and orchestration functionality for automating RANs 180 using artificial intelligence (Al). In an embodiment, the SMO platform 120 is part of an Open Radio Access Network (0-RAN or Open RAN) architecture. As shown in the diagram, the SMO platform includes an interface 130 for communicating with applications 110, a subscription manager 140, and services 160A-M. The interface 130 may allow the SMO platform 120 and applications 110 to communicate with each other. In an embodiment, the interface 130 is a R1 interface of 0-RAN architecture.Services 160A-M may provide various services for supporting the automation of RANs 180. A service 160 may provide one or more topics 165 that applications 110 can subscribe to. For example, as shown in the diagram, service 160A provides topics 165 A and service 160M provides topics 165M. An application 110 that is subscribed to atopic 165 may read data from the topic 165, write data to the topic 165, or both. As an example, service 160A may be a performance metric service that provides topics 165 that allow applications 110 to obtain information regarding the performance of the RANs 180 (e.g., by reading data from the topics 165) and service 160M may be a configuration management service that provides topics 165 that allow applications 110 to configure RANs 180 (e.g., by writing data to the topics 165). The SMO platform 120 may obtain data that is to be published to topics 165 fromnetwork management systems 170. Also, the SMO platform 120 may interact with network management systems 170 to configure RANs 180 to effectuate the data written to topics 165 by applications 110.

[0032] Applications 110 may provide RAN automation and management functionality. For example, applications 110 may implement functionality for providing network evolution, network deployment, network optimization, and / or network healing. Network evolution may enhance network planning with more efficient radio frequency (RF) planning, site selection, and capacity management. Network evolution may improve network and service performance and enable new revenues for a network operator by providing data driven and intent-based insights and recommendations. Network deployment may handle the provisioning and life cycle management of complex networks with optimal costs and speed to market. Network optimization may offer intelligent autonomous functions to optimize customer experience and return on investments (e g., RF shaping, traffic and mobility management, energy efficiency, etc.). Network healing may ensure service continuity and resolution of both basic and complex incidents, delivering high availability while keeping the operation costs low. In an embodiment, an application 110 is an rApp or an xApp. An rApp is designed to run on a non-real time intelligent controller to realize different RAN automation and management use cases, with control loops on a time scale of one second and longer. An xApp is designed to manage network functions in near-real time. In an embodiment, an application 110 is a network function of a mobile network data analytics framework (e.g., a network function of a Third Generation Partnership Project (3GPP) network data analytics framework (NWDAF)). In an embodiment, different applications 110 may be developed by different vendors.

[0033] Network management systems 170 may provide network management functionality for their respective RANs 180. For example, as shown in the diagram, network management system 170A provides network management functionality for RAN 180A and network management system 170X provides network management functionality for RAN 180X. Network management functionality provided by a network management system 170 may include performance monitoring (e.g., collecting metrics related to the functioning of a RAN 180), device detection and configuration, performance analysis, and / or notification alerts (e.g., notifying an administrator when there are network disruptions).

[0034] RANs 180 may provide radio access for end user devices (e.g., smartphones, laptops, desktops, tablets, vehicles, Internet of Things (loT) devices, etc.) that allow the end user devices to connect to a core network (e.g., a Fifth Generation (5G) core network or similar core network). In an embodiment, a RAN 180 may be virtualized and implemented in a cloud (virtualized RAN).

[0035] As will be described in further detail herein, the subscription manager 140 may control topic subscriptions for applications 110. For example, if the subscription manager 140 determines that the SMO platform 120 has low resource capacity (e.g., compute, storage, and / or network resource capacity), the subscription manager 140 may identify topics 165 that are considered less impactful to the output of an application 110 and cause the application 110 to unsubscribe from those topics 165, at least temporarily. This allows for conserving the resources of the SMO platform 120 during times of low resource capacity without sacrificing much performance / accuracy of the application 110. If the subscription manager 140 subsequently determines that the SMO platform 120 has sufficient resource capacity to support additional topic subscriptions, the subscription manager 140 may cause the application 110 to resubscribe to the topics 165.

[0036] Example operations for controlling application topic subscriptions will now be described with reference to the diagram to illustrate an embodiment. As shown in the diagram, at step 1, application 110A subscribes to topics 165. For example, application 110A may subscribe to one or more topics 165 A provided by service 160A and one or more topics 165M provided by service 160M. Application 110A may subscribe to topics 165 by sending subscription requests to the SMO platform 120 via the interface 130. Application 110A may read data from a topic 165, write data to the topic 165, or both (e.g., via interface 130). In this example, application 110A reads data from one or more topics 165 A provided by service 160A (e.g., RAN performance metric data) but does not write to the topics 165 provided by service 160A (application 110A has read-only access). Also, application 110A reads data from and writes data (e.g., RAN configuration parameters) to one or more topics 165M provided by service 160M (application 110A has read and write access). At step 2, the subscription manager 140 monitors the input data of application 110A and the output data of application 110A to generate a dataset, D. The input data of application 110A may be associated with the topics 165 that application 110A reads data from (e.g., topics 165 provided by service 160A and service 160M). The output data of application 110A may be associated with the topics 165 that application 110A writes data to (e.g., topics 165 provided by service 160M). The dataset D may associate or correlate the input data with the output data (e.g., to indicate which input data caused the application 110 to produce which output data). The association between the input data and the output data may be formed based on the timing of when the input data was received and the output data was sent (e.g., certain input data may be associated with output data that was generated shortly after the input data was received). At step 3, the subscription manager 140 trains a ML model 150 using the dataset D. The ML model 150 may be trained to predict output data of application 110A from input data ofapplication 110A. The ML model 150 may have input features that correspond to the topics 165 that application 110 reads data from. The ML model 150 may be trained using supervised learning, unsupervised learning, and / or reinforcement learning. The ML model 150 may be trained until sufficient prediction accuracy is achieved (e.g., based on MSE or MAE). In an embodiment, part of the dataset D is used for model training purposes and another part of the dataset D is used for model validation.

[0037] At operation 4, the subscription manager 140 identifies topics 165 that are less impactful to the output of application 110A. In an embodiment, the subscription manager 140 determines the less impactful topics 165 based on determining a relevance score for each of the input features of the ML model 150. The relevance score of an input feature may indicate how relevant / impactful the topic 165 corresponding to the input feature is to the output of application 110A. In an embodiment, topics 165 corresponding to input features having relevance scores that are below a predefined threshold score are considered to be less impactful. The subscription manager 140 may determine the relevance scores based on applying a feature importance algorithm to the ML model 150. The feature importance algorithm may be based on a Shapley Value analysis algorithm, feature ablation, principal component analysis, gradientbased analysis, function approximation, rule extraction, logic-based explanation, or any combination thereof. In an embodiment, a rule extraction algorithm may turn an ML model 150 into a set of rules in the form of "IF feature_l=value_l, ..., fcaturc -valiic ' THEN class value / probability." A relevance score may be calculated based on how frequently an input feature appears in such rules. Input features that do not appear among such rules or appears infrequently can be considered as less impactful or redundant.

[0038] In an embodiment, if the subscription manager 140 determines that the SMO platform 120 is low on resource capacity (or detects some other event that triggers topic unsubcriptions), the subscription manager 140 may perform operation 5 shown in the diagram to reduce the resource consumption of the SMO platform 120. At step 5, the subscription manager 140 causes application 110A to unsubscribe from the less impactful topics 165.

[0039] In an embodiment, if the subscription manager 140 subsequently determines that the SMO platform 120 has sufficient resource capacity to support resubscription to the less impactful topics 165 (or detects some other event that triggers topic re subscription), the subscription manager 140 may cause application 110A to resubscribe to the less impactful topics 165.

[0040] In an embodiment, if a topic 165 becomes free of subscriptions after an application 110 unsubscribes from the topic 165, then the SMO platform 120 can pause data collection for that topic 165, which can further reduce resource consumption.

[0041] Figure 2 is a diagram showing component interactions to control application topic subscriptions, according to some embodiments.

[0042] As shown in the diagram, an application 110 may send a subscription request to the subscription manager 140 to subscribe to a set of topics, T, which includes topics tl to tn. In response, the subscription manager 140 may subscribe application 110 to topics T (e.g., by sending an instruction to the SMO platform 120).

[0043] The SMO platform 120 may publish data from one or more of the topics T to the subscription manager 140, which relays the data to the application 110. This data may be considered to be the input data of the application 110. The application 110 may send a request to write data to one or more of the topics T to the subscription manager 140, which relays this request to the SMO platform 120. In response, the SMO platform 120 may attempt to write the data to the topics. If the write is successful, the SMO platform 120 may send an acknowledgement (ACK) to the application 110. The data that the application 110 writes to topics may be considered to be the output data of the application 110. The subscription manager 140 may monitor and keep a log / record of the input data and output data of the application 110.

[0044] The subscription managerl40 may generate a dataset, D, based on the monitored input data and output data of the application 110. The subscription manager 140 may then train a ML model, M, using the dataset D. The ML model M may be trained to predict the output data of the application 110 from the input data of the application 110. The ML model may have input features that correspond to the topics that the application 110 reads data from.

[0045] The subscription manager 140 may determine which topics are less impactful to the output data of the application 110 based on applying a feature importance algorithm to the ML model M (and possibly dataset D). The subscription manager 140 may then send an unsubscribe request to the application 110 to unsubscribe from the less impactful topics, F (where F is a subset of T). The application 110 may decide to accept or deny the request. In this example, it is assumed that the application 110 accepts the unsubscribe request and thus sends an acknowledgement (ACK) to the subscription manager 140. In response to receiving the acknowledgement from the application 110, the subscription manager 140 may unsubscribe the application 110 from the less impactful topics F (e.g., by sending an instruction to the SMO platform 120). In an alternative embodiment, the frequency with which the application receives data from one or more of the less impactful topics F can be reduced (in lieu of unsubscribing from those topics).

[0046] The subscription manager 140 may continually / periodically monitor the resource capacity of the SMO platform 120 (“loop”). If the subscription manager 140 determines that theSMO platform 120 has low resource capacity, then the subscription manager 140 may keep the application 110 unsubscribed from the less impactful topics F to conserve resources. If, however, the subscription manager 140 determines that the SMO platform 120 has sufficient resource capacity to support resubscription to the less impactful topics F, the subscription manager 140 may exit the loop and send a resubscribe message to the application 110 to indicate that the application 110 can resubscribe to the less impactful topics F. The application 110 may decide to accept or deny the request. In this example, it is assumed that the application 110 accepts the resubscribe request and thus sends an acknowledgement (ACK) to the subscription manager 140. In response to receiving the acknowledgement from the application 110, the subscription manager 140 may resubscribe the application 110 to the less impactful topics F (e.g., by sending an instruction to the SMO platform 120).

[0047] For sake of simplicity, the diagram shows an example where the subscription manager 140 controls the topic subscriptions of a single application 110. It should be appreciated that the subscription manager 140 can control the topic subscriptions of more than one application 110. In an embodiment, if an application 110 denies an unsubscribe request from the subscription manager 140, the subscription manager 140 may attempt to get another application (or another instance of the same application) to unsubscribe from less impactful topics to help reduce resource consumption at the SMO platform 120. In the example shown in the diagram, the application 110 remains unsubscribed from the less impactful topics until the subscription manager 140 determines that the SMO platform 120 has sufficient resource capacity to support resubscription. In an alternate embodiment, the application 110 may resubscribe to the less impactful topics after a certain length of time has elapsed since the application 110 unsubscribed from those topics. The decision of when the application 110 can resubscribe to an unsubscribed topic may vary depending on the implementation. In an embodiment, the decision may be based on the length of time that the application 110 has been unsubscribed to the unsubscribed topic, the sustainability goals of the application 110, and / or the customer subscription level associated with the application 110 (e.g., “gold” tier customers may have priority over lower tier customers (e.g., “silver” or “bronze” tier customers) when it comes to resubscribing their applications 110).

[0048] In an embodiment, the subscription manager 140 proactively controls application topic subscriptions. For example, the subscription manager 140 may employ a predictive model to predict when the SMO platform 120 will have lower resource capacity and use the techniques described herein to identify less impactful topics and cause the applications 110 to unsubscribe from the less impactful topics to reduce resource consumption in advance (e.g., which mighthelp avoid the SMO platform 120 from getting into a situation where it has low resource capacity).

[0049] In an embodiment, the subscription manager 140 indicates performance constraints on a specific interface to the application 110 (e.g., by publishing a congestion indicator with an associated interface identification). This may be done preemptively for an interface by means of mechanisms on the network that prioritize an interface down due to resource constraints; these resource constraints may be due to the inability of a subsystem to support the measurement service at the level of performance demanded by the application 110. Under such circumstances, the application 110 can accede to operate at a lower grade of service or may request deactivation of the interface. For example, a topic may be oversubscribed in terms of the frequency at which a measurement is requested. The frequency may be a consequence of requesting measurements across multiple interfaces at the rate desired by the most active interface. Under such circumstances, a determination that one such interface cannot handle the request rate demanded may result in the interface being subject to congestion control mechanisms and deprioritized.

[0050] Deactivation or temporary degrading of the interface may not be necessary if resources are eventually made available to exercise the interface later at a required performance level. In such a situation, the subscription manager 140 may directly signal the restart of an interface or boosting of an interface to the application 110.

[0051] While various embodiments are described herein in the context of a SMO platform 120, embodiments are not so limited. The techniques for controlling application topic subscriptions disclosed herein can be applied in other contexts that use a publish-subscribe messaging model.

[0052] Figure 3 is a diagram showing a federated learning approach to training a MU model, according to some embodiments.

[0053] In an embodiment the MU model for predicting the output data of an application from input data of the application can be generated using a federated learning approach. For example, as shown in the diagram, multiple subscription managers (e.g., subscription managers 140A-N) of multiple SMO platforms 120 (e.g., SMO platforms 120A-H) may monitor input data and output data of different instances of the same application (e.g., instances 110A-N) and each generate a dataset based on the monitored input data and output data. In the example shown in the diagram, subscription manager 140A monitors input data and output data of application instance 110A and generates dataset DI based on the monitored data. Similarly, subscription manager 140N monitors input data and output data of application instance 110N and generates dataset DM based on the monitored data. Each subscription manager 140 may train a ME model using the datasetthat it generated. For example, subscription manager 140A may train ML model, Ml, using dataset DI. Similarly, subscription manager MON may train ML model, Mw, using dataset DM. The different ML models and / or datasets may be aggregated to generate an aggregated ML model, M. In this way, the monitoring mechanism may be extended to monitor input data and output data of multiple instances of the same application implemented in different networks / platforms to further generalize the data that is used to train the ML model M. This may help with improving the prediction accuracy of the ML model.

[0054] Figure 4 is a diagram showing a cart pole example to demonstrate the effectiveness of some embodiments.

[0055] The classic control problem of cart pole balancing is used to demonstrate the effectiveness of the embodiments disclosed herein. As shown in the diagram, a cart pole balancing application 110 may have four inputs. These inputs are the cart position (“cart_position”), the cart velocity (“cart_velocity”), the pole angle (“pole_angle”), and the pole angular velocity (“pole_angular_velocity”). The application 110 may subscribe to a separate topic for each of the inputs and read data from those topics. The application 110 may have two possible actions as an output, either move the cart to the left or move the cart to the right to try to avoid letting the pole fall to the floor. The application 110 may subscribe to a topic for the output and write data to the topic. The application 110 implements a near-real time control loop to solve the cart pole balancing problem. This application is similar to an objective that an xApp may try to meet.

[0056] Tuples of the four inputs can be collected as feature-value pairs and labeled with the observed output (the action) to generate a dataset for training a classification ML model using supervised learning. A feature importance algorithm (e.g., a Shapley value analysis algorithm) can be applied to the trained ML model to identify the less impactful input features. Using this technique, it was found that the features of “pole_angle” and “pole_angular_velocity” are less impactful (as they had a relevance score that is below a threshold score). When these two input features are removed from being inputs (e.g., by putting old or random values for these features), the agent is able to maintain a reward that is slightly less than the original reward but still within the range of tolerance.

[0057] Figure 5 is a flow diagram of a method for controlling application topic subscriptions, according to some embodiments. In an embodiment, the method is performed by a subscription manager of a SMO platform. The method may be implemented using hardware, software, firmware, or any combination thereof.

[0058] The operations in the flow diagram will be described with reference to the exemplary embodiments of the other figures. However, it should be understood that the operations of theflow diagram can be performed by embodiments other than those discussed with reference to the other figures, and the embodiments discussed with reference to these other figures can perform operations different than those discussed with reference to the flow diagram.

[0059] While the flow diagram shows a particular order of operations performed by certain embodiments, it should be understood that such order is provided by way of example and should not be regarded as limiting (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

[0060] At operation 510, the subscription manager obtains a machine learning model that was trained to predict output data of an application from input data of the application. The machine learning model has a plurality of input features that corresponds to a plurality of topics that the application reads data from. In an embodiment, the application is an rApp, an xAPP, or a network function of a mobile network data analytics framework.

[0061] In an embodiment, the subscription manager obtains the machine learning model from another component (e.g., another component may train the machine learning model and provide the machine learning model to the subscription manager). In an embodiment, the subscription manager obtains the machine model by training the machine learning model. For example, at operation 520, the subscription manager may monitor input data and output data of the application. The input data of the application is associated with the plurality of topics that the application reads data from. The output data of the application is associated with one or more topics that the application writes data to. At operation 530, the subscription manager generates a dataset based on the monitored input data of the application and the monitored output data of the application. At operation 540, the subscription manager trains the machine learning model using the dataset. In an embodiment, the machine learning model is trained using supervised learning, unsupervised learning, or reinforcement learning. In an embodiment, the machine learning model is further trained using one or more other datasets that were generated based on monitored input data and monitored output data of one or more other instances of the application (e.g., a federated learning approach as shown in Figure 3).

[0062] At operation 550, the subscription manager determines a relevance score for each of the plurality of input features using the machine learning model. In an embodiment, the relevance scores of the plurality of input features are determined based on applying a feature importance algorithm to the machine learning model. In an embodiment, the feature importance algorithm is based on one or more of: a Shapley Value analysis algorithm, feature ablation, principal component analysis, gradient-based analysis, function approximation, rule extraction, and logic-based explanation.

[0063] At operation 560, the subscription manager determines that an application can unsubscribe from one or more of the plurality of topics that the application reads data from based on the relevance scores of the input features that correspond to the one or more topics. In an embodiment, the determination that the application can unsubscribe from the one or more topics is based on a determination that the relevance scores of the input features corresponding to the one or more topics are lower than a predefined threshold score.

[0064] At operation 570, the subscription manager causes the application to unsubscribe from the one or more topics. In an embodiment, the subscription manager predicts that a resource capacity of the service management and orchestration platform will be reduced, wherein the application is caused to be unsubscribed from the one or more topics as a response to the prediction.

[0065] In an embodiment, at operation 580, the subscription manager determines whether a condition for resubscribing to an unsubscribed topic has been met. In an embodiment, the condition for resubscribing to the unsubscribed topic is based on one or more of: a resource capacity of the service management and orchestration platform, a length of time that has elapsed since the application unsubscribed from the unsubscribed topic, sustainability goals of the application, and a customer subscription level associated with the application. If the condition for resubscribing to the unsubscribed topic has not been met, the subscription manager may continue checking until the condition is met. If the condition for resubscribing to the unsubscribed topic is met, at operation 590, the subscription manager causes the application to resubscribe to the unsubscribed topic.

[0066] Figure 6 is a diagram showing a mobile network that includes network devices that can implement embodiments.

[0067] Network device (ND) 620 may, in some embodiments, be an electronic device that can be communicatively connected to other electronic devices on the network (e.g., other network devices, user equipment devices (UEs), radio base stations, etc.). As depicted in Figure 6, the example network device 620 comprises processor 611, memory 612, and interface 613. These components may work together to provide various network device functionality as disclosed herein.

[0068] Processor 611 may be a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, any other type of electronic circuitry, or any combination of one or more of the preceding. The processor 611 may comprise one or more processor cores. In particular embodiments, some or all of the functionality described herein as being provided by network device 620 may beimplemented by processor 611 executing software instructions, either alone or in conjunction with other network device 620 components, such as memory 612.

[0069] Memory 602 may store code (which is composed of software instructions and which is sometimes referred to as computer program code or a computer program) and / or data using non- transitory machine-readable (e.g., computer-readable) media, such as machine-readable storage media (e.g., magnetic disks, optical disks, solid state drives, read only memory (ROM), flash memory devices, phase change memory) and machine-readable transmission media (e.g., electrical, optical, radio, acoustical or other form of propagated signals - such as carrier waves, infrared signals). For instance, memory 612 may comprise non-volatile memory containing code to be executed by processor 611. Where memory612 is non-volatile, the code and / or data stored therein can persist even when the network device is turned off (when power is removed). In some instances, while network device 620 is turned on that part of the code that is to be executed by the processor(s) 611 may be copied from non-volatile memory into volatile memory (e.g., dynamic random access memory (DRAM), static random access memory (SRAM)) of network device 620.

[0070] Interface 613 may be used in the wired and / or wireless communication of signaling and / or data to or from network device 620. For example, interface 613 may perform any formatting, coding, or translating to allow network device 620 to send and receive data whether over a wired and / or a wireless connection. In some embodiments, interface 613 may comprise network interface controller(s) (NICs), also known as a network interface card, network adapter, local area network (LAN) adapter or physical network interface. The NIC(s) may facilitate in connecting the network device 620 to other devices allowing them to communicate via wire through plugging in a cable to a physical port connected to a NIC. As explained above, in particular embodiments, processor 611 may represent part of interface 613, and some or all of the functionality described as being provided by interface XI 13 may be provided more specifically by processor 611.

[0071] The components of network device 620 are each depicted as separate boxes located within a single larger box for reasons of simplicity in describing certain aspects and features of network device 620 disclosed herein. In practice however, one or more of the components illustrated in the example network device 620 may comprise multiple different physical elements (e.g., interface 613 may comprise terminals for coupling wires for a wired connection and a radio transceiver for a wireless connection).

[0072] The solution described herein may be implemented in the network device 620 by means of a computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the actions according to any of the abovefeatures and embodiments, where appropriate. For example, memory 612 may include a subscription manager module 615 that when executed by processor 611 causes the ND 620 to perform operations of a subscription manager, as described herein above.

[0073] While the modules are illustrated as being implemented in software stored in memory 612, other embodiments implement part or all of each of these modules in hardware.

[0074] For a more thorough description of the example embodiment of network device 620 described in Figure 6, turn to Figure 7 below.

[0075] ND 600 may be a base station in a mobile network. As depicted in Figure 6, the example network device 600 comprises processor 601, memory 602, interface 603, and antenna 604. These components may work together to implement base station functionality (e.g., RAN functionality) as disclosed herein. The processor 601, memory 602, and interface 603 may be similar to the processor 611, memory 612, and interface 613 described above.

[0076] In certain embodiments, network device 600 may include radio access features that provide wireless radio network access to other electronic devices (for example a “radio access network device" may refer to such a network device) such as user equipment devices (UEs). For example, network device 600 may be a base station, such as eNodeB in Long Term Evolution (LTE), NodeB in Wideband Code Division Multiple Access (WCDMA) or other types of base stations, as well as a Radio Network Controller (RNC), a Base Station Controller (BSC), or other types of control nodes.

[0077] In some embodiments, interface 603 may comprise radio circuitry capable of receiving data from other devices in the network over a wireless connection and / or sending data out to other devices via a wireless connection. This radio circuitry may include transmitter(s), receiver(s), and / or transceiver(s) suitable for radiofrequency communication. The radio circuitry may convert digital data into a radio signal having the appropriate parameters (e.g., frequency, timing, channel, bandwidth, etc.). The radio signal may then be transmitted via antennas 604 to the appropriate recipient(s).

[0078] Figure 7 is a diagram showing specific examples of how ND 600 may be implemented in certain embodiments of the described solution including: 1) a special-purpose network device 702 that uses custom processing circuits such as application-specific integrated-circuits (ASICs) and a proprietary operating system (OS); and 2) a general purpose network device 704 that uses common off-the-shelf (COTS) processors and a standard OS which has been configured to provide one or more of the features or functions disclosed herein.

[0079] Special -purpose network device 702 includes hardware 710 comprising processor(s) 712, and interface 716, as well as memory 718 having stored therein software 720.In one embodiment, the software 720 implements the modules described with regard to the previous figures. During operation, the software 720 may be executed by the hardware 710 to instantiate a set of one or more software instance(s) 722. Each of the software instance(s) 722, and that part of the hardware 710 that executes that software instance (be it hardware dedicated to that software instance, hardware in which a portion of available physical resources (e.g., a processor core) is used, and / or time slices of hardware temporally shared by that software instance with others of the software instance(s) 722), form a separate virtual network element 730A-R. Thus, in the case where there are multiple virtual network elements 730A-R, each operates as one of the network devices from the preceding figures. In an embodiment, a virtual network element 730A executes a subscription module 732 to perform operations of one or more embodiments disclosed herein (e.g., to control application topic subscriptions).

[0080] Returning to Figure 7, the example general purpose network device 704 includes hardware 740 comprising a set of one or more processor(s) 742 (which are often COTS processors) and interface 746, as well as memory 748 having stored therein software 750. During operation, the processor(s) 742 execute the software 750 to instantiate one or more sets of one or more applications 764A-R. While certain embodiments do not implement virtualization, alternative embodiments may use different forms of virtualization. For example, in certain alternative embodiments virtualization layer 754 represents the kernel of an operating system (or a shim executing on a base operating system) that allows for the creation of multiple instances 762A-R called software containers that may each be used to execute one (or more) of the sets of applications 764A-R. In this embodiment, software containers 762A-R (also called virtualization engines, virtual private servers, or jails) are user spaces (typically a virtual memory space) that may be separate from each other and separate from the kernel space in which the operating system is run. In certain embodiments, the set of applications running in a given user space, unless explicitly allowed, may be prevented from accessing the memory of the other processes. In other such alternative embodiments virtualization layer 754 may represent a hypervisor (sometimes referred to as a virtual machine monitor (VMM)) or a hypervisor executing on top of a host operating system; and each of the sets of applications 764A-R may run on top of a guest operating system within an instance 762A-R called a virtual machine (which in some cases may be considered a tightly isolated form of software container that is run by the hypervisor). In certain embodiments, one, some or all of the applications are implemented as unikemel(s), which can be generated by compiling directly with an application only a limited set of libraries (e.g., from a libraiy operating system (LibOS) including drivers / libraries of OS services) that provide the particular OS services needed by the application. As a unikemel can be implemented to run directly on hardware 740, directly on a hypervisor (in which case theunikemel is sometimes described as running within a LibOS virtual machine), or in a software container, embodiments can be implemented fully with unikemels running directly on a hypervisor represented by virtualization layer 754, unikemels running within software containers represented by instances 762A-R, or as a combination of unikemels and the abovedescribed techniques (e.g., unikemels and virtual machines both mn directly on a hypervisor, unikemels and sets of applications that are run in different software containers).

[0081] The instantiation of the one or more sets of one or more applications 764A-R, as well as virtualization if implemented are collectively referred to as software instance(s) 752. Each set of applications 764A-R, corresponding virtualization constmct (e.g., instance 762A-R) if implemented, and that part of the hardware 740 that executes them (be it hardware dedicated to that execution and / or time slices of hardware temporally shared by software containers 762A-R), forms a separate virtual network element(s) 760A-R.

[0082] The virtual network element(s) 760A-R perform similar functionality to the virtual network element(s) 730A-R. This virtualization of the hardware 740 is sometimes referred to as network function virtualization (NFV)). Thus, NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which could be located in for example data centers and customer premise equipment (CPE). However, different embodiments may implement one or more of the software container(s) 762A-R differently. While embodiments are illustrated with each instance 762A-R corresponding to one VNE 760A-R, alternative embodiments may implement this correspondence at a finer level granularity; it should be understood that the techniques described herein with reference to a correspondence of instances 762A-R to VNEs also apply to embodiments where such a finer level of granularity and / or unikemels are used. In an embodiment, a virtual network element 760A executes a subscription module 766 (e.g., which may be a module of an application 764 A) to perform operations of one or more embodiments disclosed herein (e.g., to control application topic subscriptions).

[0083] The third exemplary ND implementation in Figure 7 is a hybrid network device 706, which includes both custom ASICs / proprietary OS and COTS processors / standard OS in a single ND or a single card within an ND. In certain embodiments of such a hybrid network device, a platform virtual machine (VM), such as a VM that that implements the functionality of the special -purpose network device 702, could provide for para-virtualization to the hardware present in the hybrid network device 706.

[0084] Some portions of the preceding detailed descriptions have been presented in terms of algorithms and symbolic representations of transactions on data bits within a computer memory. These algorithmic descriptions and representations are the ways used by those skilled in the dataprocessing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of transactions leading to a desired result. The transactions are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

[0085] It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the above discussion, it is appreciated that throughout the description, discussions utilizing terms such as "processing" or "computing" or "calculating" or "determining" or "displaying" or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

[0086] The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method transactions. The required structure for a variety of these systems will appear from the description above. In addition, embodiments are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of embodiments as described herein.

[0087] An embodiment may be an article of manufacture in which a non-transitory machine- readable storage medium (such as microelectronic memory) has stored thereon instructions (e.g., computer code) which program one or more data processing components (generically referred to here as a “processor”) to perform the operations described above. In other embodiments, some of these operations might be performed by specific hardware components that contain hardwired logic (e.g., dedicated digital filter blocks and state machines). Those operations might alternatively be performed by any combination of programmed data processing components and fixed hardwired circuit components.

[0088] Throughout the description, embodiments have been presented through flow diagrams. It will be appreciated that the order of transactions and transactions described in these flowdiagrams are only intended for illustrative purposes and not intended to be limiting. One having ordinary skill in the art would recognize that variations can be made to the flow diagrams.

[0089] In the foregoing specification, embodiments have been described with reference to specific exemplary embodiments thereof. It will be evident that various modifications may be made thereto without departing from the broader spirit and scope of the disclosure provided herein. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.

Claims

CLAIMSWhat is claimed is:

1. A method performed by one or more network devices implementing a subscription manager of a service management and orchestration platform to control application topic subscriptions, the method comprising: obtaining (510) a machine learning model that was trained to predict output data of an application from input data of the application, wherein the machine learning model has a plurality of input features that corresponds to a plurality of topics that the application reads data from; determining (550) a relevance score for each of the plurality of input features using the machine learning model; determining (560) that the application can unsubscribe from one or more of the plurality of topics that the application reads data from based on the relevance scores of the input features that correspond to the one or more topics; and causing (570) the application to unsubscribe from the one or more topics.

2. The method of claim 1, further comprising: monitoring (520) the input data of the application and the output data of the application, wherein the input data of the application is associated with the plurality of topics that the application reads data from, and the output data of the application is associated with one or more topics that the application writes data to; generating (530) a dataset based on the monitored input data of the application and the monitored output data of the application; and training (540) the machine learning model using the dataset.

3. The method of claim 2, wherein the machine learning model is trained using supervised learning, unsupervised learning, or reinforcement learning.

4. The method of claim 2, wherein the machine learning model is further trained using one or more other datasets that were generated based on monitored input data and monitored output data of one or more other instances of the application.

5. The method of claim 1, further comprising: responsive to determining (580) that a condition for the application to resubscribe to an unsubscribed topic has been met, causing (590) the application to resubscribe to the unsubscribed topic.

6. The method of claim 5, wherein the condition for resubscribing to the unsubscribed topic is based on one or more of: a resource capacity of the service management and orchestration platform, a length of time that has elapsed since the application unsubscribed from the unsubscribed topic, sustainability goals of the application, and a customer subscription level associated with the application.

7. The method of claim 1, further comprising: predicting that a resource capacity of the service management and orchestration platform will be reduced, wherein the application is caused to be unsubscribed from the one or more topics as a response to the prediction.

8. The method of claim 1, wherein the relevance scores of the plurality of input features are determined based on applying a feature importance algorithm to the machine learning model.

9. The method of claim 8, wherein the feature importance algorithm is based on one or more of: a Shapley Value analysis algorithm, feature ablation, principal component analysis, gradient-based analysis, function approximation, rule extraction, and logic-based explanation.

10. The method of claim 1, wherein the application is an rApp, an xAPP, or a network function of a mobile network data analytics framework.

11. The method of claim 1, wherein the determination that the application can unsubscribe from the one or more topics is based on a determination that the relevance scores of the input features corresponding to the one or more topics are lower than a predefined threshold score.

12. The method of claim 1, further comprising: responsive to determining that there are no applications subscribed to a particular topic from the one or more topics, causing data collection for the particular topic to be paused.

13. A non-transitory machine-readable medium comprising computer program code which when executed by a network device functioning as a subscription manager of a service management and orchestration platform carries out the method steps of any of claims 1-12.

14. A network device (704) to function as a subscription manager of a service management and orchestration platform, the network device comprising: one or more processors (742); anda non-transitory machine-readable storage medium (748) that stores instructions, which when executed by the one or more processors, causes the subscription manager to perform the method steps of any one of claims 1-12.

Images