Patent Description:
A communication system can be seen as a facility that enables communication sessions between two or more entities such as communication devices, base stations and/or other nodes by providing carriers between the various entities involved in the communications path.

The communication system may be a wireless communication system. Examples of wireless systems comprise public land mobile networks (PLMN) operating based on radio standards such as those provided by 3GPP, satellite based communication systems and different wireless local networks, for example wireless local area networks (WLAN). The wireless systems can typically be divided into cells, and are therefore often referred to as cellular systems.

The communication system and associated devices typically operate in accordance with a given standard or specification which sets out what the various entities associated with the system are permitted to do and how that should be achieved. Communication protocols and/or parameters which shall be used for the connection are also typically defined. Examples of standard are the so-called <NUM> standards.

According to an aspect there is provided an apparatus comprising means for: receiving a request from a human operator to instantiate a closed loop for managing a communication system; identifying closed loop components based on the request; and instantiating a closed loop for managing a communication system with the closed looped components.

The request may indicate unique identifiers of the closed loop components.

The unique identifiers of the closed loop component may comprise unique names of the closed loop components.

The request may indicate roles of the closed loop components.

The roles may comprise collecting data, analysing data, making a decision and/or executing a decision.

The request may indicates capabilities of the closed loop components.

The capabilities may comprise reading data relating to a managed object from the object or a network database and format the data and/or making a prediction based on formatted data.

The request may comprise inputs of the closed loop components and/or outputs of the closed loop components.

The request may comprise performance metrics of the closed loop components or the closed loop for managing the communication system.

Instantiating the closed loop for managing the communication system with the closed loop components may comprise: composing the closed loop for managing the communication system with the closed loop components; configuring the closed loop components; configuring the relations between the closed loop components; and/or configuring the closed loop for managing the communication system as active.

Configuring the relations between the closed loop components may comprise connecting the closed loop components.

Configuring the closed loop for managing the communication system may comprise: activating the closed loop components; and/or marking the closed loop for managing the communication system as active.

The apparatus may comprise means for: sending, to the operator, a notification indicating that the closed loop for managing the communication system has been instantiated; or sending, to the operator, a notification indicating that the closed loop for managing the communication system has not been instantiated.

Identifying the closed looped components is further based on a repository storing identifiers of closed looped components, roles of the closed loop components, capabilities of the closed loop components, inputs of the closed loop components, outputs of the closed loop components and/or performance metrics of the closed loop components.

The closed loop components may originate from different vendors.

The closed loop components may operate on different systems of the network.

The apparatus may be a closed loop control.

The closed loop control may be an automation platform or may be part of an automation platform.

According to an aspect there is provided a method comprising: receiving a request from a human operator to instantiate a closed loop for managing a communication system; identifying closed loop components based on the request; and instantiating a closed loop for managing a communication system with the closed looped components.

According to an aspect there is provided a computer program comprising computer executable code which when run on at least one processor is configured to: receive a request from a human operator to instantiate a closed loop for managing a communication system; identify closed loop components based on the request; and instantiate a closed loop for managing a communication system with the closed looped components.

In the above, many different aspects have been described. It should be appreciated that further aspects may be provided by the combination of any two or more of the aspects described above.

Various other aspects are also described in the following detailed description and in the attached claims.

In the following certain embodiments are explained with reference to mobile communication devices capable of communication via a wireless cellular system and mobile communication systems serving such mobile communication devices. Before explaining in detail the exemplifying embodiments, certain general principles of a wireless communication system, access systems thereof, and mobile communication devices are briefly explained with reference to <FIG>, <FIG> and <FIG> to assist in understanding the technology underlying the described examples.

<FIG> shows a schematic representation of a <NUM> system (5GS). The 5GS may comprises a terminal, a (radio) access network ((R)AN), a <NUM> core network (5GC), one or more application functions (AF) and one or more data networks (DN).

The <NUM> (R)AN may comprise one or more gNodeB (gNB) distributed unit functions connected to one or more gNodeB (gNB) centralized unit functions.

The 5GC may comprise an access and mobility management function (AMF), a session management function (SMF), an authentication server function (AUSF), a user data management (UDM), a user plane function (UPF) and/or a network exposure function (NEF). The 5GC may comprise other network functions (NF) non-illustrated such as an automation platform implementing a control loop controller (CLC).

