METHODS AND ENTITIES FOR A NETWORK

A first apparatus and a second apparatus (128) that are configured to manage or orchestrate network resources, or network services, or a machine learning model, or a composition of a machine learning model for a first stakeholder and a second stakeholder respectively, and first method comprising receiving, at the first apparatus (120), a requirement regarding a network intent, or for a network resource, or a network service, or a machine learning model, or a composition of a machine learning model, determining, at the first apparatus (120), a message regarding the requirement, sending the message to the second apparatus (128), and a second method comprising receiving, from the first apparatus (120) a first message regarding a requirement, and sending a second message regarding the requirement, to the first apparatus (120) or a first message regarding a network intent, and sending a second message regarding the network intent to the first apparatus (120).

FIELD OF THE INVENTION

The disclosure herein relates to methods and entities for a network.

BACKGROUND

In the current mobile network ecosystem there are numerous stakeholders, e.g., network operators, that offer the mobile network services.

SUMMARY

The disclosure herein relates to a multi-stakeholder concept for a network ecosystem in which numerous stakeholders, e.g., network operators, offer network resources or network services, or machine learning models, or compositions of machine learning models.

A first method comprises receiving, at a first apparatus that is configured to manage or orchestrate network resources of a first stakeholder, a requirement, determining, at the first apparatus, at least a part of the requirement that needs to be orchestrated with a second apparatus that is configured to manage or orchestrate network resources for a second stakeholder, and sending a request regarding at least a part of the requirement that needs to be orchestrated with the second apparatus to the second apparatus.

According to some examples of the first method, the requirement comprises a network intent, a network resource, a network service, a machine learning model, a composition of a machine learning model, or an information about a trust relationship between the first stakeholder and the second stakeholder.

According to some examples of the first method, the requirement comprises a machine learning model performance, or a machine learning model configuration.

According to some examples the first method comprises determining, sending, receiving, or requesting a report regarding a network resource, a service requirement, a machine learning model performance, or a machine learning model configuration.

A second method comprises receiving, from a first apparatus that is configured to manage or orchestrate network resources of a first stakeholder, at a second apparatus that is configured to manage or orchestrate network resources of a second stakeholder, a request regarding at least a part of a requirement that needs to be orchestrated with the second apparatus, determining at the second apparatus at least a part of the requirement that can be orchestrated with the second apparatus, and sending the response regarding the requirement, to the first apparatus.

According to some examples of the second method, the request comprises a network intent, a network resource, a network service, a machine learning model, a composition of a machine learning model, or an information about a trust relationship between the first stakeholder and the second stakeholder.

According to some examples of the second method, the requirement comprises a machine learning model performance or a machine learning model configuration.

According to some examples, the second method comprises receiving a request for a report regarding a network resource, a service requirement, a machine learning model performance, or a machine learning model configuration from the first apparatus, determining the report, and sending the report to the first apparatus.

According to some examples, the second the method comprises sending a request regarding at least a part of the requirement that needs to be orchestrated to an apparatus of the second stakeholder, receiving a response regarding at least a part of the requirement that needs to be orchestrated from the apparatus of the second stakeholder, and determining the response to the first apparatus depending on the response from the apparatus.

A first apparatus according to some examples comprises means for managing network resources of a first stakeholder, receiving a requirement, determining at least a part of the requirement that needs to be orchestrated with a second apparatus that is configured to manage or orchestrate network resources for a second stakeholder, and sending a request regarding at least a part of the requirement that needs to be orchestrated with the second apparatus to the second apparatus.

According to some examples of the first apparatus, the requirement comprises a network intent, a network resource, a network service, a machine learning model, a composition of a machine learning model, or an information about a trust relationship between the first stakeholder and the second stakeholder.

According to some examples of the first apparatus, the requirement comprises a machine learning model performance or a machine learning model configuration.

According to some examples, the first apparatus comprises means for determining, sending, receiving, or requesting a report regarding a network resource, a service requirement, a machine learning model performance, or a machine learning model configuration.

A second apparatus according to some examples comprises means for managing network resources of a second stakeholder, receiving a request regarding at least a part of a requirement that needs to be orchestrated with the second apparatus from a first apparatus that is configured to manage or orchestrate network resources of a first stakeholder, determining at the second apparatus at least a part of the requirement that can be orchestrated with the second apparatus, and sending the response regarding the requirement, to the first apparatus.

According to some examples of the second apparatus, the request comprises a network intent, a network resource, a network service, a machine learning model, a composition of a machine learning model, or an information about a trust relationship between the first stakeholder and the second stakeholder.

According to some examples of the second apparatus, the requirement comprises a machine learning model performance or a machine learning model.

According to some examples, the second apparatus comprises means for receiving a request for a report regarding a network resource, a service requirement, a machine learning model performance, or a machine learning model configuration from the first apparatus, and determining the report, and sending the report to the first apparatus.

According to some examples, the second apparatus comprises means for sending a request regarding at least a part of the requirement that needs to be orchestrated to an apparatus of the second stakeholder, receiving a response regarding at least a part of the requirement that needs to be orchestrated from the apparatus of the second stakeholder, and determining the response to the first apparatus depending on the response from the apparatus.

According to some examples, the means for managing network resources, determining, sending, receiving, or requesting comprise a processor a non-transitory memory.

According to some examples, a means for sending or requesting comprise a sender. According to some examples, a means for receiving comprise a receiver.

Further exemplary embodiments are derived from the following description and the drawing.

DESCRIPTION OF THE EMBODIMENTS

The framework comprises a first entity102that is configured to manage or orchestrate network resources, or network services, or a machine learning model, or a composition of a machine learning model for a first stakeholder.

The first entity102is configured in the example to manage or orchestrate a first domain of the first stakeholder104and a second domain of the first stakeholder106.

The framework comprises a second entity108that is configured to manage or orchestrate network resources, or network services, or a machine learning model, or a composition of a machine learning model for a second stakeholder.

The second entity108is configured in the example to manage or orchestrate a first domain of the second stakeholder110and a second domain of the second stakeholder112.

The first entity102comprises a cross-stakeholder intent manager114, a cross-stakeholder management and orchestrator116and a cross-stakeholder machine learning orchestrator118and a peer-to-peer orchestrator120. The peer-to-peer orchestrator120of the first entity102is an example for a first apparatus that is configured to manage or orchestrate network resources, or network services, or the machine learning model, or the composition of the machine learning model for the first stakeholder.

The second entity102comprises a cross-stakeholder intent manager122, a cross-stakeholder management and orchestrator124and a cross-stakeholder machine learning orchestrator126and a peer-to-peer orchestrator128. The peer-to-peer orchestrator128of the second entity108is an example for a second apparatus that is configured to manage or orchestrate network resources, or network services, or the machine learning model, or the composition of the machine learning model for the second stakeholder.

