Patent Description:
In recent years, with the increasing popularity and maturity of lightweight virtualization technology (for example, the container) the microservices based architecture has been adopted by more and more applications or services.

<FIG> illustrates an example of a microservice architecture.

In the microservice architecture a single service is decomposed into a plurality of modular microservices (S1 to S6) which may comprise for example containers or virtual machines. The microservices may be small in size, messaging enabled, bounded by contexts, decentralized, deployed, and/or built and released independently with automated process. The microservices may work together and communicate with each other through a Web Application processing interface (API) <NUM> (e.g., RESTful API) or message queues. Each microservice may expose an API and may be invoked by other microservices or an external client (102a to 102c). The processing functions performed by each microservice can then be used to provide the single service.

There are many scenarios in which such microservice based architectures may be used. For example, in the current 3gpp specification for <NUM> Core (5GC) network, the <NUM> System architecture may leverage service-based interactions between Control Plane (CP) Network Functions where identified.

<FIG> illustrates an example of a basic Service Based Architecture (SBA) of the core network. Network Functions (NFs) expose their abilities as services that can be used by other NFs. The NFs may therefore effectively function as microservices. For example, the Access and Mobility Management Function (AMF) may provide a service that enables a different NF to communicate with the UE and/or the AN (Access Network) through the AMF; the Session Management Function (SMF) may provide a service that allows consumer NFs to handle the Protocol Data Unit (PDU) sessions of UEs.

The NFs in the core network may expose their services (or processing functions) by registering themselves with the NRF (Network Repository Function). The NRF may also offer service discovery to enable different NFs to find each other.

To achieve a specific procedure in the system based architecture, a series of microservices performed by different network functions may need to be called. For example, in a UE registration procedure, a UE may send a registration request, the AMF may call the authentication service to AUSF (Authentication Sever Function), and the AUSF may call the service of UDM (Unified Data Management) to retrieve the authentication related data for the UE. This single service, UE registration, is therefore formed from a plurality of chained microservices performed by the different NFs. Another example could be the PDU session establishment procedure, where the UE may send the PDU session establishment request to AMF, then AMF may call the PDU session service in SMF, and the SMF may call the UDM's service to retrieve the corresponding subscription data, after that the SMF may call the service in PCF (Policy Control Function) to retrieve the corresponding policy for the PDU session.

Document <CIT> discloses a method in which an intermediate node, of a multi-stage process path through a computer network, receives a workload message with an associated latency budget to complete the multi-stage process at a final stage device. In response, the intermediate node determines a current latency from an initial stage device for the workload message to the receiving of the workload message, and also determines a remaining portion of the latency budget based on the current latency. In response to the remaining portion of the latency budget being less than expected at the intermediate node, the intermediate node may perform one or more latency-reducing actions, and then transmits the workload message toward the final stage device.

According to some embodiments there is provided a method performed by a first microservice capable of providing a first processing function in a service comprising a plurality of microservices. According to the method, the first microservice receives a processing request to provide the first processing function and further retrieves a sequence of a plurality of microservices associated with the processing request from a local repository, said local repository being updated by a Service Chain Procedure Repository, wherein the sequence comprises the first microservice. The first microservice further obtains a current latency requirement associated with the remaining microservices in the sequence, and obtains an estimated latency associated with the remaining microservices in the sequence. In a further step of the method, the microservice places the processing request in a processing queue based on a comparison between the current latency requirement and the estimated latency, thereby scheduling the processing request into the processing queue according to a priority of the processing request for processing by a processing function.

According to some embodiments there is provided a computer system comprising processing circuitry and a memory containing a first microservice capable of providing a first processing function in a service comprising a plurality of microservices. When the first microservice is executed by the processing circuitry it instructs the processing circuitry to receive a processing request to provide the first processing function and further to retrieve a sequence of a plurality of microservices associated with the processing request from a local repository, said local repository being updated by a Service Chain Procedure Repository, wherein the sequence comprises the first microservice. The processing circuitry it instructs the processing circuitry to obtain a current latency requirement associated with the remaining microservices in the sequence, obtain an estimated latency associated with the remaining microservices in the sequence, and to place the processing request in a processing queue based on a comparison between the current latency requirement and the estimated latency, thereby scheduling the processing request into the processing queue according to a priority of the processing request for processing by a processing function.

