WO2018066917A1

WO2018066917A1 - Method for receiving response message in m2m system, and device therefor

Info

Publication number: WO2018066917A1
Application number: PCT/KR2017/010925
Authority: WO
Inventors: 정원철
Original assignee: 주식회사 케이티
Priority date: 2016-10-07
Filing date: 2017-09-29
Publication date: 2018-04-12

Abstract

The present invention relates to a machine to machine (M2M) communication technology, and to a method by which an M2M device transmitting a request message receives a response message for the corresponding request message without an error, and a device therefor. According to one embodiment, a method by which an M2M communication device receives response information comprises the steps of: transmitting a request message; confirming a response type parameter set for the request message; transmitting an inquiry message inquiring about a processing result of the request message, when the response type parameter is set as a synchronous nonblocking (nonBlockingRequestSynch); and receiving a response message including the processing result in response to the inquiry message, wherein the inquiry message is set as a fixed response type parameter.

Description

Method and apparatus for receiving response message in M2M system

The present disclosure relates to a Machine to Machine Communication (M2M) technology, and relates to a method and an apparatus for an M2M device transmitting a request message without error receiving a response message to the request message.

M2M, "Machine to machine communication" or MTC, "Machine type communication" or smart device communication, "Smart Device communication" or "Machine oriented communication" or the Internet of Things, "Internet of Things" is a human communication process Refers to all communication methods in which communication is performed without intervening. Recently, there has been a discussion about M2M in oneM2M, but technical elements that satisfy the architecture and requirements of oneM2M have not been presented.

Since MOT typically does not directly perform communication and application control, there is a need for transmitting and receiving methods and procedures in order to exchange messages between objects. In addition, there is a need for a protocol for smooth message exchange between M2M devices.

In particular, a procedure for transmitting and receiving a message may be set differently for each M2M device, and the M2M device transmitting the request message may set a specific response type in order to receive a response message according to the transmission and reception procedure supported by the corresponding M2M device. However, in this case, the M2M device generating the response message may not support the corresponding response type or may not be able to exchange messages normally due to a problem of the message transmission / reception procedure according to a specific response type.

The present embodiment devised in the above-described background is to propose a specific method and apparatus for preventing a response message not received error that may occur when the M2M device transmits a request message by setting a specific response type.

According to an embodiment of the present invention, a method of receiving a response information by a machine to machine communication (M2M) device includes transmitting a request message, checking a response type parameter set in the request message, and response type. If the parameter is set to synchronous nonblocking (Sync NonLockingRequestSynch), the method includes transmitting an inquiry message for querying the processing result for the request message and receiving a response message including the processing result in response to the inquiry message. The message provides a method characterized in that it is set with a fixed response type parameter.

In addition, an embodiment of the present invention provides a machine to machine communication (M2M) apparatus for receiving response information, comprising: a transmitter for transmitting a request message, a controller for confirming a response type parameter set in the request message, and a query result of the request message; And a receiving unit for receiving a response message including the processing result in response to the inquiry message, wherein the transmitting unit receives the inquiry message for inquiring the processing result for the request message when the response type parameter is set to synchronous nonblockingRequestSynch. Further transmit, the inquiry message is set to a fixed response type parameter.

The present embodiment described above provides an effect of preventing a problem in that the response message is not normally received when the M2M device transmits a request message set to a specific response type.

In addition, the present embodiment provides an effect of preventing unnecessary resource waste of the receiving M2M device that may occur when the M2M device transmits a request message set to a specific response type.

1 is a diagram illustrating an M2M system from a high level functional point of view.

2 is a diagram illustrating in more detail an M2M system configuration diagram according to an embodiment.

3 is a diagram exemplarily illustrating a procedure of transmitting a request message and corresponding response information in an M2M system.

4 is a diagram illustrating a general processing procedure in a receiving M2M device receiving a request message.

5 is a diagram illustrating an operation of receiving response information by a transmitting side M2M device according to an embodiment.

6 is a diagram illustrating an operation of receiving response information by a transmitting side M2M device according to another embodiment.

FIG. 7 is a diagram illustrating a message flow when a response type parameter of an inquiry message is set to blockingRequest according to an embodiment.

8 is a diagram illustrating a message flow when the response type parameter of an inquiry message is set to synchronous nonblockingRequestSynch according to another embodiment.

9 is a diagram illustrating a message flow when a response type parameter of an inquiry message is set to asynchronous nonblocking (nonBlockingRequestAsynch) according to another embodiment.

10 is a diagram for describing an operation of an M2M device, according to an exemplary embodiment.

11 is a diagram illustrating a procedure for transmitting a request message according to a response type parameter setting according to an embodiment.

12 is a diagram illustrating a configuration of an M2M device according to an embodiment.

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. IoT can be variously referred to as Machine to Machine communication (M2M), Machine Type Communication (MTC), Internet of Things (IoT), Smart Device Communication (SDC), or Machine Oriented Communication. Can be. Recently, oneM2M has presented many technical matters related to IoT. The thing communication refers to various communication in which a communication is made without a person intervening in a communication process. IoT is the energy sector, the enterprise sector, the healthcare sector, the public services sector, the residential sector, the retail sector, the retail sector, the transportation sector, and others. It is divided into fields. The present invention includes the above fields, and can be applied to other fields.

1 illustrates an M2M system according to an embodiment from a high level functional perspective.

Application Entity (AE) 110 provides application logic for an end-to-end M2M solution. For example, it may be a collective tracking application such as a vehicle, a remote blood sugar monitoring application, or a remote power metering and controlling application. (AE): Application Entity provides Application logic for the end-to-end M2M solutions.Examples of the Application Entities can be fleet tracking application, remote blood sugar monitoring application, or remote power metering and controlling application.). The common service entity (CSE) 120 is a set of service functions, and these service functions are functions commonly used in an M2M environment. This service function is exposed to other functions through Reference Points Mca and Mcc, and uses the base network service using the reference point Mcn. For example, data management, device management, M2M subscription management, location service, etc. may be used. The subfunctions provided by the CSE can be logically understood as Common Service Functions (CSFs). Some of the CSFs in the CSE of the oneM2M node may be mandatory and some may be optional. Similarly, sub-functions within the CSF may be mandatory or optional.

Underlying Network Services Function (NSF) 130 provides a service to a common service entity. Examples of services include device management, location services and device triggering.

Reference Points are supported by Common Service Entities (CSEs). Mca Reference Points are reference points that direct the flow of communication between an Application Entity and a Common Service Entity. The Mcc reference point is a reference point that directs the flow of communication between two common service entities. The Mcn reference point is a reference point that directs the flow of communication between the common service entity and one network service entity.

