KR20160036691A - Mechanism for Handling Multi-Connected M2M/IoT Device using Cache - Google Patents

Abstract

A cache mechanism for handling an M2M/IoT device linked to multiple M2M/IoT devices is disclosed. According to an embodiment of the present invention, there is provided a mechanism which appropriately transmits or assigns, to related devices, data transmitted from an M2M/IoT device with a type of collecting and providing information about multiple devices.

Description

A mechanism for handling M2M / IoT devices associated with multiple M2M / IoT devices {Mechanism for Handling Multi-Connected M2M / IoT Device using Cache}

This embodiment relates to M2M / IoT Architecture, and more particularly, to a cache mechanism for handling M2M / IoT devices associated with multiple M2M / IoT devices.

M2M (Machine-to-Machine) communication provides information for performing various applications such as Smart Metering, Home Automation, eHealth and Fleet Management ("M2M Application"). Refers to a communication category performed by or between devices configured to transmit, receive, or exchange (so-called " machine "). Generally, the execution of various application programs and, in turn, the M2M communication annexed to such an execution is performed by the machine without requiring human intervention for triggering, initiating and / or sending M2M communications. As will be appreciated, the successful implementation and deployment of M2M applications depends on the adoption of industry-wide standards that define requirements to ensure interoperability between the various devices that can be manufactured and operated by various entities There is a high possibility.

Smart metering, which is a representative example of the M2M applications described above, is to quantify the energy consumption of devices (e.g., TVs, air conditioners, refrigerators, etc.). Since devices generally do not have the capability to measure their energy use, a separate device is used to measure their energy use. Some of the devices may have a number of individual devices that are not registered as devices in the server, such as Smart Multi-plug, which provides power to a plurality of other electronic devices and measures energy usage. Is a representative example.

Since the smart multi-plug is a single device with a network connection to the server, the smart multi-plug can be registered as a node in the server. The smart multi-plug measures the energy usage of other electronic devices connected to it and sends packets containing the measured data to the server, so these measured data needs to be allocated to the appropriate applications.

However, the oneM2M architecture, which is currently being standardized, does not provide a standard for devices and their message handling types that collect / provide information about a plurality of other devices, such as the above smart multi-plug. In particular, the oneM2M standard specifies links between resources, but the defined links are only about "parent-child" relationships.

Some embodiments of the present invention have a main purpose of providing a mechanism for appropriately transmitting or distributing data transmitted by a device of a type that collects / provides information related to a plurality of other devices to other related devices.

According to an aspect of this embodiment, there is provided an M2M entity comprising: an application layer configured to provide M2M applications; And a common service layer configured to provide functions shared by the M2M applications, wherein the common service layer manages resources on a resource structure and provides services to a plurality of other devices Parses a message sent from a device (hereinafter referred to as a " multi-link device "), and distributes the parsed data to the resources of the plurality of other devices.

According to another aspect of this embodiment, there is provided an M2M entity comprising: an application layer configured to provide M2M applications; And a common service layer configured to provide functions shared by the M2M applications, wherein the common service layer manages resources on the resource structure, and for registering a multi-link device, Resource for each of the resources of the other device, and generates information on a method of processing a message received from the multi-link device.

According to another aspect of this embodiment, there is provided a method of handling a multi-link device, the method comprising: receiving a message from the multi-link device; Parsing the received message; And distributing the parsed data to the resources of the plurality of other devices.

According to another aspect of this embodiment, there is provided a method of handling a multi-link device, the method comprising: receiving a registration request message from the multi-link device; Parsing the received registration request message; Generating a resource structure for the multi-link device based on the parsed data; Generating sub-resources for resources of other devices connected to the multi-link device; And generating information on a method of processing a message received from the multi-link device.

As described above, according to the present embodiment, in the M2M / IoT Architecture, a device serving a plurality of other devices can be provided with a mechanism for handling the multi-link device.

That is, the hosting IN-CSE may provide a mechanism for registering the multi-link device and a mechanism for the hosting IN-CSE to appropriately distribute or convey the data that the multi-link device transmits to other devices associated therewith.

