Method and entity for network

Abstract

A first and second device (128) for communication and a corresponding first and second method are provided, the first and second device (128) being configured to manage or orchestrate network resources, network services, machine learning models, or compositions of machine learning models for a first stakeholder and a second stakeholder, respectively, and the first method, the second device (128) being configured to manage or orchestrate network resources, network services, machine learning models, or compositions of machine learning models for a first stakeholder and a second stakeholder, respectively. Comprising receiving, at a first device (120), a requirement for a network intent, or a network resource, or a network service, or a machine learning model, or a composition of the machine learning model, determining, at the first device (120), a message for the requirement, sending the message to a second device (128), and a second method comprising receiving, from the first device (120), a first message for the requirement, and transmitting a second message about the request or a first message about the network intent to the first device (120), and transmitting a second message about the network intent to the first device (120).

Description

Technical Field

[0001] The present disclosure herein relates to methods and entities for a network. Background Art

[0002] In the current mobile network ecosystem, there are many stakeholders, such as network operators, which provide mobile network services. Summary of the invention

[0003] The present disclosure herein relates to a multi-stakeholder concept for a network ecosystem, where many stakeholders (e.g., network operators) provide network resources or network services, or machine learning models or compositions of machine learning models.

[0004] A first method includes receiving a requirement at a first device configured to manage or orchestrate network resources for a first stakeholder, determining at the first device at least a portion of the requirement that needs to be orchestrated with a second device, the second device configured to manage or orchestrate network resources for a second stakeholder, and sending a request to the second device regarding at least a portion of the requirement that needs to be orchestrated with the second device.

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

[0006] According to some examples of the first method, the requirements include machine learning model performance or machine learning model configuration.

[0007] According to some examples, the first method includes determining, sending, receiving, or requesting a report on network resources, service requirements, machine learning model performance, or machine learning model configuration.

[0008] A second method includes: receiving, at a second device, a request from a first device regarding at least a portion of a requirement that needs to be orchestrated with the second device, the first device being configured to manage or orchestrate network resources of a first stakeholder, the second device being configured to manage or orchestrate network resources of a second stakeholder, determining, at the second device, at least a portion of the requirement that can be orchestrated with the second device, and sending a response regarding the requirement to the first device.

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

[0010] According to some examples of the second method, the requirements include: machine learning model performance or machine learning model configuration.

[0011] According to some examples, the second method includes: receiving a request for a report about: network resources, service requirements, machine learning model performance, or machine learning model configuration from a first device, determining a report, and sending the report to the first device.

[0012] According to some examples, the second method includes sending a request regarding at least a portion of a requirement that needs to be orchestrated with a device of a second stakeholder, receiving a response regarding at least a portion of the requirement that needs to be orchestrated from the device of the second stakeholder, and determining a response to the first device depending on the response from the device.

[0013] According to some examples, a first device includes components for managing network resources for a first stakeholder, receiving a requirement, determining at least a portion of the requirement that needs to be orchestrated with a second device, the second device being configured to manage or orchestrate network resources for a second stakeholder, and sending a request to the second device regarding at least a portion of the requirement that needs to be orchestrated with the second device.

[0014] According to some examples of the first device, the requirement includes: network intent, network resources, network services, machine learning models, compositions of machine learning models, or information about a trust relationship between the first stakeholder and the second stakeholder.

[0015] According to some examples of the first device, the requirements include: machine learning model performance or machine learning model configuration.

[0016] According to some examples, the first device includes components for determining, sending, receiving, or requesting reports regarding: network resources, service requirements, machine learning model performance, or machine learning model configuration.

[0017] According to some examples, a second device includes components for: managing network resources of a second stakeholder, receiving a request from a first device regarding: a request for at least a portion of a requirement that needs to be orchestrated with the second device, the first device being configured to manage or orchestrate the network resources of the first stakeholder, determining at the second device at least a portion of the requirement that can be orchestrated with the second device, and sending a response regarding the requirement to the first device.

[0018] According to some examples of the second device, the request includes: a network intent, a network resource, a network service, a machine learning model, a composition of a machine learning model, or information about a trust relationship between the first stakeholder and the second stakeholder.

[0019] According to some examples of the second device, the requirements include: machine learning model performance or a machine learning model.

[0020] According to some examples, the second device includes components for: receiving a request for a report about: network resources, service requirements, machine learning model performance, or machine learning model configuration from the first device, and determining a report, and sending the report to the first device.

[0021] According to some examples, the second device includes components for sending a request regarding at least a portion of a requirement that needs to be orchestrated with a device of a second stakeholder, receiving a response regarding at least a portion of the requirement that needs to be orchestrated from the device of the second stakeholder, and determining a response to the first device depending on the response from the device.

[0022] According to some examples, means for managing network resources, determining, sending, receiving, or requesting include a processor and non-transitory memory.

[0023] According to some examples, the means for sending or requesting includes a sender. According to some examples, the means for receiving includes a receiver.

[0024] Further exemplary embodiments emerge from the following description and the drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 Schematically depicts the cross-operator peer management and orchestration framework,

[0026] Figure 2 Depicts the first part of an exemplary sequential flow chart for cross-stakeholder feasibility checks,

[0027] Figure 3 The second part of the exemplary sequential flowchart depicting the feasibility check across stakeholders,

[0028] Figure 4 The third section depicts an exemplary sequential flow chart for cross-stakeholder feasibility checks,

[0029] Figure 5 The fourth section depicts an exemplary sequential flow chart for cross-stakeholder feasibility checks,

[0030] Figure 6 A diagram depicting the stakeholders,

[0031] Figure 7 Depicting a sequential flow chart for cross-stakeholder configuration of machine learning models,

[0032] Figure 8Describes the sequence flow chart used for reporting,

[0033] Fig. 9 Schematically depicting a scenario of cross-stakeholder machine learning composition. DETAILED DESCRIPTION

[0034] Figure 1 Schematically depicting the peer management and orchestration framework across stakeholders.

[0035] The framework includes a first entity 102 configured to manage or orchestrate network resources, or network services, or machine learning models, or compositions of machine learning models for a first stakeholder.

[0036] In an example, the first entity 102 is configured to manage or orchestrate a first domain of a first stakeholder 104 and a second domain of a first stakeholder 106 .

[0037] The framework includes a second entity 108 configured to manage or orchestrate network resources, or network services, or machine learning models, or compositions of machine learning models for a second stakeholder.

[0038] In an example, the second entity 108 is configured to manage or orchestrate a first domain of a second stakeholder 110 and a second domain of a second stakeholder 112 .

[0039] The first entity 102 includes a cross-stakeholder intent manager 114, a cross-stakeholder management and orchestration 116, a cross-stakeholder machine learning orchestration 118, and a peer orchestration 120. The peer orchestration 120 of the first entity 102 is an example for a first device configured to manage or orchestrate network resources, or network services, or machine learning models, or compositions of machine learning models for a first stakeholder.

[0040] The second entity 102 includes a cross-stakeholder intent manager 122, a cross-stakeholder management and orchestration 124, a cross-stakeholder machine learning orchestration 126, and a peer orchestration 128. The peer orchestration 128 of the second entity 108 is an example of a second device configured to manage or orchestrate network resources, or network services, or machine learning models, or compositions of machine learning models for a second stakeholder.

[0041] The cross-stakeholder intent manager 114, the cross-stakeholder management and orchestration 116, and the cross-stakeholder machine learning orchestration 118 of the first entity 102 are examples of third means for being associated with the first stakeholder. The cross-stakeholder intent manager 122, the cross-stakeholder management and orchestration 124, and the cross-stakeholder machine learning orchestration 126 of the second entity 108 are examples of third means for being associated with the second stakeholder.

