KR20180039552A - Methods for processing flexBlocking communication method in Receiver CSE and Apparatuses thereof - Google Patents

Abstract

The present embodiment relates to a machine to machine communication (M2M) technology and a method for processing a flexBlocking communication method for efficient resource management in a receiver CSE. One embodiment includes a step of allowing an M2M device to receive a request message; a step of confirming a response type parameter corresponding to the request message; and a step of determining a response type parameter according to the response type parameter. The response type parameter is set to flexBlocking.

Description

Receiver CSE and Apparatuses to Handle FlexBlocking Communication Method for Effective Resource Management in Receiver CSE

This embodiment relates to M2M (Machine to Machine Communication) technology and a method for processing a flexBlocking communication method for efficient resource management in a receiver CSE.

"Machine to Machine Communication" or MTC, "Machine Type Communication" or "Smart Device Communication" or "Machine oriented communication" or "Internet of Things" In which communication is performed without intervening in the network. Recently, oneM2M has been discussing M2M, but there are no technical elements to meet the architecture and requirements of oneM2M.

The present embodiment, which is devised from the above-mentioned background, proposes a method and apparatus for flexibly handling a flexBlocking communication method even when the M2M device receives the communication method.

An embodiment of the present invention for solving the above-mentioned problems includes a method of receiving a request message from a machine to machine communication (M2M) device; Confirming a response type parameter corresponding to the request message; And determining a response type parameter according to the response type parameter, wherein the response type parameter is set to flexblocking.

The present embodiment described above provides an effect of flexibly handling the flexBlocking communication method even when the M2M device receives the flexBlocking communication method.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a diagram illustrating the M2M system from a high level functional view.
FIG. 2 is a view showing a more detailed structure of the M2M system according to one embodiment.
FIG. 3 is an exemplary diagram illustrating a procedure for transmitting a request message and receiving response information in the M2M system.
4 is a diagram showing a generic procedure of a receiver.
5 is a diagram showing a resource handling procedure.
6 is a diagram for explaining an operation in which the receiver CSE selects blockingRequest as a response type.
7 is a diagram for explaining an operation in which the receiver CSE selects nonBlockingRequestSynch as a response type.
FIG. 8 is a diagram for explaining an operation in which the Receiver CSE selects nonBlockingRequestAsynch as a Response Type.
FIG. 9 is a diagram for explaining the operation of selecting the blocking type of the response type as the Response Type CSE (Transit CSE) of the 1Hop and the non-blocking RequestSynch as the Response Type of the Receive CSE (Hosting CSE) of the 2Hop.
FIG. 10 is a diagram for explaining an operation of selecting a blocking type as a response type in the receiver CSE (Transit CSE) of 1Hop and a non-blocking request asynch as a response type in the receiving CSE (Hosting CSE) of 2Hop.
11 is a diagram for explaining an operation in which the 1Hop CSE (Transit CSE) is acceptable only to the "blockingRequest" communication method but the 2Hop CSE (Hosting CSE) selects the "nonBlockingRequestSynch" communication method.
Fig. 12 is a diagram for explaining an operation in which the 1Hop CSE (Transit CSE) can accept only the "blockingRequest" communication method but the 2Hop CSE (Hosting CSE) selects the "nonBlockingRequestAsynch" communication method.
13 is a diagram for explaining the addition of a process for modifying the Response Type to the Forward procedure of the Resource handling procedure.
14 is a diagram for explaining a process for checking whether a Transit CSE accepts both a blocking and a nonBlocking method in a Forward procedure of a Resource handling procedure.
15 is a diagram schematically illustrating a receiving side M2M device according to an embodiment.

Hereinafter, some embodiments of the present invention will be described in detail with reference to exemplary drawings. It should be noted that, in adding reference numerals to the constituent elements of the drawings, the same constituent elements are denoted by the same reference numerals whenever possible, even if they are shown in different drawings. In the following description of the present invention, a detailed description of known functions and configurations incorporated herein will be omitted when it may make the subject matter of the present invention rather unclear.

In describing the components of the present invention, terms such as first, second, A, B, (a), and (b) may be used. These terms are intended to distinguish the constituent elements from other constituent elements, and the terms do not limit the nature, order or order of the constituent elements. When a component is described as being "connected", "coupled", or "connected" to another component, the component may be directly connected or connected to the other component, Quot; may be "connected," "coupled," or "connected. &Quot;