The cross-stakeholder intent manager114, the cross-stakeholder management and orchestrator116, and the cross-stakeholder machine learning orchestrator118of the first entity102are examples for a third apparatus that is associated with the first stakeholder. The cross-stakeholder intent manager122, the cross-stakeholder management and orchestrator124and the cross-stakeholder machine learning orchestrator126of the second entity108are examples for a third apparatus that is associated with the second stakeholder.

According to some examples, the first apparatus comprises a receiver, that is configured to receive a message.

According to some examples, the first apparatus comprises a processor that is configured to determine a message.

According to some examples, the first apparatus comprises a sender that is configured to send the received or determined message.

According to some examples, the second apparatus comprises a receiver, that is configured to receive a message.

According to some examples, the second apparatus comprises a processor that is configured to determine a message.

According to some examples, the second apparatus comprises a sender that is configured to send the received or determined message.

According to some examples, the third apparatus comprises a receiver, that is configured to receive a message.

According to some examples, the third apparatus comprises a processor that is configured to determine a message.

According to some examples, the third apparatus comprises a sender that is configured to send the received or determined message.

The cross-stakeholder intent manager114of the first entity102and the cross-stakeholder intent manager122of the second entity108are configured to communicate via the peer-to-peer orchestrator120of the first entity102and the peer-to-peer orchestrator128of the second entity108.

The cross-stakeholder management and orchestrator116of the first entity102and the cross-stakeholder management and orchestrator124of the second entity108are configured to communicate via the peer-to-peer orchestrator120of the first entity102and the peer-to-peer orchestrator128of the second entity108.

The cross-stakeholder machine learning orchestrator118of the first entity102and the cross-stakeholder machine learning orchestrator126of the second entity108are configured to communicate via the peer-to-peer orchestrator120of the first entity102and the peer-to-peer orchestrator128of the second entity108.

The peer-to-peer orchestrator120of the first entity102and the peer-to-peer orchestrator128of the second entity108are configured to connect via a peer-to-peer interface130.

The first domain of the first stakeholder104and the second domain of the first stakeholder106and the first domain of the second stakeholder110and the second domain of the second stakeholder112may comprise an intent based network that is managed by a respective intent manager132.

The first domain of the first stakeholder104may comprise a radio access network management and orchestrator134that is configured to manage and orchestrate the radio access network in the first domain of the first stakeholder104. The first domain of the first stakeholder104may comprise a machine learning orchestrator136that is configured to orchestrate i machine learning models138-1, . . . ,138-iin the first domain of the first stakeholder104.

The second domain of the first stakeholder104may comprise a core network management and orchestrator140that is configured to manage and orchestrate the core network in the second domain of the first stakeholder104. The second domain of the first stakeholder104may comprise a machine learning orchestrator142that is configured to orchestrate j machine learning models144-1, . . . ,144-jin the second domain of the first stakeholder104.

The first domain of the second stakeholder110may comprise a radio access network management and orchestrator146that is configured to manage and orchestrate the radio access network in the first domain of the second stakeholder110. The first domain of the second stakeholder110may comprise a radio access network machine learning orchestrator148that is configured to orchestrate k machine learning models150-1, . . . ,150-kin the first domain.

The second domain of the second stakeholder112may comprise a core network management and orchestrator152that is configured to manage and orchestrate the core network in the second domain of the second stakeholder112. The second domain of the second stakeholder112may comprise a core machine learning orchestrator154that is configured to orchestrate l machine learning models156-1, . . . ,156-1in the second domain of the second stakeholder112.

The number i, j, k,1of the machine learning models may be the same or different numbers of machine learning models may be provided. The machine learning models may be configured to interoperate.

The stakeholders may provide more of less domains.

The cross-stakeholder peer-to-peer management and orchestration framework is used to ensure the fulfilment of desired cross-stakeholder machine learning performance or configuration requirements, in addition to the cross-stakeholder network and service performance requirements, as indicated in the network intent.

The peer-to-peer orchestrators may provide a respective management function in the stakeholders and the peer-to-peer interface130between the respective management functions.

According to one aspect, a trust model is provided for peer-to-peer cross-stakeholder orchestration.

The trust model comprises a notion of full trust as a direct trust relationship between two stakeholders who have a bilateral service level agreement. The trust model comprises a notion of partial trust as an indirect relationship between two stakeholders when there exists a chain of intermediary stakeholders who have full trust.

According to one aspect, a measure of trust is provided. The measure of trust is referred to as attenuation of trust. The attenuation expresses the minimum number of intermediary stakeholders that are needed to achieve partial trust among two stakeholders. This means, the higher the level of attenuation, the weaker the level of trust.

According to one aspect, trust tables are provided that correspond to the trust model. The trust tables are determined via a peer-to-peer algorithms, e.g., distributed or decentralized algorithms.

According to one aspect, the trust tables are provided for use in cross-stakeholder orchestration and negotiation. The cross-stakeholder orchestration and negotiation may comprise a 1:1 or one 1:N orchestration and negotiation between network resources, network services or machine learning models.

The peer-to-peer orchestrators may support the following cross-stakeholder network resource and service related operations:Receive network resource and service requirements from the cross-stakeholder management and orchestrator.Indicate needed network resource and service requirements to the peer-to-peer orchestrator of another stakeholder.Send network resource and service requirements received by the peer-to-peer orchestrator to the cross-stakeholder management and orchestrator.Receive achievable network resource and service requirements from the cross-stakeholder management and orchestrator.Indicate achievable network resource and service requirements to the peer-to-peer orchestrator of another stakeholder.Send achievable network resource and service requirements received by the peer-to-peer orchestrator to the cross-stakeholder management and orchestrator.

The peer-to-peer orchestrators may support the following cross-stakeholder machine-learning related operations:Receive machine learning requirements, e.g., a performance and configuration, from the cross-stakeholder machine learning orchestrator.Indicate needed machine learning requirements, e.g., a performance and configuration, to the peer-to-peer orchestrator of another operator.Send machine learning requirements, e.g., a performance and configuration, received by the peer-to-peer orchestrator to the cross-stakeholder machine learning orchestrator.Receive achievable machine learning requirements, e.g., a performance and configuration, from the cross-stakeholder machine learning orchestrator.Indicate the achievable machine learning requirements, e.g., a performance and configuration, to the peer-to-peer orchestrator of another operator.Send achievable machine learning requirements, e.g., a performance and configuration, requirements received by the peer-to-peer orchestrator to the cross-stakeholder machine learning orchestrator.

The peer-to-peer orchestrators may support the following cross-stakeholder machine learning composition related operations:Receive machine learning composition requirements, e.g., performance and configuration, from the cross-stakeholder machine learning orchestrator.Indicate needed machine learning composition requirements, e.g., performance and configuration, to the peer-to-peer orchestrator of another operator.Send machine learning composition requirements, e.g., performance and configuration, received by the peer-to-peer orchestrator to the cross-stakeholder machine learning orchestrator.Receive achievable machine learning composition requirements, e.g., performance and configuration, from the cross-stakeholder machine learning orchestrator.Indicate achievable machine learning composition requirements, e.g., performance and configuration, requirements to the peer-to-peer orchestrator of the other operator.Send achievable machine learning composition requirements, e.g., performance and configuration, received by the peer-to-peer orchestrator to the cross-stakeholder machine learning orchestrator.

