WO2019245274A1 - 무선 통신 시스템에서 iot 장치를 제어하는 방법 및 장치 - Google Patents

무선 통신 시스템에서 iot 장치를 제어하는 방법 및 장치 Download PDF

Info

Publication number
WO2019245274A1
WO2019245274A1 PCT/KR2019/007371 KR2019007371W WO2019245274A1 WO 2019245274 A1 WO2019245274 A1 WO 2019245274A1 KR 2019007371 W KR2019007371 W KR 2019007371W WO 2019245274 A1 WO2019245274 A1 WO 2019245274A1
Authority
WO
WIPO (PCT)
Prior art keywords
rule
resource
ocf
category
priority
Prior art date
Application number
PCT/KR2019/007371
Other languages
English (en)
French (fr)
Inventor
김나명
김동주
백선희
이병주
Original Assignee
엘지전자 주식회사
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 엘지전자 주식회사 filed Critical 엘지전자 주식회사
Publication of WO2019245274A1 publication Critical patent/WO2019245274A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]

Definitions

  • the present invention relates to an Internet of Things (IoT) device and a method and apparatus performed in connection with an IoT device. Specifically, the present invention relates to a method and apparatus for controlling an IoT device.
  • IoT Internet of Things
  • OIC Open Interconnect Consortium
  • UPF Universal Plug and Play
  • the OCF standardization organization is developing technologies to provide IoT services and open platforms, such as communication between IoT devices and the use of the cloud. Planning.
  • An apparatus for providing a service according to the OCF standard includes a server for providing a resource and a client for accessing the resource.
  • An object of the present invention is to provide a method and apparatus for controlling the IoT device in consideration of an emergency situation.
  • the present invention provides a signal receiving method and apparatus in a wireless communication system.
  • a method performed by a device for controlling one or more Internet of Things (IoT) devices in a wireless communication system, and controls the one or more IoT devices based on a first rule.
  • the first rule resource includes a first rule category resource for indicating whether the first rule is associated with an emergency situation, and the second rule resource includes the second rule resource.
  • a second rule category resource for indicating whether a rule is associated with an emergency situation, wherein the first rule category resource indicates that the first rule is associated with an emergency situation, and the second rule category resource is the second rule. If the first rule expression is satisfied, a method of deactivating the second rule is proposed by activating a priority mechanism when the first rule expression is satisfied.
  • An apparatus is a device for controlling one or more Internet of Things (IoT) devices in a wireless communication system, comprising: a transceiver; And a processor controlling the transceiver; Wherein the processor is configured to control the one or more IoT devices based on a first rule resource and a second rule for controlling the one or more IoT devices based on a first rule.
  • the processor is configured to control the one or more IoT devices based on a first rule resource and a second rule for controlling the one or more IoT devices based on a first rule.
  • Set a second rule resource and perform a first rule action if a first rule expression in the first rule resource is satisfied, wherein the first rule resource is configured to perform the first rule action.
  • a first rule category resource for indicating whether or not it is associated with an emergency situation wherein the second rule resource includes a second rule for indicating whether the second rule is related to an emergency situation
  • the method and apparatus may set a third rule resource for controlling the one or more IoT devices based on a third rule, wherein the third rule resource indicates whether the third rule is associated with an emergency situation. And a third rule category resource for indicating that the third rule category resource indicates that the third rule is associated with an emergency, even if the first rule expression is satisfied and the priority mechanism is activated. The third rule may not be inactivated.
  • the first rule resource includes a first priority enable property to indicate whether the priority mechanism is activated, and the second rule resource determines whether the priority mechanism is activated. It may include a second priority active property for indicating.
  • the method and apparatus may terminate execution of the first rule action when the first rule expression is not satisfied, and activate the second rule by deactivating the priority mechanism.
  • the second rule action may not be performed even if the second rule expression in the second rule resource is satisfied.
  • first rule resource and the second rule resource may be included in one rule engine resource.
  • the deactivation of the second rule may be performed through a constraint on the second rule expression.
  • the IoT device through the definition of a new resource, there is an advantage that the IoT device can be more efficiently controlled in consideration of an emergency situation.
  • FIG. 1 is a diagram illustrating connectivity and interoperability of an OCF platform.
  • FIG. 2 is a diagram illustrating a framework structure of an OCF platform.
  • FIG. 3 is a diagram for receiving a request and a response between a client, an intermediary, and a server.
  • FIG. 4 is a diagram illustrating a protocol stack that can be supported by the OCF standard.
  • FIG. 5 is a diagram illustrating a wide range of functions that can be supported through OCF.
  • FIG. 6 is a diagram illustrating an example of performing a CRUDN operation.
  • FIG. 7 is a diagram illustrating an example of an OCF rule function.
  • FIG. 10 is a diagram illustrating an example of an OCF rule and a new function.
  • FIG. 11 is a diagram illustrating a problem caused by the operation of an OCF rule and a new function.
  • 26 shows a flowchart in accordance with an embodiment of the present invention.
  • FIG 27 shows an apparatus according to an embodiment of the present invention.
  • FIG. 1 is a diagram illustrating connectivity and interoperability of an OCF platform.
  • OCF defines a common platform that presents basic services and data models that enable us to connect and collaborate across verticals such as health, smart home and industrial IoT.
  • the OCF platform provides connectivity between the connectivity level, platform level, and service layer.
  • the OCF platform provides full interoperability through UX (user experience).
  • the OCF standard defines data structures, types for resources, properties, and interfaces.
  • the OCF standards include device authentication, security features, access control for resources in the OCF network, discovery of devices that can be included in the OCF network, and instructions for resources (CREATE, RETRIEVE, UPDATE, DELETE, and NOTIFY; CRUDN). ), A message for the resource, and a frame for connecting the OCF network and the Internet network (IPv6, etc.).
  • FIG. 2 is a diagram illustrating a framework structure of an OCF platform.
  • Conceptually shaped content which will be described below, may be about a resource model, a RESTful operation, or an abstraction, and may be a basic feature of an OCF operation and a standard.
  • the OCF device may support one or more roles of client, server and / or intermediary.
  • a role that an OCF device can support may be an area of a logical entity, and one OCF device may support one or more roles.
  • a 'device' may refer to a physical device including a logical entity, or may refer to a logical entity itself.
  • the client device refers to a device that performs a role of accessing resources of a server.
  • the server device refers to a device capable of providing resource state information and performing remote interaction with a resource.
  • the intermediary device refers to a device that provides an OCF proxy role. In other words, it is a device that performs an intermediary role in processing a request message for an OCF resource hosted by a server device.
  • the client may request the server for CRUDN operation on the resource.
  • the server may perform the CRUDN operation requested by the client.
  • Resource assignment and operation assignment between the client and server may be performed based on the RESTful resource model.
  • Intermediary can generate another request based on the processing configuration and return a response to the OCF server based on the request to process the OCF resource hosted by the other OCF server. have.
  • the resource model corresponds to the actual entity represented by the OCF resource.
  • CRUDN behavior between client-server originating from higher layers eg OCF client, OCF server
  • Constrained Application Protocol (CoAP) request and CoAP response from lower layer eg OCF device
  • XMPP Extensible Messaging and Presence Protocol
  • the CRUDN operation occurs between an OCF client and an OCF server.
  • the CRUDN operation may be transmitted and received via a signaling message called a CoAP request and a CoAP response (e.g. GET / s / data, ⁇ "bulb": “on” ⁇ ) through protocol mapping.
  • the CRUDN operation may be transmitted and received via hypertext transfer protocol (HTTP) and / or XMPP other than CoAP via protocol mapping.
  • HTTP hypertext transfer protocol
  • XMPP other than CoAP via protocol mapping.
  • the request and response between the client and the intermediary may be transmitted and received through HTTP, and the request and response between the intermediary and the server may be transmitted and received through CoAP. .
  • the encoding layer of the protocol stack illustrated in FIG. 4 supports a CBOR (Concise binary object representation based on JSON data model) by default. However, depending on the negotiation between the client and the server, JSON (JavaScript Object Notation) and / or XML / EXI (Efficient XML Interchange) may be used.
  • CBOR Concise binary object representation based on JSON data model
  • CoAP Discovery is used for discovery of the end point (IETF RFC 7252).
  • IPv6 For connectivity with the L2 layer, there is IPv6 for IoT devices.
  • a datagram transport layer security (DTLS) layer may exist on the user datagram protocol (UDP) layer.
  • DTLS transport layer security
  • TLS transmission control protocol
  • TCP transmission control protocol
  • FIG. 5 is a diagram showing functions that can be supported through OCF at a high level.
  • the L2 connectivity layer may use existing wireless communication technologies such as wireless fidelity (Wi-Fi), Bluetooth (BT) and / or Z-wave.
  • Wi-Fi wireless fidelity
  • BT Bluetooth
  • Z-wave Z-wave
  • the CRUDN operation is an operation that can be requested for a resource, and there may be five commands as shown in Table 2.
  • the server including the resource executes a CRUDN command for the resource.
  • the client sends a Create request to the server during the CRUDN operation.
  • the server that receives the Create command performs a Create on the resource.
  • the server transmits a response to the request received from the client to the client.
  • OCF defines rule functions and scene functions for convenient and efficient control of smart home devices.
  • the rule function refers to a function of performing a predetermined specific action when a rule condition is satisfied.
  • the scene function means a function of previously defining a state value according to a specific situation for a plurality of devices as a scene, and simultaneously changing the state values of a plurality of devices through one scene when necessary.
  • a rule and scene (rule plus scene, rule plus scene) function means a function that is a scene defined as an action defined when a rule condition is satisfied. . According to the rule and scene function, a specific scene is finally performed to update the state values of a plurality of devices defined in the scene.
  • the OCF smart home environment is a complex environment consisting of a plurality of rule functions and a plurality of new functions.
  • the new update may be automatically performed regardless of the user's intention.
  • the state value of a particular device may change beyond the intention or expectation of the user.
  • certain situations e.g. fire, invasion
  • An OCF rule is an OCF resource for implementing autonomous decision logic according to a predefined input-condition-action pattern.
  • the rule input is referenced as a property value of the selected resource instance.
  • the rule action is composed of a process of transmitting a predefined property value to a resource instance referred to by a dynamic link through an UPDATE operation.
  • An OCF rule includes one or more rule inputs.
  • the rule input consists of the values of the properties of the resource instance.
  • a rule expression is generated based on the resource referenced by the rule input.
  • OCF rules also contain a rule expression (or rule condition).
  • rule expression or rule condition
  • rule logic configured based on one or more predefined rule inputs may be defined. Evaluation of true / false values may be performed in a Boolean format, and it may be determined whether a rule expression is satisfied.
  • OCF rules also include one or more rule actions, or rule outputs.
  • Rule actions are resources for defining actions to be performed when rule expressions evaluate to true.
  • OCF rules also contain one or more dynamic links.
  • the dynamic link is a link for indicating an external resource in which a rule action corresponding to a destination of the rule input is used when the rule input is viewed as a source.
  • the OCF rule may include properties for indicating the status of the OCF rule.
  • the RuleEnable property is a property for determining whether or not the OCF rule is activated. In the boolean form, if the value of the rule activation property is True, the rule function can be activated. If false, the rule function can be deactivated.
  • the ActionEnable property is a property for determining whether the OCF rule action function is activated.
  • the action defined in the rule action can be performed only when the value of the action active property is true even if the condition by the rule expression is satisfied.
  • the RuleResult property is a property for indicating whether an OCF rule expression is satisfied. If the value of the rule result property is true, it indicates that the evaluation result rule for the rule expression is satisfied (true). If the value of the rule result property is false, it indicates that the evaluation result rule for the rule expression is not satisfied (false).
  • a rule expression is configured based on one or more rule inputs. If it is determined by rule evaluation that the rule expression is satisfied, the predefined rule action is performed. Rule evaluation may be performed whenever a value of a rule input property is changed.
  • FIGS. 8 and 9 are diagrams illustrating an example of an OCF new function and configuration.
  • OCF scenes are mechanisms for performing certain operating automation.
  • the OCF scene is a static entity for storing a set of predefined resource property values in advance.
  • the OCF scene provides a mechanism for configuring and storing a set of multiple resources hosted on multiple separate servers. Once an OCF scene is set up, it can be used immediately by multiple clients.
  • a plurality of resources constituting the OCF scene may be composed of scene list, scene collection, and scene member properties as shown in FIG. 8.
  • the scene list property is the top level resource of the resources that make up the scene.
  • the scene collection property contains a list of gods.
  • the list contains one or more scenes.
  • the scene member property includes mapping information between scenes and setting values of resource property values generated for each scene.
  • various scene lists are stored in a scene collection property.
  • the currently supported scenes and the most recently updated scenes can be identified through the Scene Values and LastScene property values in the scene collection properties.
  • an UPDATE request including a setting value for a predefined resource property value may be transmitted to devices (e.g. OCF servers) linked by a link.
  • FIG 10 shows an example in which an OCF rule and scene function are performed.
  • a scene change (or update) is triggered as the rule action.
  • the scene value is a rule action (or rule output)
  • the last scene property in the scene collection is updated if the rule is satisfied.
  • Scene updates can be set automatically by the OCF rule function. If scene update is set as a rule action, a scene update message is automatically triggered to the scene server when the rule expression is satisfied.
  • the OCF rule and scene function when automatic scene update based on the OCF rule function is set, the scene update is performed without considering the surrounding environment the moment the rule expression is satisfied. As a result, a scene transition different from the user's intention may occur, and an OCF scene operation previously performed to suit the user's intention may be invalidated.
  • the scene efficiency capability is reduced, and the device can be switched to a mode different from the user's intention. You may need a way to prevent conflicts between user intent and OCF rules and new features.
  • the first OCF rule is set so that a fire alarm (FireAlarm) scene is performed when a fire occurs within a predetermined range from the house (when a rule expression is satisfied).
  • a fire alarm scene is performed, the last scene property of the scene server is updated as a rule action.
  • the second OCF rule is set such that a low power scene is performed when energy consumption in the home exceeds a threshold.
  • the light 1, the light 2, the light 3 and the alarm may be updated to be turned on, and the resource may be updated to open the front door.
  • the light 1 is updated to turn on, but the resource can be updated to turn off the light 2, light 3 and the alarm, and to close the window.
  • the fire alarm scene may be performed by the rule action included in the first OCF rule.
  • the fire alarm scene illuminates lights 1, 2 and 3, the alarm for warning and the front door open. Considering safety, fire alarm scenes need to be maintained. The user may also want to maintain a fire alarm in an emergency situation.
  • the low power scene is performed by the rule action included in the second OCF rule.
  • Low-power scenes cause lights 2 and 3 to turn off, close the windows, and turn off notifications for warnings.
  • the rule category is to classify existing OCF rules in consideration of characteristics in order to provide a differentiated rule mechanism according to a situation.
  • OCF rules may belong to one of an emergency category and a normal category defined for an emergency.
  • An OCF rule belonging to an emergency category is an OCF rule of higher importance than an OCF rule belonging to a general category, and an operation related to an OCF rule belonging to an emergency category may follow a mechanism different from that of an OCF rule belonging to a general category.
  • An OCF rule belonging to the general category corresponds to an OCF rule of lower importance than the OCF rule belonging to the emergency category.
  • a rule category resource may be added in the rule resource as shown in FIG. 12.
  • the value of the rule category resource may be represented by a value (e.g. emergency or normal) indicating whether the corresponding OCF rule belongs to an emergency or general category.
  • the OCF rule belonging to another category may be deactivated.
  • the function of all other OCF rules in a rule engine to which the corresponding OCF rule belongs is deactivated, but other OCF rules belonging to the emergency category may not be deactivated.
  • the first OCF rule is set such that when a fire occurs within a certain range from the house (when a rule expression is satisfied), a FireAlarm scene is performed, and the second OCF rule sets an energy consumption amount in the house. If the threshold is exceeded, a LowPower scene may be set to be performed.
  • the first OCF rule may be classified into an emergency category because it needs to perform an action necessary for an emergency
  • the second OCF rule may be classified into a general category because it performs an action separate from the emergency.
  • the function of the OCF rule not belonging to the emergency category may be deactivated. Since the second OCF rule does not belong to the emergency category, the values of the rule active property and the action active property in the second OCF rule may be updated to false so that operations related to the second OCF rule may be deactivated.
  • the rule expression in the second OCF rule may be satisfied so that a low power scene may be performed before the fire alarm scene as a rule action. Since the second OCF rule belongs to the general category, only operations related to the second OCF rule are performed and the rule active properties and action active properties in the first OCF rule are not updated.
  • FIG. 14 is a diagram illustrating additional resources included in a rule resource.
  • a category action and a category enable property may be added in addition to the rule category resource.
  • a category list resource may be added separately from the rule resource.
  • the category list resource is a resource for classifying, managing and defining categories of all OCF rules defined in the rule engine. For example, an emergency category and a general category may be included in the category list resource. In addition, a category list resource may define which OCF rules are included in which categories. In addition, in the category list resource, an OCF rule belonging to a specific category may be defined which additional operation should be performed.
  • the rule category resource indicates which category the rule resource belongs to for each rule resource. Since the first OCF rule belongs to the emergency category, the value of the rule category resource may be emergency. Since the second OCF rule belongs to a general category, the value of the rule category resource may be normal.
  • the category action resource is a resource for defining an action performed when the category active property is enabled. When the category active property is true, when the rule action is performed, an operation defined in the category action resource may be performed together.
  • the category action resource may include a value for deactivating an OCF rule belonging to another category. Alternatively, the category action resource may include a value indicating that the additional action is not performed.
  • the category active property is a property for indicating an active state of a rule category function.
  • the rule category function is activated, and as described above, when the rule action is performed, an operation defined in the category action resource may be performed together. If the value of the category active property is false, only the rule action may be performed and the operation defined in the category action resource may not be performed even if the rule expression is satisfied.
  • the first OCF rule is set so that a fire alarm (FireAlarm) scene is performed when a fire occurs within a certain range from the house
  • the second OCF rule when the energy consumption in the house exceeds the threshold
  • the LowPower scene may be set to be performed.
  • Two categories, emergency category and general category, may be defined and included in the category list resource. Since the first OCF rule is a rule not to be used in an emergency fire situation, it may be included in an emergency category. Since the second OCF rule may operate regardless of the emergency, it may be included in the general category. Each category may include one or more other OCF rules in addition to the first and second OCF rules.
  • a category action for each category may be defined in the category list resource. As a category action of the emergency category, an action may be defined that changes the rule activity of an OCF rule included in a category other than the emergency category to an inactive state. An action may be defined that no additional action is performed as a category action of the general category.
  • the rule function of an OCF rule belonging to a category other than the emergency category is defined as defined in the category list resource and / or the category action resource in the first OCF rule. Can be disabled. Since the second OCF rule does not belong to the emergency category, the rule activation property value in the second OCF rule may be updated to false to deactivate operations related to the second OCF rule.
  • the category action may be performed only when the value of the category active property is true. When the value of the category active property is false, only the rule action may be performed and the category action may not be performed even if the rule expression in the first OCF rule is satisfied.
  • the rule expression in the second OCF rule may be satisfied so that a low power scene may be performed before the fire alarm scene as a rule action. Since the second OCF rule belongs to a general category, only operations related to the second OCF rule are performed and the properties in the first OCF rule are not updated. In addition to considering the emergency situation according to the characteristics of the OCF rule, the category action may be activated or deactivated by the user's intention.
  • the rule expression in the second OCF rule may be satisfied so that a low power scene may be performed before the fire alarm scene as a rule action.
  • the additional operation may not be performed as defined in the category list resource and / or the category action resource in the second OCF rule.
  • FIG. 15 is a diagram illustrating resources that may be further included in a rule engine.
  • FIG. 15 is a diagram illustrating resources that may be further included in a rule engine.
  • the rule engine may include a priority enable property.
  • the priority activation property may be used for priority mechanism operation in an emergency.
  • the priority mechanism can be used to deactivate all OCF rules belonging to a category other than a specific category in an emergency. For example, when an emergency category exists and an operation related to an OCF rule belonging to an emergency category is performed, the priority activation property may be toggled to true so that the priority mechanism may be performed. If all OCF rules belonging to the general category in the rule engine are deactivated by the priority mechanism, collisions between the OCF rules can be prevented. If there is an OCF rule deactivated by the user, duplicate deactivation of the deactivated OCF rule may not be performed when the priority mechanism is operated due to toggling.
  • a recovery mechanism can be used to reactivate OCF rules that were deactivated due to the operation of the priority mechanism.
  • the restoration mechanism can be performed. Based on the restoration mechanism, OCF rules previously deactivated by the rule engine may be updated to the activated state. However, if there is an OCF rule previously deactivated by the user, the OCF rule previously deactivated by the user may not be activated when the restoration mechanism is operated.
  • the following resources may be defined for the operation of the priority mechanism (or priority mode).
  • the rule category property is an attribute for indicating the purpose / characteristic of the OCF rule resource as described above. For example, it may indicate whether it belongs to an emergency category or a general category for each OCF rule resource.
  • Rule engine resources are top-level resources for managing and / or controlling one or more rule resources, respectively.
  • Rule engine resources include one or more rule resources, and one or more rule resources are managed as links.
  • the priority enable property is an attribute included in a rule engine resource and is an attribute for indicating whether the priority mode operation is enabled or disabled. Whether active / inactive can be indicated in a boolean form. If the value of the priority activation property is true, priority mode operation may be activated to deactivate OCF rules belonging to a general category. If the value of the priority activation property is false, OCF rules deactivated by the priority mode operation may be activated (or restored) again.
  • the rule active property in the rule resource may have a value indicating three states rather than two values as Boolean types. If priority mode is not supported, the rule enabled property has a value of type called simply indicating whether the OCF rule is enabled / disabled, but for the operation of priority mode, the OCF rule and priority mode deactivated by the user's intention. OCF rules deactivated by the operation of need to be distinguished. Therefore, when the priority mode operation is supported, the rule active property may be configured in a format for displaying three values. For example, the rule activation property may be configured as a bitmask type as shown in Table 4, and may indicate whether an OCF rule operation is active, inactive by a priority operation mode, or inactive by a user.
  • FIG. 16 illustrates an example in which a rule active property value is updated when the rule active property is configured as a bit mask type as shown in Table 4.
  • the priority mechanism is activated for emergencies.
  • OCF rules belonging to the general category and activated are updated to deactivated. Since the OCF rule is deactivated by the priority mechanism, the value of the rule active property may be updated to one. Since the OCF rule previously deactivated by the user is not deactivated in duplicate, the value of the rule active property is not changed from 2 to 1.
  • the priority mechanism If the value of the priority enabled property is toggled from true to false, the priority mechanism is disabled upon exiting the emergency. If the priority mechanism is deactivated, OCF rules that were deactivated due to activation of the priority mechanism are updated to the enabled state. OCF rules deactivated by the user are not updated to the enabled state. Because the value of the priority active property is toggled from true to false, the value of the rule active property with the value 1 is updated to 0, and the value of the rule active property with the value 2 is not updated.
  • the third OCF rule is inactivated by the user and is not controlled by the priority mechanism.
  • 17 to 19 are diagrams specifically showing an example of changing a resource according to a priority mechanism.
  • the first OCF rule (rule 1) is an OCF rule configured to perform a fire alarm (FireAlarm) scene when a fire occurs within a certain range from a home, and may belong to an emergency category.
  • a fire alarm FireAlarm
  • the priority activation property in the rule engine resource is toggled to true as shown in FIG. 17.
  • Priority mode is activated by toggling the priority activation property.
  • the function of the OCF rule belonging to the general category is deactivated.
  • the value of the rule activation property included in the second OCF rule (rule 2) and the fourth OCF rule (rule 4) is updated to 1 for deactivation. Since the value of the rule active property included in the third OCF rule is 2, it corresponds to the OCF rule deactivated by the user.
  • the third OCF rule is deactivated regardless of priority mode activation.
  • the fifth OCF rule (rule 5) is not deactivated because it belongs to the emergency category, and the value of the rule active property included in the fifth OCF rule is maintained at zero.
  • the priority activation property may be updated to false so that the restoration mechanism may operate.
  • OCF rules that are deactivated due to activation of priority mode are activated.
  • the value of rule active properties of the second OCF rule and the fourth OCF rule whose value has been changed to 1 is updated to zero.
  • the third OCF rule deactivated by the user is not activated by the restoration mechanism.
  • the value of the rule activation property of the third OCF rule is 2, which is a value indicating that the user has deactivated by the user, and thus is not updated to 0 by the restoration mechanism.
  • FIG. 20 illustrates the case where the priority activation property is included in the OCF rule resource, unlike the embodiment of FIGS. 17 to 19 included in the rule engine resource other than the OCF rule resource.
  • the rule category resource is a resource for indicating which category the OCF rule belongs to as described above.
  • the rule category resource may indicate whether the corresponding OCF rule belongs to an emergency category or a general category.
  • the emergency category may have a higher priority than the general category.
  • the priority activation property is a property for indicating whether the priority mechanism is enabled or disabled as described above.
  • the priority mechanism is activated and OCF rules belonging to the general category among the OCF rules defined in the rule engine may be deactivated.
  • the OCF rule not belonging to the emergency category may be deactivated. If an OCF rule is deactivated, the rule action is not performed even if the rule expression included in the OCF rule is satisfied. Even if the priority mechanism is activated, OCF rules belonging to the emergency category among the OCF rules defined in the rule engine are not deactivated or any function is limited.
  • the priority mechanism is deactivated, and previously deactivated OCF rules can be reactivated.
  • an OCF rule that has been deactivated regardless of the priority mechanism by the user may be maintained in the deactivated state regardless of the deactivation of the priority mechanism.
  • FIG. 21 illustrates an example in which a rule active property value is updated when a priority active property is located in an OCF rule resource as shown in FIG. 20.
  • Rule priority mechanism is a mechanism defined to perform different actions according to the attributes of OCF rules in an emergency situation.
  • a rule expression included in a high priority rule e.g. a rule belonging to an emergency category
  • the priority mechanism may be performed together.
  • the priority activation property value is updated to true and the priority mechanism is activated, OCF rules except rules belonging to the emergency category are deactivated.
  • the priority active property value may be updated to true by the user. Since the OCF rules belonging to the general category are deactivated until the priority mechanism is terminated, it is possible to prevent the operation of an unexpected OCF rule from being performed in an emergency situation.
  • the deactivated OCF rules can be activated again (or the restore mechanism is activated).
  • OCF rules deactivated separately from the priority mechanism may be maintained in the deactivated state regardless of the deactivation of the priority mechanism.
  • 22 to 25 specifically illustrate an example in which a resource is changed according to a priority mechanism when a priority activation property is included in an OCF rule resource.
  • the first OCF rule (rule 1) is an OCF rule configured to perform a fire alarm (FireAlarm) scene when a fire occurs within a certain range from a home, and may belong to an emergency category.
  • FireAlarm fire alarm
  • the second to fourth OCF rules may be OCF rules belonging to a general category, and the fifth OCF rule may belong to the same emergency category as the first OCF rule.
  • the value of the rule result property in the first OCF rule is changed to true as shown in FIG. 23.
  • the priority activation property value in the first OCF rule is also changed to true, and the priority mechanism is activated.
  • the priority mechanism When the priority mechanism is activated, the value of priority active properties in the second through fifth OCF rules is changed to true.
  • the second to fourth OCF rules belonging to the general category are deactivated. Deactivation of the second to fourth OCF rules may be made by a restriction on the rule expression. As the rule expression is restricted, the determination of whether the rule expression is satisfied may not be made even if the value of the rule active property is true. Since the fifth OCF rule belongs to the emergency category, it is not deactivated and the rule expression may not be restricted.
  • the priority mechanism is deactivated.
  • the value of the priority activation property of the second to fifth OCF rules is also changed to false. Restriction on rule expressions in the second to fourth OCF rules is released, and the function of the second to fourth OCF rules is activated again.
  • 26 is a flowchart illustrating a signal receiving method according to embodiments of the present invention.
  • an embodiment of the present invention may be performed by an apparatus for controlling one or more IoT devices.
  • the method performed by the control device may include setting a first rule resource for controlling one or more IoT devices based on a first rule and a second rule resource for controlling one or more IoT devices based on a second rule.
  • the method may include performing a first rule action in operation S2603.
  • the first rule resource may comprise a first rule category resource for indicating whether the first rule is associated with an emergency
  • the control device may deactivate the second rule through activating the priority mechanism when the first rule expression is satisfied (S2605).
  • the second rule action is not performed even if the second rule expression in the second rule resource is satisfied.
  • the first rule resource and the first rule resource may be included in one rule engine resource. Deactivation of the second rule may be performed through a restriction on the second rule expression.
  • the first rule resource may include a first priority activation property for indicating whether or not the priority mechanism is activated
  • the second rule resource may include a second priority activation property for indicating whether or not the priority mechanism is activated.
  • control device may set a third rule resource for controlling one or more IoT devices based on the third rule.
  • the third rule resource may include a third rule category resource for indicating whether the third rule is related to an emergency situation. If the third rule category resource indicates that the third rule is related to the emergency situation, the third rule may not be deactivated even if the first rule expression is satisfied and the control device activates the priority mechanism.
  • the control device may terminate the execution of the first rule action when the first rule expression is not satisfied, and the control device may deactivate the priority mechanism so that the second rule is activated.
  • the control device may additionally perform one or more of the operations suggested through FIGS. 1 to 25 in addition to the operations shown through FIG. 26.
  • FIG. 27 is a block diagram illustrating components of a transmitter 10 and a receiver 20 that perform embodiments of the present invention.
  • the transmitter 10 and the receiver 20 are associated with transmitters / receivers 13 and 23 capable of transmitting or receiving radio signals carrying information and / or data, signals, messages, etc.
  • Memory 12, 22 for storing a variety of information, the transmitter / receiver 13, 23 and the memory 12, 22 and the like is operatively connected to control the components to control the components described above
  • the memories 12 and 22 may store a program for processing and controlling the processors 11 and 21, and may temporarily store input / output information.
  • the memories 12 and 22 may be utilized as buffers.
  • the processors 11 and 21 typically control the overall operation of the various modules in the transmitter or receiver. In particular, the processors 11 and 21 may perform various control functions for carrying out the present invention.
  • the processors 11 and 21 may also be called controllers, microcontrollers, microprocessors, microcomputers, or the like.
  • the processors 11 and 21 may be implemented by hardware or firmware, software, or a combination thereof.
  • firmware or software When implementing the present invention using hardware, application specific integrated circuits (ASICs) or digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), FPGAs ( field programmable gate arrays) may be provided in the processors 11 and 21.
  • ASICs application specific integrated circuits
  • DSPs digital signal processors
  • DSPDs digital signal processing devices
  • PLDs programmable logic devices
  • FPGAs field programmable gate arrays
  • firmware or software may be configured to include a module, a procedure, or a function for performing the functions or operations of the present invention, and configured to perform the present invention.
  • the firmware or software may be provided in the processors 11 and 21 or stored in the memory 12 and 22 to be driven by the processors 11 and 21.
  • the processor 11 of the transmission apparatus 10 is predetermined from the processor 11 or a scheduler connected to the processor 11 and has a predetermined encoding and modulation on a signal and / or data to be transmitted to the outside. After performing the transmission to the transmitter / receiver (13). For example, the processor 11 converts the data sequence to be transmitted into K layers through demultiplexing, channel encoding, scrambling, and modulation.
  • the coded data string is also called a codeword and is equivalent to a transport block, which is a data block provided by the MAC layer.
  • One transport block (TB) is encoded into one codeword, and each codeword is transmitted to a receiving device in the form of one or more layers.
  • the transmitter / receiver 13 may include an oscillator for frequency upconversion.
  • the transmitter / receiver 13 may include Nt transmit antennas, where Nt is a positive integer greater than or equal to one.
  • the signal processing of the receiver 20 is the reverse of the signal processing of the transmitter 10.
  • the transmitter / receiver 23 of the receiver 20 receives a radio signal transmitted by the transmitter 10.
  • the transmitter / receiver 23 may include Nr receive antennas, and the transmitter / receiver 23 frequency down-converts each of the signals received through the receive antennas to restore baseband signals. do.
  • Transmitter / receiver 23 may include an oscillator for frequency downconversion.
  • the processor 21 may decode and demodulate a radio signal received through a reception antenna to restore data originally transmitted by the transmission apparatus 10.
  • the transmitter / receiver 13, 23 is equipped with one or more antennas.
  • the antenna transmits a signal processed by the transmitter / receiver 13, 23 to the outside or receives a radio signal from the outside under the control of the processors 11 and 21, thereby transmitting / receiving the transmitter / receiver. It performs the function of forwarding to (13, 23).
  • Antennas are also called antenna ports.
  • Each antenna may correspond to one physical antenna or may be configured by a combination of more than one physical antenna elements.
  • the signal transmitted from each antenna can no longer be decomposed by the receiver 20.
  • a reference signal (RS) transmitted in correspondence with the corresponding antenna defines the antenna as viewed from the perspective of the receiver 20, and whether the channel is a single radio channel from one physical antenna or includes the antenna.
  • RS reference signal
  • the receiver 20 enables channel estimation for the antenna. That is, the antenna is defined such that a channel carrying a symbol on the antenna can be derived from the channel through which another symbol on the same antenna is delivered.
  • MIMO multi-input multi-output
  • the terminal or the UE operates as the transmitter 10 in the uplink and the receiver 20 in the downlink.
  • the base station or eNB operates as the receiving device 20 in the uplink, and operates as the transmitting device 10 in the downlink.
  • the transmitter and / or the receiver may perform at least one or a combination of two or more of the embodiments of the present invention described above.
  • the transmitter and / or receiver phases 10 and 20 may include a base station, a network node, a transmission terminal, a reception terminal, a wireless device, a wireless communication device, a vehicle, a vehicle equipped with an autonomous driving function, and a drone (Unmanned Aerial Vehicle, UAV). It may be an AI (Artificial Intelligence) module, a robot, an Augmented Reality (AR) device, a Virtual Reality (VR) device or other device.
  • AI Artificial Intelligence
  • AR Augmented Reality
  • VR Virtual Reality
  • the terminal may be a mobile phone, a smart phone, a laptop computer, a digital broadcasting terminal, a personal digital assistant (PDA), a portable multimedia player (PMP), navigation, a slate PC, a tablet. It may include a tablet PC, an ultrabook, a wearable device (eg, a smartwatch, a glass glass, a head mounted display), and the like.
  • a drone may be a vehicle in which humans fly by radio control signals.
  • the HMD may be a display device worn on the head.
  • the HMD can be used to implement VR or AR.
  • each component or feature is to be considered optional unless stated otherwise.
  • Each component or feature may be embodied in a form that is not combined with other components or features. It is also possible to combine some of the components and / or features to form an embodiment of the invention.
  • the order of the operations described in the embodiments of the present invention may be changed. Some components or features of one embodiment may be included in another embodiment or may be replaced with corresponding components or features of another embodiment. It is obvious that the claims may be combined to form an embodiment by combining claims that do not have an explicit citation relationship in the claims or as new claims by post-application correction.
  • the present invention can be applied to various wireless communication systems.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

