Verify the feasibility of automation goals

Abstract

An apparatus, method, and system for verifying feasibility of a goal for automation is disclosed. A method (700) includes receiving (702) a request to verify feasibility of a goal for automation at a network device from a consumer device in a telecommunications network. The method (700) includes decomposing (704) the goal into a set of configurable conditions, a set of sub-goals, or a combination thereof. The method (700) includes determining (706) whether the set of configurable conditions, the set of sub-goals, or a combination thereof can be set in the telecommunications network. The method (700) includes sending (708) a response to the consumer device based on whether the set of configurable conditions, the set of sub-goals, or a combination thereof can be set in the telecommunications network.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. patent application Ser. No. 63 / 161,363, entitled “APPARATUSES, METHODS, AND SYSTEMS FOR AUTOMATION GOAL FEASIBILITY CHECK,” filed on March 15, 2021, to Ishan Vaishnavi, which is incorporated by reference in its entirety.

[0002] The subject matter disclosed herein relates generally to wireless communications, and more particularly, to verifying feasibility of goals toward automation. [Background technology]

[0003] In some wireless communication networks, goals may be set in a closed loop system, in which various goals set by different consumers may conflict with each other. Summary of the Invention [Means for solving the problem]

[0004] A method is disclosed for verifying feasibility of a goal for automation. Apparatus and systems also perform the functions of the method. One embodiment of the method includes receiving, at a network device, a request from a consumer device to verify feasibility of a goal for automation in a telecommunications network. In some embodiments, the method includes decomposing the goal into a set of configurable conditions, a set of sub-goals, or a combination thereof. In some embodiments, the method includes determining whether the set of configurable conditions, the set of sub-goals, or a combination thereof can be set in the telecommunications network. In various embodiments, the method includes sending a response to the consumer device based on whether the set of configurable conditions, the set of sub-goals, or a combination thereof can be set in the telecommunications network.

[0005] An apparatus for verifying feasibility of a goal for automation includes a network device. In some embodiments, the apparatus includes a receiver that receives a request from a consumer device to verify feasibility of the goal for automation in a telecommunications network. In various embodiments, the apparatus includes a processor that decomposes the goal into a set of configurable conditions, a set of sub-goals, or a combination thereof, and determines whether the set of configurable conditions, the set of sub-goals, or a combination thereof can be set in the telecommunications network. In some embodiments, the apparatus includes a transmitter that transmits a response to the consumer device based on whether the set of configurable conditions, the set of sub-goals, or a combination thereof can be set in the telecommunications network.

[0006] Another embodiment of a method for verifying feasibility of a goal for automation includes sending a request from a consumer device to a network device to verify feasibility of the goal for automation in a telecommunications network. The goal can be decomposed into a set of configurable conditions, a set of sub-goals, or a combination thereof. In some embodiments, the method includes receiving a response from the network device based on whether the set of configurable conditions, the set of sub-goals, or a combination thereof can be set in the telecommunications network.

[0007] Another apparatus for verifying feasibility of a goal for automation includes a consumer device. In some embodiments, the apparatus includes a transmitter that transmits a request to a network device to verify feasibility of a goal for automation in a telecommunications network. The goal can be decomposed into a set of configurable conditions, a set of sub-goals, or a combination thereof. In various embodiments, the apparatus includes a receiver that receives a response from the network device based on whether the set of configurable conditions, the set of sub-goals, or a combination thereof can be set in the telecommunications network.

[0008] A more detailed description of the embodiments briefly described above will be made with reference to specific embodiments illustrated in the accompanying drawings, which depict only certain embodiments and should not be considered limiting in scope, the embodiments being described and explained with added specificity and detail through the use of the accompanying drawings. [Brief description of the drawings]

[0009] [Figure 1] FIG. 1 is a schematic block diagram illustrating an embodiment of a wireless communication system for verifying feasibility of automation goals. [Diagram 2] FIG. 1 is a schematic block diagram illustrating one embodiment of an apparatus that can be used to verify the feasibility of automation goals. [Diagram 3]FIG. 1 is a schematic block diagram illustrating one embodiment of an apparatus that can be used to verify the feasibility of automation goals. [Figure 4] FIG. 1 is a schematic block diagram illustrating one embodiment of a system for goal feasibility checking. [Diagram 5] FIG. 1 is a schematic block diagram illustrating an embodiment of a system for target feasibility verification in a network of the ETSI ZSM framework. [Figure 6] FIG. 1 is a schematic block diagram illustrating an embodiment of a system for goal feasibility verification in a 3GPP management system. [Figure 7] FIG. 1 is a flow chart diagram illustrating an embodiment of a method for verifying feasibility of automation goals. [Figure 8] FIG. 11 is a flow chart diagram illustrating another embodiment of a method for verifying feasibility of automation goals. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] As will be appreciated by those skilled in the art, aspects of the embodiments may be implemented as a system, apparatus, method, or program product. Thus, the embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, which may all be generally referred to herein as a "circuit," "module," or "system." Furthermore, the embodiments may take the form of a program product embodied in one or more computer-readable storage devices that store machine-readable code, computer-readable code, and / or program code, hereinafter referred to as code. The storage devices may be tangible, non-transitory, and / or non-transmitting. The storage devices may not embody signals. In some embodiments, the storage devices merely use signals to access the code.

[0011] Some of the functional units described herein may be termed modules to more particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit including custom very-large-scale integration (VLSI) circuits or gate arrays, non-custom semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented with programmable hardware devices, such as programmable gate arrays, programmable array logic, programmable logic devices, or the like.

[0012] Modules may also be implemented in code and / or software for execution by various types of processors. An identified module of code may include one or more physical or logical blocks of executable code that may be organized as, for example, an object, procedure, or function. However, the executable files of an identified module need not be physically located together and may include different instructions stored in different locations that, when logically combined together, comprise that module and achieve the purpose stated for the module.

[0013] In practice, a module of code may be a single instruction or many instructions, and may even be spread across several different code segments and across several memory devices among various programs. Similarly, operational data may be identified and illustrated herein in a module, and may be embodied in any suitable form and organized in any suitable type of data structure. The operational data may be collected as a single data set or may be distributed across different locations, including different computer-readable storage devices. If a module or some portions of a module are implemented in software, the software portions are stored in one or more computer-readable storage devices.

