WO2013176425A1

WO2013176425A1 - Scheduled polling method and m2m apparatus therefor

Info

Publication number: WO2013176425A1
Application number: PCT/KR2013/004070
Authority: WO
Inventors: 이승권; 장덕문
Original assignee: 주식회사 케이티
Priority date: 2012-05-21
Filing date: 2013-05-09
Publication date: 2013-11-28

Abstract

The present invention relates to a scheduled polling method and to an M2M apparatus therefor. The scheduled polling method includes the steps of: transmitting a request for receiving an M2M resource managed by a separate M2M object which operates as a server; receiving a response including schedule information related to M2M resource management from the server; and transmitting a new request for receiving an M2M resource according to the schedule information.

Description

Schedule polling method and its M2M device

The present invention relates to a schedule polling method and an M2M device thereof, and more particularly, to a schedule polling method and an M2M device implemented for requesting and receiving various information in communication between M2M devices which are objects or inter-object communication.

IoT is a communication process for people such as machine to machine communication (M2M), machine type communication (MTC), Internet of Thing (IoT), smart device communication, or machine oriented communication. Refers to all communication methods in which communication is performed without intervention.

This thing communication does not require that the communication always be connected. In the case of transmitting and receiving information, the information may be transmitted and received only when there is a request.

According to the M2M service structure described in ETSI TS 102 690 v1.1.1, short polling and long polling schemes are currently proposed as a communication method for requesting and receiving resources between a client and a server.

Such short polling or long polling requests information regardless of the type of information on a time basis set by the requesting party or in a time-independent manner.

That is, in the present M2C communication, a communication method according to an environment in which information transmission conditions vary according to information transmission conditions or types of information on the side of the information transmission side rather than the requesting information is not presented.

According to the present invention, there is provided a schedule polling method for resource transmission and an M2M device thereof.

In the present specification, in order to implement the above-described problem, as a polling method in consideration of the information transmission condition of the information transmitting side or the information transmission condition according to the type of information, for example, a periodic collection of data or an occurrence time of an event are predicted. Provided are an efficient scheduled polling method and apparatus therefor that are possible in an M2M environment.

Schedule polling method according to an embodiment of the present disclosure, in the M2M object acting as a client, transmitting a request for receiving M2M resources managed by a separate M2M object acting as a server; Receiving a response including schedule information related to the M2M resource management from the server, and transmitting a new request for receiving the M2M resource according to the schedule information.

The M2M device implementing the schedule polling method according to another embodiment of the present disclosure may create a request for receiving an M2M resource managed by a separate M2M object, and if a response is received from the separate M2M object for the request, An M2M module for extracting schedule information related to the M2M resource management from a response, and a communication module for transmitting the request made by the controller and receiving the response to the request, wherein the M2M module is configured according to the schedule information. A new request for receiving the M2M resource is prepared and transmitted through the communication module.

Schedule polling method according to another embodiment of the present disclosure, receiving an M2M resource transmission request from a separate M2M object acting as a client in the M2M object acting as a server; Transmitting a response including the next modification schedule time of the M2M resource or a prediction schedule time at which a next notification message is to be transmitted to the client; And receiving a new transmission request for the M2M resource from the client according to the schedule time information.

The present invention reduces the traffic of the M2M network by supplementing the disadvantages of short polling and long polling, and dramatically reduces the traffic load in an M2M environment where periodic data collection or event occurrence time can be predicted. A reduced schedule polling method is implemented.

The scheduled polling method according to the present invention can collect data more efficiently than a long polling method when collecting data through a periodic method. In particular, it is very efficient when collecting data in an environment where the reporting period from the M2M sensor changes frequently. Periodic data collection is widely used in applications such as smart metering, eHealth, and city automation.

Scheduled polling may be efficiently used even in an event method where an event occurrence time is predictable. For example, the event occurrence time can be predicted by accumulating event occurrence time data such as year / month / weekly / day in a hosting service capability layer (SCL), and then predicting the average event occurrence time data.

Scheduled polling can be used efficiently on-demand reporting when the M2M sensor cannot report immediately due to some failure, but the reporting period is fixed or when the reporting time point is predictable.

Scheduled polling is easy to implement due to its simple structure.

FIG. 1 is a diagram for describing a short polling scheme presented in ETSI TS 102 690.

FIG. 2 is a diagram for describing a long polling scheme presented in ETSI TS 102 690.

