KR20140113817A - M2M Device Management Method and M2M Service Platform - Google Patents

Abstract

An M2M device management method according to an embodiment of the present invention is configured to comprise the steps in which an M2M service platform sends a request message for requesting the status information about a sub-device, to which data is not normally transferred among sub-devices of an M2M gateway, to the M2M gateway; and receiving a file of the state information about the sub-device to which the data is not normally transferred for each M2M gateway.

Description

M2M DEVICE MANAGEMENT METHOD AND M2M SERVICE PLATFORM BACKGROUND OF THE INVENTION [0001]

The present invention relates to an M2M device management method and an M2M service platform for the same, and more particularly, to an M2M device management method capable of effectively solving a resource state mismatch problem between an M2M device and an M2M service platform in an M2M network environment and an M2M service platform will be.

Machine-to-machine (M2M) refers to communication for providing object information to a person or an intelligent device by using a broadcast communication network, or for controlling a state of an object by a person or an intelligent device. M2M is also called the Internet of Things (IOT) and Object to Object Intelligent Network (O2N).

If M2M communication in the past and the latter half of the 1990s meant one-to-one or many-to-many communication for simple point-to-point (P2P) connection, then ultimately the aim of M2M communication is to introduce location awareness, situational awareness, , Etc., aiming at the quality and stability of the improved M2M communication service by automatically operating without human control or with human intervention minimally.

M2M network communication can be utilized as an essential infrastructure to solve social problems, prevent disasters and disasters, and save energy through conventional u-City, u-Health, u-transportation, u-environment projects. Currently, a wide variety of services such as remote meter reading, building and facility management, vending machine management, indoor lighting control service, traffic information and vehicle control, emergency dispatch, fire alarm, security alarm device, vending machine, telematics, . In recent years, it has been applied to medical apparatuses such as a pulse system and an electrocardiogram system, and has been actively applied in the field of e-health including telemedicine services.

In general, M2M communication differs from existing human-centered human-to-human communication (H2H) in various features by communication between objects. From these differences, technically necessary technologies can be changed, and the required characteristics may be slightly different depending on the field of application using M2M communication. Currently, research and development for the standardization of successful M2M communication is continuing in the standardization groups of the world including the European Telecommunication Standard Institute (ETSI). FIG. 1 is a block diagram of an ETSI TS 102 (Technical Specification) 102 690 [Machine-to-Machine Communications (M2M); Functional architecture] for the M2M service, including the device and gateway domains and network domains as defined in Chapter 4. Hereinafter, the contents of the standardization work performed in ETSI including the ETSI TS (Technical Specification) 102 690 will be referred to as " ETSI standard ".

Referring to FIG. 1, the M2M devices 10 and 10 'are terminals for communicating with no human input or intervention, or minimizing the input and interruption thereof. Type of device.

In the ETSI standard, when the M2M device 10 'directly connects to the access network 40, the M2M service capability 11 of the M2M device 10' It is prescribed to execute the device application (DA, 12) which is an application (M2M Application). In addition, when the M2M device 10 accesses the access network 40 through the M2M gateway 30, it is prescribed to use the M2M service capability 31 of the M2M gateway 30 .

The M2M area network (20) provides a connection between the M2M device (10) and the M2M gateway (30). Examples of the M2M local area network 20 include a Personal Area Network (PAN) or a Wireless Local Area Network (LAN), such as IEEE 802.15.x, Zigbee, Bluetooth, IETF ROLL, ISA100.11a, Area Network (hereinafter also referred to as " WLAN "), PLC, M-BUS, Wireless M-BSU, and KNX.

The M2M gateway 30 is a gateway for executing a gateway application (GA) 32 which is an M2M application of the M2M gateway 30 by using the M2M service capability 31. The M2M gateway 10 is connected to the access network 40, As a proxy.

The access network 40 is a network that allows the M2M devices 10 'through M2M gateways 30 to communicate with the core network 50. Examples of the access network 40 include xDSL, HFC, FTTH, PLC, Satellite network, GERAN, UTRAN, eUTRAN, Wireless LAN, WiMAX (WiBro) and the like.

The core network 50 is a network that provides IP connectivity, access network control and network service control functions, interconnection with other networks, roaming functions, and the like. Examples of the core network 50 include 3GPP CN, ETSI TISPAN CN, 3GPP2 CN, and IMS.

