WO2023115522A1

WO2023115522A1 - Systems and methods for enabling network-based reusable computing

Info

Publication number: WO2023115522A1
Application number: PCT/CN2021/141125
Authority: WO
Inventors: Xu Li; Hang Zhang
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2021-12-24
Filing date: 2021-12-24
Publication date: 2023-06-29

Abstract

A method and system for a second computing service to reuse a first service function of a first computing service, the first service function being part a first task, the first task being part of a first work, the work being part of the first computing service being managed by a first service manager. By mapping information identifying a work of the second computing service authorized for reuse, to a combination of information identifying the first computing service, and information identifying the reuse, and storing the mapped information in a service profile of the second computing service in, a service data repository, the work of the second computing service can be reused in accordance with sequences provided herein.

Description

SYSTEMS AND METHODS FOR ENABLING NETWORK-BASED REUSABLE COMPUTING

CROSS-REFERENCE TO RELATED APPLICATIONS

This is the first application filed for the present invention.

TECHNICAL FIELD

This invention pertains generally to the field of network-based computing services and in particular, to methods of using a first interconnected computer service, within a second interconnected computer service.

BACKGROUND

Edge computing (EC) is a way of computing that reduces transmission delay and bandwidth consumption by moving computation and storage close to the network edge, and therefore closer to the end user. Typical EC applications include applications that have large bandwidth and/or stringent delay requirements, such as artificial intelligence (AI) applications, augmented reality (AR) and virtual reality (VR) games, machinery, etc. As EC techniques are developing into maturity, it is anticipated that EC capabilities and platforms (e.g. edge clouds) will be deeply deployed in the network, e.g. on radio node, and pervasively be available for use.

In the following, “network-based computing service” , “computing service” , “intelligence service” , “service” , “application” and “intelligence” are equivalent and used inter-changeably, unless clarified otherwise, and in a network, a computing service can be provided by one or more service functions. In some embodiments, when a computing service is related to artificial intelligence (AI) , it is referred to as AI service or AI application.

An authorized service provider can request to deploy its computing service in a network. The deployment of service function (s) can be subject to service function chaining (SFC) requirements and resource requirements, as specified by the service provider. SFC reflects a computing service’s networking logic. According to the request, the network deploys (instantiates) the service function (s) in edge clouds, taking into account resource availability and network conditions. This fusion of networking and computing is envisioned to be a typical scenario of next generation wireless system (6G) .

With a 6G network, not only can a user connect to an application, but an application can include many modules, interconnected via the network. Such an interconnected application can be referred to as “connected intelligence” , which is essentially distributed computing, and is also referred to as network-based computing. Network-based computing involves at least two computing modules, each potentially being deployed at a different network location (e.g. an edge cloud) . The computing modules can each perform part of the computing and exchange their results to achieve a common goal. Central to distributed computing is the concept of coordination, which refers to coordinating the computing modules performing the computing process in order to achieve goals. Conventionally, coordination is performed at the application layer. The computing modules are interoperable as they are programmed to communicate (i.e. talk or interact) with each other using well-defined signals (i.e. a “language” ) at the right times, which can be upon certain events, or following some pre-defined procedure.

It is envisioned that reusability could be an important aspect of connected intelligence in 6G. When a service provider deploys a computing application on edge clouds of a network, the computing application’s availability can be published to other service providers, which can reuse them as computing modules for further services. By making services reusable as such, redundant development can be avoided and an eco-system can be centered on the network. However, when the computing modules of a service are developed by different providers, interoperability between them can become an issue.

Therefore, there is a need for methods and/or systems that can obviate or mitigate the limitations of interoperability between modules from distributed computing services, when computing modules (or simply modules) of the computing service are provided by different service providers on a same network, and the modules are potentially located at different locations of the network, i.e. there is a need to allow modules from a first interconnected computer service to be reusable within a second interconnected computer service.

This background information is provided to reveal information believed by the applicant to be of possible relevance to the present invention. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art against the present invention.

SUMMARY

Embodiments of this disclosure address the interoperability issue in a network setting, where composite computing modules of an intelligence service are potentially located at different network locations.

Interoperability issues are addressed with systems and methods for deploying a first computing service in a network setting, and for devices to access the first computing service. Embodiments also include systems and methods of reusing a second computing service, in the first computing service.

One problem that is addressed and/or solved is that of service orchestration. Embodiments allow determining deployment locations of service functions of a first computing service, and selecting a computing plane to support that computing service.

Another problem addressed and/or solved is that of service publicity. Embodiments allow providing availability information of a first computing service to devices and to other service providers.

Another problem addressed and/or solved is that of service access, with methods allowing a device to access a first computing service.

Another problem addressed and/or solved is that of context syncronization. This involves sychronizing the execution of a first task within a first computing service, to a computing context. The execution of the first task can share the computing context with the execution of a second task in the first computing service, and with a second computing service reused by the first computing service. As such, the context sychronizaiton can be performed across tasks and across services.

Technical effect of embodiments include the ability of a first computing service implemented with routines between service functions, to reuses parts of a second computing service, also implemented on a network with routines between service functions, the two computing services being located on a network.

Embodiments include a method of implementing a computing service comprising: receiving a service registration request, by a first service manager, from an application controller for a first computing service; requesting authorization, by the first service manager, for a second computing service from a second service manager creating a service profile of the first computing service, by the first service manager, using at least part of the second service for instantiating the first computer service. A non-limiting example of the technical benefit allows for specific a reuse during service registration, and trigger authorization of the reuse.

In embodiments, creating a service profile of the first computing service using at least part of the second service for instantiating the first computer service can comprise: receiving, by the first service manager, authorization to reuse a work of a second computing service, from the second service manager. A non-limiting example of the technical benefit allows the first service manager to receive authorization result so that it can proceed to the next step.

In embodiments, a method by the second service manager can comprise: authorizing reuse of a work of a second computing service, updating a service profile of the second computing service, and responding to the first computing service. A non-limiting example of the technical benefit allows for the reuse to be recorded and then recognized and supported later

In embodiments, a first service and a second service can be the same service, and a service registration request can be a service registration request to add a new work into the service based on existing works in the service. A non-limiting example of the technical benefit allows for dynamically adding a new work into a computing service based on existing works in the computing service

In embodiments, a method can further comprise a second service manager mapping the information identifying a work of the second computing service that is authorized to be reused, to a combination of information identifying the first computing service, and information identifying the reuse of the work of the second computing service.

In embodiments, a method can further comprise a second service manager storing the mapped information in a service profile of the second computing service in a service data repository.

In embodiments, creating a service profile of the first computing service, by the first service manager, using at least part of the second service for instantiating the first computer service can comprise reusing the work of the second computing service.

In embodiments, a request can be a request for a new deployment and reusing the work of the second computing service can comprise the second service manager authorizing the reuse of the work.

In embodiments, a request can be a request for a remote connection and reusing the work of the second computing service can comprise a second service manager creating a replica of a work for use by a first service.

In embodiments, a method can comprise mapping, by the first service manager, the reuse of the work of the second computing service to the reuse of the replica of the work of the second computing service, updating, by the first service manager, a service description information (SDI) of the first computing service, by replacing information identifying the work of the second computing service with information identifying the replica of the work of the second computing service.

In embodiments, a method can further comprise an orchestrator making one or more incremental deployment decision for a second computing service.

In embodiments, a method can further comprise an orchestrator further making one or more dynamic deployment decisions for a work of a second computing service.

In embodiments, one or more dynamic deployment decisions can comprise a first dynamic deployment decision determining additional deployment locations and corresponding computing and network resource requirements of each internal function of a work Y; and a second dynamic deployment decision is determining inter-function connections and inter-function connections based on the additional deployment locations.

Embodiments include a method for a device to request a computing service comprising: a network entity receiving from a device, a request for a computing service; sending to a work manager a notice to execute a work using information of the device; receiving from the work manager an acknowledgment of work execution with device; sending a response to the device.

In embodiments, a method can further comprise the work manager executing the work according to the information of the device, wherein executing the work comprises identifying a routine associated with a service function representing the device, identifying for each routine, a task of the work to which the routine belongs; wherein the work manager can send a task request to a task manager, including information identifying the device, when triggering the task manager to execute the task.

In embodiments, a method can further comprise a work manager executing a work according to information identifying the device, wherein executing the work comprises identifying routines associated with a service function representing the device, identifying for each routine, a task of the work to which the routine belongs; wherein the work manager sends a task update request to a task manager, including information identifying the device, while the task manager is executing the task.

In embodiments, a method can further comprise a network entity notifying an application controller about the work execution.

In embodiments, a method can further comprise a network entity being a service manager.

In embodiments, a method can further comprise a work manager receiving from a task manager a request to perform context synchronization between a first task and a second task, originating from a routine manager of the first task; identifying a second task with which context synchronization is needed; requesting deactivation of first task execution; requesting deactivation of second task execution; requesting activation of the first task execution; and requesting activation of the second task execution; wherein the request to perform context synchronization includes information identifying the routine execution.

In embodiments, a method can further comprise a work manager generating information identifying the context to which the task executions should be synchronized.

In embodiments, a request to perform context synchronization can further include information identifying the context to which task executions should be synchronized.

In embodiments, deactivation can comprise the work manager: sending to the task manager a request to deactivate a task, the task manager operative to send a request to the routine manager to deactivate a native routine execution, and to deactivate a foreign routine execution; and receiving from the task manager a response regarding task deactivation, after the task manager receives a response regarding routine deactivation.

In embodiments a request to the routine manager can include information identifying a context to which the task executions are synchronized.

In embodiments, a method can further comprise a routine manager deactivating a native routine execution identified in a request to the routine manager by sending to a service function instance associated to the routine manager, a communication deactivation request to suspend data communications associated with the native routine execution; wherein the communication deactivation request is sent via a privacy router associated with the service function instance.

In embodiments, a communication deactivation request can further include information identifying the native routine execution, information identifying the native routine, information identifying the computing service, and information identifying a context in which the native routine execution is synchronized.

In embodiments, an activation can comprise a work manager sending to the task manager a request to activate a task, the task manager operative to send a request to the routine manager to activate a native routine, and to activate a foreign routine execution; and receiving from the task manager a response regarding task activation, after the task manager receives a response regarding routine activation.

In embodiments, a request to the routine manager can include information identifying the context to which the task executions should be synchronized.

In embodiments, a method can further comprise a routine manage activating a native routine execution identified in the request to the routine manager by sending to a service function instance associated to the routine manager, a communication activation request to activate data communications associated with the native routine execution; wherein the communication activation request is sent via a privacy router associated with the service function instance.

In embodiments a communication activation request can further include information identifying the native routine execution, information identifying the native routine, information identifying the computing service, and information identifying the context to which the native routine execution is synchronized.

In embodiments, deactivating a foreign function can comprise a task manager identifying a foreign function associated with the foreign routine; sending to a service manager a request to deactivate a corresponding foreign work, and initiating a work deactivation procedure; wherein the request to deactivate includes information identifying the foreign computing service to which the foreign work belongs; and information identifying the context to which the foreign work are synchronized.

In embodiments, activating a foreign function can comprise a task manager identifying a foreign function associated with the foreign routine; sending to a service manager a request to activate a corresponding foreign work; and initiating a work activation procedure; wherein the request to activate includes information identifying the foreign computing service to which the foreign work belongs; and information identifying the context to which the foreign work should be synchronized.

Other embodiments provide an apparatus for implementing a computing service including a processor and at least one non-transitory machine readable medium storing machine readable instructions which when executed by the processor, configures the apparatus for: receiving a service registration request, by a first service manager, from an application controller for a first computing service; requesting authorization, by the first service manager, for a second computing service from a second service manager; creating a service profile of the first computing service, by the first service manager, using at least part of the second service for instantiating the first computer service.

Other embodiments provide apparatus for implementing a computing service including : a processor; and at least one non-transitory machine readable medium storing machine readable instructions which when executed by the processor, configures the apparatus for executing the methods described and claimed herein.

Other embodiments provide a system comprising a plurality of devices in communication with each other for executing the methods described and claimed herein.

The foregoing and other objects, features, aspects and advantages of the present invention will become more apparent from the following detailed description, taken in conjunction with the accompanying drawings which description is by way of example only.

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1a illustrates a work as it can be used within a first computing service, according to embodiments.

Fig. 1b illustrates a work of a first computing service, as it can be used within a second computing service, according to embodiments

Fig. 2 illustrates an application-driven reuse, according to an embodiment

Fig. 3 illustrates a network system with a control plane and a compute plane, according to embodiments.

Fig. 4 illustrates a procedure of service registration for a first computing service, initiated by an application controller (AC) , according to an embodiment.

Fig. 5 illustrates a service instantiation procedure, in accordance with embodiments.

Fig. 6 is a call flow diagram illustrating a configuration procedure for a service manager, according to an embodiment.

Fig. 7 illustrates a procedure for configuring a routine manager, according to an embodiment.

Fig. 8 illustrates a procedure for configuring a privacy router for a routine, in accordance with a service function instance, according to an embodiment.

Fig. 9 illustrates a procedure of service deregistration for a computing service (i.e. a first computing service) , initiated by an application controller, according to an embodiment.

Fig. 10 illustrates a service announcement procedure, according to an embodiment.

Fig. 11 illustrates a service discovery procedure, according to an embodiment.

Fig. 12 illustrates a registration or registration update procedure for a device connecting to a platform, according to an embodiment.

Fig. 13 illustrates a procedure of device de-registration, where a device disconnects from a platform, according to an embodiment.

Fig. 14 illustrates a service request procedure, according to embodiments.

Fig. 15 illustrates a context synchronizing procedure between the routine manger, the task manager and the work manager, according to embodiments

Fig. 16 illustrates a task activation or deactivation procedure, wherein the work manager requests to activate or deactivate a task execution, according to an embodiment

Fig. 17 illustrates a work activation or deactivation procedure, according to an embodiment.

Fig. 18 is a block diagram of an electronic device (ED) illustrated within a computing and communications environment that may be used for implementing the devices and methods disclosed herein.

It will be noted that throughout the appended drawings, like features are identified by like reference numerals.

DETAILED DESCRIPTION

Embodiments include systems and methods for deploying an interconnected computing service such as to be accessible by one or more devices. Embodiments also include systems and methods of reusing, within a first interconnected computing service, a second interconnected computing service. The reuse can be determined at the application layer. Problems addressed by embodiments include:

- service orchestration: determining deployment locations for service functions of the first computing service, and selecting a computing plane to support the first computing service;

- service publicity: providing information regarding availability of the first computing service, to devices and to other service providers;

- service access: allowing a device to access the first computing service.

- context syncronization: sychronizing the execution of a first task within the first computing service, to a computing context. The execution of the first task can share the computing context with the execution of a second task in the first computing service, and with a second computing service that is reused by the first computing service. As such, a context sychronizaiton can be performed across tasks and across services.

Embodiments are related to scenarios that can be divided in two categories: application-driven reuse and network-driven reuse.

An application-driven reuse is a reuse scenario, where the reuse is determined at the application layer. The network is informed of the reuse by the application layer and supports the reuse. An example is progressive learning, where an AI model in a first AI service is extended to solve a new problem for a second AI service. A provider of the second AI service obtains information about the AI model from the provider of the first AI service, e.g. by offline means, and develops the second AI service accordingly.

