EP4690721A1

EP4690721A1 - Method for generating service graphs from high-level intents

Info

Publication number: EP4690721A1
Application number: EP23720177.7A
Authority: EP
Inventors: Sasan SABOUR; Fetahi WUHIB; Amin EBRAHIMZADEH; Roch Glitho
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2023-03-30
Filing date: 2023-03-30
Publication date: 2026-02-11
Also published as: WO2024201109A1

Abstract

The disclosure relates to a computer implemented method, a system, and a non-transitory computer readable media, for generating service graphs from high-level intents and for configuring a service and allocating resources according to a service graph selected among the generated service graphs. The method comprises translating the high-level intents into low-level intents using a domain ontology. The method comprises generating a compatible graph based on the low-level intents and based on a service catalog. The method comprises generating the service graphs based on the compatible graph. The method comprises configuring the service according to the service graph selected among the generated service graphs. The method comprises allocating computing resources for executing the configured service.

Description

METHOD FOR GENERATING SERVICE GRAPHS FROM HIGH-LEVEL

INTENTS

TECHNICAL FIELD

[0001] The present disclosure relates to a method for generating service graphs from high-level intents.

BACKGROUND

[0002] The concept of intents was introduced in the context of Intent-Based Networking (IBN), where a new paradigm was introduced to bring intelligence to traditional networks. In traditional networks, only users with technical knowledge (e.g., network administrator) can configure the network. Interestingly, IBN has made it possible for users with limited network knowledge to declare their requirements (also referred to as intent) in natural language. The intelligence in IBN indicates that users send what they want as a request (e.g., "I need a connection with high quality"), and the IBN solution translates it to configurations and performs the user's intent. [0003] An intent is the user’s request at a high-level of abstraction, which describes what the user wants. More specifically, the intent is about WHAT the user wants to be done rather than HOW it can/should be done. For example, the statement “all incoming video data is encoded” represents the WHAT, while the statement “once a video data enters to the network, encode it to MP4” represents the HOW.

[0004] Intents can be categorized into two types: low- and high-level intents. A high- level intent is the user’s request at a high-level of abstraction (e.g., natural language), which needs to be translated to be understandable by the machine, whereas the low- level intent is the translation of the user’s request to machine language (e.g., Resource Description Framework (RDF)). Therefore, a high-level intent needs to be translated to low-level intent by extracting functional and non-functional requirements of the user’s request. Functional Requirements (FRs) represent what a user requests to be done (e.g., having a secure connection between two points), and Non-Functional Requirements (NFRs) specify the quality of that request (e.g., level of security or quality of connection).

[0005] As the name implies, IBN is generally used for network-based services. A common way to implement these network services is by using Network Functions Virtualization (NFV). NFV allows network functions, which previously required proprietary hardware, to be implemented in software that runs on general-purpose hardware. In NFV, Virtual Network Functions (VNFs) are traditional Network Functions (NFs) that can be run as virtualized network functions. A VNF -Forwarding Graph (VNF-FG) consists of an ordered set of VNFs, which are needed to meet the requirements of the given network service. The concept of specifying network services in terms of VNF-FG can be generalized to any application that follows the service-based architecture (SB A).

[0006] In this context, a service graph is a directed graph containing a set of nodes and links, where the nodes and links represent services (e.g., VNFs, microservices, etc.) and connection between them, respectively. Services are composed according to the user intent, which includes FRs and NFRs, and each service graph consists of an ordered set of services, but unlike VNF-FGs, which contain only VNFs, service graphs contain services including VNFs as well.

[0007] A key challenge in intent-based management concerns determining a service graph which can fulfill the requirements in the intent. Today, these graphs are specified manually by an expert versed in the application/network service in question, which results in slow, erroneous and subpar graphs being used to attempt and fulfill the intents.

SUMMARY

[0008] There is provided a computer implemented method for generating service graphs from high-level intents and for configuring a service and allocating resources according to a service graph selected among the generated service graphs. The method comprises translating the high-level intents into low-level intents using a domain ontology. The method comprises generating a compatible graph based on the low- level intents and based on a service catalog. The method comprises generating the service graphs based on the compatible graph. The method comprises configuring the service according to the service graph selected among the generated service graphs. The method comprises allocating computing resources for executing the configured service.

[0009] There is provided a system for generating service graphs from high-level intents and for configuring a service and allocating resources according to a service graph selected among the generated service graphs. The system comprises processing circuitry and a memory, the memory containing instructions executable by the processing circuitry. The system is operative to translate the high-level intents into low-level intents using a domain ontology. The system is operative to generate a compatible graph based on the low-level intents and based on a service catalog. The system is operative to generate the service graphs based on the compatible graph. The system is operative to configure the service according to the service graph selected among the generated service graphs. The system is operative to allocate computing resources for executing the configured service.

[0010] There is provided a non-transitory computer readable media having stored thereon instructions for generating service graphs from high-level intents and for configuring a service and allocating resources according to a service graph selected among the generated service graphs. The instructions comprise translating the high- level intents into low-level intents using a domain ontology. The instructions comprise generating a compatible graph based on the low-level intents and based on a service catalog. The instructions comprise generating the service graphs based on the compatible graph. The instructions comprise configuring the service according to the service graph selected among the generated service graphs. The instructions comprise allocating computing resources for executing the configured service.