The M2M service capability 60 of the network domain provides functions that can be shared by different applications and provides an environment for accessing other service capabilities through an open interface. Using these M2M service capabilities, it is possible to develop and deploy optimal applications without considering the characteristics of the lower network layer.

A network application (NA) 70, which is an M2M application in a network domain, runs M2M service logic and uses M2M service capabilities through an open interface to provide in the M2M system.

According to the ETSI standard, a layer representing M2M service capabilities in a network domain is referred to as a network service capability layer (NSCL) and a layer representing M2M service capabilities of the gateway A layer representing a Gateway Service Capability Layer (GSCL) and an M2M service capability of an M2M device is referred to as a Device Service Capability Layer (DSCL) ). The NSCL, GSCL and DSCL are collectively referred to as a service capability layer (SCL). Herein, NSCL means a platform that is individually constructed for each service by a service provider providing each M2M service, and is hereinafter also referred to as an " M2M service platform ".

2 schematically shows an overall configuration of an M2M system according to the M2M architecture shown in Fig.

2, an entire M2M system includes a plurality of M2M devices 101-1, ..., 101-n, 102-1, ..., 102-m, And the M2M service platform 301 is connected to the M2M application service and / or the device management system 401. The M2M service platform 301 is connected to the M2M service platform 301 (or NSCL) Each of the plurality of M2M gateways 201, 202, ... connected to the M2M service platform 301 includes a plurality of M2M devices 101-1, ..., 101-n; 102-m; ....).

In the case of the M2M system as described above, the devices managed by the M2M application and / or the device management system 401 and the devices connected to the M2M gateway can provide reliable information because the status information of the resources coincide with each other, Therefore, M2M service and device management provided by M2M service platform becomes possible. For example, in the case of a wireless M2M device, when the function or status change is detected, it is notified to the M2M gateway, which must be delivered to the M2M service platform to be reflected in the M2M application and the M2M device management system.

However, in this situation, especially in a M2M network environment where a large number of M2M devices are operated, there is a possibility that an event message of the M2M device is lost, and since a large amount of data must be processed in the M2M gateway or M2M service platform, There is a possibility. This message and / or data loss is likely to cause resource inconsistencies between M2M applications and / or M2M devices between M2M device management systems and M2M devices. It is not easy to grasp the status of the M2M device in real time in the network environment as described above in real time by the M2M application service operator or the network operator.

In the conventional M2M application service or M2M device management system in the above-described situation, in order to solve the inconsistency of the resource status, the user explicitly uses the status information of the M2M device using the Simple Network Management Protocol (SNMP) And polling the status information to all M2M devices periodically to solve the problem of resource inconsistency.

However, in the case of inquiring frequent status information in an M2M network environment where a large number of M2M devices exist, in particular, in the case of a wireless M2M device, since the battery life is increased, the lifetime of the device is reduced and an excessive operation maintenance message is generated. There is a possibility that it is difficult to solve the problem of the mismatch of the resource state because the possibility of the M2M data processing is lost in the gateway and the M2M service platform.

Therefore, in order to solve the problem of discrepancy of resource status between M2M device and M2M service platform, M2M application service and M2M device management system due to battery problem of wireless M2M device, loss of M2M data or operation message in wireless M2M network environment, It is necessary to make efficient measures.

SUMMARY OF THE INVENTION The present invention is conceived to solve the above-described conventional problems, and it is an object of the present invention to efficiently solve the problem of discrepancy in resource status between a device and a server (M2M service platform or M2M application and / or device management system) in an M2M network environment For that purpose.

According to another aspect of the present invention, there is provided a method of managing an M2M device, the M2M service platform requesting status information on a child device of the M2M gateway, Transmitting a request message; And receiving a status information file for the lower-level device to which the data is not normally transmitted for each of the M2M gateways.

The method may further include classifying a class for the lower device according to a data generation period of the lower device and generating a list of devices classified into the same class.

The method may further include updating the list of devices by class based on a measurement time of data transmitted from the lower device.

Wherein the step of updating the list of device-by-grade includes: when the time interval between the measurement time of the data transmitted from the lower-level device and the measurement time of the data stored recently with respect to the lower-level device exceeds a predetermined threshold value, And generating a rating.

