WO2017007239A1 - M2m 시스템에서 응답 정보를 수신하는 방법 및 그 장치 - Google Patents

M2m 시스템에서 응답 정보를 수신하는 방법 및 그 장치 Download PDF

Info

Publication number
WO2017007239A1
WO2017007239A1 PCT/KR2016/007326 KR2016007326W WO2017007239A1 WO 2017007239 A1 WO2017007239 A1 WO 2017007239A1 KR 2016007326 W KR2016007326 W KR 2016007326W WO 2017007239 A1 WO2017007239 A1 WO 2017007239A1
Authority
WO
WIPO (PCT)
Prior art keywords
response
parameter
request message
message
information
Prior art date
Application number
PCT/KR2016/007326
Other languages
English (en)
French (fr)
Inventor
김상언
Original Assignee
주식회사 케이티
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 주식회사 케이티 filed Critical 주식회사 케이티
Priority to US15/743,270 priority Critical patent/US11095747B2/en
Priority claimed from KR1020160085554A external-priority patent/KR101931858B1/ko
Publication of WO2017007239A1 publication Critical patent/WO2017007239A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications

Definitions

  • the present embodiment relates to a Machine to Machine Communication (M2M) technology, and relates to a procedure for receiving response information on a request message in an M2M system.
  • M2M Machine to Machine Communication
  • 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.
  • MOT typically does not directly perform communication and application control
  • a procedure for transmitting and receiving response information may be set differently for each MTC device or for each request message, a specific procedure for receiving the response information is not disclosed at all according to the transmission and reception procedure of the MTC device transmitting the request message. . Therefore, there is a problem in that an error may occur due to a difference in procedures in transmitting and receiving information between different MTC devices having different message transmission / reception procedures.
  • the present embodiment devised in the background described above proposes a method and apparatus for preventing an error from occurring by dividing a procedure in which an M2M device transmits a request message and receives response information for the request message.
  • the present embodiment is to propose a method and apparatus for allowing a M2M device to perform a procedure for receiving response information according to a response type parameter included in a request message.
  • a method of receiving response information by a machine to machine communication (M2M) device includes: transmitting a request message, checking a response type parameter corresponding to the request message, and responding to the request message; And receiving the response information according to the type parameter, wherein the response type parameter is set to any one of blocking, synchronous nonblocking (nonBlockingRequestSynch), and asynchronous nonblocking (nonBlockingRequestAsynch).
  • M2M machine to machine communication
  • 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 identifying a response type parameter corresponding to the request message, and response information according to the response type parameter; Including a receiving unit for receiving, the response type parameter provides an M2M device, characterized in that is set to any one of blocking (blocking), synchronous non-blocking (nonBlockingRequestSynch) and asynchronous non-blocking (nonBlockingRequestAsynch).
  • blocking blocking
  • nonBlockingRequestSynch synchronous non-blocking
  • nonBlockingRequestAsynch asynchronous non-blocking
  • the present embodiment described above provides an effect that the processing of the request message of the sender essential for M2 communication can be processed without error.
  • the present embodiment allows the M2M device to separately perform a procedure for receiving response information according to a response type parameter included in a request message, so that all resources having various response information transmission / reception procedures can be processed without error. Provide effect.
  • FIG. 1 is a diagram illustrating an M2M system from a high level functional point of view.
  • FIG. 2 is a diagram illustrating in more detail an M2M system configuration diagram according to an embodiment.
  • FIG. 3 is a diagram exemplarily illustrating a procedure of transmitting a request message and corresponding response information in an M2M system.
  • FIG. 4 is a diagram illustrating an operation of receiving response information of an M2M device according to an embodiment.
  • 5 is a view for explaining an operation of receiving response information according to the first embodiment.
  • FIG. 6 illustrates content parameter information according to an exemplary embodiment.
  • FIG. 7 is a diagram illustrating “operationResult” attribute information according to an exemplary embodiment.
  • FIG. 8 is a view for explaining an operation of receiving response information according to the second embodiment.
  • FIG. 9 is a diagram schematically illustrating an M2M device according to an embodiment.
  • 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.
  • M2M Machine to Machine communication
  • MTC Machine Type Communication
  • IoT Internet of Things
  • SDC Smart Device Communication
  • 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.
  • FIG. 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.
  • 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.
  • 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.
  • CSFs Common Service Functions
  • Some of the CSFs in the CSE of the oneM2M node may be mandatory and some may be optional.
  • 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.
  • Mca 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.
  • 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.
  • a common service entity may be described as a CSE
  • a network service entity may be described as an NSE
  • the M2M device in the present specification may mean a CSE or AE, or may mean a device including the CSE or AE.
  • FIG. 2 is a diagram illustrating in more detail an M2M system configuration diagram according to an embodiment.
  • 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.
  • 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.
  • 220 communicates with 100 through 200 using an interface capable of ultra short-range communication such as Bluetooth, ZigBee, Zwave, and WiFi.
  • 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
  • 240 communicates with 100 using ultra-short range communication such as Bluetooth, ZigBee, Zwave, and WiFi. Communicate with
  • 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.
  • the present embodiments relate to a method and a procedure for receiving response information at a request message transmitting side in an M2M system which is essential for preventing an error from occurring.
  • 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.
  • 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. .
  • 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.
  • the present embodiment provides a method in which the originator constructs and transmits a request message, and the originator determines blocking, synchronous non-blocking, and asynchronous non-blocking according to the response type of the receiver.
  • the originator may query the processing result of the receiver to determine whether the processing is completed, and may obtain a result of the processing being completed. If the response type parameter is asynchronous nonblocking, the originator can receive the processing result completion notification information of the receiver, and can use the notification information to obtain a result of the processing being completed.
  • both the originator and the receiver may be M2M devices, and the M2M device for transmitting the request message is described as the originator, and the M2M device for receiving the request message and generating and transmitting the response information is described as the receiver. do.
  • FIG. 3 is a diagram exemplarily illustrating a procedure of transmitting a request message and corresponding response information in an M2M system.
  • the initiator 300 transmits a request message to obtain necessary information (S320).
  • the request message may include required and optional parameters.
  • 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.
  • 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).
  • the receiver 310 may have a different procedure for transmitting a response message according to the setting.
  • 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.
  • 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 invention relates to a procedure for receiving a response message of the originator 300, and proposes a procedure for receiving response information classified according to response type parameters.
  • step S330 with reference to the specific embodiment with respect to step S330 will be described, and the response information receiving procedure according to the response type parameter will be described separately.
  • FIG. 4 is a diagram illustrating an operation of receiving response information of an M2M device according to an embodiment.
  • 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 receiving side parameter, a transmitting side parameter, and a request identification parameter.
  • the M2M device checks the response type parameter corresponding to the request message (S402).
  • the response type parameter may be included in the request message.
  • the response type parameter may be separately set according to a procedure for receiving response information about the request message.
  • the response type parameter may be set to any one of blocking, synchronous nonblockingRequestSynch, and asynchronous nonblockingRequestAsynch. Or, there may be no response type parameter.
  • the M2M device performs the step of receiving the response information according to the response type parameter (S404).
  • the M2M device may receive response information on the request message through different procedures according to the response type parameter checked in step S402.
  • the M2M device waits until the response information is received. That is, the M2M device waits without performing a separate operation until a response message including response information is received.
  • the M2M device waits to receive an acknowledgment message for the request message from the receiver when the response type parameter is set to synchronous nonblocking or asynchronous nonblocking.
  • the acknowledgment message includes Ack information about the request message, and may include information indicating that the receiver has received the request message.
  • the M2M device 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 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.
  • the M2M device checks 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 handling can be performed.
  • the M2M device may receive a notification request message from the receiver.
  • the M2M device generates a notification response message for the notification request message and transmits it to the receiver.
  • the notification request message may include an operation parameter, a receiving side parameter, a transmitting side parameter, a request identification parameter, and a content parameter.
  • the notification response message may 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 a receiver that completes generation of response information according to the request message and transmits the response information to the M2M device.
  • the M2M device may obtain response information by extracting response information from the notification request message.
  • 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 extract the response information by receiving the notification request message.
  • the response information receiving procedure is classified according to the response type parameter, and in transmitting the request message, the M2M device may identify the response type parameter and may perform each procedure.
  • each embodiment may be performed independently, or may be performed in combination with each other, and some steps of each embodiment may be performed in combination with each other.
  • 5 is a view for explaining an operation of receiving response information according to the first embodiment.
  • 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.
  • the operation parameter when the operation parameter is information for creating a schedule, the request message includes a content parameter and a response type parameter.
  • the operation parameter when the operation parameter is information for updating or notifying, the content parameter is included.
  • the operation parameter 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 a "Response Status Code” parameter and a "Request Identifier” parameter.
  • the information of the "Request Identifier” parameter should be the same as the "Request Identifier” parameter of step S505.
  • the M2M device 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 one of blockingRequest, synchronous nonblockingRequestSynch, and asynchronous nonblockingRequestAsynch.
  • the M2M device processes the response message (S570).
  • 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 request message after a predetermined time or a predetermined time in order for the receiver to know whether the processing of the request message is completed (S520).
  • the inquiry request message essentially includes "Operation", "To", "From” and "Request Identifier” parameters. Operation parameters are set to Retrieve.
  • the M2M device receives the inquiry response message of the receiver for the inquiry request message (S525). If the receiver has processed the request message of step S505, the inquiry response message of the receiver essentially includes the "Response Status Code", "Request Identifier” and “Content” parameters. The information of the "Request Identifier” parameter should be the same as "Request Identifier” in the inquiry request message. The information of the "Content” parameter includes response information when the receiver has processed 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 inquiry response message (S530). If the information of the "Response Status Code” parameter is successful (for example, code 2XXX), check the Content parameter, and if there is a Content parameter, determine as Success to 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.
  • step S520 is performed. That is, after a certain time or at a certain time, the M2M device may retransmit the inquiry request message.
  • the M2M device determines that it is an error and ends. 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 an operation result that the receiver responds to using the inquiry response message.
  • 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.
  • 6 shows an example of a ⁇ request> resource in the "Content” parameter according to the present invention.
  • FIG. 7 is an illustration showing "operationResult” attribute information according to the present invention, and the information of the "Request Identifier" parameter in "operation result” should be the same as "Request Identifier” in step S505.
  • the M2M device receives an acknowledgment message of the receiver when the response type parameter constituting the request message is asynchronous nonblockingRequestAsynch. 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.
  • the receiver 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 "Request Identifier" in 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 request message for querying the "Content" parameter of the notification request message (S555).
  • the inquiry request message in step S555 essentially includes the parameters "Operation”, “To”, “From”, and "Request Identifier”. Operation parameters are set to Retrieve.
  • the M2M device receives an inquiry response message from the hosting CSE (S560).
  • the inquiry response message in step S560 essentially includes "Response Status Code", "Request Identifier”, and "Content” parameters.
  • Information of the "Request Identifier” parameter of step S560 should be the same as "Request Identifier” of step S555.
  • the information of the "Content” parameter included in the inquiry response message includes processing result information on the request message of step S505. As described above, the information of the “Content” parameter may be configured as shown in FIG. 6.
  • the M2M device extracts an operation result of the inquiry response message received in step S560 (S565).
  • the processing result is 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) of the resource ⁇ request> in step S560 includes response information about the request message in step S505.
  • the "operationResult" attribute information may be configured as shown in FIG.
  • 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 "Request Identifier" of step S505.
  • FIG. 8 is a view for explaining an operation of receiving response information according to the second embodiment.
  • the M2M device constructs a request message (S800).
  • 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 (S805).
  • the M2M device checks the response type parameter of the request message without receiving the response message (S810).
  • the response type parameter may not exist or may be set to either blocking or synchronous nonblocking or asynchronous nonblocking.
  • 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 (S815).
  • the response message essentially includes the "Response Status Code" and "Request Identifier” parameters and includes response information about the request message.
  • the information of the "Request Identifier" parameter of the response message is the same as "Request Identifier” in step S805. If the information of the response type parameter is a blocking request, the M2M device processes the receiver's response information (S820).
  • the M2M device waits for an acknowledgment message of the receiver (S825).
  • the receiver may transmit an acknowledgment message for the request message to the M2M device.
  • the M2M device sends an inquiry request message after a predetermined time or a predetermined time in order to know whether the request message is completed (S830).
  • the predetermined time or any time may be set in advance or may be set dynamically to correspond to the request message.
  • the inquiry request message may be transmitted at regular intervals.
  • the M2M device may or may not manage the process state in order to process step S830. For example, a case in which the state of the process is not managed to process step S830 in step S825 is indicated by a dotted line. In addition, when managing the state of the process, it is indicated by the solid line.
  • the inquiry request message essentially includes the parameters "Operation", "To", "From", and "Request Identifier". Operation parameters are set to Retrieve.
  • the M2M device receives an inquiry response message for an inquiry request message (S835).
  • the inquiry response message may essentially include parameters "Response Status Code”, "Request Identifier”, and "Content”.
  • the "Request Identifier” parameter information of the inquiry response message is the same as the "Request Identifier” parameter of the inquiry request message.
  • the information of the "Content” parameter may include response information to the request message of step S805 when the receiver processes the request message. If the receiver fails to process the request message of step S805, the inquiry response message may essentially include "Response Status Code" and "Request Identifier” parameters.
  • the M2M device checks the "Response Status Code” parameter of the inquiry response message (S840). 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 S845. That is, if the response status code is 2000 (OK), 2001 (created), 2002 (deleted), or 2004 (changed), and there is a Content parameter, step S840 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 S830.
  • the response status code is 1XXX
  • the inquiry request message is retransmitted after a predetermined time or after a certain time.
  • the information of the "Response Status Code" parameter is the originator error (4XXX) or the reception 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. .
  • 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 S840, the M2M device extracts the response information from the inquiry 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 ⁇ request> resource in the "Content” parameter may be configured as shown in FIG.
  • the "operationResult" attribute information may be configured as shown in FIG.
  • the information of the "Request Identifier" parameter included in the "operation result” attribute information is the same as "Request Identifier" in step S805.
  • the M2M device waits for an acknowledgment message of the receiver (S850). If the receiver confirms the request message, the M2M device receives the acknowledgment message.
  • 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 S855 in step S850 with a dotted line.
  • the M2M device may or may not manage a process for processing step S855 in step S850. In FIG. 8, it is assumed that a process state is not managed.
  • the receiver sends a notification request message to the M2M device, and the M2M device receives the notification request message (S855).
  • 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 notification content (eg, Content) may include response information to the request message transmitted in step S805.
  • the M2M device generates a notification response message for the notification request message (S860).
  • 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 "Request Identifier" in the notification request message.
  • the M2M device sends the generated notification response message to the receiver (S865).
  • 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 S805.
  • the M2M device extracts response information included in the notification request message received in step S855 (S870).
  • 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 notification request message is response information to the request message.
  • the "operationResult" attribute information may be configured as shown in FIG.
  • the M2M device processes the result of the request message by using the extracted response information (S820).
  • "Request Identifier" parameter information in step S820 should be the same as "Request Identifier” parameter information in step S805.
  • the embodiments provide the effect that the processing of the request message of the sender essential for M2 communication can be processed without error.
  • the M2M device can separately perform the procedure for receiving response information according to the response type parameter included in the request message, thereby providing an effect that all devices having various response information transmission / reception procedures can process all resources without error. .
  • FIG. 9 is a diagram schematically illustrating an M2M device according to an embodiment.
  • the M2M 900 apparatus includes a transmitter 920 for transmitting a request message, a controller 910 for identifying a response type parameter corresponding to the request message, and a receiver for receiving response information according to the response type parameter ( 930).
  • the response type parameter may be set to any one of blocking, synchronous nonblockingRequestSynch, and asynchronous nonblockingRequestAsynch.
  • the controller 910 may control to wait until the response information is received.
  • the receiver 930 may further receive an acknowledgment message for the request message when the response type parameter is set to synchronous nonblocking or asynchronous nonblocking.
  • the transmitter 920 may further transmit an inquiry request message, and the receiver 930 may further receive an inquiry response message for the inquiry request message.
  • the controller 910 extracts response information from the inquiry response message, retransmits the inquiry request message, and an error processing operation based on a result of checking the response status code parameter or the content parameter included in the inquiry response message. Any operation may be controlled to be performed.
  • the receiver 930 may further receive a notification request message including notification information.
  • the controller 910 may generate a notification response message for the notification request message and extract response information from the notification request message.
  • the transmitter 920 may further transmit a notification response message.
  • controller 910 may control the overall operation of the M2M apparatus 900 for transmitting the request message according to the above-described embodiments and for classifying and managing the response information receiving procedure according to the response type parameter. .
  • the transmitter 920 and the receiver 30 are used to transmit or receive signals, messages, and data necessary to perform the above-described embodiments.
  • the embodiments may be implemented as a computer program.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Communication Control (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

본 실시예는 M2M(Machine to Machine Communication) 기술에 관한 것으로, M2M 시스템에서 요청 메시지에 대한 응답 정보를 수신하는 절차에 관한 것이다. 특히, 일 실시예에 따른 M2M(Machine to machine communication) 장치는 요청 메시지를 전송하는 단계와 요청 메시지에 대응되는 응답 유형 파라미터를 확인하는 단계 및 응답 유형 파라미터에 따라 응답 정보를 수신하는 단계를 수행하되, 응답 유형 파라미터는 블럭킹(blocking), 동기식 논블럭킹(nonBlockingRequestSynch) 및 비동기식 논블럭킹(nonBlockingRequestAsynch) 중 어느 하나로 설정되는 방법 및 장치를 제공한다.

Description

M2M 시스템에서 응답 정보를 수신하는 방법 및 그 장치
본 실시예는 M2M(Machine to Machine Communication) 기술에 관한 것으로, M2M 시스템에서 요청 메시지에 대한 응답 정보를 수신하는 절차에 관한 것이다.
사물 통신(M2M, "Machine to machine communication" 또는 MTC, "Machine type communication" 또는 스마트 디바이스 통신, "Smart Device communication" 또는 "Machine oriented communication" 또는 사물 인터넷, "Internet of Things")은 사람이 통신 과정에 개입하지 않고 통신이 이루어지는 방식의 모든 통신 방식을 지칭한다. 최근 oneM2M에서 M2M과 관련된 논의가 이루어지고 있으나, oneM2M의 아키텍처(Architecture) 및 요구 사항(Requirement)을 충족시키는 기술적인 요소들이 제시되지 않은 상태이다.
사물통신은 통상적으로 사람이 직접적으로 통신과 응용 제어를 수행하지 않기 때문에, 사물 간에 메시지를 교환하기 위해서 송수신 방법과 절차와 필요하다. 또한, 사물통신 장치 별로 또는 요청 메시지 별로 응답 정보를 송수신하는 절차가 다르게 설정될 수 있으나, 요청 메시지를 전송하는 사물통신 장치는 송수신 절차 별로 구분되어 응답 정보를 수신하는 구체적인 절차가 전혀 개시되어 있지 않다. 따라서, 메시지 송수신 절차가 상이한 사물통신 장치 간에 정보를 송수신함에 있어서 절차의 상이함으로 인해서 에러가 발생될 수 있는 문제점이 있다.
전술한 배경에서 안출된 본 실시예는 M2M 장치가 요청 메시지를 송신하고, 요청 메시지에 대한 응답 정보를 수신하는 절차를 구분하여 에러 발생을 방지하는 방법 및 장치를 제안하고자 한다.
또한, 본 실시예는 M2M 장치가 요청 메시지에 포함되는 응답 유형 파라미터에 따라 응답 정보를 수신하는 절차를 구분하여 수행하도록 하는 방법 및 장치를 제안하고자 한다.
전술한 과제를 해결하기 위한 일 실시예는 M2M(Machine to machine communication) 장치가 응답 정보를 수신하는 방법에 있어서, 요청 메시지를 전송하는 단계와 요청 메시지에 대응되는 응답 유형 파라미터를 확인하는 단계 및 응답 유형 파라미터에 따라 응답 정보를 수신하는 단계를 포함하되, 응답 유형 파라미터는 블럭킹(blocking), 동기식 논블럭킹(nonBlockingRequestSynch) 및 비동기식 논블럭킹(nonBlockingRequestAsynch) 중 어느 하나로 설정되는 방법을 제공한다.
또한, 일 실시예는 응답 정보를 수신하는 M2M(Machine to machine communication) 장치에 있어서, 요청 메시지를 전송하는 송신부와 요청 메시지에 대응되는 응답 유형 파라미터를 확인하는 제어부 및 응답 유형 파라미터에 따라 응답 정보를 수신하는 수신부를 포함하되, 응답 유형 파라미터는 블럭킹(blocking), 동기식 논블럭킹(nonBlockingRequestSynch) 및 비동기식 논블럭킹(nonBlockingRequestAsynch) 중 어느 하나로 설정되는 것을 특징으로 하는 M2M 장치를 제공한다.
이상에서 설명한 본 실시예는 사물통신에 필수적인 송신측의 요청 메시지에 대한 처리를 오류 없이 처리할 수 있는 효과를 제공한다.
또한, 본 실시예는 M2M 장치가 요청 메시지에 포함되는 응답 유형 파라미터에 따라 응답 정보를 수신하는 절차를 구분하여 수행하도록 하여 다양한 응답 정보 송수신 절차를 가지는 모든 디바이스에서 모든 자원을 오류 없이 처리할 수 있는 효과를 제공한다.
도 1은 M2M 시스템을 상위 레벨의 기능적 관점에서 도시한 도면이다.
도 2는 일 실시예에 따른 M2M 시스템 구성도를 보다 구체적으로 도시한 도면이다.
도 3은 M2M 시스템에서 요청 메시지 전송과 이에 따른 응답 정보를 수신하는 절차를 예시적으로 도시한 도면이다.
도 4는 일 실시예에 따른 M2M 장치의 응답 정보 수신 동작을 설명하기 위한 도면이다.
도 5는 제 1 실시예에 따른 응답 정보 수신 동작을 설명하기 위한 도면이다.
도 6은 일 실시예에 따른 컨텐츠 파라미터 정보를 도시한 도면이다.
도 7은 일 실시예에 따른 "operationResult" 속성 정보를 도시한 도면이다.
도 8은 제 2 실시예에 따른 응답 정보 수신 동작을 설명하기 위한 도면이다.
도 9는 일 실시예에 따른 M2M 장치를 개략적으로 도시한 도면이다.
이하, 본 발명의 일부 실시 예들을 예시적인 도면을 통해 상세하게 설명한다. 각 도면의 구성요소들에 참조부호를 부가함에 있어서, 동일한 구성요소들에 대해서는 비록 다른 도면상에 표시되더라도 가능한 한 동일한 부호를 가지도록 하고 있음에 유의해야 한다. 또한, 본 발명을 설명함에 있어, 관련된 공지 구성 또는 기능에 대한 구체적인 설명이 본 발명의 요지를 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명은 생략한다.
또한, 본 발명의 구성 요소를 설명하는 데 있어서, 제 1, 제 2, A, B, (a), (b) 등의 용어를 사용할 수 있다. 이러한 용어는 그 구성 요소를 다른 구성 요소와 구별하기 위한 것일 뿐, 그 용어에 의해 해당 구성 요소의 본질이나 차례 또는 순서 등이 한정되지 않는다. 어떤 구성 요소가 다른 구성요소에 "연결", "결합" 또는 "접속"된다고 기재된 경우, 그 구성 요소는 그 다른 구성요소에 직접적으로 연결되거나 접속될 수 있지만, 각 구성 요소 사이에 또 다른 구성 요소가 "연결", "결합" 또는 "접속"될 수도 있다고 이해되어야 할 것이다.
본 발명의 실시예들은 사물 통신을 중심으로 설명한다. 사물 통신은 M2M(Machine to Machine communication), MTC(Machine Type Communication), IoT(Internet of Things), 스마트 장치 통신(Smart Device Communication, SDC), 또는 사물 지향 통신(Machine Oriented Communication) 등으로 다양하게 불려질 수 있다. 최근 oneM2M에서 사물통신과 관련된 많은 기술적 사항을 제시하고 있다. 사물 통신은 사람이 통신 과정에 개입하지 않고 통신이 이루어지는 다양한 통신을 지칭한다. 사물 통신은 에너지(energy) 분야, 엔터프라이즈(enterprise) 분야, 헬스케어(Healthcare) 분야, 공공 서비스(Public Services) 분야, 주거(Residential) 분야, 리테일(Retail) 분야, 운송(Transportation)분야, 그리고 기타 분야 등으로 나뉘어진다. 본 발명은 상기 분야를 포함하며, 그 외의 분야에도 적용 가능하다.
도 1은 일 실시예에 따른 M2M 시스템을 상위 레벨의 기능적 관점에서 도시한 도면이다.
애플리케이션 개체(Application Entity, AE)(110)은 종단간(end-to-end) M2M 솔루션을 위한 애플리케이션 로직을 제공한다. 일 예로 차량 등의 집단적인 추적 애플리케이션(fleet tracking application), 원격 혈당 감시 애플리케이션(remote blood sugar monitoring application), 또는 원격 전력 검침과 제어 애플리케이션(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.). 공통 서비스 개체(Common Services Entity, CSE)(120)는 서비스 기능의 집합으로써, 이러한 서비스 기능은 M2M 환경에 공통적으로 사용하는 기능이다. 이러한 서비스 기능은 참조점(Reference Points) Mca, Mcc를 통해 다른 기능으로 드러나며, 참조점 Mcn를 이용하여 기반 네트워크 서비스를 이용한다. 일 예로는 데이터 관리(Data Management), 디바이스 관리(Device Management), M2M 구독 관리(M2M Subscription Management), 위치 서비스(Location Service) 등이 될 수 있다. CSE에 의해 제공되는 서브기능(subfunction)은 논리적으로 CSF(Common service function)으로 이해될 수 있다. oneM2M 노드의 CSE내에 CSF 중 일부는 필수적(mandatory)이 되며 일부는 선택적(optional)이 될 수 있다. 마찬가지로 CSF 내의 서브기능들 역시 필수적 또는 선택적이 될 수 있다.
기반 네트워크 서비스 기능(Underlying Network Services Function, NSF)(130)은 공통 서비스 개체에게 서비스를 제공한다. 서비스의 예로는 디바이스 관리, 위치 서비스(location services)와 디바이스 트리거링(device triggering)을 포함한다.
참조점(Reference Points)은 공통 서비스 개체(CSE)에서 지원되는 것으로 Mca 참조점은 애플리케이션 개체와 공통 서비스 개체 간의 통신 플로우를 지시하는 참조점이다. Mcc 참조점은 두 공통 서비스 개체 간의 통신 플로우를 지시하는 참조점이다. Mcn 참조점은 공통 서비스 개체와 하나의 네트워크 서비스 개체간의 통신 플로우를 지시하는 참조점이다.
보다 상세히, Mca 참조점은 하나의 애플리케이션 개체(AE)가 공통 서비스 개체에 의해 지원되는 서비스를 사용할 수 있도록 한다. Mca 참조점을 통해 제공되는 서비스들은 공통 서비스 개체가 제공하는 기능에 의존적이며, 애플리케이션 개체와 공통 서비스 개체는 동일한 물리적 개체에 존재하거나 다른 물리적 개체에 따로 존재할 수 있다. Mcc 참조점은 필요한 기능을 제공하는 다른 공통 서비스 개체의 서비스를 사용하고자 하는 공통 서비스 개체에게 그러한 사용을 가능하게 한다. Mcc 참조점을 통해 제공되는 서비스들은 공통 서비스 개체가 제공하는 기능에 의존적이다. Mcc 참조점은 서로 다른 M2M 노드 간에 지원될 수 있다. Mcn 참조점은 필요한 기능을 제공하는 기반 네트워크의 서비스 개체를 사용하고자 하는 공통 서비스 개체에게 그러한 사용을 가능하게 하며, 이는 전송과 연결 이외의 서비스를 제공한다. Mcn 참조점의 인스턴스(instance)는 기반 네트워크에서 제공되는 서비스에 의존적으로 구현된다. 두 개의 물리적 M2M 노드 간의 정보 교환은 기본 서비스를 제공하는 기반 네트워크의 전송(transport) 및 연결(connectivity) 서비스를 사용할 수 있다.
본 명세서에서는 공통 서비스 개체를 CSE로 기재할 수 있으며, 네트워크 서비스 개체를 NSE로 기재할 수 있다. 또한, 본 명세서에서의 M2M 장치는 CSE 또는 AE를 의미하거나, CSE 또는 AE를 포함하는 장치를 의미할 수 있다.
도 2는 일 실시예에 따른 M2M 시스템 구성도를 보다 구체적으로 도시한 도면이다.
도 2를 참조하면, 기반노드(Infrastructure Node, 250)는 M2M 통신을 제공하는데 필수적인 서버 기능을 수행한다. 기반노드(250)는 기반노드 응용개체(AE, 252)와 기반노드 공통서비스개체(CSE, 254)로 구성된다. 기반노드 공통서비스 개체(254)는 아래에서 설명할 도 3과 같은 자원을 이용하여 구성한다. 252와 254는 Mca 참조점을 통하여 구분하고, 사물통신에 필요한 메시지, 특히 스케줄러 자원의 생성 (create), 삭제 (delete), 갱신 (update), 조회 (retrieve), 통지 (notify)하기 위한 요청메시지와 응답메시지의 구성과 처리에 사용한다.
중계노드(200)는 응용서비스노드(220)와 기반노드(100)의 M2M 통신 또는 Internet of Things, 사물통신 기능을 중계한다. 중계노드(200)는 중계노드 응용개체(202)와 중계노드 공통서비스개체(204)로 구성된다. 중계노드 공통서비스개체 (204)는 도 3과 같은 자원을 이용하여 구성한다. 202와 204는 Mca 참조점을 통하여 구분하며, 254와 204는 Mcc참조점을 이용하여 구분하고, 사물통신에 필요한 메시지, 특히 스케줄러 자원의 생성 (create), 삭제 (delete), 갱신 (update), 조회(retrieve), 통지 (notify)하기 위한 요청메시지와 응답메시지의 구성과 처리에 사용한다.
응용서비스노드(210)는 응용개체(212)와 중계노드 공통서비스개체(214)로 구성할 수 있다. 응용개체(212)는 기기의 목적상 요구되는 응용 기능을 처리한다. 응용서비스노드(210)의 공통서비스개체(214)는 도 3과 같은 자원을 이용하여 구성한다. 212와 214는 Mca 참조점을 통하여 구분하며, 214와 254는 Mcc참조점을 이용하여 구분하고, 사물통신에 필요한 메시지, 특히 스케줄러 자원의 생성(create), 삭제 (delete), 갱신 (update), 조회 (retrieve), 통지 (notify)하기 위한 요청메시지와 응답 메시지의 구성과 처리에 사용한다. 한편, 응용서비스노드(220)는 중계노드(200)를 통하여 기반노드(100)와 사물통신 기능을 수행할 수도 있다. 210과 220의 차이점은 노드를 구성하는 통신 인터페이스가 다른 것이 특징이다. 예를 들어, 220은 블루투스, ZigBee, Zwave, WiFi등의 초근거리 통신이 가능한 인터페이스를 이용하여 200을 통하여 100과 통신한다. 이에 반해, 210은 3G, LTE, Ethernet, Gigabit Ethernet, ADSL등의 통신 인터페이스를 이용하여 100과 통신한다.
응용전용노드(230, 240)는 공통서비스개체를 가지지 않고, 응용개체(242)만을 가지고 사물통신을 하는 경우를 대상으로 한다. 230은 3G, LTE, Ethernet, Gigabit Ethernet, ADSL등의 통신 인터페이스를 이용하여 100과 통신하는 경우이고, 240은 블루투스, ZigBee, Zwave, WiFi등의 초근거리 통신이 가능한 인터페이스를 이용하여 200을 통하여 100과 통신한다.
도 2에서 설명한 바와 같이, M2M 시스템은 기반노드, 중계노드, 응용 서비스 노드 및 응용전용 노드 중 적어도 하나 이상의 노드로 구성될 수 있으며, 각 노드는 CSE 또는 AE를 포함하여 구성될 수 있다. CSE와 AE는 각각의 참조점을 통해서 타 CSE 또는 AE와 통신을 수행할 수 있다.
본 실시예들은 에러 발생을 방지하기 위해서 필수적인 M2M 시스템에서의 요청 메시지 송신측의 응답 정보 수신 방법 및 절차에 관한 것이다.
예를 들면, 주택이나 아파트에서 전기, 가스, 수도 등의 사용량 정보를 월별 또는 일정한 주기로 사물통신을 통하여 제공한다. 이를 위해서는 전기계량기, 가스 검침기, 수도 계량기 등에서 정보를 수집하고 정보를 전송하여야 한다. 이 외에도, 에너지, 기업, 의료, 공공서비스, 주거, 소매, 교통 및 운송 등 다양한 응용을 사물통신에 적용할 수 있으며, 다양한 사물통신 응용 분야는 표 1과 같이 제시될 수 있으나 여기에 한정된 것은 아니다.
Figure PCTKR2016007326-appb-T000001
본 실시예는 이러한 다양한 분야의 M2M 장치 간에 정보를 송수신할 때, 개별 M2M 장치 또는 개별 요청 메시지의 응답 유형에 따라 응답 정보를 수신하는 절차를 구분하여 제공하여 응답 정보를 송수신하는 데에 발생할 수 있는 오류 발생을 방지하기 위한 것이다.
이를 위해서, 본 실시예는 발원자(Originator)가 요청 메시지를 구성하여 전송하고, 수신자(Receiver)의 응답 유형에 따라 발원자가 블럭킹, 동기식논블럭킹, 비동기식논블럭킹을 판단하는 방법을 제공한다. 또한, 응답 유형 파라미터가 동기식논블럭킹인 경우, 발원자는 수신자의 처리 결과를 조회하여 처리 완료 여부를 판단하고, 처리가 완료된 결과를 얻을 수 있다. 만약, 응답 유형 파라미터가 비동기식논블럭킹인 경우, 발원자는 수신자의 처리 결과 완료 통지 정보를 수신하고, 통지 정보를 이용하여 처리가 완료된 결과를 얻을 수 있다.
본 명세서에서의 발원자와 수신자는 모두 M2M 장치가 될 수 있으며, 요청 메시지를 전송하는 M2M 장치를 발원자로 기재하고, 요청 메시지를 수신하고 응답 정보를 생성하여 전송하는 M2M 장치를 수신자로 기재하여 설명한다.
도 3은 M2M 시스템에서 요청 메시지 전송과 이에 따른 응답 정보를 수신하는 절차를 예시적으로 도시한 도면이다.
도 3을 참조하면, 발원자(300)는 필요한 정보를 얻기 위해서 요청 메시지(Request message)를 전송한다(S320). 요청 메시지에는 필수적인 파라미터와 선택적인 파라미터가 포함될 수 있다. 예를 들어, 송신측 파라미터, 수신측 파라미터, 요청 식별 파라미터 및 동작 파라미터는 필수적인 파라미터로 포함된다. 송신측 파라미터는 메시지를 전송하는 발원자에 대한 정보를 포함하고, 수신측 파라미터는 메시지를 수신하는 수신자에 대한 정보를 포함한다. 요청 식별 파라미터는 해당 요청 메시지를 식별하기 위한 유일한 ID 정보를 포함한다. 또한, 동작 파라미터는 요청 메시지에서 요청하는 동작을 구분하기 위한 정보를 포함한다. 동작 파라미터는 생성, 조회, 삭제, 업데이트 및 통지 중 어느 하나로 설정될 수 있다.
수신자(310)는 요청 메시지를 수신하고, 이에 대한 응답 메시지(Response Message)를 생성하여 발원자(300)로 전송한다(S340). 다만, 수신자(310)는 설정에 따라서 응답 메시지를 전송하는 절차가 상이할 수 있다. 또는, 요청 메시지에 포함된 응답 유형 파라미터에 따라 응답 메시지는 다른 절차로 수신될 수 있다. 즉, 수신자(310)가 요청 메시지를 수신한 후 응답 메시지를 전송하는 절차는 상이할 수 있다.
따라서, 발원자(300)는 각각의 수신자(310)의 응답 메시지 처리 절차에 따라서 응답 메시지를 수신하기 위한 일반적인 프로시져를 진행한다(S330). 예를 들어, 발원자(300)는 요청 메시지의 응답 유형 파라미터를 확인하여, 응답 유형 파라미터 별로 다른 절차로 응답 메시지를 수신할 수 있다. 본 발명은 발원자(300)의 응답 메시지 수신 절차에 관한 것으로, 응답 유형 파라미터 별로 구분되는 응답 정보 수신 절차를 제안한다.
이하에서는, S330 단계와 관련하여 보다 구체적인 실시예를 중심으로 설명하며, 응답 유형 파라미터에 따른 응답 정보 수신 절차를 구분하여 설명한다.
도 4는 일 실시예에 따른 M2M 장치의 응답 정보 수신 동작을 설명하기 위한 도면이다.
도 4를 참조하면, M2M 장치는 요청 메시지를 전송하는 단계를 수행한다(S400). 요청 메시지는 동작 파라미터, 수신측 파라미터, 송신측 파라미터 및 요청 식별 파라미터 중 적어도 하나의 파라미터를 포함할 수 있다.
또한, M2M 장치는 요청 메시지에 대응되는 응답 유형 파라미터를 확인하는 단계를 수행한다(S402). 예를 들어, 응답 유형 파라미터는 요청 메시지에 포함될 수 있다. 응답 유형 파라미터는 요청 메시지에 대한 응답 정보를 수신하는 절차에 따라 구분되어 설정될 수 있다. 예를 들어, 응답 유형 파라미터는 블럭킹(blocking), 동기식 논블럭킹(nonBlockingRequestSynch) 및 비동기식 논블럭킹(nonBlockingRequestAsynch) 중 어느 하나로 설정될 수 있다. 또는, 응답 유형 파라미터가 존재하지 않을 수도 있다.
또한, M2M 장치는 응답 유형 파라미터에 따라 응답 정보를 수신하는 단계를 수행한다(S404). M2M 장치는 S402 단계에서 확인한 응답 유형 파라미터에 따라서 요청 메시지에 대한 응답 정보를 서로 다른 절차롤 통해서 수신할 수 있다.
일 예로, M2M 장치는 응답 유형 파라미터가 존재하지 않거나, 블럭킹으로 설정된 경우에 응답 정보가 수신될 때까지 대기한다. 즉, M2M 장치는 응답 정보를 포함하는 응답 메시지가 수신될 때까지 별도의 동작을 수행하지 않고 대기한다.
다른 예로, M2M 장치는 응답 유형 파라미터가 동기식 논블럭킹 또는 비동기식 논블럭킹으로 설정된 경우, 요청 메시지에 대한 수신 확인 메시지를 수신자로부터 수신하기 위해서 대기한다. 수신 확인 메시지는 요청 메시지에 대한 Ack 정보를 포함하는 것으로, 수신자가 요청 메시지를 수신하였음을 나타내는 정보를 포함할 수 있다.
또 다른 예로, M2M 장치는 응답 유형 파라미터가 동기식 논블럭킹으로 설정된 경우, 응답 정보를 수신하기 위한 조회 요청 메시지를 수신자로 전송한다. 조회 요청 메시지는 미리 설정된 주기 또는 일정 시간이 경과한 경우에 전송될 수 있다. M2M 장치는 조회 요청 메시지를 전송한 이후에 조회 요청 메시지에 대한 조회 응답 메시지를 수신한다. 조회 응답 메시지는 응답 상태 코드 파라미터, 요청 식별 파라미터 및 컨텐츠 파라미터를 필수적으로 포함할 수 있다. M2M 장치는 조회 응답 메시지가 수신되면 조회 응답 메시지에 포함되는 응답 상태 코드 파라미터 또는 컨텐츠 파라미터를 확인하고, 응답 정보의 포함 여부에 따라서 조회 요청 메시지를 재전송하거나, 조회 응답 메시지에서 응답 정보를 추출하거나, 에러 처리를 수행할 수 있다.
또 다른 예로, M2M 장치는 응답 유형 파라미터가 비동기식 논블럭킹으로 설정된 경우, 수신자로부터 통지 요청 메시지를 수신할 수 있다. 또한, M2M 장치는 통지 요청 메시지에 대한 통지 응답 메시지를 생성하여 수신자로 전송한다. 통지 요청 메시지는 동작 파라미터, 수신측 파라미터, 송신측 파라미터, 요청 식별 파라미터 및 켄턴츠 파라미터를 포함할 수 있다. 또한, 통지 응답 메시지는 응답 상태 코드 파라미터 및 요청 식별 파라미터를 포함할 수 있다. 통지 응답 메시지에 포함되는 요청 식별 파라미터는 통지 요청 메시지의 요청 식별 파라미터와 동일한 값으로 설정될 수 있다. 통지 요청 메시지는 수신자가 요청 메시지에 따른 응답 정보의 생성을 완료하여 M2M 장치로 전송하는 것으로, M2M 장치는 통지 요청 메시지에서 응답 정보를 추출하여 응답 정보를 획득할 수 있다.
정리하면, M2M 장치는 응답 유형 파라미터에 따라서 응답 정보가 수신될 때까지 기다리거나, 일정 주기로 조회 요청 메시지를 송신하여 응답 정보를 수신하거나, 통지 요청 메시지를 수신하여 응답 정보를 추출할 수 있다. 이러한 응답 정보 수신 절차의 구분은 응답 유형 파라미터에 따라 구분되며, M2M 장치는 요청 메시지를 송신함에 있어서 응답 유형 파라미터를 확인하여, 각 절차를 구분하여 수행할 수 있다.
이하에서는, 전술한 M2M 장치의 응답 정보 수신 절차를 두 가지 실시예로 나누어 설명하며, 각각의 실시예에서 일부 단계는 생략 또는 추가될 수 있다. 또는, 각각의 실시예는 독립적으로 수행되거나, 상호 결합되어 수행될 수도 있으며, 각 실시예의 일부 단계가 상호 결합되어 수행될 수도 있다.
제 1 실시예
도 5는 제 1 실시예에 따른 응답 정보 수신 동작을 설명하기 위한 도면이다.
도 5를 참조하면, M2M 장치는 통신을 수행함에 있어서 요청 메시지를 구성한다(S500). 요청 메시지는 동작(Operation), 수신자(To), 발원자(From), 요청 식별 정보(Request Identifier) 등의 파라미터를 필수적으로 포함한다.
동작(Operation) 파라미터는 생성, 조회, 갱신(업데이트), 삭제, 통지 등 수신자가 처리할 동작에 대한 정보를 표시한다. 일 예로, 동작(Operation) 파라미터가 스케줄을 생성(create)하는 정보인 경우 요청 메시지는 컨텐츠(Content) 파라미터와 응답 유형(Resource Type) 파라미터를 포함한다. 다른 예로, 동작 파라미터가 갱신(update)이나 통지(notify)하는 정보인 경우, 컨텐츠 파라미터를 포함한다. 또 다른 예로, 동작 파라미터가 조회(Retrieve) 정보인 경우, 컨텐츠 파라미터를 포함할 수 있다. 수신자(To) 파라미터는 요청 메시지를 수신하는 응용객체 또는 공통서비스객체를 나타낸다. 발원자(From) 파라미터는 요청 메시지를 생성하고 보내는 응용객체 또는 공통서비스객체를 나타낸다. 요청 식별(Request Identifier) 파라미터는 요청 메시지를 유일하게 식별하기 위한 정보이다.
M2M 장치는 S500 단계에서 구성한 요청 메시지를 수신자로 전송한다(S505). 요청 메시지는 동작(Operation), 수신자(To), 발원자(From), 요청 식별 정보(Request Identifier) 등의 파라미터를 필수적으로 포함한다.
M2M 장치는 수신자의 응답 메시지를 기다린다(S510). 응답메시지는 "응답 상태 코드(Response Status Code)" 파라미터와 "요청 식별(Request Identifier)" 파라미터를 필수적으로 포함한다. "Request Identifier" 파라미터의 정보는 S505 단계의 "Request Identifier"파라미터와 동일하여야 한다.
M2M 장치는 응답 메시지를 수신한 후, 응답 유형(Response Type) 파라미터의 정보를 확인한다(S515). 응답 유형 파라미터는 블록킹(blockingRequest), 동기식논블럭킹(nonBlockingRequestSynch), 비동기식논블럭킹(nonBlockingRequestAsynch)중 어느 하나로 표시된다.
일 예로, 응답 유형(Response Type) 파라미터의 정보가 블록킹(blockingRequest)인 경우, M2M 장치는 응답 메시지를 처리한다(S570).
다른 예로, 응답 유형(Response Type) 파라미터의 정보가 동기식논블록킹(nonBlockingRequestSynch)인 경우, M2M 장치는 수신자로부터 수신 확인(acknowledgement) 메시지를 수신한다. 이는 수신자가 요청메시지를 즉각적으로 처리하지 못하거나, 어떤 사유가 있는 경우, 수신자가 M2M 장치의 요청 메시지를 처리하고 있음을 나타내는 방법이며, M2M 장치만 통신을 시작할 수 있는 경우에 적용된다. M2M 장치는 수신자가 요청 메시지의 처리 완료 여부를 알기 위하여 일정 시간 또는 임의의 시간이 지난 후에 조회 요청 메시지를 보내다(S520). 예를 들어, 조회 요청 메시지는 "Operation", "To", "From" 및 "Request Identifier" 파라미터를 필수적으로 포함한다. 동작 (Operation) 파라미터는 조회(Retrieve)로 설정된다.
M2M 장치는 조회 요청메시지에 대한 수신자의 조회 응답 메시지를 수신한다(S525). 수신자가 S505 단계의 요청 메시지를 처리한 경우, 수신자의 조회 응답 메시지는 "Response Status Code", "Request Identifier" 및 "Content" 파라미터를 필수적으로 포함한다. "Request Identifier" 파라미터의 정보는 조회 요청 메시지의 "Request Identifier"와 같아야 한다. "Content" 파라미터의 정보는 수신자가 S505 단계의 요청 메시지를 처리한 경우, 응답 정보를 포함한다. 수신자가 S505 단계의 요청 메시지를 처리하지 못한 경우, 수신자의 응답 메시지는 "Response Status Code" 및 "Request Identifier" 파라미터를 필수적으로 포함한다.
M2M 장치는 조회 응답 메시지의 "Response Status Code"파라미터를 확인한다(S530). "Response Status Code" 파라미터의 정보가 성공적(예를 들어, 코드 2XXX)인 경우, Content 파라미터를 확인하여, Content 파라미터가 있는 경우, Success로 판단하여 S535 단계를 수행한다. 예를 들어, 응답 상태 파라미터의 코드가 2000(OK)이거나, 2001(created)이거나 2002(deleted)이거나 2004(changed)이고, Content 파라미터가 있는 경우 S530 단계를 수행한다.
"Response Status Code"파라미터의 정보가 수신자의 처리 미완료를 나타내는 정보(예를 들어, Informational(1XXX) 또는 Acknowledge)인 경우, S520 단계를 수행한다. 즉, 일정 시간 후 또는 일정 시점에 M2M 장치는 조회 요청 메시지를 재전송할 수 있다.
M2M 장치는 "Response Status Code"파라미터의 정보가 실패(fail)인 경우에는 오류로 판단하여 종료한다. 예를 들어, M2M 장치는 응답 상태 코드 파라미터가 발원자 오류(4XXX) 또는 수신측 오류(5XXX) 또는 네트워크 오류(6XXX)를 나타내는 경우 오류로 판단하며, 응답 상태 코드가 2XXX라도 Content 파라미터가 없는 경우 오류로 판단한다.
M2M 장치는 조회 응답 메시지를 이용하여 수신자가 응답한 처리 결과 (operation result)를 추출한다. 예를 들어, 처리 결과는 "Content" 파라미터에 있는 <request> 자원의 "operation result" 속성정보에 포함될 수 있다. <request> 자원은 필수적인 속성정보를 포함해야 한다. 필수적인 속성정보는 operation, target, originator, requestID, metaInformation, content, requestStatus, operationResult 속성에 대한 정보이다. 도 6은 본 발명에 의한 "Content" 파라미터에 있는 <request> 자원을 나타낸 예시이다. 도 7은 본 발명에 의한 "operationResult" 속성 정보를 나타낸 예시이며, "operation result"에 있는 "Request Identifier" 파라미터의 정보는 S505 단계의 "Request Identifier"와 같아야 한다.
또 다른 예로, M2M 장치는 요청 메시지를 구성하는 응답 유형(Response Type) 파라미터가 비동기식논블록킹(nonBlockingRequestAsynch)인 경우, 수신자의 수신 확인(acknowledgement) 메시지를 수신한다. 이는 수신자가 요청 메시지를 즉각적으로 처리하지 못하거나, 어떤 사유가 있는 경우, 수신자가 M2M 장치의 요청 메시지를 처리하고 있음을 나타내는 방법이며, M2M 장치나 수신자가 통신을 시작할 수 있는 경우에 적용된다.
수신자가 요청 메시지의 처리를 완료하면, 통지(notify) 요청 메시지를 M2M 장치로 보내고, M2M 장치는 통지 요청 메시지를 수신한다(S540). M2M 장치가 수신한 통지 요청 메시지는 "Operation", "To", "From", "Request Identifier", "Content" 파라미터로 구성된다. 동작(Operation) 파라미터는 통지(Notify)로 설정된다. 통지 요청 메시지의 컨텐츠 파라미터는 처리 결과가 있는 URI 정보를 포함할 수 있다.
M2M 장치는 통지 요청 메시지에 대한 통지 응답 메시지를 생성한다(S545). 통지 응답 메시지는 "Response Status Code" 및 "Request Identifier" 파라미터를 필수적으로 포함한다. 통지 응답 메시지에 포함되는 "Request Identifier" 파라미터의 정보는 통지 요청 메시지의 "Request Identifier"와 같아야 한다.
M2M 장치는 생성한 통지 응답 메시지를 수신자에게 보낸다(S550). 통지 응답 메시지에 포함되는 "To" 파라미터의 정보는 S505 단계의 "To"파라미터의 정보와 동일해야 한다.
M2M 장치는 통지 요청 메시지의 "Content" 파라미터를 조회하기 위한 조회 요청 메시지를 보낸다(S555). S555 단계의 조회 요청 메시지는 "Operation", "To", "From", "Request Identifier" 파라미터를 필수적으로 포함한다. 동작(Operation) 파라미터는 조회(Retrieve)로 설정된다.
M2M 장치는 호스팅 CSE로부터 조회 응답 메시지를 받는다(S560). S560 단계의 조회 응답 메시지는"Response Status Code", "Request Identifier", "Content" 파라미터를 필수적으로 포함한다. S560 단계의 "Request Identifier" 파라미터의 정보는 S555 단계의 "Request Identifier"와 같아야 한다. 조회 응답 메시지에 포함된 "Content" 파라미터의 정보는 S505 단계의 요청 메시지에 대한 처리 결과 정보를 포함한다. 전술한 바와 같이 "Content" 파라미터의 정보는 도 6과 같이 구성될 수 있다.
M2M 장치는 S560 단계에서 수신한 조회 응답 메시지의 처리 결과(operation result)를 추출한다(S565). 처리 결과는 "Content" 파라미터에 있는 <request> 자원의 "operation result" 속성정보이다. <request> 자원은 필수적인 속성정보를 포함해야 한다. 필수적인 속성정보는 operation, target, originator, requestID, metaInformation, content, requestStatus, operationResult 속성에 대한 정보이다. S560 단계의 <request> 자원의 처리결과(operationResult)는 S505 단계의 요청 메시지에 대한 응답 정보를 포함한다. 전술한 바와 같이, "operationResult" 속성 정보는 도 7과 같이 구성될 수 있다.
M2M 장치는 추출된 응답 정보를 이용하여 S505 단계의 요청 메시지에 대한 요청 결과를 처리한다(S570). S570 단계의 "Request Identifier" 파라미터의 정보는 S505 단계의 "Request Identifier"와 같아야 한다.
제 2 실시예
도 8은 제 2 실시예에 따른 응답 정보 수신 동작을 설명하기 위한 도면이다.
도 8을 참조하면, M2M 장치는 요청 메시지를 구성한다(S800). 요청 메시지는 동작(Operation), 수신자(To), 발원자(From), 요청 식별 정보(Request Identifier) 등의 파라미터를 필수적으로 포함한다.
M2M 장치는 구성된 요청 메시지를 수신자로 전송한다(S805).
이후, M2M 장치는 제 1 실시예와 달리 응답 메시지를 수신하지 않고, 요청 메시지의 응답 유형 파라미터를 확인한다(S810). 전술한 바와 같이, 응답 유형 파라미터는 존재하지 않거나, 블럭킹 또는 동기식 논블럭킹 또는 비동기식 논블럭킹 중 어느 하나로 설정될 수 있다.
일 예로, M2M 장치는 요청 메시지의 응답 유형(Response Type) 파라미터가 없는 경우 또는 응답 유형(Response Type) 파라미터가 블록킹인 경우에 수신자의 응답 메시지를 기다린다(S815). 응답 메시지는 "Response Status Code" 및 "Request Identifier" 파라미터를 필수적으로 포함하며 요청 메시지에 대한 응답 정보를 포함한다. 또한, 응답 메시지의 "Request Identifier" 파라미터의 정보는 S805 단계의 "Request Identifier"와 동일하다. 응답 유형(Response Type) 파라미터의 정보가 블록킹(blockingRequest)인 경우, M2M 장치는 수신자의 응답 정보를 처리한다(S820).
다른 예로, 응답 유형(Response Type) 파라미터의 정보가 동기식 논블록킹 (nonBlockingRequestSynch)인 경우, M2M 장치는 수신자의 수신 확인(acknowledgement) 메시지를 기다린다(S825). 수신자는 요청 메시지를 수신하면, 요청 메시지에 대한 수신 확인 메시지를 M2M 장치로 전송할 수 있다.
M2M 장치는 요청 메시지의 처리 완료 여부를 알기 위하여 일정 시간 또는 임의의 시간이 지난 후에 조회 요청 메시지를 보내다(S830). 일정 시간 또는 임의의 시간은 미리 설정될 수도 있고, 요청 메시지에 대응되도록 동적으로 설정될 수도 있다. 또는, 조회 요청 메시지는 일정 주기로 전송될 수도 있다. 이때 M2M 장치는 S830 단계를 처리하기 위하여 프로세스 상태를 관리하거나, 관리하지 않을 수 있다. 예를 들어, S825 단계에서 S830 단계를 처리하기 위하여 프로세스의 상태를 관리하지 않는 경우를 점선으로 표시한다. 또한, 프로세스의 상태를 관리하는 경우 실선으로 표시한다. 조회 요청 메시지는 "Operation", "To", "From", "Request Identifier" 파라미터를 필수적으로 포함한다. 동작(Operation) 파라미터는 조회(Retrieve)로 설정된다.
이후, M2M 장치는 조회 요청메시지에 대한 조회 응답 메시지를 수신한다(S835). 수신자가 S805 단계에서 전송한 요청 메시지를 처리한 경우, 조회 응답 메시지는 "Response Status Code", "Request Identifier", "Content" 파라미터를 필수적으로 포함할 수 있다. 조회 응답 메시지의 "Request Identifier" 파라미터 정보는 조회 요청 메시지의 "Request Identifier" 파라미터와 같다. "Content" 파라미터의 정보는 수신자가 요청 메시지를 처리한 경우, S805 단계의 요청 메시지에 대한 응답 정보를 포함할 수 있다. 수신자가 S805 단계의 요청 메시지를 처리하지 못한 경우, 조회 응답 메시지는 "Response Status Code", "Request Identifier" 파라미터를 필수적으로 포함할 수 있다.
M2M 장치는 조회 응답 메시지의 "Response Status Code"파라미터를 확인한다(S840). 일 예를 들어, "Response Status Code" 파라미터의 정보가 성공적(예를 들어, 코드 2XXX)인 경우, M2M 장치는 Content 파라미터를 확인하고, Content 파라미터가 있는 경우 S845 단계를 수행한다. 즉, 응답 상태 코드가 2000(OK)이거나, 2001(created)이거나 2002(deleted)이거나 2004(changed)이고, Content 파라미터가 있는 경우 S840 단계를 수행한다. 다른 예를 들어, "Response Status Code"파라미터의 정보가 수신자가 처리를 계속하는 것을 나타내는 정보인 경우, M2M 장치는 S830 단계를 수행한다. 즉, 응답 상태 코드가 1XXX인 경우, 일정 시간 이후 또는 임의의 시간 이후에 조회 요청 메시지를 재전송한다. 또 다른 예로, "Response Status Code" 파라미터의 정보가 발원자 오류(4XXX) 또는 수신측 오류(5XXX) 또는 네트워크 오류(6XXX) 또는 2XXX이며 Content 파라미터가 없는 경우에, M2M 장치는 오류 판단하여 종료한다.
M2M 장치는 S840 단계에서 응답 상태 코드 파라미터 및 컨텐츠 파라미터를 확인한 결과 응답 정보가 포함되었다고 판단되면, 조회 응답 메시짖에서 응답 정보를 추출한다. 응답 정보는 "Content" 파라미터에 있는 <request> 자원의 "operation result" 속성정보에 포함될 수 있다. <request> 자원은 필수적인 속성정보를 포함해야 한다. 필수적인 속성정보는 operation, target, originator, requestID, metaInformation, content, requestStatus, operationResult 속성에 대한 정보이다. 전술한 바와 같이, "Content" 파라미터에 있는 <request> 자원은 도 6과 같이 구성될 수 있다. 또한, "operationResult" 속성 정보는 도 7과 같이 구성될 수 있다. "operation result" 속성 정보에 포함되는 "Request Identifier" 파라미터의 정보는 S805 단계의 "Request Identifier"와 동일하다.
또 다른 예로, 요청 메시지를 구성하는 응답 유형(Response Type) 파라미터가 비동기식 논블록킹(nonBlockingRequestAsynch)인 경우, M2M 장치는 수신자의 수신 확인(acknowledgement) 메시지를 기다린다(S850). M2M 장치는 수신자가 요청 메시지를 확인한 경우, 수신 확인 메시지를 수신한다. 한편, 비동기식 논블록킹(nonBlockingRequestAsynch) 방식은 M2M 장치가 S850 단계에서 S855 단계를 처리하기 위하여 프로세스의 상태를 관리하지 않는 경우를 점선으로 표시한다. 또한 프로세스의 상태를 관리하는 경우 실선으로 표시한다. M2M 장치는 S850 단계에서 S855 단계를 처리하기 위한 프로세스를 관리할 수도 있고, 관리하지 않을 수도 있다. 도 8에서는 프로세스 상태를 관리하지 않는 경우를 가정하여 설명한다.
만약, 수신자가 요청 메시지의 처리를 완료하면, 통지(notify) 요청 메시지를 M2M 장치에게 전송하고, M2M 장치는 통지 요청 메시지를 수신한다(S855). M2M 장치가 수신한 통지 요청 메시지는 "Operation", "To", "From", "Request Identifier", "Content" 파라미터로 구성된다. 동작(Operation) 파라미터는 통지(Notify)로 설정된다. 통지 내용(예를 들어, Content)은 S805 단계에서 전송한 요청 메시지에 대한 응답 정보를 포함할 수 있다.
M2M 장치는 통지 요청 메시지에 대한 통지 응답 메시지를 생성한다(S860). 통지 응답 메시지는 "Response Status Code" 및 "Request Identifier" 파라미터를 필수적으로 포함한다. 통지 응답 메시지에 포함되는 "Request Identifier" 파라미터의 정보는 통지 요청 메시지의 "Request Identifier"와 같아야 한다.
M2M 장치는 생성한 통지 응답 메시지를 수신자에게 보낸다(S865). 통지 응답 메시지에 포함되는 "To" 파라미터의 정보는 S805 단계의 "To"파라미터의 정보와 동일해야 한다.
M2M 장치는 S855 단계에서 수신한 통지 요청 메시지에 포함된 응답 정보를 추출한다(S870). 응답 정보는 "Content" 파라미터에 있는 <request> 자원의 "operation result" 속성정보에 포함될 수 있다. <request> 자원은 필수적인 속성정보를 포함해야 한다. 필수적인 속성정보는 operation, target, originator, requestID, metaInformation, content, requestStatus, operationResult 속성에 대한 정보이다. 통지 요청 메시지의 <request> 자원에 포함되는 처리결과(operationResult)는 요청 메시지에 대한 응답 정보이다. 예를 들어, "operationResult" 속성 정보는 도 6과 같이 구성될 수 있다.
이후, M2M 장치는 추출된 응답 정보를 이용하여 요청 메시지에 대한 결과를 처리한다(S820). S820 단계의 "Request Identifier" 파라미터 정보는 S805 단계의 "Request Identifier"파라미터 정보와 같아야 한다.
이상에서 설명한 바와 같이, 본 실시예들은 사물통신에 필수적인 송신측의 요청 메시지에 대한 처리를 오류 없이 처리할 수 있는 효과를 제공한다. 또한, M2M 장치가 요청 메시지에 포함되는 응답 유형 파라미터에 따라 응답 정보를 수신하는 절차를 구분하여 수행하도록 하여 다양한 응답 정보 송수신 절차를 가지는 모든 디바이스에서 모든 자원을 오류 없이 처리할 수 있는 효과를 제공한다.
전술한 본 실시예들의 전부 또는 일부를 모두 수행할 수 있는 M2M 장치에 대해서 도면을 참조하여 간략히 다시 설명한다.
도 9는 일 실시예에 따른 M2M 장치를 개략적으로 도시한 도면이다.
도 9를 참조하면, M2M(900) 장치는 요청 메시지를 전송하는 송신부(920)와 요청 메시지에 대응되는 응답 유형 파라미터를 확인하는 제어부(910) 및 응답 유형 파라미터에 따라 응답 정보를 수신하는 수신부(930)를 포함할 수 있다. 응답 유형 파라미터는 블럭킹(blocking), 동기식 논블럭킹(nonBlockingRequestSynch) 및 비동기식 논블럭킹(nonBlockingRequestAsynch) 중 어느 하나로 설정될 수 있다.
또한, 제어부(910)는 응답 유형 파라미터가 존재하지 않거나, 블럭킹으로 설정된 경우, 응답 정보가 수신될 때까지 대기하도록 제어할 수 있다. 수신부(930)는 응답 유형 파라미터가 동기식 논블럭킹 또는 비동기식 논블럭킹으로 설정된 경우, 요청 메시지에 대한 수신 확인 메시지를 더 수신할 수 있다.
또는, 응답 유형 파라미터가 동기식 논블럭킹으로 설정된 경우, 송신부(920)는 조회 요청 메시지를 더 전송하고, 수신부(930)는 조회 요청 메시지에 대한 조회 응답 메시지를 더 수신할 수 있다. 또한, 제어부(910)는 조회 응답 메시지에 포함되는 응답 상태 코드 파라미터 또는 컨텐츠 파라미터를 확인한 결과에 기초하여, 조회 응답 메시지에서 응답 정보를 추출하는 동작, 조회 요청 메시지를 재전송하는 동작 및 에러 처리 동작 중 어느 하나의 동작이 수행되도록 제어할 수 있다.
또는, 응답 유형 파라미터가 비동기식 논블럭킹으로 설정된 경우, 수신부(930)는 통지 정보를 포함하는 통지 요청 메시지를 더 수신할 수 있다. 제어부(910)는 통지 요청 메시지에 대한 통지 응답 메시지를 생성하고, 통지 요청 메시지로부터 응답 정보를 추출할 수 있다. 송신부(920)는 통지 응답 메시지를 더 전송할 수 있다.
이 외에도, 제어부(910)는 전술한 본 실시예들에 따른 요청 메시지를 전송하고, 응답 유형 파라미터에 따라 응답 정보 수신 절차를 구분하여 관리하기 위한 전반적인 M2M 장치(900)의 동작을 제어할 수 있다.
한편, 송신부(920)와 수신부(30)는 전술한 본 실시예들을 수행하기에 필요한 신호나 메시지, 데이터를 송수신 또는 전달하는데 사용된다.
또한, 본 실시예들은 컴퓨터 프로그램으로 구현될 수 있다. 예를 들어, 전술한 각 단계 또는 구성은 컴퓨터 프로그램 코드를 이용하여 각 기능으로 구현될 수 있다. 해당 프로그램을 구성하는 코드 및 코드 세그먼트는 당해 분야의 컴퓨터 프로그래머에 의하여 용이하게 추론될 수 있다.　또한, 상기 작성된 프로그램은 컴퓨터가 읽을 수 있는 기록매체(정보저장매체)에 저장되고, 컴퓨터에 의하여 판독되고 실행됨으로써 본 실시예를 구현할 수 있다. 그리고 상기 기록매체는 컴퓨터가 판독할 수 있는 모든 형태의 기록매체를 포함한다. 따라서, 전술한 본 실시예들을 구현한 컴퓨터 프로그램 또는 컴퓨터 프로그램을 포함하는 저장매체는 본 실시예의 범위에 포함되는 것으로 해석되어야 한다.
전술한 실시예에서 언급한 표준내용 또는 표준문서들은 명세서의 설명을 간략하게 하기 위해 생략한 것으로 본 명세서의 일부를 구성한다. 따라서, 위 표준내용 및 표준문서들의 일부의 내용을 본 명세서에 추가하거나 청구범위에 기재하는 것은 본 발명의 범위에 해당하는 것으로 해석되어야 한다.
이상의 설명은 본 발명의 기술 사상을 예시적으로 설명한 것에 불과한 것으로서, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자라면 본 발명의 본질적인 특성에서 벗어나지 않는 범위에서 다양한 수정 및 변형이 가능할 것이다. 따라서, 본 발명에 개시된 실시예들은 본 발명의 기술 사상을 한정하기 위한 것이 아니라 설명하기 위한 것이고, 이러한 실시예에 의하여 본 발명의 기술사상의 범위가 한정되는 것은 아니다. 본 발명의 보호 범위는 아래의 청구범위에 의하여 해석되어야 하며, 그와 동등한 범위 내에 있는 모든 기술 사상은 본 발명의 권리범위에 포함되는 것으로 해석되어야 할 것이다.
CROSS-REFERENCE TO RELATED APPLICATION
본 특허출원은 2015년 07월 09일 한국에 출원한 특허출원번호 제 10-2015-0097960 호 및 2015년 07월 29일 한국에 출원한 특허출원번호 제 10-2015-0107329호 및 2016년 07월 06일 한국에 출원한 특허출원번호 제 10-2016-0085554 호에 대해 미국 특허법 119(a)조 (35 U.S.C § 119(a))에 따라 우선권을 주장하며, 그 모든 내용은 참고문헌으로 본 특허출원에 병합된다. 아울러, 본 특허출원은 미국 이외에 국가에 대해서도 위와 동일한 이유로 우선권을 주장하면 그 모든 내용은 참고문헌으로 본 특허출원에 병합된다.

Claims (17)

  1. M2M(Machine to machine communication) 장치가 응답 정보를 수신하는 방법에 있어서,
    요청 메시지를 전송하는 단계;
    상기 요청 메시지에 대응되는 응답 유형 파라미터를 확인하는 단계; 및
    상기 응답 유형 파라미터에 따라 응답 정보를 수신하는 단계를 포함하되,
    상기 응답 유형 파라미터는,
    블럭킹(blocking), 동기식 논블럭킹(nonBlockingRequestSynch) 및 비동기식 논블럭킹(nonBlockingRequestAsynch) 중 어느 하나로 설정되는 것을 특징으로 하는 방법.
  2. 제 1 항에 있어서,
    상기 요청 메시지는,
    동작 파라미터, 수신측 파라미터, 송신측 파라미터 및 요청 식별 파라미터 중 적어도 하나의 파라미터를 포함하는 방법.
  3. 제 1 항에 있어서,
    상기 응답 유형 파라미터가 존재하지 않거나, 상기 블럭킹으로 설정된 경우,
    상기 응답 정보가 수신될 때까지 대기하는 것을 특징으로 하는 방법.
  4. 제 1 항에 있어서,
    상기 응답 유형 파라미터가 상기 동기식 논블럭킹 또는 상기 비동기식 논블럭킹으로 설정된 경우,
    상기 응답 정보를 수신하기 이전에 상기 요청 메시지에 대한 수신 확인 메시지를 수신하는 단계를 더 포함하는 방법.
  5. 제 1 항에 있어서,
    상기 응답 유형 파라미터가 상기 동기식 논블럭킹으로 설정된 경우,
    상기 응답 정보를 수신하기 이전에 조회 요청 메시지를 전송하는 단계를 더 포함하는 방법.
  6. 제 5 항에 있어서,
    상기 조회 요청 메시지에 대한 조회 응답 메시지를 수신하는 단계를 더 포함하되,
    상기 조회 응답 메시지는,
    응답 상태 코드 파라미터, 요청 식별 파라미터 및 컨텐츠 파라미터를 포함하는 방법.
  7. 제 6 항에 있어서,
    상기 응답 상태 코드 파라미터 또는 상기 컨텐츠 파라미터를 확인한 결과에 따라 상기 조회 응답 메시지에서 상기 응답 정보를 추출하는 동작, 상기 조회 요청 메시지를 재전송하는 동작 및 에러 처리 동작 중 어느 하나의 동작을 수행하는 것을 특징으로 하는 방법.
  8. 제 1 항에 있어서,
    상기 응답 유형 파라미터가 비동기식 논블럭킹으로 설정된 경우,
    통지 정보를 포함하는 통지 요청 메시지를 수신하는 단계;
    상기 통지 요청 메시지에 대한 통지 응답 메시지를 생성하는 단계; 및
    상기 통지 응답 메시지를 전송하는 단계를 더 포함하는 방법.
  9. 제 8 항에 있어서,
    상기 통지 요청 메시지는,
    동작 파라미터, 수신측 파라미터, 송신측 파라미터, 요청 식별 파라미터 및 상기 통지 정보를 포함하는 컨텐츠 파라미터를 포함하는 것을 특징으로 하는 방법.
  10. 제 8 항에 있어서,
    상기 통지 응답 메시지는,
    응답 상태 코드 파라미터 및 요청 식별 파라미터를 포함하되,
    상기 요청 식별 파라미터는 상기 통지 요청 메시지의 요청 식별 파라미터와 동일하게 설정되는 것을 특징으로 하는 방법.
  11. 제 8 항에 있어서,
    상기 통지 요청 메시지로부터 상기 응답 정보를 추출하는 단계를 더 포함하는 방법.
  12. 응답 정보를 수신하는 M2M(Machine to machine communication) 장치에 있어서,
    요청 메시지를 전송하는 송신부;
    상기 요청 메시지에 대응되는 응답 유형 파라미터를 확인하는 제어부; 및
    상기 응답 유형 파라미터에 따라 응답 정보를 수신하는 수신부를 포함하되,
    상기 응답 유형 파라미터는,
    블럭킹(blocking), 동기식 논블럭킹(nonBlockingRequestSynch) 및 비동기식 논블럭킹(nonBlockingRequestAsynch) 중 어느 하나로 설정되는 것을 특징으로 하는 M2M 장치.
  13. 제 12 항에 있어서,
    상기 제어부는,
    상기 응답 유형 파라미터가 존재하지 않거나, 상기 블럭킹으로 설정된 경우,
    상기 응답 정보가 수신될 때까지 대기하도록 제어하는 것을 특징으로 하는 M2M 장치.
  14. 제 12 항에 있어서,
    상기 수신부는,
    상기 응답 유형 파라미터가 상기 동기식 논블럭킹 또는 상기 비동기식 논블럭킹으로 설정된 경우,
    상기 요청 메시지에 대한 수신 확인 메시지를 수신하는 것을 특징으로 하는 M2M 장치.
  15. 제 12 항에 있어서,
    상기 응답 유형 파라미터가 상기 동기식 논블럭킹으로 설정된 경우,
    상기 송신부는, 조회 요청 메시지를 전송하고,
    상기 수신부는, 상기 조회 요청 메시지에 대한 조회 응답 메시지를 수신하는 것을 특징으로 하는 M2M 장치.
  16. 제 15 항에 있어서,
    상기 제어부는,
    상기 조회 응답 메시지에 포함되는 응답 상태 코드 파라미터 또는 컨텐츠 파라미터를 확인한 결과에 기초하여,
    상기 조회 응답 메시지에서 상기 응답 정보를 추출하는 동작, 상기 조회 요청 메시지를 재전송하는 동작 및 에러 처리 동작 중 어느 하나의 동작이 수행되도록 제어하는 것을 특징으로 하는 M2M 장치.
  17. 제 12 항에 있어서,
    상기 응답 유형 파라미터가 비동기식 논블럭킹으로 설정된 경우,
    상기 수신부는, 통지 정보를 포함하는 통지 요청 메시지를 수신하고,
    상기 제어부는, 상기 통지 요청 메시지에 대한 통지 응답 메시지를 생성하고, 상기 통지 요청 메시지로부터 상기 응답 정보를 추출하며,
    상기 송신부는, 상기 통지 응답 메시지를 전송하는 것을 특징으로 하는 M2M 장치.
PCT/KR2016/007326 2015-07-09 2016-07-06 M2m 시스템에서 응답 정보를 수신하는 방법 및 그 장치 WO2017007239A1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US15/743,270 US11095747B2 (en) 2015-07-09 2016-07-06 Method and apparatus for receiving response information in M2M system

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
KR20150097960 2015-07-09
KR10-2015-0097960 2015-07-09
KR10-2015-0107329 2015-07-29
KR20150107329 2015-07-29
KR10-2016-0085554 2016-07-06
KR1020160085554A KR101931858B1 (ko) 2015-07-09 2016-07-06 M2m 시스템에서 응답 정보를 수신하는 방법 및 그 장치

Publications (1)

Publication Number Publication Date
WO2017007239A1 true WO2017007239A1 (ko) 2017-01-12

Family

ID=57685794

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2016/007326 WO2017007239A1 (ko) 2015-07-09 2016-07-06 M2m 시스템에서 응답 정보를 수신하는 방법 및 그 장치

Country Status (1)

Country Link
WO (1) WO2017007239A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108206856A (zh) * 2017-09-30 2018-06-26 中兴通讯股份有限公司 信息反馈方法及装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140073367A1 (en) * 2011-07-14 2014-03-13 Joey Chou Machine-to-machine (m2m) communications using short message services (sms)
US8868092B2 (en) * 2011-06-15 2014-10-21 Lg Electronics Inc. Method and apparatus for transmitting data in wireless communication system
US8891424B2 (en) * 2011-10-16 2014-11-18 Lg Electronics Inc. Method and device for monitoring paging message
US8929339B2 (en) * 2010-05-04 2015-01-06 Lg Electronics Inc. M2M device which performs communication during network entry and handover, and corresponding method for performing communication
WO2015069038A1 (ko) * 2013-11-08 2015-05-14 엘지전자 주식회사 M2m 통신 시스템에서 구독 및 통지를 위한 방법 및 이를 위한 장치

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8929339B2 (en) * 2010-05-04 2015-01-06 Lg Electronics Inc. M2M device which performs communication during network entry and handover, and corresponding method for performing communication
US8868092B2 (en) * 2011-06-15 2014-10-21 Lg Electronics Inc. Method and apparatus for transmitting data in wireless communication system
US20140073367A1 (en) * 2011-07-14 2014-03-13 Joey Chou Machine-to-machine (m2m) communications using short message services (sms)
US8891424B2 (en) * 2011-10-16 2014-11-18 Lg Electronics Inc. Method and device for monitoring paging message
WO2015069038A1 (ko) * 2013-11-08 2015-05-14 엘지전자 주식회사 M2m 통신 시스템에서 구독 및 통지를 위한 방법 및 이를 위한 장치

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108206856A (zh) * 2017-09-30 2018-06-26 中兴通讯股份有限公司 信息反馈方法及装置
CN108206856B (zh) * 2017-09-30 2021-11-30 中兴通讯股份有限公司 信息反馈方法及装置

Similar Documents

Publication Publication Date Title
WO2017023019A1 (en) Method and apparatus for controlling visitor call in home network system
KR101931858B1 (ko) M2m 시스템에서 응답 정보를 수신하는 방법 및 그 장치
WO2013085088A1 (ko) Ｍ２ｍ 통신에서 장치의 데이터 공유 방법 및 그 시스템
CN103220292A (zh) 跨安全区数据传输方法和系统
WO2012157940A2 (ko) 피드백메시지를 이용한 푸시 서비스 제공 시스템 및 방법
CN109922144B (zh) 用于处理数据的方法和装置
WO2017074034A1 (ko) 이종 시스템에서 상호연동에 대한 방법 및 장치
WO2012169865A2 (ko) 인터넷 명함 관리 방법 및 시스템
KR20090079396A (ko) ＵＰｎＰ 원격 프로토콜을 지원하는 홈 네트워크에서 제3의장치의 이벤트를 처리하는 방법 및 장치
CN101815106B (zh) 动态gre隧道建立的方法和设备
WO2013048038A2 (ko) 미디어 키 관리 및 상기 미디어 키를 이용한 피어-투-피어 메시지 송수신 시스템 및 방법
WO2011136526A2 (en) Method for providing message and device therefor
CN113765976A (zh) 一种通信方法和系统
WO2010008248A2 (en) A method and an apparatus for controlling messages between host and controller.
WO2017007239A1 (ko) M2m 시스템에서 응답 정보를 수신하는 방법 및 그 장치
JP5454992B2 (ja) 映像ネットワークシステム
JP6666179B2 (ja) ドアホン制御装置、ドアホンシステム及びドアホン制御方法
CN109144919B (zh) 一种接口转接方法及装置
WO2014189263A1 (ko) 디스커버리 방법 및 장치
KR20180039551A (ko) Receiver CSE에서 효율적인 자원관리 위해 flexBlocking communication method를 처리하는 방법
KR20180039198A (ko) Receiver CSE에서 request/response primitive를 정상적으로 처리하기 위한 Generic Procedure
JP4555783B2 (ja) 一斉データ配信システムおよび一斉データ配信方法
JP4555782B2 (ja) 一斉データ配信システムおよび一斉データ配信方法
KR101960608B1 (ko) M2m 시스템에서 응답 메시지를 수신하는 방법 및 그 장치
WO2018066917A1 (ko) M2m 시스템에서 응답 메시지를 수신하는 방법 및 그 장치

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16821645

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15743270

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16821645

Country of ref document: EP

Kind code of ref document: A1