Figure 1 is a diagram illustrating an architecture in accordance with the oneM2M standard.
FIG. 2 is a diagram showing a CSE defined by the oneM2M standard. FIG.
3 is a diagram illustrating a plurality of other devices connected to the smart multi-plug and their resource structures.
4 is a diagram illustrating a registration mechanism of a multi-link device according to an embodiment of the present invention.
FIG. 5 is a flowchart illustrating a registration procedure of a multi-link device according to the embodiment illustrated in FIG.
6 is a diagram illustrating a registration mechanism of a multi-link device according to another embodiment of the present invention.
7 is a flowchart illustrating a registration procedure of the multi-link device according to the embodiment illustrated in FIG.
8 is a flow chart illustrating a mechanism for updating registration information of a multi-link device according to an embodiment of the present invention.
9 is a flowchart illustrating a mechanism for updating registration information of a multi-link device according to another embodiment of the present invention.
10 is a diagram for explaining a function of the IN-CSE for distributing the measurement data transmitted by the multi-link device.
11 is a flowchart illustrating a procedure for an IN-CSE to process a message received from a multi-link device, in accordance with an embodiment of the present invention.
12 is a flowchart illustrating a procedure for an IN-CSE to process a message received from a multi-link device, according to another embodiment of the present invention.

Hereinafter, a method for setting a resource access right in the M2M communication according to the present embodiment will be described in detail. In order to clearly illustrate the present invention in the drawings, portions not related to the description in the drawings are omitted, and the same portions are denoted by the same reference numerals throughout the specification.

Throughout the specification, when an element is referred to as including an element, it is understood that it may include other elements as well, without departing from the other elements unless specifically stated otherwise. On the other hand, the terms or abbreviations used in the specification should be interpreted to comply with M2M technical standards such as M2M / IoT communication technology field and oneM2M unless otherwise specified in the specification.

First, we briefly introduce the functional architecture defined in oneM2M standard.

Figure 1 is a diagram illustrating an architecture in accordance with the oneM2M standard.

The oneM2M architecture consists largely of three functional nodes. The Application Service Node (ASN) refers to a general M2M device that includes not only an M2M application but also a common service function. A middle node (MN) is a node that serves as a gateway for connecting device nodes and a network infrastructure. An infrastructure node (IN) is a node that is located in a network infrastructure and provides M2M service. The Application Service Node (ASN) and the Middle Node (MN) can be classified into a device domain, and the Infrastructure Node (IN) can be divided into a platform domain.

Each functional node contains at least one Application Entity (AE) and a Common Service Entity (CSE). The CSE is a logical entity that runs within M2M nodes and contains Common Services Functions (CSFs), a set of common M2M service functions. CSFs can be used by AEs and other CSEs. AE and CSE are connected to Mca reference points, CSEs located at CSE and other nodes are connected to Mcc reference points, and access networks such as CSE and 3GPP are connected to Mcn reference points. That is, the AE uses the Mca reference point when the CSE uses the service, the CSE uses the Mcc reference point when the CSE uses the service of another CSE, and the CSE is used when the service of the underlying network is used.

FIG. 2 is a diagram showing a CSE defined by the oneM2M standard. FIG.

According to the oneM2M standard, the CSFs include a Registration CSF (REG CSF) that helps to register nodes and CSEs, a Security CSF (SEC CSF) that provides security and privacy for service connections, and upgrades and management of CSEs and AEs. And the AE and Service Layer Management CSF (ASM CSF). In particular, CSFs include Communication Management / Delivery Handling (CMDH), which provides functions for message delivery and handling.

oneM2M follows a resource-based data model, and all services provided at the service layer are provided through these resources. A resource is represented by a structure of data, and each resource is referenced via a URI. In addition, oneM2M provides management of resources and properties using the CRUD (CREATE, RETRIEVE, UPDATE, DEAELETE) commands that are commonly used in RESTful architecture styles. The CSE where the resource to be processed is located is called the Hosting CSE.

The following description is preferably understood with reference to Figs. 1, 2, and the contents described above. Referring now to the drawings, embodiments of the present invention relating to a mechanism for supporting M2M / IoT devices associated with multiple M2M / IoT devices will be described in detail.