The method may further include monitoring whether or not data is normally received from a lower device included in the device list.

Wherein the monitoring step determines that data is not normally received from the slave device when the time interval between the current time of searching for the latest measurement data for the slave device and the measurement time of the recently stored data exceeds a predetermined threshold value .

The method may further include generating a category-specific abnormal device list including information on a child device that is determined to be not normally received among the child devices included in the category-specific device list.

Here, the list of the abnormal devices according to the grade may be included in the request message.

In addition, the status information file may include status information on the child device included in the abnormal device list of the class.

The M2M device management method may further include a step of parsing the status information file to update the resource status of the lower device.

According to another aspect of the present invention, there is provided an M2M service platform, including: a device classification level management unit for generating a device list for each lower level device for each data generation period of a lower device of the M2M gateway; And a measurement data monitoring unit for monitoring whether data is normally received from the slave device.

In addition, the M2M service platform may further include an event request processing unit for generating a list of unequal-rank devices including information on lower-level devices, which are determined to not normally receive data among the lower-level devices included in the list of the classified devices.

Here, the event request processing unit may request the M2M gateway to transmit a status information file for a child device included in the abnormal device list of the class.

And a file processor for parsing the status information file transmitted from the M2M gateway and extracting status information on the lower-level devices included in the abnormal status device list.

Here, the device class management management unit may be configured to classify a temporary class for the lower-level device when the measurement time of the data transmitted from the lower-level device and the time interval between the measurement time of the recently stored data for the lower-level device exceed a predetermined threshold value Can be generated.

According to another aspect of the present invention, there is provided an M2M gateway comprising: an event request processing unit for requesting status information of a lower device as a lower device included in a rank-based abnormal device list transmitted from an M2M service platform; And a file generation unit for generating a status information file for the lower-level devices included in the abnormal-device-by-rank-list.

According to the present invention, a device classification level is managed based on a period in which data is measured from an M2M device in a server (M2M service platform, M2M application and / or device management system) in an M2M network environment, The M2M device requests the device status information to the corresponding gateway belonging to the lower device and matches the device resource status managed by the server on the basis of the obtained information, And the problem of resource state mismatch between the server and the server can be solved, so that the M2M network can be efficiently managed.

In addition, in the case of an M2M device (in particular, a wireless M2M device) using a battery, the message exchange for status management can be minimized and the lifetime of the M2M device can be increased.

Figure 1 illustrates an architecture for an M2M service that includes device and gateway domains and network domains.
2 schematically shows an overall configuration of an M2M system according to the M2M architecture shown in Fig.
3 is a flowchart schematically illustrating a method of managing M2M device status information according to an exemplary embodiment of the present invention.
4A is a diagram illustrating a management object structure and a management resource for managing a resource status of a device in an M2M service platform according to an exemplary embodiment of the present invention.
4B is a diagram illustrating an example of a resource tree according to an embodiment of the present invention.
FIG. 5A is a diagram schematically illustrating a configuration of an M2M service platform according to an embodiment of the present invention.
FIG. 5B is a view schematically showing a configuration of a gateway according to an embodiment of the present invention.
FIG. 6 is a flowchart illustrating a process of classifying a class of an M2M device according to a measurement data cycle by an M2M service platform according to a preferred embodiment of the present invention.
7 is a flowchart illustrating a procedure for monitoring whether measurement data is periodically received from an M2M device in an M2M service platform according to an exemplary embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The present invention will now be described in more detail with reference to the accompanying drawings. The present invention is capable of various modifications and various forms, and specific embodiments are illustrated in the drawings and described in detail in the text. It should be understood, however, that the invention is not intended to be limited to the particular forms disclosed, but includes all modifications, equivalents, and alternatives falling within the spirit and scope of the invention.

Like reference numerals are used for like elements in describing each drawing. Here, the terms first, second, etc. may be used to describe various components, but the components should not be limited by the terms. The terms are used only for the purpose of distinguishing one component from another. For example, without departing from the scope of the present invention, the first component may be referred to as a second component, and similarly, the second component may also be referred to as a first component. The singular expressions include plural expressions unless the context clearly dictates otherwise.