A network-based computing service is an application-layer service that can perform network-based computing. It can include one or more works, which can be considered to belong or to be associated to the service. The works can be exposed to service consumers (i.e. entities consuming or using the service) , and the service consumers can choose to participate in (i.e. join in, or contribute to) an execution of the work. An entity providing a computing service can be referred to as a service provider or an intelligence provider.

In a service, a work of the service can includes one or more tasks. The tasks can be considered to belong or to be associated to the service. There can be dependencies between the task (s) . When a first task depends on a second task, because for example, the first task requires a result of the second task as an input, the first task has to be executed after the second task has been executed. Such dependency can be indirect, in that the first task can depend on the second task, because the first task depends on the result of a third task, itself depending on the second task. When the first task does not depend on a second task, the first task can be executed before, or in parallel (temporally) to the second task. Dependency between tasks can be referred to as inter-task dependency or intra-work dependency.

In a service, a task of a service can include one or more routines, which can each correspond to a computing or a networking step of the task. A routine can be considered to belong or to be associated to the service. There can be dependency between routines. When a first routine depends on a second routine, because for example, the first routine requires a computing result of the second routine as input, the first routine should be executed after the second routine. Such dependency can be indirect, in that the first routine can depend on the second routine, via a result of a third routine that depends on the second routine. If the first routine does not depend on the second routine, the first routine can be executed before, or in parallel with the second routine (in time) . Dependency between routines can be referred to as inter-routine dependency or intra-task dependency.

In a service, a routine is associated with a first service function and a second service function. The first service function can be referred to as “routine server function” and it does not represent devices. The second service function can be referred to as a “routine client function” , and it can represent one or more devices, or none. The two service functions can be considered to belong to, or to be associated to, the service; and each of them can have one or multiple instances. An instance of a routine server function is referred to as a routine server, and an instance of a routine client function is referred to as a routine client. Table 1 summarizes this nomenclature.

Table 1: Nomenclature of routines

A routine can be associated with information indicating which one of the service functions associated with the routine is a routine server function. The routine can be further associated with information indicating which one of the service functions associated with the routine is a routine client function.

In some embodiments, for example, when a routine has multiple routine clients, the routine can be associated with synchronization requirements specifying whether each routine client (i.e. instance of a routine client function) should communicate with a routine server (i.e. instance of a routine server function) in parallel (i.e. at the same time when a different routine client is communicating with the routine server) , or in sequence (i.e. one after another such that no two routine clients communicate with the routine server at the same time) . In other words, a synchronization requirement can be for parallel communication or for sequential communication. During an execution of a routine, a routine server can be associated with one or more routine clients, which can communicate with the routine server according to the synchronization requirements associated with the routine.

In a service that includes computing modules, a service function can implement a computing module. A service function can be in the form of software, and it can be referred to as a virtual function. When a service function is a virtual function, it can be deployed (i.e. instantiated) at one or more network locations, referred to as deployment locations, some or all of which can be on edge clouds. After a service function is deployed at a network location, there is an instance of the service function at that network location, where an instance can be in the form of a copy of the software implementing the service function. A service function can represent one or more devices, implying that the computing module is being used by the devices or running on them. In such a case, the devices can be considered to be instances of the service function.

When needed (e.g. upon request or on certain events) , a work associated with a computing service can be executed. During a work execution, its tasks can be executed according to an inter-task dependency associated with the work. During a task execution, its routines can be executed according to an inter-routine dependency associated with the task. During execution of a routine, data communications can occur between a routine server and one or more routine clients associated to the routine server, according to a synchronization requirement associated with the routine.

In a service, a work can be reusable, such as by a new deployment, or a remote connection. A reusable work is typically associated with ingress functions providing inputs to the work, and egress functions holding outputs of the work. Ingress functions and egress functions are service functions. As such, a second computing service can use a reusable work, as a symbolic foreign service function (or simply foreign function) . Such second computing service can include at least one routine that is associated with the symbolic foreign function, as well as a native service function, which belongs to the second computing service and can act as an ingress function and/or an egress function to the reusable work.

Fig. 1a illustrates a work as it can be used within a first computing service, according to embodiments. The work 105 includes one or more internal functions 110, as well as at least one ingress function 115, and at least one egress function 120. The one or more internal functions 110 are service functions.

In an embodiment, a work of a first computing service can be reused as a function (i.e. foreign function) in a second computing service, for example between two native functions, in a sequence of native functions of the second computing service.

Fig. 1b illustrates a work of a first computing service, as it can be used as a function within a second computing service, according to embodiments. A second computing service includes a plurality of native functions, which are service functions belonging to the second computing service, including native function 1 (125) , native function 2 (130) and native function 3 (135) . A work 105 of a first computing service can be reused in the second computing service as a foreign function between two native functions of the second computing service. Each link between two functions can correspond to a routine. A routine between two native functions can be referred to as a native routine 140, and a routine between a native functions and a foreign function can be referred to as a foreign routine 145.

An AI application is an example of a computing service, wherein a work can, for example, be related to training an AI model, implemented as a service function, and the work can include the following tasks: a data collection and preparation task, a model training task, and a model validation task, wherein the model validation task depends on the model training task, that in turn depends on the data collection and preparation task. Another work of the AI application can be, for example, AI inference.

When a first computing service is in operation, a work X (more specifically, a task T within the work X) of the first computing service can reuse a work Y of a second computing service. In this case, the work X can be associated with a foreign function representing work Y of the second computer service. In some embodiments, the first and second computing services can be the same computing service. A reuse can be indicated by the service provider of the first computing service, such as within a service description information (SDI) , as described elsewhere in this invention disclosure. Hence, such scenario can be referred to as an application-driven reuse.

Fig. 2 illustrates an application-driven reuse, according to an embodiment. In a second computing service, a work Y 205 can be associated with one or more core functions (i.e. internal functions) , such as core function 1 (210) , core function 2 (215) , etc. The one or more core functions are service functions. The work Y 205 can also be associated with an ingress function 220 and an egress function 225, which are also service functions. The ingress function 220 can be associated with a routine A of work Y, and the egress function 225 can be associated with a routine B of work Y.

A core function can be native to and belong to the second computing service. In some embodiments, it is not a symbolic function, which would be a service function representing devices or a work. The one or more core functions can be associated with a routine in the work Y, which may include routine A, routine B, or other routines. In some embodiments, the ingress function 220 and the egress function 225 can be the same service function. In some embodiments, routine A and routine B can be the same routine.

In an embodiment represented by Fig. 2, a foreign function representing a work Y can be a symbolic function. A work X 230 can be associated with a routine C, the routine C being associated with a service function 1 (235) and a foreign function 240, as well as a routine D, the routine D being associated with a service function 2 (245) and the same foreign function 240. The service functions 1 and 2 are native to (i.e. belong to) the second computing service. Routine C corresponds to routine A, and routine D corresponds to routine B. This implies that routine C reuses work Y 205, and that service function 1 participates in routine A of work Y 205 as an ingress function. It also implies that routine D reuses work Y, and that service function 2 participates in routine B of work Y as an egress function. In some embodiments, service function 1 and service function 2 are the same service function. In some embodiments, routine C and routine D are the same routine. Routine C and routine D can collectively be referred to as a task T 250, a task that includes these two routines.

In embodiments, network-based computing can be supported by a network system (i.e. a platform) , designed according to the concepts of service, work, task, and routine as described herein. A platform can be operated by a third party, which in contrast to a service consumer and a service provider, can be referred to as platform operator.

Fig. 3 illustrates a network system with a control plane and a compute plane, according to embodiments. A control plane can include control plane entities, such as an access manager 305, a service manager 310, a work manager 315, a task manager 320, an orchestrator 325, a resource manager 330, and a service data repository 335. A compute plane can include compute plane entities, such as one or more routine managers 340, and one or more privacy routers 345. These control plane and compute plane entities are network entities. In some embodiments, a resource manager 330 is an external entity, in that it is not necessarily part of the network system. In some embodiments, the routine manager 340 is considered a control plane entity and belongs to the control plane.

In embodiments, some platform entities can be connected to other platform entities and the connection and information from one entity to another can be identified with alphanumeric characters T1, T2, T3, T4, T5a, T5b, T5c, T6a, T6b, T7a, T7b, T7c, T7d, T7e, T8, T9a, and T9b. The links between the entities indicate interfaces or connections used for interacting or communicating with each other. These can be labelled according to their role and include:

- a link T1 307 between the access manager 305 and a device 350,

- a link T2 352 between the privacy router 345 and a device 350,

- a link T3 317 between the service manager 310 and an application controller 365,

- a link T4 347 between the privacy router 345 and an application server 355 in an edge cloud 360,

- a link T5a 342 between the access manager 305 and the routine manager 340,

- a link T5b 312 between the task manager 320 and the routine manager 340,

- a link T5c 322 between the service manager 310 and the routine manager 340,

- a link T6a 332 between the resource manager 330 and the orchestrator 325,

- a link T6b 333 between the work manager 315 and the resource manager 330,

- a link T6c 334 between the resource manager 330 and the task manager 320,

- a link T7a 327 between the orchestrator 325 and the service manager 310,

- a link T7b 328 between access manager 305 and the service manager 310,

- a link T7c 313 between the service manager 310 and task manager 320,

- a link T7d 318 between the work manager 315 and the task manager 320,

- a link T7e 314 between the service manager 310 and the work manager 315,

- a link T8 348 between a privacy router 345 and another privacy router 345,

- a link T9a 344 between the privacy router 345 and the service manager 310,

- a link T9b 349 between the privacy router 345 the routine manager 340.

In a network system according to embodiments, network entities can be logical entities and any of the network entities can be combined into a same entity. In some embodiments, the control plane entities are integrated into, or implemented by, a same network entity, such as a platform controller or a system controller. A platform controller can implement or provide functionalities of the control plane. In some embodiments, some of the control plane entities can be integrated into, or implemented by, a same network entity. For example, an orchestrator can be merged into a service manager, or a service manager and a work manager can be combined to form a service-and-work manager, or a work manager and a task manager can be combined into a work-and-task manager, etc. In some embodiments, the compute plane entities, i.e. a routine manager and a privacy router, can be combined into a coordinator. In some embodiments, when a routine manager is a control plane entity, a work manager and a task manager and the routine manager can be combined into a work-and-task-and-routine manager, or a task manager and the routine manager can be combined into a task-and-routine manger. When two entities A and B (like any of control or compute plane entities mentioned above) are combined into a single entity C, an interface between the two entities A and B becomes internal or integral to the single entity C.

The functionalities for the entities in Fig. 3 can be as follows.

In embodiments, an orchestrator 325 can determine deployment locations of service functions for an application (or a computing service) , and it can select a compute plane for the application, including a logical topology of the compute plane. It can also determine the resources needed at the deployment locations and over the communication links in the logical topology; and it can interact with a resource manager (which can be in the infrastructure network) to provide computing and networking resources (i.e. radio resources, transport resources, etc. ) accordingly.

In embodiments, an access manager 305 can act as a control plane interface with a device; and perform mobility management for the device. It can also authenticate and/or authorize a device to connect to a platform (e.g. the platform or network system illustrated in Fig. 3) .

In embodiments, a service manager 310 can perform registrations, registration updates, and deregistrations for an application (or a computing service) . It can also authenticate and authorize a device to use an application (or a computing service) . It can also act as a control plane interface with external entities, such as application controllers. It can also select a work manager to handle a work order.

In embodiments, a work manager 315 can execute a work or a work order. This can include receiving a work order from a service manager and coordinating the execution of tasks of the work according to inter-task dependency. A work manager can also dispatch a task order, which can include selecting a task manager and sending a task order to the selected task manager. A task order can be received from a service manager, or be associated with a work execution.

In embodiments, a task manager 320 can execute a task or handle a task order. This can include receiving a task order from a work manager and coordinating the execution of routines of a task execution according to inter-routine dependency. A task manage can also trigger a routine execution. This can include allocating an identification (ID) for the routine execution, identifying one or more routine managers associated with the routine, and notifying the routine managers to execute the routine. This can further include allocating a differentiator for the routine execution.

In embodiments, a service data repository 335 can store user subscription data, as well as a service profile for each registered computing service.

In embodiments, a routine manager 340 can perform routine synchronization. This can include triggering data communication between a routine client and a routine server according to a synchronization requirement associated with the routine. It can also provide k-anonymity, including ensuring the participation of at least a minimum number k of devices in the routine execution when the routine involves devices, wherein the minimum number k in some embodiments can be a system parameter.

In embodiments, a privacy router 345 can provide signal and data routing. This can include forwarding compute plane control signals and data traffic during the execution of a routine. A privacy router can also perform proxy re-encryption on out-going data traffic before forwarding, to allow user and device privacy and data confidentiality at the same time.

In embodiments, a resource manager 330 can manage and provision computing and network resources, according to resource requirements received from an orchestrator, via an interface T6a 332. A resource manager can also adapt resource provisioning to network dynamics in order to meet end-to-end quality-of-service (QoS) requirements, at a per-task granularity of execution granularity, e.g. according to information received from a task manager, via an interface T6b 333.

In an embodiment, an application controller (AC) 365 can belong to, or be controlled by, a service provider, and it can represent the service provider. An AC can connect to a service manager via an interface or connection T3 317, in order to manage the computing service, for example, to register or deregister a service, to update the registration of a service, or to trigger an execution of a work of the service. An AC can be integrated with an application server (AS) , or it can be a separate entity from an AS.

In an embodiment, an AS 355 can be located at a network location identified by an ID such as data network access identifier (DNAI) or by a network address such as an IP address. When a service function is deployed or instantiated at such a network location, an instance of the service function, i.e. a copy of software implementation, can be hosted (i.e. run) on the AS at the network location.

When or after a computing service is registered on a platform, service functions of the service can be deployed at selected network locations and they can connect to a compute plane selected for the computing service. Each of the network locations can be identified by an ID such as a DNAI or an IP address. The compute plane can include one or more privacy routers 345 and routine managers 340. The privacy routers can be interconnected via interfaces or connections T8 348. The service function instances or the ASs hosting them can each connect to a privacy router in the compute plane via an interface or connection T4 347. During an execution of the routine, two service function instances (i.e. a routine client and a routine server) associated with a routine can communicate via their associated, connected privacy routers.

An AC 365 can send a work order to the platform, which can accordingly trigger the execution of a work identified in the work order, by signaling proper service function instances and forwarding subsequent data traffic between the service function instances, according to inter-task dependency and intra-task dependency within the work. Data originated from a service function instance during the execution can be in the form of cipher text and be forwarded by the platform without decryption. Before the data forwarding, the platform can re-encrypt the data so that the intended receiver (i.e. a different service function instance) can recover the original data (plaintext) from it using the receiver’s private key.

In embodiments, a platform as illustrated in Fig. 3 can support and manage a computing service deployed in the network.

When a routing information is related to an interface or connection, the routing information is prefixed with the name of the interface or connection for simplicity. For example, a routing information related to an interface or connection T2 352, it can be written as T2 routing information.

When a prefixed routing information (e.g. T2 routing information) is related to a network entity such as a privacy router, an AC, or a service function instance (i.e. an AS hosting a service function instance) , the routing information describes or specifies how to reach the network entity over the corresponding interface or connection (e.g. T2 interface or connection) , and it can include any of the following information related to the network entity: a network address, a port number, a protocol type, a tunnel end point ID, a tunnel ID, etc.

