WO2025201722A1

WO2025201722A1 - Method, apparatus and computer program for a closed control loop decision making and escalation

Info

Publication number: WO2025201722A1
Application number: PCT/EP2025/053491
Authority: WO
Inventors: Parisa Foroughi; Stephen MWANJE
Original assignee: Nokia Technologies Oy
Current assignee: Nokia Technologies Oy
Priority date: 2024-03-28
Filing date: 2025-02-11
Publication date: 2025-10-02
Anticipated expiration: 2026-09-28
Also published as: GB202404451D0; GB2639920A

Abstract

There is provided an apparatus comprising: means for obtaining, for a closed control loop, a level of confidence for a decision related to a network context, and means for comparing the level of confidence to a threshold. The apparatus further comprises: means for, based on the comparing, providing, to a first network entity, a request for an escalation of the decision, and means for receiving, from the first network entity, a report comprising at least one outcome for the decision that the first network entity has determined.

Description

METHOD, APPARATUS AND COMPUTER PROGRAM FOR A CLOSED CONTROL LOOP DECISION MAKING ANDESCALATION

Technical Field

Various examples of this disclosure relate to methods, apparatuses, and computer programs for a communication network.

Background

A communication network can be seen as a facility that enables communications between two or more communication devices, or provides communication devices access to a data network. A mobile or wireless communication network is one example of a communication network. A communication device may be provided with a service by an application server.

Such communication networks operate in accordance with standards such as those provided by 3GPP (Third Generation Partnership Project) or ETSI (European Telecommunications Standards Institute). Examples of standards are the so-called 5G (5th Generation) standards provided by 3GPP.

Some examples of this disclosure will be described with respect to certain aspects. These aspects are not intended to indicate key or essential features of the embodiments of this disclosure, nor are they intended to be used to limit the scope thereof. Other features, aspects, and elements will be readily apparent to a person skilled in the art in view of this disclosure. For example, it should be appreciated that further aspects may be provided by the combination of any two or more of the various aspects described below.

According to an aspect, there is provided an apparatus comprising: means for obtaining, for a closed control loop, a level of confidence for a decision related to a network context; means for comparing the level of confidence to a threshold; means for, based on the comparing, providing, to a first network entity, a request for an escalation of the decision; and means for receiving, from the first network entity, a report comprising at least one outcome for the decision that the first network entity has determined.

In some examples, the apparatus comprises: means for executing the closed control loop, wherein the means for executing comprises: the means for obtaining, for the closed control loop, the level of confidence for the decision related to the network context, the means for comparing the level of confidence to the threshold, the means for, based on the comparing, providing, to the first network entity, the request for an escalation of the decision, and the means for receiving, from the first network entity, a report comprising at least one outcome for the decision that the first network entity has determined.

In some examples, the apparatus is configured for executing the closed control loop.

In some examples, the at least one outcome is information that is actionable by the apparatus, for the decision.

In some examples, the request comprises information related to the decision.

In some examples, the threshold is obtained as part of a configuration.

In some examples, the apparatus comprises: means for receiving, from a further entity, the configuration comprising the threshold.

In some examples, the threshold comprises a numerical value. In some examples, the threshold comprises a discrete value.

In some examples, the information related to the decision comprises at least one of: an action with an associated probability for the action, an indication of the type of information related to the decision, at least one constraint associated with the decision, at least one preference associated with the decision, an attribute indicating a reason related to the escalation, an identity associated with the request.

In some examples, the apparatus comprises: means for calculating a probability for an action for the decision, wherein the calculating is based on at least one of: the network context, and the decision.

In some examples, the means for obtaining the level of confidence for the decision related to the network context comprises: means for calculating the level of confidence based on the probability for the action.

In some examples, the information related to the decision comprises: a plurality of actions for the decision, wherein each action of the plurality of actions has an associated probability value.

In some examples, the at least one outcome comprises at least one of: an identity associated with the request, a status indicating how the closed control loop should proceed, or an indication of an action for the decision.

In some examples, the status comprises a value, the value of the status indicating for the closed control loop to perform one of: proceed to execute an action for the decision according to the information in the request, execute an action as identified in the at least one outcome, or refrain from performing an action.

In some examples, the apparatus comprises: means for, based on the at least one outcome, performing an action associated with the decision.

In some examples, the apparatus comprises: means for, based on the indication of the action for the decision, performing the action associated with the decision.

In some examples, the apparatus is a second network entity. In some examples, the second network entity is configured as a management service consumer.

According to an aspect, there is provided an apparatus comprising: means for receiving, from a second network entity, a request for an escalation of a decision related to a network context; means for determining, based on the request, at least one outcome for the decision; and means for providing, to the second network entity, a report comprising the at least one outcome for the decision.

In some examples, the request comprises information related to the decision.

In some examples, the information related to the decision comprises at least one of: at least one action with an associated probability for each action, an indication of the type of information related to the decision, at least one constraint associated with the decision, at least one preference associated with the decision, an attribute indicating a reason related to the escalation, an identity associated with the request.

In some examples, the indication of the action in the report is one of: the same as an action associated with the request, or different to one or more actions indicated in the request.

In some examples, the apparatus comprises: means for receiving, from a third network entity, a second request for a second escalation of a second decision for a second closed control loop, wherein the second request comprises information related to the second decision, the information comprising an action with an associated probability for the action.

In some examples, the means for determining, based on the request, at least one outcome for the decision comprises: means for determining the at least one outcome for the decision based on: the request and the second request.

In some examples, the means for determining the at least one outcome for the decision based on: the request and the second request comprises: means for determining the at least one outcome for the decision based on: the request, the second request, an associated priority value for the closed control loop of the request, and an associated priority value for the second closed control loop of the second request. In some examples, the apparatus comprises: means for, based on the at least one outcome, performing an action associated with the decision.

In some examples, the apparatus is a first network entity.

In some examples, the first network entity is configured as a management service producer.

According to an aspect, there is provided a method comprising: obtaining, for a closed control loop, a level of confidence for a decision related to a network context; comparing the level of confidence to a threshold; based on the comparing, providing, to a first network entity, a request for an escalation of the decision; and receiving, from the first network entity, a report comprising at least one outcome for the decision that the first network entity has determined.

In some examples, the obtaining, the comparing, the providing, and the receiving are associated with the closed control loop.

In some examples, the obtaining, the comparing, the providing, and the receiving are part of an execution of the closed control loop.

In some examples, the method comprises: executing the closed control loop.

In some examples, the at least one outcome is information that is actionable by an apparatus, for the decision.

In some examples, the request comprises information related to the decision.

In some examples, the threshold is obtained as part of a configuration.

In some examples, the method comprises: receiving, from a further entity, the configuration comprising the threshold.

In some examples, the method comprises: calculating a probability for an action for the decision, wherein the calculating is based on at least one of: the network context, and the decision.

In some examples, the obtaining the level of confidence for the decision related to the network context comprises: calculating the level of confidence based on the probability for the action.

In some examples, the information related to the decision comprises: a plurality of actions for the decision, wherein each action of the plurality of actions has an associated probability value. In some examples, the at least one outcome comprises at least one of: an identity associated with the request, a status indicating how the closed control loop should proceed, or an indication of an action for the decision.

In some examples, the method comprises: based on the at least one outcome, performing an action associated with the decision.

In some examples, the method comprises: based on the indication of the action for the decision, performing the action associated with the decision.

In some examples, the method is performed by a second network entity.

In some examples, the second network entity is configured as a management service consumer.

According to an aspect, there is provided a method comprising: receiving, from a second network entity, a request for an escalation of a decision related to a network context; determining, based on the request, at least one outcome for the decision; and providing, to the second network entity, a report comprising the at least one outcome for the decision.

In some examples, the request comprises information related to the decision.

In some examples, the indication of the action in the report is one of: the same as an action associated with the request, or different to one or more actions indicated in the request. In some examples, the method comprises: receiving, from a third network entity, a second request for a second escalation of a second decision for a second closed control loop, wherein the second request comprises information related to the second decision, the information comprising an action with an associated probability for the action.

In some examples, the determining, based on the request, at least one outcome for the decision comprises: determining the at least one outcome for the decision based on: the request and the second request.

In some examples, the determining the at least one outcome for the decision based on: the request and the second request comprises: determining the at least one outcome for the decision based on: the request, the second request, an associated priority value for the closed control loop of the request, and an associated priority value for the second closed control loop of the second request.

In some examples, the method is performed by a first network entity.

According to an aspect, there is provided an apparatus comprising: at least one processor, and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to perform: obtaining, for a closed control loop, a level of confidence for a decision related to a network context; comparing the level of confidence to a threshold; based on the comparing, providing, to a first network entity, a request for an escalation of the decision; and receiving, from the first network entity, a report comprising at least one outcome for the decision that the first network entity has determined.