In this application, the terms "comprises", "having", and the like are used to specify that a feature, a number, a step, an operation, an element, a part or a combination thereof is described in the specification, But do not preclude the presence or addition of one or more other features, integers, steps, operations, components, parts, or combinations thereof.

Also, unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Terms such as those defined in commonly used dictionaries are to be interpreted as having a meaning consistent with the contextual meaning of the related art and are to be interpreted as either ideal or overly formal in the sense of the present application Do not.

3 is a flowchart schematically illustrating a method of managing M2M device status information according to an exemplary embodiment of the present invention.

First, the M2M service platform 301 manages the device classification level for M2M devices based on the reporting or measurement period of M2M data received from a large number of various M2M devices. In this case, the M2M service platform 301 generates a device list for each M2M gateway in order to manage the device classification level for the lower devices belonging to the gateway for each M2M gateway, as described later.

In step S31, the M2M service platform 301 monitors whether data is normally reported among the M2M devices included in the classified device list, and when it is determined that there is a lower device (s) for which data is not normally reported, And the like.

Then, in step S32, the M2M gateway 200, to which the lower device (s) included in the abnormal device list belonging to the class belongs, transmits a request message requesting status information on the lower device (s) included in the abnormal device list . The request message includes the list of the abnormal devices according to the rank.

In step S33 and step S34, the M2M gateway 200 having received the request message requests or inquires status information about the lower device (s) 100 included in the abnormal device list by class, and transmits a response to the request or inquiry The M2M device 100 transmits its status information to the M2M gateway 200. [

In step S35, the M2M gateway 200 creates state information in response to the response from the lower device (s) 100 included in the category-specific abnormal device list in a file format. Thereafter, in step S36, the M2M service platform 301 transmits the status And transmits the information file in response to the request message. The status information file transmitted in step S36 may be configured as follows, for example:

Filename: upload_gscl1_date

D1: Op: nor; battery: high; temp_sensor: nor; temp: 10; hum_sensor: nor; hum: 50;

D2; Op: abnor; battery: low; motion_sensor: fault; motion: -;

... .

Here, each of the devices D1, D2 ... indicates the lower-level devices included in the classified abnormal device list, gscl1 is the identification information of the M2M gateway to which the lower-level device belongs, and the operation status of each of the devices D1, D2, An identifier (Op) and status information (normal: abnorner), an identifier (battery) indicating the status of the battery, and status information (high and low depending on the remaining battery level) (Temperature sensor: temp_sensor, motion sensor: motio_sensor, humidity sensor: hum_sensor), and the sensed value.

Thereafter, in step S37, the M2M service platform 301, which has received the status information file of the class-specific abnormal devices from each M2M gateway, parses and analyzes the status information file, and based on the analyzed contents, To the M2M application and / or the device management system so that the network operator can recognize the change.

4A is a diagram illustrating a management object structure and a management resource for managing a resource status of a device in an M2M service platform according to an exemplary embodiment of the present invention.

As defined in the current ETSI standards, it is defined how M2M applications (DA, GA or NA) and M2M SCLs communicate with each other by applying a RESTful structure format to the M2M network. Representational State Transfer (REST) refers to the so-called architectural style proposed by Roy T. Fielding, a method used primarily for accessing data on the Web. These RESTful Web services have properties that can be accessed only by the HTTP protocol regardless of the server / client type by knowing the resource URI. The ETSI standard specifies a method for delivering representation information of uniquely defined resources using a RESTful structure. In addition, the ETSI standard defines a specification of resources located in the SCL. The control and data for providing the SCL function are constituted and represented as resources of a tree structure.

The managed objects shown here are configured to comply with the ETSI standard as described above wherein the oval and square shapes represent managed object nodes and < x > indicated in the graphic form has a unique name Is granted.

The sclBase resource is the top-level root resource that represents the hosting service capability layer (SCL), and the scls resource is a collection resource that represents a collection of <scl> resources. Here, the hosting SCL indicates an SCL in which a resource (master / original resource) addressed according to the ETSI standard should reside, and the < scl > resource is a resource indicating identification information of a remote SCL registered and interacting with the hosting SCL.

A subscriptions resource is a collection resource representing a set of <subscription> resources, and a <subscription> resource is a resource for storing subscription information for receiving a notification for a specific resource.

The mgmtObjs resource is a collection resource that represents a set of <mgmtObj> resources, and the <mgmtObj> resource is a resource that stores information for managing remote M2M objects and is created and managed only on the server (ie, M2M service platform or NSCL). The <mgmtCmd> resource is a resource for processing management commands of a resource other than a RESTful structure. This resource is also generated and managed only in the server.

The notificationChannels resource is a collection resource representing a collection of <notificationChannel> resources, and the <notificationChannel> resource is a resource used by clients without server capabilities to receive asynchronous notifications. Is a resource that is used for reception.

The attachedDevices resource is a collection resource representing a set of <attachedDevice> resources, and the <attachedDevice> resource is a resource representing a device connected to the server via the M2M gateway (or GSCL).

&Quot; attribute &quot; is meta data providing a property associated with the resource representation information, and includes accessRightID indicating an identifier for access right to the resource having the attribute, creationTime indicating the creation time of the resource having the attribute, And may include lastModified properties indicating the last modification time of the resource. The definitions and structures of the above-described resources and other resources are defined in the above-mentioned ETSI standard, and a detailed description thereof will be omitted.

4B is a diagram illustrating an example of a resource tree according to an embodiment of the present invention.

According to the example shown in Fig. 4, the periodic classification of measured data in the device can be created as classifiedGrade by the device classifying process under the mgmtObjs resource, and under each classifiedGrade resource, The list is registered as deviceList.

The classfiedGrade can be registered to a predetermined number, for example, up to 10, as described above, and is created and managed in units of the M2M gateway. The classifiedGrade resource and the deviceList resource, which are device classification resources, can be dynamically managed according to measurement periods of the device as described later.

FIG. 5A is a diagram schematically illustrating a configuration of an M2M service platform according to an embodiment of the present invention.

The M2M service platform (or NSCL) 301 according to one embodiment of the present invention includes a Network Remote Entity Management (NREM) unit 510, an SNMP unit 521, an NGC unit 522, 523).