The above can apply to any of, but not limited to, the T2 routing information, T4 routing information, T8 routing information, and T9b routing information according to embodiments. It can also be extended to any unnamed or unmentioned connection or interface when necessary.

If the service data repository 335 stores a service profile of a computing service, the computing service can be considered registered. The service profile of a computing service can include service description information (SDI) , which includes information describing the computing service. The SDI can be provided by an AC 365, e.g. through a service registration request 405, in an embodiment associated with Fig. 4, and it can also include information identifying the computing service, service meta information, service reusability information, and service availability information.

The information identifying a computing service can include a service ID and/or a service name.

The service’s meta-information can indicate which entity provides the computing service and who is the service provider. It can also describe or indicate the one or more works associated with the computing service and the functionality and/or purpose of each work.

The service’s availability information can indicate when and/or where a computing service is available, i.e. times and time intervals, in the form of times of a day, week, or month, and/or locations, and in the form of area IDs.

SDI can further includes data or information describing the following: service function (s) , work (s) , task (s) , routine (s) , deployment (i.e. service function instances or instances of the service functions) , and a compute plane associated with a computing service. These data or information can respectively be referred to as service function data (or information) , work data (or information) , task data (or information) , routine data (or information) and compute plane data (or information) .

In embodiments, service function data is a per-service function and it can include information for each service function associated with (or belonging to) a computing service, such as the following.

Service function data can include information identifying the service function, e.g. a function ID.

A service function can represent devices. In some embodiments, it is identified as representing/indicating devices (e.g. UEs) if this information has a particular/reserved format or value.

A service function can represent a work of a second computing service. When a service function represents a work of a second computing service, this information can include information identifying the work (e.g. a work ID) , and information (e.g. a service ID) identifying the second computing service. The second computing service can be referred to as a foreign service, the work can be referred to as a foreign work, and the service function can be referred to as a foreign function. The information identifying the second computing service is optional when the second computing service (i.e. the foreign service) is the current computing service (i.e. the one that the service profile is for) . When the second computing service is the current computing service, the service function (i.e. the foreign function) should not be used by any routine of the work (i.e. the foreign work) to prevent reuse loop.

When a service function represents devices or a work, it is a symbolic service function. However, when it does not represent devices or a work, the service function is not a symbolic service function (in this case, it can be considered a concrete service function) , and service function data (which is associated with the service function) can further include the following.

Service function data can include a software (executable or codes or image) implementation of the service function. Alternatively, it can include a reference (such as a URL) to the software implementation of the service function, or reference points to the location (e.g. storage location) of the software implementation of the service function, and it can be used to obtain the software implementation of the service function.

Service function data can include resource requirement information, such as information indicating the amount of compute resources (e.g. CPU cycles, memory, storage, I/O access) needed by the service function.

Service function data can include an outgoing traffic rate, such as information indicating the amount of outgoing traffic generated or transmitted by the service function within a certain amount of time. Alternatively, this information can indicate a relation between an amount of outgoing traffic and an amount of incoming traffic (i.e. traffic received by the service function) . For example, the relation can be that the amount of outgoing traffic and the amount of incoming traffic are equal, or that the amount of outgoing traffic is equal to the amount of incoming traffic, multiplied by a ratio having a value greater than or equal to zero (0) , and to which a constant value is added or subtracted.

Service function data can include instantiation requirement information, which can include an instantiation limit and/or an intra-function connectivity (connection) constraint.

In service function data, an instantiation limit can be information indicating a maximum number of instances and/or a minimum number of instances that the service function can have. The absence of a maximum number can imply that a default maximum number is to be applied, or that there are no limitations (i.e. the maximum number tends to infinity) . The absence of a minimum number can imply that a default minimum number is to be applied, or that there are no limitations (i.e. the minimum number tends to infinity) .

In service function data, an intra-function connectivity (or connection) constraint can be information indicating whether instances of the service function should be interconnected and/or how instances should be interconnected, e.g. whether via a tree topology, a ring topology, a mesh topology, etc. The lack of such constraint can imply that instances of the service function should not, or do not need to be connected.

In an embodiment, work data is per-work and for each work associated with, and belonging to, a computing service, work data can include the following information.

Work data can include information identifying the work, e.g. a work ID.

Work data can include meta-information about the work. This meta-information can include information describing the purpose or functionality of the work, information describing inputs and outputs of the work, e.g. information about input the format and structure of inputs and outputs, and information about how to provide inputs receive outputs.

Work data can include information identifying tasks included in the work, such as a list of task IDs.

Work data can include information about inter-task dependency among the tasks included in the work.

Work data can include information about cross-task synchronization among tasks included in the work. This information can include information about synchronized routines and information about context synchronization.

Regarding information about synchronized routines, in some embodiments, a service function can be associated with a routine group, i.e. multiple routines or a group of routines. Routines in the routine group can belong to different tasks, and when the routines are executed, the service function can provide or transmit identical data traffic for the routines, and the routines can be executed at the same time. Such routines can be referred to as synchronized routines, and the service function can be referred to as a joint service function. In some embodiments, there can be multiple such routine groups, which can be referred to as synchronized routine groups and can be identified by routine group IDs. For each synchronized routine group, the information about synchronized routines can include information (e.g. routine IDs) identifying the routines (i.e. the routines belong to the synchronized routine group) and their corresponding tasks (e.g. task IDs) , and information identifying the joint service function (e.g. function ID) . The information about synchronized routines can also indicate that the routines in the synchronized routine group should be executed at the same time, and that the joint service function can provide or transmit identical data traffic for the routines during the routine execution.

In some embodiments, a same routine manager can be selected for many routines in a synchronized routine group, and in other embodiments, it can be selected for all routines of a synchronized group.

In some embodiments, a symbolic function, for example a service function representing a foreign work, is not a joint service function.

Regarding information about context synchronization, in some embodiments, context synchronization can be required for a task group (i.e. a group of one or more tasks) , which means that when one or more tasks in the task group are being executed, data traffic associated with the task execution (s) should be synchronized or associated to a same computing context. In some embodiments, there might be multiple such task groups, and each one can be identified by a task group ID. For each task group, the information about context synchronization can include information identifying the one or multiple tasks belonging to the task group and it can indicate that context synchronization is required for the one or more tasks.

Information about cross-task synchronization can include reusability information about the work, indicating whether the work is reusable for developing a new computing service, in other words, whether it can be reused for such development. If the work is reusable, this information can include:

- information identifying ingress routine (s) and respective ingress function (s) ,

- information identifying egress routine (s) and respective egress function (s) ,

- information describing how a work can be reused, and

- information identifying entities (e.g. service providers) that can, or are allowed to reuse the work.

Information identifying ingress routines and respective ingress functions, e.g. routine IDs and function IDs, can relate to ingress routines belonging to a task of the work. An ingress routine can be associated with an ingress function and an internal service function (i.e. a core service function) , as illustrated in Fig. 2. An ingress function is a service function providing input data for the work. The input data can be provided to the internal service function (or core service function) . An internal service function (or core service function) is a service function that can be distinct from an ingress function and from an egress function.

Information identifying egress routines and respective egress functions, e.g. routine IDs and function IDs, can relate to an egress routine belonging to a task of the work. An egress routine can be associated with an egress function and an internal service function (or core service function) , as illustrated in Fig. 2. An egress function is a service function receiving output data of the work. The output data can be received from the internal service function (or from a core service function) . An internal service function (or core service function) is a service function that can be distinct from an egress function and an ingress function.

Information about cross-task synchronization can include information describing how a work can be reused, such as through a new deployment or through a remote connection, as detailed elsewhere in this invention disclosure.

Information about cross-task synchronization can include information identifying entities (e.g. service providers) that can, or that are allowed to, reuse the work. In embodiments, such information can be optional. When such information is optional, in some embodiments it may imply the work can be reused by anyone.

An embodiment can include task data, which can be per-task and include the following information for each task associated with (belonging to) the computing service:

- information identifying the task, e.g. a task ID,

- information identifying the routine (s) included in the task, e.g. a list of routine ID (s) ,

- information about the inter-routine dependency among the routines included in the task, e.g. ordering information of the list of routine ID (s) . Inter-routine dependency can also be referred to as intra-task dependency.

An embodiment can include routine data, which can be per-routine and include the following information for each routine associated with (belonging to) the computing service:

- information identifying the routine, e.g. a routine ID;

- information identifying service functions associated to the routine, e.g. function IDs;

- device information; and

- synchronization requirements.

Regarding information identifying service functions associated to the routine, a routine can be associated with two service functions, one of which may represent or indicate devices. The two service functions can be among those identified in the service function data. This information can further indicate which one of the service functions is a routine server function, and/or which one is a routine client function. The routing client function can represent or indicate devices.

When one of the above two service functions is a symbolic function representing a foreign work, i.e. a work in a second computing service (referred to as foreign service) , the routine corresponds to an ingress routine and/or an egress routine of the foreign work (defined or specified in the service profile of the foreign service) and it can be referred to as a foreign routine. The information identifying service functions associated to the routine can further indicate whether the routine corresponds to an ingress routine, and/or an egress routine of the foreign work, such as by including information identifying the ingress routine and/or the egress routine of the foreign work. If, in an embodiment, neither of the two service functions represents a foreign work, the routine can be referred to as a native routine, i.e. a routine that is native to the work, or to the service.

If one of the two service functions is an ingress function for a work that the routine belongs to, as identified in work data associated with the work, the routine is an ingress routine for the work. If one of the two service functions is an egress function for a work that the routine belongs to, as identified in the work data, the routine is an egress routine for the work. A routine can be both an ingress routine and an egress routine, for example, when one of the two service functions is both an ingress function and an egress function for a work that the routine belongs to. A routine belongs to a work if the routine belongs to a task that belongs to the work, in other words, if the work includes a task that includes the routine.

Routine data can include device information, which can be information about devices (e.g. UEs) represented by a service function of the routine (routine client function) . The devices identified in such information can (are allowed to) participate (join) in an execution of the routine. They can be viewed as instances of the service function (routine client function) and be referred to as routine clients. Such information can also be considered to be associated with the service function (routine client function) for the routine. If the routine client function of the routine does not represent devices, it can be optional. Such information can include:

- information identifying the devices, and

- information about potential/possible location (or location area) of the devices.

Information identifying the devices can include a list of device IDs or network addresses, or a device group ID, and/or it can indicate that any device can be associated to the routine. The absence of such information can imply that any device or a default device group (i.e. devices in the default device group) can be associated with the routine.

Information about potential or possible locations (or location areas) of the devices can include a list of zone IDs. Each zone can identify a geographic region, which can be in the form of a cell ID or a radio access network (RAN) node ID.

Routine data can include synchronization requirements, which refer to information about one or more synchronization requirements associated with the routine. This information is described elsewhere in the invention disclosure. This information is optional in routine data.

In an embodiment, a computing service can be considered deployed if the service profile of the computing service includes deployment data and compute plane data as described further. Otherwise, a computing service can be considered to be non-deployed. If a computing service is deployed, the computing service must have been registered. The deployment of the computing service can include instances of the service functions of the computing service, as well as inter-connections between the service function instances.

In an embodiment, the deployment data describes deployment of the computing service, and the computing plane data describes the compute plane associated with the computing service. The deployment data and the compute plane data can be generated by the platform, e.g. during an instantiation of the computing service.

In an embodiment, the deployment data is present after the computing service is deployed. Deployment data information can include:

- service function instance information,

- inter-function connectivity (connection) information,

- intra-function connectivity (connection) information.

Deployment data information can include service function instance information, which is information (e.g. a list of instance IDs) identifying service function instances, i.e. instances of service functions that are concrete functions (i.e. not abstract functions) as indicated in the service function data. An instance of a service function corresponds to a deployment location of the service function. The instance ID of a service function instance can include, or correspond to, information (e.g. function ID) identifying the service function and information identifying the deployment location (e.g. a location ID, network address or name) . In some embodiments, such information can further include T4 routing information for each of the service function instances. The T4 routing information can be used to reach the corresponding service function instance over an interface T4.

The service function instance information can further include inter-function connectivity (connection) information and intra-function connectivity (connection) information.

Inter-function connectivity (connection) information (i.e. service function instance association information) can be per-routine. A routine is associated with a routine client function and a routine server function. An inter-function connection can refer to an association between a routine client (i.e. an instance of the routine client function) and a routine server (i.e. an instance of the routine server function) , and imply that the routine client and the routine server can communicate or interact with each other during an execution of the routine. The inter-function connectivity (connection) information can indicate inter-function connectivity, i.e. which instance (identified by, e.g. an instance ID) of the routine server function is associated/connected with which instance (identified by, e.g. an instance ID) of the routine client function. The routine server, and if the routine client is not a device, the routine client, are among those identified in the service function instance information.

Intra-function connectivity information (a. k. a. service function instance connectivity information) is per-routine and is related to a service function that is associated with the routine and does not represent devices. The service function can be a routine client function of the routine or a routine server function of the routine. Intra-function connectivity refers to connectivity between a first instance of the service function and a second instance of the service function, and implies that the two instances can communicate with each other during an execution of the routine. When a service function has multiple instances, the intra-function connectivity information indicates intra-function connectivity among the multiple instances of the service function, i.e. whether there is connectivity between any two of the multiple instances. In an embodiment, such information can be optional.

The compute plane data is present after the computing service is deployed. This information includes:

- privacy router information,

- privacy router interconnection information,

- routine manager information.

Privacy router information is information identifying the privacy router (s) 345 in the compute plane and, for each identified privacy router, information identifying its associated service function instance (s) . The service function instance (s) are among those identified in the deployment data, by the service function instance information.

Privacy router interconnection information can indicate, for any pair of a first privacy router and a second privacy router, whether there is a connection or connectivity T8 348, between the first privacy router and the second privacy router (i.e. whether they are connected) . The first privacy router and the second privacy router are among those identified in the privacy router information.

Routine manager information (e.g. IDs or network addresses) can identify the routine managers in the compute plane and, for each identified routine manager, information (e.g. routine ID) identifying the associated routine (s) and information (e.g. instance ID (s) ) identifying service function instance (s) associated with each of the routine (s) . The service function instance (s) are among those identified in the deployment data (by the service function instance information) .

Information in the service profile can either be provided by the AC 365, or generated by the platform. In the following, management and operational procedures of the platform are described with respect to the system architecture illustrated in Fig. 3.

Fig. 4 illustrates a procedure of service registration for a first computing service, initiated by an application controller (AC) , according to an embodiment. Such procedure can be used to update an existing registration, of a first computing service that can reuse a second computing service. More specifically, a work X of the first computing service can reuse a work Y of the second computing service. During the procedure, the reuse is authorized, and a service profile of the first computing service is created or updated in the service data repository 335.

If delayed deployment is not indicated by the AC, the first computing service (i.e. service functions of the first computing service) is deployed or instantiated in the network during the service registration. The deployment of the first computing service includes instances of service functions of the first computing service, as well as intra-function and inter-function connections of the service function instances. Furthermore, a compute plane is selected for the first computing service and associated with the deployment of the first computing service. The compute plane can include privacy routers, coupled (or associated) with the instances of the service functions. The compute plane also includes routine managers corresponding to the routines of the first computing service.

In an initial step, the AC 365 requests to register the first computing service, by sending a service registration request 405 to the service manager 1 (310) . The service registration request includes information (e.g. a service ID or name) identifying the first computing service and service description information (SDI) of the first computing service.