[0014] Any combination of one or more computer readable media may be utilized. The computer readable medium may be a computer readable storage medium. The computer readable storage medium may be a storage device that stores the code. The storage device may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.

[0015] More specific examples (non-exhaustive list) of storage devices would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium can be any tangible medium that can contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0016] The code for carrying out the operations for the embodiments can be any number of lines and can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Python, Ruby, Java, Smalltalk, C++, or the like, and traditional procedural programming languages ​​such as the "C" programming language, or the like, and / or machine languages ​​such as assembly language. The code can run entirely on the user's computer, partly on the user's computer, as a standalone software package, partly on the user's computer and partly on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be to an external computer (e.g., via the Internet using an Internet Service Provider).

[0017] Reference throughout this specification to "one embodiment," "an embodiment," or similar language means that a particular feature, structure, or characteristic described with respect to that embodiment is included in at least one embodiment. Thus, throughout this specification, appearances of the phrases "in one embodiment," "in an embodiment," and similar language do not necessarily all refer to the same embodiment, but can mean "one or more, but not all, embodiments," unless expressly specified otherwise. The terms "including," "comprising," "having," and variations thereof mean "including but not limited to," unless expressly specified otherwise. A list of enumerated items does not imply that any or all of the items are mutually exclusive, unless expressly specified otherwise. The terms "a," "an," and "the" also refer to "one or more," unless expressly specified otherwise.

[0018] Furthermore, the functions, structures, or characteristics described with respect to the embodiments may be combined in any suitable manner. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of the embodiments. However, one skilled in the art will recognize that the embodiments can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other examples, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the embodiments.

[0019] Aspects of the embodiments are described below with reference to schematic flow chart illustrations and / or schematic block diagrams of methods, apparatus, systems, and program products according to the embodiments. It will be understood that each block of the schematic flow chart illustrations and / or schematic block diagrams, and combinations of blocks in the schematic flow chart illustrations and / or schematic block diagrams, may be implemented by code. The code may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to create a machine, such that the instructions executed by the processor of the computer or other programmable data processing apparatus generate means for performing the function / action specified in the block(s) of the schematic flow chart illustrations and / or schematic block diagrams.

[0020] Code can also be stored in a storage device that can direct a computer, other programmable data processing apparatus, or other device to function in a particular manner such that the instructions stored in the storage device create an article of manufacture that includes instructions that implement the functions / actions specified in the block(s) of the schematic flow chart illustrations and / or schematic block diagrams.

[0021] The code may also be carried on a computer, other programmable data processing apparatus, or other device and cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to generate a computer-implemented process, such that the code executing on the computer or other programmable apparatus provides a process for performing the function / action specified in the flowchart and / or block diagram block(s).

[0022] The schematic flow chart diagrams and / or schematic block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, systems, methods, and program products according to various embodiments. In this regard, each block in the schematic flow chart diagrams and / or schematic block diagrams may represent a module, segment, or portion of code, which includes one or more executable instructions of code for implementing a specified logical function(s).

[0023] It should also be noted that in some alternative implementations, the functions shown in the blocks may be performed out of the order shown in the figures. For example, two blocks shown in succession may in fact be executed substantially simultaneously, depending on the functionality involved, or the blocks may sometimes be executed in the reverse order. Other steps and methods may be deemed equivalent in function, logic, or effect to one or more blocks of the illustrated figures, or portions thereof.

[0024] Various arrow and line types may be used in the flowcharts and / or block diagrams, with it being understood that they are not intended to limit the scope of the corresponding embodiments. Indeed, some arrows or other connectors may be used to indicate only the logical flow of the illustrated embodiments. For example, arrows may indicate waiting or monitoring periods of unspecified duration between recited steps of the illustrated embodiments. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a dedicated hardware-based system that performs the specified functions or actions, or by a combination of dedicated hardware and code.

[0025] The description of an element in each figure may refer to the element in the current proceeding figure. Like numbers in all figures refer to like elements, including alternative embodiments of like elements.

[0026] 1 illustrates an embodiment of a wireless communication system 100 that configures a digital twin for software testing. In one embodiment, the wireless communication system 100 includes a remote unit 102 and a network unit 104 (e.g., a base unit). Although a particular number of remote units 102 and network units 104 are illustrated in FIG. 1, one skilled in the art will recognize that any number of remote units 102 and network units 104 may be included in the wireless communication system 100.

[0027] In one embodiment, the remote units 102 may include computing devices such as desktop computers, laptop computers, personal digital assistants (PDAs), tablet computers, smartphones, smart televisions (e.g., televisions connected to the Internet), set-top boxes, gaming consoles, security systems (including security cameras), in-vehicle computers, network devices (e.g., routers, switches, modems), aerial vehicles, drones, or the like. In some embodiments, the remote units 102 include wearable devices such as smart watches, fitness bands, optical head mounted displays, or the like. Additionally, the remote units 102 may be referred to as subscriber units, mobile, mobile stations, users, terminals, mobile terminals, fixed terminals, subscriber stations, UEs, user terminals, devices, or by other terminology used in the art. The remote units 102 may communicate directly with one or more of the network units 104 via UL and / or DL ​​communication signals 106. In some embodiments, the remote units 102 may communicate directly with other remote units 102 via sidelink communications. The remote unit 102 may include one or more software applications 110 .

