CN118401930A - System and method for implementing network-based reusable computing - Google Patents

Abstract

A method and a system are provided for a second computing service to reuse a first service function of a first computing service, the first service function being part of a first task, the first task being part of a first job, the job being part of the first computing service managed by a first service manager. By mapping information identifying the 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 store, the work of the second computing service can be reused according to the order provided herein.

Description

System and method for implementing network-based reusable computing

CROSS-REFERENCE TO RELATED APPLICATIONS

This is the first application filed for the present invention.

Technical Field

The present invention generally relates to the field of network-based computing services, and more particularly to a method of using a first interconnected computing service within a second interconnected computing service.

Background technique

With the development of society, smart terminals such as smart transportation equipment, smart home devices, and robots are gradually entering people's daily lives. Sensors play a very important role in smart terminals. Various sensors installed on smart terminals, such as millimeter-wave radars, lidars, cameras, ultrasonic radars, etc., sense the surrounding environment during the movement of smart terminals, collect data, identify moving objects, and static scenes such as lane lines and signs, and plan paths in combination with navigation and map data. Sensors can detect possible dangers in advance and assist or even autonomously take necessary avoidance measures, effectively increasing the safety and comfort of smart terminals.

Intelligent driving technology includes perception, decision-making, and control. The perception module is the "eye" of the intelligent vehicle. The perception module receives information about the surrounding environment and uses machine learning technology to understand the environment in which it is located. The perception module can estimate the state of other traffic participants based on the output of each sensor and track other traffic participants. The decision module uses the information output by the perception module to predict the behavior of traffic participants and make behavioral decisions for the vehicle. The control module calculates the lateral acceleration and longitudinal acceleration of the vehicle based on the output of the decision module and controls the passage of the vehicle.

The state estimation result of the perception module for each traffic participant is obtained by processing the data collected by each sensor in the vehicle. Considering the cost of the vehicle, cost-effective sensors are usually installed in the vehicle. However, the accuracy of cost-effective sensors in perceiving the surrounding environment may be low.

A high-precision sensor can be installed on the top of the vehicle. The data collected by the high-precision sensor is processed, and the processing results can be used to evaluate the accuracy of the state estimation results determined by the perception module in the vehicle.

The way in which data collected by high-precision sensors is processed affects the accuracy of the processing results, and thus affects the accuracy of the evaluation results of the perception module.

Summary of the invention

Embodiments of the present invention address interoperability issues in a network setting where composite computing modules of an intelligent service may be located at different network locations.

The interoperability problem of the system and method for deploying a first computing service in a network setting and for a device to access the first computing service is solved. The embodiment also includes a system and method for reusing a second computing service in a first computing service.

One problem solved is the service orchestration problem. Embodiments support determining a deployment location for a service function of a first computing service and selecting a computing plane to support the computing service.

Another problem that is addressed is the service disclosure problem. Embodiments support providing availability information of a first computing service to devices and other service providers.

Another problem addressed is a service access problem, wherein a method allows a device to access a first computing service.

Another problem that is solved is the context synchronization problem. This involves synchronizing the execution of a first task within a first computing service to a computing context. The execution of the first task can share a 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. Thus, context synchronization can be performed across tasks and across services.

Technical effects of the embodiment include: a first computing service implemented using routines between service functions can reuse parts of a second computing service, which is also implemented using routines between service functions on a network, and the two computing services are located on the network.

An embodiment includes a method for implementing a computing service, the method comprising: a first service manager receiving a service registration request for a first computing service from an application controller; the first service manager requesting authorization for a second computing service from a second service manager; the first service manager creating a service profile for the first computing service using at least a portion of the second service to instantiate the first computing service. A non-limiting example of a technical advantage supports specific reuse during service registration and triggers authorization for reuse.

In an embodiment, the creating a service profile of the first computing service using at least a portion of the second service to instantiate the first computing service includes: the first service manager receiving authorization from the second service manager to reuse the work of the second computing service. A non-limiting example of a technical advantage supports the first service manager to receive the authorization result so that it can proceed to the next step.

In an embodiment, the method of the second service manager may include: authorizing reuse of the work of the second computing service; updating a service profile of the second computing service; responding to the first computing service.Non-limiting examples of technical advantages support recording reuse and then identifying and supporting reuse at a later time.

In an embodiment, the first service and the second service may be the same service, and the service registration request may be a service registration request to add a new job to the service based on existing jobs in the service. A non-limiting example of a technical advantage supports dynamically adding new jobs to a computing service based on existing jobs in the computing service.

In an embodiment, the method may further include: the second service manager mapping information identifying the work of the second computing service that is authorized for reuse to a combination of: information identifying the first computing service, and information identifying the reuse of the work of the second computing service.

In an embodiment, the method may further include: the second service manager storing the mapped information in a service profile of the second computing service in a service data repository.

In an embodiment, the first service manager creating a service profile of the first computing service using at least a portion of the second service to instantiate the first computing service may include: reusing the work of the second computing service.

In an embodiment, the request may be a request for a new deployment, and said reusing said work of said second computing service may include: said second service manager authorizing said reuse of said work.

In an embodiment, the request may be a request for a remote connection, and said reusing said work of said second computing service may include: the second service manager creating a copy of the work for use by the first service.

In an embodiment, the method may include: the first service manager maps the reuse of the work of the second computing service to the reuse of the copy of the work of the second computing service; the first service manager updates the service description information (SDI) of the first computing service by replacing the information identifying the work of the second computing service with the information identifying the copy of the work of the second computing service.

In an embodiment, the method may further include: the orchestrator making one or more incremental deployment decisions for the second computing service.

In an embodiment, the method may further include: the orchestrator further making one or more dynamic deployment decisions for the work of the second computing service.

In an embodiment, one or more dynamic deployment decisions may include: a first dynamic deployment decision, which determines additional deployment locations and corresponding computing and network resource requirements for each internal function of work Y; a second dynamic deployment decision, which determines inter-function connections and inter-function connections based on the additional deployment locations.

An embodiment includes a method for a device to request a computing service, the method comprising: a network entity receiving a request for a computing service from a device; sending a notification to a work manager to perform work using information of the device; receiving a confirmation of the execution of the work of the device from the work manager; and sending a response to the device.

In an embodiment, the method may further include: the work manager executes the work according to the information of the device, wherein the execution of the work includes: identifying a routine, the routine being associated with a service function representing the device; identifying, for each routine, a task of the work to which the routine belongs; wherein, when the task manager is triggered to execute the task, the work manager sends a task request to the task manager, the task request including information identifying the device.

In an embodiment, the method may further include: a work manager executes the work based on information identifying the device, wherein the execution of the work includes: identifying a routine, the routine being associated with a service function representing the device; identifying, for each routine, a task of the work to which the routine belongs; wherein, when the task manager is executing the task, the work manager sends a task update request to the task manager, the task update request including information identifying the device.

In an embodiment, the method may further include: the network entity notifying the application controller of the work execution.

In an embodiment, the method may further include the network entity acting as a service manager.

In an embodiment, the method may also include: the work manager receives a request from the task manager to perform context synchronization between the first task and the second task, the request originating from the routine manager of the first task; identifying the second task that requires context synchronization; requesting to deactivate the execution of the first task; requesting to deactivate the execution of the second task; requesting to activate the execution of the first task; requesting to activate the execution of the second task; wherein the request to perform context synchronization includes information identifying the routine execution.

In an embodiment, the method may further include: the work manager generating information identifying a context to which the task execution should be synchronized.

In an embodiment, the request to perform context synchronization may also include information identifying the context to which the task execution should be synchronized.

In an embodiment, the deactivation may include, after the task manager receives a response regarding routine deactivation, the work manager: sending a request to the task manager to deactivate the task, the task manager being used to send a request to the routine manager to deactivate local routine execution and to deactivate foreign routine execution; and receiving a response regarding task deactivation from the task manager.

In an embodiment, the request to the routine manager may include information identifying a context to which the task execution is synchronized.

In an embodiment, the method may also include: the routine manager deactivating the local routine execution identified in the request to the routine manager by sending a communication deactivation request to a service function instance associated with the routine manager to suspend data communication associated with the local routine execution; wherein the communication deactivation request is sent via a privacy router associated with the service function instance.

In an embodiment, the communication deactivation request may further include: information identifying the execution of the local routine; information identifying the local routine; information identifying the computing service; information identifying a context in which the execution of the local routine is synchronized.

In an embodiment, the activation may include, after the task manager receives a response regarding the routine activation, the work manager: sending a request to activate the task to the task manager, the task manager being used to send a request to activate a local routine and to activate execution of an external routine to the routine manager; and receiving a response regarding the task activation from the task manager.

In an embodiment, the request to the routine manager may include information identifying a context to which the task execution should be synchronized.

In an embodiment, the method may further include: the routine manager activating the local routine execution identified in the request to the routine manager by sending a communication activation request to the service function instance associated with the routine manager to activate data communication associated with the local routine execution; wherein the communication activation request is sent through the privacy router associated with the service function instance.

In an embodiment, the communication activation request may further include: information identifying the execution of the local routine; information identifying the local routine; information identifying the computing service; information identifying a context to which the execution of the local routine is synchronized.

In an embodiment, deactivating an external function may include: a task manager identifying an external function associated with the external routine; sending a request to the service manager to deactivate the corresponding external work; initiating a work deactivation process; wherein the deactivation request includes: information identifying the external computing service to which the external work belongs, and information identifying the context, and the external work is synchronized to the context.

In an embodiment, activating an external function may include: a task manager identifying an external function associated with the external routine; sending a request to the service manager to activate the corresponding external work; initiating a work activation process; wherein the activation request includes: information identifying the external computing service to which the external work belongs, and information identifying the context to which the external work should be synchronized.

Other embodiments provide a device for implementing a computing service, comprising: a processor; at least one non-transitory machine-readable medium storing machine-readable instructions, which, when executed by the processor, cause the device to perform the following operations: a first service manager receives a service registration request for a first computing service from an application controller; the first service manager requests authorization for a second computing service from a second service manager; the first service manager creates a service profile for the first computing service using at least a portion of the second service to instantiate the first computing service.

Other embodiments provide an apparatus for implementing a computing service, comprising: a processor; and at least one non-transitory machine-readable medium storing machine-readable instructions that, when executed by the processor, cause the apparatus to perform the methods described and claimed herein.

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

The above 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 are merely exemplary.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 a illustrates operations provided by an embodiment that may be used within a first computing service.

FIG. 1b shows the operation of a first computing service that can be used within a second computing service according to an embodiment.

FIG. 2 shows an example of application-driven reuse provided by an embodiment.

FIG. 3 shows a network system with a control plane and a computing plane provided by an embodiment.

FIG. 4 shows a service registration process of a first computing service initiated by an application controller (AC) provided by an embodiment.

FIG5 shows the service instantiation process provided by the embodiment.

FIG. 6 is a call flow chart of the configuration process of the service manager provided in the embodiment.

FIG. 7 shows a process for configuring a routine manager provided by an embodiment.

FIG. 8 shows a process of configuring a privacy router as a routine according to a service function instance provided by an embodiment.

FIG. 9 shows a service deregistration process of a computing service (ie, a first computing service) initiated by an application controller according to an embodiment.

FIG. 10 shows a service advertisement process provided by an embodiment.

FIG. 11 shows a service discovery process provided by an embodiment.

FIG. 12 illustrates a registration process or a registration update process of a device connected to a platform provided by an embodiment.

FIG. 13 illustrates a device deregistration process provided by an embodiment, wherein the device is disconnected from the platform.

FIG. 14 shows a service request process provided by an embodiment.

FIG. 15 shows a context synchronization process between a routine manager, a task manager and a work manager provided in an embodiment

FIG. 16 shows a task activation or deactivation process provided by an embodiment, wherein a work manager requests activation or deactivation of a task execution.

FIG. 17 illustrates a work activation or deactivation process provided by an embodiment.

18 is a block diagram of an electronic device (ED) shown within a computing and communication environment, which ED may be used to implement the devices and methods disclosed herein.

It should be noted that in all the drawings, the same features are identified by the same reference numerals.

Detailed ways

Embodiments include systems and methods for deploying interconnected computing services, such as those accessible by one or more devices. Embodiments also include systems and methods for reusing a second interconnected computing service within a first interconnected computing service. Reuse may be determined at the application layer. Problems addressed by embodiments include:

-Service orchestration: determining the deployment location of the service function of the first computing service and selecting a computing plane to support the first computing service;

- Service disclosure: providing information about the availability of the first computing service to devices and other service providers;

-Service Access: Allows the device to access the first computing service.

-Context synchronization: Synchronize the execution of the first task within the first computing service to the computing context. The execution of the first task can share the computing context with the execution of the second task in the first computing service, and with the second computing service reused by the first computing service. Therefore, context synchronization can be performed across tasks and across services.

The embodiments involve scenarios that can be divided into two categories: application-driven reuse and network-driven reuse.

Application-driven reuse is a reuse scenario where 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 the AI model in the first AI service is extended to solve a new problem of the second AI service. The provider of the second AI service obtains information about the AI model from the provider of the first AI service, for example, offline, 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 jobs, which can be considered to belong to or be associated with the service. The jobs can be exposed to service consumers (i.e., entities that consume or use the service), who can choose to participate (i.e., join or contribute) in the execution of the jobs. The entity that provides the computing service can be called a service provider or intelligence provider.

In a service, the work of a service may include one or more tasks. These tasks may be considered to belong to or be associated with a service. Dependencies may exist between one or more tasks. When a first task depends on a second task, for example because the first task requires the result of the second task as input, the first task must be executed after the second task is executed. This dependency may be indirect, in that the first task may depend on the result of a third task, which itself depends on the second task. When a first task does not depend on a second task, the first task may be executed before the second task or in parallel (in time) with the second task. Dependencies between tasks may be referred to as inter-task dependencies or intra-job dependencies.

In a service, a task of the service may include one or more routines, each of which may correspond to a computational or networking step of the task. Routines may be considered to belong to or be associated with a service. Dependencies may exist between routines. When a first routine depends on a second routine, the first routine should be executed after the second routine because, for example, the first routine requires the computational result of the second routine as input. This dependency may be indirect, because the first routine may depend on the second routine through the 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 may be executed before the second routine or in parallel (in time) with the second routine. Dependencies between routines may be referred to as inter-routine dependencies or intra-task dependencies.

In a service, a routine is associated with a first service function and a second service function. The first service function may be referred to as a "routine server function," which does not represent a device. The second service function may be referred to as a "routine client function," which may represent one or more devices or no device. The two service functions may be considered to belong to or be associated with a service, and each service function may have one or more 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 the nomenclature.

Table 1: Naming of routines

The routine may be associated with information indicating which of the service functions associated with the routine is a routine server function. The routine may also be associated with information indicating which 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 a synchronization requirement that specifies whether each routine client (i.e., an instance of a routine client function) should communicate with the routine server (i.e., an instance of a routine server function) in parallel (i.e., at the same time when different routine clients communicate with the routine server) or in sequence (i.e., one after another, so that no two routine clients communicate with the routine server at the same time). In other words, the synchronization requirement can be for parallel communication or for sequential communication. During execution of the routine, the routine server can be associated with one or more routine clients, and the one or more routine clients can communicate with the routine server according to the synchronization requirement associated with the routine.

In a service that includes a computing module, a service function may implement the computing module. The service function may be in software form, which may be referred to as a virtual function. When a service function is a virtual function, it may be deployed (i.e., instantiated) at one or more network locations, referred to as deployment locations, some or all of which may be on the edge cloud. After the service function is deployed at a network location, there is an instance of the service function at the network location, where the instance may be in the form of a software copy that implements the service function. The service function may represent one or more devices, indicating that the computing module is being used by the device or running on the device. In this case, the device may be considered to be an instance of the service function.

When needed (e.g., upon request or upon the occurrence of certain events), work associated with a computing service may be executed. During execution of the work, tasks of the work may be executed in accordance with inter-task dependencies associated with the work. During execution of the task, routines of the task may be executed in accordance with inter-routine dependencies associated with the task. During execution of the routine, data communication may occur between a routine server and one or more routine clients associated with the routine server in accordance with synchronization requirements associated with the routine.

In a service, work can be reused, for example, through a new deployment or a remote connection. Reusable work is typically associated with an entry function and an exit function, wherein the entry function provides input to the work and the exit function holds the output of the work. The entry function and the exit function are service functions. Therefore, a second computing service can use the reusable work as a symbolic foreign service function (or simply foreign function). Such a second computing service may include at least one routine associated with the symbolic foreign function, and a local service function, which belongs to the second computing service and can serve as an entry function and/or exit function of the reusable work.

Figure 1a shows a job that can be used within a first computing service provided by an embodiment. The job 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 one embodiment, the work of the first computing service can be reused in the local function sequence of the second computing service as a function (ie, a foreign function) in the second computing service (eg, between two local functions).

Figure 1b shows the work of a first computing service that can be used as a function within a second computing service provided by an embodiment. The second computing service includes multiple local functions, which are service functions belonging to the second computing service, including local function 1 (125), local function 2 (130) and local function 3 (135). The work 105 of the first computing service can be reused in the second computing service as an external function between two local functions of the second computing service. Each link between two functions can correspond to a routine. The routine between two local functions can be referred to as a local routine 140, and the routine between a local function and an external function can be referred to as an external routine 145.

An AI application is an example of a computing service, where, for example, the work may be related to training an AI model, implemented as a service function, and the work may include the following tasks: data collection and preparation tasks, model training tasks, and model validation tasks, where the model validation tasks depend on the model training tasks, which in turn depend on the data collection and preparation tasks. For example, another work of an AI application may be AI reasoning.

When the first computing service is running, work X of the first computing service (more specifically, task T within work X) can reuse work Y of the second computing service. In this case, work X can be associated with an external function representing work Y of the second computing service. In some embodiments, the first computing service and the second computing service can be the same computing service. The reuse can be indicated by the service provider of the first computing service, for example, in service description information (SDI), as described elsewhere in the present invention. Therefore, this scenario can be referred to as application-driven reuse.

FIG2 illustrates application-driven reuse provided by an embodiment. In a second computing service, work Y 205 may be associated with one or more core functions (i.e., internal functions), such as core function 1 (210), core function 2 (215), etc. One or more core functions are service functions. Work Y 205 may also be associated with an entry function 220 and an exit function 225, which are also service functions. The entry function 220 may be associated with routine A of work Y, and the exit function 225 may be associated with routine B of work Y.

The core function may be local and belong to the second computing service. In some embodiments, it is not a symbolic function, it will be a service function representing a device or job. One or more core functions may be associated with a routine in job Y, which may include routine A, routine B, or other routines. In some embodiments, entry function 220 and exit function 225 may be the same service function. In some embodiments, routine A and routine B may be the same routine.

In the embodiment represented by FIG. 2 , the foreign function representing work Y may be a symbolic function. Work X 230 may be associated with routine C and routine D, wherein routine C is associated with service function 1 (235) and foreign function 240, and routine D is associated with service function 2 (245) and the same foreign function 240. Service functions 1 and 2 are local functions of the second computing service (i.e., belong to the second computing service). Routine C corresponds to routine A, and routine D corresponds to routine B. This indicates that routine C reuses work Y 205, and service function 1 participates in routine A of work Y 205 as an entry function. It also indicates that routine D reuses work Y, and service function 2 participates in routine B of work Y as an exit 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 may be collectively referred to as task T 250, which is a task that includes these two routines.

In an embodiment, network-based computing can be supported by a network system (i.e., a platform) that is designed based on the concepts of services, jobs, tasks, and routines described herein. The platform can be operated by a third party, who can be referred to as a platform operator relative to service consumers and service providers.

3 shows a network system with a control plane and a computing plane provided by an embodiment. The control plane may 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. The computing plane may include computing plane entities, such as one or more routine managers 340 and one or more privacy routers 345. These control planes and computing plane entities are network entities. In some embodiments, the resource manager 330 is an external entity because it is not necessarily part of the network system. In some embodiments, the routine manager 340 is considered to be a control plane entity and belongs to the control plane.

In an embodiment, some platform entities may be connected to other platform entities, and connections and information from one entity to another may be identified with alphanumeric characters T1, T2, T3, T4, T5a, T5b, T5c, T6a, T6b, T7a, T7b, T7c, T7d, T7e, T8, T9a, and T9b. Links between entities indicate interfaces or connections for mutual interaction or communication. These links may be labeled according to their roles, including:

- Link T1 307 between access manager 305 and device 350;

- Link T2 352 between the privacy router 345 and the device 350;

- Link T3 317 between the service manager 310 and the application controller 365;

- Link T4 347 between the privacy router 345 and the application server 355 in the edge cloud 360;

- Link T5a 342 between the access manager 305 and the routine manager 340;

- Link T5b 312 between the task manager 320 and the routine manager 340;

- Link T5c 322 between the service manager 310 and the routine manager 340;

- Link T6a 332 between resource manager 330 and orchestrator 325;

- Link T6b 333 between the work manager 315 and the resource manager 330;

- Link T6c 334 between resource manager 330 and task manager 320;

- Link T7a 327 between orchestrator 325 and service manager 310;

- Link T7b 328 between the access manager 305 and the service manager 310;

- Link T7c 313 between the service manager 310 and the task manager 320;

- Link T7d 318 between the work manager 315 and the task manager 320;

- Link T7e 314 between the service manager 310 and the work manager 315;

- Link T8 348 between a privacy router 345 and another privacy router 345;

- Link T9a 344 between the privacy router 345 and the service manager 310;

- Link T9b 349 between the privacy router 345 and the routine manager 340.

In a network system according to an embodiment, a network entity may be a logical entity, and any one of the network entities may be combined into the same entity. In some embodiments, a control plane entity is integrated into or implemented by the same network entity, such as a platform controller or a system controller. The platform controller may implement or provide the functions of a control plane. In some embodiments, some of the control plane entities may be integrated into the same network entity or implemented by the same network entity. For example, an orchestrator may be incorporated into a service manager, or a service manager and a work manager may be combined to form a service-work manager, or a work manager and a task manager may be combined into a work-task manager, etc. In some embodiments, a computing plane entity, i.e., a routine manager and a privacy router, may 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 a routine manager may be combined into a work-task-routine manager, or a task manager and a routine manager may be combined into a task-routine manager. When two entities A and B (such as any of the control or computing plane entities described above) are combined into a single entity C, the interface between the two entities A and B becomes the interior or entirety of a single entity C.

The functions of the entities in Figure 3 can be as follows.

In an embodiment, the orchestrator 325 can determine the deployment location of the service function of the application (or computing service), and it can select a computing plane for the application, including the logical topology of the computing plane. The orchestrator can also determine the resources required at the deployment location and on the communication links in the logical topology; and it can interact with the resource manager (which can be located in the infrastructure network) to provide computing and networking resources (i.e., wireless resources, transmission resources, etc.) accordingly.

In an embodiment, the access manager 305 may act as a control plane interface with the device; and perform mobility management of the device. The access manager may also authenticate and/or authorize the device to connect to a platform (eg, the platform or network system shown in FIG. 3 ).

In an embodiment, the service manager 310 can perform registration, registration updates, and deregistration for applications (or computing services). The service manager can also authenticate and authorize devices to use applications (or computing services). The service manager can also act as a control plane interface with external entities (such as application controllers). The service manager can also select a work manager to process a work order.

In an embodiment, the work manager 315 can execute work or work orders. This can include receiving work orders from the service manager and coordinating the execution of tasks of the work based on dependencies between tasks. The work manager can also dispatch task orders, which can include selecting a task manager and sending the task order to the selected task manager. The task order can be received from the service manager or associated with the work execution.

In an embodiment, the task manager 320 can execute tasks or process task orders. This can include receiving a task order from a work manager and coordinating the execution of a routine for task execution based on inter-routine dependencies. The task manager can also trigger routine execution. This can include assigning an identification (ID) to the routine execution, identifying one or more routine managers associated with the routine, and notifying the routine manager to execute the routine. This can also include assigning a distinguisher to the routine execution.

In an embodiment, the service data repository 335 may store user subscription data, as well as a service profile for each registered computing service.

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

In an embodiment, the privacy router 345 may provide signal and data routing. This may include forwarding compute plane control signals and data traffic during execution of a routine. The privacy router may also perform proxy re-encryption on outgoing data traffic prior to forwarding to allow for simultaneous protection of user and device privacy and data confidentiality.