Embodiments of the present invention will be described with reference to object communication. Object communication is variously called M2M (Machine to Machine communication), MTC (Machine Type Communication), IoT (Internet of Things), Smart Device Communication (SDC), or Machine Oriented Communication . OneM2M has recently introduced many technical issues related to object communication. Object communication refers to various communication in which communication is performed without a person intervening in the communication process. In the field of telecommunication, there are various fields such as energy field, enterprise field, healthcare field, public service field, residential field, retail field, transportation field, and others Field, and so on. The present invention includes the above-mentioned fields, and is applicable to other fields.

1 is a diagram illustrating a high-level functional view of an M2M system according to an embodiment.

An application entity (AE) 110 provides application logic for an end-to-end M2M solution. For example, a fleet tracking application such as a vehicle, a remote blood sugar monitoring application, or a remote power metering and controlling application (Application Entity (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 Services Entity (CSE) 120 is a set of service functions, and these service functions are functions commonly used in the M2M environment. This service function is exposed as a different function through reference points Mca, Mcc, and uses the base network service using the reference point Mcn. An example is data management, device management, M2M subscription management, location service, and the like. The subfunctions provided by the CSE can be logically understood as a CSF (Common Service Function). Some of the CSFs within the CSE of oneM2M node are mandatory and some may be optional. Similarly, the subfunctions in the CSF may also be mandatory or optional.

An underlying network services function (NSF) 130 provides services to the common service entity. Examples of services include device management, location services and device triggering.

Reference Points are supported in the common service entity (CSE), and the Mca reference point is a reference point that indicates the communication flow between the application entity and the common service entity. The Mcc reference point is a reference point that indicates the communication flow between two common service entities. The Mcn reference point is a reference point indicating the communication flow 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. The 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 may reside in the same physical entity or in different physical entities. The Mcc reference point enables such use by a common service entity that wishes to use the services of other common service entities that provide the necessary functionality. The services provided through the Mcc reference point are dependent on the functionality provided by the common service entity. Mcc reference points can be supported between different M2M nodes. The Mcn reference point enables such use by a common service entity that wishes to use the service object of the underlying network providing the necessary functionality, which provides services other than transport and connection. The instance of the Mcn reference point is implemented dependent on the service provided in the underlying network. Information exchange between two physical M2M nodes can use the transport and connectivity services of the underlying network to provide basic services.

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

FIG. 2 is a view showing a more detailed structure of the M2M system according to one embodiment.

Referring to FIG. 2, an infrastructure node 250 performs a server function necessary to provide M2M communication. The originating node 250 is comprised of an originating node application entity (AE) 252 and an originating node common service entity (CSE) 254. The base node common service entity 254 is configured using the resources shown in FIG. 3 to be described below. 252 and 254 are divided through an Mca reference point and a message for communication of objects, particularly a request message for creating, deleting, updating, retrieving, and notifying the scheduler resource And for constructing and processing response messages.

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

The application service node 210 may include an application entity 212 and a relay node common service entity 214. The application entity 212 processes the application functions required for the purpose of the device. The common service entity 214 of the application service node 210 is configured using the resources shown in FIG. 212 and 214 are divided through Mca reference points and 214 and 254 are classified using Mcc reference points and messages necessary for object communication, in particular, create, delete, update, Used to construct and process request and response messages to retrieve and notify. Meanwhile, the application service node 220 may perform the object communication function with the base node 100 through the relay node 200. The difference between 210 and 220 is that the communication interfaces constituting the node are different. For example, the 220 communicates with 200 through 200 using an interface capable of a near-field communication such as Bluetooth, ZigBee, Zwave, and WiFi. On the other hand, the 210 communicates with 100 using a communication interface such as 3G, LTE, Ethernet, Gigabit Ethernet, and ADSL.

The application dedicated nodes 230 and 240 do not have a common service entity but do object communication using only the application entity 242. [ 230 communicates with 100 through a communication interface such as 3G, LTE, Ethernet, Gigabit Ethernet, and ADSL, and 240 uses an interface capable of a short-range communication such as Bluetooth, ZigBee, Zwave, Lt; / RTI >

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

The embodiments relate to a method and a procedure for receiving a response message from a sender of a request message in an M2M system, which is essential for preventing an error from occurring.

For example, information on the usage amount of electricity, gas, water, etc. in a house or an apartment is provided monthly or at a constant cycle through object communication. To do this, it is necessary to collect information and transmit information from electric meters, gas meters, and water meters. In addition, various applications such as energy, enterprise, medical, public service, residential, retail, transportation and transportation can be applied to object communication, and various object communication applications can be presented as shown in Table 1 .

When transmitting and receiving information between M2M devices in various fields, the present embodiment separately provides a procedure for transmitting response information according to the response type of the individual M2M device or the individual request message, This is to prevent an error from occurring.

To this end, the present embodiment provides a method in which an originator constructs and transmits a request message, and a source determines a blocking, a synchronous non-blocking, and an asynchronous non-blocking according to a response type of a receiver. In addition, when the response type parameter is synchronous non-blocking, the sender can inquire the processing result of the receiver to determine whether or not the processing has been completed, and obtain the processing completion result. If the response type parameter is asynchronous non-blocking, the sender receives the processing result completion notification information of the receiver, and obtains the result of the processing using the notification information.

In this specification, both the originating node and the recipient can be M2M devices, describing an M2M device that transmits a request message as an originator, receiving an inquiry message, and generating and transmitting response information as a recipient But the terms can be changed as needed.

FIG. 3 is an exemplary diagram illustrating a procedure for transmitting a request message and receiving response information in the M2M system.

Referring to FIG. 3, the originator 300 transmits a request message to obtain necessary information (S320). The request message may include mandatory and optional parameters. For example, the transmitting side parameter, the receiving side parameter, the request identification parameter and the operation parameter are included as essential parameters. The sender parameter includes information about the originating atom that transmits the message, and the receiver parameter includes information about the recipient receiving the message. The request identification parameter includes unique ID information for identifying the request message. In addition, the operation parameters include information for distinguishing the requested operation from the request message. The operation parameter can be set to either of generation, inquiry, deletion, update, and notification.

The receiver 310 receives the request message, generates a response message for the response message, and transmits the response message to the dispatcher 300 (S340). However, the recipient 310 may differ in the procedure of transmitting the response message according to the setting. Alternatively, the response message may be received in a different procedure depending on the response type parameter included in the request message. That is, the procedure for transmitting the response message after receiving the request message by the receiver 310 may be different.

Therefore, the originator 300 proceeds to a general procedure for receiving a response message according to the response message processing procedure of each receiver 310 (S330). For example, the originating atom 300 may acknowledge the response type parameter of the request message and receive the response message in a different procedure for each response type parameter. The present invention relates to a response message reception procedure of the originator (300), and proposes a response information reception procedure distinguished by response type parameters.

Hereinafter, a more specific embodiment will be described with reference to step S330, and the response information receiving procedure according to the response type parameter will be described separately.

For example, the M2M device performs a step of transmitting a request message (S400). The request message may include at least one of an operation parameter, a receiver parameter, a transmitter parameter and a request identification parameter.

In addition, the M2M device performs the step of confirming the response type parameter corresponding to the request message. For example, the response type parameter may be included in the request message. The response type parameter may be set separately according to the procedure for receiving the response information for the request message. For example, the response type parameter may be set to either blocking, synchronous non-blocking (nonBlockingRequestSynch), or asynchronous non-blocking (nonBlockingRequestAsynch). Alternatively, the response type parameter may not exist.

In addition, the M2M device performs the step of receiving response information according to the response type parameter. The M2M device may receive the response information for the request message through different procedure rolls according to the response type parameter confirmed in step S402.

In one example, the M2M device waits until response information is received if the response type parameter does not exist or is set to blocking. That is, the M2M device waits without performing any other operation until a response message including response information is received.

As another example, the M2M device waits to receive an acknowledgment message for the request message from the receiver if the response type parameter is set to synchronous non-blocking or asynchronous non-blocking. The acknowledgment message includes Ack information for the request message and may include information indicating that the receiver has received the request message.

As another example, if the response type parameter is set to synchronous non-blocking, the M2M device sends an inquiry request message to the recipient to receive the response information. The inquiry request message may be transmitted when a predetermined period or a predetermined time has elapsed. The M2M device receives the inquiry response message for the inquiry request message after transmitting 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 the M2M device receives the inquiry response message, it confirms the response status code parameter or the content parameter included in the inquiry response message, retransmits the inquiry request message according to whether the response information is included, extracts the response information from the inquiry response message, Error processing can be performed.

As another example, the M2M device may receive a notification request message from a receiver if the response type parameter is set to asynchronous non-blocking. The M2M device also generates a notification response message for the notification request message and sends it to the receiver. The notification request message may include an operation parameter, a receiver parameter, a transmitter parameter, a request identification parameter, and a Kentontz parameter. The notification response message may also include a response status code parameter and a request identification parameter. The request identification parameter included in the notification response message may be set to the same value as the request identification parameter of the notification request message. The notification request message is generated when the receiver completes the generation of the response information according to the request message and transmits the response information to the M2M device. The M2M device can extract the response information from the notification request message and obtain the response information.

In summary, the M2M device may wait until the response information is received according to the response type parameter, receive the response information by transmitting the inquiry request message at regular intervals, or receive the notification request message to extract the response information. The distinction of the response information receiving procedure is classified according to the response type parameter, and the M2M device can confirm the response type parameter in transmitting the request message, and perform each procedure separately.

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

Hereinafter, the operation of the receiving side M2M device will be described in the case where the request message of the transmitting side M2M device is set as the flexblocking response type parameter as described above.

problem

If the "Response Type" indicating the communication method in the request message parameter received by the Receiver CSE is "flexBlocking", the local context (memory, processing capability, etc) .), The communication method should be determined and responded.

(Refer to: flexBlocking {~} part of Response Type of 8.1.2 Request of TS-0001-V2.10.0, 7.2.2.2 of Generic request procedure for receiver of TS-0001-V1.9.0: Figure 7.2.2.2-1: Generic Procedure of Receiver Recv-2.0 Procedure)

8.1.2 Request

~ Response Type: optional response message type: Indicates what type of response will be sent to the originator:

flexBlocking {optional list of notification targets}: When the request is received by the receiver CSE is set to flexBlocking, it means that the originator of the request has the capability to accept the following types of responses: nonBlockingRequestSynch, nonBlockingRequestAsynch and blockingRequest.

The Receiver CSE shall make the decision to respond to blocking or non-blocking based on its own local context (memory, processing capability, etc.).

If the Receiver CSE chooses to respond using non-blocking mode,

- If the notification targets are provided and the Recerver CSE is responding, the Receiver CSE shall notify the result using nonBlockingRequestAsynch.

- If notification targets are not provided, the Receiver CSE will respond with the address of <request> resource using nonBlockingRequestSynch.

~

7.2.2.2 Generic request procedure for receiver

~ Figure 7.2.2.2-1: Generic procedure of Receiver ~

Recv-2.0 "Communication method?": The Receiver CSE checks whether a received request is blockingRequest, nonBlockingRequestSynch or nonBlockingRequestAsynch by using Response Type parameter (see detail in clause 8.1.2 in TS-0001 [6]). If the request is a blockingRequest or Response type parameter is not included, it goes to step Recv-6.0 "Resource handling procedure". If the request is nonBlockingRequestSynch, it goes to step Recv-3.0 "Create <request> resource locally" If the request is nonBlockingRequestSynch, it goes to step. If the request is flexBlocking, the Receiver CSE shall make the decision to respond to blocking or non-blocking based on its own local context (memory, processing capability, etc.).

~

In the above 8.1.2 request, if Originator sets Request Type = flexBlocking and requests, this Originator assumes that it can accommodate all three communication methods: blockingRequest, nonBlockingRequestAsynch, and nonblockingRequestSynch.

However, there is a problem that there is no procedure to check that all three communication methods can be accommodated for a Transit CSE that FORWARDs this request primitive when a request primitive has to go through more than 2 hops. Therefore, the response primitive delivered by the Hosting CSE according to the acceptable response type (s) of the communication method by the Transit CSE may be delivered normally to the Originator or may not be delivered due to an error in the Transit CSE. Even if there is a communication method available, an error may occur and it may not be delivered. This may cause the CSE's resources to be wasted and should be resolved.

4 is a diagram showing a generic procedure of a receiver. 5 is a diagram showing a resource handling procedure. The receiving M2M device (including the transmitting M2M device) can forward and transmit the response message through the procedure of FIGS.

Hereinafter, a procedure for selecting and processing each response type parameter type in the case where the &quot; flexBlocking &quot; communication method is normally processed in 2 hop will be described with reference to the drawings.

6 is a diagram for explaining an operation in which the receiver CSE selects blockingRequest as a response type. As shown in FIG. 6, the Receiver CSE can select a blockingRequest to process the response message.

7 is a diagram for explaining an operation in which the receiver CSE selects nonBlockingRequestSynch as a Response Type.

FIG. 8 is a diagram for explaining an operation in which the Receiver CSE selects nonBlockingRequestAsynch as a Response Type.

FIG. 9 is a diagram for explaining the operation of selecting the blocking type of the response type as the Response Type CSE (Transit CSE) of the 1Hop and the non-blocking RequestSynch as the Response Type of the Receive CSE (Hosting CSE) of the 2Hop.

FIG. 10 is a diagram for explaining an operation of selecting a blocking type as a response type in the receiver CSE (Transit CSE) of 1Hop and a non-blocking request asynch as a response type in the receiving CSE (Hosting CSE) of 2Hop.

Thus, the response message can be normally transmitted when the Receiver CSE (Transit CSE) of the response message delivery path selects the same Response Type. In addition, the Receiver CSE (Transit CSE) of 1Hop selects blockingRequest as the response type, and the Receiver CSE (Hosting CSE) of 2Hop can normally process the response message even if nonBlockingRequestSynch is selected as the response type. Also, even if the Receiver CSE (Transit CSE) of 1Hop selects blockingRequest as the response type and the Receiver CSE (Hosting CSE) of 2Hop selects nonBlockingRequestAsynch as the response type, the response message can be normally processed.

However, an error may occur in response message processing in the following cases.

11 is a diagram for explaining an operation in which the 1Hop CSE (Transit CSE) is acceptable only to the "blockingRequest" communication method but the 2Hop CSE (Hosting CSE) selects the "nonBlockingRequestSynch" communication method. 11, when the Transit CSE accepts only the "blockingRequest" communication method but the Hosting CSE selects the "nonBlockingRequestSynch" communication method, the Registrar / Transit CSE waits for a response to the blockingRequest. Therefore, the NonBlockingReqeustSynch communication method does not receive the response primitive, and since the response to the request primitive has not been received, a REQUEST_TIMEOUT error is generated.

Fig. 12 is a diagram for explaining an operation in which the 1Hop CSE (Transit CSE) can accept only the "blockingRequest" communication method but the 2Hop CSE (Hosting CSE) selects the "nonBlockingRequestAsynch" communication method. Referring to FIG. 12, when the Transit CSE accepts only the "blockingRequest" communication method, but the Hosting CSE selects the "nonBlockingRequestAsynch" communication method, the Registrar / Transit CSE waits for a response to the blockingRequest. Therefore, the nonBlockingReqeustAsynch communication method does not receive the response primitive, and since the response to the request primitive has not been received, a REQUEST_TIMEOUT error is generated.

In this way, if some of the Transit CSEs on the response message delivery path select a different response type than the other CSEs (Transit CSE), or if some Receiver CSEs (Transit CSEs) do not support other Receiver CSEs A response type is not supported and a response message may not be transmitted normally.

To solve this problem, it is necessary to limit the operation of the receiver CSE (Transit CSE) when the response type is set to flexblocking in the procedure of FIG. 4 as follows.

7.2.2.2 Generic request procedure for receiver

The Receiver shall execute in the following steps in order. "Send an error response" (refer to clause 7.3.3.13 for details) and then "Send Response primitive" (refer to clause 7.3.2.4 for details). The corresponding Response code shall be included in the Response primitive.

Figure 7.2.2.2-1: Generic procedure of Receiver

Recv-1.0 "Check the validity of received request primitive": See clause 7.3.2.1 for details.

Recv-2.0 "Communication method?": The Receiver CSE checks whether a received request is blockingRequest, nonBlockingRequestSynch or nonBlockingRequestAsynch by using Response Type parameter (see detail in clause 8.1.2 in TS-0001 [6]). If the request is a blockingRequest or Response type parameter is not included, it goes to step Recv-6.0 "Resource handling procedure". If the request is nonBlockingRequestSynch, it goes to step Recv-3.0 "Create <request> resource locally" If the request is nonBlockingRequestSynch, it goes to step. If the request is flexBlocking, the Receiver CSE shall make the decision to respond to blocking or non-blocking based on its own local context (memory, processing capability, etc.).

If the request is flexBlocking  and the Receiver CSE  decided to respond to blocking, the Receiver CSE  The type of response that the request is primitive is blockingRequest or not include.

If the request is flexBlocking  and the Receiver CSE  decided to respond using non-blocking, the Receiver CSE  shall set that Response type of received request primitive is nonBlockingRequestAsync  or nonBlockingRequestSynch.

Recv-3.0 "Create <request> resource locally": Please refer to clause 7.3.2.2 for details.

~

13 is a diagram for explaining the addition of a process for modifying the Response Type to the Forward procedure of the Resource handling procedure. As another method for solving the above-mentioned problem, the procedure of FIG. 5 may be modified as shown in FIG. That is, as shown in FIG. 13, a process for modifying the Response Type can be added to the Resource handling procedure Forward procedure of FIG. 5 performed by the Receiver CSE.

The procedure added in the case of Fig. 13 can be as follows.

In the procedure shown in FIG. 4, a content for modifying the response type may be added to the description part of the Recv-2.0 procedure underlined below.

 ~

Recv -6.1.1 Response Type is flexBlocking ?: The Receiver CSE  Check whether a received request is flexBlocking  by using Response Type parameter (see detail in clause 8.1.2 in TS-0001 [6]). If the request is flexBlocking , it goes to step Recv -6.1.2 "Change the Response Type".

Recv -6.1.2 "Change the Response Type": The Receiver CSE  shall set the Response Type parameter of the received request primitive to the Communication Method decided by the Receiver CSE . The Communication Method may be one of blockingRequest  or nonBlockingRequestAsynch  or nonBlockingRequestSynch. And the request primitive be forwarded to other CSE  shall include Response Type parameter or not.

Recv-3.0 "Create <request> resource locally": Please refer to clause 7.3.2.2 for details.

~

According to the above-described embodiment, even in the case of "flexBlocking" communication, the Transit CSE needs to activate a process capable of receiving only one communication method such as "blockingRequest" or "nonBlockingRequest" Can be used. That is, you can minimize garbage processes.

Also, it is possible to prevent cases where the response primitive that is normally processed by the Hosting CSE is not transmitted to the Originator due to the issue of the communication method capacity of the Transit CSE and is processed as an error in the middle.

Therefore, the receiving side operation can be determined as follows.

7.2.2.1 Generic request procedure for originator

~ Figure 7.2.2.1-1: Generic procedure of Originator ~

Origin 3.0 "Check Response Type": In this step, the Originator checks that the communication method is either blockingRequest, nonBlockingRequestSynch, nonBlockingRequestAsynch or flexBlocking by using the responseType parameter (see detail in clause 8.1.2 in the oneM2M TS- 6]). If the Response Type parameter does not exist, the communication method is 'blockingRequest' as specified at clause 6.4.1.

If the Response Type is blockingRequest it waits for Response primitive and goes to step Orig-4.0. If the Response Type is nonBlockingRequestSync, it waits for the acknowledgment of the response primitive and goes to step Orig-4.1. If the Response Type is nonBlockingRequestAsynch, it waits for acknowledgment of Response primitive and goes to step Orig-4.1. If the Response Type is flexBlocking, the Originator shall wait for a Response primitive as in Orig-4.1 and Orig-4.1 below, if the Response primitive is an acknowledgment

~

The Originator or Transit CSE using flexBlocking must always activate all related processes to accommodate both blockingRequest and nonBlockingRequest communication methods until receiving a response containing the Response Type determined by the Receiver CSE.

14 is a diagram for explaining a process for checking whether a Transit CSE accepts both a blocking and a nonBlocking method in a Forward procedure of a Resource handling procedure.

Referring to FIG. 14, the Transit CSE can check whether both blocking and non-blocking methods are acceptable.

In the procedure of FIG. 5, a step of examining whether the response type is flex blocking as shown in FIG. 14 may be added.

Specifically, the following two steps can be performed with reference to FIG.

Recv-6.1.1 Response Type is flexBlocking ?: The Receiver CSE checks whether a received request is flexBlocking by using Response Type parameter (see detail in clause 8.1.2 in TS-0001 [6]). If the request is flexBlocking, it goes to step Recv-6.1.2 "Change the Response Type".

Recv-6.1.2 "Check the capability of communication method" Please refer to clause 7.3.2.9 for details.

The receiving M2M device should check whether it can accept both blockingRequest, nonBlockingRequestSync, and nonBlockingRequestAsync communication methods.

If any of the communication methods can not be accepted, it shall reject the request with a "FLEX_BLOCKING_REQUEST_NOT_SUPPORTED" Response Status Code parameter value and not forward the request.

Table 2 is a table showing an example of adding the FLEX_BLOCKIG_REQUEST_NOT_SUPPORTED error code to the RSCs for Receiver error response class for the checking operation of FIG.

Numeric Code Description 5213 FLEX_BLOCKIG_REQUEST_NOT_SUPPORTED

An M2M device capable of performing all or a part of the above-described embodiments will be briefly described again with reference to the drawings.

Alternatively, the recipient M2M device of FIG. 5 may be configured to check whether the Transit CSE can process the Asynchronous message in the Recv-6.1 procedure.

For example, it is possible to check whether the Transit CSE can process an Asynchronous message, and to set the parameter to be modified so as to request Synchronous message processing when not possible.

Specifically, when the Transit CSE is in an area where the Asynchronous message can not be processed (for example, behind a firewall) and the received request message needs to be forwarded to another CSE by a registrar or the like, the received request message is an Asynchronous message If the response type is nonblockingRequestAsynch or flexBlocking, the transit CSE may modify or set the response type of the received request message to blockingRequest or nonblockingRequestSynch and then send the request message to other CSEs or entities such as registrars . &Lt; / RTI &gt;

For this, the following operation may be performed in the step Recv-6.1 of FIG.

When the receiver is a transit CSE,

- Check if the transit CSE is not able to receive asynchronous messages,

* If yes, check the Response type parameter of the request. If it is set to nonBlockingRequestAsynch or flexBlocking, the transit CSE shall set the ResponseType parameter to blockingRequest or nonBlockingRequestSynch.

- Either CMDH Message Forwarding (Recv-6.9 in FIG. 5) or Forwarding (Recv-6.10 in FIG. 5)

15 is a diagram schematically illustrating a receiving side M2M device according to an embodiment.

15, the receiving side M2M device 1000 according to another embodiment includes a control unit 1010, a transmitting unit 1020, and a receiving unit 1030. [

The control unit 1010 controls the overall operation of the receiving-side M2M device according to the reception-side operation required to perform the above-described present invention.

The transmitting unit 1020 and the receiving unit 1030 are used to transmit and receive signals, messages, and data necessary for carrying out the present invention to the transmitting side or the transmitting M2M device.

In addition, the present embodiments can be implemented by a computer program. For example, each of the above-described steps or configurations may be implemented with respective functions using computer program code. The code and the code segment constituting the program can be easily deduced by a computer programmer in the field. In addition, the created program can be stored in a computer-readable recording medium (information storage medium), and can be read and executed by a computer to implement the present embodiment. And the recording medium includes all types of recording media readable by a computer. Therefore, a storage medium including a computer program or a computer program embodying the above-described embodiments should be construed as being included in the scope of the present embodiment.

The standard content or standard documents referred to in the above-mentioned embodiments constitute a part of this specification, for the sake of simplicity of description of the specification. Therefore, it is to be understood that the content of the above standard content and some of the standard documents is added to or contained in the scope of the present invention, as falling within the scope of the present invention.

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

Claims (1)

A method of transmitting response information from a machine-to-machine communication (M2M)
Receiving a request message;
Confirming a response type parameter corresponding to the request message; And
Determining a response type parameter according to the response type parameter,
Wherein the response type parameter is set to flexblocking.

Images