[0028] The network units 104 may be distributed across a geographic region. In some embodiments, the network unit 104 may also include an access point, an access terminal, a base, a base station, a location server, a core network (CN), a radio network entity, a Node B, an evolved Node B (eNB), a 5G node B (gNB), a home Node B, a relay node, a device, a core network, an aerial server, a radio access node, an access point (AP), a new radio (NR), a network entity, an access and mobility management function (AMF), a unified data management (UDM), a unified data repository (UDR), a UDM / UDR, a policy control function (PCF), a radio access network (RAN), a network slice selection function (NSSF), a session management function (SMF), a user plane function (UPF), an application function, an authentication server function (ASF), an authentication information processing function (ASC ... The service provider may be referred to as and / or include one or more of: a trusted non-3GPP gateway function (TNGF), a network function, a digital twin creation service producer, a test management service producer, or by any other terminology used in the art.The network unit 104 is generally part of a radio access network that includes one or more controllers that are communicatively coupled to one or more corresponding network units 104. The radio access network is generally communicatively coupled to one or more core networks, which may be coupled to other networks such as the Internet and the Public Switched Telephone Network, among other networks. These and other elements of the radio access and core networks are not shown, but are generally well known by those skilled in the art.

[0029] In one implementation, the wireless communication system 100 complies with the NR protocol, 5G Core, 5G management, and 5G applications standardized in the third generation partnership project (3GPP), in which the network unit 104 transmits on the downlink (DL) using an OFDM modulation scheme and the remote unit 102 transmits on the uplink (UL) using a single-carrier frequency division multiple access (SC-FDMA) scheme or an orthogonal frequency division multiplexing (OFDM) scheme. More generally, however, the wireless communication system 100 may implement a number of other open or proprietary communication protocols, such as, for example, WiMAX, Institute of Electrical and Electronics Engineers (IEEE) 802.11 variants, global system for mobile communications (GSM), general packet radio service (GPRS), universal mobile telecommunications system (UMTS), long term evolution (LTE) variants, code division multiple access 2000 (CDMA2000), Bluetooth, ZigBee, Sigfoxx, etc., among other communication protocols. This disclosure is not intended to be limited to any particular wireless communication system architecture or protocol implementation.

[0030] The network unit 104 may serve several remote units 102 included in a serving area, such as a cell or a cell sector, via wireless communication links. The network unit 104 transmits DL communication signals to serve the remote units 102 in the time, frequency, and / or spatial domains.

[0031] The network unit 104 may be part of a radio access network 108. The radio access network 108 may further communicate with a mobile core network 112. The mobile core network 112 may further include one or more network functions, such as a UPF 114, an AMF 116, an SMB 118, a PCT 120, a UDM 122, a network repository function (NRF) 124, an NSSF 126, a network data analytics function (NWDAF) 128, etc. The mobile core network 112 and / or the radio access network 108 are managed by an operations and management system (OAM) 130.

[0032] In various embodiments, the remote unit 102 can send a request to the network from a consumer device to verify feasibility of a goal toward automation in a telecommunications network. The goal can be decomposed into a set of configurable conditions, a set of sub-goals, or a combination thereof. In some embodiments, the remote unit 102 can receive a response from the network device based on whether the set of configurable conditions, the set of sub-goals, or a combination thereof can be set in the telecommunications network. Thus, the remote unit 102 can be used to verify feasibility of a goal toward automation.

[0033] In some embodiments, the network unit 104 can receive a request from a consumer device to check the feasibility of a goal towards automation in a telecommunication network at the network device. In some embodiments, the network unit 104 can decompose the goal into a set of configurable conditions, a set of sub-goals, or a combination thereof. In some embodiments, the network unit 104 can determine whether the set of configurable conditions, the set of sub-goals, or a combination thereof can be set in a telecommunication network. In various embodiments, the network unit 104 can send a response to the consumer device based on whether the set of configurable conditions, the set of sub-goals, or a combination thereof can be set in a telecommunication network. Thus, the network unit 104 can be used to check the feasibility of a goal towards automation.

[0034] 2 illustrates an embodiment of an apparatus 200 that may be used to verify the feasibility of an automation goal. The apparatus 200 includes an embodiment of the remote unit 102. Additionally, the remote unit 102 may include a processor 202, a memory 204, an input device 206, a display 208, a transmitter 210, and a receiver 212. In some embodiments, the input device 206 and the display 208 may be combined into a single device, such as a touch screen. In some embodiments, the remote unit 102 may not include any input device 206 and / or display 208. In various embodiments, the remote unit 102 may include one or more of the processor 202, the memory 204, the transmitter 210, and the receiver 212, and may not include the input device 206 and / or the display 208.

[0035] The processor 202, in one embodiment, may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, the processor 202 may be a microcontroller, a microprocessor, a central processing unit (CPU), a graphics processing unit (GPU), an auxiliary processing unit, a field programmable gate array (FPGA), or a similar programmable controller. In some embodiments, the processor 202 executes instructions stored in the memory 204 to perform the methods and routines described herein. The processor 202 is communicatively coupled to the memory 204, the input device 206, the display 208, the transmitter 210, and the receiver 212.

[0036] Memory 204, in one embodiment, is a computer-readable storage medium. In some embodiments, memory 204 includes a volatile computer storage medium. For example, memory 204 can include RAM, including dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), and / or static RAM (SRAM). In some embodiments, memory 204 includes a non-volatile computer storage medium. For example, memory 204 can include a hard disk drive, flash memory, or any other suitable non-volatile computer storage device. In some embodiments, memory 204 includes both volatile and non-volatile computer storage devices. In some embodiments, memory 204 also stores program code and associated data, such as an operating system or other controller algorithms running on remote unit 102.

[0037] The input device 206, in one embodiment, may include any known computer input device, including a touch panel, buttons, a keyboard, a stylus, a microphone, or the like. In some embodiments, the input device 206 may be integrated with the display 208, such as a touch screen or similar touch-sensitive display. In some embodiments, the input device 206 includes a touch screen, such that text may be entered using a virtual keyboard displayed on the touch screen and / or by handwriting on the touch screen. In some embodiments, the input device 206 includes two or more different devices, such as a keyboard and a touch panel.

[0038] The display 208, in one embodiment, can include any known electronically controllable display or display device. The display 208 can be designed to output visual, audible, and / or tactile signals. In some embodiments, the display 208 includes an electronic display capable of outputting visual data to a user. For example, the display 208 can include, but is not limited to, a liquid crystal display (LCD), a light emitting diode (LED) display, an organic light emitting diode (OLED) display, a projector, or a similar display device capable of outputting images, text, or the like to a user. As another non-limiting example, the display 208 can include a wearable display, such as a smart watch, smart glasses, a head-up display, or the like. Additionally, the display 208 can be a component of a smartphone, a personal digital assistant, a television, a table computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, or the like.

