Abstract
Context reasoning is an important issue for a context-aware system. Generally, context reasoning is adopted to deduce new context based on the available contexts. The rule-based reasoning is one of the most well-known methods for context reasoning. However, it is difficult for the rule-based algorithm to reason personalized context, because it requires a large number of rules to apply the user's preferences. To address this weakness, in this paper we suggest the Profile-Applied Reasoning Engine (PARE). PARE is an enhanced rule-based reasoning method which uses profiles while reasoning contexts. By using profiles, PARE can become aware of the context that is preferred by a specific individual. To validate the effectiveness of the proposed reasoning engine, we compared the reasoning result of PARE with traditional rule-based reasoning in smart home domain. PARE shows better outcome for reasoning the personalized contexts than the traditional rule-based reasoning. In addition, by using profiles, a significant number of rules have been omitted and consequently the running time is also decreased. Moreover, PARE occupies less memory space which is restricted with number of variables of a rule. Therefore, PARE optimizes both runtime and memory space, which is valuable when making embedded context-aware system.
1. Introduction
One of the major challenges in context-aware systems is to provide personalized context that represents the user's current state more accurately. Obviously, it is more effective to provide personalized services to the user by knowing the user's current state. In this regard, context reasoning uses context data in an intelligent way to infer a further high-level context, which is the most attractive contemporary research trend.
Context reasoning generally refers the process of deducing new and relevant information from various sources of context data [1]. However, in our paper, reasoning is performed by combining the low-level contexts and the high-level contexts hierarchically to map further into a high-level context. The low-level context is generated from sensed raw data and the high-level context is produced by context reasoning.
Generally, a context-aware system has a three-layer hierarchy structure [2–4]. In the first layer, environmental data is sensed using a sensor network. In the second layer, contexts are generated in two steps. Firstly, the low-level context is generated from raw sensed data and, secondly, the high-level context is generated by the reasoning method. In the third layer, the application provides context-aware services based on the available contexts. We will concentrate our discussion on the reasoning algorithm for inferring high-level context.
In recent years, most research has focused on personalized context-awareness and services [5]; however, personalized contexts have not been able to be recognized, unless the rules are defined for each individual. Furthermore, previous rule-based reasoning algorithms have better reasoning performance in the case of runtime but require plenty of memory space. However, we introduce a reasoning algorithm which optimizes both runtime and memory space, a user profile that gives the user's preference for each context, and the convergence of the reasoning algorithm and the user profile for the advanced context-awareness.
To develop a context-aware system, many researchers have adopted rule-based reasoning [6–8]. The rule-based method uses user-defined rules to recognize further high-level contexts. This method generates the same context under the same conditions, including user state, environment, and device state. One of the major aims of developing context-aware system to provide personalized service by reasoning personalized context which needs a bunch of rules. This is because there is a probability that the context can have different conditions for each individual. For example, some people prefer a light environment for a “sleeping” context, while others prefer a dark environment. While the simplest way to address this weakness is to define personalized rules for every individual in the domain, this results in a lack of flexibility and a massive size for the rule base.
In this paper, we present a reasoning method, called the Profile-Applied Reasoning Engine (PARE) to reflect the users' characteristics and preferences for context-awareness. While PARE is developed based on the traditional rule-based reasoning algorithm, it has been enhanced by integrating user profiles in its reasoning process. PARE resolves the drawback of traditional rule-based reasoning method by omitting a number of rules to infer personalized contexts. User preferences on a particular contexts and services are defined in a user's profile. As a result, different rules do not need to be defined for different preferences. This means that PARE needs fewer rules and consequently less runtime. Moreover, it uses less memory, since memory is restricted according to the number of variables of a rule. Therefore, PARE optimizes both runtime and memory space, which is more valuable for making embedded context-aware system. We tested PARE in a smart home environment and the results were better than those of the traditional rule-based algorithm.
The remainder of this paper is organized as follows. Related works are discussed in Section 2. Profile-applied reasoning architecture is explained in Section 3. Section 4 presents the reasoning algorithm and shows how user profiles are used. Section 5 presents the experimental results of PARE with performance evaluation and Section 6 covers conclusions along with the constraints of PARE and indications of future work.
2. Related Works
In a context-aware system, reasoning is primarily used to deduce new context from available contexts. Several reasoning methods are used to build a context-aware system. Among them, rule-based reasoning is the most well-known. First-Order Logic (FOL) rules are commonly used to reason about context for building context-aware services [9]. In this regard, context information is represented as first-order predicates, where the name of a predicate is the type of context described, and high-level context is deduced from raw context data using a predefined set of rules [10]. This method reevaluates the rules, whenever a change occurs in the current context of the system and the previous context is replaced by the currently reasoned context. Context information can also be represented as instances of ontology. In this case, corresponding software modules are used to retrieve context information from ontology and to derive new contexts using FOL rules [8, 11, 12]. A combination of Description Logics and Logic Programming reasoning is proposed in Semantic Context-Aware Access Control Framework [13]. In this framework, two types of rules are defined: the context aggregation rules to support reasoning using property path relationships and the context instantiation rules to provide OWL assertions for attribute values.
In all of the above research used rule-based context reasoning. However, they do not provide profile integration for inferring a personalized context that may be needed to define a large number of rules. This means that different rules are required to present different preferences within the same context. Hence, integrating profiles to infer a personalized context is an effective method to overcome this issue. The profile is able to provide information on individual needs and preferences for contexts and services. It is possible to recognize a user's taste in a particular context by using a profile; consequently, it is possible to provide high quality services that are derived from more accurate context-awareness. Moreover, profile-applied reasoning requires fewer rules (called basic rules), and these are applicable for every user in the domain.
An attempt has been made to adopt a user profile specifically to assist users to purchase various items [14]. User profiles in the system contain a list of purchase histories of each shopping situation, and this profile is updated automatically. However, this is only performed to calibrate the quality of a service rather than to recognize the personalized context more precisely. To overcome this problem, we have introduced the reasoning engine PARE which combines a profile with rule-based reasoning for a better outcome. We used forward chaining algorithm to find a high-level context from available contexts and a backward chaining algorithm for validation of the previously generated high-level context. Using the profile, we implemented a similar context-aware system with fewer user-defined rules, and the PARE provides a better outcome with which to infer the personalized context than the traditional rule-based reasoning.
3. Profile-Applied Reasoning Architecture
The profile-applied reasoning architecture is a collection of modules that work together to infer a high-level context from available current contexts and maintain context consistency. To develop the Profile-Applied Reasoning Engine (PARE) module, we improved the traditional rule-based reasoning algorithm by integrating user profile to infer a more accurate personalized context and to reduce the number of rules, consequently reducing runtime. The functional block diagram of the reasoning architecture is shown in Figure 1.
Block diagram of the profile-applied reasoning architecture.
In this architecture, a low-level context is added to Working Memory (WM) through the Context Inspector (CI) module, where a low-level context is generated from the sensed data by the related module of a context-aware system. Then, the reasoning process is applied to compute the high-level context. Contexts are classified as low-level and high-level based on how the context is created. On the other hand, based on how the context is represented, the contexts in PARE are either existential or relational; a detailed description is given in Section 4.1. Finally, the available contexts are conveyed to the service layer to compose and provide appropriate services to the user. In the following subsections, we briefly describe several parts of this reasoning architecture with their functions.
3.1. Context Inspector
The Context Inspector (CI) verifies low-level and high-level contexts before they are added to the WM. It determines whether any new context duplicates the existing context or not in WM. CI adds the context if the context is not available in WM or modifies a previous context to change it to the new context if the new context is an updated version of the previous context; otherwise, it discards the context. Therefore, this module plays important role to maintain context consistency by preventing context duplication.
3.2. Working Memory
To perform context reasoning, temporary storage is needed to hold available contexts for a current time. WM is traditionally used in many other reasoning systems in this way. In our system, WM is a list of current contexts which are added by CI. If any change is detected in the WM, the PARE is invoked to compute a high-level context from the available contexts. The contexts of WM are then sent to the service layer to provide services based on those contexts.
3.3. Rule
Rules need to be produced for the high-level context. We developed our own rule syntaxes in PARE. One of our goals is to enable the users to define the rules if necessary. Therefore, we made the syntax as simple as possible as shown in Box 1. The rules are stored in a text file, called rule base. Each condition for a rule is connected with “∧” character to mean logical “and.” In addition, several characters have a question mark “?”. They represent variables into which instances can be plugged. If all the conditions are true, then the context in the next line which is next to “then” is fired. PARE performs a reasoning based on rules and produces only high-level contexts.
Rules for reasoning high-level context (1) if person(?p)
hasstatus(?p, none)
then hasstatus(?p, sleeping)
(2) if person(?p) morningcall)
then hasstatus(?p, wakeup)
(3) if person(?p)
hasstatus(?p, none)
then hastatus(?p, watchingtv)
(4) if person(?p)
then hasstatus(?p, washing)
(5) if person(?p)
then hasstatus(?p, eating)
Box 1: Partial list of user-defined rules.
3.4. Profile Manager
The Profile Manager (PM) is built to handle the profiles. PM loads all users' profiles and retrieves their preference information. Whenever PM is called during the reasoning process, PM returns the preference information for better accuracy of reasoning.
3.4.1. User Profile
The user profile is able to provide the information which delivers individual needs and preferences [14]. The collection of profiles is called the profile base. The main purpose of the user profile in a context-aware system is to refer user's preference for contexts and services. In this paper, the profile provides context preferences that subsequently affect services, although previous works only contain user preferences for services [15–18]. The preference of a context refers to the user's choice for that context. For example, we could consider the state of sleeping. Most people prefer to sleep in a dark room, while some prefer to sleep in a lighter room; both situations still refer to the state of sleeping. Similarly, different users have different choices on the time of the day when they consume a meal. A major goal of PARE is to recognize this type of context and suggest a methodology for using the user profile. In this paper, the profile, written as an XML file that is not only easy to build and parse but also well-structured to read, is shown in the example in Box 2.
<?xml version= - <ca:user_profile xmlns:ca= xmlns:xsi= xsi:schemaLocation= <ca:user_identity> - <ca:user_context> - <ca:sleeping> <ca:illuminance> </ca:sleeping> - <ca:eating> <ca:time> </ca:eating> </ca:user_context> </ca:user_profile>
Box 2: User profile for context preference.
3.5. Profile-Applied Reasoning Engine (PARE)
The PARE is responsible for inferring the new high-level context as well as checking the validity of the previously generated high-level contexts. It begins reasoning process whenever a context is added or modified in WM. The internal structure of the PARE module with major functional components is depicted in Figure 2.
Internal structure of PARE.
3.5.1. The Matching Rule
The Matching Rule module coordinates the task of context reasoning. It finds and lists up the rule's variables and the corresponding instances of those variables according to current contexts. Listed variables with instances are used in subsequence module to infer high-level context. This module then invokes the Find Match module to determine whether or not the rule is satisfied with current contexts. The Matching Rule module receives high-level context from the new context list of the Find Match module and sends them to the CI to add to the WM. The Matching Rule module repeats the above steps for each rule in rule base. After that, it calls the Validator module to check the validity of the existing high-level contexts.
3.5.2. The Find Match
Whenever the Find Match module is called by the Matching Rule module, it begins to find the matches by substituting each variable of the rule with corresponding instances. If there is a variable with no instance, this module immediately returns false by terminating the matching process. If the current variable has any instance, then it substitutes the instance and moves to next variable for substitution accordingly. Once all variables are substituted, the Find Match module starts to look up the WM to see if all conditions are satisfied. If no matches are found for the current combination, then the substituted instances are modified by the Adjust Profile module according to the user profile and again matches the rule with the current contexts in WM. Whenever the rule is satisfied with current contexts, the Find Match returns true and stores “then part” of the satisfied rule in the new context list; otherwise it returns false indicating the rule is not satisfied. These processes are run recursively so that all possible outcomes can be examined with other combinations. The Find Match module plays the main role to infer a high-level context. It uses forward chaining algorithm and integrates the profile for better reasoning performance. This algorithm is discussed in Section 4 in detail.
3.5.3. The Adjust Profile
The Adjust Profile module integrates profile information with the reasoning process, where profile information is provided by the Profile Manager module. The user profile specifies user preferences in particular contexts, and the Adjust Profile module temporarily modifies the rule to infer a personalized high-level context that increases the context reasoning accuracy.
3.5.4. The Validator
After finding matches of each rule, the Validator module checks whether or not the previously generated high-level context is still valid. When the condition for a high-level context is failed, the high-level context is changed to its default state or initial state. A backward chaining algorithm is used to check context validity.
4. Profile-Applied Reasoning Algorithm
Since context reasoning is a process of obtaining new context from available current contexts, a production method is needed that keeps adding new high-level contexts to the set of existing current contexts. Strong formalism of the context and usage of a rule-based system forces PARE to use a forward and backward chaining algorithm to deduce and induce the high-level contexts, which is related to pattern matching work. In our case, all possible matches must be found as the pattern matching operates, which means all combinations of given contexts for specific rules need to be tested, and this is how traditional expert systems tested for reasoning. The traditional reasoning is still a promising method if the size of the rule base and WM are small enough to avoid the running time issue. However, by using profile, PARE optimizes all accuracy, space, and runtime suited for an embedded system. Hence, we improved the traditional rule-based reasoning by integrating profile in the following two ways: (i) improving the reasoning accuracy and (ii) reducing the number of rules as well as running time.
4.1. Context Representation
For the PARE, context is represented either as existential context (EC) or as relational context (RC). The EC is the existence of an entity in a specific domain, and its format is Concept(Instance name), for example, person(John). The RC is displayed as Relation(Subject, Object or Value), for example, locatedin(John, bedroom1) or hasstatus(John, sleeping). In this context representation, the terms Concept, Instance, Relation, Value, and Object are similar to the terms which are used in both Description Logic (DL) and First-Order Predicate Calculus (FOPC). The terms also use meanings closer to those in the Web Ontology Language (OWL), where Concept is also called class, which is a collection of the same types of instances. Instance, an individual in DL, is an instantiated unique entity obtained by concept in the domain. A Relation is a link between two entities or an entity and the attribute that defines the relationship which represents how one instance interacts with another. Moreover, Value is literally numeric or string representation of the subject's state.
4.2. Reasoning Process
As we mentioned in previous section, the reasoning engine runs whenever any context is added to WM or any update of the context in WM is detected. If a new context is added as a result of the reasoning, the reasoning engine runs again. This is because the new context changed WM, which can lead to producing further new context in a specific domain. This procedure is intended to be repeated theoretically, so chaining algorithms such as forward and backward chaining algorithms are required for its operation. These are traditional approaches used in the previous production and context-aware systems which are based on rules. When any change is found in WM, the PARE loads a list of rules defined in the rule base and then starts to find matches from WM using the Find Match module. Every rule has variables, and each variable represents instances of some concepts. The reasoning process is described in the following with an example.
In the rule for sleeping state, let person(?p)∧bedroom(?br)∧locatedin(?p, ?br)∧hasilluminance(br, dark) be defined as part of the rule. In this case, the variable, ?p, is mapped to the person and the other variable, ?br, is mapped to the bedroom. Therefore, in the case of John with his location in bedroom1, the rule is modified temporarily to person(John)∧bedroom(bedroom1)∧locatedin(John, bedroom1)∧hasilluminance(bedroom1, dark). Figure 3 shows the possible cases for sleeping state with two bedrooms and three users.
Possible outcomes from the given information for sleeping state.
Once the substitution is complete, the Find Match module begins to find matches of each rule's condition with the current contexts in WM. If the rule is not satisfied, the Adjust Profile module finds the user who is related to the modified rule; the corresponding user profile is then loaded, and the user's preference is applied by substituting the instance or value in the contexts. The further modified rule is person(John)∧bedroom(bedroom1)∧locatedin(John, bedroom1)∧hasilluminance(bedroom1, dim) by substituting dim instead of dark according to the user profile, presented in Box 2. After the modification has been performed, the Find Match module again begins to find the exact contexts that are the same as each modified condition in the rule and available in WM. Whenever the rule is satisfied, the Find Match module returns true indicating that a match is found and stores “then part” of the rule in the new context list. In next step, the Matching Rule module receives high-level context from new context list and passes to CI to be added to the WM. Figure 4 shows the Find Match process of profile-applied reasoning.
Flowchart of profile-applied reasoning algorithm.
Algorithm 1 presents a pseudocode of the Find Match module that is the main part of the reasoning engine.
(This is a simplified pseudo code of the algorithm in which- (i) An instance is an individual of the concept in the domain. For example, John is an instance of a concept person. (ii) A variable represents any instance of a concept. For example, person(?p), here ?p is a variable which can be mapped to any person in the domain, that is, John, Kelly, and so forth. (iii) The profile defines the user's preference for each context. For example, Algorithm 1 shows that John preferences for illuminance are dark, gloomy, and dim. (iv) A rule is a production rule similar in FOPC. Several conditions are combined by “∧” to form a rule. (v) (vi)
Algorithm 1: Profile-applied rule-based reasoning.
5. Experimental Result and Performance Evaluation
To demonstrate the effectiveness of this reasoning engine, we evaluated the use of PARE in a smart home domain. In addition, Java is used as the implementing language. The PARE algorithm is installed on a residential gateway together with other sensing and low-level context generating modules of a context-aware smart home system. The smart home consists of the two bedrooms, a living room, a bathroom, and a kitchen and the every location of the smart home is fitted with wireless sensor nodes which are equipped with temperature, humidity, CO2, illuminance, magnetic, smoke, PIR, pressure, and so forth sensors. Wireless sensor nodes of the smart home are connected to a sink node using Zigbee protocol, whereas the residential gateway communicates with the sink node using TCP/IP protocol. The sensing module reads sensor data and makes data packet from those data when an event occurs, for example, when a user enters into a new location in the home or if there is a significant change in the sensed data. Then, low-level context generating module generates low-level context from data packet and conveys it to PARE for inferring high-level context. To examine the accuracy of the reasoning engine, a selective scenario was considered based on the daily life in smart home, where initially at night the user enters bedroom1, turns off the light, and lies on the bed to sleep. However, although the light is off, the room is not completely dark because some streetlights are located close to the windows. The next morning, the alarm setting wakes up the user and he moves to the bathroom to take a shower. He then enters the kitchen for a meal and then leaves for school. After school, he returns home and enters bedroom2 to complete his homework. He then enters the living room and watches TV sitting on the sofa. Finally, later that night, he again enters bedroom1 to sleep.
5.1. Profile-Applied Reasoning Outcome
To observe the improvement in terms of the accuracy of context reasoning, we ran two types of reasoning: reasoning in which user profiles are applied and reasoning without the user profile. We chose sleeping state to bring user's preference for context.
To compare the reasoning performance of the profile-applied rule-based method and the traditional rule-based method, WM with specific contexts are given as follows:
person(John) cellphone(01033334444) has(John, 01033334444) hasstatus(John, none) livingroom(livingroom) entry(entry) bathroom(bathroom) kitchen(kitchen) bedroom(bedroom1) bedroom(bedroom2) outside(outside) desk(desk1) chair(sofa1) placedin(desk1, bedroom2) placedin(sofa1, livingroom) hastemperature(bedroom1, mild) hashumidity(bedroom1, moderate) hasilluminance(bedroom1, bright) hasco2(bedroom1, verylow).
In addition, assume that the user named John prefers the illuminance of dark, dim, and gloomy for sleeping, which means he can sleep in both a dark and a lighter environment. According to his preference, the user profile is given in Box 2. The sample data packets used to simulate the sleeping state are given in Table 1. Considering that the data packets are then converted to the context by the low-level context generating module of the context-aware smart home system and added to the WM through CI, in Table 1, sensed data is presented using a predefined data format. In this format, first letter indicates categories of data; for example, “E” means environmental data, that is, temperature and illuminance. The value in second position indicates ID of a person or location which is followed by actual sensed data.
Sample input data and corresponding context of the scenario.
Most of the high-level contexts related to smart home service focus on defining the user's state. The user performs a number of activities in smart home which represent user state such as sleeping, wakeup, eating, studying, washing, and watchingtv. Hence, we built user-defined rules that consider inferring only the user states, and some of these rules are listed in Box 1. If none of the rule is satisfied with current contexts in WM for a user then the user state changes to none, which is the initial state. The partial WM for a particular time is presented in Table 2 with the reasoning outcome. In rule number (1) of Box 1, the value of illuminance is set as dark for sleeping, but Table 2 shows the illuminance value in bedroom1 as being dim. Generally, the rule is not satisfied with WM, because the illuminance in bedroom1 is not dark. But, using the profile-applied reasoning method, the inferred high-level context is hasstatus(John, sleeping) because the user profile states that one of John's preferences is dim for illuminance. On the other hand, the traditional method failed to detect the user preference, so it infers hasstatus(John, none). To provide the same outcome, traditional rule-based method needs as many rules as user's preferences on illuminance. Similarly, the eating state can also be inferred more effectively using profile. The Box 2 also states that John has several choices on eating time that are breakfast, morning, lunch, evening, and dinner. That means John can go to kitchen at any of the mentioned times for eating. The rule number 5 defines that a user state will be eating if his location is in kitchen, kitchen chair pressure is on, and it is breakfast time. Using this rule, traditional algorithm cannot infer a user state eating at other times except breakfast time. To infer eating state at other times, the traditional algorithm needs to define different rule for different time. But applying profile, proposed algorithm can infer user state eating at breakfast, morning, lunch, evening, and dinner time using this rule only. Here, it is relevant to mention that we divided a day into eight time slots such as night, dawn, breakfast, morning, lunch, afternoon, evening, and dinner. In this way, applying a profile to different contexts, proposed method can show a significant promising reasoning result superior to the traditional method. This could enhance the reliability of the system, which is an important factor in the realistic usage.
Outcomes of reasoning about user state and WM after experiment.
5.2. Performance Evaluation
The function proposed in Algorithm 1 stretches the depth recursively when considering different variables and backs off when the modified rule is false. This characteristic limits the depth of this function, which is proportional to the number of variables, thus restricting the required size of memory. Therefore, it uses a limited memory space that is more valuable for making an embedded system in a small domain such as smart home.
Applying the profile, a number of rules can be reduced to catch the user's preferences in context because the system needs only basic rules that are applicable for all users. This means that only a single rule is required to infer a single state for all users, although the users have different preferences in different contexts. On the other hand, for the same outcome, the traditional algorithm needs the number of rules equal to the different preferences in the different contexts of the basic rule for different users, which increases its runtime. Therefore, it is obvious that the proposed algorithm needs fewer rules as well as less runtime, as shown in Table 3.
Comparison of time complexity between proposed and traditional algorithm.
(i) n is the number of contexts in WM.
(ii) m is the number of variables in a rule.
(iii) x is the number of instances for each variable.
(iv) d is the total number of different preferences of different users for variables m.
For testing the performance of these algorithms, sensing data from the test-bed smart home are collected based on the above-mentioned scenario and stored in the database. Both the proposed and traditional reasoning algorithms are used to infer the high-level contexts with the stored dataset. The runtime for each algorithm is measured several times. The average runtime for both algorithms with respect to the number of data packets is plotted in Figure 5, which shows that the proposed algorithm has less runtime than that of the traditional algorithm.
Comparison of runtime between traditional and proposed reasoning algorithm.
6. Conclusions
We introduced an enhanced context reasoning engine using user profiles for advanced context-awareness. The purpose of the development of PARE is to increase the accuracy of the reasoning for personalized services. PARE uses user profile while inferring high-level context and mitigates the shortcomings of the traditional rule-based algorithm to reason personalized context. Considering user preference is a primary concern in a context-aware system, to apply user preference, traditional rule-based algorithm needs a bunch of rules presenting each preference. On the other hand, proposed algorithm can handle this issue effectively using user profile with reduced rule set. Therefore, by using a user profile, the number of defined rules has been reduced and consequently the running time is also reduced. In addition, the depth of the proposed algorithm is restricted by the number of variables that means this algorithm occupies less memory. However, the PARE still needs some improvements since the profiles are static, which means they do not change once created. Although the running time is reduced compared to the traditional algorithm, there is a scope for further improvement of its running time.
To provide contexts that are more reliable, user profiles must be changed over time. Reinforcement learning in machine learning is considered a solution for this problem because it is able to enhance the function by taking feedback. We assume that the responses given by users to the services could be helpful feedback to update user profiles so that better quality services can be provided.
A relatively slow running time is caused by a linear search to find all possible solutions by testing every possible outcome of contexts in WM. To boost the speed of reasoning, we need to develop a new data structure or utilize the existing data structure such as that of RETE to avoid approaching the problem linearly. When these two issues are resolved, by utilizing PARE, context-aware systems will provide faster and more accurate context-awareness for personalized services.
Footnotes
Competing Interests
The authors declare no competing interests.
Acknowledgments
This work was supported by the Industrial Strategic Technology Development Program (10041788, Development of Smart Home Service based on Advanced Context-Awareness) funded by the Ministry of Trade, Industry & Energy (MI, Korea). The present research has been conducted by the Research Grant of Kwangwoon University in 2016.