Improvements in and relating to allocating bare-metal resources in microservice-based core networks

Abstract

Disclosed is a method of operating a telecommunication network to calculate a microservice instance-server mapping. The method comprises the steps of gathering information relating to a current load a

Description

The present invention relates to improved Control Plane (CP) / Use Plane (UP) procedures for a Microservice-based Core Network (Fifth Generation, 5G, and beyond). It also impacts Unified Data Management (UDM), Network Repository Function (NRF) and bare-metal resources. Driven by the necessity for an agile and flexible network, the 3rd Generation Partnership Project (3GPP) has redesigned the mobile core network for the 5th Generation (5G) of mobile communications systems in Rei. 15 of the applicable standard. The current design of the 5GC introduces a Service Based Architecture (SBA) with Cloud-Native thinking, where Network Functions (NFs) are loosely coupled, fine-grained services interconnected through a service bus and communicating through RESTful API interfaces. The resulting SBA of the 5GC is shown in Figure 1. While strict separation of the functions in 5GC enables innovation and brings elasticity to the network, the overhead induced by the inter-function communications of CP procedures limits the advantages to a great extent, as the majority of CP procedures involve services from multiple functions in the 5GC. Besides, the inter-communication overhead significantly contributes to the overall processing delay taking place in the CP, which may hinder the realization of the promised 5G Key Performance Indicators (KPIs). In this regard, an increasing effort has been devoted to proposing a new architecture for beyond 5G and 6G networks. This invention therefore relates to a microservice-based architecture for the core network in future releases of one or more 3GPP standard. The mobile core network architecture consists of a set of fine-grained microservices, cleanly separated in functionality, which interact in order to deliver 3GPP's CP and UP procedures. Throughout this application, various terms are used consistently and ensure clarity of definition, the following terms are defined: [Definition 1] A microservice is a self-contained logical entity processing one input request at a time. Each processed input generates one output request intended for another microservice. The output of a microservice is entirely determined by its inputs (stateless assumption). Microservices may communicate with other microservices in a plurality of communication patterns that shall entirely rely upon network interactions. [Definition 2] A microservice instance as a copy of a currently running microservice. [Definition 3] From the logic standpoint, an execution path is defined as a sequence of microservices implementing a procedure. From the point of view of a deployed system, an execution path instance is defined as the sequence of microservice instances implementing a procedure in a live system. [Definition 4] From the logic standpoint, an execution graph is defined as the union of the execution paths associated with all the procedures. From the point of view of a deployed system, an execution graph is defined the union of all the execution path instances across all the procedures. [Definition 5] A network link is akin to an edge in a directed graph. As such, if servers i and j are connected by a network link, separated load / capacity information is given for the i to j and j to i links. [Definition 6] Given an execution graph G, G consists of one weakly connected component if all the microservice instances are connected to each other by some path, ignoring the direction of edges. Graph G consists of multiple weakly connected components if it is possible to identify multiple subgraphs of G where all the microservice instances are connected to each other by some path, ignoring the direction of edges. An example of an execution graph consisting of two weakly connected components is given in Figure 2. [Definition 7] A bare-metal server both a physical or virtual machine that is capable of running one or more microservice instances. In addition, there are certain pre-requisites, which are assumed to be true: [Pre-Requisite 1] The functionalities associated with a service pertaining to an NF are mapped onto one or more microservices. [Pre-Requisite 2] The network interconnecting the available servers may be partitioned into a number of sub-networks, where a server may communicate with other servers pertaining to the same or a different sub-network. Servers do not take place in any intra- / extra-sub-network network traffic forwarding tasks, which are delegated to network switches and routers. We say that a direct network link exists between servers i and j (or equivalently, there is a direct link between i and j) if any of the following facts hold: • If i and j belong to the same sub-network, and i communicates with j via a number of switches (or none); • If i and j belong to two different sub-networks, and i communicates with j via a number of switches (or none) and one or more routers without their traffic having to go through a third sub-network; • If i is equal to j. As exemplified in Figure 3, in a microservice-based core network, from a logical standpoint, 3GPP's procedures are such that: • They may involve a large number of microservices; • The execution path may involve multiple "back and forth" interactions among the same microservices - thus, preventing the execution path from being modelled as a Directed Acyclic Graph (DAG). That is, in a typical core network deployment, it is reasonable to expect that: • Multiple instances of the same microservice are needed to fulfil the demand (to carry out each procedure); • Within the context of the same procedure, the number of instances associated with a microservice may differ from another. This is due to the nature of the task a microservice carries out or how it has been implemented. Note that the precise detail of what is disclosed in Figure 3 is unimportant; rather, note the complexity and interconnectedness. It is an aim of embodiments of the invention, to provide a method to prompt a function to dynamically partition the nodes (namely, microservice instances) of an execution graph into disjoined sets, and execute instances pertaining to each set onto a bare-metal server. In the greater context of 6G core networks, embodiments of the invention aim to enable the core to autonomously optimize its computational footprint by tracking the available bare-metal resources. This is particularly compelling when the bare-metal resource pool involves several mid- to low-end servers located at the edge to support low latency procedures - this is the case of the UE Registration procedure in massive access-type communication networks where hundreds of UEs may request to register to the network with tight latency constraints. According to the present invention there is provided an apparatus and method as set forth in the appended claims. Other features of the invention will be apparent from the dependent claims, and the description which follows. According to a first aspect of the present invention, there is provided a method of operating a telecommunication network to calculate a microservice instance-server mapping, the method comprises the steps of: gathering information relating to a current load and capacity of a plurality of servers and network links in the telecommunication network; using the information to calculate a microservice instance-server mapping when triggered to do so by a predefined trigger condition; and enacting the mapping in the telecommunication network, while live, and storing the mapping into a first database. In an embodiment, gathering information relating to a current load and capacity of a plurality of servers and network links comprises gathering information relating to a current load and capacity of all servers and network links in the telecommunication network. In an embodiment, the step of gathering may be performed periodically or on-demand. In an embodiment, there is further provided the step of selection of a microservice instance partition and selection of a server. In an embodiment, the first database is a Procedure Execution Graph, PEG, database. In an embodiment, there is further provided the step of updating second and third databases with the gathered load and capacity information. In an embodiment, the second and third databases are a Bare-metal Resource Pool, BRP, database and a Server Connectivity Map, SCM, database respectively. In an embodiment, the step of using the information to calculate a microservice instanceserver mapping is performed by a Microservice Orchestration Function, MOF. In an embodiment, the telecommunication network is a 5G or6G network. According to a second aspect of the present invention, there is provided an apparatus arranged to perform the method of the first aspect. Embodiments of the invention provide apparatus and methods to map microservice instances onto bare-metal servers in a network (e.g. 5GC) relying upon a microservice-based architecture. Advantageously, embodiments of the invention provide a definition of MOF responsible for calculating the microservice instance-server mapping and enacting the aforementioned mapping in a live system. Embodiments also define a PEG database (part of UDM), which contains the execution graph of every User Plane (UP) / Control Plane (CP) procedure. In addition, PEG records the microservice execution graph currently enacted in the system. Embodiments further define a BRP database (part of UDM), which contains the current load and maximum capacity of each bare-metal server and an SCM database (part of UDM), which contains a graph-based representation of the network links among servers, their current loads, and capacities. Embodiments described herein are particularly beneficial in heterogeneous bare-metal deployments that may include both high-performance servers in centralized locations along with edge-based servers with reduced computational resources. In this context, MOF is responsible for mapping multiple microservice instances onto a given set of servers without violating either the maximum server computational or network capacities. Furthermore, MOF may fulfil a plurality of optimization criteria, including but not limited to: • Minimization of network traffic among servers • Maximization of the bin-packing efficiency of computational resources. In an NF-based core network and within the context of a procedure, the decision of which NF instance another NF instance should direct its output to is informed by the NRF, which enables each NF instance to discover suitable instances of the NF that comes next in the procedure. Similar considerations apply when SOP is used. Embodiments of this invention rely upon an extension of the NRF and SCP to microservice-based core network architectures. As such, note that, similarly to what happens in an NF-based 5GC, the NRF and SCP will need to keep track of / inform relevant subscribers / route requests among microservice instances wishing to register, de-register, and change their profile. Finally, note that embodiments of this invention are compatible with all the NRF communication models (Model A, B, C, and D) disclosed in “3GPP Technical Specification Group Services and System Aspects, "3GPP TS 23.501: System architecture for the 5G System (5GS) Stage 2 (Release 17) v.17.6.0," Technical Specification, October 2022.” Regardless of the fact that NF-based or microservice-based 5GCs are in use, prior art systems make it possible for an NF or a microservice to be packaged as a single software image (e.g., Docker image) and run as single or multiple instances (e.g., Kubernetes replica pods) depending on the requested load. This functionality is typically achieved by means of Kubernetes horizontal pod autoscaler. Since each instance shall run on the same bare-metal server, this makes it hard for current auto-scaling solutions to efficiently accommodate (potentially) resource-hungry instances onto bare-metal servers efficiently. As such, this may result to the situation shown in Figure 4 where monolithic instances A, B and C can be accommodated onto bare-metal server 1 and instance D is run in bare-metal server 2 - thus, leaving server 1 with a non-negligible amount of available resources that are not enough to accommodate any other monolithic instance (this phenomenon is also known as bin packing inefficiency). Embodiments of the present invention provide an extension of the Network Repository Function (NRF) to microservice-based core networks. It further provides an extension of the Unified Data Management (UDM) entity to include the following structured databases: • Procedure Execution Graph (PEG) database - Microservice-based execution graph of every User Plane (UP)ZControl Plane (CP) procedure along with the flow generated by each microservice. In addition, PEG records the microservice execution graph currently enacted in the system. • Bare-metal Resource Pool (BRP) database - Current load (including but not limited to CPU usage, memory allocated, storage allocated) and maximum load (capacity) that can be allocated in any of the bare-metal servers (including but not limited to the maximum CPU, Memory footprints that can be allocated at any given time). • Server Connectivity Map (SCM) database - Graph-based description of the network links interconnecting the bare-metal servers. Each network link is associated with its current flow (intended as a measure of the amount of data that can be transferred over a link during a given time interval) and capacity (intended as the maximum flow that can be accommodated over a link at any given time). • Definition of the Microservice Orchestration Function (MOF), which is a novel network function responsible for the following: o Carrying out a periodic / event-driven monitoring of the BRP and SCM databases to assess the load experienced by the bare-metal servers and the flow circulating over all the network links. o Interrogating the PEG database to acquire the microservice execution graph currently enacted in the system. o Potentially re-calculating the mapping microservice instance-server for some or all the microservice instances. That is, MOF is in charge of mapping / re-mapping microservice instances on bare-metal servers (that may be physical or virtual machines) to fulfill a plurality of optimization criteria, including but not limited to: ■ Minimization of network traffic among servers ■ Reduction of the overall amount of processing resources (CPU, Memory, storage, etc.) that is regarded as idle in servers where at least one microservice instance is running, i.e., maximization of the bin-packing efficiency. Along with an extension to the UDM (under the form of the PEG, BRP, and SCM databases), embodiments provide a new control plane entity, the MOF, to carry out a period / event-driven monitoring of the BRP and SCM databases to assess the load experienced by the bare-metal servers and the flow currently circulating over all the network links. In addition, MOF is responsible for re-calculating the mapping microservice instance-server for some or all the microservice instances to fulfil a plurality of programmable optimization criteria and feasibility constraints (e.g., server / network capacity constraints). Due to Pre-Requisite 1, above, 5GC procedures are enacted by a network of microservice instances. Embodiments do not concern themselves with how microservice instances are implemented in a live system. In particular, one or more microservices may be grouped into the same container or pod. Despite the focus of embodiments beyond the current state-of-the-art and 5G standardization efforts, embodiments do have applicability to a state of the art 5GC. At the same time, as standardization efforts move beyond 5G, the current state-of-the-art on 6G clearly shows a focus on the self-optimisation of bare-metal and network resources. As such, adopting MOF according to an embodiment of this invention would unlock this capability in the core. Although a few preferred embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes and modifications might be made without departing from the scope of the invention, as defined in the appended claims. For a better understanding of the invention, and to show how embodiments of the same may be carried into effect, reference will now be made, by way of example only, to the accompanying diagrammatic drawings in which: Figure 1 shows a High-level model of the 5GC known in the art; Figure 2 shows a microservice-based implementation of the execution graph associated with the UE, known in the art; Figure 3 shows a microservice-based implementation of the execution graph associated with the UE Registration procedure, known in the art; Figure 4 shows an example of mapping NF or microservice instances onto two bare-metal server; Figure 5 shows a call graph for updating BRP and SOM databases according to an embodiment of the invention; Figure 6 shows a general procedure for carrying out a Microservice Instance-Server Mapping task according to an embodiment of the invention; Figure 7 shows a general flowchart for carrying out the Microservice Instance-Server Mapping task of Figure 6; Figure 8 shows a simplified procedure for carrying out the Microservice Instance-Server Mapping task according to an embodiment of the invention; Figure 9 shows a general flowchart for carrying out the simplified Microservice Instance-Server Mapping task of Figure 8; Figure 10 shows an execution graph according to an embodiment of the invention; and Figure 11 shows a microservice instance-server mapping solution according to an embodiment of the invention. Throughout this application, the following notation is used: • SetS = {1, ..., |S|} consists of the available servers; • E is a |S| x |S| matrix where the (i,j)-th element ey is equal to 1 if a network link is present between servers i and j, and 0, otherwise; if i is equal to j, eij is assumed to be equal to 1 - thus, signifying the capability that each server has to communicate with itself; • The server capacities are listed in set R = {n, ..., qsi}, where vector ri is associated with server i and consists of (but not limited to) the maximum CPU, Memory footprints that can be allocated at any given time on server i. In a similar fashion, we define R' as the server's current load; • Element mj of the |S| x |S| matrix N as the capacity associated with the link connecting server i to server j; mj is equal to 0 if eij is null. In a similar fashion, we define N' as the matrix defined by the current flow circulating on each link; • M is the set of microservice instances forming the nodes of an execution graph; • C is a |M| x |M| matrix where element V[i,j] is equal to 1 if microservice instance i generates outputs directed towards microservice instance j, 0 otherwise. V is calculated on the basis of the information contained in the PEG database. Figure 5 shows the call graph followed by each server i (for i in the server list S) to update the BRP and SOM (both part of UDM) with: • The current load (including but not limited to CPU usage, memory allocated, storage allocated) experienced i, r) (and averaged over a given time interval), and maximum load (server capacity) n that can be allocated in server i (including but not limited to the maximum CPU, Memory, etc. footprints that can be allocated at any given time); • The list of servers that can be reached via a direct link by server i; • The current flow (averaged over a given time interval) that i receives from server j (njj), for j in the list of the servers that can directly communicate to i; • The estimated capacity (n'jj) associated with the link connecting server j to i (being j capable of directly communicating to i). The graph-based description <S,E,R,R',N, N'> of the network links interconnecting the bare-metal servers to be recorded into SCM is iteratively built on the basis of the information listed above (last three bullet points). In particular, this translates into the following procedure: • Steps 1-3 are repeated for each server i in S; • In Step 1, server i periodically refreshes the list of one-hop neighboring servers (discoverNeighbors()). The neighbor discovery phase may take place in a plurality of methods including but not limited to: o Access a pre-configured list of neighbors stored in i: o Instructing server i to query an internal routing agent; o Instructing server i to record the URIs of all the servers that it might have send / received from traffic in a given time interval; The data rate (averaged over a given period of time) associated with network traffic originating from server j (one-hop neighbor of server i) constitutes the current load of link j-i. The capacity of link j-i can be established in a plurality of methods including but not limited to: o By setting the capacity of a link equal to the maximum receiving rate that can be supported by server i - this information can be obtained by instructructing server i to query its Operating System; o By actively probing the capacity of each link during the commissioning phase of a server and / or a new section of the network. • In Step 2, server i calculates its load, averaged over a given time interval, (getLoadf)) across a plurality of performance measurements (including but not limited to CPU, memory and storage footprints); • In Step 3, server i communicates to the UDM (updateLoad()y. o Its current load and capacity o The list of discovered one-hop neighbors along where the current load and capacity associated with the links originating from any all the neighbors of server i and directed to server i. UDM then proceeds to update the BRP database with the aforementioned information. • In Step 4, when all the servers in S or at least a preconfigured fraction of them have completed Step 3, the server and network link load / capacity information, along with the list of links discovered by each server are brought together in a graph-type structure (computeNetGraph()) that is then recorded in the SCM database (updatedNetGraph()). We observe that the UDM-Server i communication may take place in a plurality of abstraction layers (including but not limited to): • network functions virtualization management and orchestration (NFV-MANO). The microservice instance-server mapping task is carried out by the MOF. The mapping task may be triggered by any (but not limited to) of the following criteria: • Periodically; • Event-basis - This is the case where a third-party entity in the core, including but not limited to, a load-balancer (for microservice-based cores) calculates an execution graph to be mapped onto the available bare-metal servers. Given an execution graph <M,C> that may be currently enacted in a live system or that may be the result of the calculations made by a load-balancing service, the microservice instanceserver mapping task shall fulfill at least the following constraints: • C1 Microservice instances mapped onto a server cannot exceed its capacity; • 02 Microservice instances that are expected to communicate can only be mapped onto the same server or onto servers that can directly communicate with each other; • C3 The flow of each network link (connecting different servers) shall always be smaller than or equal to its capacity. The microservice instance-server mapping procedure (msServerMapper) is summarized in Figure 6 and Figure 7 and consists of the following key steps: • The procedure is formulated in a recursive fashion. As such, it begins with an if-then statement (line 2) designed to halt the recursive step if the procedure's input is an execution graph made of a single node, i.e., a single microservice instance. If this happens, it means that during the previous recursion step, it was not possible to find a server suitable to accommodate the aforementioned microservice instance. As such, no valid solution to the microservice instance-server mapping task can be found, and an error is returned. • Otherwise, given the execution graph <M,C> provided as input to the procedure, set M is partitioned (line 4) into two disjoined sets (M1 and M2) via a plurality of criteria including but not limited to what follows: o The partition takes place according to the min-K-cut principle aiming at establishing a cut in <M,C> associated with the minimum capacity (having the flow among microservices instances being recorded in the PEG database). • Then the procedure attempts to select a server with ID srvld (among those fulfilling constraints C1-C3) capable of running all the microservices instances in M1 (line 5) via a plurality of criteria including but not limited to any of the following ones: o Best-Fit-First - The first server in a list of servers, sorted in ascending order (priority given to currently available CPU over other load measures); o Current Load Equalization - The server selection is carried out in such a way that the overall load of each server is equalized. If no server can be found (line 7), the procedure msServerMapper is re-run with input <M1,C1>, where C1 is a |M11 x |M11 matrix where element M1[ij] is equal to 1 if microservice instance i generates outputs directed towards microservice instance j, 0 otherwise (for i and j in M1). Otherwise, if a valid server is found, the procedure stores the pair (srvld, M1) for later use. • Similar considerations can be made for set M2 (lines 10-14). Potentially, it is possible to simplify the microservice instance-server mapping as described in Figure 8 and the following. In a first case, the execution graph <M,C> consists of a single microservice instance (i.e., |M| = 1), no recursion is needed and the msServerMapper procedure can be simplified as per Figure 8 and Figure 9. In a second case, there is a bare-metal server capable of running the entire execution graph, the msServerMapper procedure will try and partition its nodes into two sets. However, a valid mapping will be returned for both subgraphs, which will coincide with the same server ID. We observe that cases 1 and 2, above, account for purely theoretical scenarios, which are unlikely to arise in a practical system, and the remarks above are presented only for the sake of completeness. In order to give a sense of how the aforementioned procedure operates, consider the following example: • One procedure is considered with ID 1; • The procedure involves two microservices with IDs 1 and 2; • Microservice 1 generates outputs for microservice 2; • There are two instances for each microservice. • Two servers with IDs 1 and 2 are present. Both servers are interconnected via a network link. For simplicity, assume that links have unlimited capacity; • Regardless of the microservice, in this example, each server can only run two microservice instances. • That is, the notation mentioned above takes on the following values: • P = {1}; • M = {microservice-1-instance-1, microservice-1-instance-2, microservice-2-instance-1, microservice-2-instance-2}; • C is an all-zero 4x4 matrices except for the (1,3)-th and (2,4)-th elements that are set equal to 1; • E is an all-one 2x2 matrix. Assume that the microservice instance partition takes place according to the min-K-cut, and that the server selection follows the best-fit-first criteria. According to the logic summarized in the flowchart in Figure 9, set M is going to be partitioned, but since the execution graph <M,C> is made of two weakly connected components (see Figure 10 and Definition 6), the min-K-cut criterion returns the following: • M1 = {microservice-1-instance-1, microservice-2-instance-1} • M2 = {microservice-1-instance-2, microservice-2-instance-2} As mentioned above, for the sake of this example, it is assumed that each server can run up to two microservice instances. Hence, the best-fit-first server selection decides that the microservice instances contained in M1 can be accommodated in server 1. Similarly, all the instances in M2 can be accommodated in the only remaining server, which is 2. This leads to the microservice instance-server mapping solution shown in Figure 11. It is worth noting that MOF may decide to update the microservice instance-server mapping by enacting a newly calculated solution (obtained utilizing the procedure in Figure 8 and Figure 9) in a plurality of ways (including but not limited to): REST-based interaction with container / pod management entities (such as k8s). In particular, if the microservice instance-server mapping currently running onto the system is identical or sufficiently similar to a newly calculated mapping, MOF may decide not to update the live system. Conversely, if a newly calculated mapping is enacted onto a live system, the new mapping is also stored in the PEG database. At least some of the example embodiments described herein may be constructed, partially or wholly, using dedicated special-purpose hardware. Terms such as ‘component’, ‘module’ or ‘unit’ used herein may include, but are not limited to, a hardware device, such as circuitry in the form of discrete or integrated components, a Field Programmable Gate Array (FPGA) or Application Specific Integrated Circuit (ASIC), which performs certain tasks or provides the associated functionality. In some embodiments, the described elements may be configured to reside on a tangible, persistent, addressable storage medium and may be configured to execute on one or more processors. These functional elements may in some embodiments include, by way of example, components, such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables. Although the example embodiments have been described with reference to the components, modules and units discussed herein, such functional elements may be combined into fewer elements or separated into additional elements. Various combinations of optional features have been described herein, and it will be appreciated that described features may be combined in any suitable combination. In particular, the features of any one example embodiment may be combined with features of any other embodiment, as appropriate, except where such combinations are mutually exclusive. Throughout this specification, the term “comprising” or “comprises” means including the component(s) specified but not to the exclusion of the presence of others. Attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and / or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and / or steps are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features. The invention is not restricted to the details of the foregoing embodiment(s). The invention extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed.

Claims

1. A method of operating a telecommunication network to calculate a microservice instance-server mapping, the method comprises the steps of:a) gathering information relating to a current load and capacity of a plurality of servers and network links in the telecommunication network;b) using the information to calculate a microservice instance-server mapping when triggered to do so by a predefined trigger condition; andc) enacting the mapping in the telecommunication network, while live, and storing the mapping into a first database.

2. The method of claim 1 wherein gathering information relating to a current load and capacity of a plurality of servers and network links comprises gathering information relating to a current load and capacity of all servers and network links in the telecommunication network.

3. The method of claim 1 or 2 wherein the step of gathering may be performed periodically or on-demand.

4. The method of any preceding claim further comprising selection of a microservice instance partition and selection of a server.

5. The method of any preceding claim wherein the first database is a Procedure Execution Graph, PEG, database.

6. The method of any preceding claim further comprising updating second and third databases with the gathered load and capacity information.

7. The method of claim 6 wherein the second and third databases are a Bare-metal Resource Pool, BRP, database and a Server Connectivity Map, SCM, database respectively.

8. The method of any preceding claim wherein the step of using the information to calculate a microservice instance-server mapping is performed by a Microservice Orchestration Function, MOF.

9. The method of any preceding claim wherein the telecommunication network is a 5G or 6G network.

10. Apparatus arranged to perform the method of any preceding claim.

Images