[0011] The method and system provided herein present improvements to the way generation of service graphs from high-level intents operate.

BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 is a block diagram presenting a general overview of the proposed intelligent resource management framework.

[0013] Figure 2 is a block diagram illustrating a user request translated to Resource Description Framework (RDF).

[0014] Figure 3 is a block diagram illustrating a domain ontology.

[0015] Figure 4 is a block diagram presenting a service graph generation architecture with "Translated intent" as input and "Candidate Service Graphs” as output, including an optional step for network-related service graph generation.

[0016] Figure 5 is a flowchart of a method for generating a compatible graph. [0017] Figure 6 is a flowchart of a method for generating service graphs.

[0018] Figure 7 is a schematic illustration of an updated graph G after adding the compatible services of “holo-generator”. [0019] Figure 8 is a schematic illustration of the updated graph G after adding the compatible services of “holo-display”.

[0020] Figure 9 is a schematic illustration of the updated graph G after adding the compatible services of “holo-encoder”.

[0021] Figures 10a to 10c present schematic illustrations of the updated graph G and the Q status at each step of the Compatible Graph Generation (CGG).

[0022] Figure 11 is a schematic illustration of the compatible graph generated from graph G, which starts from source “holo-generator”, and which has for destinations “holo-display” and “storage”.

[0023] Figure 12 is a schematic illustration of a clique, which contains two arrangeable services data packet inspection (DPI) and intrusion prevention system (IPS) which can be arranged as DPI then IPS or IPS then DPI.

[0024] Figure 13 is a schematic illustration of three service graphs generated from the graph of figure 11, with a combination of a first path in that goes from “hologenerator” to “holo-display” and all possible second paths that go from “hologenerator” to “storage”.

[0025] Figure 14 is a schematic illustration showing one example of the existence of two paths from “holo-generator” to “holo-display”, which is generated from figure 11, from a combination of the second path in the set of “holo-generator” to “holo-display” paths, with the third path in the set of “holo-generator” to “storage” paths.

[0026] Figures 15a and 15b present schematic illustrations of different service graphs, generated from the graph of figure 11, which start from source “holo-generator”, and which have for destinations “holo-display” and “storage”.

[0027] Figure 16 is a flowchart of a method for network-related service graph generation (NRSGG).

[0028] Figures 17a and 17b are schematic illustrations of: (17a) all relations between services in network-related service catalog by starting from a “src-mobile”, and (17b) a resulting compatible graph, for network-related from “src-mobile” to “dst-wifi”.

[0029] Figure 18 is a schematic illustration of two service graphs having for source "mobile" and for destination "wifi".

[0030] Figure 19 is a flowchart of a method for generating service graphs from high- level intents and for configuring services and allocating resources according to a service graph selected among the generated service graphs. [0031] Figure 20 is a schematic illustration of a hardware in which steps and/or method described herein can be executed.

[0032] Figure 21 is a schematic illustration of a virtualization environment in which the different steps and hardware components described herein can be deployed.

DETAILED DESCRIPTION

[0033] Various features will now be described with reference to the drawings to fully convey the scope of the disclosure to those skilled in the art.

[0034] Sequences of actions or functions may be used within this disclosure. It should be recognized that some functions or actions, in some contexts, could be performed by specialized circuits, by program instructions being executed by one or more processors, or by a combination of both.

[0035] Further, computer readable carrier or carrier wave may contain an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein.

[0036] The functions/actions described herein may occur out of the order noted in the sequence of actions or simultaneously. Furthermore, in some illustrations, some blocks, functions or actions may be optional and may or may not be executed; these are generally illustrated with dashed lines.

[0037] At least some aspects of the techniques described herein may be implemented using artificial intelligence, which comprises a variety of techniques as would be apparent to a person skilled in the art, including machine learning techniques.

[0038] In addition to the user’s lack of network knowledge discussed previously, other problems exist with the current state of the art.

[0039] 1) VNF selection and chaining: selecting appropriate VNFs based on the requested use-case and chaining these VNFs to realize the user intent are current problems. 2) Service graphs generation with minimum information: in real-world scenarios, there may be non-technical users with limited knowledge about the network who communicate with the network in natural language. Therefore, IBN needs to be capable, with minimum collected information from users’ requests, to generate possible service graphs.

[0040] The problem of service graphs generation is solved in three steps: (i) intent translation, (ii) service selection, and (iii) chain generation. The intent translation process requires semantic analysis to correctly understand the user's request and to extract FRs and NFRs. After intent translation, the next step is to select the services, which satisfy the user’s requirements based on the FRs and NFRs extracted from the intent. Finally, the selected services need to be composed together to generate the service graphs such that the resultant service graphs are compatible with the given user intent. Herein, a solution to solve the service graphs generation problem in IBN is proposed. The solution addresses the service selection and chain generation challenges mentioned previously. It is assumed that the intent translation step is done using existing tools/techniques.