1. Multi-link device ( Multi - Linked Device )

Smart Metering, a prime example of M2M / IoT applications, is to quantify the energy consumption of devices (eg, TVs, air conditioners, refrigerators, etc.). Since these devices generally do not have the capability to measure their energy usage, a separate device is used to measure their energy use. Some of the devices may have a number of discrete devices not registered as devices in the server, a smart multi-plug that powers a plurality of electronic devices and measures their energy usage .

Since the smart multi-plug device is a single device with a network connection to the server, the smart multi-plug can be registered as a node in the server. The smart multi-plug measures the energy usage of other devices connected to it and sends packets containing the measured data to the server, so these measured data needs to be allocated to the appropriate applications. A device serving a plurality of other devices, such as the illustrated smart multi-plug, will be referred to as a multi-link device (MLD).

3 is a diagram illustrating a plurality of other devices connected to the smart multi-plug and their resource structures.

3 illustrates a case where three devices (A: refrigerator, B: toaster, C: TV) are plugged into plugs 1, 2 and 3, respectively, in a smart multi-plug. The smart multi-plug can be configured to measure the energy usage (i.e., the amount of energy supplied to each device) of each of the devices A, B, and C, and to transmit data periodically measured to the server.

The server's CSE manages the resource structure (including one or more attributes and child resources) of each device, and stores data about each device in the attribute. In addition, the CSE of the server can be registered in the server as a single node of the smart multi-plug. Thus, the CSE of the server can manage the resource structure for the smart multi-plug, and the smart multi-plug can store the measured data in the resource structure for the smart multi-plug. However, the measurement data stored in the resource structure of the smart multi-plug is measurement data of other devices.

The packet generated by the smart multi-plug contains the measured data for other connected devices, and the server receiving the packet must be able to identify that the packet was generated by a smart multi-plug. For example, when a smart multi-plug is registered, the server needs a method that can confirm the type of the device. With this in mind, the packet generated by the smart multi-plug may be configured to include at least some of the following:

- an indication that the packet is generated from an MLD;

- all measured values from the connected device

- A: 30: B: 20.C: 40, 'ABC = 30.20.40. ==> A, B and C are the delimiters C devices were measured to consume 30, 20 and 40 watts, respectively.)

As described above, since the measurement data included in the packet transmitted from the smart multi-plug is essentially for other devices, the server needs to manage the measurement data in association with the other devices. In addition, the server receiving the packet containing the measurement data needs to perform certain procedures such as parsing the packet and delivering the parsed data to the appropriate resources.

2. Multi-link Device  Enrollment( Registration of MLD )

As described above, a multi-link device may also be registered with the server as a node, but the host IN-CSE may be a multi-link device, in that the data that the multi- The following two embodiments can be considered as a mechanism for registering a device.

First, the first embodiment will be described with reference to FIGS. 4 and 5. FIG. FIG. 4 is a diagram illustrating a registration mechanism of a multi-link device according to an embodiment of the present invention, and FIG. 5 is a flowchart illustrating a registration procedure of a multi-link device according to the embodiment illustrated in FIG. The embodiment illustrated in Figures 4 and 5 illustrates a method of registering as a separate resource from other devices connected to a multi-link device, whereby the relevance of other devices related to the resources of the multi- link. For example, the hosting IN-CSE verifies the message from the multi-link device, derives the connected device information, and creates resources for the multi-link device and other devices connected thereto. Also, the hosting IN-CSE creates a link between the sub-resources of the multi-link device corresponding to the other devices.

The specific registration procedure will be described with reference to the flowchart illustrated in FIG.

In STEP 001, the multi-link device sends a registration request message to the IN-CSE. The registration request message may include the following information.

- Indicator (MLD Indication) indicating multi-link device

- the number of other devices that can be connected to the multi-link device (e.g., in the case of a smart multi-plug, information about how many other devices can be plugged)

- the number of other devices connected (e.g., in the case of a smart multi-plug, information on how many other devices are plugged)

An identifier of the connected other devices and an identifier of the individual devices (e.g., individual plugs of the smart multi-plug) included in the corresponding multi-link device