For a better understanding of the embodiments, and to show how they may be put into effect, reference will now be made, by way of example only, to the accompanying drawings, in which:.

All references to a/an/the element, apparatus, component, means, step, etc. are to be interpreted openly, as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise.

In a microservice based application, the processing request from a client may involve multiple interactions among the microservices in order to provide the service, for example, as shown in the <FIG>, a processing request to microservice s1 will trigger the invocation of service s2, and consequently s4 and s6 will be called, i.e., the processing request will introduce a microservice call sequence. Based on the type of the processing request (e.g. UE registration, etc), different microservice call sequences may be invoked for each incoming processing request.

For a specific processing request, it may be desirable that the service is provided within a certain time limit. For example, UE registration as described above, may be required to be finished within <NUM>, or a handover procedure may be required to be finished within <NUM>, etc. These delay requirements may be important for the Quality of Service (or Quality of Experience) for some latency sensitive use cases, e.g. gaming, Augmented or Virtual Reality (AR/VR), etc. Since different service requests may have different latency (time) requirements, it may be desirable that the microservice requests to the same microservice, but belonging to different service requests, be treated differently.

For example, both the UE registration service request and PDU session establishment service request may need to call the AUSF authentication service as a microservice. However, the UE registration service request has a larger number of further microservice calls in the sequence after the authentication than those in the PDU session establishment service request. Therefore, the time budget for the authentication service in the UE registration service request may be smaller than the time budget for the authentication service in the PDU session establishment service request. Hence it may be desirable that AUSF prioritizes the authentication request for the UE registration procedure.

In embodiments described herein therefore the service request invoking a microservice chain may be scheduled dynamically in each microservice of the chain according to a dynamically modified latency requirement based on the remaining service chain of the service request.

<FIG> illustrates an example of a microservice chain architecture. The service <NUM> comprises a chain of microservices 301a to 301e. A request for the service from a client may invoke a microservice call sequence to implement each of the microservices 301a to 301e. A SCPR (Service Chain Procedure Repository) <NUM> may be used to store Service Chain Procedures (SCPs) associated with different services (for example, the type of request).

A Service Chain Procedure for a service (or a type of request) may comprise the sequence of microservices for that service. The Service Chain Procedure may also comprise information relating to a step latency associated with each step in the sequence of microservices, wherein a step comprises one of a microservice in the sequence or a hop between pair of adjacent microservices in said sequence. The SCP may also comprise information relating to a latency requirement associated with the sequence of microservices.

An example Service Chain Procedure may be given as:.

The sequence of microservices may be determined by analyzing the internal logic of the service for each type of request. Usually the sequence of microservices is static when the service is implemented and may only need be changed when the internal structure and interfaces of the service is changed.

The estimated latency for each step in the sequence of microservices may be generated by a monitoring function <NUM>, which may consistently monitor the latency introduced in each microservice and the latency between two microservices.

The monitoring function <NUM> may therefore be configured to monitor one or more microservices (for example microservice 301a to 301e) to obtain the information relating to a step latency associated with each step in at least one sequence of microservices, wherein a step comprises one of a microservice or a hop between pair of adjacent microservices in said sequence. The monitoring function <NUM> may also then be configured to transmit the information to the SCPR <NUM>.

The SCPR <NUM> may retrieve the latest estimated latency for all stored Service Chain Procedure from the Monitoring Function <NUM>. The information relating to the estimated latencies may be obtained periodically, or may be obtained responsive to a new service request, or any other suitable method.

The microservices 301a to 301e within the service <NUM> may retrieve the Service Chain Procedure (SCP) from the SCPR <NUM> and may synchronize with the SCPR <NUM> periodically.

The SCPR <NUM> may therefore be configured to receive a sequence request from a first microservice (for example microservice 301a), wherein the sequence request comprises a type of request. The type of request may for example indicate the service <NUM>. The SCPR <NUM> may then select a first sequence from one or more stored sequences, wherein the first sequence is associated with the type of request. For example, the SCPR <NUM> may select the SCP associated with the service indicated in the sequence request.

The SCPR <NUM> may then transmit the first sequence (for example, the SCP) to the first microservice.