[0041] The solution proposed herein has several advantages. It allows to generate service graphs with minimum information. More specifically, users do not need to provide information about required VNFs, or technical network information (e.g., bandwidth, latency) in their intent. The service catalog in the solution is dynamic, i.e., the services and their information change over time, based on daily, weekly, monthly, or periods, for example. In a dynamic service catalog, services can be added and deleted, and their information can be updated. The solution can identify all possible service graphs that are capable of fulfilling the functional requirement of the intent. This allows a service graph selection method to be able to select the optimal service graph that also fulfils the non-functional requirements. The output of the system contains both network-related and non-network-r elated services. The reason why those are considered separately is that having both network-related and non-network- related services in the service graph makes it hard to understand because between every two non-network-r elated services there are network-related services to make the connection. The separation allows to study each part in detail. Non-network-related services are the main services needed for implementing user’s request. Services that are needed for connection between each main service are network-related services. For example, services can communicate with each other through mobile, Ethernet, or WIFI networks.

[0042] Figure 1 depicts the general overview of an intelligent cloud resource management framework 100. The intent translation module 105 takes as input a high- level intent 102 (which is the user request in natural language) and tries to translate it to low-level intent (in RDF format) using a domain ontology. After receiving the low- level intent, the service graphs generation module 110 generates the service graphs with the help of the service catalog, which contains information about services and their relations. Service graphs generation 110 outputs possible service graphs that connect the source to the destination. The service configuration module 115 is responsible for finding the performance key performance indicators (KPIs) for each service in order to fulfil the NFRs (e.g., quality of experience). The resource configuration module 120 determines the required resources to the services in order to achieve the performance KPIs. The main focus herein is on the service graph generation 110 and related step.

[0043] To help better understand the proposed solution, each step of the method will be explained in relation with an example application: live holographic streaming, which is an example of holographic communications. However, the solution is in no way restricted to this specific application.

[0044] Consider that a user, who has no technical knowledge about the network, but knows how to explain her request, sends a high-level intent 102 in natural language to the system 100. The request contains the desired application (i.e., live holographic streaming), source and destination, and may also contain information about the required quality level or security features, among others. A typical example of a request can be as follows: “I would like to have a holographic streaming between Concordia University and Ericsson and also would like to store it”. First, the intent needs to be translated to a low-level intent and the important features of the user request need to be extract. It is assumed that the user request has already been translated into the RDF format.

[0045] Figure 2 illustrates an example RDF graph 200 of the translation of the user intent and of the features that are extracted from it. The first feature, which is the root of the RDF graph, is the requested use-case, which may have some requirements. Based on the intent, it can be determined that the user not only wants to have a holographic streaming between the source (i.e., Concordia University) and the destination (i.e., Ericsson), but she also wants to store it, which is translated into a second destination (i.e., storage). At this point, the high-level intent is translated, but there is also a need to have information about the initial services to be used to generate the service graphs. This information can be obtained from the domain ontology, illustrated in figure 3.

[0046] For each use-case, the domain ontology contains information about the source (i.e., first) and destination (i.e., last) services in service graphs. For example, as shown in Fig. 3, the holographic streaming use-case is associated with a domain ontology which requires Holographic Generator and Holographic Display to generate and display the holographic content. In the example, the Holographic Generator and the Holographic Display represent the source and destination services of the holographic streaming, respectively. Further, given that the user has requested to store the holographic content, the Storage serves as another destination. Once the information about the source and destination services for the holographic streaming is acquired, service graphs generation can begin.

[0047] The aim of the service graphs generation step is to generate service graphs based on the information gathered in the intent translation step described above and based on a given service catalog. The architecture of the service graph generation 110 is depicted in Fig. 4. The translated intent is the input to compatible graph generation (CGG) 405. The compatible graph (CG) is generated by finding compatible services in the service catalog 420. The compatible graph is used for generating service graphs. Service graph generation (SGG) 410 finds all possible service graphs (SGs) that can meet the intent's requirement and output them as candidate service graphs. Moreover, there is an optional step 415 that gets the SGs and generates the network-related service graph (NRSG) for connection between services. Each step will be explained in detail in the following.

[0048] The service catalog 420 contains information about VNFs and services (e.g., name, service version, CPU usage, etc.). This information is not helpful in the process of generating service graphs based on the FRs of the user’s request because it does not contain compatibility between services, which is necessary for the service graph generation. Therefore, as a solution, new elements are added, which make connections between VNFs and services based on their input and output content. The service catalog is modified, and new elements are added to it. These new elements are “provided service”, “pre-services interface”, “post-services interface”, and “interface type”. Each VNF in the service catalog has these new elements:

“provided service” indicates what service this VNF provides;

“pre-services interface” are types of content that this service accepts as input; “post-services interface” are types of content that this service exports as output; and

“interface type” indicates the type of network the VNF implements on, such as mobile, Ethernet, and WiFi.

[0049] The “interface type” is used in the network-specific version of the solution. The content of an example service catalog is shown in Table 1. The new elements of service catalog are columns of this table. This table contains different services, some of which are useful for the holographic streaming use-case. Some of these services are used in the service graphs generation process of the above-mentioned example.

Table 1 : Service catalog

[0050] The solution proposed herein contains two parts: compatible graph generation