[0039] In some embodiments, the display 208 includes one or more speakers for generating sound. For example, the display 208 can generate an audible alert or notification (e.g., a buzzer or chime, etc.). In some embodiments, the display 208 includes one or more haptic devices for generating vibration, movement, or other haptic feedback. In some embodiments, all or a portion of the display 208 can be integrated with the input device 206. For example, the input device 206 and the display 208 can form a touch screen or similar touch-sensitive display. In other embodiments, the display 208 can be located near the input device 206.

[0040] In some embodiments, the sender 210 sends a request to a network device to verify feasibility of a goal for automation in a telecommunications network. The goal can be decomposed into a set of configurable conditions, a set of sub-goals, or a combination thereof. In various embodiments, the receiver 212 receives a response from the network device based on whether the set of configurable conditions, the set of sub-goals, or a combination thereof can be set in the telecommunications network.

[0041] Although only one transmitter 210 and one receiver 212 are shown, the remote unit 102 may have any suitable number of transmitters 210 and receivers 212. The transmitter 210 and receiver 212 may be any suitable type of transmitter and receiver. In one embodiment, the transmitter 210 and receiver 212 may be part of a transceiver.

[0042] 3 shows an embodiment of an apparatus 300 that may be used to check the feasibility of an automation goal. The apparatus 300 includes an embodiment of the network unit 104. The network unit 104 may further include a processor 302, a memory 304, an input device 306, a display 308, a transmitter 310, and a receiver 312. As will be appreciated, the processor 302, the memory 304, the input device 306, the display 308, the transmitter 310, and the receiver 312 may be substantially similar to the processor 202, the memory 204, the input device 206, the display 208, the transmitter 210, and the receiver 212 of the remote unit 102, respectively.

[0043] In some embodiments, the receiver 312 receives a request from a consumer device to verify feasibility of a goal for automation in a telecommunications network. In various embodiments, the processor 302 decomposes the goal into a set of configurable conditions, a set of sub-goals, or a combination thereof, and determines whether the set of configurable conditions, the set of sub-goals, or a combination thereof can be set in the telecommunications network. In some embodiments, the transmitter 310 transmits a response to the consumer device based on whether the set of configurable conditions, the set of sub-goals, or a combination thereof can be set in the telecommunications network.

[0044] It should be noted that one or more embodiments described herein may be combined into a single embodiment.

[0045] In some embodiments, a closed loop can be configured with the automation goals it attempts to satisfy. In such embodiments, the configuring is performed by any suitable consumer authorized to configure such goals. In some embodiments, there can be loops specified by different consumers (e.g., different vertical industries), different tenants, different network slice owners, etc. In addition to different consumers, goals can be specified at different levels of the managed entity stack or policy continuum and need to be translated to different levels in the managed entity stack or policy continuum. In such embodiments, such translations or different consumers can cause the system to configure conflicting goals, and such conflicts can cause the translated goals or conditions (e.g., goals or conditions derived from the original goals) to be set in some domains and fail in other domains, resulting in a non-uniform state of the goal setting procedure.

[0046] In various embodiments, the fifth generation (5G) uses network slicing that is intended to allow operators to support different services for different vertical consumers (e.g., automotive (e.g., vehicle to everything (V2X)), internet of things (IoT), enhanced mobile broadband (eMBB), industry 4.0 (e.g., ultra-reliable low-latency communication (URLLC))). Network slices can be hosted on virtualized infrastructure across administrative domains. In some embodiments, network automation can focus on closed loops as the key to success in achieving automation. Each assurance control loop can include one or more assurance goals (or closed loop goals), and many closed loops (CLs) can act on a network slice, or a network slice subnet.

[0047] In some embodiments, the assurance goals corresponding to a CL include an assurance goal list (e.g., assurance goal or control loop goal (CLG)) that can be set by any authorized CL consumer and can be a list of name-value pairs indicating key performance indicators (KPIs) that the closed loop should attempt to achieve. These goals can be any optimization related to criteria (e.g., maximum and / or minimum), non-uniformity (e.g., less than or greater than), or uniformity constraints (e.g., name=value, etc., as currently specified) and can be expressed as part of the intent. Different entities can set different goals at different levels. These goals can be delegated, expanded, or passed on to other different closed loops. Different consumers (e.g., handling different network slice instances or different network slice subnet instances) can set different goals for the condition listening service (CLS) handling those network slice instances. However, these can then be delegated to other closed loops in different administrative domains (e.g., administrative domains).

[0048] In some embodiments, there may be different goals set by different consumers of different slices across a common shared infrastructure, such that the different goals may conflict with each other.

[0049] In various embodiments, before setting a goal, a feasibility analysis of the configurability of the goal in the network should be performed.

[0050] 4 is a schematic block diagram illustrating an embodiment of a system 400 for goal feasibility check. The system 400 includes a consumer 402, a first goal feasibility check service producer (GFCSP) 404, a goal translation service producer (GTSP) 406, condition detection service producers (CDSPs) 408, a condition listener service producer (CLSP) 410, and a second GFCSP 412. Each of the communications in the system 400 may include one or more messages.

[0051] The first GFCSP 404 and / or the second GFCSP 412 can 1) receive a request to check whether the target is configurable in the network, 2) if the target is configurable in the network, it can optionally reserve the target for a given time (e.g. reserving a target means that the target is compared with newer targets), and 3) if the target is not configurable in the network, it can provide the reason why the target is not configurable. For example, the reason why the target cannot be set can include: 1) there is a conflicting goal that was set, 2) the request to the listener of the condition in the network is incorrect or the listener cannot be reached, 3) the converted goal is not feasible in the network, and / or 4) the goal or condition cannot be reached. It should be noted that feasibility can include checking for conflicts. Another function identical to feasibility checking can also be used only to check for conflicts.

[0052] In the first communication 414, there may be a mapping of goals to conditions and translated goals configured in the system 400.

[0053] In the second communication 416, the consumer 402 requests to confirm the feasibility of setting a guarantee target in the first GFCSP 404. Confirming a guarantee target indicates that the consumer 402 is only requesting to know that a particular target can be set in the network. The confirmation request may include a request to reserve the target, if possible.

