WO2017111191A2 - Integrated sensor data management device and method therefor - Google Patents

Abstract

A method for processing sensor data on the basis of an integrated sensor data model according to an embodiment of the present invention may comprise the steps of: collecting sensor data according to a plurality of protocols; converting the collected sensor data into sensor data according to the integrated sensor data model; and storing the converted sensor data, wherein the converted sensor data includes a sensor device data set, a sensor entity data set, and a sensor data set, and the sensor device data set includes information related to physical sensor devices, the sensor entity data set includes information related to physical indexes measured by the physical sensor devices, and the sensor data set includes information on measurement values of the physical indexes and time points at which the measurement values are measured.

Description

Integrated sensor data management device and method for it

The present invention is directed to a data model for sensors of various heterogeneous protocols and an architecture capable of processing them.

The sensor network is partially distributed and automated, delivering data to a central system via wireless or wired sensors that can monitor physical or environmental conditions (eg, temperature, sound, pressure, etc.). In unidirectional communication, recently, controllable sensors have become possible to support bidirectional communication.

1 is a summary of the wireless sensor network architecture, originally intended for military purposes, to monitor / bound enemy movement on the battlefield. Today, however, it is used for industrial and personal users. For example, it is widely applied to factory process management, machine control, and security systems.

Sensor networks that are currently commercialized have been standardized by several standards bodies. However, when a large number of sensor nodes (or sensor devices, sensor devices, etc.) are connected to each other, standardization of how to process the data measured from each sensor is also expected. As such, the sensor data structures / models for transmitting the data obtained by the sensor nodes to the gateway and the management system and processing the information are diverse and complicated and need to be standardized. Through standardization, sensor nodes, gateways and the size and period of data to be transmitted should be easily identified to construct sensor networks and to systematically organize data to enable information processing.

The present invention proposes a generalized data structure capable of analyzing and managing characteristics of sensors, and makes these common data structures a standardized data type and maps them to values of various sensors. These data structures are complex and require data processing according to the characteristics of each sensor. Therefore, this paper proposes a standard interface between each module and an architecture that can have functions that match the sensor's data model and characteristics.

If the sensor data-based architecture and standard interface are defined, the data-based machine-to-machine communication function can be implemented by using the collected information of the sensors.

In the method for processing sensor data according to the integrated sensor data model according to an embodiment of the present invention, the method comprises the steps of collecting sensor data according to a plurality of protocols, the collected sensor data to the integrated sensor data model And converting the sensor data into the sensor data, and storing the converted sensor data, wherein the converted sensor data includes a sensor device data set, a sensor entity data set, and a sensor data set. Includes information related to a physical sensor device, wherein the sensor entity data set includes information related to a physical indicator measured by the physical sensor device, wherein the sensor data set includes the measured values and the measured values of the physical indicator. Contains information about the measured time Can.

Additionally or alternatively, the sensor device data set may include a list of physical indicators measured by the physical sensor device and location information where the physical sensor device is installed.

Additionally or alternatively, the location information in which the physical sensor device is installed may include at least three types of hierarchical location information.

Additionally or alternatively, the sensor entity data set may include information indicating one of multiple levels, binary or meter data types.

Additionally or alternatively, the sensor entity data set may include information about an entity type indicating the physical indicator.

Additionally or alternatively, the method may further comprise converting and storing the changed sensor data into sensor data according to the integrated sensor data model according to the change notification of the sensor data of the plurality of protocols.

Additionally or alternatively, the modified sensor data may be received by request to each physical sensor device in accordance with the plurality of protocols.

Additionally or alternatively, the modified sensor data can be received without a request to each physical sensor device according to the plurality of protocols.

Additionally or alternatively, the method further comprises broadcasting a message corresponding to the event if a condition of a registered event is satisfied for at least some of the sensor data of the plurality of protocols, the condition further comprising: And at least one of hierarchical position information of a sensor device data set and an entity type indicating the physical indicator included in the sensor entity data set.

An apparatus configured to process sensor data according to an integrated sensor data model according to another embodiment of the invention, the apparatus configured to control a radio frequency (RF) unit, a memory and the RF unit and the memory A processor, wherein the processor collects sensor data according to a plurality of protocols, converts the collected sensor data into sensor data according to the integrated sensor data model, and stores the converted sensor data in the memory. And the converted sensor data includes a sensor device data set, a sensor entity data set, and a sensor data set, the sensor device data set including information related to a physical sensor device, and the sensor entity data set includes the physical Water measured by sensor device Including information concerning enemy surface, wherein the sensor data set may include information about the measured values to the measured time and the measured value of said physical index.

Additionally or alternatively, the sensor device data set may include a list of physical indicators measured by the physical sensor device and location information where the physical sensor device is installed.

 Additionally or alternatively, the location information in which the physical sensor device is installed may include at least three types of hierarchical location information.

Additionally or alternatively, the sensor entity data set may include information indicating one of multiple levels, binary or meter data types.

Additionally or alternatively, the sensor entity data set may include information about an entity type indicating the physical indicator.

Additionally or alternatively, the processor may be configured to convert and store the changed sensor data into sensor data according to the integrated sensor data model according to a change notification of the sensor data of the plurality of protocols.

Additionally or alternatively, the modified sensor data may be received by request to each physical sensor device in accordance with the plurality of protocols.

Additionally or alternatively, the modified sensor data can be received without a request to each physical sensor device according to the plurality of protocols.

Additionally or alternatively, the processor is configured to broadcast a message corresponding to the event if a condition of a registered event is satisfied for at least some of the sensor data of the plurality of protocols, wherein the condition is the sensor device data. And at least one of hierarchical position information of a set and an entity type indicating the physical indicator included in the sensor entity data set.

The problem solving methods are only a part of embodiments of the present invention, and various embodiments reflecting the technical features of the present invention are based on the detailed description of the present invention described below by those skilled in the art. Can be derived and understood.

The present invention provides an integrated sensor data model of various existing heterogeneous protocol sensors and has an effect that can be utilized for the purpose of integrating / processing various protocol sensors.

The present invention has the effect of providing a method of providing sensor data in a consistent format to a user through the integrated sensor data model, and providing data grouped by a user's desired criteria.

The present invention has an effect that can provide a method for creating / registering an event by combining various conditions desired by a user through an integrated sensor data model.

Effects obtained in the present invention are not limited to the above-mentioned effects, and other effects not mentioned above may be clearly understood by those skilled in the art from the following description. will be.

BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are included as part of the detailed description in order to provide a thorough understanding of the present invention, provide an embodiment of the present invention and together with the description, illustrate the technical idea of the present invention.

1 illustrates a wireless sensor network architecture.