3 is a diagram for explaining an M2M service structure to which the present invention is applied.

4 is a view for explaining a schedule polling method according to an embodiment of the present invention.

5 is a diagram for describing a schedule polling method according to another exemplary embodiment of the present invention.

6 is a view for explaining a schedule polling method according to another embodiment of the present invention.

FIG. 7 is a diagram illustrating in more detail an M2M environment to which a scheduled polling method is applied.

8 is a diagram illustrating a schedule polling method according to the present invention.

9 is a diagram illustrating an example of an M2M resource structure when a schedule polling method according to the present invention is applied.

10 illustrates another example of an M2M resource structure when a schedule polling method according to the present invention is applied.

11 is a diagram illustrating an example of an M2M object implementing the schedule polling method according to the present invention.

Hereinafter, some embodiments of the present invention will be described in detail with reference to the accompanying drawings. In adding reference numerals to the components of each drawing, it should be noted that the same reference numerals are assigned to the same components as much as possible even though they are shown in different drawings. In addition, in describing the present invention, when it is determined that the detailed description of the related well-known configuration or function may obscure the gist of the present invention, the detailed description thereof will be omitted.

In addition, in describing the component of this invention, terms, such as 1st, 2nd, A, B, (a), (b), can be used. These terms are only for distinguishing the components from other components, and the nature, order or order of the components are not limited by the terms. If a component is described as being "connected", "coupled" or "connected" to another component, that component may be directly connected or connected to that other component, but between components It will be understood that may be "connected", "coupled" or "connected".

Embodiments of the present invention will be described based on communication of things. As described above, the thing communication includes various fields, such as M2M, MTC, smart device communication, and thing-oriented communication, and will be described with reference to M2M. However, this description is not limited to M2M, but is applicable to all systems and structures that provide inter-device communication, that is, thing communication, and communication that occurs in these systems.

In addition, the IoT can be applied to various fields including smart meter, e-health, connected consumer, city automation, automotive application, and the like. .

FIG. 1 is a diagram illustrating a short polling scheme presented in ETSI TS 102 690.

As shown in the figure, the short polling method is an asynchronous communication between the M2M client and the server presented in ETSI TS 102 690, and the short polling method is a request and a request until a requested resource (Resource or Information or Data) is received. The response is repeated.

Thus, the delivery structure is simple, but the frequent requests and responses that occur until the actual resource is received cause significant M2M network traffic load.

FIG. 2 is a diagram illustrating a long polling scheme presented in ETSI TS 102 690.

The long polling method is asynchronous communication between M2M client servers presented in ETSI TS 102 690, in which the issuer is subscribed-to-SCL 30 and a notification channel through a Hosting SCL 20. It generates a (Notification channel) and requests a long polling through it and has a structure to receive a notification (notification) in response.

When the issuer, the requestor of the resource, requests long polling, the receiver, the server, finally sends a notification as a response.

After the notification channel is formed and long polling is requested, the notification server 30 does not separately transmit a response until a notification is made in response to the issuer's resource request. Issuer 10 also waits to receive the notification as a response. Therefore, there is an advantage that M2M network traffic load is smaller than short polling.

However, the long polling requested by the issuer has a certain time limit, so if the issuer does not receive the notification (notification of 011a of FIG. 2) within the time limit, the issuer is not long polled. Request again to repeat the steps 004a ~ 010 shown in Figure 2 from scratch.

Therefore, if the notification is delayed, network traffic load will eventually be caused.

In addition, in this case, after waiting for a certain time, the long polling (long polling) must be requested again, there is a problem that the actual communication is significantly delayed.

In addition, the long polling method is a complex structure that has a problem such as notification conflict because it must work in conjunction with the notification mechanism.

Meanwhile, the server (SCL), which collects and transmits data, collects data from M2M sensors in three ways: periodic reporting, on-demand reporting, and event-based reporting. There is. Here, the long polling method is suitable for event type data collection.

However, long polling is not suitable for periodic data collection because the data is collected at regular intervals due to the nature of the data. In addition, the long polling method is not suitable even when the notification may be delayed due to data collection conditions, such as when data is collected by an event method.

According to the present invention, there is proposed a scheduled polling method that is completely different from the short polling and long polling methods described above. According to the schedule polling method according to the present invention, the polling, that is, the request and transmission of data, may be performed in consideration of the data collection situation of the server that collects data.