[0054] In a third communication 418, the first GFCSP 404 sends the assurance goal list to the goal conversion service producer 406. The third communication 418 may include a request to convert or decompose the goal into sub-goals. The GTSP 406, in one implementation, references a conversion table to find the associated sub-goals and the entity that may be used to set these goals (e.g., a condition detection service or another CL management service producer). The conversion of goals by the GTSP 406 can be based on 1) a vendor-specific implementation of the goal, 2) a technology-specific understanding of the goal, or 3) an operator-configured conversion in a database or an operator-specific implementation.

[0055] In a fourth communication 420, the GTSP 406 provides a list of internally configurable conditions or configurable goals and entities (e.g., CDSPs or another GFCSP) that can check for feasibility based on its understanding of the assurance goals (e.g., service level agreements (SLA), service level specifications (SLS)) The GTSP 406 can translate goals across management domain capabilities that set the goals, including translating goals across multi-technology or multi-vendor platforms.

[0056] Although the loop 422 may be performed for each goal and / or sub-goal from the third communication 418 and / or the fourth communication 420, there may be many entities for which the confirmation is negative.

[0057] The first GFCSP 404 evaluates 424 the address and / or type of entity to which the target is being targeted, as well as the exact address of the entity.

[0058] In the if condition in sub-step 426, 1) in the fifth communication 428, if the condition is set, a request is sent to the CDSP of CDSP 408 to confirm whether the condition can be set; if a reservation is requested, the condition is reserved for the provided time (but not set); 2) in the sixth communication 430, a positive response to the condition setting confirmation is sent; 3) in the seventh communication 432 (e.g., optional communication), in some cases it may be necessary to confirm whether the condition listening service producer 410 can receive notifications issued by the CDSP, for example whether the first GFCSP 404 can reach the subscription address for the CDSP's notifications; and 4) in the eighth communication 434 (e.g., optional communication), a positive response to the listener setting confirmation is sent.

[0059] In the if condition in sub-step 426, if not, 1) in a ninth communication 436, if the converted or decomposed target needs to be set in the second GFCSP 412, a target feasibility confirmation request is sent to the second GFCSP 412; in some embodiments, the second GFCSP 412 is a logical entity and the first GFCSP 404 can send a request to itself; 2) the second GFCSP 412 recursively repeats 438 the feasibility confirmation procedure; and 3) in a tenth communication 440, a positive or negative response is sent after the target feasibility is confirmed.

[0060] In an optional eleventh communication 442, the final set response is sent to the consumer 402 (e.g., a goal acknowledgement). Note that the reserved condition is a condition that ensures that no further conditions can be set in the CDSP that conflict with the reserved condition. However, detection of this condition is not activated in the network, and therefore no notification is issued regarding the met condition. Reserved goals are treated similarly.

[0061] 5 is a schematic block diagram illustrating an embodiment of a system 500 for target feasibility verification in a European telecommunications standards institute (ETSI) zero-touch network and service management (ZSM) framework network. The system 500 includes a consumer 502, a first management system 504 (e.g., an end-to-end (E2E) management device (MD) management system acting as a GFCSP), a GTSP 506, a CDSP 508, an orchestration service 510 (e.g., acting as a CLSP), and a second management system 512 (e.g., acting as a second GFCSP). Each communication in the system 500 may include one or more messages.

[0062] The E2E level management system (e.g., E2E MDM (E2EMDM)) as well as the mobile device (MD) level management system (e.g., mobile device management (MDM)) provide the implementation of the goal feasibility check service (GFCS) and therefore perform the role of a GFCSP. The condition detection service producer provides the condition settings described in the condition detection service on the ETSI ZSM and performs the role of a CDSP. Furthermore, the orchestration service producer (OSP) performs the role of a CLSP.

[0063] In the first communication 514, there may be a mapping of goals to conditions and translated goals configured in the system 500.

[0064] In a second communication 516, the consumer 502 requests to confirm the feasibility of setting an automation goal in the first management system 504. Confirming a goal indicates that the consumer 502 is only requesting to know that a particular goal can be set in the network. The confirmation request may include a request to reserve the goal for a certain amount of time.

[0065] In a third communication 518, the first management system 504 seeks to convert or decompose the goal into sub-goals.

[0066] In a fourth communication 520, the GTSP 506 provides a list of internally configurable conditions or configurable goals based on its understanding of the assurance goals (e.g., service level agreements ("SLA"), service level specifications ("SLS")) and the entities that can be verified (e.g., a CDSP or another management system). The GTSP 506 can translate goals across management domain capabilities that set the goals, including translating goals across multi-technology or multi-vendor platforms.

[0067] Although the loop 522 may be performed for each goal and / or sub-goal from the third communication 518 and the fourth communication 520, there may be many entities for which the confirmation is negative.

[0068] The first management system 504 evaluates 524 the address and / or type of entity to be targeted, and the exact address of the entity.

[0069] In the if condition in sub-step 526, 1) in a fifth communication 528, if the condition is set, a request is sent to the CDSP of CDSP 508 to confirm whether the condition can be set; if a reservation is requested, the condition is reserved (but not set) for the time provided; 2) in a sixth communication 530, a positive response to the condition setting confirmation is sent; 3) in a seventh communication 532 (e.g., optional communication), in some cases it may be necessary to confirm whether the condition listening service producer can receive notifications issued by the CDSP, for example, if it can subscribe to notifications from the CLSP corresponding to the set condition, to check whether the subscription address for the CDSP's notifications can be reached by the first management system 504 using the orchestration service 510 (e.g., OSP); and 4) in an eighth communication 534 (e.g., optional communication), a positive response to the listener setting confirmation is sent.

[0070] In the if condition in sub-step 526, if not, 1) in a ninth communication 536, if the converted or decomposed goal needs to be set in the second management system 512, a goal feasibility confirmation request is sent to the second management system 512, 2) the second management system 512 recursively repeats 538 the feasibility confirmation procedure, and 3) in a tenth communication 540, a positive or negative response is sent after the feasibility of the goal is confirmed.

[0071] In an optional eleventh communication 542, a final positive or negative configuration response is sent to the consumer 502 (eg, a target acknowledgement).