<FIG> illustrates a microservice <NUM> in a service <NUM>.

In this example, the microservice <NUM> comprises several functions: a scheduler <NUM>, Processing Queue (PQ) <NUM>, Processing Function (PF) <NUM>, Routing Function (RF) <NUM>, Synchronization Function (SF) <NUM>, and Local Repository <NUM>. These functions shown in the figure may be contained within each microservice in the sequence.

It will be appreciated that the functional blocks illustrated in <FIG> may be implemented differently, and that different steps of the method described below in <FIG> may be implemented by one or more of the functional blocks, or additional functional blocks.

<FIG> illustrates a method performed by a microservice, for example the microservice <NUM> illustrated in <FIG>.

In step <NUM>, the microservice receives a processing request to provide a first processing function. For example, the processing request may be received at the scheduler <NUM>. The first processing function may be the function performed by the Processing Function <NUM>.

In step <NUM> the microservice obtains a sequence of a plurality of microservices associated with the processing request, wherein the sequence comprises the first microservice.

Step <NUM> may for example comprise the scheduler <NUM> transmitting a sequence request to a local repository comprising a type of request associated with the processing request; and receiving the sequence from the local repository. For example, the scheduler <NUM> may retrieve an SCP from the local repository <NUM>. The local repository <NUM> may be updated by the Synchronization Function <NUM>, which may receive the SCPs from the SCPR <NUM>. The updates from the SCPR may, for example, be received periodically, or when there is some change to an SCP that the SCPR <NUM> reports to the local repository <NUM>.

The SCPs received from the SCPR <NUM> may be SCPs that are in use by the local repository <NUM>. For example, if the local repository <NUM> has not received a sequence request from the scheduler for a type of request associated with a particular SCP for a predetermined period of time, it may signal to the SCPR to stop updating that particular SCP.

Also, if the local repository <NUM> receives a sequence request for a type of request associated with an SCP that has not been updated for a predetermined period of time, or that the local repository does not have stored, the local repository <NUM> may retrieve the SCP from the SCPR <NUM>.

In step <NUM>, the microservice obtains a current latency requirement associated with the remaining microservices in the sequence. For example, the current latency requirement may be obtained based on a previous latency requirement that may form part the processing request. For example, the current latency requirement may indicate a latency requirement or target associated with the remainder of the microservices in the sequence including the current microservice. This may be calculated from the previous latency requirement which was the determined current latency requirement by the previous microservice in the sequence (or the original total latency requirement). The previous latency requirement may be received as a field in the processing request.

In step <NUM>, the microservice obtains an estimated latency associated with the remaining microservices in the sequence. For example, the estimated latency associated with the remaining microservices in the sequence may be calculated (for example by the scheduler <NUM>) from the information in the SCP relating to the estimated latency associated with each step in the sequence. An example of how the estimated latency associated with the remaining microservices may be obtained is described in more detail with reference to <FIG> below.

In step <NUM>, the microservice places the processing request in a processing queue based on a comparison between the current latency requirement and the estimated latency. For example, the scheduler <NUM> may place the processing request in the Processing Queue <NUM>.

The scheduler <NUM> may therefore be configured to receive the processing request either from a user or application directly or from a previous microservice in the sequence, and may then schedule the processing request into the Processing Queue <NUM> according the priority of the processing request which may be determined based on one or more conditions.

The microservice may then also process requests in the processing queue by providing the first processing function to requests in the processing queue in an order according to priority of the processing requests in the processing queue.

In some embodiments, the Processing Queue <NUM> may comprise several queues which have different priorities to be processed by the Processing Function (PF). The PF is the function that process the processing request by performing the first processing function, and for each microservice, the function performed by the processing function <NUM> may be different.

As each microservice may have multiple instance running in the cloud platform, if the current microservice need call another microservice, the Routing Function (RF) <NUM> may be responsible for choosing a running instance of the next microservice in the sequence.