본 발명의 일 실시예에 따른 무선 통신 시스템에서 하나 이상의 사물 인터넷 장치를 제어하는 장치 및 방법은, 제1 룰에 기반하여 상기 하나 이상의 IoT 장치를 제어하기 위한 제1 룰 리소스 및 제2 룰에 기반하여 상기 하나 이상의 IoT 장치를 제어하기 위한 제2 룰 리소스를 설정하고, 상기 제1 룰 리소스 내의 제1 룰 표현식이 만족되면 제1 룰 액션을 수행하되, 상기 제1 룰 리소스는 상기 제1 룰이 응급 상황과 관련되었는지 여부를 나타내기 위한 제1 룰 카테고리 리소스를 포함하고, 상기 제2 룰 리소스는 상기 제2 룰이 응급 상황과 관련되었는지 여부를 나타내기 위한 제2 룰 카테고리 리소스를 포함하고, 상기 제1 룰 카테고리 리소스가 상기 제1 룰이 응급 상황과 관련되었음을 나타내며 상기 제2 룰 카테고리 리소스가 상기 제2 룰이 응급 상황과 관련이 없음을 나타내는 경우, 상기 제1 룰 표현식이 만족되면 우선순위 메커니즘을 활성화함을 통해 상기 제2 룰을 비활성화할 수 있다.