[0072] 6 is a schematic block diagram illustrating an embodiment of a system 600 for target feasibility verification in a 3GPP management system. The system 600 includes a consumer 602, a network slice (NS) management service producer (NSMSP) 604 (e.g., acting as a GFCSP), a GTSP 606, a performance assurance services producer (PASP) 608 (e.g., acting as a CDSP), a management data analytics service producer (MDASP) and / or management data analytics function (MDAF) ("MDASP / MDAF") 610 (e.g., acting as a CLSP), and a network switching subsystem (NSS) management service producer (NSSMSP) 612 (e.g., acting as a second GFCSP). Each of the communications in the system 600 may include one or more messages.

[0073] In FIG. 6, as part of a 3GPP-compliant management system, a management service producer ("NSMSP") at the network slice level handles the feasibility check of the guarantee goals (e.g., the NMSP therefore acts as a GFCSP). The management service producer can be a provisioning service producer that handles configuring the network slice based on a service profile including SLA, SLS, or goal specifications. The performance guarantee service producer acts as a CDSP that can set conditions related to CL goals. The MDAS therefore acts as a CLSP and as a handler for triggered conditions. Furthermore, a network slice subnet management service producer (NSSMSP) acts as a second GFCSP, e.g., for the radio access network ("RAN") part of the network slice instance.

[0074] In the first communication 614, there may be a mapping of goals to conditions and translated goals configured in the system 600.

[0075] In a second communication 616, the consumer 602 requests to confirm the feasibility of configuring the guarantee and / or automation goal in the NSMSP 604. Confirming the guarantee goal indicates that the consumer 602 is only requesting to know that a particular goal can be set in the network. The confirmation request may include a request to reserve the goal for a certain amount of time.

[0076] A third communication 618 requests that the NSMSP 604 convert or decompose the goal into sub-goals.

[0077] In a fourth communication 620, the GTSP 606 provides a list of internally configurable conditions or configurable goals based on its understanding of the assurance goals (e.g., service level agreements ("SLA"), service level specifications ("SLS")) and entities that may be verified (e.g., a CDSP or another management system). The GTSP 606 can translate goals across management domain capabilities that set the goals, including translating goals across multi-technology or multi-vendor platforms.

[0078] The loop 622 may be performed for each goal and / or sub-goal from the third communication 618 and / or the fourth communication 620, although there may be many entities for which the confirmation is negative.

[0079] The first management system 604 evaluates 624 the address and / or type of entity to be targeted, as well as the exact address of the entity.

[0080] In the if condition in sub-step 626, 1) in a fifth communication 628, if the condition is set, a request is sent to the CDSP of the performance guaranteed service producer 608 to check whether the condition can be set, i.e., in 3GPP, an example of a condition could be a Key Performance Indicator ("KPI") threshold exceedance condition; if a reservation is requested, the condition is reserved (but not set) for a given time; 2) in a sixth communication 630, a positive response to the condition setting confirmation is sent; 3) in a seventh communication 632 (e.g., optional communication), in some cases it may be necessary to check whether the condition listening service producer can receive notifications issued by the CDSP, e.g., whether the MDASP / MDAF 610 is reachable at the subscription address for the PASP 608 notification; and 4) in an eighth communication 634 (e.g., optional communication), a positive response to the listener setting confirmation is sent.

[0081] If not, in the If condition in sub-step 626, 1) in a ninth communication 636, if a converted or decomposed goal needs to be set in the NSSMSP 612, a goal feasibility confirmation request is sent to the NSSMSP 612, 2) the NSSMSP 612 recursively repeats 638 the feasibility confirmation procedure, and 3) in a tenth communication 640, a positive or negative response is sent after the goal feasibility is confirmed.

[0082] 7 is a flow chart diagram illustrating one embodiment of a method 700 for verifying feasibility of goals towards automation. In some embodiments, the method 700 is performed by an apparatus such as the network unit 104. In some embodiments, the method 700 may be performed by a processor executing program code, such as, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, an FPGA, or the like.

[0083] In various embodiments, method 700 includes receiving 702, at a network device, a request from a consumer device to verify feasibility of a goal for automation in a telecommunications network. In some embodiments, method 700 includes decomposing 704 the goal into a set of configurable conditions, a set of sub-goals, or a combination thereof. In some embodiments, method 700 includes determining 706 whether the set of configurable conditions, the set of sub-goals, or a combination thereof can be set in the telecommunications network. In various embodiments, method 700 includes sending 708 a response to the consumer device based on whether the set of configurable conditions, the set of sub-goals, or a combination thereof can be set in the telecommunications network.

[0084] In some embodiments, the goal comprises a list of name-value pairs indicating a key performance indicator (KPI) goal, a guarantee goal, a control loop goal, a maximum criterion, a minimum criterion, a non-uniformity, a uniformity constraint, a portion of an intent, or some combination thereof. In some embodiments, the method 700 further comprises determining a set of actions to be taken in response to the goal not being met. In various embodiments, the method 700 further comprises determining whether there are conflicting goals corresponding to the goal, non-configurable goals corresponding to the goal, conflicting conditions corresponding to the goal, non-configurable conditions corresponding to the goal, non-configurable entities corresponding to the goal, or some combination thereof.

[0085] In one embodiment, the request includes a limited reservation time corresponding to the goal. In some embodiments, the reservation for the goal is removed upon expiration of the limited reservation time. In some embodiments, the network device comprises a goal feasibility confirmation service producer, a management system, a management service producer, or some combination thereof.

[0086] 8 is a flow chart diagram illustrating another embodiment of a method 800 for verifying feasibility of goals toward automation. In some embodiments, the method 800 is performed by an apparatus such as the remote unit 102. In some embodiments, the method 800 may be performed by a processor executing program code, such as, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, an FPGA, or the like.

[0087] In various embodiments, the method 800 includes sending 802 a request from a consumer device to a network device to verify feasibility of a goal for automation in a telecommunications network. The goal can be decomposed into a set of configurable conditions, a set of sub-goals, or a combination thereof. In some embodiments, the method 800 includes receiving 804 a response from the network device based on whether the set of configurable conditions, the set of sub-goals, or a combination thereof can be set in the telecommunications network.

[0088] In some embodiments, the goal includes a list of name-value pairs indicating a key performance indicator (KPI) goal, a guarantee goal, a control loop goal, a maximum criterion, a minimum criterion, a non-uniformity, a uniformity constraint, a portion of the intent, or some combination thereof. In some embodiments, the request includes a limited reservation time that corresponds to the goal.