In some examples, the apparatus is caused to perform: executing the closed control loop.

In some examples, the request comprises information related to the decision.

In some examples, the threshold is obtained as part of a configuration.

In some examples, the apparatus is caused to perform: receiving, from a further entity, the configuration comprising the threshold. In some examples, the threshold comprises a numerical value. In some examples, the threshold comprises a discrete value.

In some examples, the apparatus is caused to perform: calculating a probability for an action for the decision, wherein the calculating is based on at least one of: the network context, and the decision.

In some examples, the apparatus is caused to perform: based on the at least one outcome, performing an action associated with the decision.

In some examples, the apparatus is caused to perform: based on the indication of the action for the decision, performing the action associated with the decision.

In some examples, the apparatus is a second network entity.

According to an aspect, there is provided an apparatus comprising: at least one processor, and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to perform: receiving, from a second network entity, a request for an escalation of a decision related to a network context; determining, based on the request, at least one outcome for the decision; and providing, to the second network entity, a report comprising the at least one outcome for the decision.

In some examples, the request comprises information related to the decision. In some examples, the information related to the decision comprises at least one of: at least one action with an associated probability for each action, an indication of the type of information related to the decision, at least one constraint associated with the decision, at least one preference associated with the decision, an attribute indicating a reason related to the escalation, an identity associated with the request.

In some examples, the apparatus is caused to perform: receiving, from a third network entity, a second request for a second escalation of a second decision for a second closed control loop, wherein the second request comprises information related to the second decision, the information comprising an action with an associated probability for the action.

In some examples, the apparatus is a first network entity.

According to an aspect, there is provided a computer program comprising instructions, which when executed by an apparatus, cause the apparatus to perform at least the following: obtaining, for a closed control loop, a level of confidence for a decision related to a network context; comparing the level of confidence to a threshold; based on the comparing, providing, to a first network entity, a request for an escalation of the decision; and receiving, from the first network entity, a report comprising at least one outcome for the decision that the first network entity has determined.

According to an aspect, there is provided a computer program comprising instructions, which when executed by an apparatus, cause the apparatus to perform at least the following: receiving, from a second network entity, a request for an escalation of a decision related to a network context; determining, based on the request, at least one outcome for the decision; and providing, to the second network entity, a report comprising the at least one outcome for the decision.

According to an aspect, there is provided an apparatus comprising: circuitry configured to perform: obtaining, for a closed control loop, a level of confidence for a decision related to a network context; circuitry configured to perform: comparing the level of confidence to a threshold; circuitry configured to perform: based on the comparing, providing, to a first network entity, a request for an escalation of the decision; and circuitry configured to perform: receiving, from the first network entity, a report comprising at least one outcome for the decision that the first network entity has determined.

According to an aspect, there is provided an apparatus comprising: circuitry configured to perform: receiving, from a second network entity, a request for an escalation of a decision related to a network context; circuitry configured to perform: determining, based on the request, at least one outcome for the decision; and circuitry configured to perform: providing, to the second network entity, a report comprising the at least one outcome for the decision.

A computer product stored on a medium may cause an apparatus to perform the methods as described herein.

A non-transitory computer readable medium comprising program instructions, that, when executed by an apparatus, cause the apparatus to perform the methods as described herein.

An electronic device may comprise apparatus as described herein.

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

According to some aspects, there is provided the subject matter of the independent claims. Some further aspects are defined in the dependent claims. The embodiments that do not fall under the scope of the claims are to be interpreted as examples useful for understanding the disclosure.

List of Abbreviations:

AF: Application Function AMF: Access and Mobility Management Function

AN: Access Network

BS: Base Station

CCL: Closed control loop

CL: Control loop

CN: Core Network

DL: Downlink

DME: Decision making entity

DP: Decision point eNB: eNodeB gNB: gNodeB lloT: Industrial Internet of Things

LTE: Long Term Evolution

MDA: Management data analytics

ML: Machine learning

MS: Mobile Station

MnS: Management service

NEF: Network Exposure Function

NG-RAN: Next Generation Radio Access Network

NF: Network Function

NR: New Radio

NRF: Network Repository Function

NW: Network

PCF Policy Control Function

PLMN: Public Land Mobile Network

RAN: Radio Access Network

RF: Radio Frequency

SMF: Session Management Function

SON: Self-organising network

UE: User Equipment

UDR: Unified Data Repository

UDM: Unified Data Management

UL: Uplink

UPF: User Plane Function

3GPP: 3^rd Generation Partnership Project

5G: 5^th Generation

5GC: 5G Core network 5G-AN: 5G Radio Access Network

5GS: 5G System

Brief Description of Drawings

Some examples will now be described, by way of illustrative and non-limiting example only, with reference to the accompanying drawings in which:

FIG. 1 shows a schematic representation of a 5G communication system;

FIG. 2 shows a schematic representation of an apparatus for the 5G communication system of FIG. 1 ;

FIG. 3 shows a schematic representation of a communication device;

FIG. 4 shows a schematic representation of a system for triggering an escalation of a decision in a closed control loop;

FIG. 5 shows another schematic representation of a system for triggering an escalation of a decision in a closed control loop;

FIG. 6 shows an example flow diagram for triggering an escalation of a decision in a closed control loop;

FIG. 7 shows a schematic representation of a system for resolving an escalation request of a decision in a closed control loop;

FIG. 8 shows another schematic representation of a system for resolving an escalation request of a decision in a closed control loop;

FIG. 9 shows an example method flow diagram performed by an apparatus;

FIG. 10 shows another example method flow diagram performed by an apparatus; and

FIG. 11 shows a schematic representation of a non-volatile memory medium storing instructions which when executed by a processor allow a processor to perform one or more of the steps of the method of FIGS. 9 to 10.

Detailed Description

A control loop (CL) is a type of control mechanism that monitors and regulates a set of managed entities with the objective of achieving a specific goal. A closed control loop (CCL) is a control loop which operates without any intervention from a human operator or any other management entity, other than, in some instances, the configuration of the control loop.

A CCL is composed of 'monitoring’, ‘analysis’, ‘decision’ and ‘execution’ operations (or stages). A CCL is expected to make decisions in various contexts and situations based on information the CCL consumes as part of the monitoring, and any knowledge which is implemented in the analysis. However, a CCL may not have configured implementations for all possible situations that the CCL is to make a decision for. This implies that a CCL is thus expected to have different levels of certainty/confidence in the decisions that it the CCL is making at each situation. A level of confidence may be calculated and measured for each decision. While in some situations the CCL may be certain about the next action to execute in the execution stage, in some other situations, the CCL may be uncertain of which action to choose between several choices. Thus, the CCL would not always have the same confidence when determining an action is response to be decision being made.

3GPP Sa5 has agreed (e.g., in TR28.867, TS28.535 and TS28.536) to enhance mechanisms that enable CL automation by enhancing the specification for CCL. Among the agreed objectives are two that focus on supporting coordination among CLs and enhancing the capabilities of the closed control loops, that include:

- WT-5: Management Coordination: Study the relation between CLs and other management features (e.g. self-organising network (SON) functions, management data analytics (MDA), Intent) with the objective to harmonize, as appropriate.

- WT-7: Other Enhancements: Study other probable measures (e.g., CCL feedback, historical learning) to enhance the capabilities of a CCL for better and efficient operations.

The management of 3GPP networks is provided by management services (MnS). The service based architecture and interfaces support various management services of vastly different requirements on network configuration, network performance, and network fault supervision. The 3GPP network management architecture evolves supporting operators' design and management of their service oriented networks.

An MnS is a set of offered capabilities for management and orchestration of network and services. The entity producing an MnS is called MnS producer. The entity consuming an MnS is called MnS consumer. An MnS provided by an MnS producer can be consumed by any entity with appropriate authorisation and authentication.

When an entity providing a request to another entity, then the requesting entity may be acting as an MnS consumer, as it is requesting services. When an entity is responding to the request, the entity may be acting as an MnS producer, as it is providing the service. Therefore, the role of an MnS producer and an MnS consumer changes based on the messages that are exchanged. AN entity may change between the MnS consumer and MnS producer throughout a message exchange.

Functionality related to CLs and CCLs may be utilised as part of an MnS. In network environments, CCLs may be useful as CCLs help to automate the management of a network. When more decisions of a network are determined autonomously, the fewer resources are needed in order to maintain the network. However, completely autonomous CCLs being implemented in a network environment may not be possible. For a CCL to execute accurate and efficient decisions, other entities may be utilised by the CCL. In these situations, the CCL may escalate decision to another CCL which may have, for example: better capabilities, ability execute a different set of actions, or larger or more capable machine model (ML) model. However, a recipient of the request to escalate the decision may not be able to efficiently determine an action/execution for the decision.