The scheduled polling method according to the present invention can effectively compensate for the problems occurring in the short polling and long polling described above.

In particular, the scheduled polling method according to the present invention can drastically reduce traffic load in an M2M environment where a periodic collection of data or an event occurrence time can be predicted.

3 is a diagram illustrating an example of an M2M service structure to which the present invention is applied.

The network configuration of the present invention is applied in an environment that provides a function of accommodating a plurality of access networks in a device / gateway and an M2M core platform as the same structure as the existing M2M structure.

The M2M service structure is composed of a network and application domain shown in the right side of the figure and an M2M device domain shown in the left side of the figure.

The network / application domain accesses M2M M2M Service Capabilities (SC2 to SC8) 112, which is an M2M service capability, or provides an M2M application 111 and a core network to provide service logic. or B), M2M SCs (SC1 to SC8) 112.

In addition to the network / application domain, an access network (not shown) that enables communication with the M2M device domain, and M2M Management Functions (not shown) and Network Management Functions (not shown) C) may be further included.

Meanwhile, the M2M device domain includes an M2M device or an M2M gateway. In addition, the M2M device and the M2M gateway may include an M2M application 121 and may further include an M2M SC 122.

When the M2M device includes the M2M SC 122, the included M2M SC 122 may operate in the network / application domain for interworking and interconnection.

In addition, when the M2M device does not include the M2M SC 122, it may be interworking and interconnection in the network / application domain through an interface with the M2M SC included in the M2M gateway.

The M2M device may operate an M2M application to interwork and interconnect in the network / application domain through the M2M SC (Service Capabilities) of the M2M device or the M2M gateway in order to use the functions of the network domain.

Meanwhile, the M2M device may be connected to and operate with an M2M gateway through an M2M Area Network (not shown).

The M2M gateway includes an M2M SC and allows M2M devices to interwork and interconnect in the network / application domain.

Service Capabilities (SC) means providing functions shared by different applications, and M2M entities such as an M2M device, an M2M gateway, an M2M network domain, and the like may include one or more specific SCs.

The service capability layer (SCL) of such an M2M device or M2M gateway forms a specific interface with the service capability layer (SCL) of the network domain to communicate with each other and operate (interworking and interconnection).

In addition, SCs in a network domain may interface with one or a plurality of core networks. In this case, the functions of the core network may be used through a known interface according to other existing standards.

Hereinafter, a method of scheduled polling according to the present invention applied in the M2M environment as described above will be described in more detail with reference to the accompanying drawings.

In addition, as an embodiment in which the schedule polling method according to the present invention is implemented, (1) when collecting data through general periodic reporting, (2) the M2M sensor in the on-demand reporting (on-demand reporting) It also describes the case where a report cannot be reported immediately due to some obstacle, but the reporting period is fixed or when the reporting time is predictable, and (3) when the event occurrence time is predictable in event-based reporting.

Resources generated from an M2M device such as an M2M sensor in the thing communication are reported, stored, and managed in a service capability layer (SCL) reported by the corresponding M2M device.

In the schedule polling method according to the present invention, a local service capability layer (Local SCL) on the issuer side and a hosting service capability layer (Server SCL) of a server managing resources required by the issuer Layer is applied in different cases.

The issuer is an application or a service capability layer (SCL), for example, as described above, which receives a server that stores and manages the resource to access a resource required by the issuer, or a hosting SCL of the server. Send a request to.

If the issuer is a service capability layer, the request is sent directly to the server or hosting SCL via the local service capability layer (Local SCL), and the receiver sends a success or failure response. do.

On the other hand, even if the issuer is an application or service capability layer, if a relay SCL (Intermediate SCL) is separately involved in addition to the local SCL and the hosting SCL, that is, the local, the relay, and the hosting SCL are different from each other, the schedule polling method according to the present invention It is transmitted through a multihop scheme, for example, 2-hop.

In this case, the local SCL cannot communicate directly with the final recipient, the hosting SCL, so the issuer sends the request to the recipient SCL via the local SCL and the intermediate SCL registered by the local SCL, and the response is also reversed. It is passed through the issue language.

The schedule polling method according to the present invention is a very efficient method in terms of network resources and traffic when collecting data in a cyclic manner, for example, collecting data in an environment in which the reporting period from the M2M sensor changes from time to time.

Referring to FIG. 4, the issuer 210 transmits a request to read, retrieval or fetch a resource (data or information) (S311).