More specifically, the Mca reference point allows one application entity (AE) to use the services supported by the common service entity. Services provided through the Mca reference point are dependent on the functionality provided by the common service entity, and the application entity and the common service entity can exist in the same physical entity or in separate physical entities. The Mcc reference point makes such use available to common service entities that wish to use the services of other common service entities that provide the necessary functionality. Services provided through the Mcc reference point depend on the functionality provided by the common service entity. Mcc reference points may be supported between different M2M nodes. The Mcn reference point enables such use for common service entities that wish to use service entities in the underlying network that provide the necessary functionality, which provides services other than transport and connectivity. An instance of the Mcn reference point is implemented dependent on the services provided by the underlying network. Information exchange between two physical M2M nodes may use transport and connectivity services of an underlying network providing basic services.

In this specification, a common service entity may be described as a CSE, and a network service entity may be described as an NSE. In addition, the M2M device in the present specification may mean a CSE or AE, or may mean a device including the CSE or AE.

Referring to FIG. 2, an infrastructure node 250 performs a server function essential for providing M2M communication. The base node 250 is composed of a base node application entity (AE) 252 and a base node common service entity (CSE) 254. The base node common service entity 254 is configured using resources as shown in FIG. 3 to be described below. 252 and 254 are distinguished through Mca reference points, and are required for MSOs, especially request messages for creating, deleting, updating, retrieving, and notifying scheduler resources. It is used to construct and process response messages.

The relay node 200 relays M2M communication or Internet of Things, IoT communication functions of the application service node 220 and the base node 100. The relay node 200 includes a relay node application object 202 and a relay node common service object 204. The relay node common service entity 204 is configured using the resources shown in FIG. 202 and 204 are distinguished using Mca reference points, and 254 and 204 are distinguished using Mcc reference points, and messages necessary for MOT communication, in particular, create, delete, update, and Used to construct and process request and response messages to retrieve and notify.

The application service node 210 may be composed of an application object 212 and a relay node common service object 214. The application object 212 handles application functions required for the purpose of the device. The common service object 214 of the application service node 210 is configured using the resources shown in FIG. 212 and 214 are distinguished by Mca reference points, and 214 and 254 are distinguished by Mcc reference points, and messages necessary for MOT, in particular, create, delete, update, and Used to construct and process request and response messages to retrieve and notify. On the other hand, the application service node 220 may perform a thing communication function with the base node 100 through the relay node (200). The difference between 210 and 220 is that the communication interface constituting the node is different. For example, 220 communicates with 100 through 200 using an interface capable of ultra short-range communication such as Bluetooth, ZigBee, Zwave, and WiFi. In contrast, 210 communicates with 100 using communication interfaces such as 3G, LTE, Ethernet, Gigabit Ethernet, and ADSL.

The application-only

nodes

230 and 240 do not have a common service object, and are intended to communicate with only the application object 242. 230 communicates with 100 using communication interfaces such as 3G, LTE, Ethernet, Gigabit Ethernet, and ADSL, and 240 communicates with 100 using ultra-short range communication such as Bluetooth, ZigBee, Zwave, and WiFi. Communicate with

As described in FIG. 2, the M2M system may be configured with at least one or more of a base node, a relay node, an application service node, and an application-only node, and each node may be configured to include a CSE or an AE. The CSE and the AE may communicate with other CSEs or AEs through their respective reference points.

Referring to FIG. 3, the initiator 300 transmits a request message to obtain necessary information (S320). The request message may include required and optional parameters. For example, the sending side parameter, the receiving side parameter, the request identification parameter and the operating parameter are included as essential parameters. The sender parameter includes information about the originator sending the message, and the receiver parameter includes information about the receiver receiving the message. The request identification parameter contains unique ID information for identifying the corresponding request message. In addition, the operation parameter includes information for identifying the operation requested in the request message. The operation parameter may be set to any one of creation, inquiry, deletion, update and notification.

The receiver 310 receives the request message, generates a response message, and transmits the response message to the originator 300 (S340). However, the receiver 310 may have a different procedure for transmitting a response message according to the setting. Alternatively, the response message may be received in another procedure according to the response type parameter included in the request message. That is, the procedure for transmitting the response message after the receiver 310 receives the request message may be different.

Therefore, the originator 300 proceeds with the general procedure for receiving the response message according to the response message processing procedure of each receiver 310 (S330). For example, the originator 300 may check the response type parameter of the request message and receive the response message in a different procedure for each response type parameter.

The present embodiments relate to a method and procedure for transmitting response information of a receiver to a request message in an M2M system which is essential for preventing an error from occurring.

For example, usage information such as electricity, gas, and water in a house or apartment is provided through a communication of things on a monthly or regular interval. To do this, information must be collected from the electricity meter, gas meter, water meter, etc. and transmitted. In addition, various applications such as energy, enterprise, medical, public service, residential, retail, transportation, and transportation can be applied to MOT, and various MOT applications may be presented as shown in Table 1, but are not limited thereto. .

In the present embodiment, when transmitting and receiving information between M2M devices of various fields, a procedure for receiving response information according to the response type of an individual M2M device or an individual request message may be provided to differentiate the transmission and reception of response information. This is to prevent the occurrence of an error.

Meanwhile, the originator, the receiver and the forwarder in the present specification may both be M2M devices, and describe the M2M device transmitting the request message as the originator, the M2M device receiving the request message and generating and transmitting the response information. It may be described as, and may be described by describing the M2M device for transmitting the request message, such as Transit CSE, the term may be changed as necessary. In addition, as described above, the M2M device may mean CSE or AE, or may mean a device including at least one of CSE and AE. In addition, the request message in the present specification may mean a request primitive, the response message may mean a response primitive.

However, hereinafter, for convenience of understanding, a description will be given of a transmitting M2M device that transmits or transmits a request message, and a CSE will be described as an example of the transmitting M2M device.

The M2M device may generate a request message and transmit the request message to a specific M2M device. If necessary, the request message may be delivered to the hosting M2M device which is the destination of the request message via the delivery M2M device. However, each M2M device may be limited to a supportable communication scheme. Or, as needed, the M2M device may selectively limit the communication scheme. Therefore, a receiving side M2M device (for example, a hosting CSE) that receives and processes a request message performs a different procedure for processing the request message according to each communication scheme.

Hereinafter, a procedure of processing a request message by the receiving M2M device for each communication scheme according to an embodiment of the present disclosure, and a detailed embodiment of a procedure of receiving a response message to the request message by the sending M2M device will be described. Explain. In addition, a case in which an error may occur with respect to a request message set in a specific communication scheme and a specific embodiment for solving the same will be described with reference to the accompanying drawings. The aforementioned communication scheme may be included in the request message and transmitted through the response type parameter.