While CCLs are expected to operate in different conditions, currently there are no means of flexibly configuring the CCLs to make versatile decisions based on the confidence of their decisions.

CCLs may not have the capability to flexibly determine whether to execute a decision or not, and often CCLs execute any decision and continue until they can no longer execute a decision. Stated differently, operation and performance of a CCL is limited to its implementation with no means for a consumer to customize the CCL to specific needs. CCLs could not hard code and implement all potential situations that the CCL may face when making a decision. Therefore, CCLs cannot always have the same confidence in their decisions.

One or more of the problems identified above are addressed in more or more of the examples discussed below.

In examples, there is provided an apparatus (e.g., a network entity) that obtains, for a closed control loop, a level of confidence for a decision related to a network context, and compares the level of confidence to a threshold. Based on the comparing, the apparatus provides, to a first network entity (e.g., another network entity), a request for an escalation of the decision, and then receives, from the first network entity, at least one outcome for the decision that the first network entity has determined.

In some examples, an apparatus (e.g., for an escalation function) implements a CCL that is associated with monitoring a network. When a decision related to a network state is determined for the CCL, and a level of confidence for the decision is lower than a threshold value, then the apparatus provides a request to escalate the decision to a further apparatus (e.g., for an escalation recipient). In some examples, the escalation recipient determines, based on the request, an outcome for the decision. The outcome for the decision is then provided, to the escalation function. The outcome is information that is actionable by the escalation function, for the decision (e.g., the outcome indicates that the escalation function is to perform an action for the decision, or the escalation recipient is to perform an action for the decision).

These examples will be described in more detail below, alongside FIGS. 4 to 8.

Before explaining the examples above in greater detail, an example communication system (as shown in FIG. 1) which is a service based architecture and has interfaces which support various MnS will now be described. For example, the communication system (as shown in FIG. 1) has the capability to implement CLs and CCLs as part of an MnS in order to manage the communication system. A communication device (as shown in FIG. 3) is part of the communication system (as shown in FIG. 1). The communication device is able to communicate with one or more of the entities of the communication system (as shown in FIG. 1) via an apparatus (as shown in FIG. 2), which may be part of/comprised in a base station.

These certain general aspects of the communication system and the communication device are now briefly described with reference to FIGS. 1 to 3 to assist in understanding the technology underlying the described examples.

FIG. 1 shows a schematic representation of a 5G communication system 100. The wireless communication system 100 comprises one or more communication devices 102 such as user equipments (UEs), or terminals. The wireless communication system 100 comprises a 5G system (5GS). The 5GS comprises a 5G radio access network (5G-RAN) 106, a 5G core network (5GC) 104 comprising one or more network functions (NF), one or more application functions (AFs) 108, and one or more data networks (DNs) 110.

The 5G-RAN 106 may comprise one or more gNodeB (gNB) distributed unit (DU) functions connected to one or more gNodeB (gNB) centralized unit (CU) functions.

The 5GC 104 comprises an access and mobility management function (AMF) 112, a session management function (SMF) 114, an authentication server function (AUSF) 116, a user data management (UDM) 118, a user plane function (UPF) 120, a network exposure function (NEF) 122 and/or other NFs. Some of the examples as shown below may be applicable to 3GPP 5G standards. However, some examples may also be applicable to 5G- advanced, 4G, 3G and other 3GPP standards.

In a wireless communication system 100, such as that shown in FIG. 1 , communication devices 102, such as for example, terminals, user apparatuses, user equipments (UE), and/or machine-type communication devices are provided with wireless access via at least one base station or similar wireless transmitting and/or receiving node or point. The communication device 102 is provided with an appropriate signal receiving and transmitting apparatus for enabling communications, for example enabling access to a communication network or communications directly with other devices. The communication device 102 may access a carrier provided by a base station or access point, and transmit and/or receive communications on the carrier.

FIG. 2 illustrates an example of an apparatus 200. The apparatus 200 may be for the 5G communication system of FIG. 1. The apparatus 200 may be for controlling a function of one or more network entities and/or network functions, such as the entities of the 5G-RAN or the 5GC as illustrated on FIG. 1. The apparatus 200 comprises at least one random access memory (RAM) 211a, at least one read only memory (ROM) 211b, at least one processor 212, 213 and an input/output interface 214. The at least one processor 212, 213 is coupled to the RAM 211a and the ROM 211 b. The at least one processor 212, 213 may be configured to execute an appropriate software code 215. The software code 215 may for example allow to perform one or more steps to perform one or more of the present aspects or examples. The software code 215 may be stored in the ROM 211b. The apparatus 200 may be interconnected with another apparatus 200 controlling another entity/function of the 5G-AN or the 5GC. . In some examples, apparatus 200 may be configured to provide one or more functions of the 5G-AN or the 5GC. For example, apparatus 200 may be configured to perform at least some functionality of a particular function of the 5G-AN or the 5GC. For example, apparatus 200 may be configured to operate as a particular function of the 5G-AN or the 5GC. In alternative examples, apparatus 200 may be configured to perform at least some functionality of two or more functions of the 5G-AN and/or the 5GC. For example, apparatus 200 may be configured to operate as two or more functions of the 5G-AN and/or the 5GC. The apparatus 200 may comprise one or more circuits, or circuitry (not shown) which may be configured to perform one or more of the present aspects or examples.

FIG. 3 illustrates an example of a communication device 300. The communication device 300 may be similar to the communication device 102 illustrated in FIG. 1. The communication device 300 may be provided by any device capable of sending and receiving radio signals. Non-limiting examples of a communication device 300 are a user equipment, a terminal, 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 (CloT) device, or a terrestrial/maritime/aerial vehicle such as a car, a truck, a boat, an air plane, or a drone, or any combinations of these or the like. The communication device 300 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 communication device 300 may receive signals over an air or radio interface 307 via appropriate apparatus for receiving and may transmit signals via appropriate apparatus for transmitting radio signals. In FIG. 3, a transceiver apparatus is designated schematically by block 306. The transceiver apparatus 306 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 communication device 300 may be provided with at least one processor 301 , at least one memory ROM 302a, at least one RAM 302b and other possible components 303 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 301 is coupled to the RAM 302b and the ROM 302a. The at least one processor 301 may be configured to execute an appropriate software code 308. The software code 308 may for example allow to perform one or more of the present aspects. The software code 308 may be stored in the ROM 302a. The communication device 300 may comprise one or more circuits, or circuitry (not shown) which may be configured to perform one or more of the present aspects or examples.

The processor, storage and other relevant control apparatus may be provided on an appropriate circuit board and/or in chipsets. This feature is denoted by reference 304. The communication device may optionally have a user interface such as keypad 305, 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.

FIG. 4 shows a schematic representation of a system for triggering an escalation of a decision in a closed control loop.

As seen in FIG. 4, there is an MnS consumer 401 which communicates with a first CCL 403 (herein ‘CCLT). The arrow between the MnS consumer 401 and CCL1 403 indicates a direction of communication. CCL1 403 monitors network resources 405, whereby CCL1 403 communicates back and forth with the network resources 405. CCL1 403 may be termed an ‘escalator function’ or an ‘escalator CCL’. In other examples, any other suitable name may be used. CCL1 403 may be associated with a further MnS consumer (not shown).

A CCL (e.g., CCL 403) may be provided by a vendor, or solution provider. CCLs provide services, for example, monitoring, decision making, and executing and more. The services provided by a CCL may be consumed by other CCLs, and vice a versa.

CCL1 403 is also able to communicate with a second CCL 407 (herein ‘CCL2’). CCL2 407 is a potential candidate as a recipient of a request for escalation of a decision from CCL1 403. An Al function 409 is another potential candidate as a recipient of a request for escalation of a decision from CCL1 403. In other examples, any other suitable recipient receives the request, such as an operator (e.g., a human operator).

The MnS consumer 401, the CCL1 403, the CCL2 407, and the Al function 409 may each be provided by a network entity. The MnS consumer 401 , the CCL1 403, the CCL2 407, and the Al function 409 may each be provided by different network entities in some examples. In other examples, the same network entity may provide one or more of the MnS consumer 401 , the CCL1 403, the CCL2 407, and the Al function 409.

The MnS consumer 401 is able to configure the CCL1 (as indicated by label T in FIG. 4). The MnS consumer 401 may configure the CCL1 according to the requirements/needs of the MnS consumer 401. Once configured, CCL1 403 performs monitoring of the network resources 405 and will make decisions (as indicated by label ‘2’ in FIG. 4). The monitoring of the network resources 405 is an example of monitoring a state of a network (herein ‘a network state’). For each decision, CCL1 403 determines whether to escalate the decision to another entity based on a level of confidence that the CCL1 403 has for the decision. When the CCL1 403 determines to escalate the decision, the CCL1 provides a request to one or more candidates, e.g., to at least one of CCL2 407 and the Al function 409 (as indicated by label ‘3’ in FIG. 4).