Description

무선 통신 시스템에서 IOT 장치를 제어하는 방법 및 장치
본 발명은 사물인터넷 (Internet of Things; IoT) 장치 및 IoT 장치와 관련하여 수행되는 방법 및 장치에 관한 것이다. 구체적으로, 본 발명은 IoT 장치를 제어하는 방법 및 장치에 관한 것이다.
IoT 기술 발전에 따라 가정 내 다양한 전자기기들이 네트워크를 통해 서로 연결되어 정보를 공유할 수 있는 환경이 조성되어 있다.
IoT 장치 간 상호 운용성 확보를 위한 표준화를 위해 OIC(Open Interconnect Consortium)가 구성되었다. 이후 OIC와 UPnP (Universal Plug and Play)가 통합되어 OCF (Open Connectivity Foundation)가 구성되었다.
OCF 표준화 기구에서는 IoT 장치 간 통신 및 클라우드 이용 등 IoT 서비스 및 오픈 플랫폼 제공을 위한 기술을 개발 중에 있으며, 타 IoT 표준 (oneM2M, OMA LWM2M, BLE, Zigbee, Z-Wave, GENIVI 등)과의 연계를 계획하고 있다.
OCF 표준에 따른 서비스를 제공하기 위한 장치는, 리소스(resource)를 제공하기 위한 서버(server) 및 리소스에 액세스(access)하는 클라이언트(Client)를 포함한다.
이러한 환경에서, OCF 표준에 기반하여 IoT 장치를 효율적으로 제어하기 위한 방법들이 제안되고 있다.
본 발명이 이루고자 하는 기술적 과제는, 응급 상황을 고려하여 IoT 장치를 제어하기 위한 방법 및 이를 위한 장치를 제공하는데 있다.
본 발명의 기술적 과제는 상술된 기술적 과제에 제한되지 않으며, 다른 기술적 과제들이 본 발명의 실시예로부터 유추될 수 있다.
본 발명은 무선 통신 시스템에서의 신호 수신 방법 및 장치를 제공한다.
본 발명의 일 양태로서, 무선 통신 시스템에서 하나 이상의 사물 인터넷 (Internet of Things; IoT) 장치를 제어하는 장치에 의해 수행되는 방법으로, 제1 룰(rule)에 기반하여 상기 하나 이상의 IoT 장치를 제어하기 위한 제1 룰 리소스(rule resource) 및 제2 룰에 기반하여 상기 하나 이상의 IoT 장치를 제어하기 위한 제2 룰 리소스를 설정하는 단계; 상기 제1 룰 리소스 내의 제1 룰 표현식(rule expression)이 만족되면 제1 룰 액션(rule action)을 수행하는 단계; 를 포함하며, 상기 제1 룰 리소스는 상기 제1 룰이 응급(emergency) 상황과 관련되었는지 여부를 나타내기 위한 제1 룰 카테고리(rule category) 리소스를 포함하고, 상기 제2 룰 리소스는 상기 제2 룰이 응급 상황과 관련되었는지 여부를 나타내기 위한 제2 룰 카테고리 리소스를 포함하고, 상기 제1 룰 카테고리 리소스가 상기 제1 룰이 응급 상황과 관련되었음을 나타내며 상기 제2 룰 카테고리 리소스가 상기 제2 룰이 응급 상황과 관련이 없음을 나타내는 경우, 상기 제1 룰 표현식이 만족되면 우선순위 메커니즘(priority mechanism)을 활성화함을 통해 상기 제2 룰을 비활성화하는 방법을 제안한다.
본 발명의 다른 일 양태에 따른 장치는, 무선 통신 시스템에서 하나 이상의 사물 인터넷 (Internet of Things; IoT) 장치를 제어하는 장치로서, 송수신기; 및 상기 송수신기를 제어하는 프로세서; 를 포함하며, 상기 프로세서는, 제1 룰(rule)에 기반하여 상기 하나 이상의 IoT 장치를 제어하기 위한 제1 룰 리소스(rule resource) 및 제2 룰에 기반하여 상기 하나 이상의 IoT 장치를 제어하기 위한 제2 룰 리소스를 설정하고, 상기 제1 룰 리소스 내의 제1 룰 표현식(rule expression)이 만족되면 제1 룰 액션(rule action)을 수행하도록 구성되며, 상기 제1 룰 리소스는 상기 제1 룰이 응급(emergency) 상황과 관련되었는지 여부를 나타내기 위한 제1 룰 카테고리(rule category) 리소스를 포함하고, 상기 제2 룰 리소스는 상기 제2 룰이 응급 상황과 관련되었는지 여부를 나타내기 위한 제2 룰 카테고리 리소스를 포함하고, 상기 제1 룰 카테고리 리소스가 상기 제1 룰이 응급 상황과 관련되었음을 나타내며 상기 제2 룰 카테고리 리소스가 상기 제2 룰이 응급 상황과 관련이 없음을 나타내는 경우, 상기 프로세서는 상기 제1 룰 표현식이 만족되면 우선순위 메커니즘(priority mechanism)을 활성화함을 통해 상기 제2 룰을 비활성화하는 장치를 제안한다.
상기 방법 및 장치는, 제3 룰에 기반하여 상기 하나 이상의 IoT 장치를 제어하기 위한 제3 룰 리소스를 설정할 수 있고, 상기 제3 룰 리소스는 상기 제3룰이 응급 상황과 관련되었는지 여부를 나타내기 위한 제3 룰 카테고리 리소스를 포함할 수 있으며, 상기 제3 룰 카테고리 리소스가 상기 제3 룰이 응급 상황과 관련되었음을 나타내면, 상기 제1 룰 표현식이 만족되어 상기 우선순위 메커니즘(priority mechanism)이 활성화되더라도 상기 제3 룰은 비활성화되지 않을 수 있다.
더하여, 상기 제1 룰 리소스는 상기 우선순위 메커니즘의 활성화 여부를 나타내기 위한 제1 우선순위 활성(priority enable) 프로퍼티(property)를 포함하고, 상기 제2 룰 리소스는 상기 우선순위 메커니즘의 활성화 여부를 나타내기 위한 제2 우선순위 활성 프로퍼티를 포함할 수 있다.
또한 상기 방법 및 장치는, 상기 제1 룰 표현식이 만족되지 않게 되면, 상기 제1 룰 액션의 수행을 종료할 수 있고, 상기 우선순위 메커니즘을 비활성화함을 통해 상기 제2 룰을 활성화할 수 있다.
더하여, 상기 제2 룰이 비활성화되면, 상기 제2 룰 리소스 내의 제2 룰 표현식이 만족되더라도 제2 룰 액션이 수행되지 않을 수 있다.
더하여, 상기 제1 룰 리소스 및 상기 제2 룰 리소스는 하나의 룰 엔진(rule engine) 리소스에 포함될 수 있다.
더하여, 상기 제2 룰의 비활성화는, 상기 제2 룰 표현식에 대한 제한(constraint)을 통해 수행될 수 있다.
상술한 본 발명의 양태들은 본 발명의 바람직한 실시예들 중 일부에 불과하며, 본원 발명의 기술적 특징들이 반영된 다양한 실시예들이 당해 기술분야의 통상적인 지식을 가진 자에 의해 이하 상술할 본 발명의 상세한 설명을 기반으로 도출되고 이해될 수 있다.
본 발명의 일 실시예에 따르면, 새로운 리소스의 정의를 통해, 응급 상황을 고려하여 IoT 장치를 보다 효율적으로 제어할 수 있다는 장점이 있다.
본 발명의 기술적 효과는 상술된 기술적 효과에 제한되지 않으며, 다른 기술적 효과들이 본 발명의 실시예로부터 유추될 수 있다.
도 1은 OCF 플랫폼의 연결성 및 상호 운용성을 나타내는 도면이다.
도 2는 OCF 플랫폼의 프레임워크 구조를 나타낸 도면이다.
도 3은 클라이언트, 인터미디어리, 서버 사이의 요청 및 응답 수신에 대한 도면이다.
도 4는 OCF 표준에서 지원 가능한 프로토콜 스택을 나타낸 도면이다.
도 5는 OCF를 통해 지원 가능한 기능들을 넓은 범위에서 나타낸 도면이다.
도 6은 CRUDN 동작을 수행하는 일 예시를 나타낸 도면이다.
도 7은 OCF 룰 기능의 일 예시를 나타낸 도면이다.
도 8 및 도 9는 OCF 신 기능의 일 예시를 나타낸 도면이다.
도 10은 OCF 룰 및 신 기능의 일 예시를 나타낸 도면이다.
도 11은 OCF 룰 및 신 기능의 동작에 따른 문제점을 나타낸 도면이다.
도 12 내지 도 25는 본 발명의 실시 예에 따른 동작을 설명하기 위한 도면이다.
도 26은 본 발명의 실시예에 따른 흐름도를 도시한다.
도 27은 본 발명의 실시예에 따른 장치를 도시한다.
이하, 본 발명에 따른 바람직한 실시형태를 첨부된 도면을 참조하여 상 세하게 설명한다. 첨부된 도면과 함께 이하에 개시될 상세한 설명은 본 발명의 예시적인 실시형태를 설명하고자 하는 것이며, 본 발명이 실시될 수 있는 유일한 실시형태를 나타내고자 하는 것이 아니다. 이하의 상세한 설명은 본 발명의 완전한 이해를 제공하기 위해서 구체적 세부사항을 포함 한다. 그러나, 당업자는 본 발명이 이러한 구체적 세부사항 없이도 실시될 수 있음을 안다.
몇몇 경우, 본 발명의 개념이 모호해지는 것을 피하기 위하여 공지의 구조 및 장치는 생략되거나, 각 구조 및 장치의 핵심 기능을 중심으로 한 블록도 형식으로 도시될 수 있다. 또한, 본 명세서 전체에서 동일한 구성요소에 대해서는 동일한 도면 부호를 사용하여 설명한다.
설명을 명확하게 하기 위해, 3GPP 기반의 이동 통신 시스템을 위주로 기술하지만 본 발명의 기술적 사상이 이에 제한되는 것은 아니다. 이하의 기술은 oneM2M, OMA LWM2M, BLE, Zigbee, Z-Wave, GENIVI 등과 같은 다양한 IoT 서비스 또는 플랫폼에 사용될 수 있다. 또한, 이하의 설명에서 사용되는 특정 용어들은 본 발명의 이해를 돕기 위해서 제공된 것이며, 이러한 특정 용어의 사용은 본 발명의 기술적 사상을 벗어나지 않는 범위에서 다른 형태로 변경될 수 있다.
OCF 개요
도 1은 OCF 플랫폼의 연결성 및 상호 운용성을 나타내는 도면이다.
OCF는 헬스, 스마트홈, 산업 IoT 등 여러 수직산업(Verticals)을 연결하며 협력할 수 있게 하는 기본서비스와 데이터 모델을 제시하는 공통 플랫폼을 정의한다. OCF 플랫폼은 커넥티비티(Connectivity) 레벨, 플랫폼(Platform) 레벨, 서비스(Service) 계층 사이의 연결성(connectivity)을 제공한다. 더하여 OCF 플랫폼은 UX (user experience)를 통한 완전한 상호 운용성(Full interoperability)을 제공한다.
OCF 표준은 데이터 구조, 리소스에 대한 타입(type), 프로퍼티(property) 및 인터페이스(interface)를 정의한다. 더하여, OCF 표준은 기기 인증, 보안 기능, OCF 망(network) 내 리소스에 대한 접근 제어, OCF 망 내에 포함될 수 있는 기기의 발견, 리소스에 대한 명령(CREATE, RETRIEVE, UPDATE, DELETE, and NOTIFY; CRUDN), 리소스에 대한 메시지, OCF 망과 인터넷 망 (IPv6 등)의 연결을 위한 프레임(frame)을 제공한다.
OCF 프레임워크 구조 (OCF Framework Architecture)
도 2는 OCF 플랫폼의 프레임워크 구조를 나타낸 도면이다.
도 2를 통해 OCF 플랫폼의 동작 및 주요 개념을 형상화하여 설명한다. 이하에서 설명할, 개념적으로 형상화된 내용들은 리소스 모델(resource model), RESTful 동작(RESTful operation) 또는 개요(abstraction)에 대한 것이 될 수 있으며, OCF 동작 및 표준에 대한 기본적인 특징이 될 수 있다.
OCF 장치는 클라이언트, 서버 및/또는 인터미디어리(intermediary) 중 하나 이상의 역할을 지원할 수 있다. OCF 장치가 지원 가능한 역할은 논리 엔티티(logical entity)의 영역일 수 있으며, 하나의 OCF 장치가 하나 이상의 역할을 지원할 수 있다. 이하의 설명에서 '장치'는 논리 엔티티를 포함하는 물리 장치를 지칭할 수 있으며, 혹은 논리 엔티티 자체를 지칭할 수도 있다.
클라이언트 장치는, 서버의 리소스에 접속하는 역할을 수행하는 장치를 의미한다.
서버 장치는, 리소스 상태 정보(resource state information)을 제공하고, 리소스에 대해 원격 상호작용(remote interaction)을 수행 가능한 장치를 의미한다.
인터미디어리 장치는, OCF 프록시(OCF proxy) 역할을 제공하는 장치를 의미한다. 다시 말해서, 서버 장치에 의해 호스팅(hosting)된 OCF 자원에 대한 요청 메시지를 처리하는 중개 역할을 수행하는 장치이다.
이하의 설명에서, 리소스에 대한 상태(state), 값(value), 정보(information)은 동일한 의미로 사용될 수 있다.
클라이언트는 리소스에 대한 CRUDN 동작을 서버에 요구할 수 있다. 서버는 클라이언트에 의해 요구된 CRUDN 동작을 수행할 수 있다. 클라이언트와 서버 사이의 리소스 지정 및 동작 지정은, RESTful 자원 모델을 기반으로 수행될 수 있다. 인터미디어리는 다른 OCF 서버에 의해 호스팅된 OCF 리소스를 처리하기 위한 요청에 기반하여, 프로세싱 설정(processing configuration)에 따라 또 다른 요청을 생성하고, 생성된 요청에 대한 응답을 OCF 서버에 반환할 수 있다.
리소스 모델은 OCF 리소스로 표시된 실제 엔티티에 해당한다.
상위 계층(e.g. OCF client, OCF server)에서 발생한 클라이언트-서버 사이의 CRUDN 동작은, 하위 계층(e.g. OCF device)에서는 CoAP (Constrained Application Protocol) 요청 및 CoAP 응답, 또는 XMPP (Extensible Messaging and Presence Protocol)를 통해서 전달될 수 있다.
CRUDN 동작은 OCF 클라이언트와 OCF 서버 사이에서 발생된다. CRUDN 동작은 프로토콜 맵핑(protocol mapping)을 통해 CoAP 요청 및 CoAP 응답이라는 시그널링 메시지(signaling message, e.g. GET /s/data, {"bulb":"on"})를 통해 송수신될 수 있다. CRUDN 동작은, 프로토콜 맵핑을 통해 CoAP 외의 HTTP (hypertext transfer protocol) 및/또는 XMPP를 통해 송수신될 수도 있다.
또는, 도 3과 같이 클라이언트, 인터미디어리, 서버가 연결된 경우, 클라이언트와 인터미디어리 사이의 요청 및 응답은 HTTP를 통해, 인터미디어리와 서버 사이의 요청 및 응답은 CoAP를 통해 송수신될 수도 있다.
OCF 프로토콜 스택(OCF Protocol Stack)
도 4는 OCF 표준에서 지원 가능한 프로토콜 스택을 나타낸다.
도4에 도시된 프로토콜 스택 중 인코딩(Encoding) 계층은 CBOR (Concise binary object representation based on JSON data model)를 지원하는 것이 디폴트(default)이다. 다만, 클라이언트와 서버의 협상에 의해 JSON (JavaScript Object Notation) 및/또는 XML/EXI (Efficient XML Interchange)가 사용될 수도 있다.
엔드 포인트(End point)의 디스커버리(discovery)에는 CoAP 디스커버리 (CoAP Discovery)가 사용된다 (IETF RFC 7252).
L2 계층과의 연결을 위해, IoT 디바이스를 위한 IPv6 이 존재한다. 전송 계층의 보안성 확보를 위해 UDP (user datagram protocol) 계층 위에 DTLS (datagram transport layer security) 계층이 존재할 수 있다. 또한, 전송 계층의 보안성 확보를 위해 TCP (transmission control protocol) 계층 위에 TLS (transport layer security) 계층이 존재할 수 있다.
OCF 프레임워크 블록 다이어그램(OCF Framework Block Diagram)
도 5는 OCF를 통해 지원 가능한 기능들을 넓은 범위(high level)에서 나타낸 도면이다.
OCF 프레임워크에서 지원 가능한 기능들은 하기 표 1과 같다.
[표 1]
Figure PCTKR2019007371-appb-img-000001
하위 계층에서는 L2 커넥티비티(L2 connectivity) 및 네트워킹 (Networking) 계층에서 표 1을 통해 설명된 기능들이 수행될 수 있다. L2 커넥티비티 계층은 Wi-Fi (wireless fidelity), BT (bluetooth) 및/또는 Z-wave 등 기존의 무선 통신 기술이 사용될 수 있다.
OCF 프레임워크에서는 표 1을 통해 설명된 기능들이 수행될 수 있다.
어플리케이션(application) 계층에는, OCF에 의해 마켓들을 위한 개별 프로필(data model, function 등)이 생성되어 있다. 일 예로, 스마트 홈 데이터 모델 (smart home data model)이 존재한다.
CRUDN 동작(CRUDN Operation)
CRUDN 동작이란, 리소스에 대해 요청될 수 있는 동작으로, 표 2와 같이 5개의 명령이 존재할 수 있다. 클라이언트가 명령을 전송하면, 해당 리소스가 포함된 서버에서 해당 리소스에 대해 CRUDN 명령을 수행한다.
[표 2]
Figure PCTKR2019007371-appb-img-000002
도 6은 CRUDN 동작을 수행하는 일 예시를 나타낸다. 먼저, 클라이언트가 CRUDN 동작 중 Create 요청을 서버로 전송한다. Create 명령을 수신한 서버는 리소스에 대해 Create를 수행한다. 리소스에 대한 Create를 실시한 서버는 클라이언트로부터 수신한 요청에 대한 응답을 클라이언트로 전송한다.
CRUDN 메시지에 포함될 수 있는 파라미터는 표 3과 같다.
[표 3]
Figure PCTKR2019007371-appb-img-000003
OCF 룰 및 신(OCF Rule and Scene)
OCF에는 편리하고 효율적인 스마트 홈(smart home) 장치 제어를 위해 룰 (rule) 기능과 신(scene) 기능이 정의되어 있다.
룰 기능(또는 OCF 룰 기능)은, 룰 컨디션(rule condition)이 만족된 경우, 미리 정의된 특정 액션(action)을 수행하는 기능을 의미한다.
신 기능(또는 OCF 신 기능)은, 복수의 장치에 대한 특정 상황에 따른 상태 값을 미리 신으로 정의하고, 필요 시에 하나의 신을 통해 복수의 장치의 상태 값을 동시에 변경하는 기능을 의미한다.
룰 및 신(rule and scene, rule plus scene, rule + scene) 기능(또는 OCF 룰 및 신 기능)은, 룰 컨디션이 만족된 경우 정의된 액션으로서 신 업데이트(scene update)가 수행되는 기능을 의미한다. 룰 및 신 기능에 의하면 최종적으로 특정 신이 수행되어 신에 정의된 복수의 장치의 상태 값이 업데이트된다.
일반적으로, OCF 스마트 홈 환경은 복수의 룰 기능들과 복수의 신 기능들로 구성된 복잡한 환경이다.
OCF 스마트 홈 환경에서 룰 및 신 기능을 통해, 특정 룰 컨디션이 만족되면 신 업데이트가 수행되도록 설정되었다면, 사용자의 의도와 관계없이 자동적으로 신 업데이트가 수행될 수 있다. 따라서, 사용자의 의도 또는 예상을 벗어나 특정 장치의 상태 값이 변경될 수 있다. 또한, 특정 상황(e.g. 화재, 주거침입)에서는 신 기능이 설정된 장치의 상태 값이 유지될 필요성이 있는 경우가 발생될 수 있다.
복수의 룰들 및 신들이 설정되어 있을 때, 사용자의 의도나 예상을 벗어나 장치의 상태 값이 변경되는 것을 방지하는 기술 및 특정 상황에서는 OCF 장치들이 효율적으로 제어되도록 하기 위한 기술이 필요하다.
도 7은 OCF 룰 기능이 수행되는 일 예를 나타낸다.
OCF 룰은 기 정의된 입력(input)-컨디션(condition)-액션(action) 패턴에 따라서 자동적인 결정 논리(autonomous decision logic)을 구현하기 위한 OCF 리소스이다. 룰 입력은 선택된 리소스 인스턴스(resource instance)의 프로퍼티 값(property value)으로서 참조된다. 룰 액션은 동적 링크(dynamic link)에 의해 참조된 리소스 인스턴스로 기 정의된 프로퍼티 값을 UPDATE 동작을 통해 전송하는 과정으로 구성된다.
이하는 OCF 룰을 구성하는 리소스(또는 프로퍼티)에 대한 보다 구체적인 설명이다.
OCF 룰은 하나 이상의 룰 입력(rule input)들을 포함한다. 룰 입력은 리소스 인스턴스의 프로퍼티들의 값으로 구성된다. 룰 입력에 의해 참조된 리소스를 기반으로 룰 표현식(rule expression)이 생성된다.
또한 OCF 룰은 하나의 룰 표현식(또는 룰 컨디션)을 포함한다. 룰 표현식을 통해 하나 이상의 기 정의된 룰 입력을 기반으로 구성된 룰 논리(rule logic)가 정의될 수 있다. 불린(Boolean) 형식으로 true/false 값의 평가(evaluation)가 수행되고 룰 표현식의 만족 여부가 판단될 수 있다.
또한 OCF 룰은 하나 이상의 룰 액션(rule action, 또는 룰 출력; rule output)을 포함한다. 룰 액션은, 룰 표현식이 true로 평가된 경우 수행되는 액션을 정의하기 위한 리소스이다.
또한 OCF 룰은 하나 이상의 동적 링크를 포함한다. 동적 링크는, 룰 입력을 소스(source)로 볼 때, 룰 입력의 목적지에 해당하는 룰 액션이 사용되는 외부 리소스(external resource)를 지시하기 위한 링크이다.
또한 OCF 룰은 OCF 룰의 상태(status)를 표시하기 위한 프로퍼티들을 포함할 수 있다.
룰 활성(RuleEnable) 프로퍼티는, OCF 룰의 활성 여부를 결정하기 위한 프로퍼티이다. 불린 형식으로 룰 활성 프로퍼티의 값이 True이면 룰 기능이 활성화되고, false이면 룰 기능이 비활성화될 수 있다.
액션 활성(ActionEnable) 프로퍼티는, OCF룰 액션 기능의 활성 여부를 결정하기 위한 프로퍼티이다. 불린 형식으로, 룰 표현식에 의한 조건이 만족되더라도 액션 활성 프로퍼티의 값이 true일 때만 룰 액션에 정의된 동작이 수행될 수 있다.
룰 결과(RuleResult) 프로퍼티는, OCF 룰 표현식 만족 여부를 표시하기 위한 프로퍼티이다. 룰 결과 프로퍼티의 값이 true이면 룰 표현식에 대한 평가 결과 룰이 만족되었음을 나타내며(true), 룰 결과 프로퍼티의 값이 false이면 룰 표현식에 대한 평가 결과 룰이 만족되지 않았음을 나타낸다(false).
도 7을 참조하여 OCF 룰 동작이 수행되는 과정을 설명하면, 먼저 하나 이상의 룰 입력을 기반으로 룰 표현식이 구성된다. 룰 평가에 의해 룰 표현식의 만족 여부가 true로 판단되면, 기 정의된 룰 액션이 수행된다. 룰 입력 프로퍼티의 값이 변경될 때마다 룰 평가가 수행될 수 있다.
도 8 및 도 9는 OCF 신 기능, 구성의 일 예를 나타낸 도면이다.
OCF 신은 특정 동작 자동화(automating certain operation)을 수행하기 위한 메커니즘(mechanism)이다. OCF 신은 기 정의된 리소스 프로퍼티 값의 세트를 미리 저장해두기 위한 정적 엔티티(static entity)이다. OCF 신은 복수의 분리된 서버(multiple separate server)들에 호스팅된 복수의 리소스들의 세트를 설정하여 저장하기 위한 메커니즘을 제공한다. OCF 신이 설정(set up)되면 즉시 복수의 클라이언트들에 의해 사용될 수 있다.
이하는 OCF 신을 구성하는 리소스(또는 프로퍼티)에 대한 보다 구체적인 설명이다.
OCF 신을 구성하는 복수의 리소스들은 도 8과 같이 신 리스트(SceneList), 신 컬렉션(SceneCollection) 및 신 멤버(SceneMember) 프로퍼티들로 구성될 수 있다. 신 리스트 프로퍼티는 신을 구성하는 리소스들 중 가장 상위 레벨의 리소스(top level resource)이다. 신 컬렉션 프로퍼티는 신들의 리스트(list)를 포함한다. 리스트는 하나 이상의 신을 포함한다. 신 멤버 프로퍼티는 신들 간의 맵핑(mapping) 정보와 신 별로 발생하는 리소스 프로퍼티 값의 설정 값을 포함한다.
도 8을 참조하여 OCF 신 동작이 수행되는 과정을 설명하면, 신 컬렉션 프로퍼티에는 다양한 신 리스트들이 저장되어 있다. 신 컬렉션 프로퍼티 내의 신 밸류(SceneValues) 프로퍼티 및 라스트 신(LastScene) 프로퍼티 값을 통해 현재 지원되는 신들과 가장 최근 업데이트된 신이 확인될 수 있다.
라스트신 프로퍼티가 특정 신 네임(SceneName)으로 업데이트되면, 신 멤버 프로퍼티에 정의된 맵핑 정보가 확인되고, 특정 신이 수행된다. 신이 수행되면, 링크로 연계된 장치(e.g. OCF 서버)들로 기 정의된 리소스 프로퍼티 값에 대한 설정 값을 포함하는 UPDATE 요청이 전송될 수 있다.
도 10은 OCF 룰 및 신 기능이 수행되는 일 예를 나타낸다.
OCF룰이 true로 평가되면, 룰 액션으로서 신 변경(또는 업데이트)가 트리거(trigger)된다. 신 밸류가 룰 액션(또는 룰 출력)으로서, 룰이 만족되는 경우 신 컬렉션 내의 라스트신 프로퍼티가 업데이트된다.
OCF 룰 기능에 의해 자동으로 신 업데이트가 설정될 수 있다. 룰 액션으로서 신 업데이트가 설정되면, 룰 표현식 만족 시 자동으로 신 업데이트 메시지가 신 서버로 트리거된다. OCF 룰 및 신 기능에 의해, OCF 룰 기능에 기반한 자동 신 업데이트가 설정된 경우, 룰 표현식이 만족되는 순간 주변 환경에 대한 고려 없이 신 업데이트가 수행된다. 이로 인해 사용자의 의도와 다른 신 트랜지션(transition)이 발생될 수 있고, 사용자 의도에 적합하도록 기 수행된 OCF 신 동작이 무효화될 수 있다. 특히 복수의 OCF 룰들과 복수의 OCF 신들로 구성된 복잡한 환경에서는 신 효율성 능력(scene efficiency capability)이 감소되며, 사용자의 의도와 다른 모드로 장치가 전환될 수 있다. 사용자 의도와 OCF 룰 및 신 기능과의 충돌을 방지하기 위한 방법이 필요할 수 있다.
복수의 OCF 룰 설정으로 인해 충돌이 발생하는 경우의 일 예로, 복수의 OCF 룰이 및 OCF 신이 설정된 경우를 가정한다.
제1 OCF 룰은, 집으로부터 일정 범위 이내에 화재가 발생할 경우(룰 표현식 만족되는 경우) 화재 알람(FireAlarm) 신이 수행되도록 설정된다. 화재 알람 신이 수행되면, 룰 액션으로서 신 서버의 라스트신 프로퍼티가 업데이트된다.
제2 OCF 룰은, 집 내에서 에너지 소비량이 임계값을 초과한 경우, 저전력(LowPower) 신이 수행되도록 설정된다.
화재 알람 신에 의해 리소스가 업데이트될 때, 조명(Light)1, 조명2, 조명3 및 알람이 켜지도록(on) 업데이트되고, 현관문은 열리도록(open) 리소스가 업데이트될 수 있다.
저전력 신에 의해 리소스가 업데이트될 때, 조명1은 켜지도록 업데이트되지만, 조명2, 조명3 및 알람은 꺼지도록(off), 창문은 닫히도록(close) 리소스가 업데이트될 수 있다.
집으로부터 일정 범위 이내에서 화재가 발생하여 제1 OCF 룰에 포함된 룰 표현식이 만족되면, 제1 OCF 룰에 포함된 룰 액션에 의해 화재 알람 신이 수행될 수 있다. 화재 알람 신에 의해 조명1, 조명2, 조명3이 켜지고, 경고를 위한 알람이 켜지며, 현관 문이 열리게 된다. 안전을 고려한다면, 화재 알람 신이 유지될 필요가 있다. 사용자 또한 비상 상황에서 화재 알람이 유지되기를 원할 수 있다.
이후 집 내의 에너지 소비량이 임계값을 초과하여 제2 OCF 룰에 포함된 룰 표현식이 만족되면, 제2 OCF 룰에 포함된 룰 액션에 의해 저전력 신이 수행된다. 저전력 신에 의해 조명2, 조명3이 꺼지고 창문이 닫히게 되며, 경고를 위한 알림이 꺼지게 된다. 사용자 의도, 신의 중요도 및/또는 비상상황이 고려되지 않고 룰에 의해 자동으로 신이 수행되는 문제가 있으며, 이를 해결하기 위한 방안이 필요하다.
이를 위해 복수의 OCF 룰들을 특성에 따라 카테고리(category)화 함으로써 기존과는 차별적인 룰 메커니즘을 제공하는 방안을 제안한다.
룰 카테고리는, 상황에 따라 차별화된 룰 메커니즘을 제공하기 위해 기존의 OCF 룰들을 특성을 고려하여 분류하기 위한 것이다. 예를 들어, OCF 룰들은 응급상황을 위해 정의된 응급(emergency) 카테고리와 일반(normal) 카테고리 중 하나에 속할 수 있다. 응급 카테고리에 속하는 OCF 룰은 일반 카테고리에 속하는 OCF 룰에 비해 상대적으로 중요도가 높은 OCF 룰로서, 응급 카테고리에 속하는 OCF 룰과 관련된 동작은 일반 카테고리에 속하는 OCF 룰과는 다른 메커니즘을 따를 수 있다. 일반 카테고리에 속하는 OCF 룰은 응급 카테고리에 속하는 OCF 룰에 비해 상대적으로 중요도가 낮은 OCF 룰에 해당한다.
도 12 및 13은 룰 카테고리를 구분하기 위한 일 실시예를 나타낸 도면이다.
룰 카테고리를 구분하기 위해서, 도 12와 같이 룰 리소스 내에 룰 카테고리(rule category) 리소스가 추가될 수 있다. 룰 카테고리 리소스의 값은, 해당 OCF 룰이 응급 또는 일반 카테고리 중 어느 카테고리에 속하는지 나타내기 위한 값(e.g. emergency 또는 normal)으로 나타내어질 수 있다.
응급 카테고리에 속하는 OCF 룰과 관련된 동작이 수행되는 경우, 다른 카테고리에 속하는 OCF 룰은 비활성화될 수 있다. 응급 카테고리에 속하는 OCF 룰과 관련된 동작이 수행되면, 해당 OCF 룰이 속하는 룰 엔진(rule engine) 내의 다른 모든 OCF 룰의 기능이 비활성화되고 다만 해당 응급 카테고리에 속하는 다른 OCF 룰은 비활성화되지 않을 수 있다.
예를 들어, 제1 OCF 룰은, 집으로부터 일정 범위 이내에 화재가 발생할 경우(룰 표현식 만족되는 경우) 화재 알람(FireAlarm) 신이 수행되도록 설정되어 있고, 제2 OCF 룰은, 집 내에서 에너지 소비량이 임계값을 초과한 경우, 저전력(LowPower) 신이 수행되도록 설정되어 있을 수 있다.
제1 OCF 룰은 응급 상황에 필요한 액션을 수행해야 하므로 응급 카테고리로 분류되며, 제2 OCF 룰은 응급 상황과 별개의 액션을 수행하므로 일반 카테고리로 분류될 수 있다. 제1 OCF 룰 내의 룰 표현식이 만족되어 룰 액션으로서 화재 알람 신이 수행되면, 응급 카테고리에 속하지 않는 OCF 룰의 기능이 비활성화될 수 있다. 제2 OCF 룰은 응급 카테고리에 속하지 않으므로, 제2 OCF 룰 내의 룰 활성 프로퍼티 및 액션 활성 프로퍼티의 값이 false로 업데이트되어 제2 OCF 룰과 관련된 동작들이 비활성화될 수 있다.
제2 OCF 룰 내의 룰 표현식이 만족되어 룰 액션으로서 저전력 신이 화재 알람 신보다 먼저 수행될 수도 있다. 제2 OCF 룰은 일반 카테고리에 속하므로, 제2 OCF 룰과 관련된 동작만이 수행되고 제1 OCF 룰 내의 룰 활성 프로퍼티 및 액션 활성 프로퍼티들은 업데이트되지 않는다.
도 14는 룰 리소스 내에 포함되는 추가적인 리소스를 나타내는 도면이다.
도 14와 같이 룰 리소스 내에, 룰 카테고리 리소스에 더하여 카테고리 액션(category action) 및 카테고리 활성(category enable) 프로퍼티가 추가될 수 있다. 그리고 룰 리소스와 별도로 카테고리 리스트(category list) 리소스가 추가될 수 있다.
카테고리 리스트 리소스는 룰 엔진 내에 정의되어 있는 모든 OCF 룰의 카테고리를 분류하고 리스트로 정의하여 관리하기 위한 리소스이다. 예를 들어, 카테고리 리스트 리소스 내에는 응급 카테고리와 일반 카테고리가 포함될 수 있다. 또한, 카테고리 리스트 리소스 내에는 어떤 카테고리에 어떤 OCF 룰이 포함되는지 정의되어 있을 수 있다. 또한, 카테고리 리스트 리소스 내에는 특정 카테고리에 속하는 OCF 룰이 어떤 추가 동작을 수행하여야 하는지 정의되어 있을 수 있다.
룰 카테고리 리소스는 앞서 설명한 바와 같이 각 룰 리소스 별로 해당 룰 리소스가 어느 카테고리에 속하는지를 나타낸다. 제1 OCF 룰은 응급 카테고리에 속하므로 룰 카테고리 리소스의 값이 emergency일 수 있다. 제2 OCF 룰은 일반 카테고리에 속하므로 룰 카테고리 리소스의 값이 normal일 수 있다.
카테고리 액션 리소스는 카테고리 활성 프로퍼티가 활성(enable) 상태인 경우에 수행되는 동작을 정의하기 위한 리소스이다. 카테고리 활성 프로퍼티가 true 인 경우 룰 액션이 수행될 때 카테고리 액션 리소스에 정의된 동작이 함께 수행될 수 있다. 카테고리 액션 리소스는, 다른 카테고리에 속하는 OCF 룰을 비활성화하기 위한 값을 포함할 수 있다. 또는 카테고리 액션 리소스는, 추가 동작을 수행하지 않음을 나타내기 위한 값을 포함할 수 있다.
카테고리 활성 프로퍼티는 룰 카테고리 기능의 활성 상태를 나타내기 위한 프로퍼티이다. 카테고리 활성 프로퍼티의 값이 true인 경우 룰 카테고리 기능이 활성화되어, 앞서 설명한 바와 같이 룰 액션이 수행될 때 카테고리 액션 리소스에 정의된 동작이 함께 수행될 수 있다. 카테고리 활성 프로퍼티의 값이 false이면, 룰 표현식이 만족되더라도 룰 액션만이 수행되고 카테고리 액션 리소스에 정의된 동작은 수행되지 않을 수 있다.
예를 들어, 제1 OCF 룰은, 집으로부터 일정 범위 이내에 화재가 발생할 경우 화재 알람(FireAlarm) 신이 수행되도록 설정되어 있고, 제2 OCF 룰은, 집 내에서 에너지 소비량이 임계값을 초과한 경우, 저전력(LowPower) 신이 수행되도록 설정되어 있을 수 있다.
카테고리 리스트 리소스에 응급 카테고리 및 일반 카테고리의 2개 카테고리가 정의 및 포함될 수 있다. 제1 OCF 룰은 응급 상황인 화재 상황에 사용되지 위한 룰이므로, 응급 카테고리에 포함될 수 있다. 제2 OCF 룰은 응급 상황과 관련 없이 동작할 수 있으므로 일반 카테고리에 포함될 수 있다. 각 카테고리들에는 제1, 제2 OCF 룰 외에 하나 이상의 다른 OCF 룰들이 포함되어 있을 수 있다. 카테고리 리스트 리소스에는 각 카테고리 별 카테고리 액션이 정의되어 있을 수 있다. 응급 카테고리의 카테고리 액션으로서 응급 카테고리가 아닌 다른 카테고리에 포함된 OCF 룰의 룰 활성을 비활성 상태로 변경하는 액션이 정의될 수 잇다. 일반 카테고리의 카테고리 액션으로서 추가적인 동작이 수행되지 않는다는 액션이 정의될 수 있다.
제1 OCF 룰 내의 룰 표현식이 만족되어 룰 액션으로서 화재 알람 신이 수행되면, 카테고리 리스트 리소스 및/또는 제1 OCF 룰 내의 카테고리 액션 리소스에 정의된 대로 응급 카테고리가 아닌 카테고리에 속하는 OCF 룰의 룰 기능이 비활성화되도록 할 수 있다. 제2 OCF 룰은 응급 카테고리에 속하지 않으므로, 제2 OCF 룰 내의 룰 활성 프로퍼티 값이 false로 업데이트되어 제2 OCF 룰과 관련된 동작들이 비활성화될 수 있다. 카테고리 액션은 카테고리 활성 프로퍼티의 값이 true인 경우에만 수행될 수도 있다. 카테고리 활성 프로퍼티의 값이 false인 경우에는 제1 OCF 룰 내의 룰 표현식이 만족되더라도 룰 액션만이 수행되고 카테고리 액션은 수행되지 않을 수 있다.
제2 OCF 룰 내의 룰 표현식이 만족되어 룰 액션으로서 저전력 신이 화재 알람 신보다 먼저 수행될 수도 있다. 제2 OCF 룰은 일반 카테고리에 속하므로, 제2 OCF 룰과 관련된 동작만이 수행되고 제1 OCF 룰 내의 프로퍼티들은 업데이트되지 않는다. OCF 룰의 특성에 따른 응급 상황의 고려뿐 아니라, 사용자 의도에 의해 카테고리 액션이 활성화 또는 비활성화될 수 있다.
제2 OCF 룰 내의 룰 표현식이 만족되어 룰 액션으로서 저전력 신이 화재 알람 신보다 먼저 수행될 수도 있다. 저전력 신이 수행되면, 카테고리 리스트 리소스 및/또는 제2 OCF 룰 내의 카테고리 액션 리소스에 정의된 대로 추가 동작이 수행되지 않을 수 있다.
도 15는 룰 엔진 내에 추가로 포함될 수 있는 리소스를 나타내는 도면이다.
도 15에 도시된 바와 같이, 룰 엔진 내에는 우선순위 활성(PriorityEnable) 프로퍼티가 포함될 수 있다. 우선순위 활성화 프로퍼티는 응급 상황에서의 우선순위 메커니즘(priority mechanism) 동작을 위해 사용될 수 있다.
우선순위 메커니즘은, 응급 상황에서 특정 카테고리 외의 카테고리에 속하는 모든 OCF 룰들을 비활성화시키기 위해 사용될 수 있다. 예를 들어 응급 카테고리가 존재하고, 응급 카테고리에 속하는 OCF 룰과 관련된 동작이 수행될 때, 우선순위 활성 프로퍼티가 true로 토글링(toggling)되어 우선순위 메커니즘이 수행될 수 있다. 우선순위 메커니즘에 의해 룰 엔진 내의 일반 카테고리에 속하는 모든 OCF 룰들이 비활성화되면, OCF 룰들 간의 충돌이 방지될 수 있다. 사용자에 의해 기 비활성화된 OCF 룰이 있다면, 토글링으로 인한 우선순위 메커니즘 동작 시 기 비활성화된 OCF 룰의 중복 비활성화는 수행되지 않을 수 있다.
또한, 비활성화된 OCF 룰들을 다시 활성화하기 위한 복원 메커니즘(recovery mechanism)이 존재할 수 있다. 응급 상황이 종료되면, 우선순위 메커니즘의 동작으로 인해 비활성화된 OCF 룰들을 다시 활성화하기 위해 복원 메커니즘이 사용될 수 있다. 우선순위 활성 프로퍼티의 값이 false로 업데이트되면 복원 메커니즘이 수행될 수 있다. 복원 메커니즘을 기반으로, 룰 엔진이 기 비활성화한 OCF 룰들이 활성화 상태로 업데이트될 수 있다. 다만, 사용자에 의해 기 비활성화된 OCF 룰이 있다면, 복원 메커니즘 동작 시 사용자에 의해 기 비활성화된 OCF 룰은 활성화되지 않을 수 있다.
우선순위 메커니즘(또는 우선순위 모드)의 동작을 위해 이하의 리소스들이 정의될 수 있다.
룰 카테고리 프로퍼티(또는 리소스)는, 앞서 설명된 바와 같이 OCF 룰 리소스의 목적/특성을 나타내기 위한 속성이다. 예를 들어, OCF 룰 리소스 별로 응급 카테고리 또는 일반 카테고리에 속하는지 여부를 나타낼 수 있다.
룰 엔진(rule engine) 리소스는, 하나 이상의 룰 리소스를 각각 관리 및/또는 제어하기 위한 최상위 리소스이다. 룰 엔진 리소스는 하나 이상의 룰 리소스를 포함하며, 하나 이상의 룰 리소스는 링크들로서 관리된다.
우선순위 활성(priority enable) 프로퍼티는, 룰 엔진 리소스에 포함되는 속성으로서, 우선순위 모드 동작의 활성/비활성 여부를 나타내기 위한 속성이다. 활성/비활성 여부는 불린 형식으로 나타내어질 수 있다. 우선순위 활성 프로퍼티의 값이 true인 경우 우선순위 모드 동작이 활성화되어 일반 카테고리에 속하는 OCF 룰들이 비활성화될 수 있다. 우선순위 활성 프로퍼티의 값이 false인 경우, 우선순위 모드 동작에 의해 비활성화된 OCF 룰들이 다시 활성화(또는 복원)될 수 있다.
우선순위 모드의 동작을 위해서, 룰 리소스 내의 룰 활성 프로퍼티는, 불린 타입으로 2가지 값을 가지지 않고, 3가지 상태를 나타내기 위한 값을 가질 수 있다. 우선순위 모드가 지원되지 않는다면, 룰 활성 프로퍼티는 OCF 룰의 활성/비활성 여부만 나타내면 되어 불린 형식의 값을 가지지만, 우선순위 모드의 동작을 위해서는 사용자의 의도에 의해 비활성화된 OCF 룰과 우선순위 모드의 동작에 의해 비활성화된 OCF 룰이 구분될 필요가 있다. 따라서, 우선순위 모드 동작이 지원될 때 룰 활성 프로퍼티는 3가지 값을 표시하기 위한 형식으로 구성될 수 있다. 예를 들어, 룰 활성 프로퍼티는 표 4와 같이 비트마스크(bitmask) 타입으로 구성되어, OCF 룰 동작의 활성, 우선순위 동작 모드에 의한 비활성, 사용자에 의한 비활성 여부를 나타낼 수 있다.
[표 4]
Figure PCTKR2019007371-appb-img-000004
도 16은 표 4와 같이 룰 활성 프로퍼티가 비트마스크 타입으로 구성된 경우 룰 활성 프로퍼티 값이 업데이트되는 일 예를 나타낸다.
우선순위 활성 프로퍼티의 값이 false에서 true로 토글링되면, 응급 상황을 위해 우선순위 메커니즘이 활성화된다. 우선순위 메커니즘이 활성화되면, 일반 카테고리에 속하며 활성화 상태인 OCF 룰들은 비활성화 상태로 업데이트된다. 우선순위 메커니즘에 의해 OCF 룰이 비활성화되므로, 룰 활성 프로퍼티의 값은 1로 업데이트될 수 있다. 사용자에 의해 기 비활성화된 OCF 룰은 중복하여 비활성화되지 않으므로, 룰 활성 프로퍼티의 값이 2에서 1로 변경되지는 않는다.
우선순위 활성 프로퍼티의 값이 true에서 false로 토글링되면, 응급 상황 종료에 따라 우선순위 메커니즘이 비활성화된다. 우선순위 메커니즘이 비활성화되면, 우선순위 메커니즘의 활성화로 인해 비활성화되었던 OCF 룰들이 활성화 상태로 업데이트된다. 사용자에 의해 비활성화된 OCF 룰은 활성화 상태로 업데이트되지 않는다. 우선순위 활성 프로퍼티의 값이 true에서 false로 토글링됨으로 인해, 값이 1인 룰 활성 프로퍼티의 값은 0으로 업데이트되며, 값이 2인 룰 활성화 프로퍼티의 값은 업데이트되지 않는다.
다시 도 15를 참조하면, 제3 OCF 룰(rule 3)에 포함된 룰 활성 프로퍼티의 값이 2이므로, 제3 OCF 룰은 사용자에 의해 비활성화된 상태이며 우선순위 메커니즘에 의해 제어되지 않는다.
도 17 내지 도 19는 우선순위 메커니즘에 따라 리소스가 변경되는 일 예를 구체적으로 나타낸 도면이다.
제1 OCF 룰(rule 1)은, 집으로부터 일정 범위 이내에 화재가 발생할 경우 화재 알람(FireAlarm) 신이 수행되도록 설정된 OCF 룰로서, 응급 카테고리에 속할 수 있다. 화재 등 응급 상황 발생으로 인해 제1 OCF 룰의 룰 표현식이 만족되면, 룰 엔진 리소스 내의 우선순위 활성 프로퍼티가 도 17과 같이 true로 토글링된다. 우선순위 활성 프로퍼티의 토글링에 의해 우선순위 모드가 활성화된다.
우선순위 모드가 활성화되면, 도 18과 같이, 룰 엔진과 링크된 OCF 룰들인 제1 내지 제5 OCF 룰들 중에서, 일반 카테고리에 속하는 OCF 룰의 기능이 비활성화된다. 비활성화를 위해 제2 OCF룰(rule 2) 및 제4 OCF룰(rule 4)에 포함된 룰 활성 프로퍼티의 값은 1로 업데이트된다. 제3 OCF 룰에 포함된 룰 활성 프로퍼티의 값은 2이므로, 사용자에 의해 비활성화된 OCF 룰에 해당한다. 제3 OCF 룰은 우선순위 모드 활성화에 관계 없이 비활성화가 유지된다. 제5 OCF 룰(rule 5)은 응급 카테고리에 속하므로 비활성화되지 않으며, 제5 OCF 룰에 포함된 룰 활성 프로퍼티의 값은 0으로 유지된다.
화재 등 응급상황이 종료되어 우선순위 모드의 비활성화가 필요한 경우, 도 19와 같이, 우선순위 활성 프로퍼티를 false로 업데이트하여 복원 메커니즘이 동작되도록 할 수 있다. 복원 메커니즘을 통해, 우선순위 모드의 활성화로 인해 비활성화된 OCF 룰들이 활성화된다. 도 19를 참조하면, 값이 1로 변경되었던 제2 OCF 룰과 제4 OCF 룰의 룰 활성 프로퍼티들의 값이 0으로 업데이트된다. 사용자에 의해 비활성화된 제3 OCF 룰은 복원 메커니즘에 의해 활성화되지 않는다. 도 19의 같이, 제3 OCF 룰의 룰 활성 프로퍼티의 값은 사용자에 의해 비활성화되었음을 나타내기 위한 값인 2이므로, 복원 메커니즘에 의해 0으로 업데이트되지 않는다.
도 20은, 우선순위 활성 프로퍼티가 OCF 룰 리소스 외의 룰 엔진 리소스에 포함된 도 17 내지 도 19의 실시예와 달리, OCF 룰 리소스 내에 포함된 경우를 나타낸다.
룰 카테고리 리소스는, 앞서 설명된 바와 같이 OCF 룰이 어느 카테고리에 속하는지를 나타내기 위한 리소스이다. 룰 카테고리 리소스는 해당 OCF 룰이 응급 카테고리에 속하는지 아니면 일반 카테고리에 속하는지 여부를 나타낼 수 있다. 응급 카테고리는 일반 카테고리보다 높은 우선순위를 가질 수 있다. 응급 카테고리에 속하는 OCF룰과 관련된 동작이 수행되는 경우, 해당 OCF 룰 내의 우선순위 활성 프로퍼티의 값이 true가 되고 우선순위 메커니즘이 수행될 수 있다.
우선순위 활성 프로퍼티는, 앞서 설명된 바와 같이 우선순위 메커니즘의 활성/비활성 여부를 표시하기 위한 프로퍼티이다.
우선순위 활성 프로퍼티의 값이 true인 경우, 우선순위 메커니즘이 활성화되고 룰 엔진에 정의된 OCF 룰들 중 일반 카테고리에 속하는 OCF 룰은 비활성화될 수 있다. 또는, 응급 카테고리에 속하지 않는 OCF룰이 비활성화될 수 있다. OCF 룰이 비활성화되면, 해당 OCF 룰에 포함된 룰 표현식이 만족되더라도 룰 액션이 수행되지 않는다. 우선순위 메커니즘이 활성화되더라도, 룰 엔진에 정의된 OCF 룰들 중 응급 카테고리에 속하는 OCF 룰들은 비활성화되거나 어떤 기능이 제한되지 않는다.
우선순위 활성 프로퍼티의 값이 false인 경우, 우선순위 메커니즘이 비활성화되며, 기 비활성화되었던 OCF 룰들이 다시 활성화될 수 있다. 다만, 사용자에 의해 우선순위 메커니즘과 관계 없이 비활성화되었던 OCF 룰은 우선순위 메커니즘의 비활성화와 관계 없이 비활성화 상태가 유지될 수 있다.
도 21은 도 20과 같이 우선순위 활성 프로퍼티가 OCF 룰 리소스 내에 위치하는 경우 룰 활성 프로퍼티 값이 업데이트되는 일 예를 나타낸다.
룰 우선순위 메커니즘은 응급 상황에서 OCF 룰의 속성에 따라 서로 다른 동작이 수행되도록 정의된 메커니즘이다. 우선 순위가 높은 룰(e.g. 응급 카테고리에 속하는 룰)에 포함된 룰 표현식이 만족되어 룰 액션이 수행될 때, 우선순위 메커니즘이 함께 수행될 수 있다. 우선순위 활성 프로퍼티 값이 true로 업데이트되어 우선순위 메커니즘이 활성화되면, 응급 카테고리에 속하는 룰을 제외한 OCF 룰이 비활성화된다. 우선순위 활성 프로퍼티 값은, 사용자에 의해 true로 업데이트될 수 있다. 우선순위 메커니즘 종료될 때까지 일반 카테고리에 속하는 OCF 룰들이 비활성화되므로, 응급 상황에서 사용자가 예상하지 못한 OCF 룰의 동작이 수행되는 것을 방지할 수 있다. 다만 응급 카테고리에 속하는 다른 OCF 룰의 경우 응급 상황 중 해당 OCF 룰이 발생되더라고 치명적인 이슈가 아니라고 보고 해당 OCF 룰의 기능이 제한되지 않을 수 있다. 응급 상황이 종료되어 사용자가 우선순위 활성 프로퍼티 값을 false로 업데이트시키면, 비활성화되었던 OCF 룰들이 다시 활성화(또는 복원 메커니즘이 동작)될 수 있다. 다만, 사용자에 의한 우선순위 메커니즘 활성 이전에, 우선순위 메커니즘과 별개로 비활성화된 OCF 룰들은 우선순위 메커니즘의 비활성화와는 관계 없이 비활성화 상태가 유지될 수 있다.
도 22 내지 도 25는 우선순위 활성 프로퍼티가 OCF 룰 리소스 내에 포함되어 있을 때, 우선순위 메커니즘에 따라 리소스가 변경되는 일 예를 구체적으로 나타낸 도면이다.
제1 OCF 룰(rule 1)은, 집으로부터 일정 범위 이내에 화재가 발생할 경우 화재 알람(FireAlarm) 신이 수행되도록 설정된 OCF 룰로서, 응급 카테고리에 속할 수 있다.
제2 내지 제4 OCF 룰은 일반 카테고리에 속하는 OCF 룰이며, 제5 OCF 룰은 제1 OCF 룰과 동일한 응급 카테고리에 속할 수 있다.
제1 OCF 룰에 포함된 룰 표현식이 만족되면, 도 23과 같이 제1 OCF 룰 내의 룰 결과 프로퍼티의 값이 true로 변경된다. 제1 OCF 룰 내의 우선순위 활성 프로퍼티 값도 true로 변경되며, 우선순위 메커니즘이 활성화된다.
우선순위 메커니즘이 활성화되면, 제2 내지 제5 OCF 룰 내의 우선순위 활성 프로퍼티들의 값이 true로 변경된다. 또한, 일반 카테고리에 속한 제2 내지 제4 OCF 룰이 비활성화된다. 제2 내지 제4 OCF 룰의 비활성화는, 룰 표현식에 대한 제한에 의해 이루어질 수 있다. 룰 표현식이 제한됨으로써, 룰 활성 프로퍼티의 값이 true이더라도 룰 표현식이 만족 여부에 대한 판단이 이루어지지 않을 수 있다. 제5 OCF 룰은 응급 카테고리에 속하므로 비활성화되지 않으며 룰 표현식이 제한되지 않을 수 있다.
응급상황이 종료되어 제1 OCF 룰의 우선순위 활성 프로퍼티가 false로 설정되면, 우선순위 메커니즘이 비활성화된다. 제2 내지 제5 OCF 룰의 우선순위 활성 프로퍼티의 값도 false로 변경된다. 제2 내지 제4 OCF 룰 내의 룰 표현식들에 대한 제한이 해제되고, 제2 내지 제4 OCF룰들의 기능이 다시 활성화된다.
이와 같이 응급 상황의 발생을 고려하여, OCF 룰의 룰 카테고리를 분류함으로써 일반 카테고리에 속하는 OCF 룰을 비활성화하고 응급 카테고리에 속하는 OCF 룰과의 충돌을 방지할 수 있다. 응급 카테고리에 속하여 중요도가 높은 OCF 룰은 다른 OCF 룰에 의한 방해 없이 그 기능이 유지될 수 있다.
도 26은 본 발명의 실시예들에 따른 신호 수신 방법에 대한 흐름도이다.
도 26을 참조하면, 본 발명의 일 실시예는, 하나 이상의 IoT 장치를 제어하는 장치에 의해 수행될 수 있다. 제어 장치에 의해 수행되는 방법은, 제1 룰에 기반하여 하나 이상의 IoT 장치를 제어하기 위한 제1 룰 리소스 및 제2 룰에 기반하여 하나 이상의 IoT 장치를 제어하기 위한 제2 룰 리소스를 설정하는 단계(S2601), 제1 룰 리소스 내의 제1 룰 표현식이 만족되면 제1 룰 액션을 수행하는 단계(S2603)를 포함하여 구성될 수 있다.
제1 룰 리소스는 제1 룰이 응급 상황과 관련되었는지 여부를 나타내기 위한 제1 룰 카테고리 리소스를 포함할 수 있고, 제2 룰 리소스는 제2 룰이 응급 상황과 관련되었는지 여부를 나타내기 위한 제2 룰 카테고리 리소스를 포함할 수 있다.
제1 룰이 응급 상황과 관련되었으며 (제1 룰 카테고리 리소스가 제1 룰이 응급 상황과 관련되었음을 나타내며) 제2 룰은 응급 상황과 관련되지 않은 경우 (제2 룰 카테고리 리소스가 제2 룰이 응급 상황과 관련이 없음을 나타내는 경우), 제어 장치는 제1 룰 표현식이 만족되면 우선순위 메커니즘을 활성화함을 통해 제2 룰을 비활성화(S2605)할 수 있다.
상기 제2 룰이 비활성화되면, 상기 제2 룰 리소스 내의 제2 룰 표현식이 만족되더라도 제2 룰 액션이 수행되지 않는다.
여기서, 제1 룰 리소스 및 제1 룰 리소스는 하나의 룰 엔진 리소스에 포함되어 있을 수 있다. 제2 룰의 비활성화는 제2 룰 표현식에 대한 제한을 통해 수행될 수 있다. 제1 룰 리소스는 우선순위 메커니즘의 활성화 여부를 나타내기 위한 제1 우선순위 활성 프로퍼티를, 제2 룰 리소스는 우선순위 메커니즘의 활성화 여부를 나타내기 위한 제2 우선순위 활성 프로퍼티를 각각 포함할 수 있다.
예를 들어, 제어 장치는 제3 룰에 기반하여 하나 이상의 IoT 장치를 제어하기 위한 제3 룰 리소스를 설정할 수 있다. 제3 룰 리소스는 상기 제3룰이 응급 상황과 관련되었는지 여부를 나타내기 위한 제3 룰 카테고리 리소스를 포함할 수 있다. 제3 룰 카테고리 리소스가 제3 룰이 응급 상황과 관련되었음을 나타내면, 상기 제1 룰 표현식이 만족되어 제어 장치가 상기 우선순위 메커니즘(priority mechanism)을 활성화하더라도 상기 제3 룰은 비활성화되지 않을 수 있다.
제어 장치는 제1 룰 표현식이 만족되지 않게 되면 제1 룰 액션의 수행을 종료할 수 있고, 또한 제어 장치는 우선순위 메커니즘을 비활성화하여 제2 룰이 활성화되도록 할 수 있다.
제어 장치는, 도 26을 통해 도시된 동작에 더하여 도 1 내지 도 25를 통해 제안된 동작들 중 하나 이상을 추가적으로 수행할 수 있다.
장치 구성
도 27은 본 발명의 실시예들을 수행하는 전송장치(10) 및 수신장치(20)의 구성요소를 나타내는 블록도이다. 전송장치(10) 및 수신장치(20)는 정보 및/또는 데이터, 신호, 메시지 등을 나르는 무선 신호를 전송 또는 수신할 수 있는 송신기/수신기(13, 23)와, 무선통신 시스템 내 통신과 관련된 각종 정보를 저장하는 메모리(12, 22), 상기 송신기/수신기(13, 23) 및 메모리(12, 22)등의 구성요소와 동작적으로 연결되어, 상기 구성요소를 제어하여 해당 장치가 전술한 본 발명의 실시예들 중 적어도 하나를 수행하도록 메모리(12, 22) 및/또는 송신기/수신기(13,23)을 제어하도록 구성된 프로세서(11, 21)를 각각 포함한다.
메모리(12, 22)는 프로세서(11, 21)의 처리 및 제어를 위한 프로그램을 저장할 수 있고, 입/출력되는 정보를 임시 저장할 수 있다. 메모리(12, 22)가 버퍼로서 활용될 수 있다. 프로세서(11, 21)는 통상적으로 전송장치 또는 수신장치 내 각종 모듈의 전반적인 동작을 제어한다. 특히, 프로세서(11, 21)는 본 발명을 수행하기 위한 각종 제어 기능을 수행할 수 있다. 프로세서(11, 21)는 컨트롤러(controller), 마이크로 컨트롤러(microcontroller), 마이크로 프로세서(microprocessor), 마이크로 컴퓨터(microcomputer) 등으로도 불릴 수 있다. 프로세서(11, 21)는 하드웨어(hardware) 또는 펌웨어(firmware), 소프트웨어, 또는 이들의 결합에 의해 구현될 수 있다. 하드웨어를 이용하여 본 발명을 구현하는 경우에는, 본 발명을 수행하도록 구성된 ASICs(application specific integrated circuits) 또는 DSPs(digital signal processors), DSPDs(digital signal processing devices), PLDs(programmable logic devices), FPGAs(field programmable gate arrays) 등이 프로세서(11, 21)에 구비될 수 있다. 한편, 펌웨어나 소프트웨어를 이용하여 본 발명을 구현하는 경우에는 본 발명의 기능 또는 동작들을 수행하는 모듈, 절차 또는 함수 등을 포함하도록 펌웨어나 소프트웨어가 구성될 수 있으며, 본 발명을 수행할 수 있도록 구성된 펌웨어 또는 소프트웨어는 프로세서(11, 21) 내에 구비되거나 메모리(12, 22)에 저장되어 프로세서(11, 21)에 의해 구동될 수 있다.
전송장치(10)의 프로세서(11)는 상기 프로세서(11) 또는 상기 프로세서(11)와 연결된 스케줄러로부터 스케줄링되어 외부로 전송될 신호 및/또는 데이터에 대하여 소정의 부호화(coding) 및 변조(modulation)를 수행한 후 송신기/수신기(13)에 전송한다. 예를 들어, 프로세서(11)는 전송하고자 하는 데이터 열을 역다중화 및 채널 부호화, 스크램블링, 변조과정 등을 거쳐 K개의 레이어로 변환한다. 부호화된 데이터 열은 코드워드로 지칭되기도 하며, MAC 계층이 제공하는 데이터 블록인 전송 블록과 등가이다. 일 전송블록(transport block, TB)은 일 코드워드로 부호화되며, 각 코드워드는 하나 이상의 레이어의 형태로 수신장치에 전송되게 된다. 주파수 상향 변환을 위해 송신기/수신기(13)는 오실레이터(oscillator)를 포함할 수 있다. 송신기/수신기(13)는 Nt개(Nt는 1보다 이상의 양의 정수)의 전송 안테나를 포함할 수 있다.
수신장치(20)의 신호 처리 과정은 전송장치(10)의 신호 처리 과정의 역으로 구성된다. 프로세서(21)의 제어 하에, 수신장치(20)의 송신기/수신기(23)는 전송장치(10)에 의해 전송된 무선 신호를 수신한다. 상기 송신기/수신기(23)는 Nr개의 수신 안테나를 포함할 수 있으며, 상기 송신기/수신기(23)는 수신 안테나를 통해 수신된 신호 각각을 주파수 하향 변환하여(frequency down-convert) 기저대역 신호로 복원한다. 송신기/수신기(23)는 주파수 하향 변환을 위해 오실레이터를 포함할 수 있다. 상기 프로세서(21)는 수신 안테나를 통하여 수신된 무선 신호에 대한 복호(decoding) 및 복조(demodulation)를 수행하여, 전송장치(10)가 본래 전송하고자 했던 데이터를 복원할 수 있다.
송신기/수신기(13, 23)는 하나 이상의 안테나를 구비한다. 안테나는, 프로세서(11, 21)의 제어 하에 본 발명의 일 실시예에 따라, 송신기/수신기(13, 23)에 의해 처리된 신호를 외부로 전송하거나, 외부로부터 무선 신호를 수신하여 송신기/수신기(13, 23)로 전달하는 기능을 수행한다. 안테나는 안테나 포트로 불리기도 한다. 각 안테나는 하나의 물리 안테나에 해당하거나 하나보다 많은 물리 안테나 요소(element)의 조합에 의해 구성될 수 있다. 각 안테나로부터 전송된 신호는 수신장치(20)에 의해 더 이상 분해될 수 없다. 해당 안테나에 대응하여 전송된 참조신호(reference signal, RS)는 수신장치(20)의 관점에서 본 안테나를 정의하며, 채널이 일 물리 안테나로부터의 단일(single) 무선 채널인지 혹은 상기 안테나를 포함하는 복수의 물리 안테나 요소(element)들로부터의 합성(composite) 채널인지에 관계없이, 상기 수신장치(20)로 하여금 상기 안테나에 대한 채널 추정을 가능하게 한다. 즉, 안테나는 상기 안테나 상의 심볼을 전달하는 채널이 상기 동일 안테나 상의 다른 심볼이 전달되는 상기 채널로부터 도출될 수 있도록 정의된다. 복수의 안테나를 이용하여 데이터를 송수신하는 다중 입출력(Multi-Input Multi-Output, MIMO) 기능을 지원하는 송신기/수신기의 경우에는 2개 이상의 안테나와 연결될 수 있다.
본 발명의 실시예들에 있어서, 단말 또는 UE는 상향링크에서는 전송장치(10)로 동작하고, 하향링크에서는 수신장치(20)로 동작한다. 본 발명의 실시예들에 있어서, 기지국 또는 eNB는 상향링크에서는 수신장치(20)로 동작하고, 하향링크에서는 전송장치(10)로 동작한다.
상기 전송장치 및/또는 상기 수신장치는 앞서 설명한 본 발명의 실시예들 중 적어도 하나 또는 둘 이상의 실시예들의 조합을 수행할 수 있다.
상기 전송장치 및/또는 수신상치(10, 20)는 기지국, 네트워크 노드, 전송 단말, 수신 단말, 무선 장치, 무선 통신 장치, 차량, 자율주행 기능을 탑재한 차량, 드론(Unmanned Aerial Vehicle, UAV), AI(Artificial Intelligence) 모듈, 로봇, AR(Augmented Reality) 장치, VR(Virtual Reality) 장치 또는 그 이외의 장치일 수 있다.
예를 들어, 단말은 휴대폰, 스마트 폰(smart phone), 노트북 컴퓨터(laptop computer), 디지털 방송용 단말기, PDA(personal digital assistants), PMP(portable multimedia player), 네비게이션, 슬레이트 PC(slate PC), 태블릿 PC(tablet PC), 울트라북(ultrabook), 웨어러블 디바이스(wearable device, 예를 들어, 워치형 단말기 (smartwatch), 글래스형 단말기 (smart glass), HMD(head mounted display)) 등을 포함할 수 있다. 예를 들어, 드론은 사람이 타지 않고 무선 컨트롤 신호에 의해 비행하는 비행체일 수 있다. 예를 들어, HMD는 머리에 착용하는 형태의 디스플레이 장치일 수 있다. 예를 들어, HMD는 VR 또는 AR을 구현하기 위해 사용될 수 있다.
이상에서 설명된 실시예들은 본 발명의 구성요소들과 특징들이 소정 형태로 결합된 것들이다. 각 구성요소 또는 특징은 별도의 명시적 언급이 없는 한 선택적인 것으로 고려되어야 한다. 각 구성요소 또는 특징은 다른 구성요소나 특징과 결합되지 않은 형태로 실시될 수 있다. 또한, 일부 구성요소들 및/또는 특징들을 결합하여 본 발명의 실시예를 구성하는 것도 가능하다. 본 발명의 실시예들에서 설명되는 동작들의 순서는 변경될 수 있다. 어느 실시예의 일부 구성이나 특징은 다른 실시예에 포함될 수 있고, 또는 다른 실시예의 대응하는 구성 또는 특징과 교체될 수 있다. 특허청구범위에서 명시적인 인용 관계가 있지 않은 청구항들을 결합하여 실시예를 구성하거나 출원 후의 보정에 의해 새로운 청구항으로 포함시킬 수 있음은 자명하다.
본 발명은 본 발명의 정신 및 필수적 특징을 벗어나지 않는 범위에서 다른 특정한 형태로 구체화될 수 있음은 당업자에게 자명하다. 따라서, 상기의 상세한 설명은 모든 면에서 제한적으로 해석되어서는 아니되고 예시적인 것으로 고려되어야 한다. 본 발명의 범위는 첨부된 청구항의 합리적 해석에 의해 결정되어야 하고, 본 발명의 등가적 범위 내에서의 모든 변경은 본 발명의 범위에 포함된다.
상술된 바와 같이 본 발명은 다양한 무선 통신 시스템에 적용될 수 있다.