2 shows a sensor agent and a sensor device or home appliance deployed in a home.

3 illustrates a data processing operation according to an embodiment of the present invention.

4 illustrates an event processing operation according to an embodiment of the present invention.

5 shows an overview of an integrated sensor data model according to one embodiment of the invention.

6 illustrates a data structure of an integrated sensor data model according to one embodiment of the invention.

7 illustrates a data structure of Installation Id according to an embodiment of the present invention.

8 illustrates an expression grammar for a factor for expressing an attribute of an integrated sensor data model according to an embodiment of the present invention.

9 illustrates an expression grammar for a work instruction for expressing an attribute of an integrated sensor data model, according to an embodiment of the invention.

10 illustrates an expression grammar of a condition for expressing a condition of an attribute of the integrated sensor data model according to an embodiment of the present invention.

11 illustrates a sensor agent structure of an integrated sensor data model according to one embodiment of the invention.

12 illustrates an API call procedure between a sensor agent client and a sensor agent according to an embodiment of the present invention.

FIG. 13 illustrates a procedure for transmission of measurement data between a sensor device and a sensor air agent, according to an embodiment of the invention.

14 illustrates a procedure between a sensor agent client and a sensor agent at the time of sensor data update according to an embodiment of the present invention.

FIG. 15 illustrates a procedure between a rule engine and a sensor agent when updating sensor data according to an embodiment of the present invention.

16 illustrates a database structure of a sensor agent according to an embodiment of the present invention.

17 illustrates a structure of a sensor data receiver according to an embodiment of the present invention.

18 illustrates an operation for processing device information of a sensor data receiver according to an embodiment of the present invention.

19 illustrates an operation for processing data information of a sensor data receiver according to an embodiment of the present invention.

20 illustrates a structure of a sensor agent device according to an embodiment of the present invention.

21 shows a block diagram of an apparatus according to an embodiment of the present invention.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. The detailed description, which will be given below with reference to the accompanying drawings, is intended to explain exemplary embodiments of the present invention and is not intended to represent the only embodiments in which the present invention may be practiced. The following detailed description includes specific details in order to provide a thorough understanding of the present invention. However, one of ordinary skill in the art appreciates that the present invention may be practiced without these specific details.

In some instances, well-known structures and devices may be omitted or shown in block diagram form centering on the core functions of the structures and devices in order to avoid obscuring the concepts of the present invention. In addition, the same components will be described with the same reference numerals throughout the present specification.

2 illustrates a sensor network installed in a home. As shown in the drawing, sensors in the home may be included in sensor networks such as Z-Wave, BLE, and ZigBee, as well as home appliances such as refrigerators and air conditioners, and may exist in a local network. The sensor agent is a system that collects data of all commercial sensors existing in the sensor network and the local network, and then converts the data into an integrated sensor data model defined in the present invention and stores it in a database / cloud.

The processed sensor data can be provided not only to local network area devices such as AllJoyn and OIC, but also to external network area devices such as smartphones and tablet PCs through the cloud based on query / event. In addition to simply processed data, it can provide data grouped according to the user's desired criteria. 3 briefly shows an operation flow for such a series of data processing.

The sensor agent may collect sensor data of various protocols (S310). The sensor agent may convert the collected sensor data into the integrated sensor data model defined in the present invention (S320). Then, the sensor agent may store the converted data in the database / cloud (S330). The sensor agent may provide the client with grouped data based on a query / event basis or a condition (S340).

In addition, by defining / registering a new event in the sensor agent by combining desired conditions through the integrated sensor data model, an event is generated when the condition is met. Based on these events, a service such as IFTTT (if this, then that) can automatically control local / external network area devices. 4 briefly illustrates an operation flow for processing a series of events.

An event combining a sensor data model based condition through a sensor agent may be defined or registered (S410). The sensor agent may check whether the periodic condition is met through the database / cloud (S420). If you are in a condition, the sensor agent can provide an event.

Integrated Sensor Data Model

Various existing protocols have their own sensor data models, but to collect them all at once and provide useful information, an integrated sensor data model is required. Without this integrated sensor data model, a separate system for processing each data model is required for each protocol, which is inefficient, and data of different protocols are managed separately to provide limitations in providing more useful information to a user.

In addition, using existing sensor data models may not provide data grouped according to a user's desired criteria. Recently, there are many systems that create new conditions by combining the conditions that the user wants and generate an event when the conditions are met. Existing data models allow other conditions such as location and data type to be used in addition to specific data values. Can not use it.

Therefore, we define a new integrated sensor data model to solve and solve these problems.

Sensor Data Features and Processing Methods

Sensor data may be collected through various devices including home appliances as well as sensor devices. You can get the information you want to know directly through the sensor devices, and home appliances with built-in sensors can automatically control the device using the sensor data.

Sensor data can be divided into three types according to data type.

The first is data indicating the measured values such as current temperature, humidity and illuminance. This type of data can be meaningful not only for the current value itself, but also for the previous values and the mean values for a particular time period. Therefore, it may be important to store historical data and process it for the desired purpose.

The second is data indicating what state changes, such as whether the current door is open or if a movement has occurred. For this type of data, it may be more important to process the data in real time so that you know immediately when the state changes rather than the current or past state itself.

Finally, the third is data representing accumulated values such as power consumption and gas consumption during a specific period. It is not important to process this type of data in real time, and it may be important to provide data so that the cumulative value changes over time.

Accordingly, data types of the integrated sensor data model are classified into multilevel, binary, and meter.

5 illustrates an integrated sensor data model according to one embodiment of the invention. In FIG. 5, the sensor device is matched one-to-one with the physical sensor device on a basic instrument basis. Such a sensor device may be composed of one or more sensor entities.

For example, one sensor device may have two sensor entities whose entity types are "Temperature" and "Luminance". The sensor entity is a unit in which a sensor agent collects data, and information such as "Temperature", "Luminance", "Humidity", "UV", "Motion", and "Vibration" may be represented as a sensor entity. The sensor data consists of actual data collected by the sensor device and updated time stamps. Each sensor entity has a list of such sensor data.

Sensor entities are classified into three data types, such as multilevel, binary, and meter, as shown in the table below, according to the aforementioned data types. Table 1 shows three data types and one unknown data type. According to this classification, the data structure and entity type of the sensor entity are defined differently.

Table 1 Data type value detailed description Unknown 0x00 Unknown Multilevel 0x01 Measured values such as current temperature, humidity, and illuminance Binary 0x02 State changes, such as whether the door is open or motion Meter 0x03 Accumulated value such as power consumption and gas consumption during a specific period

6 shows an integrated sensor data model structure of a "MultiSensor" sensor device having a "Temperature" sensor entity with a multilevel data type, a "Motion" sensor entity with a data type binary and a "Electric" sensor entity with a data type meter. An example is shown.