<FIG> illustrates an example of a control apparatus <NUM> for controlling a function of the (R)AN or the 5GC as illustrated on <FIG>. The control apparatus may comprise at least one random access memory (RAM) 211a, at least on read only memory (ROM) 211b, at least one processor <NUM>, <NUM> and an input/output interface <NUM>. The at least one processor <NUM>, <NUM> may be coupled to the RAM 211a and the ROM 211b. The at least one processor <NUM>, <NUM> may be configured to execute an appropriate software code <NUM>. The software code <NUM> may for example allow to perform one or more steps to perform one or more of the present aspects. The software code <NUM> may be stored in the ROM 211b. The control apparatus <NUM> may be interconnected with another control apparatus <NUM> controlling another function of the <NUM> (R)AN or the 5GC. In some embodiments, each function of the (R)AN or the 5GC comprises a control apparatus <NUM>. In alternative embodiments, two or more functions of the (R)AN or the 5GC may share a control apparatus.

<FIG> illustrates an example of a terminal <NUM>, such as the terminal illustrated on <FIG>. The terminal <NUM> may be provided by any device capable of sending and receiving radio signals. Non-limiting examples comprise a user equipment, a mobile station (MS) or mobile device such as a mobile phone or what is known as a 'smart phone', a computer provided with a wireless interface card or other wireless interface facility (e.g., USB dongle), a personal data assistant (PDA) or a tablet provided with wireless communication capabilities, a machine-type communications (MTC) device, a Cellular Internet of things (CIoT) device or any combinations of these or the like. The terminal <NUM> may provide, for example, communication of data for carrying communications. The communications may be one or more of voice, electronic mail (email), text message, multimedia, data, machine data and so on.

The terminal <NUM> may receive signals over an air or radio interface <NUM> via appropriate apparatus for receiving and may transmit signals via appropriate apparatus for transmitting radio signals. In <FIG> transceiver apparatus is designated schematically by block <NUM>. The transceiver apparatus <NUM> may be provided for example by means of a radio part and associated antenna arrangement. The antenna arrangement may be arranged internally or externally to the mobile device.

The terminal <NUM> may be provided with at least one processor <NUM>, at least one memory ROM 302a, at least one RAM 302b and other possible components <NUM> for use in software and hardware aided execution of tasks it is designed to perform, including control of access to and communications with access systems and other communication devices. The at least one processor <NUM> is coupled to the RAM 302b and the ROM 302a. The at least one processor <NUM> may be configured to execute an appropriate software code <NUM>. The software code <NUM> may for example allow to perform one or more of the present aspects. The software code <NUM> may be stored in the ROM 302a.

The processor, storage and other relevant control apparatus can be provided on an appropriate circuit board and/or in chipsets. This feature is denoted by reference <NUM>. The device may optionally have a user interface such as keypad <NUM>, touch sensitive screen or pad, combinations thereof or the like. Optionally one or more of a display, a speaker and a microphone may be provided depending on the type of the device.

One or more aspects of this disclosure relate to techniques for automatically instantiating (i.e. creating) a closed loop (CL) in a communication system. The communication may be a mobile system, such as a <NUM> system or a future generation system.

A CL may refer to a control theory concept based on the sequence below:.

A CL may be executed once, terminating execution after receiving feedback. A CL may be executed multiple times. A CL may also be executed a finite number of times or an infinite resulting in what is called an infinite loop.

A CL may refer to the control theory concept as such or to a logical entity implementing the control theory concept. The logical entity may comprise one or more CL components.

<FIG> shows a schematic representation of a CL comprising four CL components chained to form a loop (see <NPL>). The four CL components may comprise a data collection CL component, an analysis component, a decision component and an execution component. It will be understood that the CL may comprise less than four CL components or more than four components.

A CL management function (MnF) may refer to a logical entity that interacts with a network (or network resources) to capture or monitor data about a network event and to act on the network (or the network resources).

A CL MnF may comprise a CL and a control point (CP) via which the CL MnF may be managed or controlled (i.e. a point which supports interaction with external entities).