Then, the service manager 1 can identify the reuse, i.e. that the work X of the first computing service reuses the work Y of the second computing service, according to the registration request (e.g. the SDI in the registration request) . The service manager 1 can interact with a service manager 2 (412) , which can be a service manager that is serving the second computing service, by requesting authorization 410 to the reuse of the work Y. If the SDI does not indicate the reuse, this step is optional.

The SDI in the service registration request can indicate the reuse and include information identifying the second computing service and information identifying the work Y. The SDI may further include information identifying the service provider that provides the first computing service.

The requesting of an authorization 410 to the reuse of the work Y can include sub-steps. These sub-steps can include the service manager 1 310 requesting an authorization 410 from the service manager 2 412 to authorize the reuse by sending an authorization request to the service manager 2. The service manager 1 can discover or select the service manager 2 using the information identifying the second computing service. The authorization request sent to the service manager 2 can include the information identifying the first computing service, the information identifying the second computing service, the information identifying the work Y, and information identifying the reuse. The information identifying the reuse can include information identifying a service function of the first computing service, which represents the work Y and is associated with the work X. The information identifying the reuse can further include information identifying the work X. The information identifying the reuse can be used to identify the reuse when there are multiple different reuses of the work Y by the first computing service. The authorization request can further include the information identifying the service provider that provides the first computing service.

Another sub-step of requesting of an authorization 410 can be the service manager 2 authorizing 415 the reuse according to the information in the authorization request. In some embodiments, the service manager 2 identifies (e.g. in local storage) or obtains (e.g. from the service data repository) a service profile of the second computing service using the information identifying the second computing service, and the service manager 2 uses the information (e.g., information about cross-task synchronization in work data related to the work Y as described above) in the service profile of the second computing service to authorize the reuse.