In some examples, an escalation function (e.g., 403) may be provided by an apparatus with the configuration to define autonomy characteristics (e.g., an autonomy level and an escalation recipient) for a CCL. This enables the CCL to be flexibly configured by an MnS consumer to make appropriate decisions based on the CCL’s confidence of decisions for different situations. The CCL is able to trigger an escalation of the decision to an escalation recipient (e.g., 407 or 409).

In some examples, an escalation function (e.g., 403) has the capability to perform at least one of: obtaining (or calculating) a level confidence for each decision on a network state (a network state may encompass a state, a context and/or a situation), comparing the level of confidence with a threshold value (which may be termed an ‘autonomy level’ or ‘autonomy value’ for example) of the CCL, identifying when to trigger an escalation to an escalation recipient.

The level of autonomy of the CCL, using a threshold value, is the degree to which the CCL independently executes decisions, or it escalates them. The level of autonomy may be flexibly configurable by an MnS consumer (e.g., 401) by configuring a threshold (e.g., a threshold value) for the CCL. The autonomy level of the CCL (i.e., the threshold value) may be configured based on at least one of: a sensitivity of the operations under control of the CCL, a trust level of the decisions, or a consideration of a larger (or improved) overview of network states (which may not be achieved with the CCL alone).

The escalation recipient is an entity that may have at least one of the following: a wider overview of network states, able to execute a different set of actions, or has better capabilities (e.g., a larger and more capable machine learning (ML) model).

CCLs may have decisions in different contexts of the network (e.g., different states, status, conditions, etc. of the network). However, all decisions made by the CCL may not be equally effective. Different decisions derived by the CLL will have different levels of confidence (or certainty). In situations wherein a level of uncertainty is high (or a level of confidence is low) for a decision, the CCL may determine to escalate decision making for the decision to another entity.

There may not be a single defined point at which the CCL may trigger escalation. Instead, the point of triggering escalation may be configured depending on the nature of the CCL and the criticality of its decisions.

Accordingly, different CCLs may have different levels to which they are autonomous on their decision-making with the level of autonomy configured by an external entity, e.g., an operator, MnS consumer, etc. In some examples, the autonomy level (e.g., a threshold, or threshold value) is a scalar index. For example, a value between 0 and 100. In such an example, the highest value (i.e. , 100) indicates no autonomy and that each decision is to be escalated. The lowest value (i.e., 0) indicates complete autonomy whereby the CCL executes all decisions without consulting or escalating to any other entity. In other examples, the lowest value (i.e., 0) indicates no autonomy, and vice versa.

The level of autonomy of the CCL enables the CCL to autonomously make decisions for each network context based on a level of confidence of the decision in the CCL, in a given situation. For example, for a decision, the CCL obtains a level of confidence (e.g., calculates the level). Then, the CCL compares that level of confidence with a threshold that has been configured for the CCL. The threshold is indicative of an autonomy level. When the level of confidence indicates a lower confidence than the threshold then the decision is escalated. When the level of confidence is higher than the threshold, the decision is executed (by the entity providing the CCL) since the CCL is confident that the decision has a high chance of achieving a suitable outcome in that situation.

In some examples, the level of confidence and the threshold are each numerical values. For example, scalar values between 0 and 100. The value associated with the level of confidence is then able to be compared to the value associated with the threshold. When the value associated with the level of confidence is lower than the value associated with the threshold, then the decision is escalated.

In some examples, the level of confidence and the threshold are discrete values. For example, ‘LOW, ‘MEDIUM’, ‘HIGH’. For example, if the threshold is associated with ‘MEDIUM’, then a decision would be escalated when the level of confidence was ‘LOW. In some examples, a CCL will be configured to escalate a decision when the level of confidence is less than or equal to the threshold. For example, if the threshold is associated with ‘MEDIUM’, then a decision would be escalated when the level of confidence was also ‘MEDIUM.

It should be understood that any suitable value such as numerical, discrete, etc. may be configured for the level of confidence and threshold.

FIG. 5 shows another schematic representation of a system for triggering an escalation of a decision in a closed control loop.

As shown in FIG. 5, there is an MnS consumer 501 which is able to communicate with a CCL 503. The CCL 503 is associated with (or acting as) an MnS producer 505. The CCL 503 is configured with/has functionality related to escalation evaluation (herein referred to as ‘escalation evaluation functionality’). The MnS consumer 501 configures a threshold (e.g., an autonomy level) and at least one escalation recipient for the CCL 503 (as MnS producer 505). This is indicated with label ‘1’ in FIG. 5.

For a decision related to a network state, the CCL 503 obtains a level of confidence for the decision. The CCL 503 compares the level of confidence to the threshold. This is indicated with label ‘2’ in FIG. 5.

When the level of confidence is indicative of a lower (or equal in some example) confidence than the threshold, then the decision is escalated. The CCL 503 provides a request (or requests) for escalation of the decision to an escalation recipient (or recipients). This is indicated with label ‘3’ in FIG. 5. As the CCL 503 is requesting escalation of the decision, it may be considered to be an MnS consumer (when making the request).

Once the request for escalation of the decision has been sent, the CCL 503 may provide a report to the MnS consumer 501. The report may comprise an indication that the decision has been escalated. This is indicated with label ‘4’ in FIG. 5.

This is described in more detail in the flow diagram of FIG. 6 as described below.

FIG. 6 shows an example flow diagram for triggering an escalation of a decision in a closed control loop.

At S601 , a CCL is initialised and/or configured. In some examples, an apparatus (e.g., a network entity) comprises the CCL. For example, the apparatus is configured with the CCL. The apparatus that is configured with the CCL, is then able to run/execute the CCL. Stated differently, the CCL is executed by the apparatus. The apparatus may be a network node or network entity.

At S602, the CCL monitors a context for a network (herein referred to as a ‘network context’).

At S603, it is determined whether there is a decision of the CCL. The decision may be related to the network context.

When ‘YES’, the flow proceeds to S604. When ‘NO’, the flow loops back to S602.

At S604, a level of confidence is obtained for the decision.

In some examples, the obtaining comprises: calculating the level of confidence (e.g., calculated by the apparatus). Any suitable method for calculating the level of confidence may be used. Information related to the decision may be used to calculate the level of confidence.

In some examples, the obtaining comprises: receiving the level of confidence (e.g., receiving from an MnS consumer, or other network entity).

In some examples, the obtaining comprises: obtaining a pre-configured level of confidence for the network context that is being monitored, based on the monitored situation.

At S605, the level of confidence is compared to the threshold. When the level of confidence is indicative of a lower (or equal, in some examples) confidence compared to the threshold then the flow proceeds to S606. When the level of confidence is indicative of a higher (or equal, in some examples) confidence compared to the threshold then the flow proceeds to S607.

At S606, the apparatus, for the COL, provides a request to escalate the decision to an escalation recipient (e.g., another CCL, an Al function, etc.). The request may comprise information related to the decision. The information related to the decision may comprise at least one of: information related to a further decision that was determined previously for the CCL, constraints associated with the CCL, preferences associated with the decision, at least one action associated with the decision, an attribute comprising a description of a reason related to the escalation.

At S607, the CCL executes the decision (without an escalation).

At S608, the CCL sends a report. The report may be related to the decision, or related to the CCL (e.g., a status of the CCL). The report may be sent to an MnS consumer (e.g., an operator that configured the threshold for the CCL).

When the CCL performs an action or executes a decision, the report is sent (e.g., to the MnS consumer). The MnS consumer may be a consumer of the service which may also be an operator that manages the network. The report may comprise high-level information on the state of the CCL with respect to a goal. For example, the report may indicate: “I executed an action and achieved the goal”, or “I cannot fulfill the goal”. When the CCL performs S606, the trigger escalation, the report may comprise “I triggered an escalation” (or similar). Stated differently, the report functions as a way for the network operator to know what network elements (e.g., CCLs) are doing.

An escalation recipient (e.g., another CCL) may have a decision-making entity (DME). There may be a mapping between a decision point (DP) and choices of the decision (e.g., action set, or outcome set) of the DME. A DP is described in more detail below.

A DME may be exposed to multiple network states, have one or more targets, and have multiple candidate decisions/actions for each DP. In this respect, a DP is a specific combination of a state and one or more target(s) for the DME. A state is a particular situation that is often defined by a set of features. Thus, based on the features’ data type (numerical or categorical), the state set of a DME may be finite or infinite. Equally, if necessary, an infinite set of states may be quantized to form a finite set of states.