The peer-to-peer orchestrators may support the following cross-stakeholder reporting related operations:Receive network resource, network service and machine learning related report requests or subscriptions from the cross-stakeholder machine learning orchestrator.Indicate needed network resource, network service and machine learning related report requests or subscriptions to the peer-to-peer orchestrator of the other operator.Send network resource, network service and machine learning related report requests or subscriptions received by the peer-to-peer orchestrator to the cross-stakeholder machine learning orchestrator.Receive network resource, network service and machine learning related reports from the cross-stakeholder machine learning orchestrator.Indicate received network resource, network service and machine learning related reports to the peer-to-peer orchestrator of another operator.Send network resource, network service and machine learning related reports received by the peer-to-peer orchestrator to the cross-stakeholder machine learning orchestrator.

The peer-to-peer orchestrators may support the following cross-stakeholder security and trust related operations:Receive requests for information about trust relationships, e.g., full trust, partial trust, or a measure of trust, with other stakeholders. Such request may be a request to or a request from the peer-to-peer orchestrator of the stakeholder, to support translation of cross-stakeholder network and service requirements and cross-stakeholder machine learning and machine learning composition requirements.Send information about trust relationships, e.g., full trust, partial trust, or a measure of trust, with other stakeholders. Such request may be a request to or a request from another peer-to-peer orchestrator of another stakeholder. Such request may be sent after applying relevant stakeholder-specific policies.

In the following, sequence flow diagrams for methods are described that focus on peer-to-peer interactions between two stakeholders. In case of more than two stakeholders, the sequence of steps applies to peer-to-peer interactions between the more than two stakeholders.

FIG.2depicts a first part of an exemplary sequence flow diagram for a cross-stakeholder feasibility check.

The steps in the exemplary first part of the sequence are as follows:

Establish trust between the stakeholders.

In the example the peer-to-peer orchestrator120of the first stakeholder and the peer-to-peer orchestrator128of the stakeholder determine a respective trust table that represents its full and partial trust relationships with other stakeholders, as well as the level of this trust as embodied in the attenuation of trust measure.

The cross-stakeholder intent manager114of the first entity102receives the network intent, e.g., performance intent, from a customer.

The cross-stakeholder intent manager114of the first entity102translates the network intent into end-to-end network resource and service requirements.

For example, the attributes and their values in the following table 1 may describe the translated end-to-end network resource and service requirements:

In table 1, a service profile ID is specified. Subsequently, the number of users, coverage area and network requirements are given. The resources can optionally be requested also in terms of PRBs (physical resource blocks). The requesting operator is then proposing a price per user, or per PRB. Performance tolerance is the maximum allowed deviation from the requested performance, i.e., the throughput cannot (on average or instantaneously) be less than 2% the agreed one. In case of non fulfilment, the parties need to agree on whether there is a compensation for the non-received services. Computational resources can also be negotiated. In this case, memory and cores need to be specified. In case of need for ML support, the ML involvement flag needs to be properly activated.

The cross-stakeholder management and orchestrator116of the first entity102receives the end-to-end resource and service requirements from the cross-stakeholder intent manager114of the first entity102.

The cross-stakeholder management and orchestrator116of the first entity102translates the end-to-end resource and service requirements into end-to-end machine learning requirements. According to an example, the end-to-end machine learning requirements are determined if machine learning models are to be instantiated, e.g., to manage or optimize the instantiated end-to-end network service.

For example, the attributes and their values in the following table 2a may describe the end-to-end network service requirements translated into end-to-end machine learning requirements, e.g., performance or configuration requirements:

Attribute NameAttribute ValueML model IDThe ID of the ML modelVersion IDThe information about theversion of the ML modelinferenceTypeThe identifier of theproblem/use case the MLmodel is solvingDecision making capabilityExpressed in the form<object, attribute, metric>>objectthe object or object typesfor which the ML model canundertake optimization orcontrol>attributethe configurableattributes on object orobject types specified,which the ML modeloptimizes or controls toachieve the desiredoutcomes>metricthe performance metricswhich the ML modeloptimizes through itsactionsAnalytics capabilityExpressed in the form<object, context>>objectthe object or object typesfor which the ML model canundertake analysis>contextthe network context (onthe specified object) forwhich the ML modelproduces analysisperformanceMetric [TSIt indicates the28.105]performance metric used toevaluate the performanceof an ML model, e.g.“accuracy”, “precision”,“F1 score”, etc.performanceScore[TSIt indicates the28.105]performance score (in unitof percentage) of an MLentity when performinginference on a specificdata set.The performance metricsmay be different fordifferent kinds of MLmodels depending on thenature of the model. Forinstance, for numericprediction, the metric maybe accuracy; forclassification, the metricmay be a combination ofprecision and recall, likethe “F1 score”.

In addition, if a composition among different machine learning models is required for fulfillment of end-to-end network service, e.g., due to needed flexibility and reusability requirements, an according machine learning composition requirement may be derived. For example, the attributes and their values in the following table 2b may describe the translated end-to-end machine learning composition requirements:

Attribute NameAttribute ValueML model composition IDThe ID of the ML modelcompositionML model compositionThe information about theversion IDversion of the ML modelcompositioninferenceTypeThe identifier of theproblem/use case the MLmodel composition issolvingComposed ML modelsThe list of ML models thatare composed together forrealization of the usecase identified byinferenceTypeStructureThe description of the MLcomposition structure interms of number of levelsand parallels.>LevelsAn integer range (1, n)that indicate the MLcomposition has n levels,where an integer in therange indicates a specificlevel, starting from 1.Each level would consistof an ML model. The outputdata of one level are usedas the input data of thenext level or as theoutput data of the MLcomposition when lastlevel.>>ParallelsAn integer range (1, m)that indicate the seriesof the parallel ML models,inside a given level,starting from 1.>>>Input parametersDescription of theparameters that areexpected as input to eachML model in thecomposition>>>Output parametersDescription of theparameters that areexpected as output of eachML model in thecomposition

Additionally, the cross-stakeholder management and orchestrator116of the first entity102may translate the end-to-end resource and service requirements into domain-specific resource and service requirements. Domain-specific in this context may be radio access network specific or core specific.

The cross-stakeholder machine learning orchestrator118of the first entity102receives the end-to-end machine learning requirements from the cross-stakeholder manager and orchestrator116of the first entity102.

The cross-stakeholder manager and orchestrator116translates the end-to-end machine learning requirements into radio access network or core network resource and service requirements.