sensor Device  Data structure

The sensor device has a structure as shown in the table below. The sensor device has a list of sensor entity IDs and information related to the physical sensor device. "Nickname" and "Installation Id" are values entered by the user.

TABLE 2 Information type detailed description example Device id Int ID of Sensor Device 15 Manufacturer String manufacturer LG Electronics Model Name String model name SA512 Device name String Device name MultiSensor Serial Number String Serial Number 123-598-624 UUID String Unique id 46c98014c56d2cbb Protocol Enum Sensor Network Protocol See Table 3 below Version String SW version 1.2 Nickname String Nickname Home Multi Sensor Installation Id Int ID of Installation See Table 4 below Sensor Entity Id List Sensor Entity Id List List of Sensor Entity Ids See tables 9, 13 and 16

A "protocol" value of type Enum is defined in the table below. Currently it includes Z-Wave, ZigBee, BLE, Alljoyn, OIC, and so on.

TABLE 3 protocol value detailed description Unknown 0x00 Unknown Z-Wave 0x01 Z-Wave standard technology ZigBee 0x02 ZigBee standard technology BLE 0x03 BLE standard technology Alljoyn 0x04 Alljoyn standard technology IoTivity 0x05 Open source project for IoT connectivity solutions as defined by the Open Interconnect Consortium (OIC) Reserved 0x06 to 0xFF Reserved

"Installation Id" contains the ID of Location, Boundary, and Material, which contains information about the location where the sensor device is installed as shown in the table below. Location represents the top level information about the location, and the sub information in the order of Boundary and Material. For example, if the location where the sensor device is installed is '1st floor living room window', the location will include 'My home', the Boundary is '1st floor living room', and the material 'Window'. Tables 4 to 7 below show "Installation Id" and information included therein. 7 shows the information shown in Tables 4 to 7 graphically.

Table 4 Information type detailed description example Installation Id Int ID of Installation 24 Location id Int ID of Location See Table 5 below Boundary Id Int Boundary ID See Table 6 below Material id Int ID of the material See Table 7 below

Table 5 Information type detailed description example Location id Int ID of Location 32 Name String Name of Location my house Address String Location's address Yangjae-dong, Seocho-gu, Seoul

Table 6 Information type detailed description example Boundary Id Int The ID of the Boundary 46 Name String Boundary's name Livingroom Floor String Boundary layer First floor Location id Int ID of Location See Table 5

TABLE 7 Information type detailed description example Material id Int ID of the material 53 Name String Name of the material window Boundary Id Int Boundary ID See Table 6

Through the information on the location where the sensor device is installed, it is possible to bundle only the data of the desired location among a large amount of sensor data and provide them at once. For example, if a user wants to collect only the sensor data in the '5th floor window' in a tall building, the sensor agent can provide the desired data using the "Boundary" and "Material" information.

In addition, a group as shown in the following table can be created to bundle and manage only desired sensor devices. By creating a group and adding sensor devices, data of desired sensor devices may be imported at once.

Table 8 Information type detailed description example Group id Int ID of the Group One Name String Name of Group Dad sensor Sensor Device Id List Sensor Device Id List List of Sensor Device Ids See Table 2

Structure of sensor entity with data level multilevel

The data structure of the sensor entity whose data type is multilevel is shown in the following table. This sensor entity contains a list of sensor data and sensor data related information such as data type, category, entity type, current value, minimum value and maximum value.

Table 9 Information type detailed description example Data type Enum Data type 0x01 (Multilevel) Category Enum Data category See Table 10 Entity Type Enum Data attributes See Table 11 Current Value Double Current data value 24.57 Min value Int Data minimum 0 Max Value Int Data max 100 Sensor Data List Sensor Data List List of Sensor Data See Table 12

Since the data type is multilevel in the above table, the data type is 0x01 according to Table 1, and the category and entity type values of the sensor entity are defined as in the following table. The categories are classified into four categories, Environmental, Biometric, Electrical, and Mechanical, as shown in the table below.

Table 10 category value detailed description Unknown 0x00 Unknown Environmental 0x01 Environment related category Biometric 0x02 Biometric Related Categories Electrical 0x03 Electrical Related Categories Mechanical 0x04 Machine related categories

Through this category classification, it is possible to bundle only the data of the desired category among a large amount of sensor data and provide them at once. For example, if a user wants to collect only sensor data of 'environment related category', the sensor agent can provide the desired data using this category information.

By type, entity types are classified and defined as shown in the table below.

Table 11 category type value Scale Unknown Unknown 0x000 Unknown Environmental Air temperature 0x001 Celsius Water temperature 0x002 Celsius Soil temperature 0x003 Celsius Humidity 0x004 Percentage Soil humidity 0x005 Percentage Illunce 0x006 Lux Atmospheric Pressure 0x007 kPa Barometric pressure 0x008 kPa Solar radiation 0x009 W / m ² Dew point 0x00A Celsius Rain rate 0x00B mm / h Tide Level 0x00C m CO2 Level 0x00D ppm Air flow 0x00E m3 / h Seismic intensity 0x00F Meralli Seismic magnitude 0x010 ML Ultraviolet 0x011 UV index Loudness 0x012 dB Moisture 0x013 Percentage Formaldehyde Level 0x014 mol / m3 Radon concentration 0x015 bq / m3 Methane density 0x016 mol / m3 Volatile Organic Compound 0x017 mol / m3 CO Level 0x018 mol / m3 Soil reactivity 0x019 pH (acidity) Soil salinity 0x01A mol / m3 Smoke density 0x01B Percentage Biometric Heart rate 0x01C Bpm Blood Pressure-Systolic 0x01D mmHg Blood Pressure-Diastolic 0x01E mmHg Muscle mass 0x01F Kg Fat mass 0x020 Kg Bone mass 0x021 Kg Fat free mass 0x022 Kg Total Body Water (TBW) 0x023 Kg Basic Metabolic Rate (BMR) 0x024 J Body Mass Index (BMI) 0x025 BMI Index Pulse rate 0x026 Bpm Glucose level 0x027 mg / dL Prothrombin Time 0x028 Second Body height 0x029 cm Body weight 0x02A Kg Body temperature 0x02B Celsius Insulin level 0x02C uIU / mL Peak Expiratory Flow (PEF) 0x02D L / m Electrical Current 0x02E A Electrical Resistivity 0x02F Ωm Electrical Conductivity 0x030 Siemens per metre Power 0x031 Watt Voltage 0x032 V Mechanical Tank capacity 0x033 Liter Distance 0x034 m Rotation 0x035 rpm Frequency 0x036 Hz Time 0x037 Second Acceleration X-axis 0x038 m / s2 Acceleration Y-axis 0x039 m / s2 Acceleration Z-axis 0x03A m / s2 Multilevel Switch 0x03B - Battery level 0x03C Percentage Target temperature 0x03D Celsius Device temperature 0x03E Celsius Weight 0x03F kg Velocity 0x040 m / s Direction 0x041 Degree