[0042] According to some examples, the first device includes a receiver configured to receive a message.

[0043] According to some examples, the first device includes a processor configured to determine a message.

[0044] According to some examples, the first device includes a transmitter configured to send the received or determined message.

[0045] According to some examples, the second device includes a receiver configured to receive the message.

[0046] According to some examples, the second device includes a processor configured to determine a message.

[0047] According to some examples, the second device includes a transmitter configured to send the received or determined message.

[0048] According to some examples, the third device includes a receiver configured to receive the message.

[0049] According to some examples, the third device includes a processor configured to determine a message.

[0050] According to some examples, the third device includes a transmitter configured to send the received or determined message.

[0051] The cross-stakeholder intent manager 114 of the first entity 102 and the cross-stakeholder intent manager 122 of the second entity 108 are configured to communicate via the peer orchestrator 120 of the first entity 102 and the peer orchestrator 128 of the second entity 108 .

[0052] The cross-stakeholder management and orchestration 116 of the first entity 102 and the cross-stakeholder management and orchestration 124 of the second entity 108 are configured to communicate via the peer orchestration 120 of the first entity 102 and the peer orchestration 128 of the second entity 108 .

[0053] The cross-stakeholder machine learning orchestrator 118 of the first entity 102 and the cross-stakeholder machine learning orchestrator 126 of the second entity 108 are configured to communicate via the peer orchestrator 120 of the first entity 102 and the peer orchestrator 128 of the second entity 108 .

[0054] Peer orchestrator 120 of first entity 102 and peer orchestrator 128 of second entity 108 are configured to connect via peer interface 130 .

[0055] The first domain of the first stakeholder 104 and the second domain of the first stakeholder 106 and the first domain of the second stakeholder 110 and the second domain of the second stakeholder 112 may include intent-based networks managed by respective intent managers 132 .

[0056] The first domain of the first stakeholder 104 may include a radio access network management and orchestrator 134 configured to manage and orchestrate a radio access network in the first domain of the first stakeholder 104. The first domain of the first stakeholder 104 may include a machine learning orchestrator 136 configured to orchestrate i machine learning models 138-1, ..., 138-i in the first domain of the first stakeholder 104.

[0057] The second domain of the first stakeholder 104 may include a core network management and orchestrator 140 configured to manage and orchestrate a core network in the second domain of the first stakeholder 104. The second domain of the first stakeholder 104 may include a machine learning orchestrator 142 configured to orchestrate j machine learning models 144-1, ..., 144-j in the second domain of the first stakeholder 104.

[0058] The first domain of the second stakeholder 110 may include a radio access network management and orchestrator 146 configured to manage and orchestrate a radio access network in the first domain of the second stakeholder 110. The first domain of the second stakeholder 110 may include a radio access network machine learning orchestrator 148 configured to orchestrate k machine learning models 150-1, ..., 150-k in the first domain.

[0059] The second domain of the second stakeholder 112 may include a core network management and orchestrator 152 configured to manage and orchestrate a core network in the second domain of the second stakeholder 112. The second domain of the second stakeholder 112 may include a core machine learning orchestrator 154 configured to orchestrate l machine learning models 156-1, ..., 156-1 in the second domain of the second stakeholder 112.

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

[0061] Stakeholders may provide more or fewer domains.

[0062] In addition to the cross-stakeholder network and service performance requirements as indicated in the network intent, the cross-stakeholder peer management and orchestration framework is also used to ensure the achievement of the desired cross-stakeholder machine learning performance or configuration requirements.

[0063] The peer orchestrator may provide corresponding management functions among stakeholders and a peer interface 130 between the corresponding management functions.

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

[0065] The trust model includes the concept of full trust as a direct trust relationship between two stakeholders with a bilateral service level agreement. The trust model includes the concept of partial trust as an indirect relationship between two stakeholders when there is a series of intermediate stakeholders with full trust.

[0066] According to one aspect, a trust metric is provided. The trust metric is called trust decay. The decay represents the minimum number of intermediate stakeholders required to achieve partial trust between two stakeholders. This means that the higher the decay level, the weaker the trust level.

[0067] According to one aspect, a trust table corresponding to a trust model is provided. The trust table is determined via a peer-to-peer algorithm, for example, a distributed or decentralized algorithm.

[0068] According to one aspect, a trust table for use in cross-stakeholder orchestration and negotiation is provided. The cross-stakeholder orchestration and negotiation may include a 1:1 or a 1:N orchestration and negotiation between network resources, network services, or machine learning models.

[0069] The peer orchestrator can support the following cross-stakeholder network resource and service related operations:

[0070] - Receive network resource and service requirements from cross-stakeholder management and orchestration.

[0071] - Indicate required network resources and service requirements to another stakeholder's peer orchestrator.

[0072] - Send network resource and service requirements received by peer orchestrators to cross-stakeholder management and orchestration.

[0073] - Receive achievable network resource and service requirements from cross-stakeholder management and orchestration.

[0074] -Indicate achievable network resource and service requirements to a peer orchestrator of another stakeholder.

[0075] - Sending achievable network resource and service requirements to cross-stakeholder management and orchestration that are received by peer orchestrators.

[0076] The peer orchestrator can support the following cross-stakeholder machine learning related operations:

[0077] - Receive machine learning requirements from cross-stakeholder machine learning orchestrators, e.g., performance and configuration.

[0078] -Indicate the desired machine learning requirements, e.g., performance and configuration, to a peer orchestrator of another operator.

[0079] -Send machine learning requirements, e.g., performance and configuration, to the cross-stakeholder machine learning orchestrator that are received by the peer orchestrator.

[0080] - Receive achievable machine learning requirements, e.g., performance and configuration, from cross-stakeholder machine learning orchestrators.

[0081] -Indicate achievable machine learning requirements, e.g., performance and configuration, to a peer orchestrator of another operator.

[0082] -Send achievable machine learning requirements (e.g., performance and configuration) to the cross-stakeholder machine learning orchestrator, which are received by peer orchestrators.

[0083] The peer orchestrator can support the following cross-stakeholder machine learning composition-related operations:

[0084] - Receive machine learning composition requirements from cross-stakeholder machine learning orchestrators, e.g., performance and configuration.

[0085] -Indicate the desired machine learning composition requirements, e.g., performance and configuration, to another operator’s peer orchestrator.

[0086] -Sends machine learning composition requirements, e.g., performance and configuration, to the cross-stakeholder machine learning orchestrator that are received by the peer orchestrator.

[0087] - Receive achievable machine learning composition requirements, e.g., performance and configuration, from cross-stakeholder machine learning orchestrators.

[0088] -Indicate achievable machine learning composition requirements, e.g., performance and configuration, to a peer orchestrator of another operator.

[0089] - Send achievable machine learning composition requirements, e.g., performance and configuration, to the cross-stakeholder machine learning orchestrator that are received by the peer orchestrators.

[0090] The peer orchestrator can support the following cross-stakeholder reporting related operations:

[0091] - Receive requests or subscriptions for network resources, network services, and machine learning related reports from the cross-stakeholder machine learning orchestrator.

[0092] -Indicate required network resources, network services, and machine learning related report requests or subscriptions to another operator’s peer orchestrator.

[0093] -Sends network resource, network service, and machine learning related report requests or subscriptions to the cross-stakeholder machine learning orchestrator that are received by peer orchestrators.