Claims (14)

  1. 무선 통신 시스템에서 하나 이상의 사물 인터넷 (Internet of Things; IoT) 장치를 제어하는 장치에 의해 수행되는 방법에 있어서,
    제1 룰(rule)에 기반하여 상기 하나 이상의 IoT 장치를 제어하기 위한 제1 룰 리소스(rule resource) 및 제2 룰에 기반하여 상기 하나 이상의 IoT 장치를 제어하기 위한 제2 룰 리소스를 설정하는 단계;
    상기 제1 룰 리소스 내의 제1 룰 표현식(rule expression)이 만족되면 제1 룰 액션(rule action)을 수행하는 단계; 를 포함하며,
    상기 제1 룰 리소스는 상기 제1 룰이 응급(emergency) 상황과 관련되었는지 여부를 나타내기 위한 제1 룰 카테고리(rule category) 리소스를 포함하고, 상기 제2 룰 리소스는 상기 제2 룰이 응급 상황과 관련되었는지 여부를 나타내기 위한 제2 룰 카테고리 리소스를 포함하고,
    상기 제1 룰 카테고리 리소스가 상기 제1 룰이 응급 상황과 관련되었음을 나타내며 상기 제2 룰 카테고리 리소스가 상기 제2 룰이 응급 상황과 관련이 없음을 나타내는 경우, 상기 제1 룰 표현식이 만족되면 우선순위 메커니즘(priority mechanism)을 활성화함을 통해 상기 제2 룰을 비활성화하는,
    IoT 장치 제어 방법.
  2. 제1항에 있어서,
    제3 룰에 기반하여 상기 하나 이상의 IoT 장치를 제어하기 위한 제3 룰 리소스를 설정하는 단계; 를 더 포함하며,
    상기 제3 룰 리소스는 상기 제3룰이 응급 상황과 관련되었는지 여부를 나타내기 위한 제3 룰 카테고리 리소스를 포함하고,
    상기 제3 룰 카테고리 리소스가 상기 제3 룰이 응급 상황과 관련되었음을 나타내면, 상기 제1 룰 표현식이 만족되어 상기 우선순위 메커니즘(priority mechanism)이 활성화되더라도 상기 제3 룰은 비활성화되지 않는,
    IoT 장치 제어 방법.
  3. 제1항에 있어서,
    상기 제1 룰 리소스는 상기 우선순위 메커니즘의 활성화 여부를 나타내기 위한 제1 우선순위 활성(priority enable) 프로퍼티(property)를 포함하고, 상기 제2 룰 리소스는 상기 우선순위 메커니즘의 활성화 여부를 나타내기 위한 제2 우선순위 활성 프로퍼티를 포함하는,
    IoT 장치 제어 방법.
  4. 제1항에 있어서,
    상기 제1 룰 표현식이 만족되지 않게 되면, 상기 제1 룰 액션의 수행을 종료하는 단계; 를 더 포함하며,
    상기 우선순위 메커니즘을 비활성화함을 통해 상기 제2 룰을 활성화하는,
    IoT 장치 제어 방법.
  5. 제1항에 있어서,
    상기 제2 룰이 비활성화되면, 상기 제2 룰 리소스 내의 제2 룰 표현식이 만족되더라도 제2 룰 액션이 수행되지 않는,
    IoT 장치 제어 방법.
  6. 제1항에 있어서,
    상기 제1 룰 리소스 및 상기 제2 룰 리소스는 하나의 룰 엔진(rule engine) 리소스에 포함된,
    IoT 장치 제어 방법.
  7. 제1항에 있어서,
    상기 제2 룰의 비활성화는, 상기 제2 룰 표현식에 대한 제한(constraint)을 통해 수행되는,
    IoT 장치 제어 방법.
  8. 무선 통신 시스템에서 하나 이상의 사물 인터넷 (Internet of Things; IoT) 장치를 제어하는 장치에 있어서,
    송수신기; 및
    상기 송수신기를 제어하는 프로세서; 를 포함하며,
    상기 프로세서는,
    제1 룰(rule)에 기반하여 상기 하나 이상의 IoT 장치를 제어하기 위한 제1 룰 리소스(rule resource) 및 제2 룰에 기반하여 상기 하나 이상의 IoT 장치를 제어하기 위한 제2 룰 리소스를 설정하고,
    상기 제1 룰 리소스 내의 제1 룰 표현식(rule expression)이 만족되면 제1 룰 액션(rule action)을 수행하도록 구성되며,
    상기 제1 룰 리소스는 상기 제1 룰이 응급(emergency) 상황과 관련되었는지 여부를 나타내기 위한 제1 룰 카테고리(rule category) 리소스를 포함하고, 상기 제2 룰 리소스는 상기 제2 룰이 응급 상황과 관련되었는지 여부를 나타내기 위한 제2 룰 카테고리 리소스를 포함하고,
    상기 제1 룰 카테고리 리소스가 상기 제1 룰이 응급 상황과 관련되었음을 나타내며 상기 제2 룰 카테고리 리소스가 상기 제2 룰이 응급 상황과 관련이 없음을 나타내는 경우, 상기 프로세서는 상기 제1 룰 표현식이 만족되면 우선순위 메커니즘(priority mechanism)을 활성화함을 통해 상기 제2 룰을 비활성화하는,
    제어 장치.
  9. 제8항에 있어서,
    상기 프로세서는, 제3 룰에 기반하여 상기 하나 이상의 IoT 장치를 제어하기 위한 제3 룰 리소스를 설정하도록 더 구성되며,
    상기 제3 룰 리소스는 상기 제3룰이 응급 상황과 관련되었는지 여부를 나타내기 위한 제3 룰 카테고리 리소스를 포함하고,
    상기 제3 룰 카테고리 리소스가 상기 제3 룰이 응급 상황과 관련되었음을 나타내면, 상기 제1 룰 표현식이 만족되어 상기 우선순위 메커니즘(priority mechanism)이 활성화되더라도 상기 제3 룰은 비활성화되지 않는,
    제어 장치.
  10. 제1항에 있어서,
    상기 제1 룰 리소스는 상기 우선순위 메커니즘의 활성화 여부를 나타내기 위한 제1 우선순위 활성(priority enable) 프로퍼티(property)를 포함하고, 상기 제2 룰 리소스는 상기 우선순위 메커니즘의 활성화 여부를 나타내기 위한 제2 우선순위 활성 프로퍼티를 포함하는,
    제어 장치.
  11. 제8항에 있어서,
    상기 제1 룰 표현식이 만족되지 않게 되면, 상기 제1 룰 액션의 수행을 종료하는 단계; 를 더 포함하며,
    상기 우선순위 메커니즘을 비활성화함을 통해 상기 제2 룰을 활성화하는,
    제어 장치.
  12. 제8항에 있어서,
    상기 제2 룰이 비활성화되면, 상기 제2 룰 리소스 내의 제2 룰 표현식이 만족되더라도 제2 룰 액션이 수행되지 않는,
    제어 장치.
  13. 제8항에 있어서,
    상기 제1 룰 리소스 및 상기 제2 룰 리소스는 하나의 룰 엔진(rule engine) 리소스에 포함된,
    제어 장치.
  14. 제8항에 있어서,
    상기 제2 룰의 비활성화는, 상기 제2 룰 표현식에 대한 제한(constraint)을 통해 수행되는,
    제어 장치.