The radio network management and orchestrator134of the first domain of the first stakeholder104receives the radio access network resource and service requirements from the cross-stakeholder manager and orchestrator116of the first entity102. The core network management and orchestrator140of the second domain of the first stakeholder106receives the core network resource and service requirements from the cross-stakeholder manager and orchestrator116of the first entity102.

The radio network management and orchestrator134of the first domain of the first stakeholder104translates the radio access network resource and service requirements into radio access network machine learning requirements.

The core network management and orchestrator140of the second domain of the first stakeholder106translates the core network resource and service requirements into core machine learning requirements.

The radio access network machine learning orchestrator136receives the radio access network machine learning requirements from the radio access network management and orchestrator134of the first domain of the first stakeholder104.

The core network machine learning orchestrator142receives the core machine learning requirements from the core network management and orchestrator140of the second domain of the first stakeholder106.

The cross-stakeholder machine learning orchestrator118of the first entity102translates the end-to-end machine learning requirements into radio access network machine learning and core machine learning requirements.

The radio access network machine learning orchestrator136of the first domain of the first stakeholder104receives the radio access network machine learning requirements from the cross-stakeholder machine learning orchestrator118of the first entity102.

The core network machine learning orchestrator142of the second domain of the first stakeholder106receives the radio access network machine learning requirements from the cross-stakeholder machine learning orchestrator118of the first entity102.

The cross-stakeholder machine learning orchestrator118of the first entity102receives an acknowledgement or not acknowledgement regarding the availability, i.e., the feasibility, of the radio access network machine learning requirements from the radio access network machine learning orchestrator136of the first domain of the first stakeholder104.

The cross-stakeholder machine learning orchestrator118of the first entity102receives an acknowledgement or not acknowledgement regarding the availability, i.e., the feasibility, of the core network machine learning requirements from the core network machine learning orchestrator142of the second domain of the first stakeholder106.

The cross-stakeholder machine learning orchestrator118of the first entity102receives an acknowledgement or not acknowledgement regarding the availability, i.e., the feasibility, of the radio access network machine learning requirements from the radio access network machine learning orchestrator136of the first domain of the first stakeholder104.

The cross-stakeholder machine learning orchestrator118of the first entity102receives an acknowledgement or not acknowledgement regarding the availability, i.e., the feasibility, of the core network machine learning requirements from the core network machine learning orchestrator142of the second domain of the first stakeholder106.

The cross-stakeholder manager and orchestrator116of the first entity102receives an acknowledgement or not acknowledgement regarding the availability, i.e., the feasibility, of the radio access network resource and service requirements from the radio network management and orchestrator134of the first domain of the first stakeholder104.

The cross-stakeholder manager and orchestrator116of the first entity102receives an acknowledgement or not acknowledgement regarding the availability, i.e., the feasibility, of the core network resource and service requirements from the core management and orchestrator140of the second domain of the first stakeholder106.

The cross-stakeholder manager and orchestrator116of the first entity102receives an acknowledgement or not acknowledgement regarding the availability, i.e., the feasibility, of the end-to-end machine learning requirements from the cross-stakeholder machine learning orchestrator118of the first entity102.

The cross-stakeholder machine learning orchestrator118of the first entity102may receive a feasibility check report from the radio access network machine learning orchestrator136of the first domain of the first stakeholder104and/or from the core access network machine learning orchestrator142of the second domain of the first stakeholder106. The cross-stakeholder machine learning orchestrator118of the first entity102may analyze whether the end-to-end machine learning requirements can be satisfied or not and correspondingly send the acknowledgement or not acknowledgement to the requested end-to-end machine learning requirements. For example, the analysis may conclude that the first stakeholder may be able to support one part of end-to-end machine learning requirements and may need to rely on other stakeholders to support other part of end-to-end machine learning requirements.

Table 2a and table 2b provide an example for the requirements.

In the example, the cross-stakeholder machine learning orchestrator118of the first entity102and the cross-stakeholder machine learning orchestrator126of the second entity108negotiate via the peer-to-peer orchestrator120of the first entity102and the peer-to-peer orchestrator128of the second entity108.

The cross-stakeholder machine learning orchestrator118of the first entity102may receive a feasibility check report from the radio access network machine learning orchestrator136of the first domain of the first stakeholder104and/or from the core access network machine learning orchestrator142of the second domain of the first stakeholder r106. The cross-stakeholder machine learning orchestrator118of the first entity102may analyze whether the end-to-end machine learning requirements. For example, the analysis may conclude that the first stakeholder may be able to support one part of end-to-end machine learning requirements and may need to rely on other stakeholders to support other part of end-to-end machine learning requirements.

According to an example, the first stakeholder is capable to provide the end-to-end resource and service requirements that are underlined in the following table 3.

According to an example, other end-to-end resource and service requirements that are underlined in the following table 4 need to be provided by the second stakeholder or another stakeholder.

In case the end-to-end resource and service requirement and/or the end-to-end machine learning requirements cannot be satisfied by the first stakeholder, step 16 is executed. Otherwise step 18 is executed.

The cross-stakeholder management and orchestrator116of the first entity102and the cross-stakeholder management and orchestrator124of the second entity108negotiate related to the end-to-end resource and service requirements.

In the example, the cross-stakeholder management and orchestrator116of the first entity102and the cross-stakeholder management and orchestrator124of the second entity108negotiate via the peer-to-peer orchestrator120of the first entity102and the peer-to-peer orchestrator128of the second entity108.

The cross-stakeholder machine learning orchestrator118of the first entity102and the cross-stakeholder machine learning orchestrator126of the second entity108negotiate related to the end-to-end machine learning service requirements.

The cross-stakeholder intent manager114of the first entity102receives an acknowledgement or not acknowledgement regarding the availability, i.e., the feasibility, of the end-to-end resource and service requirements from the cross-stakeholder management and orchestrator116of the first entity102.

The cross-stakeholder intent manager114of the first entity102may receive feasibility check reports from the cross-stakeholder management and orchestrator116of the first entity102.

The cross-stakeholder intent manager114of the first entity102may analyze the feasibility report and determine whether the network intent can be satisfied or not. If the cross-stakeholder intent manager114determines that the first stakeholder cannot satisfy the network intent, the step 19 will be executed. Otherwise, step 20 is executed.

The cross-stakeholder intent manager114of the first entity102and the cross-stakeholder intent manager122of the second entity108negotiate related to the intent.

In the example, the cross-stakeholder intent manager114of the first entity102and the cross-stakeholder intent manager122of the second entity108negotiate via the peer-to-peer orchestrator120of the first entity102and the peer-to-peer orchestrator128of the second entity108.

The cross-stakeholder intent manager114of the first entity102sends an acknowledgement or not acknowledgement regarding the availability, i.e., the feasibility, of the network intent, e.g., performance intent, to the customer.

According to some embodiments, a step requesting a requirement may be sent in case a corresponding machine learning model is to be instantiated or omitted otherwise.