In an embodiment, the resource manager 330 may manage and provide computing and network resources based on resource requirements received from the orchestrator through interface T6a 332. The resource manager may also adapt resource provisioning to network dynamics at a per-task granularity of execution granularity, for example, based on information received from the task manager through interface T6b 333, to meet end-to-end quality-of-service (QoS) requirements.

In one embodiment, an application controller (AC) 365 may belong to or be controlled by a service provider, and it may represent a service provider. The AC may be connected to the service manager via an interface or connection T3 317 to manage computing services, such as registering or unregistering a service, updating a registration of a service, or triggering the execution of a job of a service. The AC may be integrated with an application server (AS) or may be an entity independent of the AS.

In one embodiment, AS 355 may be located at a network location identified by an ID such as a 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 the software implementation) may be hosted (i.e., run) on the AS at the network location.

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

AC 365 may send a work order to the platform, which may trigger execution of the work identified in the work order accordingly by signaling the appropriate service function instances and forwarding subsequent data traffic between the service function instances based on inter-task dependencies and intra-task dependencies within the work. Data generated by the service function instances during execution may be in ciphertext form and forwarded by the platform without decryption. Prior to forwarding the data, the platform may re-encrypt the data so that the intended receiver (i.e., a different service function instance) can recover the original data (plaintext) from the re-encrypted data using the receiver's private key.

In an embodiment, the platform shown in FIG. 3 may support and manage computing services deployed in a network.

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

When the 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 through a corresponding interface or connection (e.g., a T2 interface or connection), and the routing information may include any one of the following information related to the network entity: network address, port number, protocol type, tunnel endpoint ID, tunnel ID, etc.

The above can be applied to but not limited to any one of the T2 routing information, T4 routing information, T8 routing information and T9b routing information according to the embodiment. If necessary, the above can also be extended to any unnamed or unmentioned connection or interface.

A computing service may be considered registered if the service data repository 335 stores a service profile for the computing service. The service profile for the computing service may include service description information (SDI), which includes information describing the computing service. In an embodiment associated with FIG. 4 , the SDI may be provided by the AC 365, for example, via a service registration request 405, and the SDI may also include information identifying the computing service, service meta information, service reusability information, and service availability information.

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

The meta information of the service may indicate which entity provides the computing service and who is the service provider. The meta information may also describe or indicate one or more jobs associated with the computing service, and the function and/or purpose of each job.

The availability information of the service may indicate the time and/or location at which the computing service is available, ie, the time and time interval (in the form of a day, week or month) and/or the location (in the form of an area ID).

The SDI may also include data or information describing one or more service functions, one or more jobs, one or more tasks, one or more routines, deployments (i.e., service function instances or instances of service functions), and computing planes associated with computing services. These data or information may be referred to as service function data (or information), job data (or information), task data (or information), routine data (or information), and computing plane data (or information), respectively.

In an embodiment, the service function data is per service function, and it may include information for each service function associated with (or belonging to) a computing service, such as below.

The service function data may include information identifying the service function, such as a function ID.

The service function may represent a device. In some embodiments, if this information has a specific/reserved format or value, the service function is identified as representing/indicating a device (eg, UE).

The service function may represent the work of the second computing service. When the service function represents the work of the second computing service, this information may include information identifying the work (e.g., work ID) and information identifying the second computing service (e.g., service ID). The second computing service may be referred to as an external service, the work may be referred to as an external work, and the service function may be referred to as an external function. When the second computing service (i.e., the external service) is the current computing service (i.e., the service corresponding to the service profile), the information identifying the second computing service is optional. When the second computing service is the current computing service, the service function (i.e., the external function) should not be used by any routine of the work (i.e., the external work) to prevent reuse cycles.

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

The service function data may include a software (executable file or code or image) implementation of the service function. Alternatively, it may include a reference to the software implementation of the service function (e.g., a URL), or a reference point to the location (e.g., a storage location) of the software implementation of the service function, and it may be used to obtain the software implementation of the service function.

The service function data may include resource requirement information, such as information indicating the amount of computing resources (eg, CPU cycles, memory, storage, I/O access) required by the service function.

The service function data may include an outgoing traffic rate, such as information indicating the amount of outgoing traffic generated or sent by the service function over a certain amount of time. Alternatively, this information may indicate a relationship between the amount of outgoing traffic and the amount of incoming traffic (i.e., traffic received by the service function). For example, the relationship may be that the amount of outgoing traffic is equal to the amount of incoming traffic, 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), plus or minus a constant value.

The service function data may include instantiation requirement information, which may include instantiation restrictions and/or intra-function connectivity (connection) constraints.

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

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

In one embodiment, the job data is per-job, and for each job associated with and belonging to the computing service, the job data may include the following information.

The job data may include information identifying the job, such as a job ID.

The work data may include meta-information about the work. This meta-information may include information describing the purpose or function of the work, information describing the input and output of the work, such as information about the input format and structure of the input and output, and information about how to provide input and receive output.

The job data may include information identifying tasks included in the job, such as a list of task IDs.

The job data may include information about inter-task dependencies between tasks included in the job.

The work data may include information about cross-task synchronization between tasks included in the work. This information may include information about synchronization routines and information about context synchronization.

For information about synchronization routines, in some embodiments, a service function may be associated with a routine group (i.e., multiple routines or a group of routines). Routines in a routine group may belong to different tasks, and when the routine is executed, the service function may provide or send the same data traffic for the routine, and the routine may be executed simultaneously. Such routines may be referred to as synchronization routines, and the service function may be referred to as a joint service function. In some embodiments, there may be multiple such routine groups, which may be referred to as synchronization routine groups and may be identified by routine group IDs. For each synchronization routine group, information about synchronization routines may include information (e.g., routine ID) identifying the routine (i.e., the routine belonging to the synchronization routine group) and information (e.g., task ID) identifying the corresponding task, as well as information (e.g., function ID) identifying the joint service function. Information about synchronization routines may also indicate that routines in a synchronization routine group should be executed simultaneously, and during the execution of the routine, the joint service function may provide or send the same data traffic for these routines.

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

In some embodiments, a symbolic function (eg, a service function representing foreign work) is not a federated service function.

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

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

- information identifying one or more entry routines and one or more corresponding entry functions;

- information identifying one or more exit routines and one or more corresponding exit functions;

- Information describing how the work can be reused;

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

Information identifying an entry routine and a corresponding entry function (e.g., a routine ID and a function ID) may be associated with an entry routine of a task belonging to a job. An entry routine may be associated with an entry function and an internal service function (i.e., a core service function), as shown in FIG2 . An entry function is a service function that provides input data for a job. The input data may be provided to an internal service function (or a core service function). An internal service function (or a core service function) is a service function that may be distinguished from an entry function and an exit function.

Information identifying an exit routine and a corresponding exit function (e.g., a routine ID and a function ID) may be associated with an exit routine of a task belonging to a job. An exit routine may be associated with an exit function and an internal service function (or core service function), as shown in FIG2 . An exit function is a service function that receives output data of a job. The output data may be received from an internal service function (or core service function). An internal service function (or core service function) is a service function that may be distinguished from an exit function and an entry function.

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

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

Embodiments may include task data, which may be per-task and include the following information for each task associated with (belonging to) a computing service:

-Information identifying the task, such as the task ID;

- information identifying one or more routines included in the task, such as a list of one or more routine IDs;

- Information about inter-routine dependencies between routines included in a task, such as ordering information of a list of one or more routine IDs. Inter-routine dependencies may also be referred to as intra-task dependencies.

Embodiments may include routine data, which may be per-routine and include the following information for each routine associated with (belonging to) a computing service:

- Information identifying the routine, such as a routine ID;

- information identifying the service function associated with the routine, such as a function ID;

-Device Information;

-Synchronization requirements.

For information identifying a service function associated with a routine, a routine may be associated with two service functions, one of which may represent or indicate a device. The two service functions may be identified in the service function data. This information may also indicate which service function is a routine server function, and/or which service function is a routine client function. A routing client function may represent or indicate a device.

When one of the two service functions described above is a symbolic function representing foreign work (i.e., work in a second computing service (referred to as the foreign service)), the routine corresponds to an entry routine and/or an exit routine of the foreign work (defined or specified in a service profile of the foreign service), and the routine may be referred to as a foreign routine. Information identifying the service function associated with the routine may further indicate whether the routine corresponds to an entry routine and/or an exit routine of the foreign work, for example by including information identifying the entry routine and/or the exit routine of the foreign work. In one embodiment, if neither of the two service functions represents foreign work, the routine may be referred to as a local routine, i.e., a local routine of the work or service.

If one of the two service functions is an entry function of the work to which the routine belongs (as identified in the work data associated with the work), then the routine is an entry routine for the work. If one of the two service functions is an exit function of the work to which the routine belongs (as identified in the work data), then the routine is an exit routine for the work. A routine can be both an entry routine and an exit routine, for example, one of the two service functions is both an entry function and an exit function for the work to which the routine belongs. If a routine belongs to a task and the task belongs to a work, in other words, if a work includes a task and the task includes a routine, then the routine belongs to the work.

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

-Information identifying the device;

- Information about the potential/likely location (or location area) of the device.

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

The information about potential or possible locations (or location areas) of the device may include a list of area IDs. Each area may identify a geographical area and may be in the form of a cell ID or a radio access network (RAN) node ID.

Routine data may include synchronization requirements, which refers to information about one or more synchronization requirements associated with a routine. This information is described elsewhere in the present invention. This information is optional in routine data.

In one embodiment, if the service profile of the computing service includes deployment data and further described computing plane data, the computing service can be considered deployed. Otherwise, the computing service can be considered undeployed. If the computing service is deployed, the computing service must be registered. The deployment of the computing service can include service function instances of the computing service, and the interconnections between the service function instances.

In one embodiment, the deployment data describes the deployment of the computing service, and the computing plane data describes the computing plane associated with the computing service. The deployment data and the computing plane data may be generated by the platform, for example, during instantiation of the computing service.

In one embodiment, the deployment data appears after the computing service is deployed. The deployment data information may include:

-Service function instance information;

-Inter-functional connectivity (connection) information;

- Intra-functional connectivity (connectivity) information.

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

The service function instance information may also include inter-function connectivity (connection) information and intra-function connectivity (connection) information.

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