PCT/KR2019/007371 2018-06-19 2019-06-19 무선 통신 시스템에서 iot 장치를 제어하는 방법 및 장치 WO2019245274A1 (ko)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
KR10-2018-0070463 2018-06-19
KR20180070463 2018-06-19
KR20180081928 2018-07-13
KR10-2018-0081928 2018-07-13
KR20180112518 2018-09-19
KR10-2018-0112518 2018-09-19

Publications (1)

Publication Number Publication Date
WO2019245274A1 true WO2019245274A1 (ko) 2019-12-26

Family

ID=68984301

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2019/007371 WO2019245274A1 (ko) 2018-06-19 2019-06-19 무선 통신 시스템에서 iot 장치를 제어하는 방법 및 장치

Country Status (1)

Country Link
WO (1) WO2019245274A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114830604A (zh) * 2020-01-10 2022-07-29 Oppo广东移动通信有限公司 信息处理方法、装置及设备

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120326608A1 (en) * 2011-06-21 2012-12-27 Enlighted, Inc. Intelligent and Emergency Light Control
US20140244997A1 (en) * 2013-02-25 2014-08-28 Qualcomm Incorporated Emergency mode for iot devices
WO2016137552A1 (en) * 2015-02-24 2016-09-01 BrainofT Inc. Automatically learning and controlling connected devices
US20170027045A1 (en) * 2015-07-23 2017-01-26 Digital Lumens, Inc. Intelligent lighting systems and methods for monitoring, analysis, and automation of the built environment
WO2017205770A1 (en) * 2016-05-27 2017-11-30 Afero, Inc. System and method for establishing secure communication channels with internet things (iot) devices

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120326608A1 (en) * 2011-06-21 2012-12-27 Enlighted, Inc. Intelligent and Emergency Light Control
US20140244997A1 (en) * 2013-02-25 2014-08-28 Qualcomm Incorporated Emergency mode for iot devices
WO2016137552A1 (en) * 2015-02-24 2016-09-01 BrainofT Inc. Automatically learning and controlling connected devices
US20170027045A1 (en) * 2015-07-23 2017-01-26 Digital Lumens, Inc. Intelligent lighting systems and methods for monitoring, analysis, and automation of the built environment
WO2017205770A1 (en) * 2016-05-27 2017-11-30 Afero, Inc. System and method for establishing secure communication channels with internet things (iot) devices

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114830604A (zh) * 2020-01-10 2022-07-29 Oppo广东移动通信有限公司 信息处理方法、装置及设备
CN114830604B (zh) * 2020-01-10 2023-08-29 Oppo广东移动通信有限公司 信息处理方法、装置及设备