According to some embodiments, a step sending an acknowledgement or not acknowledgement may comprise sending the acknowledgement in case a corresponding machine learning model is instantiated or available to be instantiated or otherwise sending the not acknowledgement.

According to some embodiments, a machine learning orchestrator receiving a requirement may perform a feasibility check, e.g., by interacting with domain specific network entities, e.g., base station, core network function, on what can or cannot be realized with respect to the domain-specific machine learning requirements.

FIG.3depicts a second part of the exemplary sequence flow diagram for a cross-stakeholder feasibility check. The second part comprises details of the step 16 depicted inFIG.2.

The steps in the exemplary second part of the sequence are as follows:

The cross-stakeholder management and orchestrator116of the first entity102asks the peer-to-peer orchestrator120of the first entity102to check if unachievable end-to-end resource and service requirements can be satisfied by another stakeholder.

In the example, the cross-stakeholder management and orchestrator116of the first entity102asks the peer-to-peer orchestrator120of the first entity102after analyzing that end-to-end resource and service requirements cannot be completely satisfied by the first stakeholder.

An example for the end-to-end resource and service requirements cannot be completely satisfied by the first stakeholder is given in table 3.

The peer-to-peer orchestrator120of the first entity102performs discovery of other peer operators that can satisfy the end-to-end resource and service requirements which cannot be completely satisfied by the first stakeholder.

The peer-to-peer orchestrator120of the first entity102performs discovery for example for the end-to-end resource and service requirements given in table 3.

The peer-to-peer orchestrator120of the first entity102negotiates or interacts with the corresponding peer-to-peer orchestrator of the other stakeholder.

In the example, the peer-to-peer orchestrator120of the first entity102negotiates with the peer-to-peer orchestrator128of the second entity108.

In the example, the negotiation is according to the established trust-level, i.e., full-trust, partial-trust or no-trust. This means, the negotiation is only with a peer-to-peer orchestrator that has at least a partial-trust level.

The peer-to-peer orchestrator120of the first entity102may negotiate 1:1, i.e., with one other peer-to-peer orchestrator or 1:N, i.e., with N other peer-to-peer orchestrators.

The peer-to-peer orchestrator120of the first entity102sends the required end-to-end resource and service requirements to the peer-to-peer orchestrator128of the second entity108.

The peer-to-peer orchestrator128of the second entity108sends the required end-to-end resource and service requirements to the cross-stakeholder management and orchestrator124of the second entity108.

In addition, information on offered price or compensation in case the request is fulfilled or not fulfilled may also be included.

Step 16-5 to Step 16-16 are the same as Step 4 to Step 15 in the first part with an exception that these interactions are happening in the second stakeholder instead of the first stakeholder.

The cross-stakeholder management and orchestrator124, after receiving the feasibility check reports from the radio access network management and orchestrator146, and the core network management and orchestrator152, and the radio access network machine learning orchestrator148, and the core machine learning orchestrator154analyzes whether the requested end-to-end resource and service requirements requested by the peer-to-peer orchestrator128of the second entity108can be satisfied or not and correspondingly sends an acknowledgement or not acknowledgement to the peer-to-peer orchestrator128of the second entity108.

Based on the outcome of feasibility check, the peer-to-peer orchestrator128of the second entity108decides whether to accept or not the request. The peer-to-peer orchestrator128of the second entity108may also considering other criteria such as offered price.

Since the request may be sent to multiple stakeholders, the peer-to-peer orchestrator128of the second entity108may also accept to provide a “sub-part” of the end-to-end resource and service requirements.

The peer-to-peer orchestrator128of the second entity108sends an acknowledgement or not acknowledgement to the peer-to-peer orchestrator120of the first entity102with regard to the requested end-to-end resource and service requirements from the peer-to-peer orchestrator120of the first entity102. The peer-to-peer orchestrator128of the second entity108may provide additional details on the agreement or contract of this collaboration.

Details may include, e.g., cost, validity of the contract, an indication whether an indicated fine is acceptable if some terms of the contract are violated.the peer-to-peer orchestrator120of the first entity102may receive multiple responses from other peer-to-peer orchestrators including the peer-to-peer orchestrator128of the second entity108.

The peer-to-peer orchestrator120of the first entity102may decide which offer or combination of offers to accept based on the responses received from one or more peer-to-peer orchestrators.

The peer-to-peer orchestrator120of the first entity102sends an acknowledgement or not acknowledgement for the peer collaboration with one or more peer-to-peer orchestrators based on the details provided by other more peer-to-peer orchestrators.

The peer-to-peer orchestrator120of the first entity102responds with an acknowledgement or not acknowledgement to the cross-stakeholder management and orchestrator116depending on the information received in step 16-18.

FIG.4depicts a third part of the exemplary sequence flow diagram for a cross-stakeholder feasibility check.

The third part comprises details of the step 17 depicted inFIG.2.

The steps in the exemplary third part of the sequence are as follows:

The cross-stakeholder machine learning orchestrator118of the first entity102, after analyzing that end-to-end machine learning requirements cannot be completely satisfied by the first stakeholder, asks the peer-to-peer orchestrator120of the first entity102to check if the end-to-end machine learning requirements that cannot be completely satisfied by the first stakeholder, can be satisfied by other stakeholders.

The peer-to-peer orchestrator120of the first entity102performs discovery of other peer stakeholders can satisfy the end-to-end machine learning requirements that cannot be completely satisfied by the first stakeholder.

The peer-to-peer orchestrator120of the first entity102negotiates or interacts with the corresponding peer-to-peer orchestrators, e.g., the peer-to-peer orchestrator128of the second entity according to the established trust-level, i.e., full-trust, partial-trust or no-trust. This means, the negotiation is only with a peer-to-peer orchestrator that has at least a partial-trust level.

The peer-to-peer orchestrator120of the first entity102may negotiate 1:1, i.e., with one other peer-to-peer orchestrator or 1:N, i.e., with N other peer-to-peer orchestrators.

The peer-to-peer orchestrator120of the first entity102sends the required end-to-end machine learning requirements to the other peer-to-peer orchestrators, in the example, to the peer-to-peer orchestrator128of the second entity108.

Table 2a and 2b provide examples for the end-to-end machine learning requirements.

The peer-to-peer orchestrator128of the second entity108sends the required end-to-end machine learning requirements to the cross-stakeholder machine learning orchestrator126of the second entity108.

The cross-stakeholder machine learning orchestrator126of the second entity108translates the end-to-end machine learning requirements into radio access network machine learning requirements and core machine learning requirements.

The radio access network machine learning orchestrator148receives the radio access network machine learning requirements from the cross-stakeholder machine learning orchestrator126of the second entity108.

The core network machine learning orchestrator154receives the core machine learning requirements from the cross-stakeholder machine learning orchestrator126of the second entity108.