Intra-function connectivity information (also known as 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 a device. A service function may be a routine client function of a routine, or a routine server function of a routine. Intra-function connectivity refers to the connectivity between a first instance of a service function and a second instance of the service function, and means that the two instances can communicate with each other during the execution of the routine. When a service function has multiple instances, the intra-function connectivity information indicates the intra-function connectivity between the multiple instances of the service function, i.e., whether there is connectivity between any two of the multiple instances. In one embodiment, such information may be optional.

Compute plane data exists after the compute service is deployed. This information includes:

-Privacy router information;

-Privacy router interconnection information;

- Routine Manager information.

The privacy router information is information identifying one or more privacy routers 345 in the computing plane, and for each identified privacy router, information identifying one or more associated service function instances thereof. The one or more service function instances are identified in the deployment data by the service function instance information.

For any pair of a first privacy router and a second privacy router, the privacy router interconnection information may indicate whether there is a connection or connectivity T8 348 between the first privacy router and the second privacy router (i.e., whether the privacy routers are connected). The first privacy router and the second privacy router are identified in the privacy router information.

The routine manager information (e.g., an ID or a network address) may identify a routine manager in the computing plane, and for each identified routine manager, information identifying the associated one or more routines (e.g., a routine ID) and information identifying one or more service function instances associated with each of the one or more routines (e.g., one or more instance IDs). The one or more service function instances are identified (via the service function instance information) in the deployment data.

The information in the service profile may be provided by AC 365 or generated by the platform. In the following, the management and operation process of the platform is described with respect to the system architecture shown in FIG3 .

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

If the AC does not indicate delayed deployment, a first computing service (i.e., a service function of the first computing service) is deployed or instantiated in the network during service registration. The deployment of the first computing service includes a service function instance of the first computing service, and intra-function and inter-function connections of the service function instance. In addition, a computing plane associated with the deployment of the first computing service is selected for the first computing service. The computing plane may include a privacy router coupled (or associated) with the service function instance. The computing plane also includes a routine manager corresponding to a routine of the first computing service.

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

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

The SDI in the service registration request may indicate reuse and include information identifying the second computing service and information identifying job Y. The SDI may also include information identifying a service provider providing the first computing service.

Requesting authorization 410 to reuse work Y may include sub-steps. The sub-steps may include service manager 1310 requesting authorization 410 from service manager 2 412 to authorize reuse by sending an authorization request to service manager 2. Service manager 1 may use information identifying the second computing service to discover or select service manager 2. The authorization request sent to service manager 2 may include information identifying the first computing service, information identifying the second computing service, information identifying work Y, and information identifying reuse. The information identifying reuse may include information identifying a service function of the first computing service, the service function representing work Y and associated with work X. The information identifying reuse may also include information identifying work X. The information identifying reuse may be used to identify reuse when the first computing service reuses work Y multiple different times. The authorization request may also include information identifying a service provider that provides the first computing service.

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

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

Another sub-step of requesting authorization 410 may be that service manager 2 updates (420) the service profile of the second computing service to record the reuse. Service manager 2 may correspond work Z of the second computing service to the reuse. Thus, in some embodiments, service manager 2 may map information identifying work Z to a combination of information identifying the first computing service and information identifying the reuse. 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 to service data repository 335 and indicating the mapping thereto.

If the service profile of the second computing service indicates that work Y is to be reused through a remote connection, then the reuse may be supported directly by work Y (rather than by a copy of work Y). In this case, work Z is work Y, and the information identifying work Z may include information identifying work Y. The information identifying work Y may be an ID of work Y or an alias or pseudonym of work Y, for example in the form of a work ID.

The service manager 2 may generate information identifying job Z, which may include an alias or pseudonym for job Y, for example in the form of a job ID.

Service manager 2 may map information identifying work Z to information identifying work Y. Service manager 2 may store the mapping in a service profile for the second computing service by sending or indicating the mapping to a service data repository.

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

Service Manager 2 copies work Y (including composite tasks and routines) to a replica work. Service Manager 2 may allocate or generate information identifying the replica, including a work ID identifying the replica work Z, a task ID identifying the replica task, and a routine ID identifying the replica routine. Service Manager 2 may store the information in a service profile of the second computing service by sending the information to the service data repository 335.

Service manager 2 maps the information identifying the replica (e.g., replica work) to the information identifying the corresponding original (e.g., work Y), so that the replica is associated with its original. Service manager 2 stores the mapping in the service profile of the second computing service by sending or indicating the mapping to service data repository 335.

In either case, the service data store may store the information received from the service manager 2 as part of the service profile of the second computing service. The service data store 335 may respond to the service manager 2 confirming that the information was successfully stored.

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

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

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

The service data repository may store the service profile of the first computing service. This includes storing information as part of the service profile, the contents of which are as described above. The service data repository may respond to the service manager 2, indicating that the service profile was successfully created.

The service manager 1 310 may instantiate the first computing service according to the SDI of the first computing service.

The initial service registration request 405 may indicate that 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 may 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 the registration of the first computing service, the service manager 1 310 may request the orchestrator 325 to instantiate the first computing service, or after registering the first computing service and upon receiving a request for service instantiation of the first computing service from the AC 365, request the orchestrator 325 to instantiate the first computing service. The orchestrator 325 may perform service orchestration on the first computing service accordingly. This may include making a service deployment decision and a computing plane selection decision for the first computing service based on the service profile of the first computing service. The orchestrator may jointly make the service deployment decision and the computing plane selection decision.

When making a service deployment decision, orchestrator 325 determines a deployment location, i.e., a network location where the service functions of the first computing service (only those service functions that are not abstract functions) will be deployed. It can be determined that the service function has one or more deployment locations, i.e., the service function will be deployed and/or instantiated at one or more network locations.

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

When making service deployment decisions, for each instance of the first computing service, orchestrator 325 may also determine inter-function connections and intra-function connections of service function instances associated with the instance.

When making a compute plane selection decision, the orchestrator 325 may determine or select a compute plane for the first compute service. The compute plane may include one or more privacy routers 345 and one or more routine managers 340. A privacy router is associated with a service function instance, and a routine manager corresponds to a routine of the compute service. In some embodiments, for routines that need to be synchronized (i.e., routines that belong to the same synchronized routine group), the orchestrator may select the same routine manager as indicated by information about synchronized routines in the service profile of the first compute service.

When making a computing plane selection decision and selecting a computing plane, the orchestrator selects a privacy router and a routine manager from a pool of privacy routers and routine managers. If no privacy routers or routine managers are available for selection, or the available privacy routers or routine managers are insufficient, the orchestrator 325 can trigger the expansion of the pool to deploy additional privacy routers 345 and/or routine managers 340 at the selected network location, and then select a privacy router and/or routine manager from the expanded pool.

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

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

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

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

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

The orchestrator 325 provides the computing plane selection decision for the first computing service to the service manager 1 310, which can implement the decision, ie, configure the computing plane accordingly.

In one embodiment, the first service and the second service may be the same service. This may allow new work to be added to the service based on existing work in the service. Thus, in some embodiments, the service registration request is a service registration request to add a new work to the service based on existing work in the service.

Instantiating service 435 may include multiple steps, which may be described as follows during the instantiation process.

FIG5 illustrates a service instantiation process provided by an embodiment. First, the service manager 1310 requests instantiation of a first computing service by sending (505) a service instantiation request to the orchestrator. The request includes information identifying the first computing service (e.g., a service ID). In some embodiments, the request includes information associated with a service profile of the first computing service. The information associated with the service profile of the first computing service may include a service profile (e.g., an SDI).

Then, orchestrator 325 obtains one or more service profiles associated with the deployment request. If service instantiation request 505 does not include a service profile for the first computing service, orchestrator obtains the service profile for the first computing service from service data store 335 by sending (510) information identifying the first computing service to service data store 335 and by receiving (512) the corresponding service profile from service data store 335.

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

Then, the orchestrator 325 performs service orchestration according to the service profile of the first computing service and (if applicable) the service profile of the second computing service (515). When performing service orchestration (515), as described above, the orchestrator makes service deployment decisions and computing plane selection decisions for the first computing service, and if the first computing service reuses the second computing service, the orchestrator may also make incremental deployment decisions and computing plane reselection decisions for the second computing service.

The orchestrator notifies the resource manager of one or more deployment decisions and requests (520) appropriate resources, wherein the one or more deployment decisions include a service deployment decision for the first computing service and an incremental deployment decision for the second computing service (if applicable). The orchestrator may provide the resource manager with one or more software images of the relevant service functions, or information identifying or locating the software images in this step.

The resource manager 330 implements one or more deployment decisions by instantiating and/or deploying one or more related service functions using one or more corresponding software images, and provides (525) requested resources (computing resources and/or network resources) based on corresponding resource requirements at one or more related deployment locations.

Resource manager 330 receives one or more software images along with the orchestrator's resource request (520), or uses information received along with the orchestrator's resource request (520) (i.e., information identifying/locating the software images) to obtain one or more software images from one or more specific network locations (e.g., a server or its own local storage).

After a service function (e.g., a service function indicated in a service deployment decision) is instantiated or deployed at a deployment location (e.g., a corresponding deployment location indicated in the service deployment decision), an instance of the service function exists 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.

Resource manager 330 may then respond (530) to orchestrator 325 to confirm that one or more deployment decisions have been implemented (i.e., one or more related service functions have been instantiated and/or deployed). For each service function instance, the resource manager providing resources (525) may include information identifying the service function instance (e.g., information identifying the corresponding service function and information identifying the corresponding deployment location) and T4 routing information associated with the service function instance in the response (530) sent to the orchestrator.

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

The orchestrator 325 may then update one or more related service profiles in the service data repository. This may include updating a service profile of a first computing service in the service data repository, wherein the orchestrator generates deployment data based on a service deployment decision for the first computing service and T4 routing information related to the first computing service (received from the resource manager in step 6), and sends (535) the deployment data to the service data repository. The orchestrator may generate computing plane data based on a computing plane selection decision for the first computing service. Updating the service profile of the first computing service in the service data repository may also include the orchestrator sending (535) the deployment data, computing plane data, and information identifying the first computing service to the service data repository. The service data repository stores the deployment data and computing plane data in the service profile of the first computing service.

Updating one or more related service profiles in the service data repository may also include: the orchestrator updates 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 T4 routing information related to the second computing service, the T4 routing information being received from the resource manager in response to the resource request (530). The orchestrator generates computing plane data based on the computing plane reselection decision for the second computing service and the service profile of the second computing service. The orchestrator may then send (535) the deployment data, computing plane data, and information identifying the second computing service to the service data repository. The service data repository stores the deployment data and computing plane data in the service profile of the second computing service, replacing the existing deployment data and computing plane data.

The orchestrator then interacts with service manager 2 412 to implement a computing plane reselection decision for the second computing service. Service manager 2 is a service manager that manages or is managing the second computing service. The orchestrator uses the information identifying the second computing service to select or identify service manager 2. The orchestrator may perform the following sub-steps.

Orchestrator 325 requests 540 service manager 2 412 to configure a compute plane for the second compute service. The request sent to service manager 2 includes information identifying the second compute service.

In some embodiments, the request to configure the computing plane (540) includes deployment data associated with the second computing service and computing plane data associated with the second computing service. These data can be generated by the orchestrator when updating the relevant service profile by sending service profile data 535 to the relevant service profile.

Service manager 2 may configure (545) a computing plane for the second computing service to implement the configuration based on the deployment data and computing plane data received in request 540. In some embodiments, when the orchestrator does not provide the deployment data and computing plane data in the request (540), service manager 2 may obtain the data from the service data repository by sending information identifying the second computing service to the service data repository after receiving the request, and receiving the data from the service data repository.

The service manager 2 may then respond (550) to the orchestrator indicating that the configuration is complete.

Then, the orchestrator 325 may interact with the service manager 1 310 to implement a computing plane selection decision for the first computing service. To this end, the orchestrator may perform the following sub-steps.

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

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

Then, the service manager 1 310 can configure (560) a computing plane for the first computing service based on the deployment data and computing 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 computing plane data with the request (555), the service manager 1 310 can obtain the data from the service data repository 335 by sending information identifying the first computing service to the service data repository after receiving the request, and receiving the data from the service data repository.

Service Manager 1 310 may then respond (565) to the orchestrator indicating that the configuration is complete.

In some embodiments, the service manager 1 responding (565) to the orchestrator may run in parallel with the orchestrator requesting (540) to configure the compute plane, or it may begin before the request 540 is completed.

The orchestrator may then respond (570) to service manager 1 for its initial service instantiation request (505).

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

In an embodiment associated with FIG. 5 , a routine called routine P may be associated with a task called task T, which in turn may be associated with a job called job X, all three of which may be associated with the first computing service in FIG. 5 . They may also be referred to as being intrinsic to the computing service. The computing service may include one or more other routines. Routine P may 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 may be referred to as the routine client FI1), and an instance FI2 of the service function F2 of the routine P (a routine server). The service profile of the computing service may be updated (535) to include deployment data describing the deployment.

A compute plane may be selected for a compute service during service orchestration (515) and associated with a deployment of the compute service. The compute plane may include one or more routine managers 340. Among the one or more routine managers, a routine manager is assigned to manage routines P associated with two service function instances FI1 and FI2. The compute plane also includes a first privacy router R1 and a second privacy router R2 associated with the function instances FI1 and FI2, respectively. The privacy routers R1 and R2 may be the same entity, for example, if the two service function instances FI1 and FI2 are associated with the same privacy router. The service profile of the compute service may be updated to include compute plane data describing the compute plane.

Whether it is service manager 1 (560) or service manager 2 (545), the service manager serving the computing service configures the computing plane according to the deployment data and the computing plane data. The service manager can obtain or receive the deployment data and the computing plane data from a network entity (e.g., from a service data repository or from an orchestrator). When configuring the computing plane, the service manager performs a configuration process of routine P according to the service function instances FI1 and FI2. The configuration process is shown in FIG6.

In embodiments where privacy router R1 and privacy router R2 are the same entity, the entity may be configured in one step, and further configuration may be optional. The configuration process in FIG6 assumes that routine client function F1 does not represent a device. When routine client function F1 represents a device, the process is reduced to fewer steps.

6 shows the process of the service manager configuring the routine manager provided by the embodiment. First, 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 identifying the computing service (e.g., service ID), information identifying the routine P (e.g., routine ID), information identifying the service function instance FI1 (e.g., instance ID), information identifying the service function instance FI2 (e.g., instance ID), information identifying the privacy router R1 345 (e.g., ID or network address), and information identifying the privacy router R2 346 (e.g., ID or network address).