The issuer 210 may refer to an attribute of the corresponding request resource to prepare a request message for requesting transmission. In this case, the issuer 210 may transmit a request using the hosting SCL managing the request resource as a receiver without contacting any SCL.

In addition, the issuer 210 may include an address or link for storing a requesting resource, for example, a URI identifier and / or an access right to the requesting resource in the request message. To this end, the requestor 210 may retrieve a list of resources meeting a predetermined condition by using a resource discovery attribute "Discovery resource".

In addition, the issuer 210 may include the M2M ID of the hosting SCL managing the requested resource in the request message. Also, the issuer 210 may include search strings in the request message.

The server or hosting SCL 220 that receives the request checks schedule information about a reporting cycle or an update point of the requested resource (S313), and corrects a reporting cycle or the next update point, for example, the next time of the resource. In response to the received request by transmitting a message including schedule information about a resource such as time (S315).

The issuer 210 may maintain the offline or sleep state until the next schedule time according to the schedule information. Thereafter, the issuer 210 requests a resource according to the schedule information included in the received response, for example, by sending a new request message at the next modification time (S317) and accordingly, a server or a hosting SCL (Hosting SCL). 220 transmits the requested resource to the issuer 210 and responds (S319). At this time, after transmitting and receiving the response, the mutual communication between the issuer 210 and the hosting SCL 220 is terminated.

The issuer 210 may be an M2M device, an M2M gateway or an application of a M2M network domain (Device Application: DA, Gateway Application: GA, Network Application) or an SCL (Service Capability Layer) of each M2M object. . Also, as mentioned above, this issue can be a client.

In addition, the recipient SCL (Hosting SCL) 220 is a Service Capability Layer (SCL) that manages the resources requested by the Issuer 210, an M2M gateway that manages resources generated from a plurality of M2M devices or Service Capability Layer (SCL) of the M2M network. This recipient can be a server.

The recipient SCL 220, which is a receiver, receives a report on resource generation from a plurality of M2M devices and stores and manages a schedule for a report received from each M2M device.

Such a resource reporting schedule may include a reporting period (reportingInterval), a reporting start time (reportingStartTime) and the end time (reportingEndTime).

In order for the scheduled polling of the present invention to be effectively used in an M2M environment, Table B.59 <areaNwkDeviceInfoInstance> resource attribute described in ETSI TS 102 690 is used to set the resource reporting schedule of the corresponding resource as shown in Table 1 below. It may include.

Table 1

Resource attribute

AttributeName	Mandatory / Optional	Type	Description
expirationTime	M	RW	See clause 9.2.2.
accessRightID	M	RW	See clause 9.2.2.
searchStrings	M	RW	See clause 9.2.2.
creationTime	M	RO	See clause 9.2.2.
lastModifiedTime	M	RO	See clause 9.2.2.
originalMO	M	WO	See clause 9.2.3.22.
description	O	RW	the text-format description of this MO.
areaNwkID	M	RW	The reference to an <areaNwkInstance> which this device associates with.
sleepInterval	M	RW	The interval between two sleeps.
sleepDuration	M	RW	The time duration of each sleep.
status	M	RW	The status of the device (sleeping or waked up).
reportingInterval	O	RW	The interval for reporting to server
reportingStartTime	O	RW	The start time of reporting
reportingEndTime	O	RW	The end time of reporting

Referring to Table 1, the <areaNwkDeviceInfoInstance> resource attribute includes a reporting period, a reporting start time, a reporting start time, and an ending time.

9 illustrates an example of a resource structure applied in implementing a schedule polling method according to the present invention.

As another method for effectively utilizing scheduled polling of the present invention in an M2M environment, a <reportingSchedule> resource is configured as a sub-resource of Figure B.29 <areaNwkDeviceInfoInstance> resource described in ETSI TS 102 690 as shown in FIG. May be

At this time, the <reportingSchedule> resource or resources may be defined as shown in Table 2 below.

TABLE 2

<reportingSchedule> resource

AttributeName	Madatory / Optional	Type	Description
reportingScheduleID	M	RW	The identification of reporting schedule
reportingInterval	M	RW	The interval for reporting to server
reportingStartTime	M	RW	The start time of reporting
reportingEndTime	M	RW	The end time of reporting
sleepInterval	M	RW	The Interval between two sleeps of device
sleepDuration	M	RW	The time duration of each sleep of device
deviceStatus	M	RW	The status of the device (sleeping or wakeup)