The radio access network machine learning orchestrator148sends an acknowledgement or not acknowledgement regarding the radio access network machine learning requirements to the cross-stakeholder machine learning orchestrator126of the second entity108.

The core network machine learning orchestrator154sends an acknowledgement or not acknowledgement regarding the core machine learning requirements to the cross-stakeholder machine learning orchestrator126of the second entity108.

The cross-stakeholder machine learning orchestrator126of the second entity108, after receiving the feasibility check reports from the radio access network machine learning orchestrator148and the core network machine learning orchestrator154, analyzes whether the end-to-end machine learning requirements can be satisfied or not and correspondingly sends an acknowledgement or not acknowledgement to the requested end-to-end machine learning requirements to the peer-to-peer orchestrator128of the second entity108.

The peer-to-peer orchestrator128of the second entity108sends an acknowledgement or a not acknowledgement to the peer-to-peer orchestrator120of the first entity102with regard to the requested end-to-end machine learning requirements from the peer-to-peer orchestrator128of the second entity108.

The peer-to-peer orchestrator128of the second entity108may provide additional details.

Details may include, e.g., cost, validity of the contract, an indication whether an indicated fine is acceptable if some terms of the contract are violated.

The peer-to-peer orchestrator120of the first entity102sends an acknowledgement or not acknowledgement for the peer collaboration based on the details provided by the peer-to-peer orchestrator128of the second entity108in step 17-9.

The peer-to-peer orchestrator120of the first entity102responds with an acknowledgement or not acknowledgement to the cross-stakeholder management and orchestrator118of the first entity102depending on the information received in step 17-9.

FIG.5depicts a fourth part of the exemplary sequence flow diagram for a cross-stakeholder feasibility check.

The fourth part comprises details of the step 19 depicted inFIG.2.

The steps in the exemplary third part of the sequence are as follows:

The cross-stakeholder intent manager114of the first entity102, after analyzing that network intent, e.g., performance intent, cannot be completely satisfied by the first stakeholder, asks the peer-to-peer orchestrator120of the first entity102to check if network intent that cannot be provided by the first stakeholder can be satisfied by other stakeholders.

The peer-to-peer orchestrator120of the first entity102performs discovery of other stakeholders that can satisfy the network intent that cannot be provided by the first stakeholder.

The peer-to-peer orchestrator120of the first entity102negotiates or interacts with the corresponding peer-to-peer orchestrators, e.g., the peer-to-peer orchestrator128of the second entity108, according to the established trust-level, i.e., full-trust, partial-trust or no-trust. This means, the negotiation is only with a peer-to-peer orchestrator that has at least a partial-trust level.

The peer-to-peer orchestrator120of the first entity102may negotiate 1:1, i.e., with one other peer-to-peer orchestrator or 1:N, i.e., with N other peer-to-peer orchestrators.

The peer-to-peer orchestrator120of the first entity102sends the required network intent that cannot be provided by the first stakeholder to the peer-to-peer orchestrator128of the second entity108.

The peer-to-peer orchestrator128of the second entity108sends the required network intent to the cross-stakeholder intent manager122of the second entity108.

The cross-stakeholder intent manager122of the second entity108, after receiving feasibility check reports regarding the required network intent from, e.g., network entities not shown in theFIG.5, analyzes whether the network intent can be satisfied or not and correspondingly sends an acknowledgement or not acknowledgement regarding the requested network intent to the peer-to-peer orchestrator128of the second entity108.

The peer-to-peer orchestrator128of the second entity108sends an acknowledgement or not acknowledgement to the peer-to-peer orchestrator120of the first entity102with regard to the requested network intent.

The peer-to-peer orchestrator128of the second entity108may provide additional details.

Details may include, e.g., cost, validity of the contract, an indication whether an indicated fine is acceptable if some terms of the contract are violated.

The peer-to-peer orchestrator120of the first entity102sends an acknowledgement or not acknowledgement for the peer collaboration. The acknowledgement or not acknowledgement may be based on the acknowledgement or not acknowledgement or details provided by the peer-to-peer orchestrator128of the second entity108in step 19-6.

The peer-to-peer orchestrator120of the first entity102responds with an acknowledgement or not acknowledgement to the cross-stakeholder intent manager114depending on the information received in step 19-6.

According to some embodiments, the peer-to-peer orchestrator is responsible for determining and communicating the degree of trust among stakeholder, to be used as input into translation and negotiation of cross-stakeholder network and service performance requirements into stakeholder-specific network and service performance requirements, as well as cross-stakeholder machine learning performance requirements into stakeholder-specific machine learning performance requirements. From a security perspective, the link between any two peer-to-peer orchestrators in the stakeholder ecosystem may use standard authentication-based protocols, including but not restricted to certificate-based authentication, and may use encryption to ensure the integrity of and prevent man-in-the-middle attacks on the information being sent between any two peer-to-peer orchestrators.

Definition and Measures of Trust:

From a trust perspective, trust between any two stakeholders can be comprised of two options: full trust resulting from a bilateral service level agreement (SLA) or partial trust that is the transitive closure of full trust.

Full trust: there is a full trust relationship between stakeholder A and stakeholder M if and only if there is a bilateral service-level agreement (SLA) between them.

Partial trust: there is a partial trust relationship between stakeholder A and stakeholder M if and only if there exists some number n>0 and a set of stakeholder {stakeholder1, . . . stakeholder n} such that1. for all i s.t. 1<=i<n, there is a full trust relationship between stakeholder i and stakeholder i+1,2. there is a full trust relationship between stakeholder A and stakeholder13. there is a full trust relationship between stakeholder n and stakeholder MNo trust: there is neither full trust nor partial trust between stakeholder A and stakeholder M

An example is shown inFIG.6.

FIG.6depicts a graph of the stakeholder A, B, C, D, E, F, G, J. The links shown indicate the presence of bilateral service level agreements: hence, full trust relationships. For example, inFIG.6, A has a full trust relationship with each of B, D, G, while B has a full trust relationship with C, and so forth. Stakeholders that have a full trust relationship are neighbors in the graph.

According to an example, the stakeholders have an associated attenuation of trust table, which lists the knowledge it has of its attenuation of trust levels with other stakeholder.

For the trust relationships in the above figure, the attenuation of trust table for stakeholder A in the example is:B 1C 2D 1E 2F 3G 1H 2J 2K ∞K ∞

Discovery and Trust Establishment at Operator Ecosystem Initialization:

To compute full and partial trust relationships in a peer-to-peer fashion, it is assumed that no stakeholder has a priori knowledge of other stakeholder trust relationships-that is the graph topology above is unknown. Also, given the peer-to-peer nature of the orchestration, it is assumed that there is no centralized entity that will carry out the graph traversal computations.

According to an example, an algorithm to compute these trust relationships is distributed or decentralized, as well as asynchronous given that network domains are independent. To this end, a distance vector algorithm may be used to compute trust relationships in a peer-to-peer manner at stakeholder ecosystem initialization.

