For the rest of the thesis, we first review related work in Chap. 2. We formally define the resource access requirement and the auction problem in our system in Chap. 3.
Chapter 4 presents our auction protocols for smart home IoT. The implementation design in the WuKong framework is shown in Chap. 5. We then present the simu-lation results in Chap. 6 to compare our protocols with other auction protocols in terms of resource utilities and execution time. The paper is concluded in Chap. 7.
Chapter 2
Related Work
In this chapter, we first show existing work that resolve conflicts in home automation systems. Then we show some multi-agent systems that utilize auction to coordinate agents in different domains.
2.1 Conflict Resolution in Home Automation
Some researchers have studied in resolving conflict in home automation. A common way to resolve the conflict is based on users’ preferences. The resolution should take the users’ preferences into account and decide what to do. The action to resolve the conflicts are taken according to the weighted users’ preferences. Different approaches have been studied on how to calculate the weights of the users. Some work chooses the action of the first priority while some considers all weighted preferences of users.
Shin et al.[16] propose a history-based approach to resolve conflicts. The system 5
6 CHAPTER 2. RELATED WORK
keeps the historical data and utilizes Bayesian theory to decide the priority of users.
User can use a tangible remote controller to send the feedback so the change of user preference is captured.
Park et al. [9] use a semantic ontology to represent the relationship between the environment context and the applications. The links between the context and the applications represent how the action will affect the context attribute, e.g., turn on the light will increase the lightness. The system calculates the weight by predefined users preference and decide which application get executed accordingly.
Thyagaraju et al.[19] resolves the conflicts when multiple users want to watch different TV channels. Users are required to provide their preferences on each chan-nel and their roles in the family to construct the user profile. The system uses these user profiles to calculate a weighted score for each channel when conflict arises. The channel with the highest score is selected as the output.
Petrushevski et al.[10] resolves conflicts in a lighting control system among mul-tiple users. Several lighting sources are located in different locations of a room sharing by users. When users have different preferences on the light sources, the system needs to decide how should the light sources perform. The system calculates the weighted average of preferred outputs of a light source. The distance between the user and the light source is considered as the weight of the user to control the light sources. The closer a user is to the light, the higher weight the user has.
2.2. COORDINATION IN MULTI-AGENT SYSTEMS 7
2.2 Coordination in Multi-Agent Systems
Auction has been used to coordinate multi-agent systems in different domains, in-cluding task allocation, exploration task.
Koenig et al. [7] use the auction mechanism on the robot exploration problem.
There are many targets separately in the environment that need to be visit at least once by robot agents. The robot agents are also separately around the environment.
The problem is to efficiently allocate the targets for each robot that minimize the total visited distances. They use sequential auction mechanism to coordinate agents.
Capra et al. [2] focus on the preference conflict on mobile application between several users. The users can use the same mobile application to communicate with each other. However, the application provides different communicate protocol. Each protocol has different quality of services and requirement. Each user has different preferences on each protocol. They use the auction mechanism to coordinate mobile agents to decide the protocol.
Chapter 3
Actuator Conflicts in IoT Applications
In this chapter, we first give a formal definition of our problem definition. Then we give our proposed methods in the next section. Finally, we give a example to see how our methods solve the problem.
3.1 IoT Application
In the future IoT environment, there will be lots of sensors monitoring the environ-ment and actuators controlling the environenviron-ment. An IoT application takes sensor data as input and produces operations to control the actuators. Sensors provide environment data and the application evaluates the environment state by its utility function. The utility function reports a score on the desirable degree of the current
8
3.2. RESOLUTION TIMING 9
environment. An application should always try to maximize its utility to satisfy users. When the environment is not what the application wants, the utility value will be less. Thus, the application will send out an operation for actuators to change the environment to maximize its utility.
When there exist multiple applications in the environment, these applications may send different operations to control the actuator for their different goals. There-fore, an actuator may receive more than one commands to perform. To serve ac-ceptable services to users, the actuator conflict resolution component is employed to resolve actuator conflicts. It takes all applications into account and make a final decision on what the operation should be. The whole process of IoT applications is shown in Fig. 3.1.
3.2 Resolution Timing
The conflict happens when the two applications want to perform two different actions in an actuator. An action is to keep a state in an environment. For example, the action turn on, is to keep the environment light. On the other hand, turn off, is to keep the environment dark. The application sends the action only when it wants to change the state. Therefore, we can detect the conflict when two applications want two different states.
When the environment changes, the application evaluates the utility of the en-vironment. The application might send a new action to the actuator. The conflict might happen again and the resolution process starts again to resolve the process.
10 CHAPTER 3. ACTUATOR CONFLICTS IN IOT APPLICATIONS
Figure 3.1: IoT applications flow diagram with conflict resolution
3.3. PROBLEM FORMULATION 11
3.3 Problem Formulation
An actuator conflict resolution problem is defined as a tuple (s, M, (Ai)i∈M, δ, N , (ui)i∈N, (xi)i∈N)
• s denotes the environmental state. The environmental state is represented by a vector of context attributes values. s =< β1, β2, . . . , βt >. Each element in s represents the value of a context attribute. S denotes the set of all states.
• M = {1, 2, . . . , m} denotes a finite set of actuators.
• Ai denotes the set of actions that actuator i can perform. A denotes the set join action space or set of all operation, i.e., A =Qi∈RAi. We call α ∈ A an operation, i.e., α =< α1, α2, . . . , αm > where ∀i ∈ M, αi ∈ Ai
• δ : S × A → S is the state transition function that defines the transition between states by performing an operation. For a current state s and the operation α, it outputs the next state s0 that results from doing α in state s.
• N = {1, 2, . . . , n} denotes a finite set of applications.
• ui : S → R is the utility function for application i. The application uses the utility function to evaluate the utility for each state s ∈ S. The utility value stands how much the application likes the state. An application should always try to maximize its utility.
• xi : S → A is the decision function for application i. For any current environ-mental state s, an application would try to maximize its utility by finding an operation to control the environment, i.e., xi(s) = argmaxα∈Aui(δ(s, α))
12 CHAPTER 3. ACTUATOR CONFLICTS IN IOT APPLICATIONS
• Actuator conflict: the actuator conflict happens when two applications have different operations trying to control the same actuator with different actions in the same state, i.e., ∃i, j ∈ N , xi(s) 6= xj(s). In particular, ∃t ∈ M, αt,i 6= αt,j, the actuator t is in conflict by application i and j.
3.4 Problem Definition
To resolve the conflict, we coordinate the applications to decide on an operation α∗ that maximizes the utilities of all applications, which we call the total utility function. The total utility function considers all utilities ui of applications into account and gives one utility value for all applications.
α∗ = argmax
α∈A
U (u1, u2, . . . , un, s)
where U is the total utility function. How to derive the best total utility function is out of scope for this paper. In multi-objective optimization, a well-known method is called linear scalarization, i.e., the total utility is the sum of utilities of all appli-cations. Therefore, the problem is to find an operation α∗ to resolve the actuator conflict that maximizes the sum of utilities of all applications:
α∗ = argmax
α∈A
X
i∈N
ui(s)
To summarize, the problem we aim to solve is an actuator conflict resolution prob-lem. The output is the operation α∗. We make two assumptions. First, the number of actions are discrete and finite. Second, the environmental state transitions are deterministic
Chapter 4
Auction-Based Actuator Conflict Resolution
In this chapter, we first briefly review three resources allocation problems, includ-ing multi-agent resource allocation with shareable resources, multi-round sinclud-ingle- single-item auction, and combinatorial auction. We compare the differences between their problems and ours. Then, we adopt some of their ideas and propose our auction algorithms.
13
14 CHAPTER 4. AUCTION-BASED ACTUATOR CONFLICT RESOLUTION
4.1 Existing Resource Allocation Problems
4.1.1 Multi-Agent Resource Allocation with Shareable Re-sources
[1] has studied the resource allocation with shareable resources. They model the multi-agent resource allocation with shareable resources with congestion games. The more agents share a resource, the higher cost these agents will receive. Therefore, the agent should be reluctant to share the resource with others by nature.
There are a few different issues between their work and ours. In their case, agents are less willing to share resources with others. Because if it shares the resource, the cost will be higher. An agent has no incentive to share resources. In our case, although an actuator is a shareable resource, an actuator has different actions which are mutually exclusive. Some actions, however, may unite the applications with the same preference. The applications with the same preference can cooperate together to maximize their utilities. Applications are more willing to share an actuator with other applications that have the same preferences on the actuator.
4.1.2 Combinatorial Auction
Combinatorial auction is a powerful auction mechanism [3, 11]. The application bids on bundles. A bundle is a subset of the actuators. The application bids on the maximum utility that the bundle of actuators can bring to it. The auctioneer receives bids from all applications and determines the operation which maximizes the sum
4.1. EXISTING RESOURCE ALLOCATION PROBLEMS 15
of utilities of all applications. The total utility is optimal because a combinatorial auction considers the synergizes between actuators.
However, there are two issues which make it difficult to apply combinatorial auction to resolve actuator conflicts. First, for applications, it is hard to calculate the bids for all possible bundles because the number of the bundles is extremely large (exponential in the number of actuators and actions). Second, for auctioneer, it is hard to determine the result of the auction in a short time since the winner determine problem is NP-hard. Although some research focuses on finding an approximated result in an efficient way, we focus on the simple auction mechanism that prevents the system from being overly complex.
4.1.3 Multi-Round Single-Item Auction
In multi-round single-item auction, each application bids on each actuator and sub-mit bids to the auctioneer. Every application bids the actuator based on the how many utility the actuator can bring to the application. Only one actuator is sold in a round. The application with the highest bid wins the actuator and the actuator performs the action from the winner application. The auction continues the next round for the remaining actuators until all actuators are sold. Applications can change their bids between rounds. A winner application can control the actuator to affect the environment. As the environment changes, it affects applications and applications might change their minds to ask the remaining actuators to perform different action. When applications change their minds, they can also change their bids in the next round.
16 CHAPTER 4. AUCTION-BASED ACTUATOR CONFLICT RESOLUTION
Multi-round auction has been applied in other domain and has good results [7]. However, the mechanism can not be directly applied. The reason is that the auctioneer can’t correctly optimize the total utility due to the lack of information.
The bids only provide the information about the preference to the actuator, but not what action the application would like to perform. Each actuator has several actions, and each action has different effects on the environment. Therefore, the applications has different preferences on each action. We should investigate the preferences on actions to maximize the utilities of all applications.
4.2 Proposed Auctions with Actions and Rebid-ding
Combinatorial auction synergizes between goods but suffering exponential time com-plexity while multi-round auction has better time comcom-plexity and also synergizes between actuators. Multi-Agent Resource Allocation with Shareable Resources syn-ergizes between bidders. An action, which is shareable among applications, but exclusive in an actuator, makes the applications with similar preferences to work together to maximize their utilities.
We propose two auction algorithms considering the above issues. The first one is multi-round auction considering actions. The other is multi-round auction con-sidering actions and rebidding. The latter one is to consider rebid on actuators.
The rebidding makes it possible for applications to change previous results. As the auction process goes, not all applications can always get what they want. They may
4.2. PROPOSED AUCTIONS WITH ACTIONS AND REBIDDING 17
win in the first few rounds. However, they may lose some actuators and the envi-ronment may change to what they don’t like. In this situation, application might regret their previous decisions and want to change the actions. Rebidding provides the opportunity for the applications to change their previous bids.
In our study, we assume that each application doesn’t know other’s utility func-tion. Each application bids truthfully based on their utility funcfunc-tion.
4.2.1 Multi-Round Single-Item Auction considering Actions
Multi-round auction synergizes between actuators by letting applications bid differ-ently in the next round. When an action is determined in one round, applications take the fact and recalculate the operation to control the remaining actuators to maximize their utility. Therefore, the new operation will reflect on the new bids.
The auction works as follows: Each actuator is unallocated at first. Every ap-plication bids on each action of each unallocated actuator. The apap-plication bids the action based on evaluation of next state resulting from the action. The bids are summed up for each action. The actuator whose action is the highest bid is allo-cated. Then, each application bids the remaining unallocated actuators and repeat the process until all actuators are allocated. These actions are the final decision as the result. The algorithm is shown in Algorithm 1.
18 CHAPTER 4. AUCTION-BASED ACTUATOR CONFLICT RESOLUTION
Algorithm 1: Multi-round auction considering actions Input: A set of application N
Input: A set of actuators M
Input: Current environmental state s
4.2. PROPOSED AUCTIONS WITH ACTIONS AND REBIDDING 19
4.2.2 Multi-Round Single-Item Auction considering Actions and Rebidding
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
The original WuKong framework doesn’t support running multiple applications. In