In order for the microservice to determine the current latency requirement and the estimated requirement, a number of additional fields may be included in the processing request. For example, the processing request may comprise fields indicating: the type of request, the previous latency requirement, and a timestamp. The type of request indicates the type of the current service request which can be used to retrieve the SCP as described above. The type of request may be set once by either an application or user, or by an entry microservice, i.e., the first microservice in the sequence that serves the request. The previous latency requirement denotes the desired maximum latency for remainder of the sequence of microservices. It is set by the entry microservice initially (as the total latency requirement which may be obtained as part of the SCP), and may be dynamically adjusted by the following serving microservices in the sequence. The timestamp denotes the time when each microservice receives the request. It may be assumed the time clock at each microservice is synchronized by protocols for example Network Time Protocol (NTP).

<FIG> and <FIG> illustrate an example of the scheduling and processing of a processing request by a microservice.

In step <NUM>, a processing request is received. As previously described the processing request may be received from a user or application (for example, where the receiving microservice is the first microservice in the sequence), or from a previous microservice in the sequence.

In step <NUM>, the scheduler reads the type of request, previous latency requirement and the timestamp from the processing request.

In step <NUM>, the scheduler transmits a sequence request to the local repository comprising the type of request read from the processing request in step <NUM>. As previously mentioned, the local repository may retrieve the SCP from the SCPR <NUM> if the stored SCP is not up to date, or is missing. In some cases, there may be no corresponding SCP for the type of request, and default policies may be used to schedule the processing request into the processing queue <NUM> in step <NUM>.

In step <NUM>, the scheduler <NUM> reads the SCP retrieved in step <NUM>.

In step <NUM>, the scheduler <NUM> may calculate an elapsed time by comparing the timestamp to a current time.

For example, the scheduler <NUM> may calculate the elapsed time (Le) for the received processing request as the difference between the timestamp (Tt) and the current time according to the microservice (Tc), which could be denoted as Le = Tc - Tt.

In examples where the microservice receiving the processing request is the first microservice in the sequence, the elapsed time may be zero.

In step <NUM>, the scheduler <NUM> may calculate the current latency requirement (Lr_C). If the microservice receiving the processing request is the first microservice in the sequence then the current latency requirement may be set equal to the total latency requirement Lr in the SCP. Otherwise, the current latency requirement (Lr_C) may be calculated as Lr, c = Lr_p - Le, in which Lr_p is the previous latency requirement read from the processing request in step <NUM>.

In step <NUM> the scheduler <NUM> may updating the processing request by updating the previous latency requirement field with the value of the current latency requirement calculated in step <NUM>. The scheduler <NUM> may also update the timestamp field in the processing request with the current time.

In step <NUM>, the scheduler <NUM> calculates the estimated latency (Ltes). In particular, as previously mentioned, the sequence (e.g. to SCP) comprises an indication of a step latency associated with each step in the sequence, wherein a step comprises one of a microservice or a hop between pair of adjacent microservices in the sequence.

Step <NUM> may therefore comprise calculating a sum of the step latencies associated with each remaining step in the sequence. For example, for the SCP:
{p1, rt, Lr, (s1, s2, s4), (<s1, <NUM>>, <s1-s2, <NUM>>, <s2, <NUM>>, <s2-s4, <NUM>>, <s4, <NUM>>)}.

If the current microservice is s2, then the remaining steps in the sequence are: <s2, <NUM>>, <s2-s4, <NUM>>, <s4, <NUM>>.

Therefore the estimated latency associated with the remainder of the sequence (Ltes) in this example is <NUM>.

In step <NUM>, the scheduler <NUM> places the processing request in the processing queue <NUM>.

For example, the scheduler may schedule the request based on the calculated values of Lr,c, Ltes and the type of the Processing Queue. For example, the Processing Queue may comprise a multi-level queue, in other words, a queue with a pre-defined number of levels. The processing request may then be assigned a particular level or priority. Each level of the processing queue <NUM> may use its own scheduling for example, a round-robin.

For example, if the Processing Queue is a three-level queue (q1, q2, q3), in which q3 has the highest priority, and q1 has the lowest priority.

The scheduler may calculate a value delta, Δ, where Δ = (Lr,c - Ltes)/ Lr,c. The scheduler may then, position the processing request in the processing queue based on the value of delta. In some examples, the scheduler may position the processing request with higher priority in the processing queue with increasing delta.