In this step, the routine manager 340 may also send or provide (607) T9b routing information related to the routine manager to the service manager 310. The service manager 310 may then provide the T9b routing information to the privacy router R1 and the privacy router R2 in a subsequent step so that the privacy routers R1 and R2 can use the information to reach (route data or control signals to) the routine manager of the routine.

The service manager 310 may then 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 received during the configuration (605) of the routine manager to the privacy router R2: information identifying the computing service, information identifying the routine P, T4 routing information related to the service function instance FI2, and T9b routing information related to the routine manager. The service manager 310 may obtain the T4 routing information related to the service function instance FI2 from the orchestrator in a previous step or a previous process, such as during a request (540) to configure the computing plane to the service manager 2, or during a request (555) to configure the computing plane to the service manager 1.

When configuring (610), the privacy router R2 may also provide (612) T8 routing information and T9b routing information to the service manager 310. This routing information may be associated with the privacy router R2. In this step, the privacy router R2 may also provide (612) T4 routing information associated with the privacy router R2 to the service manager. The service manager may then send the T4 routing information associated with the privacy router R2 to the AC, and the AC may also send the T4 routing information to the service function instance FI2. Alternatively, the privacy router R2 may use the T4 routing information associated with the service function instance FI2 to directly (without involving the service manager) send the T4 routing information associated with the privacy router R2 to the service function instance FI2. The T4 routing information associated with the privacy router R2 describes or specifies how to reach (e.g., route data or control signals to) the routine's privacy router R2 via the T4 connection/interface.

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

During the configuration (615) of the privacy router R1, the privacy router R1 345 may also provide (617) T8 routing information and T9b routing information to the service manager 310. This routing information is associated with the privacy router R1. In this step, the privacy router R1 may also provide the service manager with T4 routing information associated with the privacy router R1. The service manager may then send the T4 routing information associated with the privacy router R1 to the AC, which may also send the T4 routing information to the service function instance FI1. Alternatively, the privacy router R1 may use the T4 routing information associated with the service function instance FI1 to directly (without involving the service manager) send the T4 routing information associated with the privacy router R1 to the service function instance FI1. The T4 routing information associated with the privacy router R1 describes or specifies how to reach (e.g., route data or control signals to) the routine's privacy router R1 via a T4 connection or interface.

The service manager can then configure (620) the instance manager. In this step, the service manager provides the instance manager 340 with the T9b routing information associated with privacy router R2 (received during configuration (610) of privacy router 2) and the T9b routing information associated with privacy router R1 (received during configuration (615) of privacy router 1).

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

During instantiation of a computing service, a computing plane is selected for the computing service. The computing plane includes a routine manager assigned to manage execution of routines 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). An embodiment includes a process for configuring the routine manager, wherein the routine manager is provided with information about the routine and/or information about a data sub-plane, the data sub-plane being a portion of the computing plane for supporting (e.g., processing and transmitting data traffic related to the execution of the routine) the execution of the routine.

FIG7 illustrates a process for configuring a routine manager provided by an embodiment. First, 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 one of the following information: information identifying a computing service (e.g., a service ID), information identifying a routine (e.g., a routine ID), information identifying a routine server function (e.g., a function ID), and information identifying a routine client function (e.g., a function ID). The information about the data sub-plane may also include information about adding one or more service function instances, information about removing one or more service function instances, and information about one or more privacy routers.

The information about adding service function instances may indicate that one or more instances of the routine server function are associated with the routine manager of the routine, for example, by including information identifying the one or more instances of the routine server function (e.g., one or more instance IDs). The information about adding one or more service function instances may indicate that one or more instances of the routine client function are associated with the routine manager of the routine, for example, by including information identifying the one or more instances of the routine server function (e.g., one or more instance IDs).

The information about removing service function instances may indicate that one or more instances of the routine server function are no longer associated with the routine manager of the routine, for example, by including information identifying the one or more instances of the routine server function (e.g., one or more instance IDs). The information about removing one or more service function instances may indicate that one or more instances of the routine client function are no longer associated with the routine manager of the routine, for example, by including information identifying the one or more instances of the routine server function (e.g., one or more instance IDs).

For a service function instance associated with the routine manager (e.g., each service function instance identified in the information about adding the service function instance), the information about the privacy router may include information (e.g., ID, network address) identifying the privacy router associated with the service function instance. For the identified privacy router, the information about the privacy router may also include T9b routing information. The T9b routing information describes or specifies how to reach (e.g., route data to) the identified privacy router through the connection or interface T9b of the routine.

The routine manager 340 may then send (710) a configuration response to the service manager 310 to acknowledge receipt of the configuration request. In the configuration response, the routine manager may include T9b routing information associated with the routine manager. The T9b routing information describes or specifies how to reach (e.g., route data to) the routine manager via the routine's connection or interface T9b.

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

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

8 illustrates a process for configuring a privacy router for a routine based on a service function instance provided by an embodiment. First, the service manager 310 sends (805) a configuration request to the privacy router 345. The configuration request may include any of the following: information identifying a computing service (e.g., a service ID), information identifying a routine (e.g., a routine ID). The configuration request may include T4 routing information. The T4 routing information is associated with the service function instance. The privacy router may use the T4 routing information to route data (e.g., received from interface or connection T8) to the service function instance via connection or interface T4.

The privacy router 345 may then send (810) a configuration response to the service manager 310 to acknowledge receipt of the configuration request. In the configuration response, the privacy router may include any of T4 routing information, T8 routing information, and T9b routing information. This routing information is associated with the privacy router; it describes or specifies how to reach (e.g., route data services or control signals to) the privacy router 345 through the routine's connections or interfaces T4, T8, T9b. In some embodiments, the routing information may be used to reach the privacy routers of other routines. In this step, the privacy router R1 may use the T4 routing information associated with the service function instance to send the T4 routing information associated with the privacy router to the service function instance. The T4 routing information associated with the service function instance is included in the configuration request received from the service manager. The service function instance may then use the T4 routing information associated with the privacy router to reach the privacy router of the routine.

FIG9 shows a service deregistration process of a computing service (i.e., a first computing service) initiated by an application controller provided by an embodiment. After completing this process, the service profile of the computing service will be removed or deleted from the service data repository. If the computing service has been deployed, the computing plane associated with the computing service is released, and the resources (computing resources, transmission resources) related to the computing service are released. If the computing service reuses a second computing service, the deployment of the second computing service and the computing plane associated with the second computing service can be changed due to the deregistration of the computing service.

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

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

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

In response to the request to release the resource (915), the orchestration interacts with the resource manager to release the resource. As a result, the instance of the service function (non-abstract function) associated with the first computing service is deleted or removed. If the first computing service reuses the second computing service, the orchestration can change the deployment and computing plane of the second computing service, for example, removing unnecessary service function instances and/or computing plane entities, and adjusting resource allocation decisions 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 the selected service manager (which can be the service manager 310 in Figure 9) to update the computing plane of the second computing service accordingly.

The service manager 310 then requests and/or notifies the service data repository 335 to delete ( 920 ) the service profile of the first computing service.

The service manager 310 then replies to the application controller 365 by sending (925) a deregistration response to indicate that the first computing service has been deregistered.

In one embodiment, a device may receive an advertisement regarding a computing service.

Figure 10 shows a service announcement process provided by an embodiment. To allow service announcement, the access manager may subscribe to receive information about registered computing services from the service data repository and provide partial information related to the device, which is a registered device.