The Sensor Data List consists of a list of sensor data, and the data structure of the sensor data is defined as shown in the table below. The actual sensor data will be Value * 10 ^Exponent . For example, if Value is 2457 and Exponent is -2, then the actual data is 2457 * 10 ^-2 = 24.57.

Table 12 Information type detailed description example Exponent Int Exponent of Value for Data Value -2 Value Int Number except decimal point of data value 2457 Time stamp Unsigned Long Time the value changed in milliseconds 1374659200

Data structure of sensor entity whose data type is binary

The data structure of the sensor entity whose data type is binary is shown in the table below. This entity has a list of sensor data and sensor data related information such as data type, entity type, and current value.

Table 13 Information type detailed description example Data type Enum Data type 0x02 (Binary) Entity Type Enum Data attributes See Table 14 Current Value Bool Current data value TRUE Sensor Data List Sensor Data List List of Sensor Data See Table 15

Since the data type is binary, the data type is 0x02 according to Table 1, and the entity type of the sensor entity is defined as shown in the table below.

Table 14 type value detailed description Unknown 0x100 Unknown Smoke 0x101 True: Detected CO 0x102 True: Detected CO2 0x103 True: Detected Heat 0x104 True: Overheated Water 0x105 True: Overflowed Freeze 0x106 True: Frozen Tamper 0x107 True: Detected Aux 0x108 True: Detected Door / Window 0x109 True: Opened Tilt 0x10A True: Tilted Motion 0x10B True: Detected Glass break 0x10C True: Detected Fire 0x10D True: Detected Binary Switch 0x10E True: On Intrusion 0x10F True: Detected Power applied 0x110 True: Applied AC Disconnected 0x111 True: Disconnected Battery Full Charged 0x112 True: Charged Timer ended 0x113 True: Ended Fall (Concussion) 0x114 True: Detected Medication Dosage 0x115 True: Alarmed Vibration 0x116 True: Detected Presence 0x117 True: Occupied Personal emergency 0x118 True: Alarmed

The sensor data list consists of a list of sensor data, and the data structure of the sensor data is defined as shown in the table below.

Table 15 Information type detailed description example Value Bool Data value indicating status FALSE Time stamp Unsigned Long Time the value changed in milliseconds 1374659200

Data structure of sensor entity with data type meter

The data structure of the sensor entity whose data type is meter is shown in the table below.

Table 16 Information type detailed description example Data type Enum Data type 0x03 (Meter) Entity Type Enum Data attributes See Table 17 Current Value Double Current data value 3.798 Sensor Data List Sensor Data List List of Sensor Data See Table 18

Since the data type is a meter, the data type is 0x03 according to Table 1, and the entity type of the sensor entity is defined as shown in the table below.

Table 17 type value Scale Unknown 0x200 Unknown Electric 0x201 kWh Gas 0x202 Cubic meter Water 0x203 Cubic meter Heating 0x204 m ³ Cooling 0x205 m ³ Used Time 0x206 Minute

The Sensor Data List consists of a list of sensor data, and the data structure of the sensor data is defined as shown in the table below. As with multilevel, the actual sensor data has a value of 10 ^Exponent . For example, if Value is 3798 and Exponent is -3, the actual data value is 3798 * 10 ^-3 = 3.798.

Table 18 Information type detailed description example Exponent Int Exponent of Value for Data Value -3 Value Unsigned Int Number except decimal point of data value 3798 Time stamp Unsigned Long Time the value changed in milliseconds 1374659200

Expressions to leverage the integrated sensor data model

Due to the nature of the sensor, a large number of sensors are often installed in a building or a house, and in order to manage information of such a large amount of sensors, a method that can be effectively expressed using the attribute values of the integrated sensor data model described above is required. The syntax to express this is as follows:

Argument

Argument is the minimum expression to express the property of the integrated sensor data model. Factors can be used to express conditions for property values of the sensor data model. 8 shows the syntax for arguments.

The factors that can be used in the above table correspond to the properties of Sensor Device, SensorEntity, etc. defined in the integrated sensor data model. TimeRange is an argument required for the historical data aggregate function of the condition described later, where the first time value is the beginning of the range and the second time value is the end of the range. Referring to FIG. 8, the first value of the range of TimeRange may be omitted, in which case the first value means the first measurement time. Likewise, if you omit the end value of the range, the end value represents the current time.

For example, the expression "SensorEntity's DataType property value is Meter" is expressed as the following expression.

DataType = "Meter"

Job Statement

An operation command is an expression for expressing a condition for selecting a SensorDevice or a SensorEntity by combining various factors described above using AND and OR. The syntax for the operation command is shown in FIG. 9.

Using the expression above, you can combine the attribute conditions provided by the arguments to create the condition you want. "(", ")" Is to allow the user to set the priority of AND and OR operations.

For example, to represent all the thermometers (EntityType: 2) in the living room (LocationId: 1, BoundaryId: 1) or all the thermometers in the room (LocationId: 1, BoundaryId: 2) as follows.

(Location = 1 AND Boundary = 1 AND EntityType = 2) OR (Location = 1 AND Boundary = 2 AND EntityType = 2)

Condition

The condition is an expression for expressing the condition of the SensorData, and the syntax for the condition is shown in FIG. 10.

Referring to FIG. 10, [Comparator] may use ==,! =,>, <,> =, And <= as comparison operators. The strings that can precede the {SubCondition} such as LVAL, AVG, CNT, etc. represent aggregate functions, and are classified into functions that perform aggregation on the latest values and operations on historical data. All functions except CNT have two parameters. The first parameter is the entity type of sensor data to be aggregated, and the second parameter is {Statement} representing a condition to classify a SensorDevice or SensorEntity. That is, the first parameter of all functions except the CNT is an EntityType of the result value of the function, and thus can be called an EntityType of (TargetValue), which means a target setting value.

The aggregation function for the latest value used in the present specification is as follows.

Table 19 Function name etymology Explanation LVAL (device Id, entity type) Latest Value The latest value of the measured value of the sensor that satisfies the entity type and device Id AVG (entity type, statement) Average Average value of sensors that satisfy entity type and {statement} SUM (entity type, statement) Sum The sum of the values of the sensors that satisfy the entity type and {statement} MIN (entity type, statement) Minimum Minimum value of sensor that meets entity type and {statement} MAX (entity type, statement) Maximum Maximum value of sensors satisfying entity type and {statement} CNT (statement) Count the number of results satisfying {statement}