In this example, if |Δ|< µ , then the processing request may be assigned to level q2, i.e., the middle level; if Δ ≥ µ, the processing request may be assigned to level q1; if Δ ≤ - µ, the processing request may be assigned to level q3. µ may be a predefined parameter, e.g., it may be set to <NUM>.

For example, if microservice s2 receives a processing request whose SCP is {p1, t1, <NUM>, (s1, s2, s4), (<s1, <NUM>>, <s1-s2, <NUM>>, <s2, <NUM>>, <s2-s4, <NUM>>, <s4, <NUM>>)}, The measured elapsed latency (Le) from s1 to s2 is <NUM>, then the new latency requirement Lr_c = Lp,r - Le = <NUM>. The total estimated latency (Lte) of the remaining sequence is <s2> + <s2-s4> + <s4> = <NUM>. Thus, in this example, Δ = -<NUM>, if µ is set to <NUM>, the processing request may be assigned to level q3 which has the highest priority.

It will be appreciated that other types of queue and other scheduling algorithms may be used.

In step <NUM>, the queue provides the processing requests in the processing queue to the processing function <NUM> to be processed in an order according to priority in the processing queue. For example, in the example described above, the processing queue may provide requests in the queue q3 to the processing function to be processed before providing the processing requests in the queue q2. Similarly, the processing requests in the queue q2 may be processed before the requests in q1.

In step <NUM>, the processing function <NUM> handles the processing request. For example, the processing function <NUM> may perform the first processing function.

In step <NUM> the processing function <NUM> determines whether there are any further microservices in the sequence. If there are no further microservices in the sequence, the method passes to step <NUM> in which the processing ends and a reply can be sent to the user or application on completion of the service.

If there are further microservices in the sequence, the method passes to step <NUM> in which, the processing function <NUM> updates the processing request to generate an updated processing request with the appropriate field values as set in step <NUM>.

In step <NUM> the updated processing request is sent to the routing function <NUM>.

In step <NUM>, the routing function <NUM> selects a running instance of the next microservice in the sequence, for example, according to pre-defined routing and load balancing policies. Optionally, the routing function <NUM> may also select the instance according to the calculated value of Δ. For example, if Δ < <NUM>, the routing function <NUM> could select a running instance that has less than average estimated latency between it and the current microservice instance.

In step <NUM>, the routing function <NUM> transmits the updated processing request to the selected instance of the next microservice in the sequence.

<FIG> illustrates a computer system <NUM> comprising processing circuitry (or logic) <NUM>. The processing circuitry <NUM> controls the operation of the computer system <NUM> and can implement the method described herein in relation to a first microservice. The processing circuitry <NUM> can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the computer system <NUM> in the manner described herein. In particular implementations, the processing circuitry <NUM> can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the first microservice.

Briefly, the processing circuitry <NUM> of the computer system <NUM> is configured to: receive a processing request to provide the first processing function; obtain a sequence of a plurality of microservices associated with the processing request, wherein the sequence comprises the first microservice; obtain a current latency requirement associated with the remaining microservices in the sequence; obtain an estimated latency associated with the remaining microservices in the sequence; place the processing request in a processing queue based on a comparison between the current latency requirement and the estimated latency.

In some embodiments, the computer system <NUM> may optionally comprise a communications interface <NUM>. The communications interface <NUM> of the microservice <NUM> can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface <NUM> of the computer system <NUM> can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar. The processing circuitry <NUM> of the computer system <NUM> may be configured to control the communications interface <NUM> of the computer system <NUM> to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.

The computer system <NUM> comprises a memory <NUM> containing the first microservice which, when executed by the processing circuitry instructs the processing circuitry to perform the steps described above. In some embodiments, the memory <NUM> of the computer system <NUM> can be configured to store program code that can be executed by the processing circuitry <NUM> of the microservice <NUM> to perform the method described herein in relation to the microservice <NUM>. Alternatively or in addition, the memory <NUM> of the computer system <NUM>, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry <NUM> of the computer system <NUM> may be configured to control the memory <NUM> of the computer system <NUM> to store any requests, resources, information, data, signals, or similar that are described herein.

<FIG> illustrates a SCPR <NUM> comprising processing circuitry (or logic) <NUM>. The processing circuitry <NUM> controls the operation of the SCPR <NUM> and can implement the method described herein in relation to an SCPR <NUM>. The processing circuitry <NUM> can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the SCPR <NUM> in the manner described herein. In particular implementations, the processing circuitry <NUM> can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the SCPR <NUM>.