A DP is referred to a state/situation that encapsulates all or part of the circumstances that may impact the decision and/or triggering the need for decision. For example, a DP may be modelled by two sets of features (e.g., state set and target set, as described below) based on the type of their impact. In examples, a DP is abstracted when needed by a timestamp. 1. State set 1 = { , i₂, ..., i_z}: This set refers to all features that represent the state/situation of the DME in a specific network context at a given time. Stated differently, the state set provides a sense of performance state for DME that may reflect the indirect impact of the other entities in the system. Note that the performance state need not to be a finite set but needs to be represented by a finite set of features.

2. Target set K = {k_±, k₂, k_m . This set refers to all features that indicate a preferred direction for making a decision at this particular point.

A DP may also be related to a goal(s) or targets of the DME. The goal(s) of a DME may also be represented by a set of features. The goal feature set may or may not create a finite set of possibilities for goals based on the feature’s possible values.

A DME is generally responsible for assessment of a situation/decision and making an appropriate decision based on the DME’s interpretation of the situation and the targets and contexts for which it is designed and responsible for. In general, the DME may have a finite set of actions (or outcomes) A = (a,, a₂, a_n from which the DME may choose from. For any such action that is selected by the DME, the DME may not be 100% sure of its decision. Even under the assumption of access to perfect input data and measurements, the DME cannot have been exposed to all the possible scenarios that the DME may experience during its life cycle. Therefore, the DME is choosing between options with a level of uncertainty. The DME may be sure or unsure of its decisions based on at least one of: the situation it is in, its assessment of this situation, and its capabilities in this situation. Therefore, the level of confidence / level of uncertainty can be evaluated per DP.

A level of uncertainty (herein the ‘uncertainty level’) is a measure dependent on the available actions/options of DME, and may change from one DP to another. An aggregate uncertainty may be determined for a complete set of DPs of the DME. Accordingly, an MnS producer associated with the DME may expose capabilities to configure or provide information about the DME’s uncertainty level(s).

To calculate the uncertainty level of a DME, the probability of each action being taken in the particular DP in the DME’s action set may be determined (or calculated). These probabilities form a probability distribution of the action set of the DME. This probability distribution P(A, I, K) shows the probability of the DME being in favor of each of the actions in the action set. At DP t₀ where I = I_o, K = K_o , it is the P(A, l₀, K_n) that plays a role in the uncertainty level calculation.

Given the above data and/or information, the DME may calculate the uncertainty level at the given DP using a Shannon entropy of the probability distribution of the DME at that DP.

In communication systems and information theory, the Shannon entropy of a probability distribution may be used in both data compression and channel capacity. The Shannon entropy of a probability distribution, in general, may be interpreted as the level of uncertainty for a given probability distribution. For instance, the entropy of the uniform probability distribution of action set with cardinality of n actions have the maximum entropy, logn bits, compared to any other distribution. In the uniform distribution, it may be harder to guess which action will be selected or which action is the best decision. On the other hand, when one action has probability value of 1 and others 0, the entropy value is 0 regardless of the cardinality of the set. This would mean that there is no doubt which action to choose. In communication systems, Shannon entropy may be calculated for any probability distribution, P, and is represented as H(P), where H represents the Shannon entropy for probability distribution P. Therefore, based on the above interpretation, the uncertainty level (referred to as H in the following equations) fora DI E at DP t₀ (i.e., 1 = I_o and K = K_o~) may be calculated by the following:

The base of the log may determine the unit for the uncertainty value. One of the characteristics of Shannon entropy is that the larger the cardinality of the action set, the higher the chances of having more uncertainty. To make different uncertainty values comparable and fix their range, the normalized value of the above may be selected to represent the DME’s uncertainty level in making decisions.

The above equation results in the values falling between 0 and 1 , and also makes the metric unitless. Thus, the DME’s uncertainty level may be evaluated by calculating the above value and may be standardized as is. In other examples, the metric may be converted to a percentage by multiplying by 100, to give a value within [0, 100], According to this measure, 0 will indicate no doubt in decision making and 1 (or 100) is an indication of utter uncertainty. In some examples, the values may be rounded to integers when they range between 0 to 100.

There is a difference in the probability values of the action set and the uncertainty value/level. The probability of one action provides an isolated understanding of an action’s usefulness at a DP whereas the uncertainty value/level provides a comparative view among actions. Simply put, knowing the probability of most probable action does not provide the same information as the uncertainty value/level. However, the higher the probability of the most probable action, the lower the uncertainty value will be. In order to calculate the confidence (or certainty) of a decision the uncertainty value may be subtracted from 1 or 100 based on the scale.

An (instantaneous) uncertainty value may be aggregated to present the performance of the DME over a given time period. If it is assumed that instantaneous uncertainty values in a time frame are (h_lr h₂, ..., h_s}. The uncertainty may be aggregated using any suitable method. For example,

Determine a moving average of the uncertainty values. This aggregation provides a view on the average latest given values:

Or equivalently, knowing the H_ag (wherein H_ag is the aggregated uncertainty) at time t Ha_g) , upon calculation of another instantaneous uncertainty of h_s+1 (i.e. at time t + 1) calculation the aggregated uncertainty may be updated using the bellow formula:

- The three main Quartiles (Q1, Q2, Q3) of the uncertainty values. The quartiles may provide a sense of an overall distribution of values with Q2 value representing the median (i.e. half of the values in the given time frame are less than Q2). To calculate the quartiles, the uncertainty values is to be sorted first. In the following, the sorted values for the terms are referred to (i.e., sorting has already been performed). Thus, the quartiles may be calculated as follows:

3

03: H_aa = - (s + l)^tlzterm

Q2: H_ag = H - H

Probabilities that are determined in by a network function (e.g., a user-centric cell-free (UCCF) function) may, for example, be implemented using any of the following methods. It should be understood that a UCCF function is merely an example of a function that may be a DME.

In some examples, a method for determining probabilities includes: using a softmax layer as a final layer for neural network classification models. A softmax function converts a vector of K real numbers into a probability distribution of K possible outcomes. The softmax function is often used as the last activation function of a neural network to normalize the output of a network to a probability distribution over predicted output classes, based on Luce's choice axiom. For example, there may be a classifier that determines whether an action to be chosen should be A or B. When a softmax function is implemented as a final layer, instead of a ‘yes’ or ‘no’ answer to A or B, there will be a x% A and 1-x% B (e.g., 20% A, 80% B). In some examples, when a DME is implemented by a classification model using neural networks such that the ML model will provide the best option as its output, the ML model may be modified by adding a softmax function as the last layer. The softmax function generates a probability for the different classes (or options, e.g., actions associated with a decision). This approach may be applicable when a target set and a state set are both present in the input of the model or actions of the DME are not impacted by any targets.

In some examples, a method for determining probabilities includes: using a utility function. When a DME is modelled using reinforcement learning models or any ML model that uses a utility function, the probabilities may be calculated using a ratio of utility function for each option (e.g., action) to the sum of all utility values of the actions. The ML model may consume the state information as well as any targets.

In some examples, a method for determine probabilities includes: training an Al (or ML) model for purpose of determining probabilities. The probabilities may be calculated independent of other capabilities of the DME by training an Al model with the state and target feature set as input, and the probabilities of the action set as the output. The probabilities that are determined may reflect the doubt/uncertainty of an operator when making a decision in similar situations.

An escalation recipient will now be described in more detail. An apparatus may be configured as an escalation recipient. An apparatus may provide an escalation recipient. In some examples, the apparatus may be a network entity.

An entity receiving a request for escalation of a decision (the ‘escalation recipient’) (e.g., a CCL) may be assumed to have better capabilities than the COL that escalated the decision. For example, the escalation recipient may have a wider scope compared to the escalation function. The escalation recipient may have executed a different and/or larger set of actions than the escalation function. The escalation recipient may have a larger or capable ML model compared to the escalator function.

FIG. 7 shows a schematic representation of a system for resolving an escalation request of a decision in a closed control loop.

As seen in FIG. 7, there is an MnS consumer 701 and a first CCL 703 (herein ‘CCL1’). CCL1 703 is associated with the MnS consumer 701. The CCL1 703 may be considered to be an MnS consumer. CCL1 703 monitors network resources 705, whereby CCL1 703 is able to communicate with the network resources 705. CCL1 703 may be termed an ‘escalator function’ or an ‘escalator CCL’. In other examples, any other suitable name may be used.

CCL1 703 is also able to communicate with an escalation recipient 707. In this example, the escalation recipient is another CCL (‘CCL2’). In other examples, the escalation recipient 707 may be an entity configured with an Al or ML model.

The MnS consumer 701, CCL1 703, and CCL2 707 may each be provided by a network entity. The MnS consumer 701 , CCL1 703, and CCL2 707, may each be provided by different network entities in some examples. In other examples, the same network entity may provide one or more of the MnS consumer 701 , the CCL1 703, and the CCL2 707.

The CCL1 703 performs monitoring of the network resources 405 and will make decisions. The monitoring of the network resources 405 is an example of monitoring a state of a network (herein ‘a network state’). For each decision, CCL1 403 determines whether to escalate the decision to another entity based on a level of confidence that the CCL1 403 has for the decision (as indicated by label ‘0’ in FIG. 7).

When the CCL1 703 determines to escalate the decision, the CCL1 703 provides a request to CCL2 707 (as indicated by label T in FIG. 7).

CCL2 707 receives, from CCL1 703, the request for an escalation of the decision related to the network context. The CCL2 707 determines, based on the request, at least one outcome for the decision (as indicated by label ‘2’ in FIG. 7). The at least one outcome may be considered to be information that is actionable by CCL1 (e.g., an action to be performed for the decision).

The CCL2 707 then provides (or sends), to CCL1 703, the at least one outcome for the decision. In some examples, the CCL2 707 provides, to CCL1 703, a report (or message) comprising the at least one outcome for the decision. In other examples, the at least outcome is indicated to CCL1 (by CCL2) in any suitable way.

In some examples, the CCL1 703 provides information related to the decision to CCL2 707 when providing the request. In some examples, the CCL2 707 obtains further information that may be used for determining the outcome for the decision. CCL2 707 may use at least one of the information, or the further information to determine the outcome.

In this manner, as shown in the system of FIG. 7, there may be a request for a decision escalation, wherein information that shall be provided for this escalation request. Then there is a resolving of the escalated decision (by the escalation recipient) using the information received in escalation request. The escalating CCL (e.g., CCL1 703) is then informed of an outcome (e.g., attribute ‘escalationOutcome’) and may include information that indicates a next step for the escalating CCL. Following this, the escalating CCL (e.g., CCL1 703) or escalation recipient (e.g., CCL2 707) takes the recommended action and moves to the next step. A request for escalation (herein called ‘escalation request’) may be defined that comprises at least one of: escalationinformation, escalationType and escalationconstraint as attributes. The attributes indicate preference(s) of the escalating CCL for its actions together with the actions information, the level of revealed information on the actions, and the constraints for the actions, respectively.

An outcome of the escalation (herein called ‘escalationOutcome’) may be defined and used as a means to inform the escalating function how to proceed, how the escalation been resolved and comprise information of a recommended action that has been derived by the escalation recipient based on the information in escalation request.

This is described in more detail below.

FIG. 8 shows another schematic representation of a system for resolving an escalation request of a decision in a closed control loop.

As shown in FIG. 8, there is a CCL 801 (which may be an MnS consumer) which is able to communicate with a further CCL 803. The further CCL 803 may be an MnS producer 805. The further CCL 803 is configured with/has functionality related to escalation resolution (herein referred to as ‘escalation resolution functionality’).

For the system of FIG. 8, at least one of the following may be supported:

REQ-CCL-ESC-RES-1: A 3GPP management system (or a CCL MnS producer acting as an escalation recipient CCL, e.g., further CCL 803 / MnS producer 805) has a capability enabling an authorized MnS consumer (e.g., an escalation function) to request escalation of a decision or escalation of decision-making for a given network context (or network state) to the CCL associated with the CCL MnS producer.

REQ-CCL-ESC-RES-2'. A 3GPP management system (or a CCL MnS producer e.g., further CCL 803 / MnS producer 805) has a capability enabling an MnS consumer to provide information related to previous decisions, decision constraints, preferences, to be used as input in resolving an escalation sent towards the CCL associated with the CCL MnS producer.

REQ-CCL-ESC-RES-3’. An CCL MnS producer (acting as an escalation recipient CCL. e.g., further CCL 803 / MnS producer 805) has the capability, to provide to an authorized MnS consumer (e.g., an escalation function), a report that comprises the outcome(s) that the CCL (acting as an escalation recipient) has derived for a given escalation request.

In the system of FIG. 8, the CCL 801 (e.g., as MnS consumer), provides a request for escalation of a decision (e.g., referred to as ‘an escalation request’) to the further CCL 803 (as indicated by label ‘0’ in FIG. 8). The further CCL 803 is considered an escalation recipient (e.g., as MnS producer). The escalation request may comprise at least one of: escalationinformation, escalationType and escalationconstraint attributes. These are described below. In response to receiving the escalation request, the further CCL 803 requests data from one or more entities. As the further CCL 803 is requesting data from other entities, the further CCL 803 may be considered to be an MnS consumer (when making the request). The requested data may be relevant to the decision, or other decisions that are associated with the decision (as indicated by label T in FIG. 8).

The further CCL 803 obtains decisions from other CCLs. The decisions obtained from other CCLs may be relevant to the decision, or other decisions that are associated with the decision (as indicated by label ‘2’ in FIG. 8).

The further CCL 803 determines (or derives) at least one outcome for the decision (that has been escalated). The further CCL 803 may determine the at least one outcome based on at least one of: the escalation request, the decisions from the other CCLs, an algorithm associated with the escalation recipient, preferences of the escalator function, or constraints of the escalator function (as indicated by label ‘3’ in FIG. 8).

The further CCL 803 provides a report (or message, or notification, etc.) to the escalation function (CCL 801) comprising the at least one outcome. The at least one outcome is provided to CCL 801 in any suitable manner by the further CCL 803. The at least one outcome may comprise the attribute escalationoutcome (as indicated by label ‘4’ in FIG. 8).

In some examples, the at least one outcome will be associated with the further CCL 803 performing an action. In these examples, the further CCL 803 will perform an action for the decision based on the at least one outcome (as indicated by label ‘5’ in FIG. 8).

In some examples, the at least one outcome will be associated with the CCL 801 of the escalation function performing an action. In these examples, the further CCL 803 will request for the escalation function to perform an action based on the at least one outcome (as indicated by label ‘6’ in FIG. 8).

An escalation may be accomplished by providing a message requesting to escalate a decision. In some examples, this may comprise instantiating an object (named, for example, escalationRequest) on to the CCL to which the decision is being escalated. This object comprises information for requesting an escalation of decision responsibility by the CCL with the escalation function.

The escalation request is provided to the escalation recipient configured in the escalating CCL attributes (e.g., escalationRecipient). To utilise the information, preferences and constraints of the escalation function, the request may include information related to preferences and constraints of the escalation function. A context of the situation, in terms of confidence of the escalating CCL may be expressed further by a probabilities of each of a plurality of candidate actions (or decisions for the decision). When a probability distribution is closer to ‘even’, this indicates a ‘harder’ decision for the escalation function. The probabilities may also indicate the preference of the CCL towards the decisions. These probabilities may be comprised in an escalationinformation attribute. In other examples, the escalationinformation attribute has any other suitable name.

The escalationinformation attribute may include different levels of expression. For example, a first level (herein a ‘masked level’) includes the probability distribution, a second level (herein the ‘semi-masked level’) includes partial information about the decisions such as parameters, and a third level (herein the ‘unmasked level’) includes full expression of the decisions together with their respective probability. The expression type may be indicated via an informationType attribute. In other examples, the informationType attribute has any other suitable name.

The constraints of an escalation recipient in making decisions may be expressed in an attribute, called escalationconstraints. The constraints may be related to an execution limitation of the CCL, or a dynamic constraint resulting from a particular situation that is to be expressed to the escalation recipient. In this manner, the constraints are constraints from the escalating CCL. The constraints may be constraints that meant that the CCL could not make a decision by itself. In other examples, the escalationconstraints attribute has any other suitable name.

An attribute, named escalationReason, may provide a description of a reason related to the escalation. The reason may provide more context and further clarification for the escalation recipient. In other examples, the escalationReason attribute has any other suitable name.

The corresponding definition of the attributes and their properties is shown in Table 1 below:

Table 1: Attributes for a request for escalation of a decision, with the properties associated with each attribute.

Outcomes determined (or derived) by the escalation recipient may be communicated to the escalating CCL via a data structure (or data type) (or attribute). The data structure may be named, for example, escalationoutcome, escalationoutcome may includes information that facilitates a next step for the escalating function to perform.

An attribute named escalationstatus (e.g., that is part of the escalationoutcome data structure) identifies a type of action the escalating CCL is to perform as a result of the determination by the escalation recipient. The value of the escalationstatus attribute may represents one of the following examples, i) value = 1, proceed as determined by escalating CCL itself, ii) value = 2, proceed with the execution of the specified action in the attribute escalationDecision, iii) value = 3, no action to perform and proceed to the next stage (i.e., further monitoring, e.g., loop back to S602 of FIG. 6). When the value = 3, the escalation recipient makes and execute the decision on the escalating CCL's behalf. For example, when the value of escalationstatus = T, then the escalating CCL may perform an action associated the highest probability that the escalating CCL determined before the escalating CCL requested the escalation.

