Chapter 4 Auction-Based Actuator Conflict Resolution 13
4.2 Proposed Auctions with Actions and Rebidding
4.2.2 Multi-Round Single-Item Auction considering Actions and Re-
This auction is like the previous one. The main difference is that actuators will keep in the list after sold in the previous rounds. When applications regret their previous bids based on the latest bidding result, they can bid on sold actuators again to indicate their preference changes. For some applications that require atomic operation, it is important for them to withdraw the operation instead of executing partial operation. Rebidding provides them a mechanism to change their bids when their atomic operations can not be executed. The auction continues until the total utility can not be further maximized. The result is the final decision of the operation.
The algorithm is shown in Algorithm 2.
20 CHAPTER 4. AUCTION-BASED ACTUATOR CONFLICT RESOLUTION
Algorithm 2: Multi-round auction considering actions and rebidding Input: A set of applications N
Input: A set of actuators M
Input: Current environmental state s
Chapter 5
Implementation Design
In this chapter, we show the implementation design of conflict resolution in the WuKong framework. We will first introduce the WuKong framework and original development flow. Then we will introduce how to support multiple applications and conflict resolution in WuKong framework. Then the detail of the conflict resolution component is presented.
5.1 WuKong Framework
5.1.1 Goal
WuKong aims to provide a simple application development and deployment flow for developers and users to easily create IoT applications. The framework should intel-ligently perform development details, including sensor identification, device configu-ration, service deployment, user personalization, network management, and system
21
22 CHAPTER 5. IMPLEMENTATION DESIGN
Figure 5.1: A simple application by Flow-Based Programming (FBP)
sustainment. Also, the system can adapt to environment changes. The framework reduces the cost and human efforts to deploy and manage applications and auto-matically perform the optimization and proactive support for users.
5.1.2 Flow-Based Programming
IoT applications are distributed by nature. An application consists of several com-ponents. IoT applications are usually event-driven. The events are detected and the data are sent to the next component. Flow-based programming (FBP) focuses on the information flow between components instead of focusing on data processing in typical applications. Therefore, FBP is good for developing IoT applications.
Figure 5.1 shows an example using FBP to program an application. The ap-plication is to turn on the heater if the temperature is too cold. There are two conditions that the heater will be turned on. Either condition is met will turn on
5.1. WUKONG FRAMEWORK 23
the heater. The first condition is when the indoor temperature is below 18 degrees Celsius. The second condition is when the indoor temperature is below 20 degrees Celsius and the outdoor temperature is below 10 degrees Celsius. The application consists of 8 components. The sensors parts consists of two temperatures compo-nents. The actuator parts consists of one heater component. And five computing logic components in the processing parts.
WuKong provides a FBP developing tool for application developers to use. The interface provides components available to compose an application. Application developers only need to focus the abstract data flow. The communication and implementation detail are encapsulated by the component block. If predefined com-ponents in the WuKong framework can not fulfill the requirement of developers, developers can create custom components to satisfy specific task. WuKong takes care of the physical implementation details and eases the effort of managing devices.
5.1.3 Compilation Flow
Figure 5.2 shows the flow of WuKong compilation process. The left part is the process of generating components libraries and device installation. The top-right part is the FBP IDE that introduced in the previous section to develop applications.
Then, the bottom-right part is the build process of generating application Java bytecode from application drawn by the FBP.
The application.xml file is passed to the mapping compiler (mapper) in the Master. The Master will perform the discovery process to discover the information from physical devices in the environment. The mapper will match the requirement
24 CHAPTER 5. IMPLEMENTATION DESIGN
Figure 5.2: WuKong Compilation Process
5.2. SUPPORT MULTIPLE APPLICATIONS 25
from the application.xml file with the physical devices. The mapper will generate the Application.java to store the mapping result. It contains the links between components and the physical device of the component. Finally, the application.java will be sent to the Java compiler to generate the Java bytecodes which contains is the application code. Then the Master uploads the application to the devices wirelessly.
5.2 Support Multiple Applications
The original WuKong framework doesn’t support running multiple applications. In fig. 5.2, the application bytecode is uploaded to devices. Each device runs only one application. Whenever a new application is uploaded to a device, the old application will be erased.
An naive way to enable running multiple applications is to let devices store multiple application bytecodes and each devices will switch from one application to another. It’s like the context switch in common operation system. However, this will increase the overhead of devices. The devices may have very low computing capability. Managing context switch consumes the computing support.
Another way is to keep the device only run one application bytecode and let the Master merge multiple applications into one. This keeps the complexity of devices low and let the Master do the most heavy work which is reasonable since the Master should be a powerful machine.
Figure. 5.3 shows the original mapping process. The mapper takes
applica-26 CHAPTER 5. IMPLEMENTATION DESIGN
tion.xml which is created by developer using FBP and discovery result as input to map the abstract components to physical devices. The output is the mapping result stored by another xml file named WKDeploy.xml. Then the mapping result is sent to the code generator to generate application bytecode. Finally, the bytecode is uploaded to the physical devices.
The Master has two options to merge applications during the mapping process.
• Merge the application FBP xml files before mapping.
• Merge the WKDeploy.xml files after mapping.
Master choose the first way. Master merges the application FBP files. Once Master merges the FBP files, Master can put the merged FBP file into the mapper, then the mapper will map. The flow is shown in Fig. 5.4
However, we need to further add the conflict resolution component before shared actuators. When merging the application FBPs, Master should try to avoid merging actuators if possible. But the mapping might fail because there might be insufficient physical devices to map the new components. Therefore, if the mapping fails at the first round, Master can merge the unmappable components with other components.
And we add an arbitrator component before the actuator to resolve conflict resolu-tion. Then, try the second round mapping with merged components. The flow is shown in Fig. 5.5.
• Stage I: concatenate the xml without any merge and run the mapper.
• Stage II: merge unmappable components and run the mapper again.
5.2. SUPPORT MULTIPLE APPLICATIONS 27
Figure 5.3: Original WuKong Mapping Flow
An example is shown in Fig. 5.6. There is an application running in the envi-ronment. The application is to use a touch pad to control the light. The touch pad is mapped to the first physical device and the light is mapped to the second physical device. Now we want to add a new application that uses the light sensor to turn on the light if the room is too dark. Master first merges the application into one FBP file. In first stage, the new application is added at the end of the existing application. These are two isolated connected components and no component has been merged yet. Next Master sends the merge result to the mapper to see if Master can map the merge FBP to the physical devices. Assume there is only one light in the environment now so the mapping is failed because Master requires two light in the FBP. Then, Master goes to the second stage to merge the light component and Master adds an arbitrator before the light component to coordinate applications.
28 CHAPTER 5. IMPLEMENTATION DESIGN
Figure 5.4: WuKong Mapping Flow with Supporting Multi-Application
Figure 5.5: WuKong Mapping Flow with Supporting Multi-Application and Conflict Resolution
5.2. SUPPORT MULTIPLE APPLICATIONS 29
(a) Add an new application in a existing application
(b) Stage I: Concatenate the existing application and the new application
(c) Map the merged FBP
(d) Merge the failed actuator and add an arbitrator component
(e) Map the merged FBP again
Figure 5.6: Example of Merging FBP and Mapping
30 CHAPTER 5. IMPLEMENTATION DESIGN
5.3 Arbitrator Component Implementation
The arbitrator component is used to coordinate applications to control an actuator.
The arbitrator takes the actions of applications as input and check if they are the same. If two applications ask the same action, there’s no conflict. However, if two applications want to perform different actions, the arbitrator component needs to resolve the conflict. The arbitrator evaluates the utility of each application according to the action of the actuator and chooses the action that can maximize the sum of utilities.
The arbitrator component resolves the conflict when applications want the actu-ator to perform different actuactu-ators. The conflict resolution algorithm is introduced in Chap. 4. The arbitrator component needs several information to resolve the con-flict. It needs parameters of the utility function of each applications. The utility function will be introduced in more detail Chap. 6. It needs to know the effect on the environment of the each action of the actuator which we call the actuator pro-file. The actuator profile is generated and updated by the progression framework in WuKong. It also needs the current environmental state from the sensors. With these information, the arbitrator component can run the auction-based conflict resolution algorithm when applications sends different actions to control the same actuator.
The arbitrator component is a logical computing component. It doesn’t evolves physical sensors or actuators. It just computes and implemented in Java in WuKong framework. Using Java, the master can dynamically upload the new implementation easily when the actuator profile or utility function is updated.
Chapter 6
Experiment & Results
We use the simulation to examine our auction algorithms. We first describe how we simulate the environment.
6.1 Simulation Settings
6.1.1 Environmental State
In indoor human comfort index domain, four basic indexes are considered. They are thermal comfort, visual comfort, indoor air quality (IAQ), and acoustic comfort [5, 13]. We use four context attributes to represent an environment state to capture these four comfort indexes. They are temperature, lightness, CO2 concentration, sound level. C denotes the set of all considered context attributes. In current case, C = {temperature, lightness, CO2, sound}, To simplify the experiment, we normalize the values of each context attributes to 0 and 1.
31
32 CHAPTER 6. EXPERIMENT & RESULTS
s =< βtemperature, βlightness, βCO2, βsound>
C = {temperature, lightness, CO2, sound}
∀c ∈ C, βc∈ [0, 1]
6.1.2 Actuator Simulation
An actuator has several actions to perform. Each action has different effects on each context attribute. We use an uniform random generator to generate the effect of each action. These effects are the transition function of the environmental state, i.e., the δ function. Applications can evaluate the utility value of each action based on the transition function, .
6.1.3 Application Simulation
The application uses a utility function to evaluate the preference of the environ-mental state. It is concerned about some kinds of context attributes, and ignore some context attributes depending on its goal. The application has a target value of context attribute value. The application would want to keep the environmental state to stay in the target value. When the environmental state is closer to the target range, the utility value would be higher. For example, for the application which wants to keep the environment warm, the main context attributes it will con-sider are thermal and other kinds of context attributes can be ignored. When the
6.1. SIMULATION SETTINGS 33
environment is warm, the utility will be the high since it achieves the main goal.
When the environment is cold or hot, the utility should be low.
Next, we describe how we simulate the utility function. The application calcu-lates a score for each context attribute separately and the utility of the environmental state is the weighted sum of context attributes scores. For context attributes that the application cares, we use a linear scoring function to calculate the score between the environmental state and the target value.
The utility function of application i is denoted by ui. ui,c denotes the scoring function of context attribute c, and wc is the weight for context attribute c. The number a ∈ [0, 1] denotes the parameter that represents the target value, e.g., c = lightness, a = 0 indicates that the application wants to minimize the lightness in the environment. Fig. 6.1 shows different shapes with different target values a.
ui(s) =X
In our simulation, for any context attribute, the probability for an application to ignore the particular context attribute is 50%, and the target value, a, is generated by an uniform random generator. The weights for each context attributes, wtemperature, wlightness, wCO2, wsound, are 0.5, 0.3, 0.1, and 0.1 respectively. The thermal comfort gets the highest weight because it influences the human body the most [12].
34 CHAPTER 6. EXPERIMENT & RESULTS
Figure 6.1: Utility functions with different input a
6.2. EVALUATION 35
6.2 Evaluation
6.2.1 Compared Methods
We choose two methods to compare with our auction methods. The first one is the random method. It randomly selects an action from each actuator to form the output operation. The second one is the brute force method. Random method is to randomly select an action for each actuator as the output of the resolution.
Brute force method iterates all possible operations to find the operation o∗ which maximizes the total utilities. It is a global optimal solution.
6.2.2 Evaluation Metrics
For the conflict resolution, it is important to resolve the conflict in a short time while satisfy applications preferences. If the resolution guarantees to find the global optimal to maximize total utility but takes too long, users will be annoyed by the late response. On the other hand, if the resolution resolves conflict very quickly but does not meet applications goals, users will be confused about the resolution result.
Either factor is important.
Therefore, we examine our algorithm with these two factors by two metrics. The first one is the time. We calculate time of conflict resolution process. The second one is the utility ratio. The utility ratio is to compare the result from our auction algorithms and the result from the brute force method which gives optimal results.
36 CHAPTER 6. EXPERIMENT & RESULTS
The formulation is bellowed:
uratio = ua ub
where ua is the utility that auction method achieves, ub is the utility that brute force method achieves.
6.2.3 Evaluation Results
First, we investigate the time complexity of these different algorithms. n denotes the number of applications. m denotes the number of actuators. k denotes the number of actions of each actuator. The time complexity of brute force is exponential. Auction algorithms are polynomial time. The time complexity of multi-round auction is O(nm2). If we consider action into account, the time complexity will be increased by k. The time complexity table is summarized in 6.1.
We use the tuple (n, m, k) to denote the setting of the simulation. We run 500 times to get the average result for each setting. The first setting (10, 6, 6) contains 10 applications and 6 actuators. Each actuator has 6 actions. The performance of random is about 44%. The performance of multi-round is about 84%. By using auction, the performance increases to 96.7% which is two times higher than random.
We can see that considering action indeed synergizes applications and gets a more satisfying result. If we enable rebidding, the performance further increases to almost 97%. Rebidding let applications change their mind and modify the previous result which leads to a better outcome. The performance is shown in Table 6.2.
The second setting (10, 6, 13) contains the same number of applications and
6.2. EVALUATION 37
Table 6.1: Time complexity
Algorithm Time Complexity
Brute Force O(nkm)
Multi-Round O(nm2)
Multi-Round with Action O(nkm2)
Table 6.2: Experiment result (10, 6, 6)
(10, 6, 6) avg uratio std uratio
Random 43.96% 0.228
Multi-Round 84.20% 0.104
Multi-Round with actions 96.72% 0.028 Multi-Round with actions & rebidding 96.97% 0.027
actuators as the previous setting, 10 and 6 respectively. We increase the number of action to 13. The result is almost the same as the previous setting. Multi-round still achieves high performance. The result in shown in Table 6.3.
38 CHAPTER 6. EXPERIMENT & RESULTS
Table 6.3: Experiment result (10, 6, 13)
(10, 6, 13) avg uratio std uratio
Random 44.05% 0.221
Multi-Round 84.80% 0.090
Multi-Round with actions 97.60% 0.021 Multi-Round with actions & rebidding 97.77% 0.019
Chapter 7
Conclusion and Future Work
IoT is a fast growing area. It enables objects around us to communicate with each other, as well as to connect to servers and human users. Many developers are creating new applications to access these objects to provide next generation services to make our lives better. However, multiple applications may need to control smart things at the same time for different purposes. The resource conflict must be resolved to provide adequate services to all users.
In this work, we propose to resolve conflicts by leveraging auction mechanisms.
We use the auction mechanism to coordinate applications to share actuators. We examine different auction algorithms and compare the performance with the brute force method and the randomly generated method in both time efficiency and utility ratio aspect. From the result we can see the auction protocols are quite effective to achieve a good system utility. We also give the design on how to implement the resource conflict resolution protocols in the actual IoT middleware that we are
39
40 CHAPTER 7. CONCLUSION AND FUTURE WORK
developing.
For future work, we can consider the environmental state transition to become non-deterministic. When an actuator performs an action, it might lead to different states with a probability. The problem will become more complicated. Applications need to consider the probability and evaluate the expected utility of performing an action. However, it will also be interesting to model the probability into the problem. Another direction is to implement the design in the real IoT middleware to evaluate the performance of the conflict resolution in real world.
Bibliography
[1] S. Airiau and U. Endriss. Multiagent Resource Allocation with Sharable Items: Sim-ple Protocols and Nash Equilibria. In Proceedings of the 9th International Conference on Autonomous Agents and Multiagent Systems: Volume 1 - Volume 1, AAMAS ’10, pages 167–174, Richland, SC, 2010. International Foundation for Autonomous Agents and Multiagent Systems.
[2] L. Capra, W. Emmerich, and I. C. Society. CARISMA : Context-Aware Reflective mIddleware System for Mobile Applications. 29(10):929–944, 2003.
[3] P. Cramton, Y. Shoham, and R. Steinberg. Combinatorial Auctions. MIT press, 2006.
[4] F. C. Delicato, P. F. Pires, T. Batista, E. Cavalcante, B. Costa, and T. Barros. To-wards an IoT ecosystem. Proceedings of the First International Workshop on Software Engineering for Systems-of-Systems - SESoS ’13, pages 25–28, 2013.
[5] A. Dounis and C. Caraiscos. Advanced control systems engineering for energy and comfort management in a building environment—A review. Renewable and Sustain-able Energy Reviews, 13(6-7):1246–1261, Aug. 2009.
[6] J. Gubbi, R. Buyya, S. Marusic, and M. Palaniswami. Internet of Things (IoT): A vision, architectural elements, and future directions. Future Generation Computer Systems, 29(7):1645–1660, Sept. 2013.
41
42 BIBLIOGRAPHY
[7] S. Koenig, C. Tovey, M. Lagoudakis, V. Markakis, D. Kempe, P. Keskinocak, A. Kley-wegt, A. Meyerson, and S. Jain. The Power of Sequential Single-item Auctions for Agent Coordination. In Proceedings of the 21st National Conference on Artificial Intelligence - Volume 2, AAAI’06, pages 1625–1629. AAAI Press, 2006.
[8] K.-J. Lin, N. Reijers, Y.-C. Wang, C.-S. Shih, and J. Y. Hsu. Building Smart M2M Applications Using the WuKong Profile Framework. 2013 IEEE International
[8] K.-J. Lin, N. Reijers, Y.-C. Wang, C.-S. Shih, and J. Y. Hsu. Building Smart M2M Applications Using the WuKong Profile Framework. 2013 IEEE International