In particular, the standard distance vector algorithm that forms the essence of the Border Gateway Protocol for inter-domain routing may be used. Kurose J, F Ross K W. Computer Networking: A Top-Down Approach. Eighth ed. Hoboken: Pearson; 2021 discloses aspects of the standard distance vector algorithm.

According to an example, two nodes are considered as neighbors if and only if they have a service level agreement between them. The weights of the links in the graph are set to be 1. According to an example, two nodes are considered to have full trust if the computed distance vector between them is 1, and partial trust if the computed distance vector between them is strictly greater than 1 (but less than infinity). Upon termination, the distance vector algorithm also yields as output the attenuation tables.

Once computed, the trust tables and attenuation tables are expected to be largely stable and hence available when a new network intent arrives at the cross-stakeholder intent manager.

Updates when SLAs are changed:

The trust and attenuation tables may be updated whenever a new service level agreement is formed or rescinded between two stakeholders by recomputation of the distance vector algorithm initiated by the node with the changed status, resulting in eventual consistency trust knowledge across the trust tables of all the nodes. Note that this trust table is first computed at initialization of the stakeholder ecosystem, and then updated when new SLAs are created or existing ones removed, hence is always available when an intent arrives.

Discovery and Trust Establishment upon Intent Arrival:

When a cross-stakeholder intent arrives at a stakeholder, this stakeholder needs to determine with which stakeholder or stakeholders it should attempt to coordinate. To do so, it will look up its trust table and attenuation of trust table to determine which stakeholder it would like to contact on a 1-1 basis or 1-N basis. Furthermore, stakeholder-specific policies around trust may also be specified and applied, analogous to router policies, e.g., in the border gateway protocol, BGP. These trust-related policies may specify what information and/or with which granularity the information is passed along to other stakeholders, depending on full vs. partial trust, and trust attenuation levels.

FIG.7depicts a sequence flow diagram for a cross-stakeholder configuration of machine learning models.

Hereby, the procedures for cross-operator deploying of machine learning models and creating of machine learning composition are described. Such procedures rely on the level of trust established as well as the attenuation of trust among the involved operators. The machine learning construct may be created across stakeholders in order to leverage on the best performing machine learning models available among multiple stakeholders as well as to achieve better flexibility in building the machine learning based solution for specific use case. Stakeholder-specific policies around trust will impact the machine learning construct, as these policies may affect which machine learning model parameters and configuration attributes are shared, as well as the level of granularity of information. For example, more detailed information will be shared among stakeholders with full trust relationships, while less and less detailed may be shared as the trust attenuation level increases.

The cross-stakeholder configuration comprises the following steps:

Based on the outcome of a cross-operator machine learning feasibility check, the cross-stakeholder machine learning orchestrator114asks the peer-to-peer orchestrator120of the first entity102to put into operation feasible end-to-end machine learning requirements that are needed for fulfilment of the end-to-end machine learning requirements from the second stakeholder, e.g., in terms of capabilities, features, performance, or configuration. The end-to-end machine learning requirements may be expressed for individual machine learning models or for a machine learning model composition, e.g., in form of tables, e.g., table 2a and 2b.

The peer-to-peer orchestrator120of the first entity102sends the request for fulfilment of feasible end-to-end machine learning requirements to the corresponding peer-to-peer orchestrator, e.g., the peer-to-peer orchestrator128of the second entity108according to the established trust-level, i.e., full-trust, partial-trust or no-trust. This means, the negotiation is only with a peer-to-peer orchestrator that has at least a partial-trust level.

The peer-to-peer orchestrator120of the first entity102may negotiate 1:1, i.e., with one other peer-to-peer orchestrator or 1:N, i.e., with N other peer-to-peer orchestrators.

The peer-to-peer orchestrator128of the second entity108sends end-to-end machine learning requirements to the cross-stakeholder machine learning orchestrator122of the second entity108. Based on established trust level and trust attenuation, the peer-to-peer orchestrator128of the second entity108may in addition provide the according policies for configuration. E.g., if there is no full trust established, only selected machine learning models, or models deployed in selected domains can be used to fulfil the requirements.

The cross-stakeholder machine learning orchestrator122of the second entity108translates the received end-to-end machine learning requirements and if available further configuration policies into radio access network machine learning requirements and core machine learning requirements.

The cross-stakeholder machine learning orchestrator122of the second entity108sends the radio access network machine learning requirements to the radio access network machine learning orchestrator148and the core machine learning requirements to the core machine learning orchestrator154.

The radio access network machine learning orchestrator148configures the radio access network machine learning models or model compositions accordingly.

The radio access network machine learning orchestrator148may send configuration information to the cross-stakeholder machine learning orchestrator122of the second entity108

The core machine learning orchestrator154configures the core network machine learning models or model compositions accordingly.

The core network machine learning orchestrator148may send configuration information to the cross-stakeholder machine learning orchestrator122of the second entity108.

The cross-stakeholder machine learning orchestrator122of the second entity108sends configuration information that is forwarded via the peer-to-peer orchestrator128of the second entity108to the peer-to-peer orchestrator120of the first entity102and from the peer-to-peer orchestrator120of the first entity102to the cross-stakeholder machine learning orchestrator114of the first entity102.

The configuration information may be the configuration information received in step 6.

The configuration information may contain the following:

Identifications of machine learning models and machine learning model compositions that have been trained and deployed for the first stakeholder.

Information on how to access the deployed machine learning models and machine learning model compositions, e.g., uniform resource locator, URL, information.

Information on how to access the output of deployed machine learning models and machine learning model compositions, e.g., uniform resource locator, URL, information.

FIG.8depicts a sequence flow diagram for reporting.

The reporting comprises the following steps:

The cross-stakeholder intent manager114of the first entity102requests or subscribes to a network intent report from the cross-stakeholder intent manager122of the second entity108via the peer-to-peer orchestrators120,128.

This request or subscription relates to the network intent that the second stakeholder has agreed to satisfy with the first stakeholder.

Once the second stakeholder determines whether the network intent is satisfied or not, the cross-stakeholder intent manager122of the second entity108sends the network intent report to the cross-stakeholder intent manager114of the first entity102via the peer-to-peer orchestrators120,128.

The report may include details such as intent fulfilled or not and if not which particular aspect is not fulfilled such as network service performance related, network resource related, machine learning performance, machine learning capabilities, or machine learning composition related.

The cross-stakeholder management and orchestrator116of the first entity102requests or subscribes to network service and resource performance report from the radio access network management and orchestrator134and the core management and orchestrator140. This request or subscription relates to the network service and resource requirements that the first stakeholder has to satisfy.

Once the radio access network management and orchestrator134and the core management and orchestrator140determine whether network service and resource requirements are satisfied or not, it sends the network service and resource performance report to the cross-stakeholder management and orchestrator116of the first entity102. The report may include details such as achieved throughput, achieved latency, number of successful pdu sessions, number of users served, achieved coverage, utilized computational or networking resources.