[0094] - Receive network resources, network services, and machine learning related reports from the cross-stakeholder machine learning orchestrator.

[0095] -Indicate received network resources, network services, and machine learning related reports to another operator’s peer orchestrator.

[0096] - Cross-stakeholder machine learning orchestrator sends network resources, network services, and machine learning related reports which are received by peer orchestrators.

[0097] The peer orchestrator can support the following cross-stakeholder security and trust related operations:

[0098] - Receive requests for information about trust relationships with other stakeholders, such as full trust, partial trust, or trust metrics. Such requests can be requests to or from peer orchestrators of stakeholders to support translation of cross-stakeholder network and service requirements and cross-stakeholder machine learning and machine learning composition requirements.

[0099] - Send information about trust relationships with other stakeholders, e.g., full trust, partial trust, or trust metrics. Such a request may be a request to or from another peer orchestrator of another stakeholder. Such a request may be sent after applying relevant stakeholder specific policies.

[0100] In the following, a sequence flow chart for a method focusing on a peer-to-peer interaction between two stakeholders is described. In case of more than two stakeholders, the sequence of steps is applicable to the peer-to-peer interaction between more than two stakeholders.

[0101] Figure 2Depicted is the first part of an exemplary sequential flow chart for cross-stakeholder feasibility checks.

[0102] The steps in an exemplary first part of the sequence are as follows:

[0103] Step 0:

[0104] Build trust among stakeholders.

[0105] In an example, first stakeholder peer orchestrator 120 and stakeholder peer orchestrator 128 determine respective trust tables representing their full and partial trust relationships with other stakeholders, and the levels of such trust as reflected in the decay of the trust metric.

[0106] Step 1:

[0107] The cross-stakeholder intent manager 114 of the first entity 102 receives network intent, such as performance intent, from a customer.

[0108] Step 2:

[0109] The cross-stakeholder intent manager 114 of the first entity 102 translates the network intent into end-to-end network resource and service requirements.

[0110] For example, the attributes and attribute values ​​in Table 1 below can describe the translated end-to-end network resource and service requirements:

[0111]

[0112]

[0113] In Table 1, the service profile ID is specified. Subsequently, the number of users, coverage area and network requirements are given. Resources can also be optionally requested in terms of PRBs (physical resource blocks). The requesting operator then proposes a price per user or per PRB. The performance tolerance is the maximum allowed deviation from the requested performance, i.e. the throughput cannot be (average or instantaneous) less than 2% of the agreed throughput. In case it is not achieved, the parties need to agree on whether there is compensation for the service not received. Computing resources can also be negotiated. In this case, memory and cores need to be specified. In case ML support is required, the ML participation flag needs to be correctly activated.

[0114] Step 3:

[0115] The cross-stakeholder management and orchestration 116 of the first entity 102 receives the end-to-end resource and service requirements from the cross-stakeholder intent manager 114 of the first entity 102 .

[0116] Step 4:

[0117] The cross-stakeholder management and orchestrator 116 of the first entity 102 translates the end-to-end resource and service requirements into end-to-end machine learning requirements. According to an example, if the machine learning model is to be instantiated (e.g., managing or optimizing an instantiated end-to-end network service), the end-to-end machine learning requirements are determined.

[0118] For example, the attributes and attribute values ​​in Table 2a below may describe end-to-end network service requirements translated into end-to-end machine learning requirements, such as performance or configuration requirements:

[0119]

[0120] In addition, if the composition between different machine learning models is required to implement an end-to-end network service, for example, due to the required flexibility and reusability requirements, the corresponding machine learning composition requirements can be derived. For example, the attributes and their values ​​in Table 2b below can describe the translated end-to-end machine learning composition requirements:

[0121]

[0122] Furthermore, the cross-stakeholder management and orchestrator 116 of the first entity 102 may convert the end-to-end resource and service requirements into domain-specific resource and service requirements. In this context, domain-specific may be radio access network-specific or core-specific.

[0123] Step 5:

[0124] The cross-stakeholder machine learning orchestrator 118 of the first entity 102 receives the end-to-end machine learning requirements from the cross-stakeholder manager and orchestrator 116 of the first entity 102 .

[0125] Step 6:

[0126] The cross-stakeholder manager and orchestrator 116 translates the end-to-end machine learning requirements into radio access network or core network resource and service requirements.

[0127] Step 7:

[0128] The radio network management and orchestrator 134 of the first domain of the first stakeholder 104 receives the radio access network resource and service requirements from the cross-stakeholder manager and orchestrator 116 of the first entity 102. The core network management and orchestrator 140 of the second domain of the first stakeholder 106 receives the core network resource and service requirements from the cross-stakeholder manager and orchestrator 116 of the first entity 102.

[0129] Step 8:

[0130] The radio network management and orchestrator 134 of the first domain of the first stakeholder 104 translates the radio access network resource and service requirements into radio access network machine learning requirements.

[0131] The core network management and orchestrator 140 of the second domain of the first stakeholder 106 translates the core network resource and service requirements into core machine learning requirements.

[0132] Step 9:

[0133] The radio access network machine learning orchestrator 136 receives the radio access network machine learning requirements from the radio access network management and orchestrator 134 of the first domain of the first stakeholder 104 .

[0134] The core network machine learning orchestrator 142 receives the core machine learning requirements from the core network management and orchestrator 140 of the second domain of the first stakeholder 106 .

[0135] Step 10:

[0136] The cross-stakeholder machine learning orchestrator 118 of the first entity 102 translates the end-to-end machine learning requirements into radio access network machine learning and core machine learning requirements.

[0137] Step 11:

[0138] The radio access network machine learning orchestrator 136 of the first domain of the first stakeholder 104 receives the radio access network machine learning requirements from the cross-stakeholder machine learning orchestrator 118 of the first entity 102 .

[0139] The core network machine learning orchestrator 142 of the second domain of the first stakeholder 106 receives the radio access network machine learning requirements from the cross-stakeholder machine learning orchestrator 118 of the first entity 102 .

[0140] Step 12:

[0141] The cross-stakeholder machine learning orchestrator 118 of the first entity 102 receives a confirmation or a non-confirmation regarding the availability (ie, feasibility) of the radio access network machine learning requirement from the radio access network machine learning orchestrator 136 of the first domain of the first stakeholder 104 .

[0142] The cross-stakeholder machine learning orchestrator 118 of the first entity 102 receives a confirmation or a non-confirmation regarding the availability (ie, feasibility) of the core network machine learning requirement from the core network machine learning orchestrator 142 of the second domain of the first stakeholder 106 .

[0143] Step 13:

[0144] The cross-stakeholder machine learning orchestrator 118 of the first entity 102 receives a confirmation or a non-confirmation regarding the availability (ie, feasibility) of the radio access network machine learning requirement from the radio access network machine learning orchestrator 136 of the first domain of the first stakeholder 104 .

[0145] The cross-stakeholder machine learning orchestrator 118 of the first entity 102 receives a confirmation or a non-confirmation regarding the availability (ie, feasibility) of the core network machine learning requirement from the core network machine learning orchestrator 142 of the second domain of the first stakeholder 106 .

[0146] Step 14:

[0147] The cross-stakeholder manager and orchestrator 116 of the first entity 102 receives a confirmation or non-confirmation regarding the availability (ie, feasibility) of the radio access network resources and service requirements from the radio network management and orchestrator 134 of the first domain of the first stakeholder 104 .