[0089] In various embodiments, the reservation for the goal is removed upon expiration of a limited reservation time. In one embodiment, the network device comprises a goal feasibility checking service producer, a management system, a management service producer, or some combination thereof.

[0090] In one embodiment, the apparatus comprises a network device in a telecommunications network, the apparatus further comprising: a receiver for receiving a request from a consumer device in the telecommunications network to verify feasibility of a goal for automation, a processor for decomposing the goal into a set of configurable conditions, a set of sub-goals, or a combination thereof, and determining whether the set of configurable conditions, the set of sub-goals, or a combination thereof can be set in the telecommunications network, and a transmitter for transmitting a response to the consumer device based on whether the set of configurable conditions, the set of sub-goals, or a combination thereof can be set in the telecommunications network.

[0091] In some embodiments, the goal comprises a list of name-value pairs that indicate a key performance indicator (KPI) goal, a guarantee goal, a control loop goal, a maximum standard, a minimum standard, a non-uniformity, a uniformity constraint, a portion of an intent, or some combination thereof.

[0092] In some embodiments, the processor determines a set of actions to be performed in response to the goal not being performed.

[0093] In various embodiments, the processor determines whether there are competing goals corresponding to the goal, non-configurable goals corresponding to the goal, competing conditions corresponding to the goal, non-configurable conditions corresponding to the goal, non-configurable entities corresponding to the goal, or some combination thereof.

[0094] In one embodiment, the request includes a limited reservation time that corresponds to the goal.

[0095] In some embodiments, reservations for targets are removed upon expiration of a limited reservation time.

[0096] In some embodiments, the network device comprises a goal feasibility checking service producer, a management system, a management service producer, or some combination thereof.

[0097] In one embodiment, a method of a network device in a telecommunications network includes receiving a request from a consumer device to confirm feasibility of a goal for automation in the telecommunications network, decomposing the goal into a set of configurable conditions, a set of sub-goals, or a combination thereof, determining whether the set of configurable conditions, the set of sub-goals, or a combination thereof can be set in the telecommunications network, and sending a response to the consumer device based on whether the set of configurable conditions, the set of sub-goals, or a combination thereof can be set in the telecommunications network.

[0098] In some embodiments, the goal comprises a list of name-value pairs that indicate a key performance indicator (KPI) goal, a guarantee goal, a control loop goal, a maximum standard, a minimum standard, a non-uniformity, a uniformity constraint, a portion of an intent, or some combination thereof.

[0099] In some embodiments, the method further includes determining a set of actions to be performed in response to the goal not being met.

[0100] In various embodiments, the method further includes determining whether there are competing goals corresponding to the goal, non-configurable goals corresponding to the goal, competing conditions corresponding to the goal, non-configurable conditions corresponding to the goal, non-configurable entities corresponding to the goal, or some combination thereof.

[0101] In one embodiment, the request includes a limited reservation time that corresponds to the goal.

[0102] In some embodiments, reservations for targets are removed upon expiration of a limited reservation time.

[0103] In some embodiments, the network device comprises a goal feasibility checking service producer, a management system, a management service producer, or some combination thereof.

[0104] In one embodiment, an apparatus comprises a consumer device in a telecommunications network, the apparatus further comprising a transmitter in the telecommunications network for sending a request to a network device to verify feasibility of a goal for automation, the goal being decomposable into a set of configurable conditions, a set of sub-goals, or a combination thereof, and a receiver for receiving a response from the network device based on whether the set of configurable conditions, the set of sub-goals, or a combination thereof can be set in the telecommunications network.

[0105] In some embodiments, the goal comprises a list of name-value pairs that indicate a key performance indicator (KPI) goal, a guarantee goal, a control loop goal, a maximum standard, a minimum standard, a non-uniformity, a uniformity constraint, a portion of an intent, or some combination thereof.

[0106] In some embodiments, the request includes a limited reservation time that corresponds to the goal.

[0107] In various embodiments, reservations for targets are removed upon expiration of a limited reservation time.

[0108] In one embodiment, the network device comprises a goal feasibility checking service producer, a management system, a management service producer, or some combination thereof.

[0109] In one embodiment, a method for a consumer device in a telecommunications network includes sending a request to a network device to verify feasibility of a goal toward automation in the telecommunications network, where the goal is decomposable into a set of configurable conditions, a set of sub-goals, or a combination thereof, and receiving a response from the network device based on whether the set of configurable conditions, the set of sub-goals, or a combination thereof can be set in the telecommunications network.

[0110] In some embodiments, the goal comprises a list of name-value pairs that indicate a key performance indicator (KPI) goal, a guarantee goal, a control loop goal, a maximum standard, a minimum standard, a non-uniformity, a uniformity constraint, a portion of an intent, or some combination thereof.

[0111] In some embodiments, the request includes a limited reservation time that corresponds to the goal.

[0112] In various embodiments, reservations for targets are removed upon expiration of a limited reservation time.

[0113] In one embodiment, the network device comprises a goal feasibility checking service producer, a management system, a management service producer, or some combination thereof.

[0114] The embodiments may be embodied in other specific forms. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is therefore indicated by the appended claims, rather than by the foregoing description. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope. [Explanation of symbols]