Referring to Table 2, the <reportingSchedule> resource or resource is an ID (reportingScheduleID), reporting interval (reportingInterval), reporting start time (reportingStartTime), and reporting end time (ID) to identify the reporting schedule associated with the M2M device generating the requested resource. reportingEndTime, a time when the M2M device generating the requested resource is in a sleep state (sleepDuration), a sleep interval occurrence time of the M2M device, a sleep or wakeup state of the M2M device ( deviceStatus) and the like. In addition, these attributes can be both read and write.

The schedule polling method according to the present invention is very efficient when the M2M sensor cannot report immediately due to an unspecified failure, for example, in on-demand reporting. .

Referring to FIG. 5, the issuer 210 transmits a request to receive or fetch a resource (data, information, or resource) (S321).

In this case, when the M2M device generating and reporting the requested resource becomes impossible to report due to various failures such as battery discharge and network failure (S323), the server or hosting SCL 220 that receives the request may determine the resource. A schedule such as a reporting period or an update time point is checked, or various information according to a situation of a failure is examined to predict a schedule such as a next report time point (S325).

Accordingly, the server or hosting SCL 220 transmits a message including the confirmed or predicted schedule information and responds to the received request (S327).

The issuer 210 may maintain the offline or sleep state until the next schedule time according to the schedule information. Thereafter, the issuer 210 requests the resource according to the schedule information included in the received response (S329). When the M2M device 230 generates and reports the resource according to the schedule information (S331), the server accordingly Alternatively, the hosting SCL 220 transmits the requested resource to the issuer 210 and responds (S333). At this time, after transmitting and receiving the response, the mutual communication between the issuer 210 and the hosting SCL 220 is terminated.

Here, the issuer 210 is an M2M device or an application of an M2M gateway or an M2M network domain (Device Application: DA, Gateway Application: GA, Network Application: NA) or SCL (Service Capability) of each M2M object. Layer).

This type of issuer can also be a client. The server or hosting SCL 220 is a Service Capability Layer (SCL) having resources requested by the Issuer 210 as described above, and includes a plurality of M2M devices 230 such as sensors. It may be an M2M gateway or a Service Capability Layer (SCL) of an M2M network that stores and manages resources generated from the network.

6 is a diagram for describing a schedule polling method according to another exemplary embodiment.

The schedule polling method of the present invention can be efficiently implemented even when an event occurrence time is predictable in, for example, event-based reporting.

Referring to FIG. 6, when the hosting SCL 220 is an object different from a subscribed-to-SCL 240 that is a notification server or a server managing a requested resource, The issuer 210 is a notification channel to a subscribed-to-SCL 240 via a relay server or a hosting SCL 220 that creates and manages a notification channel. (Notification Channel) should be formed.

This process is applied to the case where the issuer 210 subscribes to a resource.

To this end, the issuer 210 requests creation of a notification channel resource with a subscribed-to-SCL 240 through a hosting SCL 220 that creates and manages a notification channel. (S341).

Accordingly, the relay server or hosting SCL 220 generates a notification channel resource (S343) and requests schedule information from the subscribed-to-SCL (240) (S345).

The subscribed-to-SCL 240 checks the schedule information (S347) and transmits a message including the confirmed schedule information to the relay server or the hosting SCL 220 (S349). The received relay server or hosting SCL 220 transmits a message including the received schedule information to the issuer 210 and responds (S351).

In this case, the subscribed-to-SCL 240 and the relaying hosting SCL 220 may transmit a response indicating that there is no schedule information without the confirmed schedule information.

Upon receiving the response to the request for the schedule information, the issuer S353 may transmit the resource request to the hosting SCL 220 according to the corresponding schedule when the schedule information for the requested resource exists in the corresponding response message (S353). S357).

Accordingly, the hosting SCL 220 forwards the received request to the subscribed-to-SCL 240 and transfers the resource from the subscribed-to-SCL 240. When a response including the received message is received (S361), it is transmitted to the issuer 210 (S363).

On the other hand, if schedule polling cannot be applied, such as when there is no schedule information included in the response received in step S351 or when the next update schedule cannot be checked, the issuer 210 selects a long polling method and then selects a long polling method. A resource may be requested by performing the steps 004a to 011b shown (S355).

On the other hand, when a notification channel is formed, a notification channel resource described in ETSI TS 102 690 may be configured as shown in Table 3 below to support a schedule polling scheme.