For example, if a particular temperature sensor (SensorDevice.Id = 1, SensorEntity.EntityType = 2) installed in the house (Location.Id = 3) has a value greater than 30 degrees and all temperature sensors installed in the main room (Boundary.Id = 4) If the condition for the case larger than 20 is written,

(LVAL (1, 2)> = 30) AND (MIN (2, (Location = 3 AND Boundary = 4))> = 20)

The historical data aggregation function represents the aggregation function for the measurement cumulative value and the time interval can be determined by the factor of {Statement}. The contents of the historical data aggregation function are as follows.

Table 20 Item Explanation HAVG (entity type, statement) Average value of TimeRange of sensors satisfying entity type and additional {statement} HSUM (entity type, statement) Total of TimeRange of sensors that satisfy entity type and additional {statement} HMIN (entity type, statement) Minimum value among TimeRange values of sensors satisfying entity type and additional {statement} MAX (entity type, statement) Maximum value of TimeRange of sensors satisfying entity type and additional {statement}

In the above table, TimeRange means the argument included in {statement}. If there is no TimeRange argument in the {statement}, it means that the entire historical data is aggregated.

For example, the condition for the case where the average temperature (EntityType = 2) from September 1, 2015 to October 1, 2015 of the house (Location.Id = 1) exceeds 30 degrees is as follows.

HAVG (2, (Location = 1 AND TimeRange = (2015-09-01: 2015-10-01)))

Custom events and conditions

User-defined events and conditions can be registered using the condition grammar using the integrated sensor data model and expressions described above, and the event agent of the sensor agent can generate an event when the condition is satisfied. to provide.

The conditional grammar is used because the conditional expression should be registered when the value of the sensor reaches the desired value.

An event means a message that is broadcasted to the local network when the condition written in the above-described grammar is satisfied, and is triggered when the condition set in the corresponding event is satisfied. The structure of the event is as follows:

Table 21 Item Detail Event Name The living room is hot and humid Event Description When living room temperature is above 30 degrees and humidity is above 60 Conditions LVAL (12, 2)> = 30 AND LVAL (11, 1)> = 60

The above table shows a data table for registering an event. When the condition is satisfied, only the event name is broadcasted to the local network. In addition, when a sensor agent connects to a remote device or cloud, the event is also sent to them.

For example, a user registers an event to turn on the air conditioner in the dehumidification mode when the temperature of the living room is 30 degrees or more and the humidity is 50% or more. Here, if the device Id of the temperature sensor of the living room is 12 and the device Id of the humidity sensor is 11, an event may be defined as follows.

Table 22 Item Detail Event Name The living room is hot and humid Event Description When the villa's temperature is above 30 degrees and the humidity is above 60 Conditions LVAL (12, 2)> = 30 AND LVAL (11, 1)> = 60

As a more complex example, the following is an example of setting an event when the average value of all the thermometers in the living room (BoundaryId: 3) of the VacationId: 1 is more than 30 degrees and the average value of all the hygrometers is more than 60%.

Table 23 Item Detail Event Name The living room is hot and humid Event Description When the villa's temperature is above 30 degrees and the humidity is above 60 Conditions AVG (2, Location = 1 AND Boundary = 3)> = 30 AND AVG (1, Location = 1 AND Boundary = 3)> = 60

Sensor agent Architecture

11 shows the structure of a sensor agent. The sensor agent is designed independently of the connectivity framework. The application of the sensor agent client does not need to know how the lower layer is implemented, and only needs to know the interface of the sensor agent, so the application is not affected by the change of the lower layer. Similarly, since the sensor agent manager completely separates the network connection part based on the sensor agent interface, the part is not affected even if it is changed to another communication framework.

12 is a sequence of API (application program interface) calls provided by a sensor agent interface of a sensor agent client application. The sensor agent client application 121 shows the operation of requesting the sensor agent proxy 122 for the sensor device list and forwarding the request to the sensor agent side sequentially so that the sensor agent client application receives the response.

FIG. 13 is a sequence of when a sensor agent requests sensor data directly from a sensor or when the sensor transmits sensor data to the sensor agent, and illustrates a procedure of storing sensor data received from a commercial sensor in a database of the sensor agent. .

14 illustrates a sequence in which a sensor agent informs a sensor agent client of its contents when data update of a sensor occurs. When the sensor data core 145 receives the sensor data of the sensor through AddEntity (), the database manager 144 stores the sensor data in the DB and informs the sensor agent client about the changed sensor data.

15 shows a sequence for generating an event. When the sensor data core 156 receives the sensor data of the sensor through AddEntity (), the database manager 155 informs the event manager 154 of the changed sensor data information, and the event manager determines whether the related condition is satisfied. When the test is satisfied, the information is broadcast to the local network.

Hereinafter, the configuration of the sensor agent client and the sensor agent will be described.

Sensor Agent Proxy

A module that inherits the sensor agent interface and is a module that acts as a local representative of a remote sensor agent. That is, the sensor agent proxy is implemented to have the same API as the sensor agent, and since the implementation for the remote call is handled internally by the proxy, the sensor agent client application can be used as if the sensor agent is directly called through the sensor agent proxy. . The sensor agent proxy forwards the request to the sensor agent stub, which in turn receives it from the sensor agent stub and forwards it to the sensor agent client application.

Sensor agent Stub ( SensorAgent  Stub)

When the sensor agent client application calls the sensor agent proxy's API, the sensor agent proxy forwards the request to the remote sensor agent stub. The sensor agent stub serves to directly call the sensor agent's API corresponding to the request received from the sensor agent proxy to the sensor agent and deliver the result to the sensor agent proxy. That is, it can be viewed as an agent for a sensor agent client application.

Sensor agent interface ( SensorAgent  Interface)

It is an interface that separates the functional unit and the connection unit of the sensor agent and the API of the sensor agent.

sensor device  Sensor Device Interface

Interface provided for inquiry / management of sensor device in sensor agent.

Table 24 Method name Remarks GetSensorDeviceList ( Statement ) Return the list of registered sensor device information.Search condition can be set by using Statement expression. GetSensorDeviceInformationList ( Statement ) Return detailed information of sensor device. Search condition can be set using Statement expression. ScanSensorDevice () Search for new sensor devices RegisterSensorDevice () Register a new sensor device UnregisterSensorDevice () Delete registered sensor device

Sensor Data Interface

This is an interface provided by the sensor agent to inquire the measurement values of the sensor. The latest measurement value and the cumulative measurement value can be inquired through the corresponding method.