Referring to FIG. 4, when the request message is received, the M2M device checks the validity of the received request message (S400). The request message may include at least one of an operation parameter, a receiving side parameter, a transmitting side parameter, and a request identification parameter.

When the validity check for the request message is completed, the M2M device checks the response type parameter for the request message (S405_. For example, the response type parameter may be included in the request message. The response type parameter may be set according to a procedure for receiving response information about a message, for example, blocking, synchronous nonblockingRequestSynch, asynchronous nonBlockingRequestAsynch, and flexBlocking. The response type parameter may not exist, or if the response type parameter does not exist, the processing may be performed in a blocking manner.

The M2M device may process response information on the request message through different procedures according to the response type parameter checked in step S405.

For example, when the response type parameter does not exist or is set to blocking, the M2M device performs a resource handling procedure for processing the request based on the parameter included in the request message (S450). For example, when the content requested in the request message indicates an inquiry about specific data, the M2M device may search for the specific data. Alternatively, when the content requested in the request message is the generation, deletion, or update of specific data, the M2M device may perform the operation of generating, deleting, or updating the specific data. This operation is described as a resource handling procedure.

As another example, the M2M device generates the request resource when the response type parameter is set to asynchronous nonblocking (S410). When the request resource for processing the request message is successfully generated, the M2M device generates a response (S415) and transmits a response message (S420). Thereafter, the M2M device performs a resource handling procedure for processing the request based on the parameter included in the request message (S425). For example, when the content requested in the request message indicates an inquiry about specific data, the M2M device may search for the specific data. Alternatively, when the content requested in the request message is the generation, deletion, or update of specific data, the M2M device may perform the operation of generating, deleting, or updating the specific data. This operation is described as a resource handling procedure. When the resource handling procedure according to the request message is completed, the M2M device updates the generated request resource (S430). Thereafter, the M2M device completes resource handling according to the request message, and transmits a request message including notification information to the originator that the result is stored in a specific request resource (S435). The M2M device waits for a response message from the originator (S440).

As another example, when the response type parameter is set to synchronous nonblocking, the M2M device generates a request resource (S460). When the request resource for processing the request message is successfully generated, the M2M device generates a response (S465), and transmits a response message (S470). Thereafter, the M2M device performs a resource handling procedure for processing the request based on the parameter included in the request message (S475). For example, when the content requested in the request message indicates an inquiry about specific data, the M2M device may search for the specific data. Alternatively, when the content requested in the request message is the generation, deletion, or update of specific data, the M2M device may perform the operation of generating, deleting, or updating the specific data. This operation is described as a resource handling procedure. When the resource handling procedure according to the request message is completed, the M2M device updates the generated request resource (S480). In this case, the originator who sent the request message transmits an inquiry request message for receiving response information to the receiver. The inquiry request message may be transmitted when a predetermined period or a predetermined time has elapsed. The originator receives the inquiry response message for the inquiry request message after sending the inquiry request message. The inquiry response message may essentially include a response status code parameter, a request identification parameter, and a content parameter. When an inquiry response message is received, the originator checks the response status code parameter or content parameter included in the inquiry response message, resends the inquiry request message according to whether the response information is included, extracts the response information from the inquiry response message, or receives an error. Processing can be performed.

In summary, the M2M device may transmit the response information according to the response type parameter, receive the inquiry request message at regular intervals, transmit the response information, or transmit the notification request message and wait for the response message. The response information receiving procedure is classified according to the response type parameter, and in processing the request message, the M2M device may identify the response type parameter and may perform each procedure.

In addition, the response type parameter may be set to flex blocking. flexblocking indicates that the receiving M2M device can dynamically determine the response type parameter. That is, the receiving side M2M device that receives the flexblocking response type parameter may select the response type parameter according to the setting or convenience of the receiving side M2M device.

As such, the M2M device receiving the request message processes the received request message through a different procedure according to a communication method, and transmits response information thereto.

On the other hand, the sending M2M device (originator) that sent the request message may also receive the response message in a different procedure according to the communication method. Hereinafter, a specific method of receiving a response message for a request message based on a communication method in which the transmitting M2M device is divided according to the response type parameter will be described in two embodiments.

First embodiment

Referring to FIG. 5, the M2M device configures a request message in performing communication (S500). The request message essentially includes parameters such as an operation, a receiver, a initiator, a request identifier, and the like.

Operation parameters indicate information about operations to be processed by the receiver, such as creation, inquiry, update (update), deletion, and notification. As an example, when the operation parameter is information for creating a schedule, the request message includes a content parameter and a response type parameter. As another example, when the operation parameter is information for updating or notifying, the content parameter is included. As another example, when the operation parameter is Retrieve information, the content parameter may be included. The receiver (To) parameter indicates an application object or a common service object that receives a request message. The From parameter represents an application object or a common service object that generates and sends a request message. The Request Identifier parameter is information for uniquely identifying a request message.

The M2M device transmits the request message configured in step S500 to the receiver (S505). The request message essentially includes parameters such as an operation, a receiver, a initiator, a request identifier, and the like.

The M2M device waits for a response message from the receiver (S510). The response message essentially includes the "Response Status Code" parameter and the "Request Identifier" parameter. The information of the “Request Identifier” parameter should be the same as the “Request Identifier” parameter in step S505.

After receiving the response message, the M2M device checks the information of the response type parameter (S515). The response type parameter may be indicated by any one of blockingRequest, synchronous nonblockingRequestSynch, and asynchronous nonblockingRequestAsynch, or the response type parameter may not exist. If the response type parameter does not exist, the blocking procedure is performed.

As an example, when the information of the response type parameter is a blocking request, the M2M device processes the response message (S570).

As another example, when the information of the Response Type parameter is synchronous nonblockingRequestSynch, the M2M device receives an acknowledgment message from the receiver. This is a method that indicates that the receiver does not immediately process the request message or, if there is any reason, the receiver is processing the request message of the M2M device, and only the M2M device can start communication. The M2M device sends an inquiry message after a predetermined time or a predetermined time in order for the receiver to know whether the request message is completed (S520). For example, the inquiry message essentially includes the parameters "Operation", "To", "From", and "Request Identifier". Operation parameters are set to Retrieve.

The M2M device receives the response message of the receiver for the inquiry message (S525). If the receiver has processed the request message of step S505, the receiver's response message essentially includes the "Response Status Code", "Request Identifier" and "Content" parameters. The information in the “Request Identifier” parameter should be the same as the “Request Identifier” in the inquiry message. The information of the "Content" parameter includes response information (processing result) when the receiver processes the request message of step S505. If the receiver fails to process the request message of step S505, the receiver's response message essentially includes the "Response Status Code" and "Request Identifier" parameters.

The M2M device checks the "Response Status Code" parameter of the response message (S530). If the information of the “Response Status Code” parameter is successful (for example, code 2XXX), check the Content parameter, and if the Content parameter exists, determine as Success and perform step S535. For example, if the code of the response status parameter is 2000 (OK), 2001 (created), 2002 (deleted), or 2004 (changed), and there is a content parameter, step S530 is performed.

If the information of the "Response Status Code" parameter is information indicating the incomplete processing of the receiver (for example, Informational (1XXX) or Acknowledge), step S520 is performed. That is, after a certain time or at a certain time, the M2M device may retransmit the inquiry message.

If the information of the “Response Status Code” parameter fails, the M2M device determines that it is an error and terminates. For example, the M2M device determines that it is an error if the response status code parameter indicates originator error (4XXX) or receiving side error (5XXX) or network error (6XXX), and if the response status code is 2XXX but no Content parameter is present. Judging by the error.

The M2M device extracts the operation result (operation result) that the receiver responds using the response message. For example, the processing result may be included in the “operation result” attribute information of the <request> resource in the “Content” parameter. The <request> resource MUST contain the required attribute information. Essential attribute information is information on operation, target, originator, requestID, metaInformation, content, requestStatus, and operationResult attributes.

As another example, the M2M device receives an acknowledgment message of the receiver when the response type parameter constituting the request message is non-blockingRequestAsynch. This is a way of indicating that the receiver is processing the request message of the M2M device if the receiver does not immediately process the request message or if there is any reason, and applies when the M2M device or the receiver can start communication.

When the receiver completes processing of the request message, the receiver sends a notification request message to the M2M device, and the M2M device receives the notification request message (S540). The notification request message received by the M2M device is composed of parameters "Operation", "To", "From", "Request Identifier", and "Content". The Operation parameter is set to Notify. The content parameter of the notification request message may include URI information having a processing result.

The M2M device generates a notification response message for the notification request message (S545). The notification response message essentially includes the "Response Status Code" and "Request Identifier" parameters. The information of the “Request Identifier” parameter included in the notification response message should be the same as the “Request Identifier” of the notification request message.

The M2M device sends the generated notification response message to the receiver (S550). The information of the "To" parameter included in the notification response message should be the same as the information of the "To" parameter of step S505.

The M2M device sends an inquiry message for inquiring the "Content" parameter of the notification request message (S555). The inquiry message of step S555 essentially includes the parameters "Operation", "To", "From", and "Request Identifier". Operation parameters are set to Retrieve.

The M2M device receives a response message from the hosting CSE (S560). The response message in step S560 essentially includes the "Response Status Code", "Request Identifier", and "Content" parameters. Information of the "Request Identifier" parameter of step S560 should be the same as the "Request Identifier" of step S555. The information of the “Content” parameter included in the response message includes processing result information on the request message of step S505. As mentioned above

The M2M device extracts an operation result of the response message received in step S560 (S565). The processing result is “operation result” attribute information of the <request> resource in the “Content” parameter. The <request> resource MUST contain the required attribute information. Essential attribute information is information on operation, target, originator, requestID, metaInformation, content, requestStatus, and operationResult attributes. The operation result (operationResult) of the resource <request> in step S560 includes response information about the request message in step S505.

The M2M device processes the request result for the request message of step S505 by using the extracted response information (S570). Information of the "Request Identifier" parameter of step S570 should be the same as the "Request Identifier" of step S505.

As described above, the M2M device transmitting the request message may obtain the processing result according to different procedures according to the response type parameter.

Second embodiment

Referring to FIG. 8, the M2M device configures a request message (S600). The request message essentially includes parameters such as an operation, a receiver, a initiator, a request identifier, and the like.

The M2M device transmits the configured request message to the receiver (S605).

Thereafter, unlike the first embodiment, the M2M device checks the response type parameter of the request message without receiving the response message (S610). As mentioned above, the response type parameter may not exist or may be set to either blocking or synchronous nonblocking or asynchronous nonblocking.

As an example, the M2M device waits for a response message of the receiver when there is no response type parameter of the request message or when the response type parameter is blocking (S615). The response message essentially includes the “Response Status Code” and “Request Identifier” parameters and includes response information about the request message. In addition, the information of the "Request Identifier" parameter of the response message is the same as the "Request Identifier" in step S605. If the information of the response type parameter is blockingRequest, the M2M device processes the receiver's response information (S620).

As another example, when the information of the response type parameter is synchronous nonblockingRequestSynch, the M2M device waits for an acknowledgment message of the receiver (S625). When the receiver receives the request message, the receiver may transmit an acknowledgment message for the request message to the M2M device.

The M2M device sends a request message for inquiry after a predetermined time or a predetermined time in order to know whether the request message is completed (S630). The predetermined time or any time may be set in advance or may be set dynamically to correspond to the request message. Alternatively, the request message may be transmitted at regular intervals. At this time, the M2M device may or may not manage the process state in order to process step S630. For example, the case where the state of the process is not managed to process the step S630 in step S625 is indicated by a dotted line. In addition, when managing the state of the process, it is indicated by the solid line. The request message essentially includes the parameters "Operation", "To", "From", and "Request Identifier". Operation parameters are set to Retrieve.

Thereafter, the M2M device receives a response message for the request message (S635). When the receiver has processed the request message transmitted in step S605, the response message may essentially include "Response Status Code", "Request Identifier", and "Content" parameters. The “Request Identifier” parameter information of the response message is the same as the “Request Identifier” parameter of the request message. The information of the “Content” parameter may include response information to the request message of step S605 when the receiver processes the request message of step S605. If the receiver fails to process the request message of step S605, the response message may include the "Response Status Code", "Request Identifier" parameters.

The M2M device checks the "Response Status Code" parameter of the response message (S640). For example, if the information of the "Response Status Code" parameter is successful (for example, code 2XXX), the M2M device checks the Content parameter and, if there is a Content parameter, performs step S645. That is, if the response status code is 2000 (OK), 2001 (created), 2002 (deleted), or 2004 (changed), and there is a Content parameter, step S640 is performed. For another example, when the information of the "Response Status Code" parameter is information indicating that the receiver continues processing, the M2M device performs step S630. That is, when the response status code is 1XXX, the request message for inquiry is retransmitted after a predetermined time or after a certain time. As another example, when the information in the “Response Status Code” parameter is the originator error (4XXX) or the receiver side error (5XXX) or the network error (6XXX) or 2XXX and there is no Content parameter, the M2M device determines that the error is terminated. .

If the M2M device determines that the response information is included as a result of checking the response status code parameter and the content parameter in step S640, the M2M device extracts the response information from the response message. The response information may be included in the “operation result” attribute information of the <request> resource in the “Content” parameter. The <request> resource MUST contain the required attribute information. Essential attribute information is information on operation, target, originator, requestID, metaInformation, content, requestStatus, and operationResult attributes. The information of the "Request Identifier" parameter included in the "operation result" attribute information is the same as that of "Request Identifier" in step S605.

As another example, when the response type parameter constituting the request message is asynchronous nonblockingRequestAsynch, the M2M device waits for an acknowledgment message of the receiver (S650). If the receiver confirms the request message, the M2M device receives the acknowledgment message. On the other hand, the asynchronous nonblocking (nonBlockingRequestAsynch) method displays a case in which the M2M device does not manage the state of the process to process the step S655 in step S650 with a dotted line. In addition, when managing the status of a process, it is indicated by a solid line. The M2M device may or may not manage a process for processing step S655 in step S650. In FIG. 6, it is assumed that a process state is not managed.

If the receiver completes processing of the request message, a request message indicating a notification is transmitted to the M2M device, and the M2M device receives a request message for notification (S655). The request message received by the M2M device consists of “Operation”, “To”, “From”, “Request Identifier” and “Content” parameters. The Operation parameter is set to Notify. The notification content (eg, Content) may include response information on the request message transmitted in step S605.

The M2M device generates a response message to the request message indicating the notification (S660). The response message essentially includes the "Response Status Code" and "Request Identifier" parameters. The information of the “Request Identifier” parameter included in the response message indicating the notification should be the same as the “Request Identifier” of the request message indicating the notification.

The M2M device sends the generated response message to the receiver (S665). The information of the "To" parameter included in the response message should be the same as the information of the "To" parameter of step S605.

The M2M device extracts response information included in the request message received in step S655 (S670). The response information may be included in the “operation result” attribute information of the <request> resource in the “Content” parameter. The <request> resource MUST contain the required attribute information. Essential attribute information is information on operation, target, originator, requestID, metaInformation, content, requestStatus, and operationResult attributes. The operation result (operationResult) included in the <request> resource of the request message indicating the notification is response information to the request message in step S605.

Thereafter, the M2M device processes the result of the request message using the extracted response information (S620). The “Request Identifier” parameter information in step S620 should be the same as the “Request Identifier” parameter information in step S605.

The M2M device which has transmitted the request message through the above operation may obtain the response information through a different procedure for each communication method.

Meanwhile, the request message may be delivered to one or more hops by the delivery M2M device. For example, the M2M device may receive the request message and determine whether the CSE-ID included in the To parameter of the request message is the same as the CSE-ID of the M2M device receiving the message. If the CSE-IDs are the same, the M2M device may process the request message with the hosting CSE. On the contrary, when the CSE-IDs do not match, the corresponding M2M device performs an operation of delivering a request message. In order to check whether the request message is delivered or not, the CSE-ID is described as an example, but the identification information is not limited.

Hereinafter, an example in which an error or waste of resources occurs for each communication method when a request message is transmitted and received is described with reference to the drawings. In the following description, it is assumed that a request message is delivered once to explain a more detailed example. However, the same problem may occur when the request message is directly processed without a delivery process. In addition, hereinafter, the transmitter-side M2M device will be described based on the case where the response procedure for the request message is performed according to the second embodiment, and the case where the first request message is set to synchronous non-blocking will be described.

Referring to FIG. 7, the originator 600 transmits a request message (S710). The request message may include required and optional parameters. The essential parameters may include an operation parameter (Operation, op), a transmitter side parameter (TO, to), a receiver side parameter (From, fr), and a request identifier parameter (Request Identifier, rqi). It may also include content (PrimitiveContent, pc). Optional parameters may include a response type parameter (rt). Here, an example will be described in which the operation parameter is set to retrieve (r) and the response type parameter is set to synchronous nonblocking.

Upon receiving the request message, the delivery M2M device 601 generates a request resource (S720), and transmits a response message indicating that the request resource generation is completed to the originator 600 (S730). In addition, the delivery M2M device 601 transmits a request message to the hosting M2M device 602 (S740). In this case, the response type parameter of the delivered request message may be set to synchronous nonblocking in the same way. Or, it may be changed according to the selection of the delivery M2M device 602.

The hosting M2M device 602 receiving the forwarded request message checks the response type parameter and generates a request resource (S750). In addition, the M2M device 602 transmits a response message indicating that the request resource generation is completed to the delivery M2M device 601 (S760). The hosting M2M device 602 performs a designated operation by using parameters of the received request message and updates the request resource (S770).

The delivery M2M device 601 transmits an inquiry message to the hosting M2M device 602 at a predetermined period or a specified time point according to the response type in synchronous nonblocking (S780). The transmitting M2M device 601 may set the response type parameter of the inquiry message to blocking in transmitting the inquiry message. Alternatively, the response type parameter of the inquiry message may not be set. In this case, the hosting M2M device 602 transmits a response message to the inquiry message in a communication method according to the blocking response type (S790). The delivery M2M device 601 updates the request resource using the content of the response message received from the hosting M2M device 602 (S792).

The originator 600 transmits an inquiry message to the delivery M2M device 601 at a predetermined period or at a designated time according to the synchronous nonblocking response type (S794). In transmitting the inquiry message, the originator 600 may set the response type parameter of the inquiry message to blocking. Alternatively, the response type parameter of the inquiry message may not be set. In this case, the delivery M2M device 601 transmits a response message to the inquiry message (S796).

Through such a process, the initiator 600 may obtain response information.

As such, the response result may be normally received when the response type parameter of the inquiry message is blocked or unset.

Referring to FIG. 8, the originator 600 transmits a request message (S810). As described above, the request message may include required parameters and optional parameters. The essential parameters may include an operation parameter (Operation, op), a transmitter side parameter (TO, to), a receiver side parameter (From, fr), and a request identifier parameter (Request Identifier, rqi). It may also include content (PrimitiveContent, pc). Optional parameters may include a response type parameter (rt). Here, an example will be described in which the operation parameter is set to retrieve (r) and the response type parameter is set to synchronous nonblocking.

Upon receiving the request message, the delivery M2M device 601 generates a request resource (S820), and transmits a response message indicating that the request resource generation is completed to the originator 600 (S830). In addition, the delivery M2M device 601 transmits a request message to the hosting M2M device 602 (S840). In this case, the response type parameter of the delivered request message may be set to synchronous nonblocking in the same way. Or, it may be changed according to the selection of the delivery M2M device 602.

The hosting M2M device 602 receiving the forwarded request message checks the response type parameter and generates a request resource (S850). In addition, the M2M device 602 transmits a response message indicating that the request resource generation is completed to the delivery M2M device 601 (S860). The hosting M2M device 602 performs a designated operation by using parameters of the received request message and updates the request resource (S870).

The delivery M2M device 601 transmits an inquiry message to the hosting M2M device 602 at a predetermined period or a specified time point according to the response type in synchronous nonblocking (S872). The transmitting M2M device 601 may set the response type parameter of the inquiry message to synchronous nonblocking in transmitting the inquiry message. In this case, the hosting M2M device 602 performs the inquiry message processing procedure according to the synchronous nonblocking response type.

For example, the hosting M2M device 602 receives an inquiry message and generates a request resource (S874). In addition, the M2M device 602 transmits a response message indicating that the request resource generation is completed to the delivery M2M device 601 (S876). Thereafter, the hosting M2M device 602 performs a designated operation using the parameters of the received inquiry message and updates the request resource (S878).

Accordingly, although the delivery M2M device 601 transmits an inquiry message in step S872 according to the synchronous nonblocking communication scheme, when the response type parameter of the inquiry message is set to synchronous nonblocking, response information is not obtained. That is, after step S878, the delivery M2M device 601 additionally transmits an inquiry message again, and in this case, the hosting M2M device 602 repeats steps S872 to S878. As such, when the response type parameter of the inquiry message is set to synchronous nonblocking, when the hosting M2M device 602 completes processing of the original request message, information about this cannot be delivered to the delivery M2M device 601. An error occurs.

The same problem may occur between originator 600 and delivery M2M device 601. For example, the originator 600 transmits an inquiry message to the delivery M2M device 601 at a predetermined period or a predetermined time point according to the response type in synchronous nonblocking (S880). The originator 600 may set the response type parameter of the inquiry message to synchronous nonblocking in transmitting the inquiry message. In this case, the delivery M2M device 601 performs the inquiry message processing procedure according to the synchronous nonblocking response type.

That is, the delivery M2M device 601 receives the inquiry message and generates a request resource (S882). In addition, the delivery M2M device 601 transmits a response message indicating that the request resource generation is completed to the originator 600 (S882). Thereafter, the delivery M2M device 601 performs a designated operation by using parameters of the received inquiry message and updates a request resource (S886). However, in operation S886, when the delivery M2M device 601 does not receive the processing result from the hosting M2M device 602, the delivery M2M device 601 may normally process the update operation.

As such, the originator 600 may not receive the response result when the inquiry message is set to be transmitted synchronously non-blocking, and a problem occurs in that steps S880 to S886 are repeated repeatedly.

In summary, when the response type parameter of the inquiry message is set to synchronous nonblocking, a serious problem may occur in which the processing result for the request message is not received.

Referring to FIG. 9, the originator 600 transmits a request message (S910). As described above, the request message may include required parameters and optional parameters. The essential parameters may include an operation parameter (Operation, op), a transmitter side parameter (TO, to), a receiver side parameter (From, fr), and a request identifier parameter (Request Identifier, rqi). It may also include content (PrimitiveContent, pc). Optional parameters may include a response type parameter (rt). Here, an example will be described in which the operation parameter is set to retrieve (r) and the response type parameter is set to synchronous nonblocking.

Upon receiving the request message, the delivery M2M device 601 generates a request resource (S920), and transmits a response message indicating that the request resource generation is completed to the originator 600 (S930). In addition, the delivery M2M device 601 transmits a request message to the hosting M2M device 602 (S940). In this case, the response type parameter of the delivered request message may be set to synchronous nonblocking in the same way. Or, it may be changed according to the selection of the delivery M2M device 602.

The hosting M2M device 602 receiving the transferred request message checks the response type parameter and generates a request resource (S950). In addition, the M2M device 602 transmits a response message indicating that the request resource generation is completed to the delivery M2M device 601 (S960). The hosting M2M device 602 performs a designated operation by using parameters of the received request message and updates the request resource (S970).

The delivery M2M device 601 transmits an inquiry message to the hosting M2M device 602 at a predetermined period or a specified time point according to the response type in synchronous nonblocking (S972). The transmitting M2M device 601 may set the response type parameter of the inquiry message to asynchronous nonblocking in transmitting the inquiry message. In this case, the hosting M2M device 602 performs the inquiry message processing procedure according to the asynchronous nonblocking response type.

For example, the hosting M2M device 602 receives an inquiry message and generates a request resource (S974). In addition, the M2M device 602 transmits a response message indicating that the request resource generation is completed to the delivery M2M device 601 (S976). Thereafter, the hosting M2M device 602 performs a designated operation using the parameters of the received inquiry message and updates the request resource (S978). The hosting M2M device 602 then delivers a request message to the delivery M2M device 601 in which the operating parameter is set to notification.

The delivery M2M device 601 receives the request message of step S980, checks the processing result of the content parameter included in the request message, and updates the request resource (S982). Thereafter, the delivery M2M device 601 transfers the response message to the hosting M2M device (S984).

If the originator 600 may also transmit an inquiry message to the delivery M2M device 601 at a predetermined period or time point according to the synchronous blocking communication scheme, the inquiry message may be set to asynchronous nonblocking. If the inquiry message transmitted from the originator 600 to the delivery M2M device 601 is also set to asynchronous nonblocking, steps S972 to S984 may be similarly generated between the originator 600 and the delivery M2M device 601. On the contrary, if the inquiry message transmitted from the originator 600 is set to blocking, the originator 600 may receive a response message according to the operation as shown in FIG. 7. Alternatively, if the inquiry message transmitted by the originator 600 is set to synchronous nonblocking, the response message may not be received due to repetition of the operation of FIG. 8.

As such, when the inquiry message is set to asynchronous nonblocking, the steps of S974 to S978 may additionally occur unnecessarily. That is, the M2M device receiving the inquiry message needs to additionally generate a request resource and perform an operation such as request resource update. This has a problem of causing resource waste of the M2M device.

As described above, when the request message is set to the synchronous non-blocking communication method, the M2M device that transmits the request message (including the delivery request message) must transmit an inquiry message to obtain a processing result. Since the inquiry message is also a kind of request message, the communication method of the inquiry message is also set.

As shown in FIG. 7, when the communication method of the inquiry message is set to blocking, the processing result may be normally transmitted to the originator. However, as shown in FIG. 8, when the communication method of the inquiry message is set to synchronous nonblocking, the originator may not normally receive the processing result for the request message. In addition, when the communication method of the inquiry message is set to asynchronous nonblocking, as shown in FIG. 9, the processing result of the request message may be obtained, but the receiving M2M device additionally generates unnecessary resources, causing resource waste. Done.

In order to solve such a problem, the present disclosure proposes a specific procedure for the M2M device to normally receive the response message for the request message set to synchronous nonblocking.

Referring to FIG. 10, the M2M device performs a step of transmitting a request message (S1000). The request message may include required and optional parameters. The essential parameters may include an operation parameter (Operation, op), a transmitter side parameter (TO, to), a receiver side parameter (From, fr), and a request identifier parameter (Request Identifier, rqi). It may also include content (PrimitiveContent, pc). Optional parameters may include a response type parameter (rt).

For example, the response type parameter set in the request message may be set to any one of blocking, synchronous nonblockingRequestSynch, asynchronous nonblockingRequestAsynch, flexBlocking, and not set. If the request message is set to not set, the blocking communication scheme may be applied in the same manner.

The M2M device checks the response type parameter set in the request message (S1010). As described with reference to FIGS. 5 and 6, the M2M device checks the communication scheme according to the request message after transmitting the request message. For example, the M2M device may confirm the communication method by checking the response type parameter of the request message. If the response type parameter included in the request message is set to flex blocking, the corresponding communication scheme is determined by the M2M device receiving the request message. Accordingly, the M2M device which has transmitted the request message may check the communication scheme determined according to the selection of the M2M device which has received the request message.

If the response type parameter is set to synchronous non-blocking (nonBlockingRequestSynch), the M2M device transmits an inquiry message for inquiring the processing result for the request message (S1020).

For example, if the communication method is confirmed as synchronous nonblocking according to the response type parameter check, the M2M device transmits an inquiry message to receive the response message.

As another example, the M2M device confirms the communication method through a response message received from the M2M device receiving the request message when the response type parameter is set to flex blocking, and processes the request message when the confirmed communication method is synchronous nonblocking. Send an inquiry message to check the result.

In this case, the inquiry message may be set to a fixed response type parameter to prevent the above problem.

For example, the response type parameter of the inquiry message may be fixed to blocking. That is, the response type parameter of the inquiry message may be set to blocking independently of the response type parameter of the request message.

As another example, the response type parameter of the inquiry message may not be set. When the response type parameter is not set, the inquiry message is processed by the blocking communication scheme, thereby generating the same effect as that of the blocking.

The M2M device performs a step of receiving a response message including a processing result in response to the inquiry message (S1030). The M2M device may receive a response message with respect to the inquiry message set with the fixed response type parameter. In this case, the response message may include processing result information about the request message. For example, the response message may include a response status code parameter, a request identification parameter, and a content parameter. The information of the request identification parameter should be the same as the information of the request identification parameter of the inquiry message. The information of the content parameter includes response information (processing result) when the receiving M2M device processes the request message.

Thereafter, the M2M device may perform any one of an operation of extracting a processing result from the response message, retransmitting an inquiry message, and an error processing operation according to a result of checking the response status code parameter or the content parameter.

For example, when the information of the response status code parameter is successful (for example, code 2XXX), the M2M device checks the content parameter, and if there is a content parameter, determines that the content parameter is successful and extracts a processing result. . For example, if the code of the response status parameter is 2000 (OK), 2001 (created), 2002 (deleted), or 2004 (changed), and there is a content parameter, the processing result extraction operation is performed.

As another example, when the information of the response status code parameter is information indicating the incomplete processing of the receiver (for example, Informational (1XXX) or Acknowledge), the M2M device performs an inquiry message retransmission operation. That is, after a certain time or at a certain time, the M2M device may retransmit the inquiry message.

If the information of the response status code parameter fails, the M2M device determines that it is an error and ends. For example, the M2M device determines that an error occurs when the response status code parameter indicates originator error (4XXX) or receiving side error (5XXX) or network error (6XXX), and the response status code does not have a content parameter even when the response status code is 2XXX. Judging by the error.

The M2M device extracts the operation result (operation result) that the receiver responds using the response message. For example, the processing result may be included in the “operation result” attribute information of the <request> resource in the content parameter. The <request> resource MUST contain the required attribute information. Essential attribute information is information on operation, target, originator, requestID, metaInformation, content, requestStatus, and operationResult attributes.

As described above, the M2M device processing the request message according to the present embodiment may solve the problem of no response message and unnecessary resource generation that may occur according to the response type parameter of the inquiry message.

Hereinafter, the processing operation when the present embodiment is added to the general processing operation of the above-described M2M apparatus of FIG. 6 will be described once again with reference to FIG. 11.

Referring to FIG. 11, operations S600 to S670 are performed in the same manner as operations S600 to S670 of FIG. 6. However, when the response type parameter of the request message is set to synchronous nonblocking, step S1130 may be performed to prevent the above-mentioned problem from occurring. That is, when the M2M device transmits an inquiry message requesting a processing result for the request message, the operation parameter of the inquiry message is set to "lookup", and the response type parameter is set to blocking.

According to such a general processing procedure, the problems of FIGS. 8 and 9 can be prevented.

Each embodiment described above may be applied individually, or some or all of them may be combined and applied. Hereinafter, the M2M device capable of performing some or all of the above-described embodiments will be briefly described again.

Referring to FIG. 12, the M2M device 1200 may include a transmitter 1220 for transmitting a request message, a controller 1210 for checking a response type parameter set in the request message, and an inquiry message for inquiring processing results for the request message. It may include a receiving unit 1230 for receiving a response message including the processing result in response.

Also, when the response type parameter is set to synchronous nonblockingRequestSynch, the transmitter 1220 may further transmit an inquiry message for inquiring the processing result of the request message.

As described above, the request message may include required parameters and optional parameters. The essential parameters may include an operation parameter (Operation, op), a transmitter side parameter (TO, to), a receiver side parameter (From, fr), and a request identifier parameter (Request Identifier, rqi). It may also include content (PrimitiveContent, pc). Optional parameters may include a response type parameter (rt). For example, the response type parameter set in the request message may be set to any one of blocking, synchronous nonblockingRequestSynch, asynchronous nonblockingRequestAsynch, flexBlocking, and not set. If the request message is set to not set, the blocking communication scheme may be applied in the same manner.

In addition, after transmitting the request message, the controller 1210 checks the communication scheme according to the request message. For example, the controller 1210 may check the response type parameter of the request message to confirm the communication scheme. If the response type parameter included in the request message is set to flex blocking, the corresponding communication scheme is determined by the M2M device receiving the request message. Accordingly, the M2M device which has transmitted the request message may check the communication scheme determined according to the selection of the M2M device which has received the request message.

Meanwhile, when the response type parameter is set to synchronous nonblocking, the transmitter 1220 may transmit an inquiry message for obtaining a processing result. For example, if the communication method is synchronous nonblocking according to the response type parameter check, the transmitter 1220 transmits an inquiry message to receive the response message. As another example, when the response type parameter is set to flex blocking, the controller 1210 confirms a communication method through a response message received from the M2M device receiving the request message, and when the confirmed communication method is synchronous nonblocking, 1220 transmits an inquiry message to confirm the processing result for the request message.

In this case, the controller 1210 may set the response type parameter of the inquiry message to the fixed response type parameter in order to solve the above problem. For example, the response type parameter of the inquiry message may be fixed to blocking. That is, the response type parameter of the inquiry message may be set to blocking independently of the response type parameter of the request message. As another example, the response type parameter of the inquiry message may not be set. When the response type parameter is not set, the inquiry message is processed by the blocking communication scheme, thereby generating the same effect as that of the blocking.

Meanwhile, the receiver 1230 receives a response message. The response message may include processing result information about the request message. For example, the response message may include a response status code parameter, a request identification parameter, and a content parameter. The information of the request identification parameter should be the same as the information of the request identification parameter of the inquiry message. The information of the content parameter includes response information (processing result) when the receiving M2M device processes the request message.

The controller 1210 may perform any one of an operation of extracting a processing result from a response message, an operation of retransmitting an inquiry message, and an error processing operation according to a result of checking the response status code parameter or the content parameter.

For example, when the information of the response status code parameter is successful (for example, code 2XXX), the controller 1210 checks the content parameter, and if the content parameter is present, determines that the content parameter is successful and extracts a processing result. To perform. For example, if the code of the response status parameter is 2000 (OK), 2001 (created), 2002 (deleted), or 2004 (changed), and there is a content parameter, the processing result extraction operation is performed.

As another example, when the information of the response status code parameter is information indicating the incomplete processing of the receiver (for example, Informational (1XXX) or Acknowledge), the controller 1210 may control to perform an inquiry message retransmission operation.

If the information of the response status code parameter is a failure, the controller 1210 determines as an error and ends. For example, the controller 1210 determines that the response status code parameter indicates an error when the response status code parameter indicates an originator error (4XXX) or a reception side error (5XXX) or a network error (6XXX). If not, it is regarded as an error. In addition, the controller 1210 extracts an operation result (operation result) answered by the receiver using the response message. For example, the processing result may be included in the “operation result” attribute information of the <request> resource in the content parameter. The <request> resource MUST contain the required attribute information. Essential attribute information is information on operation, target, originator, requestID, metaInformation, content, requestStatus, and operationResult attributes.

In addition, in performing the above-described embodiments, the control unit 1210 sets the communication method of the inquiry message to obtain a processing result as a specific communication method when the communication method of the request message is set to synchronous nonblocking. The overall operation of the M2M device 1200 can be controlled.

In addition, the transmitter 1220 and the receiver 1230 are used to transmit and receive signals, messages, and data necessary for performing the above-described embodiments with other M2M devices.

The controller 1210, the transmitter 1220, the receiver 1230, and the like used in the M2M device 1200 described above may be implemented as some modules of the integrated controller or the electronic controller. Alternatively, the transmitter 1220 and the receiver 1230 may be implemented as modules for wireless communication.

The integrated control device or electronic control device may include a storage device such as a processor and a memory, a computer program capable of performing a specific function, and the like. The controller 1210, the transmitter 1220, the receiver 1230, etc. It may be implemented as a software module capable of performing each unique function.

In addition, the embodiments may be implemented as a computer program. For example, each of the steps or configurations described above may be implemented in each function using computer program code. Code and code segments constituting the program can be easily inferred by a computer programmer in the art. In addition, the created program is stored in a computer-readable recording medium (information storage medium), and can be embodied in this embodiment by being read and executed by a computer. The recording medium may include any type of computer readable recording medium. Therefore, a computer program or a storage medium including the computer program implementing the above-described embodiments should be construed as being included in the scope of the present embodiment.

The standard contents or standard documents mentioned in the above embodiments are omitted to simplify the description of the specification and form a part of the present specification. Therefore, the addition of the contents of the standard and part of the standard documents to the specification or the description in the claims should be construed as falling within the scope of the present invention.

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 spirit of the present invention but to describe the present invention, and the scope of the technical idea of the present invention is not limited by these embodiments. 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 under U.S. Patent Application No. 10-2017-0129596 for the Korean Patent Application No. 10-2016-0129596 filed on October 7, 2016 and the Korean Patent Application No. 10-2017-0126043 filed for Korea on September 28, 2017. a) claims priority under section 35 USC § 119 (a), all of which is hereby incorporated by reference in this patent application. 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 the machine to machine communication (M2M) device receives the response information,