- additional information (e.g., IDs of other connected devices, type of application, etc.)

In step 002, the IN-CSE checks the registration request message and generates corresponding resources and links. That is, the IN-CSE generates resources and sub-resources for the multi-link device itself, and generates lower resources for the resources of other devices connected to the multi-link device. In addition, the IN-CSE creates a link between the lower resources corresponding to each other.

In step 003, the IN-CSE notifies the multi-link device that registration has been successful.

In step 004, the IN-CSE informs other IN-CSEs associated with the <application> that the <application> is registered.

Hereinafter, with reference to Figs. 6 and 7, a second embodiment of a mechanism in which a hosting IN-CSE registers a multi-link device will be described.

FIG. 6 is a diagram illustrating a registration mechanism of a multi-link device according to another embodiment of the present invention, and FIG. 7 is a flowchart illustrating a registration procedure of a multi-link device according to the embodiment illustrated in FIG. The embodiment illustrated in Figs. 6 and 7 illustrates a method of registering with other devices connected to a multi-link device, and the IN-CSE must support the following functions. For example, the IN-CSE verifies the message from the multi-link device, derives the connected device information, and stores the multi-link device information in its local memory area. In addition, the IN-CSE searches the resources of the other devices and creates a lower resource in each of the retrieved resources. These lower resources are used to store measurement data received from the multi-link device.

The specific registration procedure will be described with reference to the flowchart illustrated in FIG.

In STEP 001, the multi-link device sends a registration request message to the IN-CSE. The registration request message may include the following information.

- Indicator indicating multi-link device

- the number of other devices that can be connected to the multi-link device (e.g., in the case of a smart multi-plug, information about how many other devices can be plugged)

- the number of other devices connected (e.g., in the case of a smart multi-plug, information on how many other devices are plugged)

- the identifier of the connected other device and the identifier of the corresponding plug

- additional information (e.g., IDs of other connected devices, type of application, etc.)

In step 002, the IN-CSE checks the registration request message, checks the resources of other connected devices, and creates a lower resource in each of these resources. In addition, the IN-CSE generates multi-link device related information in its local memory area. The multi-link device related information should include a matrix indicating how messages received from the multi-link device should be handled. For example, the multi-link device related information should include the identifier of the multi-link device and the identifiers of other devices connected thereto. Thus, when the IN-CSE receives a message from the multi-link device, the IN-CSE derives the requested information from the message and distributes the information to the appropriate resource.

In step 003, the IN-CSE notifies the multi-link device that registration has been successful.

In step 004, the IN-CSE publishes the registration of the <application> to other IN-CSEs associated with the <application>.

Since the multi-link device is subject to change, such as addition or removal of other devices connected to it, the IN-CSE may update registration information related to the multi-link device (e.g., , A matrix indicating how messages received from the multi-link device should be handled, etc.). In updating the registration information, two embodiments can be considered as well as the mechanism for registering the multi-link device illustrated in Figs. 4 to 7. Hereinafter, with reference to Figs. 8 and 9, a mechanism for updating the registration information of the multi-link device will be described.

8 is a flow chart illustrating a mechanism for updating registration information of a multi-link device according to an embodiment of the present invention.

In STEP 001, the multi-link device sends an update registration request message to the IN-CSE. The update registration request message may include the same information as the registration request message, but it is preferable to include the abbreviated information as follows because the update registration request message is used to transmit the connection addition or connection release information of the other device to the IN_CSE.

- Indicator (MLD Indication) indicating multi-link device

- Indicator indicating information about adding or disconnecting connections of other devices

- identifiers of other devices added or released and identifiers of individual devices (e.g., individual plugs of a smart multi-plug) included in the corresponding multi-link device

- additional information (e.g., IDs of other devices added or released, type of application, etc.)

In step 002, the IN-CSE checks the update registration request message and updates the corresponding resources and links. In other words, the IN-CSE creates or deletes sub resources in the resources of other devices added or released. In addition, the IN-CSE updates the link between the lower resources corresponding to each other.

In step 003, the IN-CSE notifies the multi-link device that update registration has succeeded.