First, the access manager 305 may subscribe (1005) to receive computing service information (i.e., 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 may include information indicating an area of interest. The area of interest is a geographic area, which may be indicated in the form of a list of one or more area IDs. This means that the access manager 305 is interested in computing services available in the area of interest (i.e., wishes to receive information about computing services available in the area of interest).

The service data store 335 may then respond to the access manager's subscription request by sending (1010) a subscription response to the device 350 to acknowledge receipt of the subscription request. This step is optional.

The service data repository 335 may then send 1015 computing service information to the access manager 305 in accordance with the subscription request 1005 by sending a notification to the access manager 305. The notification includes the computing service information, which may include information about one or more registered computing services. The one or more computing services are selected by the service data repository 335 in accordance with the subscription request 1005. If the subscription request indicates an area of interest, the one or more computing services include computing services available within the area of interest, as indicated by service availability information in a service profile of the computing service.

In some embodiments, the one or more computing services are also limited to deployed computing services. For each computing service in the one or more computing services, the computing service information and meta information may include:

Information identifying the computing service, such as the service ID/name;

Service meta information indicating an entity providing a computing service, such as a name or ID, the service meta information may further describe or indicate one or more jobs associated with the computing service and the function/purpose of each job;

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

Service availability information, indicating the time (e.g., one or more time periods/one or more durations, in the form of days/weeks/months) and/or locations (e.g., one or more locations/one or more regions, in the form of location or region IDs) when the computing service is available.

Sending (1015) the computing service information may be used as a response to the subscription request (1005), in which case sending (1010) the subscription response is optional.

When the computing service information changes, the computing service information may be sent (1015). The computing service information may change due to a new registration, registration update or deregistration of a computing service. FIG4 shows a service registration (update) process, and FIG9 shows a service deregistration process of a computing service.

When resending (1015) the computing service information, the service manager may also notify the access manager 305 of changed or different information (ie, the difference in information compared to the previous announcement), which may indicate that the computing service (or more) has become unavailable.

For a device 350 served by the access manager 305, the access manager identifies device-related information from the computing service information sent by the service data repository 1015. The device-related information may include information in the computing service information about computing services available at the location of the device. In some embodiments, the device-related information includes a subset of the information in the computing service information. In some embodiments, the information includes the entire set of information in the computing service information. The device-related information may then be sent to the device, thereby advertising (1020) the service.

In some embodiments, the service may be advertised (1020) by sending a registration accept message to the device during the device registration (update) process.

Embodiments may include a service discovery process in which an application controller requests discovery of reusable computing services and the platform provides relevant information to the application controller.

FIG11 illustrates a service discovery process provided by an embodiment. First, the application controller 365 may request (1105) 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 results. The request may also indicate whether to discover all computing services or only reusable computing services. A reusable computing service includes at least one reusable work (i.e., work that can be used).

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

If the service discovery request indicates that subsequent updates (regarding the discovery results) are not to be received, the service manager may indicate in the subscription (update) request that the subscription is a one-time subscription, otherwise it is a continuous subscription. If the service discovery request indicates that a reusable computing service is discovered, the service manager may indicate in the subscription (update) request that the subscription is for information about the reusable computing service, otherwise the subscription is for information about any other computing service. If this step is to update an existing subscription, the service manager may ensure that the update does not reduce the existing subscription (e.g., from a continuous subscription to a one-time subscription, or from subscribing to any computing service to subscribing to a reusable computing service).

The service data repository 335 may then respond to the service manager by sending (1115) a subscription response to the service manager 310 to confirm receipt of the subscription (update) request. This step is optional. The response may include subscription information, which may include information about each computing service that meets the subscription requirements, including:

- Information identifying the computing service, such as service ID/name;

- Service metadata (e.g., name or ID) indicating the entity providing the computing service, which may further describe or indicate one or more jobs associated with the computing service and the function or purpose of each job, and may further include, for each job, information about the reusability of the job (if any);

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

Then, the service data repository 335 may notify (1120) the subscribed information to the service manager 310. In some embodiments, this step may be a response to the subscription request and is therefore an optional step.

The subscription request (1110), subscription response (1115) and notification of information about the subscription (1120) constitute a subscription notification process independent of other steps in Figure 11. This process can be triggered by the service discovery request (1105), or by a different service discovery request.

The service manager 310 may then respond to the application controller 365 by sending 1125 a service discovery response. The service discovery response includes discovery results, which may include the information received from the service data store in the previous steps.

Then, if the subscription is a continuous subscription, the service data repository 335 may notify the service manager of the update in the subscribed information by sending (1130) a notification to the service manager 310. The update in the subscribed information may be caused by a registration or deregistration update of the computing service. The notification may include the updated information or a change in the information. This step is optional.

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

In one embodiment, a device may deregister from the platform, or update its registration status.

FIG. 12 illustrates a registration process or a registration update process of a device connected to a platform provided by an embodiment.

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

The registration request message includes information identifying the device, such as a device ID. The registration request message also includes information indicating the location of the device, which may be in the format of an access node ID (identifying an access node serving the device). The information indicating the location of the device may 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, considering the state of device 350 is registered, access manager 305 may authenticate and authorize 1210 device 350. This step is optional if the device is already in a registered state (e.g., if the access manager already has a device context for the device in its local storage).

The access manager 305 can provide 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. Afterwards, the access manager maintains the device context of the device in its local storage. The device context includes the user subscription data corresponding to the device.

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

The access manager 305 may then send (1220) a registration acceptance message to the device 350 indicating that the registration request (1205) is accepted. A service announcement message (1135) may be sent with (or as part of) the registration acceptance message, as shown in FIG. 11. The device may then request access to the registered computing service. If a service profile has been created for the computing service and stored in the service data repository, the computing service is registered.

Embodiments include processes by which a device may log off and disconnect from a platform.

FIG. 13 illustrates a device deregistration process provided by an embodiment, wherein the device is disconnected from the platform.

First, device 350 may request 1305 to deregister by sending a deregistration request message, typically via an access node, to access manager 305. The deregistration request message may include information identifying the device, such as a device ID.

The access manager 305 may then remove or delete the device context for the device from its local storage. The access manager notifies (1310) the user data repository 335 that the device's status has changed from registered to unregistered (or unregistered). The user data repository may update the device's status accordingly by changing the device's status information from registered to unregistered (or unregistered).

The user data repository 335 may then send ( 1315 ) an update response message to the access manager 305 .

The access manager may then send (1320) a logout response message to device 350 to acknowledge receipt of the logout request.

Embodiments include a service request process in which a device may request access to work within a computing service, and the platform may authorize the request and include the device in the execution of the work.

Figure 14 shows a service request process provided by an embodiment. Figure 14 also shows a device adding process provided by an embodiment, wherein a device is added to the execution of a job.

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

The access manager 305 may then authorize (1410) the service request. In some embodiments, this step is an optional step, such as when the access manager 305 is configured not to perform this step. In this step, the access manager 305 identifies whether the device 350 is allowed to access the work based on the service profile of the computing service. The access manager may obtain the service profile from the service data repository. For example, if the device is identified in the device information in the routine data within the service profile, the device is allowed to access the work, and the routine data is associated with a routine belonging to a task, and the task 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 denied and stops the process step.

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

The service manager 310 then authorizes (1420) the service request. In some embodiments, this step is an optional step, such as when the service manager is configured not to perform this step. In this step, the service manager identifies whether the device is allowed to access the work based on the service profile of the computing service. The service manager can obtain the service profile from the service data repository. For example, if the device is identified in the device information in the routine data within the service profile, the device is allowed to access the work, and the routine data is associated with a routine belonging to a task, and the task belongs to the work. If the device is not allowed to access the work, the service manager responds to the device through the access manager to indicate that the service request is denied and stops the process step.

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 a device to the execution of the work through the device adding process. In this case, if the work is not being executed, the service manager can trigger the execution of the work. If the work is being executed, this step is an optional step.

In some embodiments, work manager 315 is selected by service manager 310 to perform work according to a work order. For example, a work order may be received from application controller 365 or generated by service manager 310, as described below.

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

The first option for the service manager 310 to trigger the execution of work is for the service manager 310 to send (1425) a notification to the application controller 365 regarding the work to be performed. The notification includes information identifying the computing service and information identifying the work. After the notification, the application controller 365 can send (1430) a work order for the work to be performed. The application controller's request (called a work order) is sent to the work manager 315 through the service manager 310. The work manager is selected by the service manager. The work manager confirms the work order to the application controller through the service manager. The application controller then sends a confirmation to the service manager to indicate that the notification was received. This confirmation indicates to the application controller that the work is being executed.

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

Regardless of whether the work order comes from application controller 365 or service manager 310, the work order includes information identifying the computing service and information identifying the work. The work order may also include information identifying the order (i.e., the work order), which may be generated by service manager 310. Based on the work order, the work manager obtains work data from service data repository 335, which is associated with the work and is part of the service profile of the computing service.

In some embodiments, the work order indicates one or more trigger conditions. The one or more trigger conditions are evaluated by the work manager. When one of the one or more trigger conditions is met, the work manager performs the work. For example, the trigger condition can be that the number of devices requesting access to the work is equal to or greater than a threshold k, and the value k is a positive value. The value k can be 1, meaning that the work execution begins as soon as there is a service function instance (which is an instance of the service function associated with the work, and can be a device in this process) requesting or attempting to access the work. The value k can be greater than 1, for example in connection with k-anonymity provision. In some embodiments, the work manager performs the work when a work order is received (i.e., the work manager is triggered to perform the work according to the work order).

When executing a job, the job manager identifies one or more tasks included in the job from the job data, and for each of these one or more tasks, the job manager selects a task manager to manage the task and triggers the task manager to execute the task. When the job includes multiple tasks, the job manager triggers the execution of the tasks according to the inter-task dependency information indicated in the job data. The job manager triggers the execution of interdependent tasks in sequence. That is, after executing the second task (i.e., after the second task has been executed), the job manager triggers the execution of the first task that depends on the second task (as indicated by the inter-task dependency information). In some embodiments, the job manager triggers the parallel (i.e., simultaneous) execution of tasks that do not have interdependencies (as indicated in the inter-task dependency information).

The service manager 310 then notifies (1440) the work manager 315 that the device 350 is accessing (or requesting access to) a work by sending a notification to the work manager. The notification includes information identifying the device, information identifying the work, and information identifying the computing service. The work manager is selected by the service manager based on the information identifying the computing service and/or the information identifying the work. In some embodiments, this step can be integrated with the work order 1435 when the work order originates from the service manager, 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).

Based on the work data associated with the work, the work manager can identify routines respectively associated with service functions representing devices. A device is an instance of a service function. For each identified routine, the work manager further identifies a task to which the routine belongs, wherein a task belongs to the work, and the work manager performs the following operations to ensure that the device is considered when executing the task during the execution of the work.

If the task is not currently executing, the work manager 315 can add (1445) the device to be considered when triggering the task to be executed 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 information identifying the computing service and information identifying the task. The task request instructs the device to join the task and includes information identifying the device. The work manager 315 decides to trigger or when to trigger the execution of the task based on a number of factors, as described in the notifications (1425) and (1435) regarding the execution of the work.

If the task is currently executing, the work manager 315 adds (1445) the device to the execution of the task. That is, the work manager 315 identifies or selects the task manager (managing the task) and sends a task update request to the task manager. The task update request includes information identifying the computing service and information identifying the task. The task update request indicates that the device joins the task and includes information identifying the device. The task update request may also include information identifying the routine.

In either case, the task manager may perform the following operations based on the request (task request or task update request) received from the work manager. The task manager may identify routines, each routine being associated with a service function representing a device. The task manager may identify routines based on task data and related routine data associated with the task. For each identified routine, the task manager may perform one of the following operations based on whether the routine is a local routine or an external routine.

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

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

The work manager 315 may then confirm the device arrival by sending (1450) an acknowledgement to the service manager 310 indicating receipt of the device arrival notification.

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

In some embodiments, after the access manager 305 has authorized (1410) the service request, the work has been performed, and the access manager 305 is aware of 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 to be considered for execution of the task and then send a response directly to the access manager 305, which response can include or indicate a confirmation. The above can be viewed as the access message 305 initiating the device addition process with the work manager 315 using the request (1415).

In some embodiments, after the service manager 310 has sent 1435 the work order to the work manager, the service manager 310 may send 1455 a response regarding the service request to the access manager 305. Based on the response 1455, the access manager may perform the device add process directly with the work manager 315, as described above.

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

The work order itself may include information specifying one or more triggering conditions. The work manager evaluates the triggering conditions. When at least one of the conditions is met, or in some embodiments, when all of the conditions are met, the work manager executes the work order, i.e., executes the first work identified in the work order. The work manager generates information identifying the execution of the first work and uses the information identifying the execution of the first work to manage the execution of the first work. The information identifying the execution of the first work can be referred to as a differentiator because it distinguishes 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 a service profile of a first computing service. In some embodiments, the work manager obtains the service profile from a service data repository. When executing the first work, the work manager requests or triggers the task manager to execute the first task, wherein the work manager provides the task manager with information identifying the execution of the first work, information identifying the first task, and information identifying the first computing service. Therefore, the task manager knows that the work manager manages the execution of the first work and maintains information about the work manager. The task manager executes the first task according to the request of the work manager and manages the execution of the first task. The task manager regards the execution of the first task as part of the execution of the first work, and uses the information identifying the first task and the information identifying the execution of the first work together to identify the execution of the first task.

The first task includes a routine. The task manager obtains information identifying the routine from the task data associated with the first task. If the routine is an external routine, that is, if the routine is associated with a service function (which is a symbolic function) representing external work, and if the external work is not performed according to the knowledge of the task manager, then when executing the first task, the task manager requests the service manager to perform the external work. If the external work is indeed not being performed, then according to the request, the service manager triggers the execution of the external work by selecting a work manager and sending a work order to the work manager. Otherwise, the service manager must have triggered the execution of the external work by selecting a work manager and sending a work order to the work manager. In either case, the service manager responds to the request of the task manager, sends information identifying the work order to the task manager, and the task manager accordingly knows that the external work is being performed.

If the routine is a local routine, that is, if the routine is not associated with any service function representing an external work, when executing the first task, the task manager generates information identifying the execution of the routine (e.g., execution ID) and requests or triggers the routine manager to execute the routine, wherein the task manager provides the routine manager with information identifying the execution of the routine, information identifying the routine, and information identifying the computing service. Since 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 request of the task manager and manages the routine execution.

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

During the execution of the routine, the routine manager may receive a notification from the service function instance through the privacy router. The service function instance is one of the service function instances described above, and the privacy router is associated with the service function instance. The notification from the service function instance may indicate that task-level context synchronization related to the execution of the routine is required. Task-level context synchronization means that the execution of the first task needs to be synchronized to the computing context. The notification from the service function instance includes information identifying the execution of the routine. The notification may also include information (e.g., context ID) identifying the computing context (i.e., "context"). Based on the notification from the service function instance, the routine manager requests to perform task-level context synchronization through the context synchronization process shown in FIG. 15. The routine manager sends a context synchronization request to the work manager through 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. Then, the work manager performs task-level context synchronization according to the request received from the task manager. Then, the work manager responds to the task manager, and the task manager in turn responds to the routine manager. Afterwards, the routine manager may reply to the service function instance to indicate that the task-level context synchronization is complete.

FIG. 15 shows a context synchronization process among a routine manager, a task manager and a work manager provided by an embodiment.

First, the routine manager 340 requests to perform task-level context synchronization by sending (1505) a context synchronization request to the task manager 320. The context synchronization request includes information identifying the routine execution. The request may also include information identifying the context (eg, context ID).

The task manager then 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, wherein the context synchronization request includes 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 regarded as the result of the task manager processing the context synchronization request received from the routine manager.

The work manager then identifies the first work and the first computing service based on information identifying the execution of the first work, wherein the information is in the context synchronization request received from the task manager. Based on the information identifying the first task (the information is in the context synchronization request received from the task manager) and work data associated with the first work (the work data is part of the service profile of the first computing service), the work manager 315 identifies (1515) a second task that requires context synchronization. The second task belongs to the first work. If the second task does not exist (or cannot be identified), this step is optional.

The work manager 315 then requests (1520) to deactivate the first task execution (the execution of the first task being part of the execution of the first work) to initiate the task deactivation process.

Then, the work manager 315 requests (1525) to deactivate the second task execution (the execution of the second task is part of the execution of the first work) to initiate the task deactivation process. If the second task does not exist, this step is an optional step.

Then, the work manager 315 generates (1530) a context ID by assigning information for identifying the context. If the context synchronization request (1505) includes information identifying the context, this step is an optional step.

The work manager 315 then requests (1535) to activate the first task execution (the execution of the first task has been deactivated (1520)) to initiate the task activation process. The request sent (1535) by the work manager includes information identifying the context, which is included in the request for context synchronization of the routine manager (1505) or generated (1530) by the work manager 315.

The work manager 315 then requests (1540) activation of the second task execution (the execution of the second task was previously deactivated (1525)) to initiate the task deactivation process. The request sent by the work manager 315 includes information identifying the context, which is included in the request (1505) of the routine manager's context synchronization, or generated (1530) when requesting (1535) activation of the first task execution. This step is optional if the second task does not exist.