[0148] The cross-stakeholder manager and orchestrator 116 of the first entity 102 receives a confirmation or disconfirmation regarding the availability (ie, feasibility) of the core network resources and service requirements from the core management and orchestrator 140 of the second domain of the first stakeholder 106 .

[0149] Step 15:

[0150] The cross-stakeholder manager and orchestrator 116 of the first entity 102 receives a confirmation or disconfirmation regarding the availability (ie, feasibility) of the end-to-end machine learning requirement from the cross-stakeholder machine learning orchestrator 118 of the first entity 102 .

[0151] The cross-stakeholder machine learning orchestrator 118 of the first entity 102 may receive a feasibility check report from the radio access network machine learning orchestrator 136 of the first domain of the first stakeholder 104 and / or from the core access network machine learning orchestrator 142 of the second domain of the first stakeholder 106. The cross-stakeholder machine learning orchestrator 118 of the first entity 102 may analyze whether the end-to-end machine learning requirement can be met and send a confirmation or non-confirmation of the requested end-to-end machine learning requirement accordingly. For example, the analysis may conclude that the first stakeholder may be able to support a portion of the end-to-end machine learning requirement and may need to rely on other stakeholders to support other portions of the end-to-end machine learning requirement.

[0152] Tables 2a and 2b provide examples for the requirements.

[0153] In an example, the cross-stakeholder machine learning orchestrator 118 of the first entity 102 and the cross-stakeholder machine learning orchestrator 126 of the second entity 108 negotiate via the peer orchestrator 120 of the first entity 102 and the peer orchestrator 128 of the second entity 108 .

[0154] The cross-stakeholder machine learning orchestrator 118 of the first entity 102 may receive a feasibility check report from the radio access network machine learning orchestrator 136 of the first domain of the first stakeholder 104 and / or from the core access network machine learning orchestrator 142 of the second domain of the first stakeholder 106. The cross-stakeholder machine learning orchestrator 118 of the first entity 102 may analyze whether the end-to-end machine learning requirements are met. For example, the analysis may conclude that the first stakeholder may be able to support a portion of the end-to-end machine learning requirements and may need to rely on other stakeholders to support other portions of the end-to-end machine learning requirements.

[0155] According to an example, the first stakeholder can provide the end-to-end resource and service requirements underlined in Table 3 below.

[0156]

[0157]

[0158] According to an example, other end-to-end resource and service requirements underlined in Table 4 below need to be provided by the second stakeholder or another stakeholder.

[0159]

[0160]

[0161] In the event that the end-to-end resource and service requirements and / or the end-to-end machine learning requirements cannot be met by the first stakeholder, step 16 is performed. Otherwise, step 18 is performed.

[0162] Step 16:

[0163] The cross-stakeholder management and orchestrator 116 of the first entity 102 and the cross-stakeholder management and orchestrator 124 of the second entity 108 negotiate regarding end-to-end resource and service requirements.

[0164] In an example, cross-stakeholder management and orchestration 116 of first entity 102 and cross-stakeholder management and orchestration 124 of second entity 108 negotiate via peer orchestration 120 of first entity 102 and peer orchestration 128 of second entity 108 .

[0165] Step 17:

[0166] The cross-stakeholder machine learning orchestrator 118 of the first entity 102 and the cross-stakeholder machine learning orchestrator 126 of the second entity 108 negotiate regarding the end-to-end machine learning service requirements.

[0167] Step 18:

[0168] The cross-stakeholder intent manager 114 of the first entity 102 receives a confirmation or disconfirmation regarding the availability (ie, feasibility) of the end-to-end resource and service requirements from the cross-stakeholder management and orchestration manager 116 of the first entity 102 .

[0169] The cross-stakeholder intent manager 114 of the first entity 102 may receive a feasibility check report from the cross-stakeholder management and orchestration manager 116 of the first entity 102 .

[0170] The cross-stakeholder intent manager 114 of the first entity 102 may analyze the feasibility report and determine whether the network intent can be met. If the cross-stakeholder intent manager 114 determines that the first stakeholder cannot meet the network intent, step 19 will be performed. Otherwise, step 20 is performed.

[0171] Step 19:

[0172] The cross-stakeholder intent manager 114 of the first entity 102 and the cross-stakeholder intent manager 122 of the second entity 108 negotiate regarding intent.

[0173] In an example, the cross-stakeholder intent manager 114 of the first entity 102 and the cross-stakeholder intent manager 122 of the second entity 108 negotiate via the peer orchestrator 120 of the first entity 102 and the peer orchestrator 128 of the second entity 108 .

[0174] Step 20:

[0175] The cross-stakeholder intent manager 114 of the first entity 102 sends a confirmation or a non-confirmation regarding the availability (ie, feasibility) of the network intent (eg, performance intent) to the client.

[0176] According to some embodiments, a request may be sent requiring steps where the corresponding machine learning model would be instantiated or otherwise omitted.

[0177] According to some embodiments, the step of sending a confirmation or a non-confirmation may include sending a confirmation if the corresponding machine learning model is instantiated or available for instantiation, or sending a non-confirmation in other ways.

[0178] 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 stations, core network functions), on what can or cannot be achieved with respect to the domain-specific machine learning requirements.

[0179] Figure 3 Depicts the second part of an exemplary sequential flow chart for cross-stakeholder feasibility checks. The second part includes Figure 2 The details of step 16 are depicted in FIG.

[0180] The steps in an exemplary second part of the sequence are as follows:

[0181] Step 16-1:

[0182] Cross-stakeholder management and orchestration 116 of first entity 102 invites peer orchestration 120 of first entity 102 to check whether another stakeholder can satisfy the unachievable end-to-end resource and service requirements.

[0183] In an example, cross-stakeholder management and orchestrator 116 of first entity 102 engages peer orchestrator 120 of first entity 102 after analyzing that the first stakeholder cannot fully meet end-to-end resource and service requirements.

[0184] Table 3 gives an example where the first stakeholder cannot fully satisfy the requirements for end-to-end resources and services.

[0185] Step 16-2:

[0186] Peer orchestrator 120 of first entity 102 performs discovery of other peer operators that can satisfy end-to-end resource and service requirements that cannot be fully satisfied by the first stakeholder.

[0187] Peer orchestrator 120 of first entity 102 performs discovery for end-to-end resource and service requirements given in Table 3, for example.

[0188] Peer orchestrator 120 of first entity 102 negotiates or interacts with corresponding peer orchestrators of other stakeholders.

[0189] In the example, peer orchestrator 120 of first entity 102 negotiates with peer orchestrator 128 of second entity 108 .

[0190] In the example, the negotiation is based on the established trust level, i.e., full trust, partial trust, or no trust. This means that the negotiation is only conducted with peer orchestrators that have at least a partial trust level.

[0191] Peer orchestrator 120 of first entity 102 may negotiate 1:1, ie, with one other peer orchestrator, or 1:N, ie, with N other peer orchestrators.

[0192] Step 16-3:

[0193] Peer orchestrator 120 of first entity 102 sends the required end-to-end resource and service requirements to peer orchestrator 128 of second entity 108 .

[0194] Step 16-4:

[0195] Peer orchestrator 128 of second entity 108 sends the required end-to-end resource and service requirements to cross-stakeholder management and orchestrator 124 of second entity 108 .

[0196] Additionally, information regarding offers or compensation in case the request was fulfilled or not fulfilled may also be included.

[0197] Step 16-5 through Step 16-16 are the same as Step 4 through Step 15 in Part I, except that these interactions occur with the second stakeholder instead of the first stakeholder.

[0198] Steps 16-17:

[0199] After receiving the feasibility check reports from the radio access network management and orchestrator 146, and the core network management and orchestrator 152, and the radio access network machine learning orchestrator 148, and the core machine learning orchestrator 154, the cross-stakeholder management and orchestrator 124 analyzes whether the requested end-to-end resource and service requirements requested by the peer orchestrator 128 of the second entity 108 can be met, and sends a confirmation or non-confirmation to the peer orchestrator 128 of the second entity 118 accordingly.

[0200] Based on the results of the feasibility check, peer orchestrator 128 of second entity 108 decides whether to accept the request. Peer orchestrator 128 of second entity 108 may also consider other criteria, such as the price.

[0201] Since requests may be sent to multiple stakeholders, peer orchestrator 128 of second entity 108 may also accept "sub-portions" of providing end-to-end resource and service requirements.

[0202] Steps 16-18:

[0203] Peer orchestrator 128 of second entity 108 sends to peer orchestrator 120 of first entity 102 a confirmation or non-confirmation of the end-to-end resource and service requirements requested from peer orchestrator 120 of first entity 102. Peer orchestrator 128 of second entity 108 may provide additional details regarding the agreement or contract for the collaboration.

[0204] The details may include, for example, costs, the validity of the contract, an indication of whether the penalties indicated are acceptable if certain terms of the contract are breached.

[0205] Peer orchestrator 120 of first entity 102 may receive a plurality of responses from other peer orchestrators, including peer orchestrator 128 of second entity 108 .

[0206] Peer orchestrator 120 of first entity 102 may decide which proposal or combination of proposals to accept based on responses received from one or more peer orchestrators.

[0207] Steps 16-19:

[0208] Peer orchestrator 120 of first entity 102 sends a confirmation or non-confirmation of peer collaboration with one or more peer orchestrators based on details provided by other more peer orchestrators.

[0209] Steps 16-20:

[0210] Peer orchestrator 120 of first entity 102 responds with a confirmation or a non-confirmation to cross-stakeholder management and orchestrator 116 depending on the information received in steps 16 - 18 .

[0211] Figure 4 Depicts the third part of an exemplary sequential flow chart for cross-stakeholder feasibility checking.

[0212] The third part includes Figure 2 The details of step 17 are depicted in FIG.

[0213] The steps in an exemplary third portion of the sequence are as follows:

[0214] Step 17-1:

[0215] After analyzing that the first stakeholder cannot fully meet the end-to-end machine learning requirements, the cross-stakeholder machine learning orchestrator 118 of the first entity 102 invites the peer orchestrator 120 of the first entity 102 to check whether other stakeholders can meet the end-to-end machine learning requirements that cannot be fully met by the first stakeholder.

[0216] Step 17-2:

[0217] The peer orchestrator 120 of the first entity 102 performs discovery of other peer stakeholders that can satisfy end-to-end machine learning requirements that cannot be fully satisfied by the first stakeholder.

[0218] Peer orchestrator 120 of first entity 102 negotiates or interacts with a corresponding peer orchestrator (e.g., peer orchestrator 128 of second entity) according to the established trust level (i.e., full trust, partial trust, or no trust). This means that the negotiation is only conducted with peer orchestrators with at least a partial trust level.

[0219] Peer orchestrator 120 of first entity 102 may negotiate 1:1, ie, with one other peer orchestrator, or 1:N, ie, with N other peer orchestrators.

[0220] Step 17-3:

[0221] Peer orchestrator 120 of first entity 102 sends the required end-to-end machine learning requirements to other peer orchestrators, in the example, peer orchestrator 128 of second entity 108 .

[0222] Tables 2a and 2b provide examples for end-to-end machine learning requirements.

[0223] Step 17-4:

[0224] Peer orchestrator 128 of second entity 108 sends the requested end-to-end machine learning requirements to cross-stakeholder machine learning orchestrator 126 of second entity 108 .

[0225] Step 17-5:

[0226] The cross-stakeholder machine learning orchestrator 126 of the second entity 108 translates the end-to-end machine learning requirements into radio access network machine learning requirements and core machine learning requirements.

[0227] Step 17-6:

[0228] Radio access network machine learning orchestrator 148 receives the radio access network machine learning requirements from cross-stakeholder machine learning orchestrator 126 of second entity 108 .

[0229] Core network machine learning orchestrator 154 receives core machine learning requirements from cross-stakeholder machine learning orchestrator 126 of second entity 108 .

[0230] Step 17-7:

[0231] The radio access network machine learning orchestrator 148 sends a confirmation or a non-confirmation regarding the radio access network machine learning requirement to the cross-stakeholder machine learning orchestrator 126 of the second entity 108 .

[0232] The core network machine learning orchestrator 154 sends a confirmation or a non-confirmation regarding the core machine learning requirement to the cross-stakeholder machine learning orchestrator 126 of the second entity 108 .

[0233] Step 17-8:

[0234] After receiving the feasibility check reports from the radio access network machine learning orchestrator 148 and the core network machine learning orchestrator 154, the cross-stakeholder machine learning orchestrator 126 of the second entity 108 analyzes whether the end-to-end machine learning requirements can be met, and accordingly sends a confirmation or non-confirmation of the requested end-to-end machine learning requirements to the peer orchestrator 128 of the second entity 108.

[0235] Step 17-9:

[0236] Peer orchestrator 128 of second entity 108 sends a confirmation or a non-confirmation to peer orchestrator 120 of first entity 102 regarding the end-to-end machine learning requirement requested from peer orchestrator 128 of second entity 108 .

[0237] Peer orchestrator 128 of second entity 108 may provide additional details.

[0238] The details may include, for example, costs, the validity of the contract, an indication of whether the penalties indicated are acceptable if certain terms of the contract are breached.

[0239] Step 17-10:

[0240] Peer orchestrator 120 of first entity 102 sends a confirmation or non-confirmation of peer collaboration based on the details provided by peer orchestrator 128 of second entity 108 in step 17-9.

[0241] Step 17-11:

[0242] Peer orchestrator 120 of first entity 102 responds with a confirmation or a non-confirmation to cross-stakeholder management and orchestrator 118 of first entity 102 depending on the information received in step 17 - 9 .

[0243] Figure 5 Depicts the fourth section of an exemplary sequential flow chart for cross-stakeholder feasibility checking.

[0244] Part 4 includes Figure 2 The details of step 19 are depicted in FIG.

[0245] The steps in an exemplary third portion of the sequence are as follows:

[0246] Step 19-1:

[0247] After analyzing that the first stakeholder cannot fully satisfy the network intent (eg, performance intent), cross-stakeholder intent manager 114 of first entity 102 invites peer orchestrator 120 of first entity 102 to check whether other stakeholders can satisfy the network intent that cannot be provided by the first stakeholder.

[0248] Step 19-2:

[0249] Peer orchestrator 120 of first entity 102 performs discovery of other stakeholders that can satisfy network intent that cannot be provided by the first stakeholder.

[0250] Peer orchestrator 120 of first entity 102 negotiates or interacts with a corresponding peer orchestrator (e.g., peer orchestrator 128 of second entity 108) according to the established trust level (i.e., full trust, partial trust, or no trust). This means that the negotiation is only conducted with peer orchestrators with at least a partial trust level.

[0251] Peer orchestrator 120 of first entity 102 may negotiate 1:1, ie, with one other peer orchestrator, or 1:N, ie, with N other peer orchestrators.

[0252] Step 19-3:

[0253] Peer orchestrator 120 of first entity 102 sends the required network intent to peer orchestrator 128 of second entity 108 that cannot be provided by the first stakeholder.

[0254] Step 19-4:

[0255] Peer orchestrator 128 of second entity 108 sends the required network intent to cross-stakeholder intent manager 122 of second entity 108 .

[0256] Step 19-5:

[0257] The cross-stakeholder intent manager 122 of the second entity 108 receives information from e.g. Figure 5 After receiving the feasibility check report on the required network intent, the network entity not shown in the figure analyzes whether the network intent can be met and sends a confirmation or non-confirmation on the requested network intent to the peer scheduler 128 of the second entity 108 accordingly.

[0258] Step 19-6:

[0259] Peer orchestrator 128 of second entity 108 sends a confirmation or non-confirmation of the requested network intent to peer orchestrator 120 of first entity 102 .

[0260] Peer orchestrator 128 of second entity 108 may provide additional details.

[0261] The details may include, for example, costs, the validity of the contract, an indication of whether the penalties indicated are acceptable if certain terms of the contract are breached.

[0262] Step 19-7:

[0263] Peer orchestrator 120 of first entity 102 sends a confirmation or non-confirmation of peer collaboration. The confirmation or non-confirmation may be based on the confirmation or non-confirmation or details provided by peer orchestrator 128 of second entity 108 in step 19-6.

[0264] Step 19-8:

[0265] Peer orchestrator 120 of first entity 102 responds with a confirmation or a non-confirmation to cross-stakeholder intent manager 114 depending on the information received in step 19 - 6 .

[0266] According to some embodiments, the peer orchestrator is responsible for determining and communicating the level of trust between stakeholders as input for translating and negotiating cross-stakeholder network and service performance requirements into stakeholder-specific network and service performance requirements, and translating and negotiating cross-stakeholder machine learning performance requirements into stakeholder-specific machine learning performance requirements. From a security perspective, the link between any two peer orchestrators in the stakeholder ecosystem may use standard authentication-based protocols, including but not limited to certificate-based authentication, and encryption may be used to ensure the integrity of information sent between any two peer orchestrators and prevent man-in-the-middle attacks thereon.

[0267] Definition and measurement of trust:

[0268] From a trust perspective, the trust between any two stakeholders can consist of two options: full trust resulting from a bilateral service level agreement (SLA) or partial trust, which is the transitive closure of full trust.

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

[0270] Partial trust: There is a partial trust relationship between stakeholder A and stakeholder M if and only if there exists a number n>0 and a set of stakeholders {stakeholder 1, …, stakeholder n} such that

[0271] 1. For all i s.t. 1 <= i < n, there is a full trust relationship between stakeholder i and stakeholder i + 1.

[0272] 2. There is a full trust relationship between stakeholder A and stakeholder 1. 3. There is a full trust relationship between stakeholder n and stakeholder M. · No trust: There is neither full trust nor partial trust between stakeholder A and stakeholder M.

[0273] In Figure 6 an example is shown.

[0274] Figure 6 A graph depicting stakeholders A, B, C, D, E, F, G, J is shown. The links shown indicate the existence of bilateral service level agreements: and thus, full trust relationships. For example, in Figure 6 it, A has a full trust relationship with each of B, D, G, while B has a full trust relationship with C, and so on. Stakeholders with full trust relationships are neighbors in the graph.

[0275] According to the example, a stakeholder has an associated trust decay table that lists its knowledge of the decay of its trust level with other stakeholders.

[0276] For the trust relationships in the above graph, the trust decay table for stakeholder A in the example is:

[0277] B 1

[0278] C 2

[0279] D 1

[0280] E 2

[0281] F 3

[0282] G 1

[0283] H 2

[0284] J 2

[0285] K ∞

[0286] K ∞

[0287] Discovery and trust establishment during operator ecosystem initialization:

[0288] To compute full and partial trust relationships in a peer-to-peer fashion, assume that no stakeholder has prior knowledge of the trust relationships of other stakeholders - i.e., the above graph topology is unknown. Moreover, given the peer-to-peer nature of the orchestration, assume that there is no centralized entity that will perform graph traversal computations.

[0289] According to an example, the algorithm for calculating these trust relationships is distributed or decentralized, and asynchronous in the case where the network domains are independent. To this end, a distance vector algorithm can be used to calculate trust relationships in a peer-to-peer manner when the stakeholder ecosystem is initialized.

[0290] 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 KW. Computer Networking: A Top-Down Approach. Eighthed. Hoboken: Pearson; 2021 Aspects of the standard distance vector algorithm are disclosed.

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

[0292] Once computed, the trust and decay tables are expected to be largely stable and thus usable when new network intents arrive at the cross-stakeholder intent manager.

[0293] Updates when SLA changes:

[0294] Whenever a new service level agreement is formed or withdrawn between two stakeholders, the trust and decay tables can be updated by recalculating the distance vector algorithm initiated by the node with the changed state, which leads to an eventual consistency of the trust table across all nodes' trust knowledge. Note that this trust table is first calculated at the initialization of the stakeholder ecosystem and then updated when a new SLA is created or an existing one is deleted, so it is always available when the intent arrives.

[0295] Discovery and trust building after intention arrives:

[0296] When a cross-stakeholder intent arrives at a stakeholder, that stakeholder needs to determine which stakeholder or stakeholders it should attempt to coordinate with. To do so, it will look up its trust table and trust decay table to determine which stakeholder it wants to contact on a 1-1 basis or a 1-N basis. Additionally, stakeholder-specific policies around trust can also be specified and applied, similar to router policies, for example, in Border Gateway Protocol BGP. These trust-related policies can specify what information and / or at what granularity to pass information to other stakeholders depending on full trust versus partial trust and trust decay levels.

[0297] Figure 7 Depicts a sequential flow chart for cross-stakeholder configuration of machine learning models.

[0298] Thus, a process for cross-operator deployment of machine learning models and creation of machine learning compositions is described. Such a process relies on the level of trust established and trust decay between the operators involved. Machine learning constructs can be created across stakeholders in order to leverage the best performing machine learning models available across multiple stakeholders, as well as to achieve better flexibility in building machine learning based solutions for specific use cases. Stakeholder-specific policies around trust will impact machine learning constructs, as these policies may affect which machine learning model parameters and configuration properties are shared, as well as the level of granularity of the information. For example, more detailed information will be shared between stakeholders with a full trust relationship, while fewer and fewer details may be shared as the level of trust decay increases.

[0299] Cross-stakeholder configuration consists of the following steps:

[0300] Step 7-1:

[0301] Based on the results of the cross-operator machine learning feasibility check, the cross-stakeholder machine learning orchestrator 114 requires the peer orchestrator 120 of the first entity 102 to put into operation feasible end-to-end machine learning requirements needed to implement the end-to-end machine learning requirements from the second stakeholder, such as in terms of capabilities, features, performance, or configuration. The end-to-end machine learning requirements can be expressed for individual machine learning models or machine learning model compositions, such as in the form of tables, such as Tables 2a and 2b.

[0302] Step 7-2:

[0303] Peer orchestrator 120 of first entity 102 sends a request for feasible end-to-end machine learning requirement implementation to a corresponding peer orchestrator, such as peer orchestrator 128 of second entity 108, depending on the established trust level (i.e., full trust, partial trust, or no trust). This means that the negotiation is only conducted with peer orchestrators with at least a partial trust level.

[0304] Peer orchestrator 120 of first entity 102 may negotiate 1:1, ie, with one other peer orchestrator, or 1:N, ie, with N other peer orchestrators.