405 and service graphs generation 410. The flowchart illustrating the steps executed in the CGG part is depicted in Fig. 5.

[0051] In the CGG process 500, the source services (from domain ontology) are used as the initial services in the solution, step 505. Then, these initial services are added to a queue Q, step 510, which includes unvisited services. At each step of the CGG process, a service from the top of the Q is selected, step 525. To perform the search, step 530, the dictionary (key-value) search algorithm can be used. After finding this service in the service catalog, all the services whose pre-service interface is compatible with the post-service interface of this service are added to the Q, step 535. In addition, a graph G is generated, where services are nodes and relationships between services are links of the graph. A service selected from the top of the Q is then added to the G with its compatible services from the service catalog. The process of selecting a service from the top of the Q, searching for its compatible services in the service catalog, adding new services to the Q, and updating graph G are repeated until the Q becomes empty, step 515. When the Q becomes empty, the links are followed from the source services in G toward the destination services (from domain ontology) and backward links are removed to prevent having a cycle in the graph, step 520. This graph is called a compatible graph (CG).

[0052] The second part of the solution uses the CG to generate service graphs (SGs). The flowchart illustrating the steps executed in the SGG part is depicted in Fig. 6. [0053] In the SGG process 600, the first step is to read the compatible graph, step 605. Then, all the paths from source to destination services are found in the CG, step 610. Then, all combinations of these paths which contain source and destination services are discovered, step 615. Since each SG presents one of the ways to connect the source to destination services, combinations are selected such that there is only one path from each source to each destination, step 620. Finally, these selected combinations are the ultimate SGs.

[0054] Compatible graph generation is now discussed while considering the above- mentioned example.

[0055] Referring to figure 3, according to the domain ontology, there is one source service (i.e., holo-generator) and two destination services (i.e., holo-display and storage). The “Holographic Generator” is thus added to the Q and G. The status of the Q then becomes Q=[“holo-generator”]. One service is selected from the top of the Q, which is the “holo-generator”. By exploring row 1 of Table 1 for “holo-generator”, it can be noticed that “holo-generator” has no pre-service interface (column 4), while “raw-holo-content” is its post-service interface (column 5). Thus, a search is made for services, in the service catalog, that are compatible and that have “raw-holo-content” as a pre-service interface. These compatible services are “holo-display” (row 2), “holo-encoder” (row 3), and “raw-holo-write” (row 10). These services (“holodisplay”, “holo-encoder” and “raw-holo-write”) are added to the Q, and the G is updated. Newly added nodes and links to G in each step will be shown in bold solid lines in the figures 7-9. The updated Q and G at this point are shown in Fig. 7.

[0056] Then, the next service from the top of the Q (“holo-display”) is select. In Table 1, the pre-service interface for “holo-display” (row 2) is “raw-holo-content”, and its post-service interface is "none". A search is made for the services, in the service catalog (Table 1), whose post-service interface is “raw-holo-content”. These services are “holo-generator” (row 1), “holo-decoder” (row 4), “game-engine” (row 7), and “raw-holo-read” (row 11). Among these services, the “holo-generator” was previously checked, thus only the other services are added to the Q and the graph G is updated. This is illustrated in Fig. 8.

[0057] The “holo-encoder” (corresponding to row 3 of Table 1) is the next service in the Q. In Table 1, for “holo-encoder”, there is “raw-holo-content” as a pre-service interface and “encode-holo-contenf ’ as a post-service interface. A search is made in Table 1, the service catalog, for services whose pre-service interface is compatible with “encode-holo-contenf ’, and services that have “raw-holo-content” as the postservice interface. Thus, the “holo-generator” (row 1), “holo-decoder” (row 4), “gameengine” (row 7), and “raw-holo-read” (row 11) are compatible with the “holoencoder”. The Q and graph G are updated accordingly. As explained previously, adding the previously added services to the Q should be avoided. The updated graph G and the updated Q are shown in Fig. 9.

[0058] This process is repeated for all the services in the Q until the Q is empty. Figures 10a- 10c show the updated graph G and the Q status at each step of the solution.

[0059] After processing all services in the Q, which ends up being empty, a final graph G is obtained, which is depicted in Figure 10c (i). It has source and destination services from the domain ontology as input to the solution. To find the CG, the starting point is the source, “holo-generator”, and the links and nodes are followed to the destinations, i.e., “holo-display” and “storage”. The direction is from source to destination.

[0060] Any backward links that cause cycles in the graph are removed. This is achieved by performing topological ordering of the graph in 10c (i). For example, when starting from “holo-generator”, the next move can be “holo-encoder”, from “holo-encoder”, it is possible to go to “holo-decoder” and from “holo-decoder” it is possible to get back to “holo-encoder,” which is a backward link that causes a cycle in the graph. To avoid this, in the CG, only the “holo-encoder” to “holo-decoder” is considered, which is a forward move starting from “holo-generator”. After processing all nodes and links from the source to destination services, the output CG which is shown in Fig. 11 is obtained. The same can be achieved using other topological sorting algorithms, such as Kahn’s algorithm.