Then, the work manager 315 responds (1545) to the task manager regarding the context synchronization request (1510) to indicate that the task-level context synchronization has been completed. This step is an optional step.

Then, the task manager 320 responds (1550) to the routine manager 340 for the context synchronization request (1510) to indicate that the task level context synchronization has been completed. This step is an optional step.

Context Synchronization Process FIG. 15 involves task deactivation processes 1520 , 1530 and activation processes 1535 , 1540 , both of which may include multiple process steps as shown in FIG. 16 .

FIG. 16 illustrates a task activation or deactivation process provided by an embodiment, wherein a work manager requests activation or deactivation of task execution. Task execution refers to the execution of a task that belongs to a work associated with a computing service. Task execution is part of the execution of a work. In other words, the execution of a work includes task execution. Task execution includes routine execution, i.e., the execution of a routine that belongs to a task. The work manager's request is sent to one or more task managers that manage task execution, and the one or more task managers deactivate or activate the execution of their routines accordingly.

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

The request (1605) is referred to as a task deactivation request when it concerns deactivating task execution, and is referred to as a task activation request when it concerns activating task execution.

Then, the task manager that has received the task activation or deactivation request (1605) from the work manager identifies the local routines belonging to the task that is identified in the task activation or deactivation request. For each identified local routine, the task manager can also identify the routine manager that manages the routine and performs the following operations according to the task activation or deactivation request.

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

When the request sent (1610) to each routine manager 340 is to activate routine execution, the request may include information identifying the context, which was previously received (1605).

The request sent (1610) to each routine manager 340 is referred to as routine deactivation in the case of a request to deactivate routine execution and is referred to as routine activation in the case of a request to activate routine execution.

The routine manager that has received the routine activation or deactivation request (1610) can then obtain the information identifying the routine from the request directly (if the request includes information identifying the routine) or indirectly (by mapping the information identifying the routine execution in the request to the information identifying the routine) and perform the following operations according to the request.

If the request is a routine deactivation request, the routine manager 340 may deactivate (1615) the local routine execution identified in the request. The routine manager sends a communication deactivation request to a service function instance associated with the routine manager to suspend or deactivate data communications associated with the routine execution, wherein the service function instance is an instance of a service function associated with the routine. The communication deactivation request may be sent to the service function instance via a privacy router associated with the service function instance. The communication deactivation request may include information identifying the local routine execution, information identifying the local routine, and information identifying the computing service. The communication deactivation request may also include information identifying the context to which the local routine execution is currently synchronized.

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

Each privacy router can forward the communication deactivation request to the service function instance associated with the privacy router and the routine. Upon receiving the communication deactivation request, each service function instance correspondingly suspends (or stops, or terminates) sending data services associated with the execution of the routine.

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 the service function instance associated with the routine manager to resume or activate data communications associated with the routine execution, wherein the service function instance is an instance of a service function associated with routing. The communication activation request is sent to the service function instance via a privacy router associated with the service function instance. The communication activation request includes information identifying the routine execution, information identifying the routine, and information identifying the computing service. The communication activation request may also include information identifying a context received in the routine activation request. A context is a context to which the routine execution is to be synchronized.

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

Each privacy router forwards the communication activation request to the service function instance associated with the privacy router and the routine. Upon receiving the communication activation request, each service function instance correspondingly activates (or resumes, or restarts, or starts) the data service associated with the execution of the routine.

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

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

Then, the task manager 320 that has received the task activation or deactivation request (1605) identifies the foreign routines that belong to the task and are executed as part of the task execution, and the task is identified in the task activation or deactivation request. The task manager 320 activates or deactivates (1625) the execution of the relevant foreign routines, that is, the execution of the foreign routines as part of the task execution.

In order to activate or deactivate the execution of an external routine, the task manager identifies the external function associated with the external routine. For each identified external function, the task manager 320 requests to activate or deactivate (1625) the corresponding external work execution (the execution of the external work triggered by the task manager during the task execution), and initiates the work activation or deactivation process (as shown in Figure 17). According to the information identifying the external computing service to which the external work belongs, the request (shown as element 1705 in Figure 17) is sent to the service manager selected by the task manager 320. The information identifying the external computing service is included in the service function data associated with the external function representing the external work. The request sent to the service manager includes information identifying the context, which is first received from the work manager (1605). In the case where the external routine execution is activated (1625), the context is the context to which the external work execution is to be synchronized. In the case where the external routine execution is deactivated (1625), the context is the context to which the external work execution is currently synchronized.

If such foreign routine or such foreign functionality does not exist, activation or deactivation (1625) of foreign routine execution is optional. Such activation or deactivation (1625) can be performed in parallel with the task manager 320 requesting (1610) a routine activation or deactivation, the routine manager 340 activating or deactivating (1615) native routine execution, or the routine manager 340 responding (1620) to a routine activation or activation request.

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

Work execution refers to the execution of work associated with a computing service. The execution of work is associated with or triggered by a work order, which is generated by a network entity (such as an application controller) or a service manager on behalf of an application controller. Work execution includes task execution, i.e., the execution of tasks belonging to a work. Requests from network entities are sent through the service manager to the work manager that manages the work execution. The work manager deactivates or activates the tasks of the work execution accordingly.

FIG. 17 illustrates a work activation or deactivation process provided by an embodiment, wherein a network entity initiates the work activation or deactivation process by requesting deactivation or activation of work execution.

First, a network entity 1702, such as a task manager 320, may request activation or deactivation of 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 may 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 based on any one of the information identifying the computing service and the information identifying the work order.

When the network entity requests activation of work execution, the network entity may also include information identifying the context (eg, context ID) in the request. This indicates that the work execution should be synchronized to the context when activated. Thus, the work execution may 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 the work manager 315 that services or processes the work order.

The work manager 315 then activates or deactivates (1715) the work execution based on the request (1710) received from the service manager 310. The work manager identifies one or more tasks belonging to the work and activates or deactivates the executions of these tasks that are part of or associated with the work execution (i.e., task executions). To this end, for each task execution, the work manager identifies one or more task managers that manage the task execution and requests each task manager to activate or deactivate the task execution through the task activation or deactivation process shown in Figure 16.

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

The work manager 315 may then respond to the routine activation or deactivation request by sending (1720) a work activation or deactivation response to the service manager 310 to indicate that the work execution identified in the work activation or deactivation request has been activated or deactivated accordingly (1715).

The service manager 310 may then send ( 1725 ) a working activation or deactivation response to the network entity 1702 .

Embodiments include service orchestration for determining a deployment location of a service function of a first computing service and selecting a computing plane supporting the computing service so that the computing service can run in a network.

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

An embodiment includes providing service access by allowing a device to access a first computing service.

Embodiments include context synchronization, wherein the context synchronization refers to synchronizing the execution of a first task within a first computing service to a computing context. If the execution of the first task can share a 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 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 for communicating with an orchestrator, the orchestrator can communicate with a resource manager and provide instructions to the resource manager to instantiate service functions of a computing service. The 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 for communicating with a privacy router and an instance manager and providing instructions to the privacy router and the instance manager to configure a compute plane for a compute service.

An embodiment includes a work manager that is used to communicate with an access manager, which can communicate with a device work manager, receive one or more service requests from a device, receive and authorize the service requests, and further trigger the execution of work related to the service requests.

Embodiments include a work manager for communicating with a work manager that may execute work and notifying the work manager of access of a device to the work so that the work manager may include the device in the execution of the work.

The embodiment includes a system architecture including a work manager having the function of synchronizing computing context across tasks and works.

In an embodiment, synchronizing the compute context across tasks and work may include a work manager communicating with a task manager, which may communicate with a routine manager and provide instructions to the routine manager to synchronize routine execution to the compute context, and provide instructions to the task manager to synchronize task execution to the compute context.

In an embodiment, synchronizing the compute context across tasks and work may include a work manager communicating with a service manager, which may communicate with different work managers and provide instructions to the different work managers to synchronize different work executions to the compute context.

In an embodiment, the device may 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 be registered with the platform as a device and identified as a device by the platform.

18 is a block diagram of an electronic device (ED) 1852 shown within a computing and communication environment 1850, which can be used to implement the devices and methods disclosed herein. In some embodiments, the electronic device 1852 can be an element of a communication 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 also include a dedicated processor, 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 the ED 1852. Optionally, the ED 1852 may also include components such as a mass storage device 1862, a video adapter 1864, and one or more I/O interfaces 1868 (as shown in dashed lines).

The memory 1846 may 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 certain embodiments, the memory 108 may include more than one type of memory, such as a ROM used at boot time and a DRAM used to store programs and data when executing programs.

The mass storage 1862 may be any type of non-transitory storage device for storing data, programs, and other information and making the data, programs, and other information accessible via the bus 1860. In some embodiments, the mass storage 1862 may be remote from the electronic device 1852 and may be accessed via a network interface such as the interface 1858. In the illustrated embodiment, the mass storage 1862 is distinct from the memory 1846 that includes it, and may generally perform storage tasks compatible with higher latency, but may generally provide less or no volatility. In some embodiments, the mass storage 1862 may be integrated with the memory 1846 to form a heterogeneous memory.

In some embodiments, the electronic device 1852 may be a stand-alone device, while in other embodiments, the electronic device 1852 may reside in a data center. As will be understood in the art, a data center is a collection of computing resources (usually in the form of servers) that can be used as collective computing and storage resources. In a data center, multiple servers may be connected together to provide a computing resource pool in which virtualized entities may be instantiated. Data centers may be interconnected to form a network that includes a pool of computing resources and storage resources that are connected to each other via connection resources. Connection resources may take the form of physical connections such as Ethernet or optical communication links, and may also include wireless communication channels. If two different data centers are connected via multiple different communication channels, the links may be combined together using any of a variety of techniques including forming a link aggregation group (LAG). It should be understood that any or all computing, storage, and connection resources (as well as other resources within the network) may be divided between different subnets, and in some cases, may be divided in the form of resource slices. If resources across multiple connected data centers or other node collections are sliced, different network slices may be created.

It should be understood that network functions such as privacy routers, tasks, jobs and routine managers, and routine clients and servers can be instantiated within one or more electronic devices. Therefore, embodiments include one or more electronic devices, the electronic devices including a processor and a non-transitory machine-readable memory, the non-transitory machine-readable memory storing machine-executable instructions that, when executed by the processor, cause the electronic device to implement the methods disclosed herein. In addition, systems of electronic devices and/or data centers can be used to implement the methods disclosed herein.

An embodiment includes a method for implementing a computing service, the method comprising: a first service manager receiving a service registration request for a first computing service from an application controller; the first service manager requesting authorization for a second computing service from a second service manager; the first service manager using at least a portion of the second service to create a service profile for the first computing service to instantiate the first computing service.

In an embodiment, creating a service profile of the first computing service using at least a portion of the second service to instantiate the first computing service includes: the first service manager receiving authorization to reuse work of the second computing service from the second service manager.

In an embodiment, the method of the second service manager may include: authorizing reuse of the work of the second computing service; updating a service profile of the second computing service; and responding to the first computing service.

In an embodiment, the first service and the second service may be the same service, and the service registration request may be a service registration request for adding a new job to the service based on an existing job in the service.

In an embodiment, the method may further include: the second service manager mapping information identifying the work of the second computing service that is authorized for reuse to a combination of: information identifying the first computing service, and information identifying the reuse of the work of the second computing service.

In an embodiment, the method may further include: the second service manager storing the mapped information in a service profile of the second computing service in a service data repository.

In an embodiment, the first service manager creating a service profile of the first computing service using at least a portion of the second service to instantiate the first computing service may include: reusing the work of the second computing service.

In an embodiment, the request may be a request for a new deployment, and said reusing said work of said second computing service may include: said second service manager authorizing said reuse of said work.

In an embodiment, the request may be a request for a remote connection, and said reusing said work of said second computing service may include: the second service manager creating a copy of the work for use by the first service.

In an embodiment, the method may include: the first service manager maps the reuse of the work of the second computing service to the reuse of the copy of the work of the second computing service; the first service manager updates the service description information (SDI) of the first computing service by replacing the information identifying the work of the second computing service with the information identifying the copy of the work of the second computing service.