Similar Documents

Publication Publication Date Title
WO2020067736A1 (en) Method and apparatus for preventing loss of uplink data in wireless communication system
WO2020036460A1 (en) Method and apparatus for supporting early data transmission in inactive state in wireless communication system
WO2020017941A1 (en) Method and apparatus for supporting link congestion detection in wireless communication system
WO2018164498A1 (ko) 단말 개시 통신 전용 모드 단말의 연결을 유지시키는 방법
WO2020091443A1 (en) Deactivation of configured grant and initiation of connection request upon detection of sidelink failure
WO2020149718A1 (en) Method and apparatus for access control in wireless communication system
WO2022186657A1 (en) Method and apparatus for support of machine learning or artificial intelligence techniques in communication systems
WO2020167036A1 (en) Method and apparatus for failure notification on backhaul link in wireless communication system
WO2019221530A1 (en) Method and apparatus for discarding data among associated transmission buffers in wireless communication system
WO2020166872A1 (en) Method and apparatus for controlling early data transmission procedure in a wireless communication system
WO2021230700A1 (ko) Nr v2x에서 사이드링크 재전송 패킷을 수신하는 방법 및 장치
WO2020067763A1 (en) Relaxed measurement based on data transmission
WO2022025682A1 (ko) Nr v2x에서 절전 모드 별 drx 동작을 수행하는 방법 및 장치
WO2014073902A1 (en) Method and apparatus for providing web service in wireless communication system
WO2020145726A1 (ko) Nr v2x에서 bwp 기반의 통신을 수행하는 방법 및 장치
WO2019245274A1 (ko) 무선 통신 시스템에서 iot 장치를 제어하는 방법 및 장치
WO2022039475A1 (en) Methods and systems for aggregating and exchanging messages in an iot communication system
WO2022086184A1 (ko) Nr v2x에서 sl csi를 보고하는 방법 및 장치
WO2021020834A1 (ko) 단말이 네트워크에 접속하는 방법
WO2020071851A1 (en) Radio link monitoring
WO2020091181A1 (ko) 무선 통신 시스템에서 신호를 송수신하는 방법 및 장치
WO2023075136A1 (ko) 라디오 자원 제어 상태를 변경하기 위한 전자 장치 및 동작 방법
WO2021153982A1 (en) Method and apparatus for informing changes in coverage enhancement usage in a network
WO2022086182A1 (ko) Nr v2x에서 sl drx 동작 시 모드2 자원 재평가 및 프리앰션을 수행하는 방법 및 장치
WO2022050674A1 (ko) 사이드링크 릴레잉에서 이종 네트워크 재선택을 수행하기 위한 방법 및 장치

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19822363

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19822363

Country of ref document: EP

Kind code of ref document: A1