Sending a request message;

Checking a response type parameter set in the request message;

When the response type parameter is set to synchronous nonBlockingRequestSynch, transmitting an inquiry message for querying a processing result for the request message; And

Receiving a response message including the processing result in response to the inquiry message,

The inquiry message,

Set to a fixed response type parameter.
The method of claim 1,

The response type parameter set in the request message is

Blocking, the synchronous nonblocking (nonBlockingRequestSynch), asynchronous nonblocking (nonBlockingRequestAsynch), flex blocking (flexBlocking) and non-set.
The method of claim 1,

The request message,

Operating parameters, receiving parameters, sending parameters and request identification parameters.
The method of claim 1,

The fixed response type parameter is

And blocking is set independently of the response type parameter of the request message.
The method of claim 1,

The response message is,

And a response status code parameter, request identification parameter, and content parameter.
The method of claim 5, wherein

And extracting the processing result from the response message, retransmitting the inquiry message, and error processing according to a result of checking the response status code parameter or the content parameter. .
In the machine to machine communication (M2M) device for receiving the response information,

A transmitter for transmitting a request message;

A controller for checking a response type parameter set in the request message; And

Including a receiving unit for receiving a response message including the processing result in response to the inquiry message for inquiring the processing result for the request message,

The transmitting unit,

If the response type parameter is set to synchronous nonblockingRequestSynch, further send the inquiry message for querying the processing result for the request message,

The inquiry message,

M2M device, characterized in that it is set to a fixed response type parameter.
The method of claim 7, wherein

The response type parameter set in the request message is

M2M device is set to any one of blocking (blocking), synchronous nonblocking (nonBlockingRequestSynch), asynchronous nonblocking (nonBlockingRequestAsynch), flex blocking (flexBlocking) and not set.
The method of claim 7, wherein

The request message,

M2M apparatus comprising an operation parameter, a receiving side parameter, a transmitting side parameter and a request identification parameter.
The method of claim 7, wherein

The fixed response type parameter is

M2M device, characterized in that it is set to blocking independently from the response type parameter of the request message.
The method of claim 7, wherein

The response message is,

M2M device comprising a response status code parameter, a request identification parameter and a content parameter.
The method of claim 11,

The control unit,

And extracting the processing result from the response message, retransmitting the inquiry message, and error processing according to a result of checking the response status code parameter or the content parameter. M2M device.