TABLE 3

Notification channel resource attribute

AttributeName	Mandatory / Optional	Type	Description
channelType	M	RW	The type of the notification Channel. longpolling or schdeduledPolling are supported
contactURI	M	RO	The URI that is used in subscriptions.
channelData	M	RO	The data associated with the channel. If longPolling, the longPolling URI is displayed. If schdeduledPolling, the schedule time is displayed.
creationTime	M	RO
lastModifiedTime	M	RO

Referring to Table 3, a notification channel resource (notificationChannel) attribute includes a channel type (ChannelType), a contact URI (contactURI) used at registration, channel data including data related to a generated notification channel (channelData), and a channel creation time (creationTime). And lastModifiedTime.

In this case, channel data may include a long polling URI when the long polling method is performed, and may include schedule time information when the schedule polling method is performed.

In addition, when scheduled polling of the present invention is utilized in a long polling procedure, Table 9.59 <notificationChannel> resource attributes described in ETSI TS 102 690 may be configured as shown in Table 4 below. .

Table 4

Notification channel resource attribute

AttributeName	Mandatory / Optional	Type	Description
channelType	M	RW	The type of the notification Channel. Currently onlylongPolling is supported.
contactURI	M	RO	The URI that is used in subscriptions.
channelData	M	RO	The data associated with the channel. The type of data may differ depending on the channelType.For the longPolling channelType, the channel Dataincludes a URI on which the client can do the longpolling request in order to get the notifications that were sent to the contactURI.
creationTime	M	RO	See clause 9.2.2 Common attributes.
lastModifiedTime	M	RO	See clause 9.2.2 Common attributes.
nextScheduledTime	O	RW	The scheduled time on which the next notification will be sent

Referring to Table 4, the notificationChannel resource attribute includes a ChannelType indicating that it supports long polling, a contact URI used during registration, channel data including data related to the generated notification channel, and a channel. It may include schedule information including a creation time (creationTime), a last modified time (lastModifiedTime) and a time (nextScheduledTime) scheduled to be sent the next notification.

In this case, the channel data may vary depending on the channel type, and may include a URI for requesting long polling to obtain a notification transmitted to a contact URI used for registration when the long polling scheme is performed.

10 illustrates another example of a resource structure applied in implementing a schedule polling method according to the present invention.

As another method for effectively utilizing the scheduled polling of the present invention in an M2M environment, a <reportingSchedule> resource may be added as a sub-resource of FIG. 9.35 <notificationChannel> resource structure described in ETSI TS 102 690 as shown in FIG. It may be.

At this time, the <reportingSchedule> resource or resource including the reporting schedule information may be defined as shown in Table 3 above.

Referring to the drawings, M2M devices 440 such as various sensor nodes such as pollution measurement, wind measurement, solar panel, and thermometer measurement are used to measure pollution, wind speed / wind direction. In an M2M environment where measurements, solar energy observations, temperature, etc. are measured and the measurement data is periodically reported to the SCL 430,

① When a specific network application (NA) 410 needs wind speed data and becomes an issuer at 13:42 and requests a resource to the corresponding SCL 430 (S511), ② the corresponding SCL 430 is a reporting schedule (reporting schedule). Since the period of reporting the wind speed data of the wind speed measuring device D2 440 by checking the resource is 1 hour, it can be seen that the wind speed measuring device 440 will report again at 14 o'clock next time. The network application (NA) 410, which is an issuer, is informed that the scheduled update time of the wind speed data is 14:00 (S513).

③ After that, the wind speed measuring device D2 440 updates the wind speed data at 14:00 (S515), and ④ the network application (NA) 410 requests the wind speed data again at 14:00 to obtain data (S517).

For this process, the SCL 430 managing the resources reported from the M2M devices 440 generates a reporting schedule including a reporting period of each M2M devices 440, for example, as shown in the reporting schedule table shown in FIG. Can be stored in the form.

In the drawing, after receiving a response to a request according to a schedule polling method, the issuer does not repeat the resource request but maintains the resource at a scheduled time while remaining offline or sleeping until a scheduled update time of the data included in the response message. You can ask for data.

Therefore, it is possible to prevent network resource waste and congestion due to continuous repetition of requests and responses as in the short polling scheme, thereby enabling efficient use of network resources.