Briefly, the processing circuitry <NUM> of the SCPR <NUM> is configured to: store at least one sequence of microservices; and store information relating to a step latency associated with each step in each sequence of microservices, wherein a step comprises one of a microservice in the sequence or a hop between pair of adjacent microservices in said sequence.

In some embodiments, the SCPR <NUM> may optionally comprise a communications interface <NUM>. The communications interface <NUM> of the SCPR <NUM> can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface <NUM> of the SCPR <NUM> can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar. The processing circuitry <NUM> of the SCPR <NUM> may be configured to control the communications interface <NUM> of the SCPR <NUM> to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.

Optionally, the SCPR <NUM> may comprise a memory <NUM>. In some embodiments, the memory <NUM> of the SCPR <NUM> can be configured to store program code that can be executed by the processing circuitry <NUM> of the SCPR <NUM> to perform the method described herein in relation to the SCPR <NUM>. Alternatively or in addition, the memory <NUM> of the SCPR <NUM>, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry <NUM> of the SCPR <NUM> may be configured to control the memory <NUM> of the SCPR <NUM> to store any requests, resources, information, data, signals, or similar that are described herein.

<FIG> illustrates a monitoring function <NUM> comprising processing circuitry (or logic) <NUM>. The processing circuitry <NUM> controls the operation of the monitoring function <NUM> and can implement the method described herein in relation to an monitoring function <NUM>. The processing circuitry <NUM> can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the monitoring function <NUM> in the manner described herein. In particular implementations, the processing circuitry <NUM> can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the monitoring function <NUM>.

Briefly, the processing circuitry <NUM> of the monitoring function <NUM> is configured to: monitor one or more microservices to obtain information relating to a step latency associated with each step in at least one sequence of microservices, wherein a step comprises one of a microservice or a hop between pair of adjacent microservices in said sequence; and transmit the information to a service call procedure repository.

In some embodiments, the monitoring function <NUM> may optionally comprise a communications interface <NUM>. The communications interface <NUM> of the monitoring function <NUM> can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface <NUM> of the monitoring function <NUM> can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar. The processing circuitry <NUM> of the monitoring function <NUM> may be configured to control the communications interface <NUM> of the monitoring function <NUM> to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.

Optionally, the monitoring function <NUM> may comprise a memory <NUM>. In some embodiments, the memory <NUM> of the monitoring function <NUM> can be configured to store program code that can be executed by the processing circuitry <NUM> of the monitoring function <NUM> to perform the method described herein in relation to the monitoring function <NUM>. Alternatively or in addition, the memory <NUM> of the monitoring function <NUM>, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry <NUM> of the monitoring function <NUM> may be configured to control the memory <NUM> of the monitoring function <NUM> to store any requests, resources, information, data, signals, or similar that are described herein.

Embodiments described herein therefore provide methods and apparatuses for providing a first processing function in a first microservice. In particular, the methods and apparatuses described herein allow for dynamically prioritizing the processing requests based on the real time measured latency and estimated latency together, so that the latency requirement for the processing requests can be better fulfilled in each microservice in the sequence. The proposed mechanism may also be applied to other chain-based services in addition to microservice based services. The proposed mechanism may also be applied to service mesh based microservices.

Claim 1:
A method performed by a first microservice (<NUM>) capable of providing a first processing function in a service comprising a plurality of microservices, the method comprising:
receiving (<NUM>) a processing request to provide the first processing function;
retrieving (<NUM>) a sequence of a plurality of microservices associated with the processing request from a local repository, said local repository (<NUM>) being updated by a Service Chain Procedure Repository (<NUM>), wherein the sequence comprises the first microservice;
obtaining (<NUM>) a current latency requirement associated with the remaining microservices in the sequence;
obtaining (<NUM>) an estimated latency associated with the remaining microservices in the sequence; and
placing (<NUM>) the processing request in a processing queue (<NUM>) based on a comparison between the current latency requirement and the estimated latency, thereby scheduling the processing request into the processing queue according to a priority of the processing request for processing by a processing function (<NUM>).