[0115] 100 Wireless communication system 102 Remote Unit 104 Network Unit 106 UL / DL communication signal 108 Wireless Access Network 110 Software Applications 112 Mobile Core Network 114 UPF 116 AMF 118 SMB 120 PCT 122 UDM 124 Network Repository Facility (NRF) 126 NSSF 128 Network Data Analysis Facility (NWDAF) 130 Operations and Management Systems (OAM) 200 equipment 202 Processor 204 Memory 206 Input Devices 208 Display 210 Transmitter 212 Receiver 300 equipment 302 Processor 304 Memory 306 Input Devices 308 Display 310 Transmitter 312 Receiver 400 Systems 402 Consumer 404 First Goal Feasibility Check Service Producer (GFCSP) 406 Goal Transformation Service Producer (GTSP) 408 Condition Detection Service Producer (CDSP) 410 Conditional Listener Service Producer (CLSP) 412 Second GFCSP 414 First Communication 416 Second Communication 418 Third Communication 420 Fourth Communication 422 Loop 424 Rating 426 Sub-steps 428 Fifth Communication 430 Sixth Communication 432 Seventh Communication 434 Eighth Communication 436 Ninth Communication 438 Recursively 440 Tenth Communication 442 Eleventh Communication 500 Systems 502 Consumer 504 First Management System 506 GTSP 508 CDSP 510 Orchestration Services 512 Second Management System 514 First Communication 516 Second Communication 518 Third Communication 520 Fourth Communication 522 Loop 524 Reviews 526 Sub-steps 528 Fifth Communication 530 Sixth Communication 532 Seventh Communication 534 Eighth Communication 536 Ninth Communication 538 Recursively 540 10th Communication 542 11th Communication 600 System 602 Consumer 604 Network Slice (NS) Management Service Producer (NSMSP) 606 GTSP 608 Performance Assured Service Producer (PASP) 610 Managed Data Analysis Service Producer (MDASP) and / or Managed Data Analysis Facility (MDAF) (MDASP / MDAF) 612 Network Switching Subsystem (NSS) Management Service Producer (NSSMSP) 614 First Communication 616 Second Communication 618 Third Communication 620 Fourth Communication 622 Loop 624 Reviews 626 Sub-steps 628 Fifth Communication 630 Sixth Communication 632 Seventh Communication 634 Eighth Communication 636 Ninth Communication 638 Recursively 640 10th Communication 700 methods 800 ways

Claims

1. 1. An apparatus for performing network functions in a telecommunications network, comprising: At least one memory; and at least one processor coupled to the at least one memory, the at least one processor providing to the apparatus: receiving, in the telecommunications network, a request from a consumer device to verify feasibility of an automation goal; Decomposing the goal into a set of configurable conditions, a set of sub-goals, or a combination thereof; determining whether the set of configurable conditions, the set of sub-goals, or the combination thereof can be configured in the telecommunications network; sending a response to the consumer device based on whether the set of configurable conditions, the set of sub-goals, or the combination thereof can be set in the telecommunications network; is configured to execute Device.

2. The goal is to A list of name-value pairs representing key performance indicator (KPI) goals; Guarantee goals, Control Loop Objectives, maximum standard, Minimum standards, Inhomogeneity, uniformity constraints, Part of the intent, or Combinations of these Includes 2. The apparatus of claim 1.

3. The at least one processor is configured to cause the device to determine a set of actions to be performed in response to the goal not being met.

2. The apparatus of claim 1.

4. The at least one processor may further include, for the device: a competing goal corresponding to said goal; a non-settable goal corresponding to said goal; competing conditions corresponding to said objectives; non-configurable conditions corresponding to said goals; a non-configurable entity that corresponds to said goal; or Combinations of these is configured to perform a step of determining whether 2. The apparatus of claim 1.

5. The request includes a limited reservation time corresponding to the goal.

2. The apparatus of claim 1.

6. Reservations for the target are removed upon expiration of the limited reservation time.

6. The apparatus of claim 5.

7. A target feasibility confirmation service producer, a management system, a management service producer, or a combination thereof.

2. The apparatus of claim 1.

8. 1. A method of performing a network function in a telecommunications network, comprising: receiving, in said telecommunications network, a request from a consumer device to verify feasibility of an automation goal; decomposing the goal into a set of configurable conditions, a set of sub-goals, or a combination thereof; determining whether the set of configurable conditions, the set of sub-goals, or the combination thereof can be configured in the telecommunications network; sending a response to the consumer device based on whether the set of configurable conditions, the set of sub-goals, or the combination thereof can be set in the telecommunications network; The method includes:

9. The goal is to A list of name-value pairs representing key performance indicator (KPI) goals; Guarantee goals, Control Loop Objectives, maximum standard, Minimum standards, Inhomogeneity, uniformity constraints, Part of the intent, or Combinations of these Includes The method of claim 8.

10. determining a set of actions to be taken in response to the goal not being met. The method of claim 8.

11. A user equipment (UE) in a telecommunications network, comprising: At least one memory; and at least one processor coupled to the at least one memory, the at least one processor configured to: transmitting, in the telecommunications network, to a network device a request to verify feasibility of an automation goal, the goal being decomposable into a set of configurable conditions, a set of sub-goals, or a combination thereof; receiving a response from the network device based on whether the set of configurable conditions, the set of sub-goals, or the combination thereof can be configured in the telecommunications network; is configured to execute U.E.

12. The goal is to A list of name-value pairs representing key performance indicator (KPI) goals; Guarantee goals, Control Loop Objectives, maximum standard, Minimum standards, Inhomogeneity, uniformity constraints, Part of the intent, or Combinations of these Includes The UE of claim 11.

13. The request includes a limited reservation time corresponding to the goal. The UE of claim 11.

14. Reservations for the target are removed upon expiration of the limited reservation time. The UE of claim 13.

15. The network device comprises a goal feasibility checking service producer, a management system, a management service producer, or a combination thereof. The UE of claim 11.

16. A processor for wireless communication in a telecommunications network, comprising: at least one controller coupled to the at least one memory, the at least one controller configured to: transmitting, in the telecommunications network, to a network device a request to verify feasibility of an automation goal, the goal being decomposable into a set of configurable conditions, a set of sub-goals, or a combination thereof; receiving a response from the network device based on whether the set of configurable conditions, the set of sub-goals, or the combination thereof can be configured in the telecommunications network; is configured to execute Processor.

17. The goal is: A list of name-value pairs representing key performance indicator (KPI) goals, Guarantee goals, Control Loop Objectives, maximum standard, Minimum standards, Inhomogeneity, uniformity constraints, Part of the intention, or Combinations of these Includes 17. The processor of claim 16.

18. The method of claim 17, wherein the request includes a limited reservation time corresponding to the goal.

17. The processor of claim 16.

19. The reservation for the target is removed upon expiration of the limited reservation time.

20. The processor of claim 18.

20. The network device comprising a goal feasibility confirmation service producer, a management system, a management service producer, or a combination thereof.

17. The processor of claim 16.

Images