The escalationDecision may be expressed via a recommendedAction data structure (also referred to as a data type) that is already available in the 3GPP MDA specifications. The recommendedAction data structure may be amended to include the escalationDecision attribute, as shown in Table 2 below:

Table 2: A recommendedAction data structure comprising attributes, wherein T = true and F

= false.

The constraint for the escalationDecision attribute may be defined as follows, in Table 3:

Table 3: escalationDecision attribute and its accompanying definition Definitions of some of the attributes described above alongside their properties are shown below in Table 4:

Table 4: List of attribute names with respective descriptions and properties for each attribute.

An escalation recipient, as discussed above, may have more information, a wider scope, or a more advanced capability of utilising more information that eventually enables the escalation recipient to make ‘better’ and ‘more suitable’ decisions. This will now be described in more detail alongside examples for each of these cases.

In some examples, the escalation recipient has access to additional information, compared to the entity escalating the decision, that is utilised in orderto determine an outcome for the decision. The escalation recipient may be a CCL that uses more information (than the entity escalating the decision) to make decisions, and is therefore capable of making better decisions. For example, the escalating CCL may be making its decisions based on information (or observations) of x and y, whereas the escalation recipient is able make decisions based on x, y, z, v and w. As the escalation recipient is capable of additionally utilising (z, v, w), the escalation recipient requests additional data and information (e.g., from other CCLs). This additional information (i . e. , z, v and w) increases the possibility of a better (or more accurate) decision being determined. In this context, a ‘better’ decision is a decision that enables the CCL/system to move closer towards a goal or target. The closer the decision moves the CCL/system towards the goal or target, the better it is.