Table 25 Method name Remarks GetSensorDataList ( Statement ) Return the list of measured values for the entities of the sensor device.Search condition can be set using Statement expression. GetSensorHistoricalDataListByEntityId (EntityId) Returns historical data of the entity's measurements

Sensor Event Interface

The interface provided to inquire / manage events set by users in the sensor agent is as follows.

Table 26 Method name Remarks GetRegisterdEventList () Return list of registered events GetRegisteredConditionList (EventId) Returns a list of occurrence conditions for registered events RegisterEvent (EventName, Description, Condition) Event and event occurrence conditions can be registered using Condition expressions. UnregisterEvent (EventId) Delete registered event

sensor device  Sensor Device Signal

Signal sent to the sensor agent client when the state of the sensor device changes in the sensor agent.

Table 27 Signal name Remarks SensorDeviceDetected Signal generated when a new sensor device is found SensorDeviceAdded Signal generated when a new sensor device is registered SensorDeviceRemoved Signal generated when the sensor device is deleted

Sensor Data Signal

This is a signal sent to the sensor agent client when the value of the sensor entity registered in the sensor agent is changed.

Table 28 Signal name Remarks SensorDataChanged Signal generated when sensor reading is updated

Sensor Agent Manager ( SensorAgent  Manager)

The sensor agent manager inherits the sensor agent interface to provide the function of the sensor agent. As a main feature,

-Save / manage measurement information received from sensor agent receiver in DB

-Register / manage user's events and conditions

-Whenever the sensor measurement information changes, the event is triggered by checking whether the condition of the user defined event is satisfied.

The sensor agent manager provides these functions to higher layers through the sensor agent interface described later.

The sensor agent manager consists of three modules. One is a database manager, which manages the flow of sensor data. Second, as an event manager, it manages registration of events, condition checking, and occurrence. Finally, the database serves to physically store the measurement data.

Database Manager

The database manager is a module that handles requests for sensor data and handles sensor device interface, sensor data interface, and sensor data signal among sensor agent interfaces, which are APIs provided to upper layers. The database manager is responsible for processing sensor data asynchronously received from the sensor agent receiver. That is, the database manager manages the flow of sensor data. In addition, the database manager also transmits an update signal to the sensor agent client when the sensor data is changed.

Event Manager

The event manager plays a role of registering / managing an event through the sensor agent interface and triggering a corresponding event by checking whether an event condition is satisfied when updating sensor data. The event manager is responsible for processing the sensor event interface among the sensor agent interfaces, which are APIs provided to the upper layer.

Sensor Database

The sensor data data is a database designed based on the integrated sensor data model described above. The sensor data data includes a table for storing information of the sensor device, a table for storing sensor data, and an installation location and a custom group, which are additional information about the sensor. It is divided into tables. 16 is a table design diagram of a sensor database.

Sensor device table

The sensor device table is a table defined for storing information that can be brought from the sensor device. That is, the sensor device table stores the information of the sensor device of the integrated sensor data model described above.

Sensor data table

The sensor data table is a table for storing data measured by the sensor. The sensor entity information of the sensor measurement data can be known through the SensorValuePropertyId. The value of the measured data is divided into an exponent part and an exponent part, respectively, and time information means a time at which the corresponding value is measured. That is, the sensor data table stores information of sensor data of the integrated sensor data model described above.

Sensor entity table

The sensor entity table is a table that stores information of sensor entities of the integrated sensor data model described above. The sensor data has a SensorValuePropertyId, so it can be known what value the corresponding sensor data represents.

Sensor Data Receiver

The sensor data receiver collects the device information of the physical device and the sensor data information of the device through various protocol stacks and processes them into an integrated sensor data model. It updates and sends a signal to inform it.

Sensor Data Receiver Architecture

The sensor data receiver may be classified into a data receiver core module, a protocol adapter module, and an adapter interface as shown in FIG. 17.

The data receiver core module provides an interface to the outside of the sensor data receiver so that the protocol adapter modules can be normally operated, and requests data through the protocol adapter module. In addition, the data receiver core module also receives and processes the device / data information from the protocol adapter module when the device state / data is changed.

The adapter interface is an interface commonly used by protocol adapter modules, and provides an interface through which the data receiver core module operates the protocol stacks normally and requests data from the protocol stack.

When the protocol adapter module receives notification of device status / data change from the protocol stack, the protocol adapter module transmits the relevant information and device / data information to the data receiver core module, and the device ID manager, device id, entity type, etc. Only store / manage information.

The protocol stack provides an interface for communicating with each physical device and manages device / data information of the physical device. The protocol stack is responsible for requesting data from the physical device through an interface provided by the protocol stack, receiving the information, and providing information to the protocol adapter module. In addition, if a listener is registered in the protocol stack that can receive notification of device status / data change of the protocol, information can be received when the notification occurs.

18 briefly illustrates an operation flow for processing device information of a sensor data receiver. First, the sensor data receiver initializes the protocol adapter module and the protocol stack and starts the operation through the adapter manager (S1801). When the protocol adapter module is initialized, the stack manager registers a listener for receiving notification of device state change in the protocol stack through the stack notification manager (S1801-a). The adapter manager may start the device search by the request of the sensor agent client (S1802), and the protocol stack may add a newly discovered device (S1803). When the device is added, a notification that the device has been added through the registered listener comes up (S1804). When the device addition notification comes up, the stack notification manager requests an event transmission for notifying the sensor agent client that the device has been added through the signal transmitter (S1804-a). The stack notification manager transmits the device information to the device / data updater to convert the device information into the integrated sensor data model (S1805), and requests the device / data updater to add the converted device information (S1806). In addition, the stack notification manager stores later necessary information such as Device Id and Entity Id, which are issued upon conversion to the integrated sensor data model (S1804-b).

19 briefly illustrates an operation flow for processing data information of a sensor data receiver. The sensor data receiver initializes and starts operation of the protocol adapter module and the protocol stack through the adapter manager (S1901). When the protocol adapter module is initialized, the stack manager registers a listener for receiving a change notification of data in the protocol stack through the stack notification manager (S1901-a). When the protocol adapter module is started, the adapter manager may start a data requester scheduler to periodically request data from the device through the data requestor (S1902). By this request or even if there is no request, if the device transmits the changed data by itself (S1903-b), a notification that the data has been changed through a listener registered in the protocol stack comes up (S1903). When the data change notification comes up, it requests the event transmission to inform the sensor agent client that the data has been changed through the signal transmitter (S1903-a). The device / data updater converts the data into the integrated sensor data model (S1904), and the device / data updater requests the sensor agent manager to add the data (S1905).

Data Receiver Core Module

The data receiver core module consists of adapter manager, data requestor scheduler, device / data updater and signal transmitter class as shown in the table below.