In addition, according to the scheduled polling method according to the present invention, when a periodic reporting M2M environment or a resource reporting time is predictable, a separate notification channel is not required, such as a long polling method, and resources are not required. It can be seen that the message exchange process for obtaining is an excellently simple and efficient method.

When the issuer 610 sends a request to receive or fetch a resource (S711), a server or a hosting SCL (620) that is the receiver of the request is received. Checks the schedule for the reporting period or the update time of the resource (S713).

To this end, the server or hosting SCL 620 that receives the request sent by the issuer 610 to retrieve the information or resource may determine that the requested resource is based on information based on heuristics or actual implementation. You can decide when that time will be corrected next time.

As an example of the rule of thumb, the scheduled polling method according to the present invention may use the occurrence prediction time as the schedule information in the event method whose event occurrence time is predictable. The event occurrence time can be predicted by, for example, accumulating the year / month / weekly / daily event occurrence time data in a hosting SCL and calculating the average event occurrence time data.

Therefore, the server or hosting SCL 620 that receives the request responds to the received request by transmitting a message including information on the reporting period or the next update time (S715).

Also, even when the issuer 610 subscribes to or subscribes to a resource through a notification channel creation method, when the next notification of the resource is predicted when the next notification is to be transmitted, the next notification prediction time and The same prediction schedule indication information may be included in the notification message.

Therefore, whether a simple resource request or a notification channel is created, the issuer 610 may remain offline or sleep until the next scheduled time according to this information, and thus, the battery operated device may be maintained. In this case, battery savings can be achieved.

However, when the notification channel is generated, if the requested resource is modified before the displayed schedule time, the wakeup mechanism may be performed to the device or gateway, which is the issuer 610, for example.

Thereafter, the issuer 610 may transmit a new request for requesting a resource according to the schedule information included in the received response (S717). Accordingly, the server or hosting SCL (620) that receives the request may transmit the new request. Responds by sending the requested resource to the issuer 610 (S719). At this time, after transmitting and receiving a response, mutual communication between the issuer 610 and the hosting SCL 620 is terminated.

The scheduled polling method according to the present invention can handle the data more efficiently than the long polling method when collecting data through the periodic method, and in particular, the data in an environment where the reporting period from the M2M sensor is changed from time to time. It is very efficient when collecting. Periodic data collection is widely used in applications such as smart metering, eHealth, and city automation.

In addition, the scheduled polling method according to the present invention can be efficiently used even in an event method where an event occurrence time can be predicted. As the event occurrence time can be predicted, the average event occurrence time data can be predicted after accumulating the year / month / weekly / daily event occurrence time data in the hosting SCL.

In addition, the scheduled polling method according to the present invention can be used efficiently when the M2M sensor cannot report immediately due to an obstacle in on-demand reporting, but the reporting period is set or the reporting time point is predictable. Can be.

In addition, the scheduled polling method according to the present invention is simple to implement the message transmission structure.

11 is a diagram illustrating a configuration of an M2M object according to an embodiment of the present invention.

In the drawings, the elements for implementing the schedule polling method according to the present invention are shown.

The illustrated M2M objects may be implemented to operate as M2M devices, M2M gateways or M2M network domains, respectively.

Referring to the drawings, the M2M object includes an M2M application module 121, an M2M service capability module 122, and a communication module 125.

In the drawing, the M2M application module 121 and the M2M service capability module 122 are shown as being implemented as separate elements, but each of them may be implemented as a separate processor or may be implemented in one processor.

The M2M application module 121 and the M2M service capability module 122 operate in interoperation with each other and may collectively control device elements in the M2M object to implement a schedule polling function according to the present invention. In this case, the M2M application module 121 and / or the M2M service capability module 122 may be implemented as the integrated control unit or the M2M service module 123 and may be implemented as one processor.

In order to implement the schedule polling method, the M2M application module 121 and the M2M service module 122 collect a request and response message for collecting and transmitting information on an M2M object which is a target of receiving a request or an M2M object which has transmitted a request. And control the communication module 125 to transmit and receive the above-described request message and to transmit and receive the above-described response message.

In addition, the M2M application module 121 and the M2M service module 122 interpret the received message, extract necessary information, and stop the transmission of a predetermined time message according to the schedule information. As a result, battery-operated devices can achieve battery savings.

In addition, when the M2M object is implemented as a hosting SCL, the M2M application module 121 and the M2M service module 122 perform a function of analyzing information received from various connected M2M devices and storing them as resources.