The CL MnF may provide a control interface through which external entities may manage or control the CL MnF as well as an exposure interface through which the CL MnF may expose characteristics of the CL towards external entities. Note that the CP may be implemented as a standalone component within the CL MnF or as part of the CL components specially as part of the decision CL component.

<FIG> shows a schematic representation of an MnF Fn1 with a CL comprising four closed loop components (the analysis CL component and the analysis CL component are separate) and a control point and another MnF Fn2 with a CL comprising three closed loop components (the analysis CL component and the analysis CL component are combined).

It is important to note that a CL is not necessarily based on the above sequence of operations <NUM>) to <NUM>). A CL may be based on a different sequence, such as MAPE-K (Monitor, Analyse, Plan, Execute - Knowledge - see<NPL>) or OODA (Observe, Orient, Decide, Act - see <NPL>").

Although on <FIG> the CL MnF Fn1 and Fn2 are represented as separate logical entities with separate control interfaces and exposure interfaces this may not always be the case. Multiple CL MnFs may be implemented as combinations of different CL components in a single entity (e.g. in a single application) with a single control interface and a single exposure interface.

An example may be the application Nokia NetACT. Nokia NetACT may implement different CL components for data collection such as the simple network management protocol mediation, for analysis such as the monitor, for decision making such as the performance manager as well as for execution of network configurations such as the configurator. The CL components may be combined to compose a separate CL MnFs. With Nokia NetACT multi-vendor interactions may only be required for the control interface and the exposure interface. That is, Nokia NetACT may interact with external entities from Nokia or from another vendor via the control interface and the exposure interface.

There is a push however for multi-vendor network automation environments. For example, Nokia EdenNet seeks to support third party applications by providing a software development kit (the EdenNet SDK) through which third-party vendors may develop modules that can be executed on EdenNet. This supports specific modules for accomplishing certain tasks, for example providing a specific customized analysis on some indicated data. It however requires close integration, for example the third-party vendor shall co-develop the application using EdenNet SDK. Yet because of intellectual property concerns, the vendors may not be willing to open their developments by using a common development kit. Instead, the eventual implementation is likely to be a platform through which multi-vendor CLs are integrated without the need for a shared development.

A CL may be a multi-vendor CL. That is, a CL may be composed from multi-vendor CL components using standardised APIs. However, these APIs are currently not available. As illustrated by <FIG>, the different CL components implement control interfaces and exposure interfaces, through which an external entity may control the CL components. These control interfaces and exposure interfaces are not yet explored. Each CL component may also implement run-time interfaces through which the CL components may exchange data to accomplish the network management tasks.

Typically, a common implementation may assume that a multi-vendor CL is integrated and managed by a human operator manually. However, given the likely large number of CLs that may be instantiated (i.e. created) on a given network, it would be a heavy task for an operator to manage the CLs. Instead another means is needed to automate the management operations. The question then is how to automatically instantiate (i.e. create) multi-vendor CLs while leveraging standardized APIs.

One or more aspects of this disclosure provide techniques for automatically instantiating a CL in an efficient way. More specifically, one or more aspects of this disclosure provide techniques for automatically instantiating a CL while leverage the 3GPP SA5 APIs.

One or more aspects of this disclosure shed light on the APIs, which enable different CL components to implement control interfaces and exposure interfaces.

There has been discussions in standards groups for whitebox deployments, where CL components are not pre-integrated or pre-selected and combined by the respective vendors, but where CL can be instantiated (i.e. created) by combining CL components from different vendors. However, no mechanism has been provided to achieve this.

On or more aspect of this disclosure provide a CL control/controller (CLC) that is responsible for identifying CL components based on an input provided by an operator and instantiating a CL with the CL components. The CLC may replaces the operator for identifying CL components and instantiating a CL with the CL components the CL as illustrated on <FIG>.

The CLC may be an automation platform or a part of an automation platform.

The operator may send a request to the CLC to instantiate a CL. The request may comprise information (input from the operator) that allows the CLC to identify CL components and instantiate a CL with the CL components. There may be four possible methods that may be used by the CLC to identify the CL components.

In a first method using CL components identifiers, the operator may know (e.g. via pre-arrangement per use case, capabilities and/or roles) the exact CL components which need to compose a CL. In that case, the operator may identify the CL components, for example using their unique identifiers (e.g. unique names such as Calculate_mean or Statistical_analysis). The operator may define the roles (e.g. Data collection, Analysis, Decision, execution) of the CL components. The operator may provide the unique identifiers and roles in a request sent to the CLC. The operator may use a hash function. An example of a hash function may be:
{
Data collection - function ABC,
Analysis - function AXC,
Decision - function GBC,
Execution - function XDF
}.

In a second method using CL components inputs and/or outputs, the operator may not know the exact CL components which need to compose a CL. However, the operator may know the inputs (e.g. tuple) to be used by the CL components and/or outputs (e.g. tuple) to be generated by the CL components. In that case, the operator may identify the inputs and/or outputs of the CL components. The operator may define the roles (e.g. Data collection, Analysis, Decision, execution) of the CL components. The operator may provide the inputs and/or outputs of the CL components and the roles of the CL components in a request sent to the CLC. The operator may use a hash function. An example of a has function may be:
{
Data collection - cell identifiers,
Analysis - handover measurements counters data,
Decision - handover failure statistics,
Execution - radio resource control configurations
}.

In a third method using CL components capabilities, the operator may not know the exact CL components which need to compose a CL. Also, the operator may not know the inputs (e.g. tuple) to be used by the CL components and outputs (e.g. tuple) to be generated by the CL components. However, the operator may know the capabilities (e.g. reading data relating to the performance of a cell from a network database and format the data and/or making a prediction based on formatted data) of the CL components (or a subset of them). In that case, the operator may identify the capabilities of the CL components. The operator may define the roles (e.g. Data collection, Analysis, Decision, execution) of the CL components. The operator may provide the capabilities of the CL components and the roles of the CL in a request sent to the CLC. The operator may use a hash function. An example of a hash function may be:
{
Data collection - capability: collects and formats handover performance data as
a time series,
Analysis - capability: derives insight about the state of handover performance
and possible suggest recommendations,
Decision - capability: derives actions intended to improve handover for a given
object (cell or group of cells),
Execution - capability: implements actions related to cell handover performance
e.g. on TTT and CIO
}.

In a fourth method using a combination of CL components inputs, outputs and/or capabilities, the operator may not know the exact CL components which need to compose a CL. However, the operator may know the inputs (e.g. tuple) to be used by the CL components, outputs (e.g. tuple) to be generated by the CL components and/or the capabilities (e.g. reading data relating to the performance of a cell from a network database and format the data and/or making a prediction based on formatted data) of the CL components (or a subset of them). The operator may provide the capabilities of the CL components and the inputs of the CL components as the input in a request sent to the CLC. The operator may provide the capabilities of the CL components and the outputs of the CL components as the input in a request sent to the CLC. The operator may provide the capabilities of the CL components, the inputs and the outputs of the CL components in a request sent to the CLC. The operator may use a hash function. An example of a hash function may be a combination of the above has functions.

The operator may trigger the instantiation of the CL for example using the createMOI procedure defined by 3GPP SA5.

The CLC may identify the CL components to compose the CL based on the unique identifiers of the CL components, inputs and outputs of the CL components, roles of the CL components and/or capabilities of the CL component indicated by the operator in the request.

The CLC may identify the CL components to compose the CL based on assurance expectations of the CL components or the CL (e.g. expressed in form of a CL goal, which can be decomposed into assurance performance metrics such as delay, throughput, etc). The information may be provided using a hash function.

The CLC may configure the CL components. The CLC may configure the relation and data exchange among the CL components. For example, the CLC may configure the data collection CL component to deliver data to the analytics CL component. The CLC may configure the analytics CL component to collect data from the data collection CL component whenever such data is needed to compute analytics. The CLC may configure the analytics CL component to deliver data to the decision CL component. The CLC may configure the decision CL component to request and collect data in the form of an analytics report from the analytics CL component whenever such data is needed to derive a decision. The CLC may configure the decision CL component to deliver data in form of recommended actions or commands to the execution CL component. The CLC may configure the execution CL component to collect data in form of a set of recommended actions from the decision CL component whenever such recommendations are needed. The CLC may configure the execution component to implement the recommended actions on to the network once received or upon certain conditions (e.g. threshold surpass). The CLC may configure the CL components to provide performance management (PM), key performance indicator (KPI) and/or feedback data on their operations.

The CLC may be modelled as a logical entity that receives and fulfils the requests to instantiate the CL for example using the createMOI procedure.

The section below depicts the set of classes that encapsulates the information relevant for this management service (MnS )and provides an overview of the relationships between relevant classes in UML.

Each of <FIG> shows a schematic representation of a CLC network resource management fragment.

<FIG> shows a signalling diagram of a first process for instantiating (i.e. creating) a CL for managing a communication system.

In step <NUM> the operator may identify and compile information to be provided to the CLC to identify CLcomponents and instantiate (i.e. create) a CL with the CL components. The information may comprise unique identifiers (e.g. unique names) of the CL components, inputs of the CL components, outputs of the CL components, roles of the CL components and/or capabilities of the CL components. The information may further comprise assurance expectations of the CL components or the CL (e.g. expressed in form of a CL goal, which can be decomposed into assurance performance metrics such as delay, throughput, etc). The information may be provided using a hash function.

In step <NUM> the operator may send a request to the CLC to instantiate (i.e. create) a CL. The request may provide the information that may be used by the CLC to identify CL components and then instantiate the CL.

In step <NUM> the CLC may interpret the information. The CLC may determine how the CL components should be identified based on the information. For example, if the information comprises the unique identifiers of the CL components then the CLC may determine that the CL components identified by the unique identifiers should be identified. If the information only comprises inputs and outputs of the CL components then the CLC may determine that CL components matching the inputs and outputs of the CL components provided by the operator should be identified.

In step <NUM> the CLC may identify the CL components based on the information. The CLC may identify the CL components based on a repository that holds available CL components. The CLC may then compose the CL with the identified CL components.

It will be understood that the CL components may operate on different systems of the network (e.g. a CL component may operate on a management data analytics platform or function while another CL component may be operate on a cognitive self organizing network server. In such a case the CLC may identify the systems where the CL components should operate. The repository may integrated within the CLC in which case step <NUM> may be internal within the CLC.

In step <NUM> the CLC configure the CL component. The CLC may configure the relation and data exchange among the CL components.

In step <NUM> the CLC may configure the CL. For example, the CLC may activate the CL components. The CLC may mark the CL as active.

In step <NUM> the CLC may send a notification to the operator indicating that the CL has been instantiated (i.e. created). Alternatively, the CLC may send a notification to the operator indicating that the CL has not been instantiated (i.e. created).

In step <NUM> the operator may further configure the CL or the CL components.

<FIG> shows a signalling diagram of a second process for instantiating (i. e creating) a CL for managing a communication system.

Each CL component may be identified by a unique identifier (e.g. unique name). In a scenario the operator may know the unique identifiers of the CL components.

In step <NUM> the operator may identify and compile information to be provide to the CLC to identify CLC components and instantiate (i.e. create) a CL with the CL components. The information may comprise unique identifiers (e.g. unique names) of the CL components and roles of the CL components. The information may be provided using a hash function.

In step <NUM> the CLC may interpret the information. The CLC may determine how the CL components should be identified based on the information. Here, the information comprises the unique identifiers of the CL components then the CLC may determine that CL components identified by the unique identifiers provided by the operator should be identified.

In step <NUM> the CLC may identify the CL components based on the information. The CLC may identify the CL components based on a repository that holds available CL components and/or based on pre-configuration arrangements. The CLC may then compose the CL with the identified CL components.

The CL components may operate on different systems of the network (e.g. a CL component may operate on a management data analytics platform or function while another CL component may be operate on a cognitive self organizing network server. In such a case the CLC may identify the systems where the CL components should operate. The repository may be integrated within the CLC in which case step <NUM> may be internal within the CLC.

<FIG> shows a signalling diagram of a third process for instantiating (i.e. creating) a CL for managing a communication system.

Each CL component may be identified by a unique identifier (e.g. unique name). Each CL component may be identified by inputs used by the CL component and/or outputs generated by the CL component. In a scenario the operator may not know the unique identifiers of the CL components but may know the inputs and/or outputs of the CL components.

For example a Vendor_x data collection component may use performance management data as inputs and may generate formatted data (e.g. time series) as outputs. In this way, if the operator wishes to instantiate (i.e. create) a CL comprising a data collection component that uses performance management data as inputs and generating formatted data (e.g. time series) as outputs, then the CLC may identify the Vendor_x data collection component.

Similarly a Vendor_y analytics and decision component may use formatted data as inputs and may generate decisions as outputs. In this way, if the operator wishes to instantiate a CL comprising an analytics and decision component that uses formatted data as inputs and generating decisions as outputs, then the CLC may identify the Vendor_y analytics and decision component.

The CLC may be configured to identify CL components matching inputs and/or outputs of the CL components provided by the operator.

In step <NUM> the operator may identify and compile information to be provide to the CLC to identify CLC components and instantiate (i.e. create) a CL with the CL components. The information may comprise inputs and/or outputs of the CL components and roles of the CL components. The information may be provided using a hash function. The inputs and/or outputs of the CL components may be ordered such that the position of the inputs and/or outputs of the CL components is indicative of the role of the CL components. For example, the first inputs and/or outputs of a CL component may correspond to a data collection CL component, the second inputs and/or outputs of a CL component may correspond to an analysis CL component, the third inputs and/or outputs of a CL component may correspond to a decision CL component and the fourth inputs and/or outputs of a CL component may correspond to an execution CL component.

In step <NUM> the operator may send a request to the CLC to instantiate (i.e. create) a CL. The request may provide the information that may be used by the CLC to identify CL components and then instantiate (i.e. create) the CL.

In step <NUM> the CLC may interpret the information. The CLC may determine how the CL components should be identified based on the information. Here, the information comprises the inputs and/or outputs of the CL components then the CLC may determine that CL components matching the inputs and outputs of the CL components provided by the operator should be identified.

<FIG> shows a signalling diagram of a fourth process for instantiating (i.e. creating) a CL for managing a communication system.

Each CL component may be identified by a unique identifier (e.g. unique name). Each CL component may be identified by inputs used by the CL component and/or outputs generated by the CL component. Each CL component may be identified by capabilities of the CL component. In a scenario the operator may not know the unique identifiers of the CL components, the operator may not know the inputs and outputs of the CL components but the operator may know the capabilities of the CL components.

For example, the capabilities of a data collection CL component may comprise reading the performance of a cell from network databases and providing the PM data formatted into an hourly time series. The capabilities of an analytics CL component may comprise using a time series of historical cell performance and providing predictions of the likely performance in the next x hours. The value of x may be configurable by the consumer of the analytics. The capabilities of the decision CL component may comprise using a particular kind data and format from and making a decision.

The CLC may be configured to identify CL components matching capabilities of the CL components provided by the operator.

In step <NUM> the operator may identify and compile information to be provide to the CLC to identify CL components and instantiate (i.e. create) a CL with the CL components. The information may comprise capabilities of the CL components and/or roles of the CL components. The information may be provided using a hash function. The capabilities of the CL components may be ordered such that the position of the capabilities of the CL components is indicative of the role of the CL components. For example, the first capabilities of a CL component may correspond to a data collection CL component, the second capabilities of a CL component may correspond to an analysis CL component, the third capabilities of a CL component may correspond to a decision CL component and the fourth capabilities of a CL component may correspond to an execution CL component.

In step <NUM> the CLC may interpret the information. The CLC may determine how the CL components should be identified based on the information. Here, the information comprises the capabilities of the CL components then the CLC may determine that CL components matching the capabilities of the CL components provided by the operator should be identified.

The CL components may operate on different systems of the network (e.g. a CL component may operate on a management data analytics platform or function while another CL component may operate on a cognitive self organizing network server. In such a case the CLC may identify the systems where the CL components should operate. The repository may be integrated within the CLC in which case step <NUM> may be internal within the CLC.

It may be helpful to have a full description of the CL components to facilitate identification of the CL components on the repository. The CL component related information model of <FIG> may be used.

The CL component information object class (IOC) may represent the properties of an abstract CL component. The CL component IOC may include attributes inherited from a top IOC (defined in TS <NUM>) and one or more of the attributes listed in table <NUM>. The definition of these attributes is provided table <NUM>.

The CLComponentProfile of a CL component may comprise descriptions of some or all the characteristics of the CL component, such as descriptions of the roles, descriptions of inputs, descriptions of outputs, descriptions of capabilities, descriptions of data formats, etc..

The operator may read the CLComponentProfile of a CL component in order to understand the operation of the CL component and how it may be combined with another CL component. The entries in the CLComponentProfile may include one or more attributes listed in Table <NUM> whose definition is provided in Table <NUM>.

Although the requirements for the interfaces of the CL components may be different depending on the characteristics of the CL components, they may be implemented using the same APIs. Specifically, the interfaces for the CL components may comprise a control interface and an exposure interface.

The control interface may be used to configure the CL components. The control interface may be implemented using a provisioning management service produced by the CL components and consumed by the CLC. The respective details for each CL component may be implemented as in Table <NUM>.

The exposure interface may be used to collect and expose operational data from the CL components to the CLC. The exposure interface may be implemented using the file data reporting or streaming data reporting APIs as described in TS <NUM>. Therein the service is produced by the CL components and consumed by the CLC. The respective details for each CL component may be implemented as in Table <NUM>.

<FIG> shows a block diagram of a method for instantiating a CL for managing a communication system performed by a CLC.

In step <NUM>, a CLC may receive a request from an operator to instantiate a CL for managing a communication system.

In step <NUM>, the CLC may identify CL components based on the request.

In step <NUM>, the CLC may instantiate a CL for managing a communication system with the CL components.

The request may indicate unique identifiers of the CL components.

The unique identifiers of the CL component may comprise unique names of the CL components.

The request may indicate roles of the CL components. The roles may comprise collecting data, analysing data, making a decision and/or executing a decision.

The request may indicates capabilities of the CL components. The capabilities may comprise reading data relating to a managed object from the object or a network database and format the data and/or making a prediction based on formatted data.

The request may comprise inputs of the CL components and/or outputs of the CL components.

The request may comprise performance metrics of the CL components or the CL for managing the communication system.

Instantiating the CL for managing the communication system with the CL components may comprise: composing the CL for managing the communication system with the CL components; configuring the CL components; configuring the relations between the CL components; and/or configuring the CL for managing the communication system as active.

Configuring the relations between the CL components may comprise connecting the CL components.

Configuring the CL for managing the communication system may comprise: activating the CL components; and/or marking the CL for managing the communication system as active.

The CLC may send, to the operator, a notification indicating that the CL for managing the communication system has been instantiated. Alternatively, the CLC may send, to the operator, a notification indicating that the CL for managing the communication system has not been instantiated.

Identifying the CL components is further based on a repository storing identifiers of CL components, roles of the CL components, capabilities of the CL components, inputs of the CL components, outputs of the CL components and/or performance metrics of the CL components.

The CL components may originate from different vendors.

The CL components may operate on different systems of the network.

The CLC may be an automation platform or may be part of an automation platform.

<FIG> shows a schematic representation of non-volatile memory media <NUM> storing instructions and/or parameters which when executed by a processor allow the processor to perform one or more of the steps of the method of <FIG>.

It is noted that while the above describes example embodiments, there are several variations and modifications which may be made to the disclosed solution without departing from the scope of the present invention.

It will be understood that although the above concepts have been discussed in the context of a 5GS, one or more of these concepts may be applied to other cellular systems.

The embodiments may be implemented by computer software stored in a memory and executable by at least one data processor of the involved entities or by hardware, or by a combination of software and hardware. Further in this regard it should be noted that any procedures, e.g., as in <FIG>, may represent program steps, or interconnected logic circuits, blocks and functions, or a combination of program steps and logic circuits, blocks and functions.

Alternatively or additionally some embodiments may be implemented using circuitry. The circuitry may be configured to perform one or more of the functions and/or method steps previously described. That circuitry may be provided in the base station and/or in the communications device.

The term circuitry also covers, for example integrated device.

Claim 1:
An apparatus comprising means for:
receiving (<NUM>) a request from a human operator to instantiate a closed loop for managing a communication system;
identifying (<NUM>) closed loop components based on the request; and
instantiating (<NUM>) a closed loop for managing a communication system with the closed looped components,
wherein the request indicates unique identifiers of the closed loop components.