[0305] Step 7-3:

[0306] The peer orchestrator 128 of the second entity 108 sends the end-to-end machine learning requirements to the cross-stakeholder machine learning orchestrator 122 of the second entity 108. Based on the established trust level and trust decay, the peer orchestrator 128 of the second entity 108 may additionally provide corresponding configuration policies. For example, if full trust is not established, only selected machine learning models or models deployed in selected domains may be used to meet the requirements.

[0307] Step 7-4:

[0308] The cross-stakeholder machine learning orchestrator 122 of the second entity 108 translates the received end-to-end machine learning requirements and other configuration policies, if applicable, into radio access network machine learning requirements and core machine learning requirements.

[0309] Step 7-5:

[0310] The cross-stakeholder machine learning orchestrator 122 of the second entity 108 sends the radio access network machine learning requirements to the radio access network machine learning orchestrator 148 and sends the core machine learning requirements to the core machine learning orchestrator 154 .

[0311] Step 7-6:

[0312] The radio access network machine learning orchestrator 148 configures the radio access network machine learning model or model components accordingly.

[0313] Radio access network machine learning orchestrator 148 may send the configuration information to cross-stakeholder machine learning orchestrator 122 of second entity 108 .

[0314] The core machine learning orchestrator 154 configures the core network machine learning model or model composition accordingly.

[0315] Core network machine learning orchestrator 148 may send configuration information to cross-stakeholder machine learning orchestrator 122 of second entity 108 .

[0316] Step 7-7:

[0317] The cross-stakeholder machine learning orchestrator 122 of the second entity 108 sends configuration information, which is forwarded to the peer orchestrator 120 of the first entity 102 via the peer orchestrator 128 of the second entity 108, and forwarded from the peer orchestrator 120 of the first entity 102 to the cross-stakeholder machine learning orchestrator 114 of the first entity 102.

[0318] The configuration information may be the configuration information received in step 6.

[0319] Configuration information can include the following:

[0320] Identification of machine learning models and machine learning model components trained and deployed to the first stakeholder.

[0321] Information about how to access deployed machine learning models and machine learning model components, e.g., Uniform Resource Locator (URL) information.

[0322] Information about how to access the deployed machine learning models and outputs composed of the machine learning models, e.g., Uniform Resource Locator (URL) information.

[0323] Figure 8 Depicts a sequential flow chart for reporting.

[0324] The report includes the following steps:

[0325] Step 8-1:

[0326] The cross-stakeholder intent manager 114 of the first entity 102 requests or subscribes to a network intent report from the cross-stakeholder intent manager 122 of the second entity 108 via the peer orchestrators 120 , 128 .

[0327] The request or subscription involves the second stakeholder having agreed to satisfy the network intent of the first stakeholder.

[0328] Step 8-2:

[0329] Once the second stakeholder determines whether the network intent is satisfied, the cross-stakeholder intent manager 122 of the second entity 108 sends a network intent report to the cross-stakeholder intent manager 114 of the first entity 102 via the peer orchestrators 120 , 128 .

[0330] The report may include details such as whether the intent was achieved, and if not, which specific aspect was not achieved, such as network service performance related, network resource related, machine learning performance, machine learning capability, or machine learning composition related.

[0331] Step 8-3:

[0332] The cross-stakeholder management and orchestrator 116 of the first entity 102 requests or subscribes to network service and resource performance reports from the radio access network management and orchestrator 134 and the core management and orchestrator 140. The request or subscription concerns network service and resource requirements that must be satisfied by the first stakeholder.

[0333] Step 8-4:

[0334] Once the radio access network management and orchestrator 134 and the core management and orchestrator 140 determine whether the network service and resource requirements are met, it sends a network service and resource performance report to the cross-stakeholder management and orchestrator 116 of the first entity 102. The report may include details such as achieved throughput, achieved latency, number of successful pdu sessions, number of users served, achieved coverage, computing or network resources utilized.

[0335] Step 8-5:

[0336] The cross-stakeholder management and orchestrator 116 of the first entity 102 requests or subscribes to a network service for resource performance reports from the cross-stakeholder management and orchestrator 124 of the second entity 108 via the peer orchestrators 120, 128. The request or subscription involves the second stakeholder having agreed to satisfy the network service and resource requirements of the first stakeholder.

[0337] Step 8-6:

[0338] The cross-stakeholder management and orchestration 124 of the second entity 108 aggregates the management and orchestration of the radio access network and the core management and orchestration (in Figure 8 Network service and resource performance reports received (not depicted).

[0339] Step 8-7:

[0340] The cross-stakeholder management and orchestration 124 of the second entity 108 sends the aggregated network service and resource performance report to the cross-stakeholder management and orchestration 116 of the first entity 102 via the peer orchestrators 120 , 128 .

[0341] Step 8-8:

[0342] The cross-stakeholder machine learning operator 118 of the first entity 102 requests or subscribes to machine learning performance or configuration reports from the radio access network machine learning orchestrator 136 and the core machine learning orchestrator 142. The request or subscription relates to machine learning performance or configuration requirements that must be met by the first stakeholder.

[0343] Steps 8-9:

[0344] Once the radio access network machine learning orchestrator 136 and the core machine learning orchestrator 142 determine whether the machine requirements are met, it sends a machine learning performance or configuration report to the cross-stakeholder machine learning operator 118 of the first entity 102. The report may include details such as the achieved accuracy, mean squared error, mean absolute error, or confusion matrix of one or more machine learning models.

[0345] Steps 8-10:

[0346] The cross-stakeholder machine learning operator 118 of the first entity 102 requests or subscribes to a machine learning performance or configuration report from the cross-stakeholder machine learning operator 126 of the second entity 108 via the peer orchestrators 120, 128. The request or subscription involves the second stakeholder having agreed to satisfy the machine learning performance or configuration requirements of the first stakeholder.

[0347] Steps 8-11:

[0348] The cross-stakeholder machine learning operator 126 of the second entity 108 gathers data from the radio access network management and orchestration and the core management and orchestration (in Figure 8 Received machine learning performance or configuration reports (not depicted).

[0349] Steps 8-12:

[0350] The cross-stakeholder machine learning operator 126 of the second entity 108 sends an aggregated machine learning performance or configuration report to the cross-stakeholder machine learning operator 118 of the first entity 102 via the peer orchestrators 120 , 128 .

[0351] Fig. 9 Schematically depicting a scenario of cross-stakeholder machine learning composition. The scenario is explained for operators as an example for stakeholders.

[0352] In scenario 900-1, a user equipment (UE) 902 is within the coverage of a terrestrial network (TN) and a non-terrestrial network (NTN), the terrestrial network (TN) supporting a first public land mobile network (PLMN) 904 of a first operator, and the non-terrestrial network (NTN) supporting a second PLMN 906 of a second operator's resources 908 of the first operator, including a first machine learning model (ML) 910 configured for quality of service (QoS) prediction, a second ML model 912 configured for traffic steering, and an orchestrator 914 of the first operator, which includes a cross-stakeholder management and orchestrator, a cross-stakeholder machine learning orchestrator, and a peer orchestrator of the first operator. Suddenly, the UE 902 joins a metaverse call that requires resources, or is out of the coverage area of ​​the TN. The first machine learning (ML) model 910 predicts QoS degradation for the UE 902, and provides this information to the second ML model 912. If the changes to the first ML model 910 and the second ML model 912 do not resolve the high throughput requirements or the need for extended coverage using the available first PLMN 904 resources, this will be detected by the first operator's cross-stakeholder management and orchestrator by monitoring network key performance indicators (KPIs). Additionally or alternatively, the operator 1's cross-stakeholder machine learning orchestrator may monitor the output of the QoS predictions and detect that the expected QoS degradation persists. 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.

[0353] The second operator's resources 916 include a third ML model 918 configured for quality of service (QoS) prediction, a fourth ML model 920 configured for business steering, and the second operator's orchestrator 922, which includes a cross-stakeholder management and orchestrator, a cross-stakeholder machine learning orchestrator, and a peer orchestrator of the second operator.

[0354] According to some examples, the third ML model 918 is configured to make QoS predictions for a specific UE with higher accuracy than the first ML model 910 .

[0355] The peer orchestrator of the first operator notifies the peer orchestrator of the second operator through the peer interface between the peer orchestrators, and also specifies the information about the predicted QoS degradation as the output of the first ML model 910. The peer orchestrator of the second operator can directly convey this information to the fourth ML model 920 in the second PLMN 906, or it will provide the information required to temporarily link the first ML model 910 and the fourth ML model 920. In this way, by using the output of the first ML model 910, the fourth ML model 920 can decide to enhance the existing connection via the first PLMN 904 with an additional connection via the second PLMN 906 (e.g., via NTN) in order to solve the coverage problem, or if possible, solve the throughput problem. Further, in the case where the third ML model 918 can provide the same or similar input to the fourth ML model 920, the fourth ML model 920 uses the output of the third ML model 918 as input data.

[0356] In the second scenario 900-2, the UE 902 may be within the coverage of only one NTN, for example, the second PLMN 906, and therefore the traffic steering may only rely on the third ML model 918 and the fourth ML model 920, and may be completed with the help of different satellite access. In the case of multiple NTN coverage, the same / similar process as in the first scenario 900-1 will be applied.

[0357] In the third scenario 900-3, when UE 902 moves toward the coverage area of ​​the third PLMN 924 in addition to the NTN coverage, UE 902 can initiate a voice call, and the available resources of the second PLMN 906 are sufficient for the voice call. In such a case, the third ML model 918 can predict that there will be no QoS degradation for UE 902.

[0358] The resources 926 of the third operator providing the third PLMN 924 include a fifth ML model 928 configured for quality of service (QoS) prediction, a sixth ML model 930 configured for traffic steering, and an orchestrator 932 of the third operator, which includes a cross-stakeholder management and orchestrator, a cross-stakeholder machine learning orchestrator, and a peer orchestrator of the third operator.

[0359] The peer orchestrator of the second operator informs the peer orchestrator of the third operator that there will be no QoS degradation for UE 902. The cross-stakeholder machine learning orchestrator of the second operator may send this information to the cross-stakeholder machine learning orchestrator of the third operator via the peer orchestrators of the second and third operators. Similar to the first scenario, the cross-stakeholder machine learning orchestrator of the third operator may convey this information directly to the matching sixth ML model 930 in the third PLMN 924, or it will provide the information needed to temporarily link the third ML model 918 and the sixth ML model 930. In this way, by using the output of the third ML model 918, the sixth ML model 930 may decide that no additional connection or traffic splitting is required by using the resources of the third PLMN 923. Since the fifth ML model 928 may be able to provide QoS predictions only with a certain delay, for example, once the UE enters the coverage area of ​​the third PLMN, the sixth ML model 930 may rely on the output from the third ML model 918 during the transition phase. Later, the sixth ML model 930 may rely on the output of the third ML model 918 or the fifth ML model 928 , depending on the accuracy or confidence of the predictions achieved.

[0360] Overall, ad hoc on-demand ML model chaining enables operators to collaborate efficiently to meet service requirements while optimizing resource consumption and total cost of ownership.

Claims

1. A first method for communication, comprising: Receiving (16-1, 17-1) a request at a first device (120) configured to manage or orchestrate network resources of a first stakeholder, determining, at the first device (120), at least a portion of the requirement that needs to be orchestrated with a second device (128), the second device being configured to manage or orchestrate network resources for a second stakeholder, and A request is sent (16-3, 17-3) to the second device (128) regarding at least a portion of the requirement to be orchestrated with the second device (128).

2. The method according to claim 1, characterized in that The requirement includes: network intent, network resources, network services, machine learning models, components of machine learning models, or information about a trust relationship between the first stakeholder and the second stakeholder.

3. The method according to any one of the preceding claims, characterized in that The requirements include: machine learning model performance or machine learning model configuration.

4. A method according to any one of the preceding claims, characterised in that The method includes: determining, sending, receiving or requesting reports about: network resources, service requirements, machine learning model performance or machine learning model configuration.

5. A second method for communication, comprising: receiving (16-1, 17-1) at a second device (128) from a first device (120) a request for at least a portion of a requirement to be orchestrated with the second device (128), the first device being configured to manage or orchestrate network resources of a first stakeholder, the second device being configured to manage or orchestrate network resources of a second stakeholder, determining, at the second device (128), at least a portion of the requirement that can be orchestrated with the second device (128), and A response to the request is sent (16-18, 17-9) to the first device (120).

6. The method according to claim 5, characterized in that The request includes: network intent, network resources, network services, machine learning models, components of machine learning models, or information about a trust relationship between the first stakeholder and the second stakeholder.

7. The method according to any one of claims 5 or 6, characterized in that The requirements include: machine learning model performance or machine learning model configuration.

8. The method according to any one of claims 5 to 7, characterized in that The method comprises: receiving a request from the first device (120) for a report regarding: network resources, service requirements, machine learning model performance, or machine learning model configuration, determining said report, and The report is sent to the first device (120).

9. The method according to any one of claims 5 to 8, characterized in that The method comprises: sending (16-4, 17-4) a request for at least a portion of the requirement to be orchestrated with the device (124, 126) of the second stakeholder, receiving (16-17, 17-8) a response to at least a portion of the requirement to be orchestrated from a device (124, 126) of the second stakeholder, and The response to the first device (120) is determined depending on the response from the device (124, 126).

10. A first device (120) for communication, wherein the first device comprises means for: Manage the network resources of the first stakeholders, Receive request, determining at least a portion of the requirement to be orchestrated with a second device (128), the second device being configured to manage or orchestrate network resources for a second stakeholder, and A request is sent (16-3, 17-3) to the second device (128) regarding at least a portion of the requirement to be orchestrated with the second device (128).

11. The first device (120) according to claim 10, characterized in that The requirement includes: network intent, network resources, network services, machine learning models, components of machine learning models, or information about a trust relationship between the first stakeholder and the second stakeholder.

12. The first device (120) according to any one of claims 10 or 11, characterized in that The requirements include: machine learning model performance or machine learning model configuration.

13. The first device (120) according to any one of claims 10 to 12, characterized in that The first device includes components for: determining, sending, receiving or requesting reports about: network resources, service requirements, machine learning model performance or machine learning model configuration.

14. A second device (128) for communicating, wherein the second device (128) comprises means for: Manage the network resources of the second stakeholders, receiving a request from a first device (120) regarding at least a portion of a requirement to be orchestrated with the second device (128), the first device being configured to manage or orchestrate network resources of a first stakeholder, determining, at the second device (128), at least a portion of the requirement that can be orchestrated with the second device (128), and A response to the request is sent to the first device (120).

15. The second device (128) according to claim 14, characterized in that The request includes: network intent, network resources, network services, machine learning models, components of machine learning models, or information about a trust relationship between the first stakeholder and the second stakeholder.

Images