Meanwhile, the communication module 125 performs interconnection to perform M2M communication between M2M objects and is connected through an existing area network or core network. The communication module 125 may be configured to provide this functionality by using IEEE 802.15.1 [i.3], Zigbee, Bluetooth, IETF ROLL, ISA100.11a, or local networks such as PLC, M-BUS, Wireless M-BUS, and KNX. Alternatively, it may be equipped with an area network communication module and / or core network communication modules such as xDSL, HFC, satellite communication, GERAN, UTRAN, eUTRAN, W-LAN and WiMAX.

The above description is merely illustrative of the technical idea of the present invention, and those skilled in the art to which the present invention pertains may make various modifications and changes without departing from the essential characteristics of the present invention. Therefore, the embodiments disclosed in the present invention are not intended to limit the technical idea of the present invention but to describe the present invention, and the scope of the technical idea of the present invention is not limited thereto. The protection scope of the present invention should be interpreted by the following claims, and all technical ideas within the equivalent scope should be interpreted as being included in the scope of the present invention.

CROSS-REFERENCE TO RELATED APPLICATIONCROSS-REFERENCE TO RELATED APPLICATION

This patent application is filed with Korea Patent Application No. 10-2012-0053883 filed in Korea on May 21, 2012 and Patent Application No. 10-2012-0074045 filed in Korea on July 06, 2012 and July 2012 Patent Application No. 10-2012-0078606, filed in Korea on 19th, and Patent Application No. 10-2012-0084932, filed in Korea, on Aug. 2, 2012 and Patent application, filed in Korea, on November 5, 2012 Claims No. 10-2012-0124057 are issued pursuant to United States Patent Act Section 119 (a) (35 USC § 119 (a)), all of which are incorporated herein by reference. In addition, if this patent application claims priority for the same reason for countries other than the United States, all its contents are incorporated into this patent application by reference.

Claims

In an M2M object acting as a client,

Transmitting a request to receive M2M resources managed by a separate M2M object operating as a server;

Receiving a response including schedule information related to the M2M resource management from the server; And

And transmitting a new request for receiving the M2M resource according to the schedule information.
The method of claim 1,

And the schedule information includes a next modification time of the M2M resource.
The method of claim 2,

In the new request transmission step according to the schedule information, the schedule polling method, characterized in that for transmitting the new request at the next modification time.
The method of claim 3, wherein

And the M2M object operating as a client remains offline or sleeps until the next modification time.
The method of claim 1,

The schedule information is determined by the separate M2M object operating as a server.
The method of claim 1,

If the M2M object acting as a client subscribes to the resource, it receives a notification message in response to the resource request and the notification message includes an indication of a predicted schedule time at which the next notification message will be sent. A schedule polling method characterized by the above.
The method of claim 6,

And the M2M object operating as a client maintains an offline or sleep state until a schedule time at which the next notification message is to be transmitted.
The method of claim 1,

And after the response receiving step, mutual communication between the M2M objects is terminated after transmitting and receiving a new request and a response thereto according to the schedule information.
M2M which creates a request to receive M2M resources managed by a separate M2M object operating as a server and extracts schedule information related to M2M resource management from the response when a response is received from the separate M2M object to the request. module; And

A communication module for transmitting the request made by the controller and receiving the response to the request,

The M2M module generates a new request for receiving the M2M resources according to the schedule information and transmits through the communication module.
The method of claim 9,

The schedule information includes a next modification time of the M2M resource, and the M2M module transmits the new request through the communication module according to the next modification time.
The method of claim 10,

The M2M device is characterized in that the M2M device to maintain the offline or sleep state until the next modification time.
The method of claim 9,

The M2M module receives a notification message as a response to the resource request when the M2M module subscribes to the resource, and the notification message includes an indication of a predicted schedule time at which a next notification message will be sent. .
The method of claim 12,

The M2M module, characterized in that the M2M device to maintain the offline or sleep state until the scheduled time to send the next notification message.
The method of claim 9,

After receiving the response, the M2M module M2M device characterized in that after the transmission and reception of the new request and the response according to the schedule information with the server through the communication module.
In an M2M object acting as a server,

Receiving an M2M resource transfer request from a separate M2M object acting as a client;

Transmitting a response including the next modification schedule time of the M2M resource or a prediction schedule time at which a next notification message is to be transmitted to the client; And

Receiving a new transmission request for the M2M resource from the client according to the schedule time information.