In an embodiment, the method may further include: the orchestrator making one or more incremental deployment decisions for the second computing service.

In an embodiment, the method may further include: the orchestrator further making one or more dynamic deployment decisions for the work of the second computing service.

In an embodiment, one or more dynamic deployment decisions may include: a first dynamic deployment decision, which determines additional deployment locations and corresponding computing and network resource requirements for each internal function of work Y; a second dynamic deployment decision, which determines inter-function connections and inter-function connections based on the additional deployment locations.

An embodiment includes a method for a device to request a computing service, the method comprising: a network entity receiving a request for a computing service from a device; sending a notification to a work manager to perform work using information of the device; receiving a confirmation of the execution of the work of the device from the work manager; and sending a response to the device.

In an embodiment, the method may further include: the work manager executes the work according to the information of the device, wherein the execution of the work includes: identifying a routine, the routine being associated with a service function representing the device; identifying, for each routine, a task of the work to which the routine belongs; wherein, when the task manager is triggered to execute the task, the work manager sends a task request to the task manager, the task request including information identifying the device.

In an embodiment, the method may further include: a work manager executes the work based on information identifying the device, wherein the execution of the work includes: identifying a routine, the routine being associated with a service function representing the device; identifying, for each routine, a task of the work to which the routine belongs; wherein, when the task manager is executing the task, the work manager sends a task update request to the task manager, the task update request including information identifying the device.

In an embodiment, the method may further include: the network entity notifying the application controller of the work execution.

In an embodiment, the method may further include the network entity acting as a service manager.

In an embodiment, the method may also include: the work manager receives a request from the task manager to perform context synchronization between the first task and the second task, the request originating from the routine manager of the first task; identifying the second task that requires context synchronization; requesting to deactivate the execution of the first task; requesting to deactivate the execution of the second task; requesting to activate the execution of the first task; requesting to activate the execution of the second task; wherein the request to perform context synchronization includes information identifying the routine execution.

In an embodiment, the method may further include: the work manager generating information identifying a context to which the task execution should be synchronized.

In an embodiment, the request to perform context synchronization may also include information identifying the context to which the task execution should be synchronized.

In an embodiment, the deactivation may include, after the task manager receives a response regarding routine deactivation, the work manager: sending a request to the task manager to deactivate the task, the task manager being used to send a request to the routine manager to deactivate local routine execution and to deactivate foreign routine execution; and receiving a response regarding task deactivation from the task manager.

In an embodiment, the request to the routine manager may include information identifying a context to which the task execution is synchronized.

In an embodiment, the method may also include: the routine manager deactivating the local routine execution identified in the request to the routine manager by sending a communication deactivation request to a service function instance associated with the routine manager to suspend data communication associated with the local routine execution; wherein the communication deactivation request is sent via a privacy router associated with the service function instance.

In an embodiment, the communication deactivation request may further include: information identifying the execution of the local routine; information identifying the local routine; information identifying the computing service; information identifying a context in which the execution of the local routine is synchronized.

In an embodiment, the activation may include, after the task manager receives a response regarding the routine activation, the work manager: sending a request to activate the task to the task manager, the task manager being used to send a request to activate a local routine and to activate execution of an external routine to the routine manager; and receiving a response regarding the task activation from the task manager.

In an embodiment, the request to the routine manager may include information identifying a context to which the task execution should be synchronized.

In an embodiment, the method may further include: the routine manager activating the local routine execution identified in the request to the routine manager by sending a communication activation request to the service function instance associated with the routine manager to activate data communication associated with the local routine execution; wherein the communication activation request is sent through the privacy router associated with the service function instance.

In an embodiment, the communication activation request may further include: information identifying the execution of the local routine; information identifying the local routine; information identifying the computing service; information identifying a context to which the execution of the local routine is synchronized.

In an embodiment, deactivating an external function may include: a task manager identifying an external function associated with the external routine; sending a request to the service manager to deactivate the corresponding external work; initiating a work deactivation process; wherein the deactivation request includes: information identifying the external computing service to which the external work belongs, and information identifying the context, and the external work is synchronized to the context.

In an embodiment, activating an external function may include: a task manager identifying an external function associated with the external routine; sending a request to the service manager to activate the corresponding external work; initiating a work activation process; wherein the activation request includes: information identifying the external computing service to which the external work belongs, and information identifying the context to which the external work should be synchronized.

Embodiments are described above in conjunction with various aspects of the present invention, and these embodiments can be implemented based on these aspects. It will be appreciated by those skilled in the art that embodiments can be implemented in conjunction with the aspects describing these embodiments, but can also be implemented together with other embodiments of this aspect. When the embodiments are mutually exclusive or incompatible with each other, this will be apparent to those skilled in the art. Some embodiments can be described in conjunction with an aspect, but can also be applied to other aspects, which will be apparent to those skilled in the art.

Although the present invention has been described with reference to specific features and embodiments of the present invention, it is apparent that various modifications and combinations of the present invention may be made without departing from the present invention. Therefore, the specification and drawings are only regarded as an illustration of the present invention as defined by the appended claims, and are intended to cover any and all modifications, variations, combinations or equivalents falling within the scope of the present invention.

Claims (34)

1. A method for implementing a computing service, comprising:

the first service manager receives a service registration request for a first computing service from an application controller;

The first service manager requesting authorization for a second computing service from a second service manager;

The first service manager creates a service profile of the first computing service using at least a portion of the second service to instantiate the first computing service.

2. The method of claim 1, wherein the creating a service profile of the first computing service using at least a portion of the second service to instantiate the first computing service comprises:

The first service manager receives authorization from the second service manager to reuse the work of the second computing service.

3. The method of claim 1 or 2, further comprising the second service manager:

Authorizing reuse of the work of the second computing service;

updating a service profile of the second computing service;

Responsive to the first computing service.

4.A method according to any one of claim 1 to 3, wherein,

The first service and the second service are the same service,

The service registration request is a service registration request to add a new job to the service based on an existing job in the service.

5. The method of any of claims 1-4, further comprising the second service manager:

Mapping information identifying the work of the second computing service authorized for reuse to a combination of:

information identifying the first computing service;

Information identifying the reuse of the work of the second computing service.

6. The method as recited in claim 5, further comprising: the second service manager stores the mapped information in a service profile of the second computing service in a service data store.

7. The method of claim 2, wherein the first service manager creating a service profile of the first computing service using at least a portion of the second service to instantiate the first computing service comprises: reusing the work of the second computing service.

8. The method of claim 7, wherein the request is a request for a new deployment, and the reusing the job of the second computing service comprises: the second service manager authorizes the reuse of the work.

9. The method of claim 7, wherein the request is a request for a remote connection, and the reusing the job of the second computing service comprises: the second service manager creates a copy of the work for use by the first service.

10. The method as recited in claim 9, further comprising:

the first service manager maps the reuse of the work of the second computing service to reuse of the copy of the work of the second computing service,

The first service manager updates the service description information SDI of the first computing service by:

replacing information identifying the work of the second computing service with information identifying the copy of the work of the second computing service.

11. The method according to claim 9 or 10, further comprising: an orchestrator makes one or more incremental deployment decisions for the second computing service.

12. The method as recited in claim 11, further comprising: the orchestrator also makes one or more dynamic deployment decisions for the work of the second computing service.

13. The method of claim 12, wherein the one or more dynamic deployment decisions comprise:

a first dynamic deployment decision that determines a corresponding computing and network resource requirement for each internal function of the work Y and the additional deployment location;

A second dynamic deployment decision that determines an inter-function connection and an inter-function connection based on the additional deployment location.

14. A method for a device to request a computing service, comprising a network entity:

Receiving a request for a computing service from a device;

Sending a notification to a job manager to perform a job using information of the device;

receiving a confirmation of the performance of the work of the device from the work manager;

a response is sent to the device.

15. The method as recited in claim 14, further comprising:

The work manager performs the work according to the information of the device,

Wherein said performing said 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 when the task manager is triggered to execute the task, the work manager sends a task request to the task manager, the task request including information identifying the device.

16. The method as recited in claim 14, further comprising:

The job manager performs the job according to information identifying the device,

Wherein said performing said 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, while the task manager is executing the task, the job manager sends a task update request to the task manager, the task update request including information identifying the device.

17. The method according to any one of claims 14 to 16, further comprising:

the network entity informs the application controller of the execution of the job.

18. The method according to any of claims 14 to 17, wherein the network entity is a service manager.

19. The method of any one of claims 14 to 18, further comprising the job manager:

Receiving a request from the task manager to perform context synchronization between a first task and a second task, the request originating from a routine manager of the first task;

identifying a second task requiring context synchronization;

Requesting to deactivate the first task execution;

requesting deactivation of the second task execution;

requesting activation of the first task execution;

requesting activation of the second task execution;

wherein the request to perform context synchronization includes information identifying the execution of the routine.

20. The method of claim 19, further comprising the job manager generating information identifying the context to which the task execution should be synchronized.

21. The method of claim 19, wherein the step of determining the position of the probe comprises,

The request to perform context synchronization also includes information identifying the context to which the task execution should be synchronized.

22. The method according to any one of claims 19 to 21, wherein the deactivating comprises:

After the task manager receives a response regarding routine deactivation, the job manager:

A request to deactivate a task is sent to the task manager,

The task manager is configured to send a request to the routine manager to deactivate local routine execution and deactivate foreign routine execution;

A response is received from the task manager regarding the deactivation of the task.

23. The method of claim 22, wherein the request to the routine manager includes information identifying the context to which the task execution is synchronized

24. The method according to claim 22 or 23, further comprising:

the routine manager deactivates the local routine execution identified in the request to the routine manager by sending a communication deactivation request to a service function instance associated with the routine manager to suspend data communications associated with the local routine execution;

Wherein the communication deactivation request is sent through a privacy router associated with the service function instance.

25. The method of any of claims 21 to 24, wherein the communication deactivation request further comprises:

Information identifying the local routine execution;

Information identifying the local routine;

Information identifying the computing service;

Information identifying a context in which the local routine execution is synchronized.

26. The method according to any one of claims 19 to 25, wherein the activating comprises:

After the task manager receives a response regarding routine activation, the job manager:

A request to activate a task is sent to the task manager,

The task manager is used for sending a request for activating a local routine and activating execution of an external routine to the routine manager;

a response is received from the task manager regarding task activation.

27. A method according to any one of claims 20 to 26, wherein the request to the routine manager includes information identifying the context to which the task execution should be synchronised.

28. The method according to claim 26 or 27, further comprising:

The routine manager activates the local routine execution identified in the request to the routine manager by sending a communication activation request to the service function instance associated with the routine manager to activate data communication associated with the local routine execution;

Wherein the communication activation request is sent through the privacy router associated with the service function instance.

29. The method of any one of claims 26 to 28, wherein the communication activation request further comprises:

Information identifying the local routine execution;

Information identifying the local routine;

Information identifying the computing service;

Information identifying the context to which the native routine execution is synchronized.

30. The method of any one of claims 22 to 29, wherein deactivating a foreign function comprises: the task manager:

Identifying a foreign function associated with the foreign routine;

sending a request for deactivating corresponding external work to the service manager;

initiating a work deactivation process;

wherein the request for deactivation comprises:

Information identifying a foreign computing service to which the foreign work belongs;

information identifying the context to which the foreign work is synchronized.

31. The method of any one of claims 22 to 29, wherein activating a foreign function comprises: the task manager:

Identifying a foreign function associated with the foreign routine;

Sending a request for activating corresponding external work to the service manager;

initiating a work activation process;

wherein the request for activation comprises:

Information identifying a foreign computing service to which the foreign work belongs;

information identifying the context to which the foreign work should be synchronized.

32. An apparatus for implementing a computing service, comprising:

A processor;

At least one non-transitory machine-readable medium storing machine-readable instructions that, when executed by the processor, cause the apparatus to:

The first service manager receives a service registration request for a first computing service from the application controller;

The first service manager requesting authorization for a second computing service from a second service manager;

The first service manager creates a service profile of the first computing service using at least a portion of the second service to instantiate the first computing service.

33. An apparatus for implementing a computing service, comprising:

A processor;

at least one non-transitory machine-readable medium storing machine-readable instructions that, when executed by the processor, cause the apparatus to perform the methods described and claimed herein.

34. A system comprising a plurality of devices in communication with each other, the system configured to perform the methods described and claimed herein.