[0061] In the solution, a structure in SGs where the order of the services can be changed is also considered. This helps arrange the services inside this structure based on the requirement (e.g., bandwidth). In the service catalog, if there is a service that has the same pre-services and post-services interface, it can be a candidate for this structure. For this structure, other services that have the same pre-service and postservice interfaces are needed. Then, such services can be grouped together to form a clique in the SG. In an undirected graph, a clique is a subset of vertices such that every two vertices are connected. For example, in Table 1, there are Data Packet Inspection (row 13) and Intrusion Prevention System (row 14) services. As can be seen in table 1, DPI and IPS pre-service and post-service interfaces are the same. Thus, in the service graph, there can be two ways to arrange these services: DPI followed by IPS or vice versa. This is illustrated in Fig. 12.

[0062] Service graphs generation is now discussed while considering the above- mentioned example.

[0063] Service graphs are possible graphs extracted from the compatible graph that contain services that connect the sources to the destinations. In other words, these service graphs are possible ways that users’ intent can be realized. For finding all possible service graphs, all paths from each source to each destination first need to be found. Taking the example of Fig. 11, that means looking for all paths from “hologenerator” to “holo-display”, and all paths from “holo-generator” to “storage”.

[0064] All paths from “holo-generator” to “holo-display” are as follows:

1- holo-generator holo-display

2- holo-generator holo-encoder holo-decoder holo-display

3- holo-generator holo-encoder holo-compressor holo-decompressor holo-decoder holo-display

4- holo-generator raw-holo- write raw-holo-read holo-display

5- holo-generator holo-encoder holo-decoder raw-holo- write raw- holo-read holo-display 6- holo-generator holo-encoder holo-compressor holo-decompressor holo-decoder raw-holo- write raw-holo-read holo-display

[0065] All paths from “holo-generator” to “storage” are as follows:

1- holo-generator raw-holo- write storage

2- holo-generator holo-encoder holo-decoder raw-holo- write storage

3- holo-generator holo-encoder holo-compressor -> holo-decompressor holo-decoder raw-holo- write storage

[0066] After finding all the possible paths from each source to each destination, the combination of all paths is considered together. Continuing with the previous example, among the paths from “holo-generator” to “holo-display”, one path is selected and combined with each path from “holo-generator” to “storage”. This is repeated for all the paths in the “holo-generator” to “holo-display” paths. Some of these combinations are shown in Fig. 13.

[0067] When the process of finding all combinations is finished, there might be some combinations that have the same nodes and links, thus these combinations are duplicates and need to be removed. Each service graph shows one of the ways that the source can be connected to the destination, thus if in any combination there is more than one path from source to destination, these combinations are removed. For example, the combination of [holo-generator holo-encoder holo-decoder holo-display] and [holo-generator holo-encoder holo-compressor holodecompressor holo-decoder raw-holo-write storage] is shown in Fig. 14. As shown in Fig. 14, from “holo-generator” to “holo-display” there are two paths: [hologenerator holo-encoder holo-decoder holo-display] and [holo-generator holo-encoder holo-compressor holo-decompressor holo-decoder holodisplay], Also, for “holo-generator” to “storage”, there are two paths. As mentioned above, each service graph needs to show one of the ways that the user's intent can be realized, it is not acceptable to have two paths from source to destination in one service graph, and that should be removed from the final service graphs. The final service graphs for the example are shown in Figs. 15a and 15b.

[0068] The solution can also be used with a network-specific version of the services. This network-specific version is needed because each service in the service graph requires a connection for communication with its post-service. This connection can be Mobile, Ethernet, or WiFi. Thus, a network-specific version for the Network-Related Service Graph (NRSG) is presented. The structure of the network-related service catalog does not change; it contains the same elements as before. An example network-related service catalog is shown in table 2.

Table 2: An example of network-related service catalog

[0069] In this example, three network interfaces are considered: mobile, Ethernet, and

WiFi. Each service in the service graphs needs to use a network interface for communicating with its neighbor services. For example, in Fig. 15a (a), the “hologenerator” uses a mobile network interface (table 1, row 1, col 6), and the “holo- display” uses a WiFi network interface (table 1, row 2, col 6). The direction of the link between these two services is from “holo-generator” to “holo-display”. Thus, the “holo-generator” is the source, and the “holo-display” is the destination. Likewise, to make the connection between these two services, the source interface type is “mobile” (table 2, row 1), and the destination interface type is “wifi” (table 2, row 4). This determination is done for each link in service graphs. Note that there can be more than one interface type for services in the non-network-related service catalog.

[0070] The flowchart for the network-related service graph (NRSG) generation 1600 is shown in Fig. 16. First, the service graph is read, step 1605, then all the source and destination interface type pairs are found, step 1610, and these pairs are stored in list L. For each pair in L, the same algorithm that was used for generating SGG is used for generating NRSG, step 1625. Finally, the NRSG is outputted for each pair in list L, step 1630. The solution is divided into two parts since considering it as one part may cause the final service graphs to be complicated and hard to follow.

[0071] Figure 17a shows all relations between services in the network-related service catalog of Table 2, by starting from a “src-mobile”. The solution is applied on this example from “mobile” to “wifi”. The compatible graph generated for source "mobile" and destination "wifi" is shown in Fig. 17-b.