In some embodiments, the service manager 2 uses a network entity (e.g. an AC having registered the second computing service, or an authentication, authorization and accounting server (AAA server) to authorize the reuse. The service profile of the second computing service can indicate that the network entity is to be used for authorizing the reuse and includes information (e.g. a domain name, an IP address) identifying the network entity. The service manager 2 accordingly performs 415 the authorization. That is, the service manager 2 sends the information identifying the service provider that provides the first computing service, the information identifying the second computing service, and the information identifying the work Y to the network entity, and the network entity sends the authorization result (i.e. the reuse is authorized/allowed) to the service manager 2.

Another sub-step of requesting of an authorization 410 can be the service manager 2 updating 420 the service profile of the second computing service to record the reuse. The service manager 2 can make a work Z of the second computing service correspond to the reuse. Accordingly, in some embodiments, the service manager 2 can map the information identifying the work Z to the combination of the information identifying the first computing service and the information identifying the reuse. The service manager 2 stores the mapping in the service profile of the second computing service, by sending the information identifying the first computing service and the information identifying the reuse, and by indicating the mapping, to the service data repository 335.

If the service profile of the second computing service indicates that the work Y is to be reused through remote connection, the reuse can be supported directly by the work Y (as opposed to being supported by a replica work of the work Y) . In this case, the work Z is the work Y, and the information identifying the work Z can include information identifying the work Y. The information identifying the work Y may be an ID of work Y or an alias or pseudonym of the work Y, e.g. in the form of a work ID.

The service manager 2 can generate the information identifying the work Z, which can include an alias or pseudonym of the work Y, e.g. in the form of a work ID.

The service manager 2 can map the information identifying the work Z to the information identifying the work Y. The service manager 2 can store the mapping in the service profile of the second computing service, by sending or indicating the mapping to the service data repository.

If the service profile of the second computing service indicates that the work Y is to be reused through new deployment, the reuse can be supported by a replica work of the work Y. In this case, the work Z is a replica of the work Y and it can be generated by the service manager 2 in this step according to the reuse, as follows.

The service manager 2 replicates the work Y (including composite tasks and routines) into a replica work. The service manager 2 can allocate or generate information identifying the replicas, including a work ID identifying the replica work Z, task IDs identifying the replica tasks and routine IDs identifying the replica routines. The service manager 2 can store the information in the service profile of the second computing service by sending the information to the service data repository 335.

The service manager 2 maps the information identifying the replicas (e.g. the replica work) to the information identifying the corresponding originals (e.g. the work Y) so that the replicas are correlated with their originals. The service manager 2 stores the mapping in the service profile of the second computing service by sending or indicating the mapping to the service data repository 335.

In either of the above cases, the service data repository can store the information received from the service manager 2 as part of the service profile of the second computing service. The service data repository 335 can respond to the service manager 2, confirming that the information is stored successfully.

Another sub-step of requesting of an authorization 410 can be the service manager 2 412 responding 425 to the authorization request of the service manager 1 (310) . The authorization response includes an authorization result. The authorization result indicates that the first computing service is authorized to reuse the work Z of the second computing service. As described previously, when the reuse is through remote connection, the work Z is the work Y; when the reuse is through new deployment, the work Z is a replica of the work Y.

In a case where the work Z is a replica of the work Y, and in some embodiments where the work Z is the work Y, the service manager 1 (310) can process the service description information (SDI) of the first computing service according to the authorization result. For example, the service manager can translate or map the reuse of the work Y to a reuse of the work Z, and update the SDI accordingly, by replacing the information identifying the work Y with the information identifying the work Z.

The service manager 1 (310) can create 430 a service profile for the first computing service in the service data repository, by sending a request to the service data repository. The request includes the information identifying the first computing service. If the SDI of the first computing service was processed when the service manager 2 updated 420 the service profile of the second computing service to record the reuse, the request can include the processed SDI; otherwise, the request can include the SDI received from the AC in step 1.

The service data repository can store a service profile for the first computing service. This includes storing information as part of the service profile, the content of which is described above. The service data repository can respond to the service manager 2, indicating that the service profile is created successfully.

The service manager 1 (310) can instantiate the first computing service according to the SDI of the first computing service.

The initial service registration request 405 can indicate that the instantiation 435 of the first computing service should be delayed, by including an indication of delayed instantiation. If the service registration request indicates delayed instantiation, this step is optional.

After instantiating the service 435, the service manager 1 can respond 440 to the service registration request, by indicating to the application controller 365 that the requested service registration has been completed or accepted.

During registration of the first computing service, the service manager 1 (310) can request the orchestrator 325 to instantiate the first computing service, or to do so after registration of the first computing service and upon receiving a request from the AC 365 for service instantiation for the first computing service. The orchestrator 325 can accordingly perform service orchestration for the first computing service. This can include making a service deployment decision and a compute plane selection decision, both for the first computing service based on the service profile of the first computing service. The orchestrator can make the service deployment decision and the compute plane selection decision jointly.

When making the service deployment decision, the orchestrator 325 determines deployment locations, i.e. network locations where service functions (only those that are not abstract functions) of the first computing service are to be deployed. A service function can be determined to have one or multiple deployment locations, i.e. to be deployed and/or instantiated at one or multiple network locations.

After a service function is deployed and/or instantiated at a deployment location, there is an instance of the service function (e.g. in the form of a copy of the software implementing the service function) at the deployment location. The service function instance is identified by an instance ID. In some embodiments, the instance ID includes the information identifying the deployment location and the information identifying the service function.

When making the service deployment decision, for each routine of the first computing service, the orchestrator 325 can also determine inter-function connections and intra-function connections of service function instances related to the routine.

When making the compute plane selection decision, the orchestrator 325 can determine or select a compute plane for the first computing service. The compute plane can include one or multiple privacy routers 345 and one or multiple routine managers 340. The privacy routers are associated to the service function instances, while the routine managers correspond to routines of the computing service. In some embodiments, for routines that need to be synchronized (i.e. routines belonging to a same synchronized routine group) , as indicated in the information about synchronized routines in the service profile of the first computing service, the orchestrator can select a same routine manager.

When making the compute plane selection decision and selecting the compute plane, the orchestrator selects the privacy routers and the routine managers from a pool of privacy routers and routine managers. If there are no, or insufficient privacy routers or routine managers for a selection, the orchestrator 325 can trigger to enlarge the pool to deploy additional privacy routers 345 and/or routine managers 340 at selected network locations, and then select the privacy routers and/or the routine managers from the enlarged pool.

In some embodiments, when the first computing service reuses a second computing service (i.e. when a work X of the first computing service reuses a work Z of the second computing service) , and when performing service orchestration, the orchestrator 325 can further make an incremental deployment decision and/or a compute plane reselection decision for the second computing service. The orchestrator 325 provides the compute plane reselection decision for the second computing service to a service manager, e.g. service manager 2 (412) , serving the second computing service, which then implements the decision, i.e. it reconfigures the compute plane for the second computing service accordingly.

When making the incremental deployment decision for the second computing service: if the work Z is a replica work of a work Y of the second computing service (e.g. as indicated in the service profile of the second computing service) , the orchestrator 325 makes dynamic deployment decisions for the work Z, including determining additional deployment locations and corresponding resource (computing/network resource) requirements of each internal function of the work Y, and determining inter-function connections and inter-function connections based on these additional deployment locations.

If the work Z is not a replica work (e.g. as indicated in the service profile of the second computing service) , the orchestrator makes deployment sharing decisions about the work Z, including selecting instance (s) of each internal function of the work Z from the deployment of the work Z for the first computing service to reuse. These selected instances of the internal function are then shared by both the first computing service (i.e. the work X of the first computing service) and the second computing service (i.e. the work Z of the second computing service) .

When making the compute plane reselection decision for the second computing service, the orchestrator reselects the computing plane for the second computing service, according to the incremental deployment decision for the second computing service and the service deployment decision for the first computing service. When the orchestrator reselects the computing plane, the orchestrator can reselect (or relocate) , add, and/or remove some of compute plane entities (e.g. routine managers, privacy routers) associated with the second computing service to optimize compute plane efficiency.

To implement the deployment decisions, i.e. the service deployment decision for the first computing service, and the incremental deployment decision for the second computing service, the orchestrator 325 interacts with the resource manager 330.

The orchestrator 325 provides the compute plane selection decision for the first computing service to the service manager 1 (310) , which can implement the decision, i.e. configure the computing plane accordingly.

In an embodiment, the first service and the second service can be the same service. This can allow the addition of a new work into the service, based on existing works in the service. Accordingly, in some embodiments the service registration request is a service registration request to add a new work into the service based on existing works in the service.

Instantiating a service 435 can include multiple steps, which can be described in an instantiation procedure as follows.

Fig. 5 illustrates a service instantiation procedure, in accordance with embodiments. Initially, the service manager 1 (310) requests to instantiate the first computing service, by sending 505 a service instantiation request to the orchestrator. The request includes information (e.g. a service ID) identifying the first computing service. In some embodiments, the request includes information associated with the service profile of the first computing service. The information associated with the service profile of the first computing service can include the service profile (e.g. the SDI) .

Then, the orchestrator 325 obtains service profile (s) related to the deployment request. If the service instantiation request 505 does not include the service profile of the first computing service, the orchestrator obtains the service profile of the first computing service from the service data repository 335, by sending 510 the information identifying the first computing service to the service data repository 335 and by receiving 512 the corresponding service profile from the service data repository 335.

In some embodiments, when the first computing service reuses a second computing service, the service profile of the first computing service indicates a reuse (by the first computing service) of a work Z of the second computing service and includes information identifying the second computing service and information identifying the work Z. In this case, the orchestrator 325 obtains 512 the service profile 510 of the second computing service from the service data repository 335, by sending 510 the information identifying the second computing service (and possibly the information identifying the work Z) to the service data repository, and by receiving 512 the corresponding service profile from the service data repository 335.

Then, the orchestrator 325 performs service orchestration 515 according to the service profile of the first computing service and, if applicable, the service profile of the second computing service. When performing service orchestration 515, the orchestrator makes a service deployment decision and a compute plane selection decision, both for the first computing service, as described above, and if the first computing service reuses the second computing service, the orchestrator can further make an incremental deployment decision and a compute plane reselection decision, both for the second computing service, as described above.

The orchestrator notifies the deployment decision (s) , including the service deployment decision for the first computing service and, if applicable, the incremental deployment decision for the second computing service, to the resource manager for implementation, and requests 520 appropriate resources. The orchestrator may provide software image (s) of related service functions or information identifying or locating the software images to the resource manager in this step.

The resource manager 330 implements the deployment decision (s) by instantiating and/or deploying the related service function (s) using corresponding software image (s) , and provides 525 the requested resources (compute resources and/or network resources) , according to corresponding resource requirements at respect deployment location (s) .

The resource manager 330 receives the software image (s) with the orchestrator’s request 520 of resources, or obtains the software image (s) from some network location (s) (e.g. a server, or its own local storage) using information received with the orchestrator’s request 520 of resources, i.e. the information identifying/locating the software image (s) .

After a service function (e.g. one indicated in the service deployment decisions) is instantiated or deployed at a deployment location (e.g. a corresponding deployment location indicated in the service deployment decisions) , there is an instance of the service function at the deployment location. The instance of the service function can be identified using information identifying the service function and information identifying the deployment location.

Then, the resource manager 330 can respond 530 to the orchestrator 325 to confirm that the deployment decision (s) have been implemented (i.e. that related service function (s) have been instantiated and/or deployed) . For each of the service function instances, the resource manager providing resources 525 can include information identifying the service function instance (e.g. information identifying corresponding service function and information identifying the corresponding deployment location) , as well as a T4 routing information associated with the service function instance, in a response sent 530 to the orchestrator.

The T4 routing information describes or specifies how to reach (communication with) the service function instance over an interface T4 347. The T4 routing information can include any of the following information related to the service function instance: a network address, a port number, a protocol type, a tunnel end point ID, a tunnel ID, etc. The T4 routing information can be generated and/or allocated by the resource manager, or be received from the corresponding deployment location by the resource manager while providing 525 resources, when deploying the service function instance.

Then, the orchestrator 325 can update the related service profile (s) in the service data repository. This can include updating the service profile of the first computing service in the service data repository, where the orchestrator generates deployment data based on the service deployment decision for the first computing service and the T4 routing information related to the first computing service (which is received from the resource manager in step 6) , and sends 535 it to the service data repository. The orchestrator can generate compute plane data based on the compute plane selection decision for the first computing service. Updating the service profile of the first computing service in the service data repository can also include the orchestrator sending 535 the deployment data, the compute plane data and the information identifying the first computing service to the service data repository. The service data repository stores the deployment data and the compute plane data in the service profile of the first computing service.

Updating the related service profile (s) in the service data repository can also include the orchestrator updating the service profile of the second computing service in the service data repository. In doing so, the orchestrator generates deployment data based on the incremental deployment decision for the second computing service and the T4 routing information related to the second computing service, which is received from the resource manager while responding to the resource request 530. The orchestrator generates compute plane data based on the compute plane reselection decisions for the second computing service and the service profile of the second computing service. The orchestrator can then sends 535 the deployment data, the compute plane data and the information identifying the second computing service to the service data repository. The service data repository stores the deployment data and the compute plane data in the service profile of the second computing service, replacing the existing ones.

Then, the orchestrator interacts with the service manager 2 (412) to implement the compute plane reselection decision for the second computing service. The service manager 2 is a service manager that manages or is managing the second computing service. The orchestrator selects or identifies the service manager 2 using the information identifying the second computing service. The orchestrator can perform the following sub steps.

The orchestrator 325 requests 540 the service manager 2 (412) to configure the compute plane for the second computing service. The request sent to the service manager 2 includes the information identifying the second computing service.

In some embodiments, the request to configure the compute plane 540 includes the deployment data associated with the second computing service and the compute plane data associated with the second computing service. These data can be generated by the orchestrator while updating a related service profile by sending it service profile data 535.

The service manager 2 can configure 545 the compute plane for the second computing service, according to the deployment data and the compute plane data received in the request 540 to do so. In some embodiments, when the orchestrator does not provide the deployment data and the compute plane data in the request 540, the service manager 2 can obtain these data from the service data repository by sending the information identifying the second computing service to the service data repository after receiving the request and receiving these data from the service data repository.

Then, the service manager 2 can respond 550 to the orchestrator, indicating that the configuration is complete.

Then, the orchestrator 325 can interact with the service manager 1 (310) to implement the compute plane selection decision for the first computing service. To do so, the orchestrator can perform the following sub steps.

Initially, the orchestrator requests 555 the service manager 1 (310) to configure the compute plane for the first computing service. The request 555 sent to the service manager 1 (310) includes the information identifying the first computing service.

In some embodiments, the request 555 includes the deployment data associated with the first computing service and the compute plane data associated with the first computing service. These data are generated by the orchestrator while updating 535 a service profile.

Then, the service manager 1 (310) can configure 560 the computing plane for the first computing service, according to the deployment data and the compute plane data received in the request 555 to configure the control plane. In some embodiments, if the orchestrator does not provide the deployment data and the compute plane data with the request 555, the service manager 1 (310) can obtain these data from the service data repository 335 by sending the information identifying the first computing service to the service data repository after receiving the request and receiving these data from the service data repository.

Then, the service manager 1 (310) can respond 565 to the orchestrator, indicating that the configuration is complete.

In some embodiments, the service manager 1 responding 565 to the orchestrator can run in parallel with the request 540 from the orchestrator to configure the compute plane, or it can start before that request 540 is complete.

Then, the orchestrator can respond 570 to the service manager 1 regarding the service manager 1’s initial service instantiation request 505.

In some embodiments, if the orchestrator requests configuration of the compute plane from both the service manage 2 (412) and the service manager 1 (310) sequentially, the orchestrator’s response 570 to the service instantiation can be integrated within its request 555 to configure the compute plane.

In an embodiment associated with Fig. 5, a routine referred to as routine P can be associated with a task referred as task T, which in turn can be associated with a work referred to as work X, all three of which can be associated with the first computing service in Fig. 5. They can also be said to be native to the computer service. The computer service can include one or more other routines. The routine P can be associated with a first service function F1 (routine client function F1) , and a second service function F2 (routine server function F2) .

If the computing service is deployed, the deployment of the computing service includes an instance FI1 of the service function F1 of the routine P, which can be referred to as a routine client FI1, and an instance FI2 of the service function F2 a routine server of the routine P. The service profile of the computing service can be updated 535 to include deployment data describing the deployment.

A compute plane can be selected for the computing service during service orchestration 515, and associated with the deployment of the computing service. The compute plane can include one or multiple routine managers 340. Among the one or multiple routine managers, a routine manager is assigned to manage the routine P with respect to the two service function instances FI1 and FI2. The compute plane further includes a first privacy route R1 and a second privacy router R2, which are respectively associated with function instances FI1 and FI2. The privacy routers R1 and R2 can be the same entity, e.g. if the two service function instances FI1 and FI2 are associated with a same privacy router. The service profile of the computing service can be updated to include compute plane data describing the compute plane.

Whether it is service manager 1 (560) or service manage 2 (545) , a service manager serving the computing service configures the compute plane, in accordance with the deployment data and the compute plane data. The service manager can obtain or receive the deployment data and the compute plane data from a network entity, e.g. from the service data repository or from the orchestrator. When configuring the compute plane, the service manager performs a configuration procedure for the routine P, in accordance with service function instances FI1 and FI2. The configuration procedure is illustrated in Fig. 6.

In an embodiment where the privacy router R1 and the privacy router R2 are the same entity, the entity can be configured in one step, and further configuration can be optional. The configuration procedure in Fig. 6 assumes the routine client function F1 does not represent devices. When the routine client function F1 does represent devices, the procedure is reduced to fewer steps.

Fig. 6 illustrates a procedure for a service manager to configure a routine manager, according to an embodiment. Initially, the service manager 310 configures 605 the routine manager 340. In this step, the service manager sends or provides the following information to the routine manager: information (e.g. service ID) identifying the computing service, information (e.g. routine ID) identifying the routine P, information (e.g. instance ID) identifying the service function instance FI1, information (e.g. instance ID) identifying the service function instance FI2, information (e.g. ID or network address) identifying the privacy router R1 345, and information (e.g. ID or network address) identifying the privacy router R2 346.

In this step, the routine manager 340 can also send or provide 607 T9b routing information related to the routine manager, to the service manager 310. The service manager 310 can then provide the T9b routing information to the privacy router R1 and to the privacy router R2 in subsequent steps, so that the privacy routers R1 and R2 can reach (e.g. route data or control signal to the routine manager for the routine using the information.

Then, the service manager 310 can configure 610 the privacy router R2 346. In this step, the service manager configures the privacy router R2 by sending or providing the following information to the privacy router R2: the information identifying the computing service, the information identifying the routine P, T4 routing information related to the service function instance FI2, the T9b routing information related to the routine manager, received during configuration 605 of the routine manager. The service manager 310 can have obtained the T4 routing information related to the service function instance FI2 from the orchestrator, in an earlier step or an earlier procedure, such as during a request to the service manager 2 to configure 540 the compute plane or to the service manager 1 to configure 555 the compute plane.

While being configured 610, the privacy router R2 can also provide 612 T8 routing information and T9b routing information to the service manager 310. This routing information can be related to the privacy router R2. In this step, the privacy router R2 can further provide 612 T4 routing information related to the privacy router R2, to the service manager. The service manager can then send the T4 routing information related to the privacy router R2 to the AC, which may further send it to the service function instance FI2. Alternatively, the privacy router R2 can send the T4 routing information related to the privacy router R2, to the service function instance FI2 directly (without involving the service manager) , using the T4 routing information related to the service function instance FI2. The T4 routing information related to the privacy router R2 describes or specifies how to reach (e.g. route data or control signal to) the privacy router R2 for the routine over a T4 connection/interface.

Then, the service manager can configure 615 the privacy router R1. In this step, the service manager provides the following information to the privacy router R1: the information identifying the computing service, the information identifying the routine P, T4 routing information related to the service function instance FI1, the T8 routing information related to the privacy router R2, and the T9b routing information related to the routine manager (initially received during configuration 605 of the routine manager) . The T8 routing information related to the privacy router R2 can allow the privacy router R1 to reach (e.g. route data to) the privacy router R2 for the routine using the information. The service manager can have obtained the T4 routing information related to the service function instance FI1 from the orchestrator, in an earlier step, such as during a request to the service manager 2 to configure 540 the compute plane or to the service manager 1 to configure 555 the compute plane.

During configuration 615 of the privacy router R1, the privacy router R1 345 can also provide 617 T8 routing information and T9b routing information to the service manager 310. This routing information is related to the privacy router R1. In this step, the privacy router R1 can also provide T4 routing information related to the privacy router R1, to the service manager. The service manager can then send the T4 routing information related to the privacy router R1 to the AC, which can further send it to the service function instance FI1. Alternatively, the privacy router R1 can send the T4 routing information related to the privacy router R1 to the service function instance FI1 directly (without involving the service manager) , using the T4 routing information related to the service function instance FI1. The T4 routing information related to the privacy router R1 describes or specifies how to reach (e.g. route data or control signal to) the privacy router R1 for the routine over a T4 connection or interface.

Then, the service manager can configure 620 the routine manager. In this step, the service manager provides the T9b routing information related to the privacy router R2 (received during the configuring 610 of privacy router 2) , and the T9b routing information related to the privacy router R1 (received during the configuring 615 of privacy router 1) , to the routine manager 340.

Then, the service manager 310 can configure 625 the privacy router R2 346. In this step, the service manager provides the T8 routing information related to the privacy router R1, received during the configuration of privacy router 1 (615) to the privacy router R2.

During instantiation of a computing service, a compute plane is selected for the computing service. The computing plane includes a routine manager that is assigned to manage an execution of a routine within the computing service. The routine is associated with a first service function (referred to as a routine server function) and a second service function (referred to as a routine client function) . Embodiments include a procedure for configuring the routine manager, wherein the routine manager is provided with information about the routine and/or with information about a data sub plane, which is part of the compute plane, that is to be used to support (e.g. process and transport data traffic related to) the execution of the routine.

Fig. 7 illustrates a procedure for configuring a routine manager, according to an embodiment. Initially, the service manager 310 sends 705 a configuration request to the routine manager 340. The configuration request includes information about the routine and/or information about the data sub plane. The information about the routine includes any of the following: information (e.g. a service ID) identifying the computing service, information (e.g. a routine ID) identifying the routine, information (e.g. a function ID) identifying the routine server function, and information (e.g. a function ID) identifying the routine client function. The information about the data sub plane can also include information about the addition of service function instance (s) , information about removal of service function instance (s) , and information about privacy router (s) .

The information about addition of service function instances can indicate that one or multiple instances of the routine server function are associated with the routine manager for the routine, e.g. by including information (e.g. one or multiple instance IDs) identifying the one or multiple instances of the routine server function. The information about the addition of service function instance (s) can indicate that one or multiple instances of the routine client function are associated with the routine manager for the routine, e.g. by including information (e.g. one or multiple instance IDs) identifying the one or multiple instances of the routine server function.

The information about a removal of service function instances can indicate that one or multiple instances of the routine server function are no longer associated with the routine manager for the routine, e.g. by including information (e.g. one or multiple instance IDs) identifying the one or multiple instances of the routine server function. The information about the removal of service function instance (s) can indicate that one or multiple instances of the routine client function are no longer associated with the routine manager for the routine, e.g. by including information (e.g. one or multiple instance IDs) identifying the one or multiple instances of the routine server function.

The information about privacy routers can include, for a service function instance associated with the routine manager (e.g. every one of those identified in the information about addition of service function instances) , information (e.g. an ID, a network address) identifying the privacy router associated with the service function instance. For an identified privacy router, the information about privacy routers can further include T9b routing information. The T9b routing information describes or specifies how to reach (e.g. route data to) the identified privacy router over a connection or interface T9b for the routine.

Then, the routine manager 340 can send 710 a configuration response to the service manager 310, acknowledging reception of the configuration request. In the configuration response, the routine manager can include T9b routing information related to the routine manager. The T9b routing information describes or specify how to reach (e.g. route data to) the routine manager over a connection or interface T9b for the routine.

During instantiation of a computing service, a compute plane is selected for the computing service. The compute plane includes one or multiple routine managers 340 and one or multiple privacy routers 345.

If a privacy router is in the compute plane, the privacy router is associated with a routine within the computing service via a service function instance, and the service function instance is an instance of a service function associated with the routine. The service function belongs to the computing service, i.e. it is native to the computing service. The service function instance can participate in an execution of the routine via the privacy router, e.g. by sending or receiving data traffic related to the execution of the routine via the privacy router. The privacy router 345 is coupled with a routine manager 340 in the compute plane, which is assigned to manage the routine with respect to the service function instance.

Fig. 8 illustrates a procedure for configuring a privacy router for a routine, in accordance with a service function instance, according to an embodiment. Initially, the service manager 310 sends 805 a configuration request to the privacy router 345. The configuration request can include any of the following: information (e.g. a service ID) identifying the computing service, information (e.g. a routine ID) identifying the routine. The configuration request can include T4 routing information. The T4 routing information is related to the service function instance. The privacy router can use the T4 routing information to route data (e.g. received from an interface or connection T8) to the service function instance over a connection or interface T4.

Then, the privacy router 345 can send 810 a configuration response to the service manager 310, acknowledging reception of the configuration request. In the configuration response, the privacy router can include any of T4 routing information, T8 routing information, and T9b routing information. This routing information is related to the privacy router; it describes or specify how to reach (e.g. route data traffic or control signal to) the privacy router 345, over connections or interfaces T4, T8, T9b for the routine. In some embodiments, the routing information can be used to reach the privacy router for other routines. In this step, the privacy router R1 can send the T4 routing information related to the privacy router, to the service function instance using the T4 routing information related to the service function instance. The T4 routing information related to the service function instance is included in the configuration request received from the service manager. The service function instance can then use the T4 routing information related to the privacy router to reach the privacy router for the routine.

Fig. 9 illustrates a procedure of service deregistration for a computing service (i.e. a first computing service) , initiated by an application controller, according to an embodiment. After this procedure is complete, the computing service’s service profile is removed or deleted from the serviced data repository. If the computing service has been deployed, the compute plane associated with the computing service is released, and resources (compute resources, transport resources) related to the computing service are released. If the computing service reuses a second computing service, deployment of the second computing service and the compute plane associated with the second computing service can be changed due to the deregistration of the computing service.

Initially, the application controller (i.e. AC) sends 905 a deregistration request to the service manager 310 for deregistering a first computing service. The request includes information (e.g. a service ID or name) identifying the first computing service.

Then, the service manager releases 910 the compute plane associated with the first computing service. If the first computing service is not yet deployed, this step is optional. In this step, the service manager 310 notifies each compute plane entity (e.g. routine manager, privacy router) in the compute plane to remove local data and/or configuration data related to the first computing service, which can then do so accordingly. The notification sent to each compute plane entity includes information identifying the first computing service.

Then the service manager 310 interacts with the orchestrator 325 to release resources 915 (e.g. compute resources, transport and/or network resources such as wireless resources and radio resources) associated with or related to the first computing service. For example, the orchestrator 325 sends a resource release request to the orchestrator, the request including the information identifying the first computing service. If the first computing service is not yet deployed yet, this step is optional.

According to the request to release resources 915, the orchestration interacts with a resource manager to release the resources. As a result, instances of service functions (non-abstract ones) associated with the first computing service are deleted or removed. If the first computing service reuses a second computing service, the orchestration can change the deployment and the compute plane of the second computing service, e.g. remove unnecessary service function instances and/or computing plane entities, and adapt resources allocation decision associated with the second computing service. The orchestrator updates the service profile of the second computing service in the service data repository to reflect the change and triggers a selected service manager, which can be the service manager 310 of Fig. 9, to update the compute plane of the second computing service accordingly.

Then, the service manager 310 requests and/or informs the service data repository 335 to delete 920 the service profile of the first computing service.

Then, the service manager 310 replies to the application controller 365, indicating that the first computing service has been deregistered, by sending a deregistration response 925.

In an embodiment, a device can receive announcements regarding a computing service.

Fig. 10 illustrates a service announcement procedure, according to an embodiment. To allow a service announcement, an access manager can subscribe to receive information about registered computing services from the service data repository and provides part of the information that is related to a device, the device being a registered device.

Initially, the access manager 305 can subscribe 1005 to receive computing service information (i.e. to receive information about computing services) , by sending a subscription request to the service data repository 335. The subscription request includes information describing the subscription, which can include information indicating an area of interest. The area of interest is a geographic area and it can be indicated in the form of a list of zone ID (s) . It implies that the access manger 305 is interested in (i.e. wants to receive information about) computing services available in the area of interest.

Then, the service data repository 335 can respond to the access manager’s subscription request, by sending 1010 a subscription response to the device 350, to acknowledge the reception of the subscription request. This step is optional.

Then, the service data repository 335 can send 1015 the computing service information, to the access manager 305, according to the subscription request 1005, by sending a notification to the access manager 305. The notification includes the computing service information, which can include information about one or multiple registered computing services. The one or multiple computing services are selected by the service data repository 335 according to the subscription request 1005. If the subscription request indicates an area of interest, the one or multiple computing services include computing services that are available within the area of interest, as indicated by the service availability information in the service profiles of the computing services.

In some embodiments, the one or multiple computing services are further limited to deployed computing services. For each of the one or multiple computing services, the computing service information and meta information can include:

- information identifying the computing service, e.g. a service ID/name;

- service meta-information indicating the entity that provides the computing service, e.g. name or ID, and that can further describe or indicate the work (s) associated with the computing service and the functionality/purpose of each work;

- meta-information about each work identified in the service meta information;

- service availability information indicating when (e.g. time period (s) /duration (s) , in the form of time of the day/week/month) and/or where (e.g. location (s) /area (s) , in the form of location or area ID (s) ) the computing service is available.

The sending 1015 of computing service information can be used as a response to the subscription request 1005, in which case sending 1010 a subscription response is optional.

When a computing service information changes, computing service information can be sent 1015. The computing service information can change due to a new registration, a registration update, or deregistration of a computing service. Fig. 4 illustrates a service registration (update) procedure, and Fig. 9 illustrates a service deregistration procedure for a computing service.

When sending 1015 computing service information again, the service manager can also notify the change or different information (i.e. differences in the information compared to previous notification) to the access manager 305, which can indicate that a computing service (or more) become unavailable.

For a device 350 served by the access manager305, the access manager identifies information related to the device from the computing service information sent 1015 by the service data repository. The information related to the device can include information about computing service that are available at the device’s location, among the computing service information. In some embodiments, the information related to the device includes a sub set of information in the computing service information. In some embodiments, it includes the entire set of information in the computing service information. The information related to the device can then be sent to the device, thereby announcing 1020 the service.

In some embodiments, announcing 1020 the service can be performed by sending a registration accept message to the device during a device registration (update) procedure.

An embodiment can include a service discovery procedure, wherein an application controller requests to discover reusable computing service and the platform provides related information to the application controller.

Fig. 11 illustrates a service discovery procedure, according to an embodiment. Initially, the application controller 365 can request 1105 a service discovery, by sending a service discovery request to the service manager 310. The service discovery request includes information indicating whether to receive subsequent updates about the discovery result. The request can further indicate whether to discover all computing services or only reusable computing services. A reusable computing service includes at least one reusable work (i.e. a work that can be used) .

Then, the service 310 manager can subscribe to receive computing service information from the service data repository 335, or update an existing subscription, according to the service discovery request, by sending 1110 a subscription (update) request to the service data repository 335. The request can include information indicating whether the subscription is a one-time subscription or a continuous subscription (i.e. not one-time) . The request can further indicate a subscription requirement, i.e. whether the subscription is for information about reusable computing services, or about any computing services.

The service manager can indicate in the subscription (update) request that the subscription is a one-time subscription if the service discovery request indicates not to receive subsequent updates (about the discovery result) , and a continuous subscription otherwise. The service manager can indicate in the subscription (update) request that the subscription is for information about reusable computing services if the service discovery request indicates to discover reusable computing services, and for information about any other computing services otherwise. If this step is to update an existing subscription, the service manager can make sure the update does not reduce the existing subscription (e.g. from continuous subscription to one-time subscription, or from subscription to any computing services to subscription to reusable computing services) .

Then, the service data repository 335 can respond to the service manager, by sending 1115 a subscription response to the service manager 310, to acknowledge recipient of the subscription (update) request. This step is optional. The response can include the subscribed information, which can include information about each computing service that meets the subscription requirement, including:

- information identifying the computing service, e.g. a service ID/name;

- service meta data indicating the entity that provides the computing service, e.g. name or ID, that can further describe or indicate the work (s) associated with the computing service and the functionality or purpose of each work, and that can further include for each work, reusability information (if any) about the work;

- service availability information indicating when (e.g. time periods or durations, in the form of time of the day, week, and/or month) , and/or where (e.g. locations or /areas, in the form of location or area IDs) the computing service is available.

Then, the service data repository 335 can notify 1120 the service manager 310 about the subscribed information. In some embodiments, this step can be used as a response to the subscription request, and is therefore optional.

The subscription request 1110, the subscription response 1115, and the notification about subscribed information 1120 constitute a subscription-notify procedure that is independent from the other steps in Fig. 11. This procedure may be triggered by the service discovery request 1105, or by a different service discovery request.

Then, the service manager 310 can respond to the application controller 365, by sending 1125 a service discovery response. The service discovery response includes discovery result, which can include the information received from the service data repository in previous steps.

Then, the service data repository 335 can notify the service manager about updates in the subscribed information by sending 1130 a notification to the service manager 310, if the subscription is a continuous subscription. The update in the subscribed information can be due to registration or deregistration updates of a computing service. The notification can include the updated information or changes to the information. This step is optional.

Then, the service manager 310 can send 1135 a service announcement message to the application controller 365. The service announcement message includes the information received from the service data repository, as an update about the discovery result.

In an embodiment, a device can be deregistered from a platform, or have its registration status updated.

Initially, a device 350 can request to register on the platform by sending 1205 a registration request message to the access manager 305. The registration request can be sent from the device to the access manager via an access node (e.g. a wireless access node such as cellular base station, satellite, and drone) that is serving the device.

The registration request message includes information identifying the device, e.g. a device ID. The registration request message further includes information indicating the device’s location, which may be in the format of an access node ID (identifying the access node serving the device) . The information indicating the device location can be included in the message by the device, or by the access node when the access node forwards the message to the access manager.

Then, the access manager 305 can authenticate and authorize 1210 the device 350, considering the state of the device as registered. If the device is already in the registered state (e.g., if the access manager already has a device context for the device in its local storage) , this step is optional.

The access manager 305 can provide the information identifying the device 350 to the user data repository 335, which then sends the corresponding user subscription data to the access manager. The access manager uses the user subscription data to authenticate and authorize the device. The access manager afterward maintains a device context for the device in its local storage. The device context includes the user subscription data corresponding to the device.

Then, the access manager 350 can store the information indicating the device location in the user data repository 335, by sending 1215 device status information to the user data repository 335 for storage. In this step, the access manager can notify the user data repository to update the device status to “registered” . The user data repository can accordingly update the state information of the device, i.e. change the state information of the device to “registered” .

Then, the access manager 305 can send 1220 a registration acceptance message to the device 350, indicating that the registration request 1205 is accepted. A service announcement message 1135 can be sent along with (or, as part of) a registration accept message, as shown in Fig. 11. Then, the device can request access to a registered computing service. A computing service is registered if a service profile is created and stored in the service data repository for the computing service.

Embodiments include a procedure with which a device can deregister and disconnect from a platform.

Initially, a device 350 can request 1305 deregistration by sending a de-registration request message to the access manager 305, typically via an access node. The de-registration request message can include information identifying the device, e.g. a device ID.

Then, the access manager 305 can remove or delete the device context of the device from its local storage. The access manager informs 1310 the user data repository 335 to change the state of the device from registered to de-registered (or un-registered) . The user data repository can accordingly update the device’s status, by changing the state information of the device from registered to de-registered (or un-registered) .

Then, the user data repository 335 can send 1315 an update response message to the access manager 305.

Then, the access manager can send 1320 a de-registration response message to the device 350, acknowledging the reception of the de-registration request.

Embodiments include a service request procedure wherein a device can request to access a work within a computing service, and the platform can authorize the request and include the device into the execution of the work.

Fig. 14 illustrates a service request procedure, according to embodiments. Fig. 14 also illustrates a device addition procedure wherein a device is added into an execution of a work, according to embodiments.

Initially, a device 350 requests to access (i.e. to join or participating in) a work associated with a computing service, by sending 1405 a service request to the access manager 305. The service request includes information (e.g. a service ID or name) identifying the computing service and information (e.g. a work ID) identifying the work.

Then, the access manager 305 can authorize 1410 the service request. In some embodiments, this step is optional, for example, when the access manager 305 is configured not to perform this step. In this step, the access manager 305 identifies, according to the computing service’s service profile, whether the device 350 is allowed to access the work. The access manager can obtain the service profile from the service data repository. The device is allowed to access the work, for example, if the device is identified in device information in a routine data within the service profile, the routine data being associated with a routine belonging to a task that belongs to the work. If the device is not allowed to access the work, the access manager responds to the device to indicate that the service request is rejected and the procedure stops.

Then, the access manager 305 requests a service by sending 1415 a service request to the service manager 310. The service manager is selected by the access manager according to, for example, local configuration and/or the information identifying the computing service in the service request.

Then, the service manager 310 authorizes 1420 the service request. In some embodiments, this step is optional, for example, when the service manager is configured not to perform this step. In this step, the service manager identifies, according to the computing service’s service profile, whether the device is allowed to access the work. The service manager can obtain the service profile from the service data repository. The device is allowed to access the work, for example, if the device is identified in device information in a routine data within the service profile, the routine data being associated with a routine belonging to a task that belongs to the work. If the device is not allowed to access the work, the service manager responds to the device via the access manager to indicate that the service request is rejected and the procedure stops.

In some embodiments, one of the access manager’s authorization 1410 and the service manager’s authorization 1420 is sufficient.

In some embodiments, the service manager 310 can add the device into an execution of the work through a device addition procedure. In this case, if the work is not being executed, the service manager can trigger to execute the work. If the work is being executed, this step is optional.

In some embodiments, a work manager 315 is selected by the service manager 310 to execute the work according to a work order. The work order can be received from the application controller 365 or generated by the service manager 310, for example, as described below.

There are at least two options for the service manager 310 to trigger to execute the work.

A first option for the service manager 310 to trigger to execute the work is for the service manager 310 to send 1425 a notification to the application controller 365 for the work to be executed. The notification includes the information identifying the computing service and the information identifying the work. Upon the notification, the application controller 365 can send 1430 a work order for the work to be executed. The application controller’s request (referred to as work order) is sent to the work manager 315 via the service manager 310. The work manager is selected by the service manager. The work manager acknowledges the work order to the application controller via the service manager. The application controller then sends an acknowledgement to the service manager, indicating the reception of the notification. This acknowledgement implies to the application controller that the work is being executed.

A second option for the service manager to trigger to execute the work is for the service manager to request to execute the work on behalf of the application controller. The service manager 310 selects the work manager and sends 1435 a work order (a request to execute the work) to the work manager 315. The work manager can acknowledge the work order to the service manager.

Whether the work order originates from the application controller 365 or from the service manager 310, the work order includes the information identifying computing service and the information identifying the work. The work order can further include information identifying the order (i.e. the work order) , which can be generated by the service manager 310. The work manager, according to the work order, obtains work data from the service data repository 335, the work data being associated with the work and being part of the service profile of the computing service.

In some embodiments, the work order indicates one or multiple triggering conditions. The one or multiple triggering conditions are evaluated by the work manger. When one of the one or multiple triggering conditions is met, the work manager executes the work. For example, a triggering condition can be when the number of devices requesting to access the work is equal or greater than a threshold value k, the value k being a positive value. The value k may be 1, implying the work execution is started as soon as there is a service function instance (which is an instance of a service function associated with the work, and can be a device as in this procedure) requesting or attempting to access the work. The value k can be larger than 1, for example, being related to k-anonymity provisioning. In some embodiments, the work manager executes the work upon receiving the work order (i.e. the work manager is triggered to execute the work by the work order) .

When executing the work, the work manager identifies the task (s) included in the work from the work data, and for each of these task (s) , the work manager selects a task manager to manage the task and triggers the task manager to execute the task. When the work includes multiple tasks, the work manager triggers to execute the tasks in accordance with inter-task dependency information as indicated in the work data. The work manager triggers to execute inter-dependent tasks in sequence. That is, the work manager triggers to execute a first task that depends on a second task (as indicated by the inter-task dependency information) after the second task is executed (i.e., after the second task has been executed) . In some embodiments, the work manager triggers to execute tasks that have no inter-dependency (as indicated in the inter-task dependency information) in parallel (i.e. at the same time) .

Then, the service manager 310 notifies 1440 the work manager 315 that the device 350 is accessing (or requesting to access) the work, by sending a notification to the work manager. The notification includes the information identifying the device, the information identifying the work and the information identifying the computing service. The work manager is selected by the service manager according to the information identifying the computing service and/or the information identifying the work. In some embodiments, when a work order originates from the service manager, this step can be integrated with that work order 1435, wherein the notification is integrated with the work order sent from the service manager to the work manager (e.g. the work order includes the notification) .

According to the work data associated with the work, the work manager can identify routines that are each associated with a service function representing devices. The device is an instance of the service function. For each identified routine, the work manager further identifies a task that the routine belongs to, wherein the task belongs to the work, and the work manager performs the following to make sure the device is taken into consideration when the task is executed during the execution of the work.

If the task is not being executed currently, the work manager 315 can add 1445 the device into consideration when triggering to execute the task at a future time. That is, when triggering the task manager to execute the task, the work manager 315 sends a task request to the task manager. The task request includes the information identifying the computing service and the information identifying the task. The task request indicates that the device joins the task and includes the information identifying the device. The work manager 315 decides to trigger, or when to trigger to execute the task according to a number of factors, as described with the notifications about

work execution

1425 and 1435.

If the task is being executed currently, the work manager 315 adds 1445 the device into consideration for the execution of the task. That is, the work manager 315 identifies or selects the task manager (which manages the task) and sends a task update request to the task manager. The task update request includes the information identifying the computing service and the information identifying the task. The task update request indicates that the device joins the task and includes the information identifying the device. The task update request can further include the information identifying the routine.

In either case, the task manager can do the following according to the request (atask request or a task update request) received from the work manager. The task manager can identify routines each associated with a service function that represents devices. The task manager can identify the routines according to task data associated with the task and related routine data. For each identified routine, the task manager performs one of the following, depending on whether the routine is a native routine or a foreign routine.

In a case where the routine is a native routine, the task manager notifies a routine manager to invite the device into an execution of the routine, wherein the execution of the routine is part of the execution of the task and the routine manager manages the execution of the routine. The task manager notifies the routine manager by sending a notification to the routine manager, the notification including information identifying the device.

In a case where the routine is a foreign routine, the task manager requests a service manager to add the device into an execution of the corresponding foreign work, wherein the execution of foreign work is associated with or related to the execution of the task. The request includes information identifying the device and is sent to the service manager, the service manager 310 being the one that manages the corresponding foreign service. The service manager 310 then identifies a work within the foreign service, the work corresponding to the foreign work identified in the request, and adds the device into an execution of the identified work within the foreign service through a device addition procedure. The execution of the identified work within the foreign service corresponds to the execution of the foreign work associated with the execution of the task. In some embodiments, the foreign work and the identified work are the same work, for example, when the foreign work is reused through remote connection as indicated in the service profile of the foreign service. In some embodiments, they are different works, and in particular, when the identified work is a duplicate or a replica of the foreign work, for example, the foreign work is reused through new deployment as indicated in the service profile of the foreign service and through instantiating a service 435.

Then, the work manager 315 can acknowledge device arrival, by sending 1450 an acknowledgement to the service manager 310, indicating the reception of the device arrival notification.

Then, the service manager 310 can respond to a service request by sending 1455 a response about service request, to the access manager 305, which can relay 1460 the response to device 350, indicating the service request is accepted. When sending 1455 the response to the access manager 305, the service manager 310 can further provide information about the work manager 315 to the access manager 305. The information about the work manager 315 can include information identifying the access manager 305, e.g. an ID and/or a network address (such as an IP address) . According to this information, the access manager 305 knows that the work manager 315 is managing the work (in other words, an execution of the work) .

In some embodiments, after the access manager 305 has authorized 1410 the service request, the work has been executed, and the access manager 305 knows about the work manager 315, the access manager 305 can send a request 1415 directly to the work manager 315. The request sent to the work manager 315 can include or indicate a notification to the work manager 315 that the device 350 is accessing (or requesting access to) the work. In this case, the work manager 315 can add 1445 the device into consideration for the execution of the task, and then send a response directly to the access manager 305, the response can include or indicate the acknowledgement. The above can be viewed as the access message 305 initiating a device addition procedure with the work manager 315 using the request 1415.

In some embodiments, after the service manager 310 has sent 1435 a work order to the work manager, the service manager 310 can send 1455 a response to the access manager 305 about the service request. According to the response 1455, the access manager can perform the device addition procedure with the work manager 315 directly as described above.

In an embodiment, an application controller can request to execute a first work associated with a first computing service, by sending a request to the work manager via the service manager. In some embodiments, the service manager on behalf of the application controller can request to execute the first work, by sending a request from the service manager to the work manager. In either case, the request can be referred to as a work order. The work order includes information identifying the work order, information identifying the first work and information identifying the first computing service.

A work order as such can include information specifying one or multiple triggering conditions. The work manager evaluates the triggering conditions. When at least one of the conditions is met, or in some embodiments when all the conditions are met, the work manger executes the work order, that is, executes the first work identified in the work order. The work manager generates information identifying the execution of the first work and manages the execution of the first work using the information identifying the execution of the first work. The information identifying the execution of the first work can be referred to as differentiator as it differentiates one execution of the work order from another execution of the same work order.

The first work includes a first task. The work manager obtains information identifying the first task from work data associated with the first work. The work data associated with the first work is included in the service profile of the first computing service. In some embodiments, the work manager obtains the service profile from the service data repository. When executing the first work, the work manager requests or triggers a task manager to execute the first task, wherein the work manager provides the information identifying the execution of the first work, the information identifying the first task and the information identifying the first computing service to the task manager. The task manager therefore knows that the work manager manages the execution of the first work and maintains information about the work manger. The task manager executes the first task according to the work manager’s request and manages the execution of the first task. The task manager considers the execution of the first task part of the execution of the first work, and identifies the execution of the first task using the information identifying the first task and the information identifying the execution of the first work together.

The first task includes a routine. The task manager obtains information identifying the routine from task data associated with the first task. If the routine is a foreign routine, i.e. if the routine is associated with a service function (which is a symbolic function) representing a foreign work, and if the foreign work is not being executed according to the task manager’s knowledge, when executing the first task, the task manager requests a service manager to execute the foreign work. If the foreign work is indeed not being executed, according to the request, the service manager triggers to execute the foreign work, by selecting a work manager and sending a work order to the work manager. Otherwise, the service manager must have triggered to execute the foreign work, by selecting a work manager and sending a work order to the work manager. In either case, the service manager sends information identifying the work order to the task manager in response to the request from the task manager, and the task manager accordingly knows that the foreign work is being executed.

If the routine is a native routine, i.e. if the routine is not associated with any service function that represents a foreign work, then when executing the first task, the task manager generates information (e.g. an execution ID) identifying the execution of the routine and requests or triggers a routine manager to execute the routine, wherein the task manager provides the information identifying the routine execution, the information identifying the routine, and the information identifying the computing service, to the routine manager. As the routine execution is part of the execution of the first task, the task manager maintains a mapping between the information identifying the routine execution and the information identifying the execution of the first task (i.e. a combination of the information identifying the first task and the information identifying the execution of the first work) . The routine manager executes the routine according to the task manager’s request and manages the routine execution.

When executing the routine (i.e. during the routine execution) , the routine manager invites some service function instances associated with the routine manager to join the routine execution, wherein the service function instances are instances of service functions associated with the routine. When inviting the service function instances, the routine manager provides the information identifying the routine and the information identifying the routine execution to the service function instances. After the service function instances accept the invitation, the routine manager triggers the service function instances to perform data communications for the routine execution.

During the routine execution, the routine manager may receive a notification from a service function instance via a privacy router. The service function instance is among the service function instances described above, and the privacy router is associated with the service function instance. The notification from the service function instance can indicate that a task-wise context synchronization related to the routine execution is needed. A task-wise context synchronization implies that the execution of the first task needs to be synchronized to a computing context. The notification from the service function instance includes the information identifying the routine execution. The notification can further include information (e.g. a context ID) identifying the computing context (i.e. “context” ) . According to the notification from the service function instance, the routine manager requests to perform the task-wise context synchronization, through a context synchronization procedure illustrated in Fig. 15. The routine manager sends a context synchronization request to the work manager via the task manager, wherein the task manager processes the request (i.e. by performing information mapping) and sends the processed request to the work manager. The work manager then performs the task-wise context synchronization, according to the request received from the task manager. The work manager then responds to the task manager, which in turn responds to the routine manager. Afterwards, the routine manager can reply to the service function instance, indicating that the task-wise context synchronization is complete.

Fig. 15 illustrates a context synchronizing procedure between the routine manager, the task manager and the work manager, according to embodiments.

Initially, the routine manager 340 requests to perform a task-wise context synchronization, by sending 1505 a context synchronization request to the task manager 320. The context synchronization request includes the information identifying the routine execution. The request can further include the information (e.g. context ID) identifying the context.

Then, the task manager processes the context synchronization request received from the routine manager. The task manager maps the information identifying the routine execution to the information identifying the first task and the information identifying the execution of the first work. The task manager 320 requests context synchronization by sending 1510 a context synchronization request to the work manager 315, including the information identifying the first task and the information identifying the execution of the first work. The context synchronization request sent to the work manager can be viewed as a result of the task manager’s processing the context synchronization request received from the routine manager.

Then, according to the information identifying the execution of the first work, the information being in the context synchronization request received from the task manager, the work manager identifies the first work and the first computing service. According to the information identifying the first task (the information being in the context synchronization request received from the task manager) and the work data associated with the first work (the work data being part of the service profile of the first computing service) , the work manager 315 identifies 1515 a second task with which context synchronization is needed. The second task belongs to the first work. This step is optional if the second task does not exist (or cannot be identified) .

Then, the work manager 315 requests 1520 deactivation of first task execution (the execution of the first task being part of the execution of the first work) , initiating a task deactivation procedure.

Then, the work manager 315 requests 1525 deactivation of second task execution (the execution of the second task being part of the execution of the first work) , initiating a task deactivation procedure. This step is optional if a second task does not exist.

Then, the work manager 315 generates 1530 a context ID, by allocating information to identify the context. This step is optional if the context synchronization request 1505 includes the information identifying the context.

Then, the work manager 315 requests 1535 activation of the first task execution (the execution of the first task having been deactivated 1520) , initiating a task activation procedure. The request sent 1535 by the work manager includes the information identifying the context, which is either included in the routine manager’s request 1505 of context synchronization, or generated 1530 by the work manger 315.

Then, the work manager 315 requests 1540 activation of second task execution (the execution of the second task having been deactivated 1525 earlier) , initiating a task deactivation procedure. The request sent by the work manager 315 includes the information identifying the context, which is either included in the routine manager’s request 1505 of context synchronization, or generated 1530 while requesting 1535 activation of first task execution. This step is optional if a second task does not exist.

Then, the work manager 315 responds 1545 to the task manager regarding the context synchronization request 1510, indicating that the task-wise context synchronization is complete. This step is optional.

Then, the task manager 320 responds 1550 to the routine manager 340 for the context synchronization request 1510, indicating that the task-wise context synchronization is complete. This step is optional.

The context synchronization procedure Fig. 15 refers to a task deactivation procedure 1520, 1530, and an

activation procedure

1535, 1540, both of which can include multiple procedural steps as illustrated in Fig. 16.

Fig. 16 illustrates a task activation or deactivation procedure, wherein the work manager requests to activate or deactivate a task execution, according to an embodiment. A task execution refers to an execution of a task, the task belonging to a work that is associated with a computing service. The task execution is part of an execution of the work. In other words, an execution of the work includes the task execution. The task execution includes routine executions, i.e. executions of routines that belong to the task. The work manager’s requests are sent to one or more task managers managing the task execution, which accordingly deactivate or activate executions of their routines.

Initially, the work manager 315 identifies task managers 320 associated with the task, i.e. task managers that manage the task execution. The work manager can request 1605 task activation or deactivation by sending to each task manager a request to deactivate or activate the task execution. A request 1605 includes information identifying the task execution, which includes information identifying the execution of the work and information identifying the task. If the request is to activate the task execution, the request can further include information (i.e. a context ID) identifying a context, to which the task execution should be synchronized. In some embodiments, the request includes information identifying the work and information identifying the computing service.

A request 1605 is referred to as a task deactivation request in a case involving deactivating a task execution, and a task activation request in a case involving activating a task execution.

Then, task managers having received a task activation or deactivation request 1605 from a work manager identify native routines belonging to the task, the task being identified in the task activation or deactivation request. For each identified native routine, a task manager can further identify routine managers managing the routine and performing the following according to the task activation or deactivation request.

The task manager identifies an execution of the routine based on the information identifying the execution of the work (the information being in the task activation or deactivation request) , wherein the execution of the routine (i.e. the routine execution) is part of the task execution (which is identified in the task activation or deactivation request) . The task manager 320 sends 1610 to each routine manager 340 a request to deactivate the routine execution (in the case of a task deactivation request) or to activate the routine execution (in the case of a task activation request) , the request including information identifying the routine execution. In some embodiments, the request includes information identifying the routine and the information identifying the computing service.

When the request sent 1610 to each of the routine manager 340 is to activate the routine execution, the request can include information identifying a context, which is received 1605 earlier.

The request sent 1610 to each of the routine manager 340 is referred to as a routine deactivation in the case of deactivating the routine execution, and a routine activation in the case of activating the routine execution request.

Then, routine managers having received a routine activation or deactivation request 1610 can obtain information identifying the routine from the request, directly (if the request includes the information) , or indirectly (by mapping the information identifying the routine execution in the request to the information) , and perform the following, according to the request.

If the request is a routine deactivation request, the routine manager 340 can deactivate 1615 the native routine execution identified in the request. The routine manager sends a communication deactivation request to service function instances associated to the routine manager, the service function instances being instances of service functions associated with the routine, to suspend or deactivate data communications associated with the routine execution. The communication deactivation request can be sent to the service function instances via privacy routers associated with the service function instances. The communication deactivation request can include the information identifying the native routine execution, the information identifying the native routine, and the information identifying the computing service. The communication deactivation request may further include information identifying a context that the native routine execution is currently synchronized to.

After receiving the communication deactivation request, each privacy router suspends (or stops or pauses) processing or forwarding data traffic associated with the execution of the routine accordingly. In some embodiments, each privacy router further drops the data traffic, according to the communication deactivation request.

Each privacy router can forward the communication deactivation request to service function instances that are associated with the privacy router and with the routine. Upon receiving the communication deactivation request, each of the service function instances suspends (or stops, or pauses) sending data traffic associated with the execution of the routine accordingly.

If the request 1610 is a routine activation request, the routine manager 340 activates 1615 the routine execution identified in the request. The routine manager sends a communication activation request to service function instances associated to the routine manager, the service function instances being instances of service function associated with the routing, to resume or activate data communications associated with the routine execution. The communication activation request is sent to the service function instances via privacy routers that are associated with the service function instances. The communication activation request includes the information identifying the routine execution, the information identifying the routine, and the information identifying the computing service. The communication activation request may further include the information identifying a context, which is received in the routine activation request. The context is one that the routine execution is to be synchronized to.

After receiving the communication activation request, each of the privacy routers activates (or resumes, or restarts, or starts) processing or forwarding data traffic associated with the execution of the routine accordingly.

Each of the privacy routers forwards the communication activation request to service function instances that are associated with the privacy router and with the routine. Upon receiving the communication activation request, each of the service function instances activates (or resumes, or restarts, or starts) sending data traffic associated with the execution of the routine accordingly.

If the communication activation request includes the information identifying a context, when sending the data traffic, each of the service function instances associates the data traffic with the context by including the information in the data traffic (e.g. in a message header) .

Then, routine managers 340 having received a routine activation or deactivation request 1610 from a task manager 320 sends a routine activation or deactivation response 1620 to the task manager 320, indicating that the routine identified in the routine activation or deactivation request has been activated or deactivated 1615 accordingly.

Then, task managers 320 having received a task activation or deactivation request 1605 identify foreign routines belonging to the task and being executed as part of the task execution, the task being identified in the task activation or deactivation request. The task managers 320 activate or deactivate 1625 related foreign routine executions, i.e. executions of the foreign routines as part of the task execution.

To activate or deactivate the foreign routine executions, the task manager identifies foreign functions associated with the foreign routines. For each of the identified foreign functions, the task manager 320 requests to activate or deactivate 1625 a corresponding foreign work execution (an execution of the foreign work, triggered by the task manager during the task execution) , initiating a work activation or deactivation procedure (illustrated in Fig. 17) . The request (shown in Fig. 17 as element 1705) is sent to a service manager selected by the task manager 320, according to information identifying the foreign computing service to which the foreign work belongs. The information identifying the foreign computing service is included in service function data associated with the foreign function representing the foreign work. The request sent to the service manager includes the information identifying a context, which is initially received 1605 from the work manager. In a case where foreign routine executions are activated 1625, the context is one that the foreign work execution is to be synchronized to. In a case where foreign routine executions are deactivated 1625, the context is one that the foreign work execution is currently synchronized to.

The activation or deactivation 1625 of a foreign routine execution is optional if such foreign routines or such foreign functions do not exist. Such activation or deactivation 1625 can be performed in parallel to a task manager 320 requesting 1610 routine activation or deactivation, a routine manager 340 activating or deactivating 1615 native routine execution, or a routine manager 340 responding 1620 to routine activation or activation request.

Then, task managers 320 having received a task activation or deactivation request 1605 can send 1630 a response regarding task activation or deactivation to the work manager 315, indicating that the task identified in the task activation or deactivation request has been activated or deactivated accordingly.

A work execution refers to an execution of a work that is associated with a computing service. The execution of a work is associated with or triggered by a work order, the work order being generated by a network entity, such as an application controller, or a service manager on behalf of an application controller. The work execution includes task executions, i.e. executions of tasks belonging to the work. The network entity’s request is sent via the service manager to the work manager managing the work execution. The work manager accordingly deactivates or activates the comprising task executions of the work execution.

Fig. 17 illustrates a work activation or deactivation procedure, wherein a network entity initiates a work activation or deactivation procedure by requesting to deactivate or activate a work execution, according to an embodiment.

Initially, the network entity 1702, such as a task manager 320, can request to activate or deactivate a work execution, by sending a request 1705 for work activation or deactivation to the service manager 310. The request includes information identifying the work execution. In some embodiments, the request includes information identifying the work order. The request can be referred to as a work activation or deactivation request, i.e. an activation request in the case of activating the work execution, and a deactivation request in the case of deactivating the work execution.

The service manager 310 is selected by the network entity 1702 according to any of the information identifying the computing service and the information identifying the work order.

When the network entity requests to activate the work execution, the network entity can further include information (e.g. a context ID) identifying a context in the request. This indicates that the work execution should be synchronized to the context when being activated. The work execution can accordingly be synchronized.

Then, the service manager 310 selects a work manager 315 according to the work activation or deactivation request and sends 1710 the work activation or deactivation request to a work manager 315 serving or handling the work order.

Then, the work manager 315 activates or deactivates 1715 the work execution according to the request received 1710 from the service manager 310. The work manager identifies task (s) that belong to the work and activates or deactivates executions of the tasks, the executions (i.e. the task executions) being part of or associated with the work execution. To do so, for each of the task executions, the work manager identifies one or more task managers managing the task execution, and requests each task manager to activate or deactivate the task execution, through a task activation or deactivation procedure illustrated in Fig. 16.

When the request 1710 received from the service manager is a work activation request (i.e. to activate the work execution) , the request 1710 can include the information identifying a context. If the request includes the information, the work manager synchronizes the work execution to the context by synchronizing each of the task executions to the context. That is, the work manager 315 provides the information to the task managers managing the task execution when requesting 1605 the task managers to activate the task execution.

Then, the work manager 315 can respond to the routine activation or deactivation request by sending 1720 a work activation or deactivation response to the service manager 310, indicating that the work execution identified in the work activation or deactivation request has been activated or deactivated 1715 accordingly.

Then, the service manager 310 can send 1725 the work activation or deactivation response to the network entity 1702.

Embodiments include service orchestration operative to determine deployment locations of service functions of a first computing service, and to select a computing plane to support the computing service so that the computing service can run in the network.

Embodiments include the provision of service publicity, by providing availability information of a first computing service to devices, so that devices can choose to access the computing service, as well as to other service providers, so that other new services can be deployed by reusing existing services.

Embodiments include service access by allowing a device to access a first computing service.

Embodiments include context synchronization, which refers to synchronizing the execution of a first task within a first computing service, to a computing context. If the execution of a first task can share the computing context with the execution of a second task in the first computing service, or with a second computing service reused by the first computing service, then cross-task or cross-service in the context synchronization can be performed, while ensuring correct performance of the first computing service.

Embodiments include a system architecture including a service manager and a work manager operative to communicate with an orchestrator, which can communicate with a resource manager and provide instructions for the resource manager to instantiate service functions of a computing service. A work manager can also communicate with a service data repository and update a service profile in the service data repository.

Embodiments include a work manager operative to communicate with privacy routers and routine managers, and to provide instructions for the privacy routers and routine mangers such that a compute plane is configured for the computing service.

Embodiments include a work manager operative to communicate with an access manager, which can communicate with a device work manager, receive one or more service requests from the device, receive and authorize a service request, and further trigger the execution a work related to the service request.

Embodiments include a work manager operative to communicate with a work manager that can execute a work, and notify the work manager about a device’s access to a work so that the work manger can include the device into a work execution.

Embodiments include a system architecture that includes a work manager. The work manager having functionalities for synchronizing computing context across tasks and works.

In embodiments, synchronizing computing context across tasks and works can include a work manager communicating with a task manager, which can communicate with a routine manager and provide instructions for the routine manager to synchronize a routine execution to a computing context, and provide instructions for a task manager to synchronize a task execution to a computing context.

In embodiments, synchronizing computing context across tasks and works can include a work manager communicating with a service manager, which can communicates with a different work manager and provide instructions for the different work manager to synchronize a different work execution to a computing context.

In embodiments, a device can be a network element, such as a user equipment (UE) , an internet-of-things (IoT) device, a vehicle, a satellite, a server, etc. as long as it can register with the platform as a device and be recognized by the platform as a device.

Fig. 18 is a block diagram of an electronic device (ED) 1852 illustrated within a computing and communications environment 1850 that may be used for implementing the devices and methods disclosed herein. In some embodiments, the electronic device 1852 may be an element of communications network infrastructure or a user equipment (UE) . The electronic device 1852 typically includes a processor 1854, such as a central processing unit (CPU) , and may further include specialized processors such as a graphics processing unit (GPU) or other such processor, a memory 1856, a network interface 1858 and a bus 1860 to connect the components of ED 1852. ED 1852 may optionally also include components such as a mass storage device 1862, a video adapter 1864, and one or more I/O interface 1868 (shown in dashed lines) .

The memory 1846 can be any type of non-transitory system memory, readable by the processor 1854, such as static random-access memory (SRAM) , dynamic random access memory (DRAM) , synchronous DRAM (SDRAM) , read-only memory (ROM) , or a combination thereof. In specific embodiments, the memory 108 can include more than one type of memory, such as ROM for use at boot-up, and DRAM for program and data storage for use while executing programs.

The mass storage 1862 can be any type of non-transitory storage device configured to store data, programs, and other information and to make the data, programs, and other information accessible via the bus 1860. In some embodiments, mass storage 1862 may be remote to the electronic device 1852 and accessible through use of a network interface such as interface 1858. In the illustrated embodiment, mass storage 1862 is distinct from memory 1846 where it is included, and can generally perform storage tasks compatible with higher latency, but can generally provide lesser or no volatility. In some embodiments, mass storage 1862 can be integrated with a memory 1846 to form an heterogeneous memory.

In some embodiments, electronic device 1852 can be a standalone device, while in other embodiments electronic device 1852 may be resident within a data center. A data center, as will be understood in the art, is a collection of computing resources (typically in the form of servers) that can be used as a collective computing and storage resource. Within a data center, a plurality of servers can be connected together to provide a computing resource pool upon which virtualized entities can be instantiated. Data centers can be interconnected with each other to form networks consisting of pools computing and storage resources connected to each by connectivity resources. The connectivity resources can take the form of physical connections such as Ethernet or optical communications links, and can include wireless communication channels as well. If two different data centers are connected by a plurality of different communication channels, the links can be combined together using any of a number of techniques including the formation of link aggregation groups (LAGs) . It should be understood that any or all of the computing, storage and connectivity resources (along with other resources within the network) can be divided between different sub-networks, in some cases in the form of a resource slice. If the resources across a number of connected data centers or other collection of nodes are sliced, different network slices can be created

It should be appreciated that the network functions such as the privacy routers, task, work and routine managers and the routine clients and servers can all be instantiated within one or more electronic devices. Accordingly, embodiments include one or more electronic devices including a processor and non-transitory machine readable memory, storing machine executable instructions which when executed by the processor, cause the electronic device to implement the methods disclosed herein. Further a system of electronic devices and/or data centers can be used to implement the methods disclosed herein.

Embodiments include a method of implementing a computing service comprising: receiving a service registration request, by a first service manager, from an application controller for a first computing service; requesting authorization, by the first service manager, for a second computing service from a second service manager creating a service profile of the first computing service, by the first service manager, using at least part of the second service for instantiating the first computer service.

In embodiments, creating a service profile of the first computing service using at least part of the second service for instantiating the first computer service can comprise: receiving, by the first service manager, authorization to reuse a work of a second computing service, from the second service manager.

In embodiments, a method by the second service manager can comprise: authorizing reuse of a work of a second computing service, updating a service profile of the second computing service, and responding to the first computing service.

In embodiments, a first service and a second service can be the same service, and a service registration request can be a service registration request to add a new work into the service based on existing works in the service.

Embodiments have been described above in conjunction with aspects of the present invention upon which they can be implemented. Those skilled in the art will appreciate that embodiments may be implemented in conjunction with the aspect with which they are described, but may also be implemented with other embodiments of that aspect. When embodiments are mutually exclusive, or are otherwise incompatible with each other, it will be apparent to those skilled in the art. Some embodiments may be described in relation to one aspect, but may also be applicable to other aspects, as will be apparent to those of skill in the art.

Although the present invention has been described with reference to specific features and embodiments thereof, it is evident that various modifications and combinations can be made thereto without departing from the invention. The specification and drawings are, accordingly, to be regarded simply as an illustration of the invention as defined by the appended claims, and are contemplated to cover any and all modifications, variations, combinations or equivalents that fall within the scope of the present invention.

Claims

A method of implementing a computing service comprising:

receiving a service registration request, by a first service manager, from an application controller for a first computing service;

requesting authorization, by the first service manager, for a second computing service from a second service manager

creating a service profile of the first computing service, by the first service manager, using at least part of the second service for instantiating the first computer service.
The method of claim 1, wherein creating a service profile of the first computing service using at least part of the second service for instantiating the first computer service comprises:

receiving, by the first service manager, authorization to reuse a work of a second computing service, from the second service manager.
The method of any of claims 1-2 further comprising, by the second service manager:

authorizing reuse of a work of a second computing service,

updating a service profile of the second computing service, and

responding to the first computing service.
The method of any of claims 1-3,

wherein the first service and a second service are the same service,

and the service registration request is a service registration request to add a new work into the service based on existing works in the service.
The method of any of claims 1-4, further comprising the second service manager mapping the information identifying

the work of the second computing service, that is authorized to be reused, to a combination of

information identifying the first computing service, and

information identifying the reuse of the work of the second computing service.
The method of claim 5, further comprising the second service manager storing the mapped information in a service profile of the second computing service in a service data repository.
The method of claim 2, wherein creating a service profile of the first computing service, by the first service manager, using at least part of the second service for instantiating the first computer service comprises reusing the work of the second computing service.
The method of claim 7 wherein the request is a request for a new deployment and reusing the work of the second computing service comprises the second service manager authorizing the reuse of the work.
The method of claim 7 wherein the request is a request for a remote connection and reusing the work of the second computing service comprises the second service manager creating a replica of the work for use by the first service.
The method of claim 9, further comprising

mapping, by the first service manager, the reuse of the work of the second computing service to

the reuse of the replica of the work of the second computing service, updating, by the first service manager, a service description information (SDI) of the first computing service, by replacing

information identifying the work of the second computing service with

information identifying the replica of the work of the second computing service.
The method of any of claims 9-10, further comprising an orchestrator making one or more incremental deployment decision for the second computing service.
The method of claim 11 further comprising the orchestrator further makes one or more dynamic deployment decisions for the work of the second computing service.
The method of claim 12, wherein the one or more dynamic deployment decisions comprises

a first dynamic deployment decision is determining

additional deployment locations and

corresponding computing and network resource requirements

of each internal function of the work Y; and

a second dynamic deployment decision is determining

inter-function connections and

inter-function connections based on the additional deployment locations.
A method for a device to request a computing service, comprising:

a network entity

receiving from a device, a request for a computing service;

sending to a work manager a notice to execute a work using information of the device;

receiving from the work manager an acknowledgment of work execution with device;

sending a response to the device.
The method of claim 14, further comprising

the work manager executing the work according to the information of the device,

wherein executing the work comprises

identifying a routine associated with a service function representing the device,

identifying for each routine, a task of the work to which the routine belongs;

wherein

the work manager sends

a task request to a task manager, including information identifying the device,

when triggering the task manager to execute the task.
The method of claim 14, further comprising

the work manager executing the work according to information identifying the device,

wherein executing the work comprises

identifying routines associated with a service function representing the device,

identifying for each routine, a task of the work to which the routine belongs;

wherein

the work manager sends

a task update request to a task manager, including information identifying the device,

while the task manager is executing the task.
The method of any of claims 14-16, further comprising

the network entity

notifying an application controller about the work execution.
The method of any of claims 14-17, wherein the network entity is a service manager.
The method of any of claims 14-18, further comprising

the work manager

receiving from a task manager a request

to perform context synchronization between a first task and a second task,

originating from a routine manager of the first task;

identifying a second task with which context synchronization is needed;

requesting deactivation of first task execution;

requesting deactivation of second task execution;

requesting activation of the first task execution; and

requesting activation of the second task execution;

wherein the request to perform context synchronization includes

information identifying the routine execution.
The method of claim 19, further comprising the work manager generating information identifying the context to which the task executions should be synchronized.
The method of claim 19, wherein

the request to perform context synchronization further includes

information identifying the context to which the task executions should be synchronized.
The method of any of claims 19-21, wherein deactivation comprises

the work manager:

sending to the task manager a request to deactivate a task,

the task manager operative to send a request to the routine manager

to deactivate a native routine execution, and

to deactivate a foreign routine execution; and

receiving from the task manager a response regarding task deactivation,

after the task manager receives a response regarding routine deactivation.
The method of claim 22, wherein

the request to the routine manager includes

information identifying the context to which the task executions are synchronized
The method of any of claims 22-23, further comprising

the routine manager

deactivating the native routine execution identified in the request to the routine manager by sending to a service function instance associated to the routine manager,

a communication deactivation request to suspend

data communications associated with the native routine execution;

wherein the communication deactivation request

is sent via a privacy router associated with the service function instance.
The method of any of claims 21-24,

wherein the communication deactivation request further includes

information identifying the native routine execution,

information identifying the native routine,

information identifying the computing service, and

information identifying a context in which the native routine execution is synchronized.
The method of any of claims 19-25, wherein activation comprises

the work manager:

sending to the task manager a request to activate a task,

the task manager operative to send a request to the routine manager

to activate a native routine, and

to activate a foreign routine execution; and

receiving from the task manager a response regarding task activation,

after the task manager receives a response regarding routine activation.
The method of any of claims 20-26, wherein the request to the routine manager includes information identifying the context to which the task executions should be synchronized.
The method of claim any of claims 26-27, further comprising

the routine manager

activating the native routine execution identified in the request to the routine manager by sending to a service function instance associated to the routine manager,

a communication activation request to activate

data communications associated with the native routine execution;

wherein the communication activation request

is sent via a privacy router associated with the service function instance.
The method of any of claims 26-28, wherein

the communication activation request further includes

information identifying the native routine execution,

information identifying the native routine,

information identifying the computing service, and

information identifying the context to which the native routine execution is synchronized.
The method of any of claims 22-29, wherein deactivating a foreign function comprises the task manager

identifying a foreign function associated with the foreign routine;

sending to a service manager a request to deactivate a corresponding foreign work, and

initiating a work deactivation procedure;.

wherein the request to deactivate includes

information identifying the foreign computing service to which the foreign work belongs; and

information identifying the context to which the foreign work are synchronized.
The method of any of claims 22-29, wherein activating a foreign function comprises the task manager

identifying a foreign function associated with the foreign routine;

sending to a service manager a request to activate a corresponding foreign work; and

initiating a work activation procedure;

wherein the request to activate includes

information identifying the foreign computing service to which the foreign work belongs; and

information identifying the context to which the foreign work should be synchronized.
An apparatus for implementing a computing service comprising: a processor; and

at least one non-transitory machine readable medium storing machine readable instructions which when executed by the processor, configures the apparatus for

receiving a service registration request, by a first service manager, from an application controller for a first computing service;

requesting authorization, by the first service manager, for a second computing service from a second service manager

creating a service profile of the first computing service, by the first service manager, using at least part of the second service for instantiating the first computer service.
An apparatus for implementing a computing service comprising: a processor; and

at least one non-transitory machine readable medium storing machine readable instructions which when executed by the processor, configures the apparatus for executing the methods described and claimed herein.
A system comprising a plurality of devices in communication with each other for executing the methods described and claimed herein.