The cross-stakeholder management and orchestrator116of the first entity102requests or subscribes to network service a resource performance report from the cross-stakeholder management and orchestrator124of the second entity108via the peer-to-peer orchestrators120,128. This request or subscription relates to the network service and resource requirements that second stakeholder has agreed to satisfy with the first stakeholder.

The cross-stakeholder management and orchestrator124of the second entity108aggregates network service and resource performance reports received from the radio access network management and orchestrator and the core management and orchestrator (not depicted inFIG.8).

The cross-stakeholder management and orchestrator124of the second entity108sends the aggregated network service and resource performance report to the cross-stakeholder management and orchestrator116of the first entity102via the peer-to-peer orchestrators120,128.

The cross-stakeholder machine learning operator118of the first entity102requests or subscribes to machine learning performance or configuration report from the radio access network machine learning orchestrator136and the core machine learning orchestrator142. This request or subscription relates to the machine learning performance or configuration requirements that first stakeholder has to satisfy.

Once the radio access network machine learning orchestrator136and the core machine learning orchestrator142determine whether machine requirements are satisfied or not, it sends the machine learning performance or configuration report to the cross-stakeholder machine learning operator118of the first entity102. The report may include details such as achieved accuracy, mean squared error, mean absolute error, or confusion matrix of one or more machine learning models.

The cross-stakeholder machine learning operator118of the first entity102requests or subscribes to machine learning performance or configuration report from the cross-stakeholder machine learning operator126of the second entity108via the peer-to-peer orchestrators120,128. This request or subscription relates to the machine learning performance or configuration requirements that the second stakeholder has agreed to satisfy with the first stakeholder.

The cross-stakeholder machine learning operator126of the second entity108aggregates machine learning performance or configuration reports received from the radio access network management and orchestrator and the core management and orchestrator (not depicted inFIG.8).

The cross-stakeholder machine learning operator126of the second entity108sends the aggregated machine learning performance or configuration report to the cross-stakeholder machine learning operator118of the first entity102via the peer-to-peer orchestrators120,128.

FIG.9schematically depicts scenarios of cross-stakeholder machine learning composition. The scenario are explained for operators as example for the stakeholders.

In Scenario900-1a user equipment (UE)902is in coverage of a terrestrial network (TN) that supports a first public land mobile network (PLMN)904of a first operator as well as a non-terrestrial network (NTN) that supports a second PLMN906of a second operator Resources908of the first operator comprise a first machine learning model (ML)910that is configured for quality of service (QOS) prediction, a second ML model912that is configured for traffic steering, and an orchestrator914of the first operator that comprises a cross-stakeholder management and orchestrator, a cross-stakeholder machine learning orchestrator and a peer-to-peer orchestrator of the first operator. Suddenly, the UE902joins a resource demanding metaverse call or goes above the coverage area of the TN. The first machine learning (ML) model910predicts the QOS degradation of the UE902and provides this information to the second ML model912. If the changing of the first ML model910and the second ML model912is not able to resolve the problem of high throughout demand or need for extended coverage using the available first PLMN904resources, this will be detected by the cross-stakeholder management and orchestrator of the first operator by monitoring network key performance indicators (KPIs). In addition, or alternatively, the cross-stakeholder machine learning orchestrator of operator1can monitor the output of Qos prediction and detect that QoS degradation is expected to last. In such a case, the first operator needs to rely on resources and capabilities from the second operator, e.g., for coverage related issues, or some other operator, e.g., for throughput related issues.

Resources916of second operator comprise a third ML model918that is configured for quality of service (QOS) prediction, a fourth ML model920that is configured for traffic steering, and an orchestrator922of the second operator that comprises a cross-stakeholder management and orchestrator, a cross-stakeholder machine learning orchestrator and a peer-to-peer orchestrator of the second operator.

According to some examples, the third ML model918is configured for QoS prediction of a particular UE with higher accuracy than the first ML model910.

The peer-to-peer orchestrator of the first operator informs the peer-to-peer orchestrator of the second operator over a peer-to-peer interface between the peer-to-peer orchestrators, also specifying the information on predicted Qos degradation as output of the first ML model910. The peer-to-peer orchestrator of the second operator may either convey this information directly to the fourth ML model920in the second PLMN906, or it will provide the information needed to temporarily chain the first ML model910and the fourth ML model920. In such a way, by using the output of the first ML model910, the fourth ML model920may decide to enhance the existing connection via the first PLMN904with additional connection via the second PLMN906, e.g., via the NTN, in order to address the coverage problem or if possible the throughout problems. Further, in the case that the third ML model918can provide the same or similar input to the fourth ML model920, the fourth ML model920will take outputs of the third ML model918as input data.

In a second scenario900-2the UE902might be in coverage of only one NTN, e.g., the second PLMN906and therefore the steering of traffic may rely only on the third ML model918and the fourth ML model920and may be done by means of diverse satellite access. In the case of multiple NTN coverage, the same/similar procedures as in the first Scenario900-1would apply.

In a third scenario900-3while the UE902is moving towards the coverage area of a third PLMN924in addition to NTN coverage, the UE902may initiate a voice call, for which the available resources of the second PLMN906are sufficient. In such a case the third ML model918may predict that there will be no QoS degradation for UE902.

Resources926of a third operator that provides the third PLMN924comprise a fifth ML model928that is configured for quality of service (Qos) prediction, a sixth ML model930that is configured for traffic steering, and an orchestrator932of the third operator that comprises a cross-stakeholder management and orchestrator, a cross-stakeholder machine learning orchestrator and a peer-to-peer orchestrator of the third operator.

The peer-to-peer orchestrator of the second operator informs the peer-to-peer orchestrator of the third operator that there will be no QoS degradation for UE902. The cross-stakeholder machine learning orchestrator of the second operator may send this information via the peer-to-peer orchestrators of the second operator and the third operator to the cross-stakeholder machine learning orchestrator of the third operator. Similar to the first scenario, the cross-stakeholder machine learning orchestrator of the third operator may either convey this information directly to the matching sixth ML model930in the third PLMN924, or it will provide the information needed to temporarily chain the third ML model918and the sixth ML model930. In such a way, by using the output of the third ML model918, the sixth ML model930may decide that no additional connections or traffic split is needed by using resources of the third PLMN923. As the fifth ML model928may be able to provide QoS predictions only with certain delay, e.g., once UE enters coverage area of the third PLMN, the sixth ML model930may rely on the output from the third ML model918during the transition phase. Later on, the sixth ML model930may rely on either the output of third ML model918or the fifth ML model928depending on the achieved accuracy or confidence of predictions.

Overall, the temporary on demand ML model chaining enables efficient cooperation between the operators in order to fulfill service requirements while optimizing the resource consumption and total cost of ownership.