[0072] Then it is possible to find all the service graphs from “src-mobile” to “dst- wifi”. The result of the service graphs generation is depicted in Fig. 18.

[0073] Turning to figure 19, there is provided a computer implemented method 1900 for generating service graphs from high-level intents and for configuring a service and allocating resources according to a service graph selected among the generated service graphs. The method comprises translating, step 1905, the high-level intents into low- level intents using a domain ontology. The method comprises generating, step 1910, a compatible graph based on the low-level intents and based on a service catalog. The method comprises generating, step 1915, the service graphs based on the compatible graph. The method comprises configuring, step 1920, the service according to the service graph selected among the generated service graphs. The method comprises allocating, step 1925, computing resources for executing the configured service.

[0074] The high-level intents may be intents formulated in natural language by a user. The low-level intents may be provided in a Resource Description Framework (RDF) format.

[0075] The domain ontology may correspond to the high-level intent and may contain information about at least one source service and at least one destination service in the service graphs.

[0076] Translating may comprise extracting functional requirements (FRs) and nonfunctional requirements (NFRs) from the high-level intents. [0077] Generating the compatible graph may comprise selecting services satisfying the FRs and NFRs extracted from the high-level intents.

[0078] Generating the compatible graph may further comprise using the at least one source service from the domain ontology as the initial at least one source service in the solution. Generating the compatible graph may further comprise adding the initial at least one source service to a queue Q, which includes unvisited services. Generating the compatible graph may further comprise generating a graph G, comprising the initial at least one source service, wherein, in the graph G, services are nodes and relationships between services are links. Generating the compatible graph may further comprise iteratively selecting a service from the top of the queue Q and performing a search for the selected service in the service catalog, adding all compatible services which have a pre-service interface compatible with a post-service interface of the selected service to the queue Q, adding the selected service and all the compatible services to the graph G, until the queue Q becomes empty. Generating the compatible graph may further comprise following the links from the at least one source service in the graph G toward the at least one destination service and removing backward links to prevent having a cycle in the graph.

[0079] Generating the service graphs may further comprise reading the compatible graph, finding all paths from each of the at least one source service to each of the at least one destination service in the compatible graph, if there is more than one source service or more than one destination service, finding all combinations of paths from source service to destination service and removing duplicate paths, thereby obtaining the service graphs.

[0080] The service catalog may comprise information about the services and about interfaces the services expose and consume.

[0081] The service graph may be selected by, for each service graph, given resource requirements of the service, determining a placement of the service in a distributed cloud environment, estimating a cost of deploying the service graph for the placement and selecting the service graph with a minimal cost.

[0082] Configuring the services according to the service graph selected may further comprise determining key performance indicators (KPIs) for each service in the service graph to fulfil the NFRs. Allocating computing resources for executing the configured services may further comprise determining resources required by the services to achieve the KPIs. [0083] It should be noted that methods and steps described herein are, generally, computer implemented methods and steps. The term computer may be interpreted as having different meanings, such as explained next, for example.

[0084] Referring to figure 20, there is provided an apparatus (HW) 2001, in which functions and steps described herein can be implemented.

[0085] The apparatus 2001 may be a server, network node, radio base station, or other computing device which may be part of a cloud computing system, edge computing system, or which may be a standalone device.

[0086] The apparatus 2001 is configured and used to generate service graphs from high-level intents entered by a user through e.g., a keyboard of a microphone, and to automatically configure services and allocate resources, such as computing resources, for executing the user intent, according to a service graph selected among the generated service graphs. The apparatus is configured to execute any of the steps according to the teachings provided herein.

[0087] The apparatus 2001 comprises processing circuitry 2003 and memory 2005. The memory 2005 can contain instructions executable by the processing circuitry 2003 whereby functions and steps described herein may be executed to provide any of the relevant features and benefits disclosed herein.

[0088] The apparatus 2001 may also include non-transitory, persistent, machine- readable storage media 2007 having stored therein software and/or instruction 2009 executable by the processing circuitry 2003 to execute functions and steps described herein. The apparatus may also include network interface(s) and a power source. [0089] The instructions 2009 may include a computer program for configuring the processing circuitry 2003. The computer program may be stored in a physical memory local to the device, which can be removable, or it could alternatively, or in part, be stored in the cloud. The computer program may also be embodied in a carrier such as an electronic signal, optical signal, radio signal, or computer readable storage medium.

[0090] Referring to figure 21, there is provided a virtualization environment 2100 in which functions and steps described herein can be implemented.

[0091] The virtualization environment 2100 (which may go beyond what is illustrated in figure 21), may comprise systems, networks, servers, nodes, devices, etc., that are in communication with each other either through wire or wirelessly, e.g., through a network interface component (NIC) comprising physical network interface(s). Some or all of the functions and steps described herein may be implemented as one or more virtual components (e.g., via one or more applications, components, functions, virtual machines, containers, etc.) executing on one or more physical apparatus in one or more networks, systems, environment, etc.

