EP2919438B1 - Method and system to estimate user desired delay for resource allocation for mobile-cloud applications - Google Patents
Method and system to estimate user desired delay for resource allocation for mobile-cloud applications Download PDFInfo
- Publication number
- EP2919438B1 EP2919438B1 EP14158553.9A EP14158553A EP2919438B1 EP 2919438 B1 EP2919438 B1 EP 2919438B1 EP 14158553 A EP14158553 A EP 14158553A EP 2919438 B1 EP2919438 B1 EP 2919438B1
- Authority
- EP
- European Patent Office
- Prior art keywords
- delay
- desired delay
- task
- user
- mobile device
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims description 53
- 238000013468 resource allocation Methods 0.000 title claims description 46
- 238000012545 processing Methods 0.000 claims description 31
- 230000008569 process Effects 0.000 claims description 13
- 238000013507 mapping Methods 0.000 claims description 6
- 230000000694 effects Effects 0.000 claims description 4
- 238000003066 decision tree Methods 0.000 claims description 3
- 230000008447 perception Effects 0.000 claims description 3
- 238000012706 support-vector machine Methods 0.000 claims description 3
- 230000004807 localization Effects 0.000 claims description 2
- 238000005259 measurement Methods 0.000 claims description 2
- 230000004044 response Effects 0.000 description 10
- 238000013459 approach Methods 0.000 description 8
- 238000013480 data collection Methods 0.000 description 8
- 238000010801 machine learning Methods 0.000 description 8
- 230000003993 interaction Effects 0.000 description 7
- 230000007423 decrease Effects 0.000 description 6
- 230000006399 behavior Effects 0.000 description 4
- 230000001934 delay Effects 0.000 description 4
- 238000010586 diagram Methods 0.000 description 4
- 238000009877 rendering Methods 0.000 description 4
- 230000008859 change Effects 0.000 description 3
- 230000008713 feedback mechanism Effects 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 238000012549 training Methods 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 230000003247 decreasing effect Effects 0.000 description 2
- 239000000284 extract Substances 0.000 description 2
- 241001161843 Chandra Species 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000018109 developmental process Effects 0.000 description 1
- 230000007613 environmental effect Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/2866—Architectures; Arrangements
- H04L67/30—Profiles
- H04L67/306—User profiles
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/02—Protocol performance
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W24/00—Supervisory, monitoring or testing arrangements
- H04W24/02—Arrangements for optimising operational condition
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/02—Terminal devices
Definitions
- the invention relates to a method and system for user desired delay estimation for mobile-cloud applications and a method and system for resource allocation.
- US 2011/004574 A1 discloses a method for dynamically allocating cloud resources for executing portions of a mobile application using cloud resources.
- a mobile device monitors and collects device and application parameters (runtime, sensor, device information) and using a cost model, generates a cost objective which it uses to determine whether to offload the portions of the application to the cloud.
- US8656284 B2 discloses a mechanism for inferring Quality of Experience, QoE, on a mobile device using subjective and objective metrics by monitoring user behaviour and quality of service parameters including delay.
- the object of the present invention is to provide a method and system for user desired delay estimation for mobile-cloud applications and a method and system for resource allocation. This object is achieved with the features of the independent claims.
- the dependent claims relate to further aspects of the invention.
- a method for user desired delay estimation for mobile-cloud applications comprises the steps of collecting data for a mobile application using at least one of sensors, application logger and user feedback module of a mobile device, inferring the quality of experience based on the collected data, determining the desired delay by taking the quality of experience and optionally some additional statistical data based on the collected data into account, and offloading a task to the cloud together with a corresponding desired delay.
- the quality of experience is measured by subjective rating from users, e.g. by using the graphic Self-Assessment Manikin (SAM) to collect subjective rating.
- SAM graphic Self-Assessment Manikin
- the collected data preferably comprise subjective and objective data.
- the subjective data includes at least one of refreshment frequency and refresh time stamp, from a user interaction feedback module.
- the objective data includes at least one of locations, network access, signal strength, system running time, active time stamp, and offloading delay, from sensors and application logger.
- determining the desired delay applies nonparametric methods and more preferably decision tree or K-nearest neighbor classifier or linear discrimination or multilayer perceptions or support vector machine either as a two-class classification or a multiple class classification.
- a method for resource allocation comprises the steps of receiving a task to be executed along with a corresponding desired delay from a mobile device, determining a resource allocation strategy based on the desired delay and the task to be processed, and executing the task using the allocated resources and sending the result to the mobile device.
- the step of determining a resource allocation strategy further comprises determining whether the desired delay can be met with the current resources.
- the desired delay is disregarded and the task may still be executed with the available resources, if the desired delay cannot be met.
- determining of a resource allocation strategy is based on a self-learning process, wherein processing time on server analysis, delay estimation, elapsed time measurement and a table mapping the delay to resource allocation is used.
- the self-learning process may change the items of the table mapping the delay to resource allocation according to the feedback of server processing time.
- a system for user desired delay estimation for mobile-cloud applications comprises a mobile device, an application framework on the mobile device, that is configured to collect data from a mobile application using at least one of sensors, application logger and user feedback module of the mobile device, to infer the quality of experience for users using the collected data, to estimate a desired delay based on the inferred quality of experience, and to offload a task to the cloud together with a corresponding desired delay.
- the mobile device further comprises a GPS module and a WiFi module configured to collaborate for outdoor and for indoor localization.
- system further comprises a database memory configured to store therein records linking to user registrations including at least one of user's activities, locations, signal strength, system running time, network access, active time stamp, offloading delay, quality of experience.
- the mobile device may be configured to remotely access the server.
- a system for resource allocation comprising at least one server containing abundant computing resources being configured to receive a task to be executed along with a corresponding desired delay from a mobile device, to determine a resource allocation strategy based on the desired delay and the task to be processed, to execute the task using the allocated resources and to send the result to the mobile device.
- the at least one server is configured to self-learn and update the resource allocation strategy based on delay feedback.
- the at least one server is further configured to send deny of service messages to the application framework on mobile devices when the server does not have enough resources to support the desired delay.
- the task may still be executed with the remaining resources, when the desired delay cannot be executed.
- the present invention is the first work to optimize the resource allocation with respect to the quality of user experience. Therefore, it exploits a completely new solution to compromise the delay and user's experience.
- the present invention allows compromising the delay and resource allocation by the fact that the quality of experience is highly contrived.
- the image search application returns all images containing the user's face. Different users have different satisfying delays. User A does not need the result very soon so that he puts the mobile device into his pocket. While user B cannot wait to get the result, he checks the processing frequently. Hence, the quality of experience between user A and B will be different with the same application delay. Therefore, applications could have their own desired delay for different users. To this end, wisely determining a suitable desired delay would be an attractive solution to compromise the delay and resource allocation. In the above example, user A could tolerate longer delay. Thus, when the computing resource is limited, the system allocates fewer resources for user A and more for user B to satisfy both of them.
- the present invention provides a system and method to dynamically determine a desired delay for users in order to maximize the overall quality of user's experience.
- the invention disclosed and claimed herein provides a system for desired delay estimation of mobile applications.
- the system may include two components on the application and the cloud.
- the system is to dynamically determine a suitable desired delay for users using machine-learning mechanism and second to control the application delay close to the desired delay.
- the system collects subjective and objective data through a feedback mechanism and sensors.
- the machine-learning block uses the collected data, the machine-learning block outputs a desired delay.
- the application sends the desired delay along with the offloading request to the cloud and the system components in the cloud control the application delay close to the desired delay by adjusting the resource allocation strategy.
- a suitable desired delay for each user allows application developers optimally utilize their computing resources such as CPU, memory, etc.
- the desired delay depends on not only user's objective parameters but also user's subjective parameters. Combining these parameters can help to make a decision for adjusting the desired delay by machine-learning methods.
- QoE quality of experience
- QoS quality of service
- the graphic Self-Assessment Manikin might be employed to collect subjective rating.
- the system uses the measured QoE and other factors (e.g., application running time, user complain frequency, etc.) to make a decision whether the desired delay should be increased or decreased by applying a machine-learning mechanism.
- the application sends the offloading request incorporating the decision on the desired delay to the cloud. Then the cloud coordinates the communication, processes tasks and returns the results.
- the system of the present invention is a framework that supports task offloading with dynamic desired delay for mobile-cloud applications.
- Application developers need to create their applications following some principles of the system according to the invention for taking advantage of the present system. The principles depend on the implementation, which will be discussed in detail later.
- FIG. 1 illustrates a system 100 that enables dynamic desired delay.
- the system 100 comprises a first sub-system 100a which can be a mobile device of a user and a second sub-system 100b which is located in the cloud.
- the first sub-system 100a comprises a data collection component 101, an inferring Quality of experience component 102, a desired delay estimator 103 and a first offloading controller 104. It further comprises a local processing and rendering component 105.
- the first sub-system 100a may further comprise units usually present in a mobile device in particular a screen and/or an application interface (not shown).
- the first sub-system 100a can collect data through the data collection component 101. Based on the collected data, component 102 infers the QoE of users. QoE is an important parameter to determine the desired delay.
- the desired delay estimator 103 generates a desired delay based on QoE and some statistical data, i.e. user implicit feedback and subjective rating. The implicit feedback might include user's interaction with the application interface and user's free touching behaviors on the screen when running the application.
- the first offloading controller 104 makes decisions whether to offload execution of a task, or to allow it to continue locally on the mobile device 100a. If the offloading controller 104 decides to offload the task, it sends a request incorporating the desired delay to the cloud 100b for remotely processing the task.
- the second sub-system 100b comprises a second offloading controller 106, a dynamic delay controller 108, a cloud processing component 107 and a resource allocator 109.
- the second offloading controller 106 in the cloud receives the request and extracts the desired delay to the dynamic delay controller 108.
- the dynamic delay controller 108 learns and stores a table mapping desired delay to resource allocation. For example, it is desired to accomplish a task A within 100 milliseconds. Dynamic delay controller 108 searches the table to get an item showing that 100-200 ms for task type A needs 1 CPU and 40MB memory. Then, dynamic delay controller 108 hands in the resource allocation strategy to the resource allocator 109. The resource allocator allocates resources for processing the task. Finally, the cloud processing component 107 accomplishes the task and sends the result as a response to the mobile device 100a. The local processing and rendering component 105 receives the response and starts to process or render it.
- the application running with system 100 preferably provides a feedback mechanism for users.
- the system collects user's operations as well as delays to build a model for predicting user's desired delay. Thus, the system makes future decisions on the desired delay according to these data.
- the system does not require users to provide subjective survey; it collects implicit feedback like user's operations or interactions with an application.
- the desired delay prediction is therefore transparent to users, in that it does not change the way that users commonly use the application.
- FIG. 2 illustrates the data collection component 101 of the system in accordance with an aspect of the present invention. It collects data from system components, i.e. in this example a user interaction feedback component 201, sensors 202 and an application logger 203.
- the user feedback component 201 periodically surveys user's opinion and behavior.
- a refresh button for an image processing application can be provided.
- the button response could be either the result or an under processing message.
- the refresh frequency can be obtained.
- the refresh frequency (the ratio of press times and the time period) is capable of inferring user's QoE. This can be used as a subjective factor in estimating the desired delay. Therefore, user interaction feedback component 201 records the refresh frequency for learning.
- Sensors 202 collect objective data such as location, network access, signal strength, etc.
- Application logger 203 records system running time, active time stamp (the time when user activates the application) and offloading delay. The offloading delay can be used to validate the effectiveness of the system. If the delay is longer than the desired value, the event is recorded as a failure. In contrast, when a too short delay compared with the desired value is detected, the event is recorded as overestimated. Thus, the system tries to allocate more resources for the failure and less for the overestimated.
- Data collection component 101 sends the collected data to inferring QoE component 102 for inferring user's QoE.
- QoE component 102 To implement QoE component 102 several existing approaches can be used.
- IQX hypothesis Fiedler, Markus and Hossfeld, Tobias and Tran-Gia, Phuoc: A generic quantitative relationship between quality of experience and quality of service, IEEE, Network, volume 24, page 36-41, 2010 ).
- the formula relates changes of QoE with respect to QoS to the current level of QoE, it is simple to match, and its limited behaviors are straightforward to interpret.
- inferring QoE component 102 calculates the QoE directly from QoS parameters (collected by sensors 202).
- the system will take the QoE, user statistical data (collected by application logger 203) and user's subjective feedback (collected by interaction feedback component 201) to perform a machine-learning method in the desired delay estimator 103.
- FIG. 3 illustrates an example of the desired delay estimator 103.
- the desired delay estimator 103 comprises a data formatting component 301 and a machine-learning component 302.
- the desired delay estimator 103 receives input data from the inferring QoE component 102. It transmits data in particular the desired delay to the first offloading controller 104.
- data formatting component 301 preferably converts the raw input into different data file formats.
- the implementation of the machine learning component 302 is flexible. It depends on the input data features and sizes. QoE and user's subjective feedback are highly contrived. It is difficult to find a probabilistic model fitting the data. Therefore, the system adopts nonparametric methods to learn the data such as decision tree, K-nearest neighbor classifier, linear discrimination, multilayer perceptrons, support vector machine.
- a 0-1 classifier (0 means the desired delay should increase, 1 means it should decrease) could be implemented.
- the increase/decrease step is preferably about 10 milliseconds. It is very easy to extend the two classes (0-1) to multiple classes, e.g. using classifications like very fast, fast, normal, slow, and very slow with corresponding increase/decrease steps.
- desired delay estimator 103 could assigns label 0 (increase the delay) by default.
- desired delay estimator 103 labels the current decision 1. For example, desired delay estimator 103 collects and maintains a recent week's data as the training data set. Later, desired delay estimator 103 makes the increase/decrease decision using the training data.
- the system may set an upper bound as the delay with minimum resource processing.
- the system may be set to a standard delay (depends on tasks) if the current desired delay is greater than the standard delay. The system decreases the desired delay, for example by 10 milliseconds, if the current desired delay is less than or equal to the standard delay.
- the first offloading controller 104 can be implemented by existing techniques such as ThinkAir ( Kosta, Sokol and Aucinas, Andrius and Hui, Pan and Mortier, Richard and Zhang, Xinwen. Thinkair: Dynamic resource allocation and parallel execution in the cloud for mobile code offloading, Proceedings of INFOCOM, 2012 ), MAUI ( Cuervo, Eduardo and Balasubramanian, Aruna and Cho, Dae-ki and Wolman, Alec and Saroiu, Stefan and Chandra, Ranveer and Bahl, Paramvir.
- ThinkAir Kosta, Sokol and Aucinas, Andrius and Hui, Pan and Mortier, Richard and Zhang, Xinwen.
- Thinkair Dynamic resource allocation and parallel execution in the cloud for mobile code offloading, Proceedings of INFOCOM, 2012
- MAUI Cuervo, Eduardo and Balasubramanian, Aruna and Cho, Dae-ki and Wolman, Alec and Saroiu, Stefan and Chandra, Ranveer and Bahl, Paramvir
- MAUI making smartphones last longer with code offload, Proceedings of MobiSys, 2010 ) or CloneCloud ( Chun, Byung-Gon and Ihm, Sunghwan and Maniatis, Petros and Naik, Mayur and Patti, Ashwin. Clonecloud: elastic execution between mobile device and cloud, Proceedings of EuroSys, 2011 ).
- the controller decides whether to offload execution of a particular method, or to allow it to continue locally on the mobile device. The decision depends on data collected about the current environment as well as that learnt from past executions. As an example, ThinkAir implementation is chosen here.
- the controller 104 When a task is encountered for the first time, it is unknown to the first offloading controller 104 and so the decision is based only on environmental parameters such as network quality: for example, if the connection is of type WiFi, and the connectivity is strong, the controller is likely to offload the task. On a low quality connection, the task is likely to be executed locally. The controller combines the desired delay and the offload request and sends both to the cloud if it decides to offload.
- the second offloading controller 106 is to manage client (mobile device 100a) connections. If the client application is unknown to the application server, the second offloading controller 106 retrieves the application from the client, and loads any required class definitions and native libraries. It also responds to application-level ping messages sent by the first offloading controller 104 to measure connection latency. Following the initial connection set up, the server waits to receive execution requests from the client.
- FIG. 4 illustrates an example of a dynamic delay controller 108.
- the dynamic delay controller 108 comprises a self-learning component 401 and an allocation strategy table component 402.
- the dynamic delay controller 108 receives input data, such as search keys from the second offloading controller 106 and feedback from the cloud processing component 107.
- the dynamic delay controller 108 learns from historical statistic data and determines a suitable resource allocation strategy based on the desired delay. Initially, the table in the dynamic delay controller 108 contains only one item: mapping the default desired delay value to a resource allocation strategy. The default desired delay is unknown actually because initially the system has no knowledge of the processing load for different types of applications. Therefore, the system simply sets a default resource allocation strategy for all applications.
- the dynamic delay controller 108 self-learns the delay by the feedback of the cloud processing component 107, which is the processing time on the server for the task. However, the server processing time is only one part of the application delay.
- One way to implement the dynamic delay controller 108 is using the existing technique Timecard ( Ravindranath, Lenin and Padhye, Jitendra and Mahajan, Ratul and Balakrishnan, Hari: Timecard: controlling user-perceived delays in server-based mobile applications, Proceedings of SOSP, 2013 ). It provides two abstractions: the first returns the time elapsed since the user started the request, and the second returns an estimate of the time it would take to transmit the response from the server to the client and process the response at the client.
- the server can adapt its processing time to control the end-to-end delay for the request exploiting resource allocation techniques.
- the dynamic delay controller 108 could learn a resource allocation strategy for the future, recording the corresponding delay of the resource allocation strategy. The strategy could be updated accordingly.
- the resource allocator 109 can be implemented by existing resource allocation techniques. To make the cloud infrastructure easily maintainable and to keep the execution environment homogeneous, a virtualization environment is typically used, allowing the system to be deployed where needed. There are many suitable virtualization platforms available, e.g., Xen, QEMU and VirtualBox. It is preferable to pre-configure a few types of VMs (virtual machines) in common use so that the resource allocation to tasks can be managed in terms of different types of VMs. This is more efficient and effective. For example, the system can have 4 types of VMs with different configurations of CPU and memory: (1 CPU, 256MB), (1 CPU 512MB), (2 CPU, 1024MB) and (4 CPU, 1024MB). When the dynamic delay controller 108 asks for 2 CPU and 512MB memory, the resource allocator 109 allocates 2 VMs with 1 CPU and 256MB memory.
- the resource allocator 109 sends back a warning signal to the dynamic delay controller 108 showing that it fails to allocate the resource. Then the dynamic delay controller 108 will change the allocation strategy accordingly.
- the system might send a deny-of-service message to the application framework of the mobile device. For example, a task would require 3 CPUs and 100 MB memory to meet the desired delay. However, the cloud can only provide 1 CPU and 10 MB memory. Then the server sends a deny message to the mobile device. Next, the cloud disregards the desired delay and tries in a best effort approach to execute the task without the desired delay guarantee. The cloud may reallocate resources for next requests depending on the overall desired delay situation for all users.
- the cloud processing component 107 is responsible for executing tasks. It coordinates VMs and combines results as an output. Finally, it sends the output as a response to the local processing and rendering component 105. After receiving the response, the local processing and rendering component 105 processes and renders the result in the response. The process and render method depends on the corresponding processes.
- FIG. 5 illustrates the workflow of applications using the first sub-system 100a in mobile devices.
- the data collection component 101 collects data from application logger (e.g., application running time, application delay, i.e. the desired delay, request time, response time), sensors (e.g., location, light, temperature, noise), and user interaction feedback (e.g., refresh time, shutdown time, reactivate time).
- step 501 obtains the QoE through the inferring QoE component 102.
- Step 502 activates the desired delay estimator.
- step 503 makes a decision whether to offload the task or to process locally with the data from the data collection component 101 and the output of step 502.
- the first offloading controller 104 sends the offloading request to the cloud and waits for the response as long as the decision is yes. Otherwise, step 504 activates local processing and returns some statistical data to the data collection component 101 for future work.
- FIG. 6 illustrates the workflow of the second sub-system 100b in the cloud.
- the server is waiting for a request.
- Step 601 receives and extracts the request.
- Step 602 makes a decision whether to offload or to reject the request based on the current state of the cloud such as the remaining resource, and/or network problems and so on. If no, the second offloading controller 106 sends a reject reply to the mobile device. If yes, step 603 uses the desired delay to search for a resource allocation strategy as the output. If no such item can be obtained, step 603 selects a default allocation strategy.
- Step 604 receives the output of step 603, and then deploys different types of VMs based on the use of resource allocation techniques.
- step 605 is to confirm the feasibility of resource allocation strategy. If it is not feasible due to inadequate resources, step 607 sends a report to the dynamic delay controller 108 for changing the resource allocation strategy and updating the table. If it is feasible, step 606 activates the allocated VMs and processes the tasks. Finally, the cloud processing component 107 sends the calculated result back to the mobile devices.
- a mobile-cloud system that can estimate user desired delay for mobile-cloud applications is provided. Furthermore, a method that can collect data reflecting user experience is provided. The method can learn from the collected data to determine a suitable desired delay. Application developers can maximize overall user experience by adjusting the resource allocation to meet the desired delay of users.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Mobile Radio Communication Systems (AREA)
Description
- The invention relates to a method and system for user desired delay estimation for mobile-cloud applications and a method and system for resource allocation.
- The popularity of smartphones, 3G/4G devices, tablets and other advanced mobile devices surged in the world. Together with widespread cellular networks and WiFi access, mobile devices have brought rich mobile applications to users. However, the resource-limited nature of mobile devices has hindered further developments for mobile services.
- To improve mobile applications and services various solutions based on offloading tasks to the powerful cloud have been proposed. Rather than conducting all operations locally, the cloud takes advantage of the abundant resources to provide better services (store, process) for mobile devices. Therefore, mobile applications determine some computational-intensive or energy-consuming tasks or methods to be sent to the cloud for processing.
- Among many performance metrics to the quality of services of applications, the application delay is especially interesting. Intuitively, users always desire online services with the delay as short as possible. Due to the best-effort nature of the Internet, it is very difficult and expensive to provide hard delay guarantees for applications. Therefore, to provide a soft delay guaranteed service attracts attentions for researchers and commercial companies. A soft delay guarantee makes a best-effort attempt to achieve the delay goal. Recent work (Ravindranath, Lenin and Padhye, Jitendra and Mahajan, Ratul and Balakrishnan, Hari: Timecard: controlling user-perceived delays in server-based mobile applications, Proceedings of SOSP, 2013) proposed a method to provide a soft delay guarantee. Ravindranath et al. measure the elapsed time and predict the application delay. With the predicted delay, the system makes a best-effort attempt to control the delay close to a somehow predetermined desired delay by adjusting the allocated resource in the cloud.
US 2011/004574 A1 discloses a method for dynamically allocating cloud resources for executing portions of a mobile application using cloud resources. A mobile device monitors and collects device and application parameters (runtime, sensor, device information) and using a cost model, generates a cost objective which it uses to determine whether to offload the portions of the application to the cloud.US8656284 B2 discloses a mechanism for inferring Quality of Experience, QoE, on a mobile device using subjective and objective metrics by monitoring user behaviour and quality of service parameters including delay. - The object of the present invention is to provide a method and system for user desired delay estimation for mobile-cloud applications and a method and system for resource allocation. This object is achieved with the features of the independent claims. The dependent claims relate to further aspects of the invention.
- According to one aspect of the present invention a method for user desired delay estimation for mobile-cloud applications is provided, wherein the method comprises the steps of collecting data for a mobile application using at least one of sensors, application logger and user feedback module of a mobile device, inferring the quality of experience based on the collected data, determining the desired delay by taking the quality of experience and optionally some additional statistical data based on the collected data into account, and offloading a task to the cloud together with a corresponding desired delay.
- Preferably, the quality of experience (QoE) is measured by subjective rating from users, e.g. by using the graphic Self-Assessment Manikin (SAM) to collect subjective rating.
- Furthermore, the collected data preferably comprise subjective and objective data. The subjective data includes at least one of refreshment frequency and refresh time stamp, from a user interaction feedback module. The objective data includes at least one of locations, network access, signal strength, system running time, active time stamp, and offloading delay, from sensors and application logger.
- Preferably, determining the desired delay applies nonparametric methods and more preferably decision tree or K-nearest neighbor classifier or linear discrimination or multilayer perceptions or support vector machine either as a two-class classification or a multiple class classification.
- In another aspect of the present invention a method for resource allocation is provided, wherein the method comprises the steps of receiving a task to be executed along with a corresponding desired delay from a mobile device, determining a resource allocation strategy based on the desired delay and the task to be processed, and executing the task using the allocated resources and sending the result to the mobile device.
- Preferably, the step of determining a resource allocation strategy further comprises determining whether the desired delay can be met with the current resources. Optionally, the desired delay is disregarded and the task may still be executed with the available resources, if the desired delay cannot be met.
- More preferably, determining of a resource allocation strategy is based on a self-learning process, wherein processing time on server analysis, delay estimation, elapsed time measurement and a table mapping the delay to resource allocation is used.
- Furthermore, the self-learning process may change the items of the table mapping the delay to resource allocation according to the feedback of server processing time.
- In another aspect of the present invention a system for user desired delay estimation for mobile-cloud applications is provided, wherein the system comprises a mobile device, an application framework on the mobile device, that is configured to collect data from a mobile application using at least one of sensors, application logger and user feedback module of the mobile device, to infer the quality of experience for users using the collected data, to estimate a desired delay based on the inferred quality of experience, and to offload a task to the cloud together with a corresponding desired delay.
- Preferably, the mobile device further comprises a GPS module and a WiFi module configured to collaborate for outdoor and for indoor localization.
- More preferably, the system further comprises a database memory configured to store therein records linking to user registrations including at least one of user's activities, locations, signal strength, system running time, network access, active time stamp, offloading delay, quality of experience.
- Furthermore, the mobile device may be configured to remotely access the server.
- In another aspect of the present invention a system for resource allocation is provided, wherein the system comprises at least one server containing abundant computing resources being configured to receive a task to be executed along with a corresponding desired delay from a mobile device, to determine a resource allocation strategy based on the desired delay and the task to be processed, to execute the task using the allocated resources and to send the result to the mobile device.
- Preferably, the at least one server is configured to self-learn and update the resource allocation strategy based on delay feedback.
- More preferably, the at least one server is further configured to send deny of service messages to the application framework on mobile devices when the server does not have enough resources to support the desired delay. Optionally, the task may still be executed with the remaining resources, when the desired delay cannot be executed.
- The present invention is the first work to optimize the resource allocation with respect to the quality of user experience. Therefore, it exploits a completely new solution to compromise the delay and user's experience.
- More specifically, the present invention allows compromising the delay and resource allocation by the fact that the quality of experience is highly contrived. For example, the image search application returns all images containing the user's face. Different users have different satisfying delays. User A does not need the result very soon so that he puts the mobile device into his pocket. While user B cannot wait to get the result, he checks the processing frequently. Apparently, the quality of experience between user A and B will be different with the same application delay. Therefore, applications could have their own desired delay for different users. To this end, wisely determining a suitable desired delay would be an attractive solution to compromise the delay and resource allocation. In the above example, user A could tolerate longer delay. Thus, when the computing resource is limited, the system allocates fewer resources for user A and more for user B to satisfy both of them. The present invention provides a system and method to dynamically determine a desired delay for users in order to maximize the overall quality of user's experience.
- Thus, the invention disclosed and claimed herein provides a system for desired delay estimation of mobile applications. The system may include two components on the application and the cloud. First, the system is to dynamically determine a suitable desired delay for users using machine-learning mechanism and second to control the application delay close to the desired delay. Preferably the system collects subjective and objective data through a feedback mechanism and sensors. Using the collected data, the machine-learning block outputs a desired delay. The application sends the desired delay along with the offloading request to the cloud and the system components in the cloud control the application delay close to the desired delay by adjusting the resource allocation strategy.
- To adjust the resource allocation in the cloud one can control the application delay and accomplish a task faster by allocating more resources and vice versa. However, there is a trade-off between delay and user's interest: longer delay drops the population of users due to poor user experience while shorter delay decreases service capacity due to consuming more resources.
-
-
FIG. 1 is a block diagram illustrating an example of an embodiment of a system according to the invention for dynamically estimating the desired delay and for determining resource allocation. -
FIG. 2 is a block diagram illustrating an example of one information gather component in accordance with an aspect of the invention. -
FIG. 3 is a block diagram illustrating an example of a desired delay estimator. -
FIG. 4 is a block diagram illustrating an example of a desired delay controller. -
FIG. 5 is a flow chart for illustrating an example of procedures in the mobile device. -
FIG. 6 is a flow chart for illustrating an example of procedures in the cloud. - A suitable desired delay for each user allows application developers optimally utilize their computing resources such as CPU, memory, etc. The desired delay depends on not only user's objective parameters but also user's subjective parameters. Combining these parameters can help to make a decision for adjusting the desired delay by machine-learning methods.
- The concept of quality of experience (QoE) combines user perception, experience, and expectations with subjective and objective parameters such as application level and network level quality of service (QoS). There are two approaches for measuring QoE: service level approach (uses statistical samples) and network management system approach (uses QoS parameters). The system of the present invention combines both approaches in a complementary way.
- In order to measure the QoE by subjective rating from users the graphic Self-Assessment Manikin might be employed to collect subjective rating. Using the measured QoE and other factors (e.g., application running time, user complain frequency, etc.), the system makes a decision whether the desired delay should be increased or decreased by applying a machine-learning mechanism. The application sends the offloading request incorporating the decision on the desired delay to the cloud. Then the cloud coordinates the communication, processes tasks and returns the results.
- The system of the present invention is a framework that supports task offloading with dynamic desired delay for mobile-cloud applications. Application developers need to create their applications following some principles of the system according to the invention for taking advantage of the present system. The principles depend on the implementation, which will be discussed in detail later.
-
FIG. 1 illustrates asystem 100 that enables dynamic desired delay. Thesystem 100 comprises afirst sub-system 100a which can be a mobile device of a user and asecond sub-system 100b which is located in the cloud. Thefirst sub-system 100a comprises adata collection component 101, an inferring Quality ofexperience component 102, a desireddelay estimator 103 and afirst offloading controller 104. It further comprises a local processing andrendering component 105. Thefirst sub-system 100a may further comprise units usually present in a mobile device in particular a screen and/or an application interface (not shown). - The
first sub-system 100a can collect data through thedata collection component 101. Based on the collected data,component 102 infers the QoE of users. QoE is an important parameter to determine the desired delay. The desireddelay estimator 103 generates a desired delay based on QoE and some statistical data, i.e. user implicit feedback and subjective rating. The implicit feedback might include user's interaction with the application interface and user's free touching behaviors on the screen when running the application. - The
first offloading controller 104 makes decisions whether to offload execution of a task, or to allow it to continue locally on themobile device 100a. If the offloadingcontroller 104 decides to offload the task, it sends a request incorporating the desired delay to thecloud 100b for remotely processing the task. - The
second sub-system 100b comprises asecond offloading controller 106, adynamic delay controller 108, acloud processing component 107 and aresource allocator 109. - The
second offloading controller 106 in the cloud receives the request and extracts the desired delay to thedynamic delay controller 108. Thedynamic delay controller 108 learns and stores a table mapping desired delay to resource allocation. For example, it is desired to accomplish a task A within 100 milliseconds.Dynamic delay controller 108 searches the table to get an item showing that 100-200 ms for task type A needs 1 CPU and 40MB memory. Then,dynamic delay controller 108 hands in the resource allocation strategy to theresource allocator 109. The resource allocator allocates resources for processing the task. Finally, thecloud processing component 107 accomplishes the task and sends the result as a response to themobile device 100a. The local processing andrendering component 105 receives the response and starts to process or render it. - The application running with
system 100 preferably provides a feedback mechanism for users. The system collects user's operations as well as delays to build a model for predicting user's desired delay. Thus, the system makes future decisions on the desired delay according to these data. The system does not require users to provide subjective survey; it collects implicit feedback like user's operations or interactions with an application. The desired delay prediction is therefore transparent to users, in that it does not change the way that users commonly use the application. -
FIG. 2 illustrates thedata collection component 101 of the system in accordance with an aspect of the present invention. It collects data from system components, i.e. in this example a userinteraction feedback component 201,sensors 202 and anapplication logger 203. Theuser feedback component 201 periodically surveys user's opinion and behavior. - Application developer may set a lot of questions about the application accuracy, interface, etc. Although the survey is very simple, it might not be the most effective way to obtain the data needed. Instead, it might be better to implicitly obtain the subjective parameters by implementing a feedback mechanism, i.e. count user activities. For example, a refresh button for an image processing application can be provided. Thus, the user could get the output of the cloud by pressing the refresh button. The button response could be either the result or an under processing message. By counting the press times for certain periods (e.g., some minutes or hours, one or several days, a week, a month and so on) the refresh frequency can be obtained. The refresh frequency (the ratio of press times and the time period) is capable of inferring user's QoE. This can be used as a subjective factor in estimating the desired delay. Therefore, user
interaction feedback component 201 records the refresh frequency for learning. -
Sensors 202 collect objective data such as location, network access, signal strength, etc.Application logger 203 records system running time, active time stamp (the time when user activates the application) and offloading delay. The offloading delay can be used to validate the effectiveness of the system. If the delay is longer than the desired value, the event is recorded as a failure. In contrast, when a too short delay compared with the desired value is detected, the event is recorded as overestimated. Thus, the system tries to allocate more resources for the failure and less for the overestimated. -
Data collection component 101 sends the collected data to inferringQoE component 102 for inferring user's QoE. To implementQoE component 102 several existing approaches can be used. - One approach is to connect QoE parameters and QoS parameters through an exponential relationship called IQX hypothesis (Fiedler, Markus and Hossfeld, Tobias and Tran-Gia, Phuoc: A generic quantitative relationship between quality of experience and quality of service, IEEE, Network, volume 24, page 36-41, 2010). The formula relates changes of QoE with respect to QoS to the current level of QoE, it is simple to match, and its limited behaviors are straightforward to interpret. An alternative is to adopt the Likert scale of Mean Opinion Scores (Mok, Ricky KP and Chan, Edmond WW and Luo, Xiapu and Chang, Rocky KC: Inferring the QoE of HTTP video streaming from user-viewing activities, Proceedings of SIGCOMM W-MUST 2011) to assess the QoE based on the collected data.
- For both approaches, inferring
QoE component 102 calculates the QoE directly from QoS parameters (collected by sensors 202). The system will take the QoE, user statistical data (collected by application logger 203) and user's subjective feedback (collected by interaction feedback component 201) to perform a machine-learning method in the desireddelay estimator 103. -
FIG. 3 illustrates an example of the desireddelay estimator 103. The desireddelay estimator 103 comprises adata formatting component 301 and a machine-learningcomponent 302. The desireddelay estimator 103 receives input data from the inferringQoE component 102. It transmits data in particular the desired delay to thefirst offloading controller 104. - As different machine-learning methods/tools require different data file formats and for user's convenience and system robustness,
data formatting component 301 preferably converts the raw input into different data file formats. - The implementation of the
machine learning component 302 is flexible. It depends on the input data features and sizes. QoE and user's subjective feedback are highly contrived. It is difficult to find a probabilistic model fitting the data. Therefore, the system adopts nonparametric methods to learn the data such as decision tree, K-nearest neighbor classifier, linear discrimination, multilayer perceptrons, support vector machine. - For simplicity, a 0-1 classifier (0 means the desired delay should increase, 1 means it should decrease) could be implemented. The increase/decrease step is preferably about 10 milliseconds. It is very easy to extend the two classes (0-1) to multiple classes, e.g. using classifications like very fast, fast, normal, slow, and very slow with corresponding increase/decrease steps.
- An important feature for learning is the QoE, time and the refresh record. In a training stage, desired
delay estimator 103 could assigns label 0 (increase the delay) by default. When the user presses the refresh button and an under processing message is returned (meaning the task has not been accomplished in the cloud), desireddelay estimator 103 labels the current decision 1. For example, desireddelay estimator 103 collects and maintains a recent week's data as the training data set. Later, desireddelay estimator 103 makes the increase/decrease decision using the training data. - When increasing the desired delay, the system may set an upper bound as the delay with minimum resource processing. When decreasing the desired delay, the system may be set to a standard delay (depends on tasks) if the current desired delay is greater than the standard delay. The system decreases the desired delay, for example by 10 milliseconds, if the current desired delay is less than or equal to the standard delay.
- The
first offloading controller 104 can be implemented by existing techniques such as ThinkAir (Kosta, Sokol and Aucinas, Andrius and Hui, Pan and Mortier, Richard and Zhang, Xinwen. Thinkair: Dynamic resource allocation and parallel execution in the cloud for mobile code offloading, Proceedings of INFOCOM, 2012), MAUI (Cuervo, Eduardo and Balasubramanian, Aruna and Cho, Dae-ki and Wolman, Alec and Saroiu, Stefan and Chandra, Ranveer and Bahl, Paramvir. MAUI: making smartphones last longer with code offload, Proceedings of MobiSys, 2010) or CloneCloud (Chun, Byung-Gon and Ihm, Sunghwan and Maniatis, Petros and Naik, Mayur and Patti, Ashwin. Clonecloud: elastic execution between mobile device and cloud, Proceedings of EuroSys, 2011). The controller decides whether to offload execution of a particular method, or to allow it to continue locally on the mobile device. The decision depends on data collected about the current environment as well as that learnt from past executions. As an example, ThinkAir implementation is chosen here. - When a task is encountered for the first time, it is unknown to the
first offloading controller 104 and so the decision is based only on environmental parameters such as network quality: for example, if the connection is of type WiFi, and the connectivity is strong, the controller is likely to offload the task. On a low quality connection, the task is likely to be executed locally. The controller combines the desired delay and the offload request and sends both to the cloud if it decides to offload. - The
second offloading controller 106 is to manage client (mobile device 100a) connections. If the client application is unknown to the application server, thesecond offloading controller 106 retrieves the application from the client, and loads any required class definitions and native libraries. It also responds to application-level ping messages sent by thefirst offloading controller 104 to measure connection latency. Following the initial connection set up, the server waits to receive execution requests from the client. -
FIG. 4 illustrates an example of adynamic delay controller 108. Thedynamic delay controller 108 comprises a self-learning component 401 and an allocationstrategy table component 402. Thedynamic delay controller 108 receives input data, such as search keys from thesecond offloading controller 106 and feedback from thecloud processing component 107. - The
dynamic delay controller 108 learns from historical statistic data and determines a suitable resource allocation strategy based on the desired delay. Initially, the table in thedynamic delay controller 108 contains only one item: mapping the default desired delay value to a resource allocation strategy. The default desired delay is unknown actually because initially the system has no knowledge of the processing load for different types of applications. Therefore, the system simply sets a default resource allocation strategy for all applications. - The
dynamic delay controller 108 self-learns the delay by the feedback of thecloud processing component 107, which is the processing time on the server for the task. However, the server processing time is only one part of the application delay. One way to implement thedynamic delay controller 108 is using the existing technique Timecard (Ravindranath, Lenin and Padhye, Jitendra and Mahajan, Ratul and Balakrishnan, Hari: Timecard: controlling user-perceived delays in server-based mobile applications, Proceedings of SOSP, 2013). It provides two abstractions: the first returns the time elapsed since the user started the request, and the second returns an estimate of the time it would take to transmit the response from the server to the client and process the response at the client. With these abstractions, the server can adapt its processing time to control the end-to-end delay for the request exploiting resource allocation techniques. With the feedback of thecloud processing component 107 and the measured time elapsed, thedynamic delay controller 108 could learn a resource allocation strategy for the future, recording the corresponding delay of the resource allocation strategy. The strategy could be updated accordingly. - The
resource allocator 109 can be implemented by existing resource allocation techniques. To make the cloud infrastructure easily maintainable and to keep the execution environment homogeneous, a virtualization environment is typically used, allowing the system to be deployed where needed. There are many suitable virtualization platforms available, e.g., Xen, QEMU and VirtualBox. It is preferable to pre-configure a few types of VMs (virtual machines) in common use so that the resource allocation to tasks can be managed in terms of different types of VMs. This is more efficient and effective. For example, the system can have 4 types of VMs with different configurations of CPU and memory: (1 CPU, 256MB), (1 CPU 512MB), (2 CPU, 1024MB) and (4 CPU, 1024MB). When thedynamic delay controller 108 asks for 2 CPU and 512MB memory, theresource allocator 109 allocates 2 VMs with 1 CPU and 256MB memory. - If the remaining resource cannot satisfy a new coming allocation strategy, the
resource allocator 109 sends back a warning signal to thedynamic delay controller 108 showing that it fails to allocate the resource. Then thedynamic delay controller 108 will change the allocation strategy accordingly. In other words, if the desired delay cannot be met with the remaining resources the system might send a deny-of-service message to the application framework of the mobile device. For example, a task would require 3 CPUs and 100 MB memory to meet the desired delay. However, the cloud can only provide 1 CPU and 10 MB memory. Then the server sends a deny message to the mobile device. Next, the cloud disregards the desired delay and tries in a best effort approach to execute the task without the desired delay guarantee. The cloud may reallocate resources for next requests depending on the overall desired delay situation for all users. - The
cloud processing component 107 is responsible for executing tasks. It coordinates VMs and combines results as an output. Finally, it sends the output as a response to the local processing andrendering component 105. After receiving the response, the local processing andrendering component 105 processes and renders the result in the response. The process and render method depends on the corresponding processes. -
FIG. 5 illustrates the workflow of applications using thefirst sub-system 100a in mobile devices. Thedata collection component 101 collects data from application logger (e.g., application running time, application delay, i.e. the desired delay, request time, response time), sensors (e.g., location, light, temperature, noise), and user interaction feedback (e.g., refresh time, shutdown time, reactivate time). Using the output of thedata collection component 101,step 501 obtains the QoE through the inferringQoE component 102. Step 502 activates the desired delay estimator. Then step 503 makes a decision whether to offload the task or to process locally with the data from thedata collection component 101 and the output ofstep 502. Thefirst offloading controller 104 sends the offloading request to the cloud and waits for the response as long as the decision is yes. Otherwise,step 504 activates local processing and returns some statistical data to thedata collection component 101 for future work. -
FIG. 6 illustrates the workflow of thesecond sub-system 100b in the cloud. Initially, the server is waiting for a request. Step 601 receives and extracts the request. Step 602 makes a decision whether to offload or to reject the request based on the current state of the cloud such as the remaining resource, and/or network problems and so on. If no, thesecond offloading controller 106 sends a reject reply to the mobile device. If yes, step 603 uses the desired delay to search for a resource allocation strategy as the output. If no such item can be obtained,step 603 selects a default allocation strategy. Step 604 receives the output ofstep 603, and then deploys different types of VMs based on the use of resource allocation techniques. By checking the remaining resource,step 605 is to confirm the feasibility of resource allocation strategy. If it is not feasible due to inadequate resources,step 607 sends a report to thedynamic delay controller 108 for changing the resource allocation strategy and updating the table. If it is feasible,step 606 activates the allocated VMs and processes the tasks. Finally, thecloud processing component 107 sends the calculated result back to the mobile devices. - A mobile-cloud system that can estimate user desired delay for mobile-cloud applications is provided. Furthermore, a method that can collect data reflecting user experience is provided. The method can learn from the collected data to determine a suitable desired delay. Application developers can maximize overall user experience by adjusting the resource allocation to meet the desired delay of users.
- What has been described above includes examples of the present invention. It is not possible to describe every conceivable combination of components or methodologies for purposes of describing the subject of the invention, but one of ordinary skill in the art may recognize that many further combinations and permutations of the invention are possible. The foregoing detailed description has described only a few of many possible implementations of the present invention. The detailed description is intended by way of illustration, not by way of limitation.
Claims (16)
- A method for user desired delay estimation for mobile-cloud applications, wherein a desired delay is a delay which a user is willing to tolerate for a task to be executed, wherein the method comprises:collecting data by a mobile device for a mobile application using at least one of sensors, application logger and user feedback module of the mobile device;inferring a quality of experience for the user by the mobile device based on the collected data;determining the desired delay by the mobile device by taking the quality of experience and optionally additional statistical data based on the collected data into account; andoffloading the task to a cloud by the mobile device, wherein the mobile device sends an offloading request incorporating the desired delay to the cloud for remotely processing the task.
- The method of claim 1, wherein the collected data comprises subjective and objective data, wherein the subjective data includes at least one of refreshment frequency recorded by the user feedback module, wherein the refreshment frequency which is a frequency that the user presses a refresh button for the application; and objective data includes at least one of location, network access, signal strength, system running time, active time stamp, which is the time when the user activates the application, and offloading delay, which is the delay for the offloaded task to be completed,
wherein the location, network access and signal strength are collected from the sensors and the system running time, active time stamp and offloading delay are recorded by the application logger. - The method of any of claims 1 or 2, wherein determining the desired delay applies nonparametric methods, preferably decision tree or K-nearest neighbor classifier or linear discrimination or multilayer perceptions or support vector machine either as a two-class classification or a multiple class classification.
- A method for resource allocation, wherein the method comprises:receiving an offloading request for a task to be executed along with a corresponding desired delay from a mobile device wherein the desired delay is determined by taking a quality of experience of a user into account, wherein the desired delay is a delay which the user is willing to tolerate for the task to be executed;determining a resource allocation strategy based on the desired delay and the task to be processed; andexecuting the task using allocated resources by the determined resource allocation strategy and sending a result of the executed task to the mobile device.
- The method of claim 4, wherein the step of determining the resource allocation strategy further comprises determining whether the desired delay can be met with current resources and optionally disregarding the desired delay and executing the task with available resources.
- The method of any of claims 4 or 5, wherein determining of the resource allocation strategy is based on a self-learning process, wherein processing time on a server, delay estimation which is an estimate of the time it would take to send the result, elapsed time measurement which is an elapsed time since the offload request was issued and a table mapping the desired delay to resource allocation are used.
- The method of claim 6, wherein the self-learning process updates the table mapping the desired delay to resource allocation according to feedback of the server processing time.
- A method comprising the method for user desired delay estimation for mobile-cloud applications according to any of claims 1 to 3 and the method for resource allocation according to any of claims 4 to 7.
- A first system for user desired delay estimation for mobile-cloud applications, wherein a desired delay is a delay which a user is willing to tolerate for a task to be executed, wherein the first system comprises:a mobile device;an application framework on the mobile device configured to:collect data from a mobile application using at least one of sensors, application logger and user feedback module of the mobile device;infer a quality of experience for the user using the collected data;estimate the desired delay based on the inferred quality of experience; andoffload the task to a cloud, wherein the mobile device is configured to send an offload request incorporating the desired delay to the cloud for remotely processing the task.
- The first system of claim 9, wherein the mobile device further comprises a GPS module and a WiFi module configured to collaborate for outdoor and for indoor localization.
- The first system of any of claims 9 or 10, wherein the first system further comprises a database memory configured to store therein records linking to user registrations including at least one of user activities, location, signal strength, system running time, network access, active time stamp, which is the time when the user activates the application, offloading delay, which is the delay for the offloaded task to be completed, and the inferred quality of experience.
- The first system of any of claims 9 to 11, wherein the mobile device is configured to remotely access a server.
- A second system for resource allocation, wherein the second system comprises: at least one server containing computing resources and being configured to:receive an offloading request for a task to be executed along with a corresponding desired delay from a mobile device wherein the desired delay is determined by taking a quality of experience of a user into account, wherein the desired delay is a delay which the user is willing to tolerate for the task to be executed;determine a resource allocation strategy based on the desired delay and the task to be processed;execute the task using allocated resources by the determined resource allocation strategy; andsend a result of the executed task to the mobile device.
- The second system of claim 13, wherein the at least one server is configured to self-learn and update the resource allocation strategy based on delay feedback wherein the delay feedback is the processing time on the at least one server for the task.
- The second system of any of claims 13 or 14, wherein the at least one server is further configured to send deny of service messages to the mobile device when the at least one server does not have enough resources to support the desired delay and optionally the at least one server is configured to execute the task with remaining resources, when the desired delay cannot be supported.
- A system comprising the first system according to any of claims 9 to 12 and the second system according to any of claims 13 to 15.
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP14158553.9A EP2919438B1 (en) | 2014-03-10 | 2014-03-10 | Method and system to estimate user desired delay for resource allocation for mobile-cloud applications |
PCT/EP2015/054630 WO2015135834A1 (en) | 2014-03-10 | 2015-03-05 | Method and system to estimate user desired delay for resource allocation for mobile-cloud applications |
US15/120,761 US10200446B2 (en) | 2014-03-10 | 2015-03-05 | Method and system to estimate user desired delay for resource allocation for mobile cloud applications |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP14158553.9A EP2919438B1 (en) | 2014-03-10 | 2014-03-10 | Method and system to estimate user desired delay for resource allocation for mobile-cloud applications |
Publications (2)
Publication Number | Publication Date |
---|---|
EP2919438A1 EP2919438A1 (en) | 2015-09-16 |
EP2919438B1 true EP2919438B1 (en) | 2019-06-19 |
Family
ID=50272350
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP14158553.9A Active EP2919438B1 (en) | 2014-03-10 | 2014-03-10 | Method and system to estimate user desired delay for resource allocation for mobile-cloud applications |
Country Status (3)
Country | Link |
---|---|
US (1) | US10200446B2 (en) |
EP (1) | EP2919438B1 (en) |
WO (1) | WO2015135834A1 (en) |
Families Citing this family (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP6035288B2 (en) * | 2014-07-16 | 2016-11-30 | 富士フイルム株式会社 | Image processing system, client, image processing method, program, and recording medium |
US9813523B2 (en) * | 2015-03-16 | 2017-11-07 | Intel IP Corporation | Apparatus, method and system of quality of experience indication |
CN105893083B (en) * | 2016-03-29 | 2019-06-11 | 华中科技大学 | Mobile code unloading support system and its discharging method under cloud environment based on container |
US10628222B2 (en) | 2016-05-17 | 2020-04-21 | International Business Machines Corporation | Allocating compute offload resources |
US20180110010A1 (en) * | 2016-10-19 | 2018-04-19 | Microsoft Technology Licensing, Llc | Extending battery life in low signal conditions |
KR102027682B1 (en) * | 2018-02-08 | 2019-10-02 | 한국과학기술원 | System and method for load balancing in mobile cloud network for partial computation offloading |
JP7210313B2 (en) * | 2019-02-14 | 2023-01-23 | 株式会社日立製作所 | COMMUNICATION CONTROL DEVICE, COMMUNICATION CONTROL METHOD, AND COMMUNICATION SYSTEM |
CN110087318B (en) * | 2019-04-24 | 2022-04-01 | 重庆邮电大学 | Task unloading and resource allocation joint optimization method based on 5G mobile edge calculation |
KR102214231B1 (en) * | 2019-05-17 | 2021-02-09 | 군산대학교산학협력단 | Mobile device for performing offloading process and method thereof |
EP3973397A1 (en) * | 2019-05-22 | 2022-03-30 | Microsoft Technology Licensing, LLC | Systems and methods for distribution of application logic in digital networks |
US11237861B2 (en) * | 2019-05-31 | 2022-02-01 | Vmware, Inc. | Managing virtual infrastructure resources in cloud environments |
CN111010434B (en) * | 2019-12-11 | 2022-05-27 | 重庆工程职业技术学院 | Optimized task unloading method based on network delay and resource management |
CN110928691B (en) * | 2019-12-26 | 2021-07-09 | 广东工业大学 | Traffic data-oriented edge collaborative computing unloading method |
US11063881B1 (en) * | 2020-11-02 | 2021-07-13 | Swarmio Inc. | Methods and apparatus for network delay and distance estimation, computing resource selection, and related techniques |
US11599837B2 (en) | 2020-12-30 | 2023-03-07 | Microsoft Technology Licensing, Llc | Method and system for selection of users in feature rollout |
US11829743B2 (en) | 2021-09-29 | 2023-11-28 | Microsoft Technology Licensing, Llc | Method and system for providing customized rollout of features |
CN113961266B (en) * | 2021-10-14 | 2023-08-22 | 湘潭大学 | Task unloading method based on bilateral matching under edge cloud cooperation |
CN114264220B (en) * | 2021-12-23 | 2022-11-22 | 湖南大学 | Method for accurately sensing and detecting relative displacement of mobile equipment |
US20240015104A1 (en) * | 2022-07-06 | 2024-01-11 | Cisco Technology, Inc. | Quantifying application quality of experience under different path performance motifs |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20110004574A1 (en) * | 2009-07-02 | 2011-01-06 | Samsung Electronics Co., Ltd. | Execution allocation cost assessment for computing systems and environments including elastic computing systems and environments |
US8656284B2 (en) * | 2009-04-17 | 2014-02-18 | Empirix Inc. | Method for determining a quality of user experience while performing activities in IP networks |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100306249A1 (en) * | 2009-05-27 | 2010-12-02 | James Hill | Social network systems and methods |
US8121618B2 (en) * | 2009-10-28 | 2012-02-21 | Digimarc Corporation | Intuitive computing methods and systems |
US8464255B2 (en) * | 2010-03-12 | 2013-06-11 | Microsoft Corporation | Managing performance interference effects on cloud computing servers |
US8879438B2 (en) * | 2011-05-11 | 2014-11-04 | Radisys Corporation | Resource efficient acoustic echo cancellation in IP networks |
US20130138798A1 (en) * | 2011-11-29 | 2013-05-30 | International Business Machines Corporation | Predictive and dynamic resource provisioning with tenancy matching of health metrics in cloud systems |
EP2847971B1 (en) * | 2012-05-08 | 2018-12-26 | Cirrus Logic International Semiconductor Ltd. | System and method for forming media networks from loosely coordinated media rendering devices. |
US8959583B2 (en) * | 2013-02-05 | 2015-02-17 | Ca, Inc. | Access to vaulted credentials using login computer and mobile computing device |
US9703478B2 (en) * | 2013-07-19 | 2017-07-11 | Intel Corporation | Category-based keyboard |
US10292067B2 (en) * | 2013-11-25 | 2019-05-14 | At&T Intellectual Property I, L.P. | Collaborative scheduling of last hop cellular traffic |
US10296391B2 (en) * | 2014-06-30 | 2019-05-21 | Microsoft Technology Licensing, Llc | Assigning a player to a machine |
WO2017001634A1 (en) * | 2015-06-30 | 2017-01-05 | British Telecommunications Public Limited Company | Negotiating quality of service for data flows |
-
2014
- 2014-03-10 EP EP14158553.9A patent/EP2919438B1/en active Active
-
2015
- 2015-03-05 WO PCT/EP2015/054630 patent/WO2015135834A1/en active Application Filing
- 2015-03-05 US US15/120,761 patent/US10200446B2/en active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8656284B2 (en) * | 2009-04-17 | 2014-02-18 | Empirix Inc. | Method for determining a quality of user experience while performing activities in IP networks |
US20110004574A1 (en) * | 2009-07-02 | 2011-01-06 | Samsung Electronics Co., Ltd. | Execution allocation cost assessment for computing systems and environments including elastic computing systems and environments |
Also Published As
Publication number | Publication date |
---|---|
WO2015135834A1 (en) | 2015-09-17 |
US20160381116A1 (en) | 2016-12-29 |
EP2919438A1 (en) | 2015-09-16 |
US10200446B2 (en) | 2019-02-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP2919438B1 (en) | Method and system to estimate user desired delay for resource allocation for mobile-cloud applications | |
US12034597B2 (en) | Methods and apparatus to control processing of telemetry data at an edge platform | |
Ashok et al. | Vehicular cloud computing through dynamic computation offloading | |
US20200236012A1 (en) | System and method for applying machine learning algorithms to compute health scores for workload scheduling | |
US11106560B2 (en) | Adaptive thresholds for containers | |
EP2882140B1 (en) | Data partitioning in internet-of-things (IOT) network | |
US20140215076A1 (en) | Allocation of Virtual Machines in Datacenters | |
JP2018503275A (en) | Method, apparatus, and system for exploring application topology relationships | |
CN103002005A (en) | Cloud service monitoring system | |
CN105431822A (en) | Managing a succession of deployments of an application programming interface (api) server configuration in the software lifecycle development | |
US11568242B2 (en) | Optimization framework for real-time rendering of media using machine learning techniques | |
CN103713935A (en) | Method and device for managing Hadoop cluster resources in online manner | |
CN112433733A (en) | Controlling performance of deep learning models deployed on edge devices via predictive models | |
US11546422B2 (en) | Dynamic management of locations of modules of a platform hosted by a distributed system | |
Patman et al. | Data-driven edge computing resource scheduling for protest crowds incident management | |
Wu | Analysis of offloading decision making in mobile cloud computing | |
Passas et al. | Artificial Intelligence for network function autoscaling in a cloud-native 5G network | |
US12026542B2 (en) | Optimizing deployment of machine learning workloads | |
US11729080B2 (en) | Agentless method to automatically detect low latency groups in containerized infrastructures | |
Premkumar et al. | Processing capacity‐based decision mechanism edge computing model for IoT applications | |
US20210287112A1 (en) | Real-time server capacity optimization tool | |
US20180262395A1 (en) | System management device, system management method, program, and information processing system | |
Zakarya et al. | ApMove: A service migration technique for connected and autonomous vehicles | |
US20240179567A1 (en) | Dynamic functional splitting systems and methods | |
Shekhar et al. | INDICES: Applying DDDAS Principles for Performance Interference-aware Cloud-to-Fog Application Migration |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
AX | Request for extension of the european patent |
Extension state: BA ME |
|
17P | Request for examination filed |
Effective date: 20160316 |
|
RBV | Designated contracting states (corrected) |
Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: EXAMINATION IS IN PROGRESS |
|
17Q | First examination report despatched |
Effective date: 20180426 |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R079 Ref document number: 602014048500 Country of ref document: DE Free format text: PREVIOUS MAIN CLASS: H04L0029080000 Ipc: H04W0024020000 |
|
GRAP | Despatch of communication of intention to grant a patent |
Free format text: ORIGINAL CODE: EPIDOSNIGR1 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: GRANT OF PATENT IS INTENDED |
|
RIC1 | Information provided on ipc code assigned before grant |
Ipc: H04W 88/02 20090101ALI20181203BHEP Ipc: H04L 29/08 20060101ALI20181203BHEP Ipc: H04L 29/06 20060101ALI20181203BHEP Ipc: H04W 24/02 20090101AFI20181203BHEP |
|
INTG | Intention to grant announced |
Effective date: 20190103 |
|
GRAS | Grant fee paid |
Free format text: ORIGINAL CODE: EPIDOSNIGR3 |
|
GRAA | (expected) grant |
Free format text: ORIGINAL CODE: 0009210 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE PATENT HAS BEEN GRANTED |
|
RIN1 | Information on inventor provided before grant (corrected) |
Inventor name: ZHANG, SHENGKAI Inventor name: PEYLO, CHRISTOPH Inventor name: HUI, PAN |
|
AK | Designated contracting states |
Kind code of ref document: B1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
REG | Reference to a national code |
Ref country code: GB Ref legal event code: FG4D |
|
REG | Reference to a national code |
Ref country code: CH Ref legal event code: EP |
|
REG | Reference to a national code |
Ref country code: IE Ref legal event code: FG4D |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R096 Ref document number: 602014048500 Country of ref document: DE |
|
REG | Reference to a national code |
Ref country code: AT Ref legal event code: REF Ref document number: 1147082 Country of ref document: AT Kind code of ref document: T Effective date: 20190715 |
|
REG | Reference to a national code |
Ref country code: NL Ref legal event code: MP Effective date: 20190619 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: FI Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20190619 Ref country code: AL Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20190619 Ref country code: NO Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20190919 Ref country code: SE Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20190619 Ref country code: HR Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20190619 Ref country code: LT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20190619 |
|
REG | Reference to a national code |
Ref country code: LT Ref legal event code: MG4D |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: GR Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20190920 Ref country code: LV Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20190619 Ref country code: RS Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20190619 Ref country code: BG Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20190919 |
|
REG | Reference to a national code |
Ref country code: AT Ref legal event code: MK05 Ref document number: 1147082 Country of ref document: AT Kind code of ref document: T Effective date: 20190619 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: CZ Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20190619 Ref country code: SK Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20190619 Ref country code: PT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20191021 Ref country code: AT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20190619 Ref country code: EE Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20190619 Ref country code: RO Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20190619 Ref country code: NL Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20190619 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: IT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20190619 Ref country code: IS Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20191019 Ref country code: ES Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20190619 Ref country code: SM Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20190619 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: TR Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20190619 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: PL Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20190619 Ref country code: DK Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20190619 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: IS Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20200224 |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R097 Ref document number: 602014048500 Country of ref document: DE |
|
PLBE | No opposition filed within time limit |
Free format text: ORIGINAL CODE: 0009261 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT |
|
PG2D | Information on lapse in contracting state deleted |
Ref country code: IS |
|
26N | No opposition filed |
Effective date: 20200603 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: SI Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20190619 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: MC Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20190619 |
|
REG | Reference to a national code |
Ref country code: CH Ref legal event code: PL |
|
REG | Reference to a national code |
Ref country code: BE Ref legal event code: MM Effective date: 20200331 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: LU Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20200310 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: IE Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20200310 Ref country code: CH Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20200331 Ref country code: LI Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20200331 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: BE Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES Effective date: 20200331 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: MT Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20190619 Ref country code: CY Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20190619 |
|
PG25 | Lapsed in a contracting state [announced via postgrant information from national office to epo] |
Ref country code: MK Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT Effective date: 20190619 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: FR Payment date: 20231213 Year of fee payment: 11 |
|
PGFP | Annual fee paid to national office [announced via postgrant information from national office to epo] |
Ref country code: DE Payment date: 20231212 Year of fee payment: 11 Ref country code: GB Payment date: 20240322 Year of fee payment: 11 |