Table 29 Class detailed description Adapter Manager Create, initialize, start, shut down, and destroy protocol adapters. Request protocol discovery / disablement via protocol adapters, and enable / disable operation of the desired protocol adapter. Data Requester Scheduler Ask the protocol adapter to get data periodically. Device / Data Updater Request to update information from sensor adapter / data change from protocol adapter. Signal Sender Requests to send information about sensor device / data change from the protocol adapter and send a signal to the sensor agent client.

The adapter manager class provides an API to request creation, initialization, start, and termination of a protocol adapter module, and destroys all protocol adapter classes when destroyed. In addition, the adapter manager class provides APIs for requesting device execution and interruption through the stack manager in the protocol adapter module and for enabling / disabling operation of a desired protocol adapter module.

The API provided by the adapter manager class is shown in the table below. The transfer parameter "Protocol" shown in the table below is a value generated by bitwise operation of the protocol values in Table 3. For example, if you want to use Z-Wave and ZigBee, the protocol values are 0x01 (Z-Wave) & 0x02 (ZigBee) = 0x03.

Table 30 API detailed description InitializeAdpater (Protocol) Initialize desired protocol adapters StartAdapter () Initialize protocol adapters start working StopAdapter () Initialized protocol adapters stopped working StartScanDevice (Protocol) Request to start device discovery of desired protocols StopScanDevice (Protocol) Request to stop device discovery of desired protocols EnableAdapter (Protocol) Adapter activation request for desired protocols DisableAdapter (Protocol) Request adapter deactivation of desired protocols

The data requestor scheduler class is created, started, and terminated by the adapter manager, and provides an API that allows the data requestor in the protocol adapter module to request data periodically. The APIs provided by the data requestor scheduler class are shown in the table below.

Table 31 API detailed description SetSchedulerPeroid (Second) Scheduler operation cycle setting StartScheduler () Scheduler starts working StopScheduler () Scheduler crashes

The device / data updater class provides APIs that can receive information on device status / data change from the stack notification manager in the protocol adapter module, convert them to the integrated sensor data model described above, and request updates to DB, cloud, etc. The APIs provided in the device / data updater classes are shown in the table below.

Table 32 API detailed description AddSensorDevice (SensorDeviceInfo) Sensor Device Add Request / Device Id Return RemoveSensorDevice (DeviceId) Sensor Device Removal Request AddSensorEntity (DeviceId, SensorEntityInfo) Request to add Sensor Entity to Device of Device Id / Return Entity Id AddSensorData (EntityId, SensorDataInfo) Request to add Sensor Data to Entity in Entity Id

The signal transmitter class provides an API that can receive information about device state / data change from a stack notification manager in a protocol adapter module and request to transmit a signal to a sensor agent client. The APIs provided by the signal transmitter class are shown in the table below.

Table 33 API detailed description SendDeviceAddedSignal (DeviceId) Request to send DeviceAdded Signal of Device Id SendDeviceRemovedSignal (DeviceId) Request to send DeviceRemoved Signal of Device Id SendDeviceDeadSignal (DeviceId) Request DeviceDead Signal of Device Id SendDataChangedSignal (EntityId) Request to send Entity data change signal of Entity ID

Adapter Interface

Adapter interface is used to provide the same interface regardless of protocol type. It consists of stack manager and data requestor class as shown in the table below.

Table 34 Class detailed description Stack Manager Initialize, start, and exit the stack to communicate with the physical device through the protocol stack. Ask the protocol stack to discover / stop devices. Data Requester Data Requestor Requests data from a physical device through the protocol stack at periodic requests from the scheduler.

The stack manager class allows protocol adapter modules to communicate with physical devices through the protocol stack. To do this, an API is provided for the adapter manager in the data receiver core module to request initialization, start, and termination of the protocol stack. It also provides APIs to perform and stop device discovery through the protocol stack and to enable / disable operation of the protocol adapter module. Upon initialization of the protocol stack, a listener may be registered that may receive information on device state / data change from the protocol stack through the stack notification manager. The APIs provided in the stack manager class are shown in the table below.

Table 35 API detailed description InitializeStack () Initialization of the Protocol Stack StartStack () t Protocol stack starts working StopStack () Protocol Stack Down StartScanDevice () Initiate device discovery of protocols StopScanDevice () Stop device discovery of protocol EnableProtocolAdapter () Enable protocol adapter DisableProtocolAdapter () Deactivate protocol adapter

The data requestor class provides an API that can request data from physical devices through a protocol stack according to a periodic request of a data requestor scheduler in a data receiver core module. As such, for the data request, the data requestor class can retrieve information about the physical device from the device information manager. The APIs provided in the data requestor class are shown in the table below.

Table 36 API detailed description RequestSensorData () Request sensor data from all devices

Protocol adapter module

The protocol adapter module consists of device information manager and stack notification manager classes as shown in the table below and has different interfaces depending on the protocol type. Therefore, the specification briefly defines only APIs and listeners that can be used with the same name.

Table 37 Class detailed description Stack Notification Manager It receives information on device status / data change from the protocol stack and processes it and sends it to the device manager and data receiver core. Device Information Manager Manages the device status of the physical device based on the contents received from the stack notification manager.

The stack notification manager class provides an API for registering listeners that can receive information about device state / data change from the protocol stack. The stack notification manager class receives and processes this information through registered listeners. First, the device information manager can transmit device status related information to manage device information, and request device / data updater in the data receiver core module to process and deliver device status / data related information to update DB, cloud, etc. do. In addition, the device status / data change information is also transmitted to the signal transmitter in the data receiver core module to transmit the corresponding signal to the sensor agent client. The APIs and listeners provided in the stack notification manager class are shown in the table below.

Table 38 name detailed description RegisterStackNotificaionListener () Register listeners to receive stack notifications DeviceStatusNotificationListener Listener for notification of device state change DataChangedNotificationListener Listener for receiving notification of data changes

The device information manager class receives and stores information that needs to be managed, such as Device Id, Entity Id, and Entity Type, from the stack notification manager, and provides an API that can be provided when information is requested from the data requestor and the stack notification manager. It also provides an API that converts the sensor data type of the protocol to the entity type of the sensor agent. The APIs provided in the device information manager class are shown in the table below.

Table 39 API detailed description AddDeviceInformation (Information) Add device related information RemoveDeviceInformation (Id) Remove device related information GetDeviceInformationList () Return a complete list of device related information GetDeviceId () Return Device Id of Physical Device GetEntityId () Return Entity Id of Physical Device Data ConvertToEntityType () Convert sensor data type of physical device to Entity Id and return

Sensor Agent Device Structure Diagram