[0092] A virtualization environment provides hardware 2101 comprising processing circuitry 2103 and memory 2105. The memory 2105 can contain instructions executable by the processing circuitry 2103 whereby functions and steps described herein may be executed to provide any of the relevant features and benefits disclosed herein.

[0093] The hardware 2101 may also include non-transitory, persistent, machine- readable storage media 2107 having stored therein software and/or instruction 2109 executable by the processing circuitry 2103 to execute functions and steps described herein.

[0094] The instructions 2109 may include a computer program for configuring the processing circuitry 2103. The computer program may be stored in a removable memory, such as a portable compact disc, portable digital video disc, or other removable media. The computer program may be stored in a physical memory local to the hardware 2101, which can be removable, or it could alternatively, or in part, be stored in the cloud. The computer program may also be embodied in a carrier such as an electronic signal, optical signal, radio signal, or computer readable storage medium.

[0095] Referring again to figures 20 and 21, there is provided a system 2001, 2100 for generating service graphs from high-level intents and for configuring a service and allocating resources according to a service graph selected among the generated service graphs. The system comprises processing circuitry 2003, 2103 and a memory 2005, 2105, the memory containing instructions executable by the processing circuitry whereby the system is operative to translate the high-level intents into low-level intents using a domain ontology. The system is operative to generate a compatible graph based on the low-level intents and based on a service catalog. The system is operative to generate the service graphs based on the compatible graph. The system is operative to configure the service according to the service graph selected among the generated service graphs. The system is operative to allocate computing resources for executing the configured service. [0096] The high-level intents may be intents formulated in natural language by a user. The low-level intents may be provided in a Resource Description Framework (RDF) format.

[0097] The domain ontology may correspond to the high-level intent and may contain information about at least one source service and at least one destination service in the service graphs.

[0098] The system is further operative to extract functional requirements (FRs) and non-functional requirements (NFRs) from the high-level intents.

[0099] The system is further operative to select services satisfying the FRs and NFRs extracted from the high-level intents.

[00100] The system is further operative to use the at least one source service from the domain ontology as the initial at least one source service in the solution. The system is further operative to add the initial at least one source service to a queue Q, which includes unvisited services. The system is further operative to generate a graph G, comprising the initial at least one source service, wherein, in the graph G, services are nodes and relationships between services are links. The system is further operative to, iteratively, select a service from the top of the queue Q and perform a search for the selected service in the service catalog, add all compatible services which have a pre-service interface compatible with a post-service interface of the selected service to the queue Q, add the selected service and all the compatible services to the graph G, until the queue Q becomes empty. The system is further operative to follow the links from the at least one source service in the graph G toward the at least one destination service and remove backward links to prevent having a cycle in the graph.

[00101] The system is further operative to read the compatible graph. The system is further operative to find all paths from each of the at least one source service to each of the at least one destination service in the compatible graph. The system is further operative to, if there is more than one source service or more than one destination service, find all combinations of paths from source service to destination service. The system is further operative to remove duplicate paths, to thereby obtain the service graphs.

[00102] The service catalog may comprise information about the services and about interfaces the services expose and consume.

[00103] The system is further operative to, for each service graph, given resource requirements of the service, determine a placement of the service in a distributed cloud environment, estimate a cost of deploying the service graph for the placement and select the service graph with a minimal cost.

[00104] The system is further operative to determine key performance indicators (KPIs) for each service in the service graph to fulfil the NFRs. The system is further operative to determine resources required by the services to achieve the KPIs.

[00105] Referring again to figures 20 and 21, there is provided a non-transitory computer readable media 2007, 2107 having stored thereon instructions 2009, 2109 for generating service graphs from high-level intents and for configuring a service and allocating resources according to a service graph selected among the generated service graphs. The instructions 2009, 2109 comprise translating the high-level intents into low-level intents using a domain ontology. The instructions 2009, 2109 comprise generating a compatible graph based on the low-level intents and based on a service catalog. The instructions 2009, 2109 comprise generating the service graphs based on the compatible graph. The instructions 2009, 2109 comprise configuring the service according to the service graph selected among the generated service graphs. The instructions 2009, 2109 comprise allocating computing resources for executing the configured service.

[00106] Modifications will come to mind to one skilled in the art having the benefit of the teachings presented in the foregoing description and the associated drawings. Therefore, it is to be understood that modifications, such as specific forms other than those described above, are intended to be included within the scope of this disclosure. The previous description is merely illustrative and should not be considered restrictive in any way. The scope sought is given by the appended claims, rather than the preceding description, and all variations and equivalents that fall within the range of the claims are intended to be embraced therein. Although specific terms may be employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

1. A computer implemented method for generating service graphs from high-level intents and for configuring a service and allocating resources according to a service graph selected among the generated service graphs, comprising:

- translating the high-level intents into low-level intents using a domain ontology; generating a compatible graph based on the low-level intents and based on a service catalog; generating the service graphs based on the compatible graph; configuring the service according to the service graph selected among the generated service graphs; and allocating computing resources for executing the configured service.

2. The method of claim 1, wherein the high-level intents are intents formulated in natural language by a user.

3. The method of claim 1 or 2, wherein the low-level intents are provided in a Resource Description Framework (RDF) format.