In step 004, the IN-CSE informs the other IN-CSEs associated with the < application >

9 is a flowchart illustrating a mechanism for updating registration information of a multi-link device according to another embodiment of the present invention.

In STEP 001, the multi-link device sends an update registration request message to the IN-CSE. As described above, the update registration request message may include the same information as the registration request message. However, since the update registration request message is used to transmit the connection addition or connection release information of another device to the IN_CSE, it is preferable to include the reduced information Do.

In step 002, the IN-CSE checks the update registration request message and creates or deletes the lower resource of the added or released devices. In addition, the IN-CSE updates the multi-link device related information stored in its local memory area.

In step 003, the IN-CSE notifies the multi-link device that update registration has succeeded.

In step 004, the IN-CSE publishes the update registration of the <application> to the other IN-CSEs associated with the <application>.

3. Delivery of measurement data ( Delivery of Measured Data )

10 is a diagram for explaining a function of the IN-CSE for distributing the measurement data transmitted by the multi-link device. The IN-CSE needs to communicate the measurement data transmitted by the multi-link device to the resources of other appropriate devices. Therefore, the CMDH (Communication Management and Delivery Handling) function of the IN-CSE requires functions for transferring measurement data. That is, as shown in FIG. 10, the CMDH of the IN-CSE parses a message received from the multi-link device or a value stored in a resource of the multi-link device, and distributes ) Is required. The parsing and distribution functions of the CMDH can be considered in the following two embodiments.

11 is a flowchart illustrating a procedure for an IN-CSE to process a message received from a multi-link device, in accordance with an embodiment of the present invention.

In a second embodiment, the CMDH may include i) storing the values contained in the message received from the multi-link device in a resource of the multi-link device. In this case, unlike other general device resource types, it is necessary to define an additional type of 'multi-link device resource', namely, <MLD resource>. Once the values are stored in the MLS resource, the IN-CSE can parse the stored values and distribute the parsed values to the resources of other appropriate devices. The procedure illustrated in FIG. 11 is suitable when the multi-link device is registered with the hosting IN-CSE according to the method illustrated in FIG. 4 and FIG.

Referring to the flowchart of Fig. 11, in STEP 001, the multi-link device transmits a message containing the measured information to the IN-CSE. The message may include the following information in a predetermined format.

- Indicator indicating multi-link device

- the identifier of the multi-link device

- measurement data (e.g., pairs of 'measured device ID and measurement value'),

In step 002, the IN-CSE performs the following steps upon receiving a message.

- Check whether the message is a message sent from a multi-link device.

- If the message is a message sent from a multi-link device, check the identifier of the multi-link device and derive the corresponding matrix information.

- Parset the message to extract measurement data.

- The extracted measurement data is stored in the lower resource of the corresponding other device.

In step 003, the IN-CSE notifies the multi-link device that the data has been properly stored.

In step 004, the IN-CSE informs the other IN-CSEs of the update of < application >. Here, < application > indicates an application that has been previously announced.

12 is a flowchart illustrating a procedure for an IN-CSE to process a message received from a multi-link device, according to another embodiment of the present invention.

The embodiment illustrated in FIG. 12 is a method in which a hosting IN-CSE (Host In-CSE) parses a message received from a multi-link device and stores values of a plurality of other devices included in the message in an appropriate resource . For example, the CMDH may include: i) a function to determine whether a message is received from a multi-link device, ii) a function to determine whether a message is received from a multi-link device, Value, ... "), and iii) after parsing the message, storing the values of a plurality of other devices included in the message in an appropriate resource. The procedure illustrated in FIG. 12 is suitable when the multi-link device is registered with the hosting IN-CSE according to the method illustrated in FIG. 6 and FIG.

12, in STEP 001, the multi-link device generates a message including measurement data for a plurality of other connected devices in a predetermined packet format, and transmits the generated message to the hosting IN-CSE .

In STEP 002, upon reception of the message, the CMDH of the hosting IN-CSE determines whether the received message is data transmitted from a device of the multi-link device type (e.g., whether the message includes an indicator indicating the type of multi- Or not).