However, the more information that is involved in making a decision, there may be a greater the number of potential solutions that are found that fit the goal/target of the CCL. Inclusion of any preferences/constraints introduced as escalationinformation facilitates a more efficient decision making, by considering the observations and preferences of the entity escalating the decision.

For example, there is an entity escalating a decision for a CCL, wherein the entity provides "(0.4, A), (0.3, B), (0.3, C)" as escalationinformation to an escalation recipient. Here, ‘A’, ‘B’, and ‘C’ are each representing different actions related to the decision at the (escalating) CCL. Action A is preferred as it has the highest associated value/probability. However, the higher probability of action A is by a small margin compared to actions B and C. The escalation recipient may have one of the following configurations: i) the escalation recipient is capable of choosing between the same actions A, B, C (only), or ii) the escalation recipient is capable of computing and assessing complementary decisions to A, B, C. For configuration i), the escalation recipient may decide that action B is the most desirable action when it takes into account the additional information from z, v, and w. This additional information together with the small difference in the probability distribution from escalating entity (0.4 for A compared to 0.3 for B), results in a confident decision from the escalation recipient in choosing action B and informing the escalating entity through updating the escalationOutcome with values of 2, and B for escalationstatus and escalationDecision respectively. Stated differently, escalationstatus - 2 which means that the escalating CCL should proceed with a 'specified action’, and escalationDecision - B, which means that the ‘specified action’ is action B.

For configuration ii), the escalation recipient may, based on the information from v, w, z, determine that there is an alternative action D that is more suitable. For example, action D would progress the system towards a goal faster and more efficiently. Therefore, the escalation recipient updates the escalationOutcome with values of 3, and D for escalationstatus and escalationDecision respectively. Stated differently, escalationstatus = 3 which means that there is no action for the escalating CCL to perform, and escalationDecision = D, which means that the ‘specified action’ is action D. In some examples, to keep the action D secret from the escalating CCL, the escalation recipient may indicate that the action was not among the escalating CCL’s suggested actions (e.g., escalationDecision = N/A, which indicates that the action was not from the list of actions provided by the escalating CCL).

In some examples, the escalation recipient has a wider scope compared to the entity escalating the decision. In this context, a wider scope may mean that the escalation recipient has access to information from more CCLs (e.g., a plurality of CCLs) than the escalating CCL does. The escalation recipient may be able to receive escalations from several escalating CCLs. Therefore, escalation recipient may request escalation information from the CCLs or use previous historical escalation information. In this manner, it may be assumed that the escalation recipient has a wider scope compared to the escalating CCL even if the escalation recipient does not have any complex analysis capability. The escalation recipient is able to make more informed decisions based on the collective information from the escalating CCLs. For example, three different CCLs may request escalation (CCL1 , CCL2, CCL3). The request from CCL1 comprises "(0.3, A), (0.4, B), (0.3, C)", the request from CCL2 comprises "(0.6, A), (0.4, H)" and the request from CCL3 comprises "(0.3, A), (0.1 , B), (0.6, F)", for the escalationinformation. In this example, a priority value (or weighting value) is provided for the CCLs (CCL1 , CCL2, and CCL3) based on observations of their performance. In other examples, there may be alternative or additional policies for the CCLs, such as consensus on decision. The inclusion of these capabilities may be left to implementation choices. In this example, the priority values for CCL1 , CCL2, CCL3 are 0.2, 0.6. 0.2 respectively. The escalation recipient then follows at least one of the following: - Determine the action with highest probability in each COL based on the received information (i.e., (0.4, B) for CCL1 , (0.6, A) for CCL2, (0.6, F) for CCL3).

- Multiply the probability of each CL with the respective priority value (i.e., (0.4*0.2 = 0.08, B) for CCL1, (0.6*0.6 = 0.36, A) for CCL2, (0.6*0.2 = 0.12, F) for CCL3).

- Unify the calculated values so that they sum up to 1. In examples, the unifying comprises: dividing the values by the sum of all values. The resulting values form a ‘new’ probability distribution (i.e., 0.14, 0.64, 0.22 respectively for actions B, A and F). The actions with the highest probability is selected. This leads to the selection of action A (0.64 probability).

The escalation recipient may then provide an escalationoutcome attribute to each of the three escalating CCLs (i.e., CCL1, CCL2, CCL3) as follows, wherein each escalationoutcome is formatted to comprise {escalationstatus, escalationDecision}. The escalationoutcome for CCL1 = {3, A}, the escalationoutcome for CCL2 = {1 , A}, and the escalationoutcome for CCL3 = {3, A}. Here, CCL2 is the (only) one of the three escalating CCLs to be instructed to proceed as per the calculated probabilities comprised in the respective request (i.e., escalationoutcome comprises a value of 1 for escalationstatus') because CCL2 was the (only) one of three escalating CCLs to indicate action A as the highest probability in the request.

In some examples, the escalation recipient has more capability compared to the entity escalating the decision. The escalation recipient may have more resources available to use to make decision, be using more advanced technology, or be using more advanced methods to make decisions. For example, the escalation recipient may be using the same information (e.g., x and y) but also be using a trained Al or ML model (instead of instead of simple statistics).

In some examples, an escalation recipient has at least two of: access to additional information, a wider scope, or more capability.

One or more of the examples discussed above have the advantage that decisions in a CCL are determined more accurately and efficiently. For example, when confidence on a suitable decision for a CCL is too low (i.e., below a threshold), then a more capable entity is utilised to determine an outcome for the decision. Decisions that have a high degree of confidence may be determined by the entity executing the CCL, which allows for quick determinations of outcomes. Decisions with a low degree of confidence are escalated, which even though this may increase the latency of the decision, will mean that a more accurate or suitable outcome is determined. This is because the escalating recipient may have access to additional information, have a wider scope, or more capability.

The entity executing the CCL is configurable such that the autonomy level of the entity is flexible, dependent on the CCL that is being implemented or the criticality of the network state being monitored. This has the advantage of greater flexibility in the system. For example, for a CCL monitoring highly important data, the threshold may be configured such that the autonomy level is low. This means that when the confidence level of a decision is low, then the decision will likely be escalated. As this data is of high importance, it may be important that a correct/accurate outcome for the decision is determined. When a CCL is monitoring less important data, then the threshold may be configured such that the autonomy level is high. A high autonomy level will lead to reduced latency and reduced resource usage (i.e., less use of an escalation recipient).

FIG. 9 shows an example method flow performed by an apparatus. The apparatus may be a network entity or network node. The apparatus may be configured for executing a closed control loop (CCL). The apparatus may comprise one or more means for performing the methods of FIG. 9. For examples, the means may comprise at least one processor, and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to perform the methods of FIG. 9. In other examples, any other suitable means performs the methods.

In S901 , the method comprises: obtaining, for a closed control loop, a level of confidence for a decision related to a network context.

In S903, the method comprises: comparing the level of confidence to a threshold.

In S905, the method comprises: based on the comparing, providing, to a first network entity, a request for an escalation of the decision.

In S907, the method comprises: receiving, from the first network entity, a report comprising at least one outcome for the decision that the first network entity has determined.

In some examples, S901 , S903, S905 and S907 are all associated with the execution of the closed control loop by the apparatus.

It should be understood that, in some examples, one or more additional method steps are included in the method flow of FIG. 9 and are performed by the apparatus. In some examples, one or more of the method steps of FIG. 9 detailed above may not be performed, or may be performed in a different order.

FIG. 10 shows an example method flow performed by an apparatus. The apparatus may be a network entity or network node. The apparatus may comprise one or more means for performing the methods of FIG. 10. For examples, the means may comprise at least one processor, and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to perform the methods of FIG. 10. In other examples, any other suitable means performs the methods.

In S1001 , the method comprises receiving, from a second network entity, a request for an escalation of a decision related to a network context.

In S1003, the method comprises determining, based on the request, at least one outcome for the decision. In S1005, the method comprises providing, to the second network entity, a report comprising the at least one outcome for the decision.

It should be understood that, in some examples, one or more additional method steps are included in the method flow of FIG. 10 and are performed by the apparatus. In some examples, one or more of the method steps of FIG. 10 detailed above may not be performed, or may be performed in a different order.

FIG. 11 shows a schematic representation of non-volatile memory media 1100a (e.g. Blu-ray disc (BD), computer disc (CD) or digital versatile disc (DVD)) and 1100b (e.g. flash memory, solid state memory, universal serial bus (USB) memory stick) storing instructions and/or parameters 1102 which when executed by a processor allow the processor to perform one or more of the steps of the methods of FIGS. 10 to 11.

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.

The examples may thus vary within the scope of the attached claims. In general, some embodiments may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device, although embodiments are not limited thereto. While various embodiments may be illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as nonlimiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

The examples 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 may represent program steps, or interconnected logic circuits, blocks and functions, or a combination of program steps and logic circuits, blocks and functions. The software may be stored on such physical media as memory chips, or memory blocks implemented within the processor, magnetic media such as hard disk or floppy disks, and optical media such as for example DVD and the data variants thereof, CD.

The term “non-transitory”, as used herein, is a limitation of the medium itself (i.e. tangible, not a signal) as opposed to a limitation on data storage persistency (e.g. RAM vs ROM).

As used herein, “at least one of the following:<a list of two or more elements>” and “at least one of: <a list of two or more elements>” and similar wording, where the list of two or more elements are joined by “and”, or “or”, mean at least any one of the elements, or at least any two or more of the elements, or at least all of the elements.

The memory may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The data processors may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASIC), gate level circuits and processors based on multi core processor architecture, as non-limiting examples.