Hereinafter, a description will be given of how each module of the aforementioned sensor agent architecture is connected and operated with hardware. 20 is a structural diagram of a gateway, which illustrates how software modules of a sensor agent are connected to and operate with hardware of the gateway.

The sensor agent separates hardware dependent parts through the sensor agent data adapter (that is, the protocol adapter) and implements and adds a data adapter for the hardware to be connected, so that the sensor agent and the corresponding hardware can be connected. Referring to FIG. 20, the Z-Wave Adapter, the ZigBee Adapter, and the BLE Adapters are connected to a corresponding controller, receive data, and transmit data to a sensor agent. Wi-Fi is indirectly connected through a communication framework (AllJoyn).

21 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 radio frequency (RF) units 13 and 23 capable of transmitting or receiving radio signals carrying information and / or data, signals, messages, and the like, and in a wireless communication system. The device is operatively connected to components such as the memory 12 and 22 storing the communication related information, the RF units 13 and 23 and the memory 12 and 22, and controls the components. And a processor 11, 21 configured to control the memory 12, 22 and / or the RF units 13, 23, respectively, to perform at least one of the embodiments of the invention 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. 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. Meanwhile, when implementing the present invention using firmware or software, the 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 RF unit 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 RF unit 13 may include an oscillator for frequency upconversion. The RF unit 13 may include Nt transmit antennas (Nt is a positive integer greater than or equal to 1).

The signal processing of the receiver 20 is the reverse of the signal processing of the transmitter 10. Under the control of the processor 21, the RF unit 23 of the receiving device 20 receives a radio signal transmitted by the transmitting device 10. The RF unit 23 may include Nr receive antennas, and the RF unit 23 frequency down-converts each of the signals received through the receive antennas to restore the baseband signal. The RF unit 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 RF units 13, 23 have one or more antennas. The antenna transmits a signal processed by the RF units 13 and 23 to the outside under the control of the processors 11 and 21, or receives a radio signal from the outside to receive the RF unit 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. Regardless of whether it is a composite channel from a plurality of physical antenna elements, 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. In the case of an RF unit supporting a multi-input multi-output (MIMO) function for transmitting and receiving data using a plurality of antennas, two or more antennas may be connected.

The transmitting device 10 and the receiving device 20 shown in FIG. 21 may be modules, devices or subjects of specific operations described in the above-described embodiments of the present invention. For example, if the transmitting device 10 corresponds to a sensor agent client, the receiving device 20 may be a sensor agent; If the transmitting device 10 is a sensor agent, the receiving device 20 may be a sensor agent client or a sensor device. As such, a sensor agent, a sensor agent client (or application), a sensor device, or a specific configuration included therein (eg, a sensor agent manager of a sensor agent, a sensor agent receiver, and each of them, according to one embodiment of the present invention) And other configurations) may be understood as a single device, and may also be expressed as a specific device in the claims. Accordingly, the transmitter and / or the receiver may perform at least one or a combination of two or more embodiments of the present invention described above.

The detailed description of the preferred embodiments of the invention disclosed as described above is provided to enable those skilled in the art to implement and practice the invention. While the above has been described with reference to preferred embodiments of the present invention, those skilled in the art will understand that various modifications and changes can be made to the present invention as set forth in the claims below. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

The present invention can be used in a terminal, base station, server or other equipment of a wireless mobile communication system.

Claims (18)

A method for processing sensor data in accordance with an integrated sensor data model, Collecting sensor data according to a plurality of protocols; Converting the collected sensor data into sensor data according to the integrated sensor data model; And Storing the converted sensor data, The converted sensor data includes a sensor device data set, a sensor entity data set, and a sensor data set, The sensor device data set includes information related to a physical sensor device, The sensor entity data set includes information related to physical indicators measured by the physical sensor device, And the sensor data set includes information about the measured values of the physical indicator and the time at which the measured values were measured. The method of claim 1, wherein the sensor device data set includes a list of physical indicators measured by the physical sensor device and location information on which the physical sensor device is installed. 3. The method of claim 2, wherein the location information in which the physical sensor device is installed comprises at least three types of hierarchical location information. The method of claim 1, wherein the sensor entity data set includes information indicating one of multiple levels, binary or meter data types. The method of claim 1, wherein the sensor entity data set includes information about an entity type indicating the physical indicator. The integrated sensor data processing of claim 1, further comprising converting and storing the changed sensor data into sensor data according to the integrated sensor data model according to a change notification of the sensor data of the plurality of protocols. Way. 7. The method of claim 6, wherein the modified sensor data is received by a request to each physical sensor device according to the plurality of protocols. 7. The method of claim 6, wherein the modified sensor data is received without a request to each physical sensor device according to the plurality of protocols. The method of claim 1, further comprising: if a condition of a registered event is satisfied for at least some of the sensor data of the plurality of protocols, broadcasting a message corresponding to the event; And the condition relates to at least one of hierarchical position information of the sensor device data set and an entity type indicating the physical indicator included in the sensor entity data set. An apparatus configured to process sensor data according to an integrated sensor data model, Radio frequency (RF) units; Memory; And A processor configured to control the RF unit and the memory, The processor is configured to collect sensor data according to a plurality of protocols, convert the collected sensor data into sensor data according to the integrated sensor data model, and store the converted sensor data in the memory, The converted sensor data includes a sensor device data set, a sensor entity data set, and a sensor data set, The sensor device data set includes information related to a physical sensor device, The sensor entity data set includes information related to physical indicators measured by the physical sensor device, The sensor data set comprises information about the measured values of the physical indicator and the time at which the measured values were measured. The apparatus of claim 10, wherein the sensor device data set includes a list of physical indicators measured by the physical sensor device and location information at which the physical sensor device is installed. 12. The apparatus of claim 11, wherein the location information in which the physical sensor device is installed comprises at least three types of hierarchical location information. 11. The terminal of claim 10, wherein the sensor entity data set includes information indicating one of a multi-level, binary or meter data type. The terminal of claim 10, wherein the sensor entity data set includes information on an entity type indicating the physical indicator. The terminal of claim 10, wherein the processor is configured to convert the changed sensor data into sensor data according to the integrated sensor data model and store the changed sensor data according to a change notification of the sensor data of the plurality of protocols. The terminal of claim 15, wherein the changed sensor data is received by a request to each physical sensor device according to the plurality of protocols. The terminal of claim 15, wherein the changed sensor data is received without a request to each physical sensor device according to the plurality of protocols. The method of claim 10, wherein the processor is configured to broadcast a message corresponding to the event when a condition of a registered event is satisfied for at least some of the sensor data of the plurality of protocols. And the condition relates to at least one of hierarchical position information of the sensor device data set and an entity type indicating the physical indicator included in the sensor entity data set.

Images