4. The method of any one of claims 1 to 3, wherein the domain ontology corresponds to the high-level intent and contains information about at least one source service and at least one destination service in the service graphs.

5. The method of any one of claims 1 to 4, wherein translating comprises extracting functional requirements (FRs) and non-functional requirements (NFRs) from the high-level intents.

6. The method of claim 5, wherein generating the compatible graph comprises selecting services satisfying the FRs and NFRs extracted from the high-level intents.

7. The method of claim 4, wherein generating the compatible graph further comprises: - using the at least one source service from the domain ontology as the initial at least one source service in the solution; adding the initial at least one source service to a queue Q, which includes unvisited services; generating a graph G, comprising the initial at least one source service, wherein, in the graph G, services are nodes and relationships between services are links; iteratively: o selecting a service from the top of the queue Q and performing a search for the selected service in the service catalog; o adding all compatible services which have a pre-service interface compatible with a post-service interface of the selected service to the queue Q; o adding the selected service and all the compatible services to the graph G; until the queue Q becomes empty; and following the links from the at least one source service in the graph G toward the at least one destination service and removing backward links to prevent having a cycle in the graph.

8. The method of claim 4 or 7, wherein generating the service graphs further comprises: reading the compatible graph; finding all paths from each of the at least one source service to each of the at least one destination service in the compatible graph; if there is more than one source service or more than one destination service, finding all combinations of paths from source service to destination service; and removing duplicate paths, thereby obtaining the service graphs.

9. The method of any one of claims 1 to 8, wherein the service catalog comprises information about the services and about interfaces the services expose and consume.

10. The method according to any one of claims 1 to 9, wherein the service graph is selected by:

- for each service graph, given resource requirements of the service, determining a placement of the service in a distributed cloud environment; estimating a cost of deploying the service graph for the placement; and selecting the service graph with a minimal cost.

11. The method of claim 5 or 6, wherein configuring the services according to the service graph selected further comprises determining key performance indicators (KPIs) for each service in the service graph to fulfil the NFRs.

12. The method of claim 10, wherein allocating computing resources for executing the configured services further comprises determining resources required by the services to achieve the KPIs.

13. A system for generating service graphs from high-level intents and for configuring a service and allocating resources according to a service graph selected among the generated service graphs, comprising processing circuitry and a memory, the memory containing instructions executable by the processing circuitry whereby the system is operative to:

- translate the high-level intents into low-level intents using a domain ontology; generate a compatible graph based on the low-level intents and based on a service catalog; generate the service graphs based on the compatible graph; configure the service according to the service graph selected among the generated service graphs; and allocate computing resources for executing the configured service.

14. The system of claim 13, wherein the high-level intents are intents formulated in natural language by a user.

15. The system of claim 13 or 14, wherein the low-level intents are provided in a Resource Description Framework (RDF) format.

16. The system of any one of claims 13 to 15, wherein the domain ontology corresponds to the high-level intent and contains information about at least one source service and at least one destination service in the service graphs.

17. The system of any one of claims 13 to 16, further operative to extract functional requirements (FRs) and non-functional requirements (NFRs) from the high-level intents.

18. The system of claim 17, further operative to select services satisfying the FRs and NFRs extracted from the high-level intents.

19. The system of claim 16, further operative to:

- use the at least one source service from the domain ontology as the initial at least one source service in the solution; add the initial at least one source service to a queue Q, which includes unvisited services; generate a graph G, comprising the initial at least one source service, wherein, in the graph G, services are nodes and relationships between services are links; and further operative to, iteratively: o select a service from the top of the queue Q and perform a search for the selected service in the service catalog; o add all compatible services which have a pre-service interface compatible with a post-service interface of the selected service to the queue Q; o add the selected service and all the compatible services to the graph G; until the queue Q becomes empty; and follow the links from the at least one source service in the graph G toward the at least one destination service and remove backward links to prevent having a cycle in the graph.

20. The system of claim 16 or 19, further operative to: read the compatible graph; find all paths from each of the at least one source service to each of the at least one destination service in the compatible graph; if there is more than one source service or more than one destination service, find all combinations of paths from source service to destination service; and remove duplicate paths, to thereby obtain the service graphs.

21. The system of any one of claims 13 to 20, wherein the service catalog comprises information about the services and about interfaces the services expose and consume.

22. The system according to any one of claims 13 to 21, further operative to:

- for each service graph, given resource requirements of the service, determine a placement of the service in a distributed cloud environment; estimate a cost of deploying the service graph for the placement; and select the service graph with a minimal cost.

23. The system of claim 17 or 18, further operative to determine key performance indicators (KPIs) for each service in the service graph to fulfil the NFRs.

24. The system of claim 22, further operative to determine resources required by the services to achieve the KPIs.

25. A non-transitory computer readable media having stored thereon instructions for generating service graphs from high-level intents and for configuring a service and allocating resources according to a service graph selected among the generated service graphs, the instructions comprising:

- translating the high-level intents into low-level intents using a domain ontology;

- generating a compatible graph based on the low-level intents and based on a service catalog;

- generating the service graphs based on the compatible graph; configuring the service according to the service graph selected among the generated service graphs; and allocating computing resources for executing the configured service.