As used herein, the terms “means for”, “means for performing operations including”, “means configured to perform operations including”, or “means configured to perform” (or similar) may be any means that are suitable for performing the feature(s). The “means” may be configured to perform one or more of the functions and/or method steps previously described. For example, the “means” may include one or more of: at least one processor, at least one memory, transceiver circuitry, antenna circuitry, etc. It should be understood that these are provided as non-limiting examples.

Alternatively, or additionally some examples 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.

As used in this application, the term “circuitry” may refer to one or more or all of the following:

(a) hardware-only circuit implementations (such as implementations in only analogue and/or digital circuitry);

(b) combinations of hardware circuits and software, such as:

(i) a combination of analogue and/or digital hardware circuit(s) with software/firmware and

(ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as the communications device or base station to perform the various functions previously described; and

(c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.

This definition of circuitry applies to uses of the term “means” in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware. The term circuitry also covers, for example integrated device. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in a server, a cellular network device, or other computing or network device.

The foregoing description has provided by way of exemplary and non-limiting examples a full and informative description of some embodiments. However, various modifications and adaptations may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings and the appended claims. However, all such and similar modifications of the teachings will still fall within the scope as defined in the appended claims.

Claims

Claims:

1. An apparatus comprising: means for obtaining, for a closed control loop, a level of confidence for a decision related to a network context; means for comparing the level of confidence to a threshold; means for, based on the comparing, providing, to a first network entity, a request for an escalation of the decision; and means for receiving, from the first network entity, a report comprising at least one outcome for the decision that the first network entity has determined.

2. The apparatus according to claim 1 , wherein the request comprises information related to the decision.

3. The apparatus according to claim 1 or claim 2, wherein the threshold is obtained as part of a configuration.

4. The apparatus according to claim 2, wherein the information related to the decision comprises at least one of: an action with an associated probability for the action, an indication of the type of information related to the decision, at least one constraint associated with the decision, at least one preference associated with the decision, an attribute indicating a reason related to the escalation, an identity associated with the request.

5. The apparatus according to any of claims 1 to 4, wherein the apparatus comprises: means for calculating a probability for an action for the decision, wherein the calculating is based on at least one of: the network context, and the decision.

6. The apparatus according to any of claims 1 to 5, wherein the means for obtaining the level of confidence for the decision related to the network context comprises: means for calculating the level of confidence based on the probability for the action.

7. The apparatus according to claim 2 or claim 4, wherein the information related to the decision comprises: a plurality of actions for the decision, wherein each action of the plurality of actions has an associated probability value.

8. The apparatus according to any of claims 1 to 7, wherein the at least one outcome comprises at least one of: an identity associated with the request, a status indicating how the closed control loop should proceed, or an indication of an action for the decision.

9. The apparatus according to claim 8, wherein the status comprises a value, the value of the status indicating for the closed control loop to perform one of: proceed to execute an action for the decision according to the information in the request, execute an action as identified in the at least one outcome, or refrain from performing an action.

10. The apparatus according to any of claims 1 to 9, wherein the apparatus comprises: means for, based on the at least one outcome, performing an action associated with the decision.

11 . The apparatus according to any of claims 1 to 10, wherein the apparatus is a second network entity.

12. An apparatus comprising: means for receiving, from a second network entity, a request for an escalation of a decision related to a network context; means for determining, based on the request, at least one outcome for the decision; and means for providing, to the second network entity, a report comprising the at least one outcome for the decision.

13. The apparatus according to claim 12, wherein the request comprises information related to the decision.

14. The apparatus according to claim 13, wherein the information related to the decision comprises at least one of: at least one action with an associated probability for each action, an indication of the type of information related to the decision, at least one constraint associated with the decision, at least one preference associated with the decision, an attribute indicating a reason related to the escalation, an identity associated with the request.

15. The apparatus according to claims 13 or claim 14, wherein the information related to the decision comprises: a plurality of actions for the decision, wherein each action of the plurality of actions has an associated probability value.

16. The apparatus according to any of claims 12 to 15, wherein the at least one outcome comprises at least one of: an identity associated with the request, a status indicating how the closed control loop should proceed, or an indication of an action for the decision.

17. The apparatus according to claim 16, wherein the status comprises a value, the value of the status indicating for the closed control loop to perform one of: proceed to execute an action for the decision according to the information in the request, execute an action as identified in the at least one outcome, or refrain from performing an action.

18. The apparatus according to claim 16 or claim 17, wherein the indication of the action in the report is one of: the same as an action associated with the request, or different to one or more actions indicated in the request.

19. The apparatus according to any of claims 12 to 18, wherein the apparatus comprises: means for receiving, from a third network entity, a second request for a second escalation of a second decision for a second closed control loop, wherein the second request comprises information related to the second decision, the information comprising an action with an associated probability for the action.

20. The apparatus according to claim 19, wherein the means for determining, based on the request, at least one outcome for the decision comprises: means for determining the at least one outcome for the decision based on: the request and the second request.

21 . The apparatus according to claim 19 or claim 20, wherein the means for determining the at least one outcome for the decision based on: the request and the second request comprises: means for determining the at least one outcome for the decision based on: the request, the second request, an associated priority value for the closed control loop of the request, and an associated priority value for the second closed control loop of the second request.

22. A method comprising: obtaining, for a closed control loop, a level of confidence for a decision related to a network context; comparing the level of confidence to a threshold; based on the comparing, providing, to a first network entity, a request for an escalation of the decision; and receiving, from the first network entity, a report comprising at least one outcome for the decision that the first network entity has determined.

23. A method comprising: receiving, from a second network entity, a request for an escalation of a decision related to a network context; determining, based on the request, at least one outcome for the decision; and providing, to the second network entity, a report comprising the at least one outcome for the decision.

24. A computer program comprising instructions, which when executed by an apparatus, cause the apparatus to perform at least the following: obtaining, for a closed control loop, a level of confidence for a decision related to a network context; comparing the level of confidence to a threshold; based on the comparing, providing, to a first network entity, a request for an escalation of the decision; and receiving, from the first network entity, a report comprising at least one outcome for the decision that the first network entity has determined.

25. A computer program comprising instructions, which when executed by an apparatus, cause the apparatus to perform at least the following: receiving, from a second network entity, a request for an escalation of a decision related to a network context; determining, based on the request, at least one outcome for the decision; and providing, to the second network entity, a report comprising the at least one outcome for the decision.