The NREM 510 performs a function of processing messages such as managed object (MO) data and <mgmtObj> resource management of the ETSI standard. The NREM unit 510 includes a NREM unit 510, A device classification management unit 512, a measurement data monitoring unit 513, and a file processing unit 514. The event request processing unit 511, the device classification management unit 512, the measurement data monitoring unit 513,

The event request processing unit 511 requests an event to the M2M device or processes an event transmitted from the M2M device. Here, the event may include status information on the child device to a specific gateway to which the child device, Request and process it. The event request processing unit 510 also receives a category-specific abnormal device list including information on lower-level devices, which are determined to be not normally received, among lower-level devices included in the category-specific device list managed by the device classification management unit 512 And requests status information about the devices from the M2M gateway 201, 202, ....

The device classification class management unit 512 classifies and manages classes for the M2M devices in each data generation period. That is, when the device class management unit 512 periodically receives the measured data from the M2M device, the device class management unit 512 inquires the time information of the data recently generated in the same device, calculates the measurement period of the device, And generates a list of classified devices by mapping to a classification class close to each other.

Initially, the measurement period classification class can be set to any classification class, such as 1 hour, 1 day, 1 week, 1 month, etc. If the measurement data period of the M2M device deviates as described below, And the measurement time difference of data measured at the same device in the future exceeds the threshold value (which can be arbitrarily determined as a unit for generating the device classification class) periodically, the device class classification can be updated at the corresponding measurement cycle. In addition, the device classification level may be dynamically changed based on a measurement data cycle.

It is desirable to manage the device classification class with a limit of, for example, 10 per gateway. This is because if too many device classifications are given, the management burden of the M2M service platform increases, and the management process becomes complicated and the M2M network can not be efficiently managed.

The measurement data monitoring unit 513 monitors whether or not data is normally received from the lower device included in the device list. If there is a device classification class including a lower device that is not normally measured as a result of monitoring by the measurement data monitoring unit 513, the event request processing unit 511 is requested to request status information on the lower device.

The file processing unit 514 parses the file related to the status information of the abnormal device transmitted from the M2M gateway, extracts the measured device status information, and updates the related resource using the information.

5A, the NGC (Network Generic Communication) unit 522 is a functional block that provides a communication function for transmitting and receiving messages with the M2M gateway 205, which is defined in the ETSI standard.