In step STEP 003, when it is determined that the received message has been received by the device rotor of the multi-link device type, the host IN-CSE parses the received message and stores measurement data for each device (e.g., ').

In STEP 004, CMDH confirms the device ID in the IN-CSE resource structure, and then stores the measurement data for each device in an appropriate location (resource or attribute of another device).

In step 005, the hosting IN-CSE notifies the multi-link device that the data has been properly stored.

In step 006, the IN-CSE informs the other IN-CSEs of the update of < application >. Here, < application > indicates an application that has been previously announced.

In the above-described embodiments, the communication management and delivery handling (CMDH), which provides functions related to message delivery and handling, is included among CSFs, which are common M2M service functions included in the CSE, In the example, other CSFs other than CMDH may include parsing and distribution functions, and other logical entities other than CSE may perform parsing and distribution functions.

The foregoing description is merely illustrative of the technical idea of the present embodiment, and various modifications and changes may be made to those skilled in the art without departing from the essential characteristics of the embodiments. Therefore, the present embodiments are to be construed as illustrative rather than restrictive, and the scope of the technical idea of the present embodiment is not limited by these embodiments. The scope of protection of the present embodiment should be construed according to the following claims, and all technical ideas within the scope of equivalents thereof should be construed as being included in the scope of the present invention.

Claims (12)

In an M2M entity,
An application layer configured to provide M2M applications; And
A common service layer configured to provide functions shared by the M2M applications,
The common service layer manages resources on a resource structure, parses a message transmitted from a device serving as a service to a plurality of other devices (hereinafter referred to as a 'multi-link device'), To the resources of the plurality of other devices. The method according to claim 1,
The message transmitted from the multi-link device,
And a format capable of distinguishing data from the lower devices of the multi-link device. The method according to claim 1,
The message transmitted from the multi-link device,
And an Indication indicating that the message was sent from the multi-link device. In an M2M entity,
An application layer configured to provide M2M applications; And
A common service layer configured to provide functions shared by the M2M applications,
The common service layer manages resources on the resource structure, and for registering a device serving a plurality of other devices (hereinafter, referred to as a 'multi-link device'), Resources in the resources of the multi-link device, and generates information on how to process the messages received from the multi-link device. 5. The method of claim 4,
The information on the processing method may be,
An identifier of the multi-link device, and an identifier of other devices connected to the multi-link device. 5. The method of claim 4,
Wherein the common service layer comprises:
Receiving a registration request message from the multi-link device, the registration request message including an indicator indicating that the device is a multi-link device, the number of other devices that can be connected to the multi-link device, An identifier of the device, and an identifier of another device connected to the multi-link device. A method of handling a device (hereinafter referred to as a multi-link device) serving as a common service layer to a plurality of other devices,
Receiving a message from the multi-link device;
Parsing the received message; And
Distributing the parsed data to the resources of the plurality of other devices
Lt; RTI ID = 0.0 &gt; multi-link &lt; / RTI &gt; 8. The method of claim 7,
The message transmitted from the multi-link device,
And a format for distinguishing data from the lower devices of the multi-link device. 8. The method of claim 7,
The message transmitted from the multi-link device,
And an Indication indicating that the message is sent from the multi-link device. A method of handling a device (hereinafter referred to as a multi-link device) serving as a common service layer to a plurality of other devices,
Receiving a registration request message from the multi-link device;
Parsing the received registration request message;
Generating a resource structure for the multi-link device based on the parsed data;
Generating sub-resources for resources of other devices connected to the multi-link device; And
A step of generating information on a method of processing a message received from the multi-link device
Lt; RTI ID = 0.0 &gt; multi-link &lt; / RTI &gt; 11. The method of claim 10,
The information on the processing method may be,
Link device comprises an identifier of the multi-link device and an identifier of other devices connected to the multi-link device. 11. The method of claim 10,
The registration request message includes:
Link device, the number of other devices that can be connected to the multi-link device, the number of other connected devices, the identifier of the multi-link device, and the identifier of the other device connected to the multi-link device Lt; RTI ID = 0.0 &gt; 1, &lt; / RTI &gt;

Images