In addition, the Simple Network Management Protocol (SNMP) unit 521 supports a protocol for managing the M2M device. The simple network management protocol unit 521 can perform a GET for searching for a management object, a SET for changing, and a TRAP command for transmitting notification information.

The other services capability unit 521 performs security functions, connectivity, and address management functions to be supported by the M2M service platform. These functional blocks are defined in the above-mentioned ETSI standard, and therefore detailed description will be omitted.

The NA / device management system 500 performs a specific service logic as an application resident in the server, which may be part of the M2M service platform, or may be a system separately constructed by another network operator.

FIG. 5B is a view schematically showing a configuration of a gateway according to an embodiment of the present invention.

The M2M gateway according to the present invention comprises a gateway application (GA) and a GSCL (200), wherein the GA is an application residing in the gateway and performs specific service logic.

The GSCL 200 includes a Gateway Remote Entity Management (GREM) unit 530, a GGC unit 533, an SNMP unit 534, and other service capability units 535.

The GREM unit 530 provides management functions to be performed by the M2M gateway and may include an event request processing unit 531 and a file generating unit 532. [ When receiving the status information request message of the M2M device from the M2M service platform, the event request processing unit 531 requests the status information of the abnormal device included in the abnormal device list of the rank of the status information request message, And the file generating unit 532 is responsible for generating a status information file of an abnormal device to be transmitted to the M2M service platform as described above.

The GGC unit 533 is a functional block for providing a communication function for transmitting and receiving messages with the NSCL. The SNMP unit 534 is for supporting a protocol for managing the M2M device, and the other service capability unit 535, Is a functional block for performing security functions, connectivity, and address management functions to be supported by the GSCL 200.

FIG. 6 is a flowchart illustrating a process of classifying a class of an M2M device according to a measurement data cycle by an M2M service platform according to a preferred embodiment of the present invention.

When the M2M service platform receives an event from the M2M device (or from the M2M gateway) in step S601, it is determined whether the event corresponds to the reporting of the measurement data of the M2M device, that is, whether the event information includes measurement data (Step S602).

If it is determined in step S602 that measurement data is not included in the event information, monitoring is continued until measurement data is included in the event information.

If it is determined in step S602 that measurement data is included in the event information, the device identification information is extracted from the received event information, and the device list of the class indicating the current device classification class is inquired, (Steps S603 and S604).

If the device that transmitted the measurement data exists in the device list of the specific grade in step S604, the latest data measured by the device is inquired (step S605). In step S606, a time interval between the measurement time of the currently measured data of the device and the measurement time of the latest data is extracted, and the time interval is compared with a predetermined threshold value (step S607). The threshold value in step S607 is a value determined arbitrarily as a value for determining whether or not there is a period in the device classification class.

If it is determined in step S607 that the time interval is not larger than the threshold value, the resource tree is updated by reflecting the currently measured data on the related resource managed by the M2M service platform (step S608). An example of a resource to be updated is as follows.

<sclBase> / scls / <scl> / applications / <containers> / containers / contentInstances / <contentInstance> / <content>

Here, the <container> resource represents a container (a kind of repository) for the instance object, the <contentInstance> resource represents the data instance in the container, and the currently measured data is reflected in the <content> resource.

On the other hand, if it is determined in step S604 that the classification level for the device that transmitted the measurement data does not exist in step S604 (step S609), it is determined whether the provisional rating exists for the device The measurement time of the device is recorded (step S610), and the resource tree for managing the current measurement data is updated (step S608).

If the temporary grade for the device does not exist in step S609, or if the time interval is greater than the threshold value in step S607, a new temporary grade is generated for the device (step S611), and the measured data of the device is stored in the newly created temporary grade (Step S608).

7 is a flowchart illustrating a procedure for monitoring whether measurement data is periodically received from an M2M device in an M2M service platform according to an exemplary embodiment of the present invention.

In step S701, the M2M service platform extracts a specific device from the list of device-by-grade for the M2M device, and searches for the latest data on the extracted device (step S702).

Thereafter, in order to monitor the extracted device, the time interval between the current time for performing the search of the latest measurement data for the extracted device and the measurement time of the latest measurement data is compared with the classification rating measurement period, (Step S703).

If it is determined in step S703 that the difference between the classification grade measurement period and the time interval is not larger than a certain threshold value, it is determined that data is normally measured in the extracted device (step S704). In step S705, It is determined whether another device is present, and the procedure after step S701 is repeated until there is no other device to be monitored.

If the difference between the classification grade measurement period and the time interval is greater than a certain threshold value in step S703, the device is determined to be an abnormal measurement device and is registered in the abnormal device list by class (step S706), and the procedure after step S705 is repeated.

After determining whether the measurement data is periodically received for all the devices included in the classified device list, it is determined in step S707 whether there are devices registered in the classified device by abnormal device list. If there is a list of abnormal devices by class, And requests status information on the device (s) determined to be abnormal in the gateway to which the device (s) included in the device list belongs (step S708). As described above, the request message may include the unsteady-type abnormal device list.

As described above, according to the present invention, compared to the prior art in which state information is requested to each of the devices to which data is not normally transmitted, all the devices included in the unlisted abnormal device list, to which data is not normally transmitted, To reduce the possibility of M2M data loss in M2M gateways and M2M service platforms due to excessive operation maintenance messages.

301: M2M service platform or NSCL
500: Device Management System
510: NREM section
511: Event Request Processor
512: device class management section
513: Measurement data monitoring section
514:
522: NGC Department
530: GREM part
533: GGC department

Claims (16)

The M2M service platform sending a request message to the M2M gateway requesting status information about a child device to which data is not normally transmitted among the child devices of the M2M gateway; And
And receiving a status information file for the lower-level device to which the data is not normally transmitted for each of the M2M gateways. The method according to claim 1,
Further comprising the steps of: classifying the class of the lower device according to a data generation period of the lower device; and generating a class-specific device list belonging to the same class. 3. The method of claim 2,
Further comprising the step of updating the list of devices according to the rating based on a measurement time of data transmitted from the lower device. The method of claim 3,
The step of updating the list of devices by grade may further include the step of updating a tentative rating for the lower device if the time interval between the measurement time of the data transmitted from the lower device and the measurement time of recently stored data for the lower device exceeds a predetermined threshold The method comprising the steps of: 3. The method of claim 2,
Further comprising the step of monitoring whether data is normally received from a lower device included in the device list of the class. 6. The method of claim 5,
Wherein the monitoring step determines that data is not normally received from the lower device when the time interval between the current time for retrieving the latest measurement data for the lower device and the measurement time for the recently stored data exceeds a predetermined threshold The method comprising the steps of: 6. The method of claim 5,
Further comprising generating a list of unlisted devices by class including information on the lower devices that are not normally received data among the lower devices included in the list of the devices classified by the class. 8. The method of claim 7,
And the list of unstructured devices is included in the request message. 9. The method of claim 8,
Wherein the status information file includes status information on a child device included in the abnormal device list by class. The method according to claim 1,
Further comprising: parsing the status information file to update a resource status of the lower-level device. A device classification class management unit for generating a class-specific device list for the lower-level device in each data generation period of the lower-level devices of the M2M gateway; And
A measurement data monitoring unit for monitoring whether data is normally received from the lower device,
And an M2M service platform. 12. The method of claim 11,
Further comprising an event request processing unit for generating a list of unequal-rank devices including information on the lower-level devices, which are determined to not normally receive data among the lower-level devices included in the list of the classified devices. 13. The method of claim 12,
Wherein the event request processing unit requests the M2M gateway to transmit a status information file for the lower device included in the abnormal device list of the class. 14. The method of claim 13,
Further comprising a file processor for parsing the status information file transmitted from the M2M gateway and extracting status information on the lower-level devices included in the unstructured-type abnormal device list. 12. The method of claim 11,
The device class management management unit generates a temporary class for the lower device if the time interval between the measurement time of the data transmitted from the lower device and the measurement time of the data stored recently with respect to the lower device exceeds a predetermined threshold Gt; M2M &lt; / RTI &gt; service platform. An event request processing unit for requesting status information of the lower device as a lower device included in the classified abnormal device list transmitted from the M2M service platform; And
And a file generation unit for generating a status information file for the lower-level devices included in the unregistered-device-by-rank-list.

Images