WO2018236179A1 - M2m 시스템에서 메시지를 처리하는 방법 및 그 장치 - Google Patents

M2m 시스템에서 메시지를 처리하는 방법 및 그 장치 Download PDF

Info

Publication number
WO2018236179A1
WO2018236179A1 PCT/KR2018/007070 KR2018007070W WO2018236179A1 WO 2018236179 A1 WO2018236179 A1 WO 2018236179A1 KR 2018007070 W KR2018007070 W KR 2018007070W WO 2018236179 A1 WO2018236179 A1 WO 2018236179A1
Authority
WO
WIPO (PCT)
Prior art keywords
resource
information
target resource
parameter
request message
Prior art date
Application number
PCT/KR2018/007070
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
Priority claimed from KR1020180071308A external-priority patent/KR102051839B1/ko
Application filed by 주식회사 케이티 filed Critical 주식회사 케이티
Priority to US16/626,280 priority Critical patent/US11533597B2/en
Publication of WO2018236179A1 publication Critical patent/WO2018236179A1/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

  • This embodiment relates to M2M (Machine to Machine Communication) technology, and relates to a method and apparatus for a receiver to process a request message sent by a sender.
  • M2M Machine to Machine Communication
  • MTC Machine Communication
  • Smart Device Communication or “Machine oriented communication” or “Internet of Things” In which communication is performed without intervening in the network.
  • a plurality of object communication devices are used in the home and office, and a plurality of object communication devices performing the same or similar functions are deployed for a certain purpose.
  • each object communication device can store, manage and process data using different protocols.
  • each object communication device can manage and transmit data using different media types or encoding types, and the like. Therefore, it may be difficult to smoothly exchange information between object communication apparatuses using different encoding types or the like.
  • the M2M device when the M2M device receives a request message from another M2M device, a specific method for increasing the efficiency of information exchange by separately managing data type information on the processed resource according to the request message And apparatus.
  • One embodiment for solving the above-mentioned problem is a method for processing a message in a machine-to-machine communication (M2M) apparatus, comprising: receiving a request message including an operation parameter, a reception-side parameter, a transmission- Processing the target resource according to the operation indicated by the operation parameter including the step of receiving from the apparatus and the attribute information indicating the resource information, and transmitting the response message including the response information to the request message ≪ / RTI >
  • M2M machine-to-machine communication
  • a machine-to-machine communication (M2M) apparatus for processing a message includes a receiving unit that receives a request message including an operation parameter, a receiving-side parameter, a transmitting-side parameter, A controller for processing the target resource according to an operation indicated by the operation parameter including attribute information indicating information, and a transmitter for transmitting a response message including response information for the request message.
  • M2M machine-to-machine communication
  • the present disclosure provides an effect of extracting data more quickly and efficiently through messages transmitted and received between different M2M devices.
  • the present disclosure also provides the effect of preventing the occurrence of errors throughout the M2M system arising from the ambiguity of the data processing type.
  • 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.
  • FIG. 4 is a diagram illustrating a functional structure of a common service entity according to an embodiment.
  • FIG. 5 is a diagram for explaining a procedure for processing a request message for ⁇ timeSeriesInstance> resource creation according to an embodiment.
  • FIG. 6 is an exemplary diagram illustrating a message code and a response message code according to an operation parameter of a request message according to an exemplary embodiment of the present invention.
  • FIG. 7 is a diagram for explaining a content processing method expressed in various ways according to a data processing method.
  • FIG. 8 is a view for explaining an operation of processing a target resource according to a conventional request message.
  • FIG. 9 is a diagram for explaining a processing operation for a request message for requesting an inquiry about a target resource according to an embodiment.
  • FIG. 10 is a diagram exemplarily showing a code of a request message for inquiring a ⁇ timeSeriesInstance > resource according to an embodiment.
  • FIG. 11 is an exemplary diagram illustrating a code of a response message to the request message of FIG. 10 according to an embodiment.
  • FIG. 12 is a diagram for explaining an operation of extracting information through the response message of FIG.
  • FIG. 13 is a view for explaining the operation of the M2M device according to an embodiment.
  • FIG. 14 is an exemplary diagram illustrating a structure of a time series resource including a ContentInfo attribute resource according to an embodiment.
  • 15 is a diagram illustrating a structure of a time series instant resource including a ContentInfo attribute resource according to an exemplary embodiment.
  • 16 is a view for explaining an operation of extracting information in a response message according to an inquiry request message for time series instantaneous resources according to an embodiment.
  • 17 is a diagram illustrating a structure of an M2M device according to an embodiment.
  • 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.
  • 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 .
  • M2M Machine to Machine communication
  • MTC Machine Type Communication
  • IoT Internet of Things
  • SDC Smart Device Communication
  • Object communication refers to various communication in which communication is performed without a person intervening in the communication process.
  • 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.
  • FIG. 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 service logic for an end-to-end M2M solution.
  • a fleet tracking application such as a vehicle, a remote blood sugar monitoring application, or a remote power metering and controlling application.
  • the Common Services Entity (CSE) 120 may be used for various services such as an energy field, an enterprise field, a healthcare field, a public service field, a residential field, ), Transportation (transportation), and other fields.
  • CSE Common Services Entity
  • 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.
  • One example of the common service entity may be 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.
  • Mca reference point is a reference point for providing object communication between an application entity and a common service entity.
  • the Mcc reference point is a reference point for providing communications between the two common service entities.
  • the Mcn reference point is a reference point for providing object communication between a 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.
  • 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.
  • a common service entity can be described as a CSE
  • a network service entity can be described as a network service entity (NSE).
  • the M2M device means CSE or AE
  • FIG. 2 is a view showing a more detailed structure of the M2M system according to one embodiment.
  • 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.
  • Based node common service entity 254 is configured using various resources. 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 250.
  • 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 various resources. 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 various resources. 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.
  • the application service node 220 may perform the object communication function with the base node 250 through the relay node 200. The difference between 210 and 220 is that the communication interfaces constituting the node are different.
  • the 220 communicates with 200 through 200 using an interface capable of a near-field communication such as Bluetooth, ZigBee, Zwave, and WiFi.
  • the 210 communicates with 250 using a communication interface such as 3G, LTE, 5G, Ethernet, Gigabit Ethernet, ADSL and the like.
  • 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 is used to communicate with 250 using a communication interface such as 3G, LTE, Ethernet, Gigabit Ethernet, ADSL and the like
  • 240 is used to communicate with 250 through 200 using an interface capable of Bluetooth communication, ZigBee, Zwave, WiFi, Lt; / RTI >
  • 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 originator 300 transmits a request message to a receiver 310 (S320).
  • the sender 300 and the receiver 310 may each be an M2M device and may be CSE or AE as described above. Also, the sender 300 and the recipient 310 may be nodes or servers or devices, including CSE or AE.
  • the request message may include one or more parameters.
  • the request message may include mandatory and optional parameters.
  • the From side parameter, the To parameter, the Request Identifier parameter and the Operation parameter are included as mandatory parameters.
  • the From parameter includes information about the originating atom that sends the message, and the To parameter contains information about the recipient receiving the message.
  • the Request Identifier parameter contains unique identification information for identifying the request message.
  • the operation parameter includes information for distinguishing the requested operation from the request message.
  • the operation parameter may be set to one of Create, Retrieve, Update, Delete, and Notify.
  • optional parameters may be added to control various operations of the request message.
  • the optional parameters of the response type include a blocking method, a non-blocking blocking scheme, a non-blocking blocking scheme, a non-blocking blocking scheme, a flexBlocking scheme, .
  • the receiver 310 When the request message is received, the receiver 310 performs an operation for processing the request message (S330). For example, the receiver 310 can check whether the sender 300 having transmitted the request message has the right to the request. When it is determined that the sender 300 has the authority for the request, the request message is processed after confirming whether the requested resource exists. Alternatively, the receiver 310 may perform a corresponding operation according to the operation parameter of the request message. For example, when an operation parameter is set to be generated and a subscription function for instructing the sender 300 to inform the sender 300 of a change, addition, deletion, or the like of specific data occurs, the receiver 310 transmits the subscription information And notifies the sender 300 of the occurrence of an event such as change, addition, deletion, etc. in the data corresponding to the subscription information.
  • the receiver 310 generates processing result information according to the request operation and includes it in a response message and transmits it to the sender 300 (S340).
  • the step S340 may be performed before the step S330. That is, when the receiver 310 receives the request message, it generates an ACK response message indicating simple reception of the ACK response message, and transmits the ACK response message to the sender 300, and then performs a step S330 to process the request message.
  • FIG. 4 is a diagram illustrating a common service entity according to an exemplary embodiment of the present invention.
  • Fig. 4 includes a function of processing identification information.
  • the functions provided by the common service object can be summarized as shown in FIG. 4, and can be classified into Addressing & Identification, Application and Service Layer Management, Data Management & Repository, Location, Security, Communication Management / Delivery Handling, Registration, Service Session Management, Device Management, Subscription / Notification, Connection Management Service Charging / Accounting, Network Service Exposure / Service Execution and Triggering, Group Management, and so on.
  • ASM Application and Service Layer Management
  • CMDH Communication Management and Delivery Handling
  • CSE-CSE communication communication connection
  • CMDH is responsible for storing the communication requests at which time to communicate using which communication connection (CSE-CSE communication), when it is needed and when it is allowed, and when the transmission of the communication is postponed.
  • CMDH is performed according to the provisioning policy and delivery handling parameters specific to each request for communication.
  • the underlying network can support the same forwarding handling function.
  • the CMDH can use the underlying network and can act as a front end accessing the same forwarding handling function to the underlying network.
  • DMR Data Management and Repository
  • the DMR CSF provides the ability to provide and coordinate data storage. It also includes the ability to collect and combine large amounts of data, convert data to a specific format, or store data for analysis and semantic processing.
  • &Quot; Data means raw data that is extracted transparently from an M2M device, or may refer to data processed or combined and processed by an M2M entity. Collecting large amounts of data constitutes what is known as Big Data Storage.
  • the CSF is responsible for managing device functions of devices in MNs, device nodes, and M2M area networks. It enables device management to provide one or more of the following functions: Application software installation and settings, configuration settings and provisioning, firmware updates, logging and monitoring and analysis, topology management of area networks, and area network management.
  • the DIS (Discovery) CSF is responsible for retrieving the information and resources granted in the given scope and subject (including those allowed in the M2M service subscription) and the request from the Originator within a given scope Loses.
  • the originator can be an application or another CSE.
  • the scope of the search may be one CSE or multiple CSEs.
  • the discovery result is returned to the originator.
  • Group Management handles the group associated with the request. Requests are sent for the management of group and group membership, and are also responsible for the bulk operations supported by the group. When adding or deleting members to a group, you need to make sure that the members conform to the purpose of the group. Bulk operations include read, write, subscribe, notify, and device management. The request or subscription is made through the group, and the group is responsible for combining these requests and notifications. Members of a group have the same role in access rights to resources. In this case, access control is done by the group. If the underlying network provides broadcasting and multicasting capabilities, the GMG CSF should use these functions.
  • the CSF enables the M2M AE to acquire the geographical location information of M2M nodes (eg ASN, MN) for location based services. This location information may be requested from an M2M AE that is in the same or a different M2M node.
  • M2M nodes eg ASN, MN
  • the CSF manages the communication with the underlying network to access the network service functions via the Mcn reference point on behalf of the M2M application, the available or supportable way for the service request from the M2M system.
  • the NSE CSF conceals other CSFs and AFs from specific technologies and mechanisms supported in the underlying network.
  • the network service functions provided from the underlying network include, but are not limited to, device triggering, small data transfer, location notification, policy rule setting, location query, IMS service, device management and the like. These functions do not include general transmission services.
  • REG Registration
  • the REG CSF handles not only device registration for the CSE, but also device property / attribute registration.
  • SEC Secure Electronic Data handling
  • the SEC CSF provides sensitive data handling capabilities to protect local credentials that require security during storage and manipulation. Sensitive data handling also uses security algorithms. This feature supports separate security environments with different cryptographic techniques.
  • the security operations function provides the following functions, first providing the creation and operation of a secure environment dedicated to being supported by the sensitive data handling function. It supports post provisioning of root credentials protected in a secure environment and supports the provisioning and operation of subscriptions related to M2M services and M2M application services.
  • the security association setting function establishes a security association between M2M nodes to enable confidentiality, integrity, authentication, and authorization.
  • Authorization and access control functions control the access of services and data to authorized entities according to the provisioned security policies and assigned roles.
  • the unique identifier of the entity is used for authorization, and the identity protection function can provide anonymity that serves as a temporary identifier so that it is not linked to the actual identity information associated with the entity or user.
  • SCA Service Charging and Accounting
  • the SCA CSF acquires billable events, stores information, and generates billing records and billing information.
  • the SCA CSF can interact with the billing system of the underlying network. However, the SCA CSF is responsible for generating and recording billing information at the final service level.
  • the SCA CSF of the base node or service layer charging server is responsible for handling billing information for billing.
  • the CSF manages M2M service sessions that are end-to-end service layer connections.
  • the SSM CSF manages M2M service sessions between M2M applications, or between M2M applications and CSEs, or between CSEs.
  • Management of the M2M service session includes management of the session state, establishment and authentication of the session, management of the underlying network connection and service related to the session, coordination of the session expansion of the CSE multi-hop cse, exchange of information between sessions, .
  • the SSM CSF uses the CMDH CSF in the local CSE to send / receive messages to / from the next hop CSE or application.
  • the SSM CSF uses the SEC CSF for session credentials for session participants and for session management related to authentication.
  • the SSM CSF generates session-specific billing events and also communicates with the SCA CSF in the local CSE.
  • Subscription and Notification provides notification to maintain subscriptions and tracks changes in resources (for example, deletion of resources).
  • the subscription of the resource is initiated by the M2M AE or CSE and the access rights are granted by the hosting CSE.
  • the hosting CSE sends a notification to the address that the resource subscriber wants to receive in the event of a change in the subscribed resource.
  • the M2M identifier includes an M2M Service Provider Identifier (M2M-SP-ID), an App-Inst-ID (Application Instance Identifier), an App-ID (Application Identifier), a CSE- A Node Identifier / Device Identifier, an M2M Service Subscription Identifier (M2M-Sub-ID), and an M2M-Request-ID (Request Identifier).
  • M2M-SP-ID M2M Service Provider Identifier
  • App-Inst-ID Application Instance Identifier
  • an App-ID Application Identifier
  • CSE- A Node Identifier / Device Identifier an M2M Service Subscription Identifier
  • M2M-Sub-ID M2M-Request-ID
  • oneM2M is a requirement that must be fulfilled to implement the system. It includes overall system requirements, management requirements, data model & semantics requirements, security requirements Requirements, Charging Requirements, and Operational Requirements.
  • M2M system technology especially oneM2M service platform technology.
  • this description is not limited to the M2M service platform technology, but is applicable to all systems and structures that provide inter-device communication, i.e., object communication, and communication operations occurring in these systems.
  • a sender, a sender, an originator, or the like means an M2M device that transmits a message
  • a recipient, a receiver, a hosting CSE, or the like may refer to an M2M device that receives a message.
  • the recipient can also send a reply message, and the sender can also receive the reply message. Therefore, the M2M device that initially transmits the request message in a specific procedure is described as the originator or Originator or the originator, and the M2M device receiving the transmitted request message is described as the receiver or Receiver or Hosting CSE.
  • both the sender and receiver can send and receive messages, as described above.
  • the M2M device in this specification describes the various nodes including the above-mentioned AE, CSE, NSE and the like, and for the sake of understanding, the description will be made with the host CSE as a center.
  • the M2M device refers to a constituent device that constitutes the M2M system, and refers to various nodes, devices, and entities that receive a request message, perform processing thereon, and transmit a response message.
  • the M2M system exchanges necessary information with each of the M2M devices constituting the M2M system and the application providing the application program to the user by using the information of the corresponding M2M device.
  • the M2M device may perform operations of creating, inquiring, deleting, updating, and notifying the necessary information, and other M2M devices and applications may request the corresponding operation.
  • the M2M system may be constituted by a plurality of M2M devices, and the individual M2M devices may be produced and operated by different manufacturers or operators.
  • an application using M2M information can be configured based on various platforms.
  • different data management policies data types, encoding schemes, etc. may be applied between M2M devices or between M2M devices and applications.
  • time series resource in this specification is an example of data managed by the M2M device, and the present disclosure can be equally applied to various resources. That is, a time series resource refers to a resource for data collected and stored in a time-series manner, such as a water usage amount and an electricity usage amount.
  • the present disclosure can be equally applied to all resources stored and managed by M2M devices as well as time series resources.
  • time-series resources as ⁇ timeSeries> resources as needed, and an example of ⁇ timeSeriesInstance> resources as subordinate resources of time-series resources.
  • the M2M device can include the attached resource and the attribute information for each resource, and the attached resource and the attribute information can be separately stored and managed according to the purpose.
  • FIG. 5 is a diagram for explaining a procedure for processing a request message for ⁇ timeSeriesInstance> resource creation according to an embodiment.
  • the sender 300 may send a request message to the receiver 310 requesting generation of a time series instant resource (S310).
  • the request message may include mandatory and optional parameters in the request message.
  • the request message essentially includes a sender parameter and a receiver parameter, an operation parameter and a request identification parameter.
  • the request message may optionally include a response type parameter.
  • the operation parameter is set to a value indicating generation
  • the resource type is set to a value indicating a time series instantaneous resource because it is a request message for requesting generation of a time series instant resource.
  • the content parameter includes content information to be generated.
  • the receiver 310 processes the request message by receiving the request message, confirming each parameter of the request message, and performing the indicated operation (S520). For example, the receiver 310 generates a time series instantaneous resource as an accessory resource of the time series resource, and stores the contents information included in the request message in the time series instantaneous resource.
  • the receiver 310 transmits a response message to the sender 300 according to the processing result of step S520 (S530).
  • the response message may include response status code information and request identification parameter information.
  • the request identification parameter information is set to the same value as the request identification parameter information in step S510, indicating which response message corresponds to which request message.
  • the response status code may be set to a value indicating success, failure, or other type, indicating whether the processing of the request message was successful, failed, or other predetermined type of operation.
  • the sender 300 can request the receiver 310 to generate a specific resource, and can request update, inquiry, and deletion of a specific resource through the same or similar operation. Or the recipient 310 may notify the specific resource as needed.
  • FIG. 6 is an exemplary diagram illustrating a message code and a response message code according to an operation parameter of a request message according to an exemplary embodiment of the present invention.
  • the generation request message of FIG. 5 may be transmitted in various ways.
  • the request message of FIG. 5 may be sent with a value for each parameter, such as 600.
  • " to " indicates the target recipient of the corresponding request message in the receiving-side parameter.
  • " from " indicates the caller sending the request message to the sender parameter.
  • " op " is set to indicate any of generation, inquiry, update, deletion, and notification as operation parameters. In this example, the case where the generation is instructed to be set to 1 is described.
  • the " rqi " can be set to a specific value as a request identification parameter.
  • the " pc " indicates content, which in this example includes information about the car, speed, date, status, and the like.
  • the request message can be sent in JSON (JavaScript Object Notation) format, and 600 is JSON format data format.
  • 600 implicitly indicates that the encoding type and the data to be transmitted are not encrypted, that is, there is no content security.
  • the receiver performs the corresponding request message processing operation and transmits a response message of the 605 format.
  • " rsc” can be set to a value indicating the success (2001) in the response status code parameter, and the request identification parameter is set to the same value as " rqi "
  • the sender receives the 605 response message and recognizes that the resource has been successfully created according to the 600 request message.
  • Reference numerals 650 and 655 illustrate a JSON format data configuration method of a request message and a response message when the operation parameter is set to be inquired.
  • the operation parameter may be set to 2, which may be set to a value for instructing inquiry, and may not include content such as 600 by requesting a inquiry operation for a specific resource.
  • the receiver Upon receipt of the 650 request message, the receiver constructs a response message including the content of the requested resource in the content as shown in 655 and transmits the response message.
  • each message can be transmitted in JavaScript Object Notation (JSON) format and the data structure of JSON format is shown.
  • JSON JavaScript Object Notation
  • 650 and 655 implicitly indicate that the encoding type and the data to be transmitted are not encrypted, that is, there is no content security.
  • the method of representing contents according to the media type, encoding type, and content security type for data may vary widely.
  • FIG. 7 is a diagram for explaining a content processing method expressed in various ways according to a data processing method. Referring to FIG. 7, the same contents as the request message and the response message of FIG. 6 can be expressed in various cases as shown in the table of FIG.
  • Encoding types can also exist in various ways, such as Plan and Base64.
  • various types of content security can be set.
  • media type information As such, media type information, encoding type information, and content security type information may be defined for a particular resource.
  • the media type information is defined in RFC 6838 and can be managed by a particular management entity (e.g., https://www.iana.org/assignments/media-types/media-types.xhtml).
  • the encoding type information can be classified as a type not encoding, a Base64 encoding type for string data such as a string, and a Base64 encoding type for binary data, as shown in Table 1 below.
  • Encoding type indication value Encoding type 0 Plain - no transfer encoding is applied One base64 encoding is applied on string data 2 base64 encoding is applied on binary data
  • content security type information can be classified as shown in Table 2 below.
  • Content security type indication value Content security type 0 ESData has not been applied to the content data.
  • One ESData using JWE and / or JWS with Compact Serialization has been applied to the content data with no subsequent transfer encoding.
  • 2 ESData using JWE and / or JWS with JSON Serialization has been applied to the content data with no subsequent transfer encoding.
  • 3 ESData using JWE and / or JWS with JSON Serialization has been applied to the content data and subsequent base64 encoding (see [9]) has been applied.
  • 4 ESData using XML encryption and / or XML-Signature has been applied to the content data has been applied with no subsequent transfer encoding.
  • 5 ESData using XML encryption and / or XML-Signature has been applied to the content data and subsequent base64 encoding (see [9]) has been applied.
  • Each type described above is shown as an example, and various types can be applied depending on the setting. Since various media types, encoding types, and content security types can be applied as described above, there is a problem that the M2M device or the application can not recognize the type of the specific content when accessing the specific content, Lt; / RTI >
  • the M2M device receiving the request message or the response message can not confirm which media type, encoding type, or content security type is applied to the received content information, and the number of cases for each type defined in the protocol specification ( Up to 63 times) are all combined to perform decoding.
  • FIG. 8 is a view for explaining an operation of processing a target resource according to a conventional request message.
  • the M2M device receiving the request message can generate and process a target resource by applying a preset media type, an encoding type, and a content security type to the corresponding device. That is, it handles the target resource irrespective of the sender who sent the request message or the application that may use the target resource.
  • the M2M device when the M2M device receives a request message for requesting generation of a time series instant resource ( ⁇ timeSeriesInstance> resource), the M2M device checks a request parameter of the request message (S800). If the request parameter verification fails, it is not confirmed which request message is received, so that the M2M device performs error processing (S810). In this case, the M2M device generates a response status code mapped in advance to the error status (S880), and transmits a response message including the response status code (S890).
  • the M2M device compares the maximum instantaneous number included in the lower attribute information of the time series resource with the instant stored instant number (S820).
  • maxNrOfInstances is the attribute information indicating the maximum instance number of the time series resource
  • currentNrOfInstances is the attribute information indicating the current instance number.
  • the current instance number may be set or excluded except for the number of instances indicated by the request message.
  • the M2M device compares the maximum byte size included in the lower attribute information of the time series resource with the current byte size (S830).
  • CurrentByteSize is attribute information indicating the byte size of the current time series resource
  • maxByteSize is attribute information indicating the maximum byte size set in the time series resource.
  • a time series instance resource can be created as a subordinate resource of a time series resource.
  • the M2M device can not indicate that the request message can not be processed, (S840). In this case, the M2M device generates a response status code preset in accordance with the failure processing type (S880), and transmits a response message including the response status code (S890).
  • the currentNrOfInstances attribute information and the value of the CurrentByteSize attribute information among the lower attribute information of the time series resource are updated by reflecting the generated instant resource (S860).
  • the M2M device performs a success process for the request message (S870), generates a response status code mapped to the success process (S880), inserts the response status code into the response message, and transmits the response message (S890).
  • the M2M device processes the request message.
  • step S850 the contents of the media type, the encoding type, and the content security type are not checked and applied according to the policy set in the M2M device. That is, conventionally, when a target resource is implicitly generated, any one of the cases shown in Fig. 7 can be applied.
  • the other M2M device when the M2M device applies the format of CASE B in FIG. 7 to generate the target resource, the other M2M device (AE or CSE) needs to search for and use the target resource, Attribute information should be used. Because other M2M devices can not search for cars with Base64 encoded content. If the M2M device that created the target resource generates the label attribute information as " automobile ", another M2M device can find the target resource using the corresponding label attribute information.
  • a new sender requesting a query for a target resource can not understand or interpret the content of the target resource or the content attribute information "ew0KCSJ0aGluZyI6ICJjYXIiLA0KCSJzdGF0dXMiOiAiZHJpdmUiLA0KCSJzcGVlZCI6ICIxMDAiDQp9". This is because it is not possible to know what type of content or attribute information of the target resource is encoded.
  • This problem also occurs when requesting a query for a target resource.
  • FIG. 9 is a diagram for explaining a processing operation for a request message for requesting an inquiry about a target resource according to an embodiment.
  • the sender 300 may transmit a request message requesting a retrieve operation for a specific resource (S910).
  • the request message may essentially include the above-mentioned operational parameters, the receiver parameter, the transmitter parameter and the request identification parameter.
  • the operation parameter is set to a value indicating an inquiry.
  • the receiver 310 Upon receiving the request message, the receiver 310 performs an operation of the requested operation parameter and performs an inquiry operation (S920).
  • the receiver 310 transmits the response message including the content of the inquired target resource to the sender 300 (S1030).
  • the request identification parameter of the response message may be set to the same value as the request identification parameter of the request message.
  • the receiver 310 may set a value (e.g., 2000) of the response status code indicating the successful processing of the inquiry request, and transmit the response status code in a response message.
  • FIG. 9 The code of the request message and the response message in FIG. 9 will be described with reference to FIGS. 10 and 11.
  • FIG. 10 The code of the request message and the response message in FIG. 9 will be described with reference to FIGS. 10 and 11.
  • FIG. 10 is a diagram exemplarily showing a code of a request message for inquiring a ⁇ timeSeriesInstance > resource according to an embodiment.
  • the request message has an operation parameter set to 2 to request an inquiry about a target resource, and includes a sender parameter and a receiver parameter.
  • the request identification parameter is set to a specific value.
  • FIG. 11 is an exemplary diagram illustrating a code of a response message to the request message of FIG. 10 according to an embodiment.
  • the response message indicates that the process of the request message has been successfully performed through the response status code.
  • the request identification parameter is set equal to the value of the request message.
  • the content information includes information about the target resource to be inquired.
  • the " con " of the content information includes the code for the corresponding resource, and may be included in the form of CASE B in Fig. 7 in which the receiver stores the target resource as described above.
  • FIG. 12 is a diagram for explaining an operation of extracting information through the response message of FIG.
  • the request message sender receiving the response message code of FIG. 11 checks the response status code of the received response message (S1200). If the response status code is set to a value indicating successful processing of the request message, the sender checks whether the request identification parameter is the same as the request identification parameter of the request message (S1210). The order of S1200 and S1210 may be changed.
  • step S1210 determines whether the sender is identical. If it is determined that the content exists, the sender extracts the content information from the content parameter (S1230). However, as shown in FIG. 11, the content information is included according to the data management type of the recipient of the response message, so that the sender determines whether the extracted content information matches the format of the sender set in advance (S1240).
  • the caller performs an error processing operation (S1205).
  • the sender performs decoding by applying the data management type of the sender to the content information. If the receiver and the caller use different data management types, decoding will fail. Alternatively, the sender may attempt to decode sequentially for all data management types.
  • the caller fails to decode, or decoding sequentially by applying the number of all cases may be a fatal problem in the information transfer function. That is, there is a problem that the information is not exchanged properly, or a resource unnecessary for acquiring the exchanged information is used.
  • the present disclosure aims to smoothly exchange information by adding information on a data type to the attribute information of a target resource.
  • FIG. 13 is a view for explaining the operation of the M2M device according to an embodiment.
  • a machine-to-machine communication (M2M) device includes a method for processing a message, the method comprising: receiving from the other M2M device a request message including an operation parameter, a receiving parameter, a transmitting parameter, (S1300).
  • the request message includes a sender parameter indicating the sender as a mandatory parameter, a receiver parameter indicating the recipient, an operation parameter indicating the operation type, and a request identification parameter for identifying the request and the response.
  • it may further include content parameters in accordance with each operation parameter.
  • it may include a target resource to be generated in the case of a request message instructing an operation such as creation, update, etc., and a content parameter for content to be updated.
  • the M2M device performs step of processing the target resource according to the operation indicated by the operation parameter including the attribute information indicating the resource information (S1310). For example, upon receiving the request message, the M2M device processes the target resource based on the operating parameters.
  • the attribute information may include at least one of media type information for the target resource, encoding type information, and content security type information. That is, the attribute information may include information on at least one of the media type information, the incode type information, and the content security type information applied to the target resource.
  • the target resource may be a time series resource that is a subordinate resource of a time series resource or a time series resource.
  • the target resource may be a content instance resource. That is, the target resource may be a resource that is stored and managed by the M2M device, or may be a subordinate resource of the resource.
  • the attribute information may be the Contentinfo attribute information as the sub-attribute information of the target resource, and the Contentinfo attribute information essentially includes the media type information and the encoding type information applied to the target resource, and selectively includes the content security type information can do.
  • the M2M device can use the attribute information in processing the target resource according to the operation parameter.
  • the M2M device may include at least one of the media type information, the encoding type information, and the content security type information applied to the target resource in the Contentinfo attribute information, Attribute information of the target resource.
  • the M2M device specifies the inquiry target resource requested by the sender and can specify the contentinfo attribute information, which is the attribute information applied to the target resource, as the information to be included in the response message.
  • the type information for the target resource is clearly .
  • the M2M device performs a step of transmitting a response message including response information to the request message (S1320).
  • the M2M device transmits a response message including the target resource and attribute information when the operation parameter indicates inquiry or notification.
  • the response message may include a response status code, and when the operation parameter indicates generation, deletion, or the like, the response status code may be set to a value indicating the success or failure of the operation.
  • the response message also includes a request identification parameter set to the same value as the value of the request identification parameter included in the request message.
  • the response message may include a response status code that is individually mapped according to the response mode processed by the M2M device when the response mode of the request message is indicated as flex blocking.
  • the response mode is for discriminating the operation of processing the request message, and is divided into blocking, synchronous non-blocking, asynchronous non-blocking and flex blocking.
  • the flexblocking mode determines the response mode of the receiver, and the caller can not know the response mode selected by the receiver. Accordingly, by setting a value indicating the success process of the response status code to a value separated according to each response mode, the caller receives the response message and determines whether the response process operation for the request message should be performed according to which response mode .
  • the following shows an example of the attribute information and the configuration of the auxiliary resource when the target resource is a time series resource and the time series instance resource.
  • FIG. 14 is an exemplary diagram illustrating a structure of a time series resource including a ContentInfo attribute resource according to an embodiment.
  • a time series resource may include contentInfo attribute information, and may include various attribute information and additional resources such as time series instantiation resources.
  • a ⁇ timeSeries> resource containing contentInfo attribute information can be constructed as shown in Table 3.
  • OA announceTo 0. 1 (L) RW See clause 9.6.1.3.
  • NA announcedAttribute 0. 1 (L) RW See clause 9.6.1.3.
  • NA dynamicAuthorizationConsultationIDs 0. 1 (L) RW See clause 9.6.1.3.
  • OA creator One RO See clause 9.6.1.3.
  • NA maxNrOfInstances 0..1 RW Maximum number of direct child ⁇ timeSeriesInstance> resources in the ⁇ timeSeries> resource.
  • OA maxByteSize 0..1 RW The maximum size in bytes of data that is allocated for the ⁇ timeSeriesInstance> resource is for all direct child ⁇ timeSeriesInstance> resources.
  • OA maxInstanceAge 0..1 RW Maximum age of a direct child ⁇ timeSeriesInstance> resource in the ⁇ timeSeries> resource. The value is expressed in seconds.
  • OA currentNrOfnstances One RO Current number of direct child ⁇ timeSeriesInstance> resource in the ⁇ timeSeries> resource. It is limited by the maxNrOfInstances .
  • the currentNrOfInstances attribute of the ⁇ timeSeries> resource shall be updated on successful creation or deletion of the direct child ⁇ timeSeriesInstance> resource of ⁇ timeSeries> resource.
  • OA currentByteSize One RO Current size in bytes of data stored in all direct child ⁇ timeSeriesInstance> resources of a ⁇ timeSeries> resource.
  • the currentByteSize attribute of the ⁇ timeSeries> resource shall be updated on the successful creation or deletion of the direct child ⁇ timeSeriesInstance> resource of ⁇ timeSeries> resource.
  • NA ontologyRef 0..1 RW A reference (URI) of the ontology used to represent the information stored in the child ⁇ timeSeriesInstance> resources of the present ⁇ timeSeriesData> resource (see note).
  • OA missingDataMaxNr 0..1 RW Maximum number of entries in the missingDataList if the periodicInterval is set and the missingDataDetect is TRUE.
  • OA missingDataCurrentNr 0..1 RO Current number of missing time series data in the missingDataList .
  • OA missingDataList 0. 1 (L) RO The list of the dataGenerationTime value representing the missing Time Series data in descending order by time if the periodicInterval is set and the missingDataDetect is TRUE.
  • OA missingDataDetectTimer 0..1 RW The missing DataDetectTimer is a missing Time Series Data. Note that the setting of this value may not apply to certain transports such as TCP, OA contentInfo 0..1 WO This attribute contains information to understand the contents of the content attribute of ⁇ timeSeriesInstance>.
  • URI Internet Media Type
  • IETF RFC 6838 an encoding type
  • an optional content security component may also be included.
  • TS-0004 [3] If not present, the default shall be a media type of XML, an encoding type of plain text and no optional content security.
  • FIG. 15 is a diagram illustrating a structure of a time series instant resource including a ContentInfo attribute resource according to an exemplary embodiment.
  • a time series instant resource may include contentInfo attribute information including information indicating a media type, an encoding type, a content security type, and the like.
  • a ⁇ timeSeriesInstance> resource represents a data object of a ⁇ timeSeries> resource.
  • the ⁇ timeSeriesInstance> resource can not be modified, and the application object (AE) must be able to explicitly delete the ⁇ timeSeriesInstance> resource and can be removed from the platform according to the policy.
  • the platform has a policy for ⁇ timeSeriesInstance> resource retention, the policy is represented by a combination of maxByteSize, maxNrOfInstances, maxInstanceAge, or such attribute information of the ⁇ timeSeries> resource. When multiple policies are enforced, the most stringent policy applies. The difference is that the ⁇ timeSeriesInstance> resource inherits the same access control policy as the parent ⁇ timeSeries> resource and does not have its own accessControlPolicyIDs attribute information.
  • the ⁇ timeSeriesInstance> resource may contain the subordinate subordinate resources specified in Table 4.
  • Child Resources of ⁇ timeSeriesInstance> Child Resource Type Multiplicity Description
  • timeSeriesInstanceAnnc> Child Resource Types [variable] ⁇ semanticDescriptor> 0..n See clause 9.6.30 ⁇ semanticDescriptor>, ⁇ semanticDescriptorAnnc>
  • the description part is described as "See clause 9.6.30.” For convenience of explanation, and the corresponding part can be referred to the corresponding section of the OneM2M TS-0001 document.
  • the ⁇ timeSeriesInstance> resource contains the attribute information specified in Table 5.
  • OA dataGenerationTime One WO This attribute contains the time when the data was generated by the AE / CSE.
  • OA content One WO This attribute contains the data generated by the AE / CSE.
  • OA sequenceNr 0..1 WO This attribute contains the data sequence number generated by the AE / CSE OA
  • the ⁇ timeSeriesInstance> resource may contain contentInfo attribute information.
  • the contentInfo attribute information may include information for understanding the content of the content attribute information.
  • the contentInfo attribute information may be composed of three elements: a media type, an encoding type, and a content security type.
  • the delimiter for distinguishing attribute information uses the ':' character.
  • a ⁇ timeSeries> resource can have a ⁇ timeSeriesInstance> resource as an attached resource.
  • the ⁇ timeSeriesInstance > resource may separately include attribute information indicating a media type or the like, but the value of the content attribute information may be changed according to the generation time of the attribute information generated in the resource ⁇ timeSeriesInstance >.
  • the effect of reducing the amount of communication in delivering the ⁇ timeSeriesInstance> resource is more effective than the case of using the ⁇ timeSeriesInstance> contentInfo attribute when the contentInfo attribute information is included in the ⁇ timeSeries> resource.
  • the amount of data can be reduced in terms of storage and management, and the processing method can be simplified in the case of retrieving and extracting ⁇ timeSeriesInstance> resource information on a large scale.
  • attribute information including the type information described above may be configured in the ⁇ timeSeriesInstance> resource, and attribute information including the type information described above in the ⁇ timeSeries> resource, which is an upper resource, may be configured as needed.
  • the attribute information indicating the media type, the encoding type, and the content security type may be configured as attribute information of the content instance resource.
  • the above-described present disclosure is also applied to a general data ⁇ contentInstance > resource so that contentInfo attribute information including information on the media type, the encoding type, and the content security type can be configured also in a general data ⁇ contentInstance> resource. That is, the contentInfo attribute information constituting the ⁇ contentInstance> resource may be composed of three elements of media type, encoding type, and content security.
  • a delimeter for distinguishing attribute information can use a ':' character.
  • the ⁇ contentInstance> resource including the contentInfo attribute information as shown in Table 6 may include various attribute information.
  • OA contentRef 0..1 RW This attribute contains a list of name-value pairs. Each entry expresses and associative reference to a ⁇ contentInstance> resource. The name of the entry indicates the relationship and the value of the entry indicates the URI to the resource.
  • OA content One WO Actual content of a contentInstance This content may be opaque data for understandable with the help of the contentInfo . This may, for example, be an image taken by a security camera, or a temperature measurement taken by a temperature sensor.
  • the M2M device when the M2M device includes the response message and transmits the content, at least one of the media type, the encoding type, and the content security type of the target resource content, And transmits the attribute information together.
  • the sender who transmits the request message does not have a problem of consuming a large amount of resources for decoding failure or decoding by using the response message.
  • 16 is a view for explaining an operation of extracting information in a response message according to an inquiry request message for time series instantaneous resources according to an embodiment.
  • the sender of the request message receiving the response message checks the response status code of the received response message (S1600). If the response status code is set to a value indicating successful processing of the request message, the sender checks whether the request identification parameter is the same as the request identification parameter of the request message (S1610). The order of S1600 and S1610 may be changed.
  • step S1610 determines whether the sender exists (S1620). If it is determined that the content exists, the sender checks the attribute information of the target resource of the content (S1630).
  • the content type information of the time-series resource is checked to check at least one of the media type, the encoding type, and the content security type for the time series resource.
  • the content type attribute information of a time-series instance resource or the content information property information of a time-series resource, which is a parent resource is checked to determine a media type, an encoding type, Check at least one piece of information.
  • the content instance attribute information of the content instance resource or the content resource attribute information of the content resource that is the upper resource is the content resource type of the content instance resource, Or the like.
  • the sender extracts the content information according to the type information of the confirmed attribution information (S1640). That is, by decoding the content information using the media type, the encoding type, or the content security type specified by the above-described attribute information, it is possible to prevent the resource from being wasted in decoding failure or decoding.
  • the caller performs an error handling operation (S1605).
  • the target resource includes at least one of the media type, the encoding type, and the content security type information as attribute information, and the M2M device decodes the target resource using the corresponding attribute information, Waste of resources can be prevented.
  • 17 is a diagram illustrating a structure of an M2M device according to an embodiment.
  • a machine to machine communication (M2M) device 1700 includes a receiving unit 1730 for receiving a request message including an operation parameter, a receiving side parameter, a transmitting side parameter and a request identifying parameter from another M2M device, A control unit 1710 for processing the target resource according to an operation indicated by the operation parameter including attribute information indicating information and a transmission unit 1720 for transmitting a response message including response information for the request message have.
  • M2M machine to machine communication
  • the request message includes a sender parameter indicating the sender as a mandatory parameter, a receiver parameter indicating the recipient, an operation parameter indicating the operation type, and a request identification parameter for identifying the request and the response.
  • the request message may further include content parameters in accordance with each operation parameter. For example, it may include a target resource to be generated in the case of a request message instructing an operation such as creation, update, etc., and a content parameter for content to be updated.
  • control unit 1710 processes the target resource based on the operation parameter.
  • the attribute information may include at least one of media type information for the target resource, encoding type information, and content security type information. That is, the attribute information may include information on at least one of the media type information, the incode type information, and the content security type information applied to the target resource.
  • the target resource may be a time series resource that is a subordinate resource of a time series resource or a time series resource.
  • the target resource may be a content instance resource. That is, the target resource may be a resource that is stored and managed by the M2M device, or may be a subordinate resource of the resource.
  • the attribute information may be the Contentinfo attribute information as the sub-attribute information of the target resource, and the Contentinfo attribute information essentially includes the media type information and the encoding type information applied to the target resource, and selectively includes the content security type information can do.
  • control unit 1710 can use the attribute information in processing the target resource according to the operation parameter.
  • control unit 1710 may include at least one of the media type information, the encoding type information, and the content security type information applied to the target resource in the Contentinfo attribute information, It is possible to construct a target resource by configuring it as sub-attribute information of the target resource.
  • control unit 1710 specifies the inquiry target resource requested by the sender, and specifies the contentinfo attribute information, which is the attribute information applied to the target resource, as the information to be included in the response message have.
  • the transmitter 1720 transmits a response message including the target resource and attribute information when the operation parameter indicates inquiry or notification.
  • the response message may include a response status code, and when the operation parameter indicates generation, deletion, or the like, the response status code may be set to a value indicating the success or failure of the operation.
  • controller 1710 controls the overall operation of the M2M device 1700 in accordance with the management of the information on the media type, the encoding type, and the content security type as attribute information in association with the target resource according to the present embodiment .
  • the transmitting unit 1720 and the receiving unit 1730 transmit and receive messages, signals, and data necessary for performing the present embodiment with at least one of the sender, the other M2M device, the other node constituting the M2M system, and the application user terminal Is used.
  • system generally used to refer to computer-related entity hardware, Combination, software, or software in execution.
  • the above-described components may be, but are not limited to, a process driven by a processor, a processor, a controller, a control processor, an entity, an execution thread, a program and / or a computer.
  • a component can be a controller or an application running on a processor and a controller or processor.
  • One or more components may reside within a process and / or thread of execution and the components may reside in one system or be distributed to more than one system.

Landscapes

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

Abstract

본 실시예는 M2M(Machine to Machine Communication) 기술에 관한 것으로, 발신자가 보낸 요청 메시지를 수신자가 처리하기 위한 방법 및 그 장치에 관한 것이다. 일 실시예는 M2M(Machine to Machine communication) 장치가 메시지를 처리하는 방법에 있어서, 동작 파라미터, 수신측 파라미터, 송신측 파라미터 및 요청 식별 파라미터를 포함하는 요청 메시지를 타 M2M 장치로부터 수신하는 단계와 자원 정보를 지시하는 속성정보를 포함하여 대상 자원을 동작 파리미터에 의해서 지시된 동작에 따라 처리하는 단계 및 요청 메시지에 대한 응답 정보를 포함하는 응답 메시지를 전송하는 단계를 포함하는 방법 및 장치를 제공한다.

Description

M2M 시스템에서 메시지를 처리하는 방법 및 그 장치
본 실시예는 M2M(Machine to Machine Communication) 기술에 관한 것으로, 발신자가 보낸 요청 메시지를 수신자가 처리하기 위한 방법 및 그 장치에 관한 것이다.
사물 통신(M2M, "Machine to machine communication" 또는 MTC, "Machine type communication" 또는 스마트 디바이스 통신, "Smart Device communication" 또는 "Machine oriented communication" 또는 사물 인터넷, "Internet of Things")은 사람이 통신 과정에 개입하지 않고 통신이 이루어지는 방식의 모든 통신 방식을 지칭한다.
사물통신은 통상적으로 사람이 직접적으로 통신과 응용 제어를 수행하지 않기 때문에, 사물 간에 메시지를 교환하기 위해서 송수신 방법과 절차와 필요하다. 또한, M2M 장치 간의 원활한 메시지 교환을 위한 프로토콜이 필요하다.
특히, IoT 기기의 대중화에 따라서 다수의 사물 통신 장치가 가정 및 직장 내에서 사용되고 있으며, 동일 또는 유사한 기능을 수행하는 사물 통신 장치가 일정 목적을 위해서 다수 전개되는 상황이 존재한다.
이러한 상황에서 다수의 사물 통신 장치는 서로 다른 프로토콜을 사용하여 데이터를 저장, 관리 및 처리할 수 있다. 예를 들어, 각 사물통신 장치는 서로 다른 미디어 유형 또는 인코딩 유형 등을 사용하여 데이터를 관리하고 송수신할 수 있다. 따라서, 서로 다른 인코딩 유형 등을 사용하는 사물통신 장치 간에는 원활한 정보 교환이 어려울 수 있다.
즉, 서로 다른 데이터 처리 유형을 가지는 M2M 장치 간에 원활한 정보 교환을 위해서 데이터 처리 유형에 대한 정보 처리가 요구된다. 또한, 보다 빠르게 메시지에서 정보를 추출하기 위한 구체적인 기술이 요구되고 있는 실정이다.
전술한 배경에서 안출된 일 실시예는 M2M 장치가 다른 M2M 장치로부터 요청 메시지를 수신한 경우, 해당 요청 메시지에 따라 처리된 자원에 대한 데이터 유형 정보를 별도로 관리하여 정보 교환의 효율성을 높이기 위한 구체적인 방법 및 장치를 제안하고자 한다.
전술한 과제를 해결하기 위한 일 실시예는 M2M(Machine to Machine communication) 장치가 메시지를 처리하는 방법에 있어서, 동작 파라미터, 수신측 파라미터, 송신측 파라미터 및 요청 식별 파라미터를 포함하는 요청 메시지를 타 M2M 장치로부터 수신하는 단계와 자원 정보를 지시하는 속성정보를 포함하여 대상 자원을 동작 파리미터에 의해서 지시된 동작에 따라 처리하는 단계 및 요청 메시지에 대한 응답 정보를 포함하는 응답 메시지를 전송하는 단계를 포함하는 방법을 제공한다.
또한, 일 실시예는 메시지를 처리하는 M2M(Machine to Machine communication) 장치에 있어서, 동작 파라미터, 수신측 파라미터, 송신측 파라미터 및 요청 식별 파라미터를 포함하는 요청 메시지를 타 M2M 장치로부터 수신하는 수신부와 자원 정보를 지시하는 속성정보를 포함하여 대상 자원을 동작 파리미터에 의해서 지시된 동작에 따라 처리하는 제어부 및 요청 메시지에 대한 응답 정보를 포함하는 응답 메시지를 전송하는 송신부를 포함하는 M2M 장치를 제공한다.
본 개시는 서로 다른 M2M 장치 간에 송수신 되는 메시지를 통해서 보다 빠르고 효율적으로 데이터를 추출할 수 있는 효과를 제공한다.
또한, 본 개시는 데이터 처리 유형의 모호성에서 발생하는 M2M 시스템 전체의 오류 발생을 방지하는 효과를 제공한다.
도 1은 M2M 시스템을 상위 레벨의 기능적 관점에서 도시한 도면이다.
도 2는 일 실시예에 따른 M2M 시스템 구성도를 보다 구체적으로 도시한 도면이다.
도 3은 M2M 시스템에서 요청 메시지 전송과 이에 따른 응답 정보를 수신하는 절차를 예시적으로 도시한 도면이다.
도 4는 일 실시예에 따른 공통 서비스 개체의 기능적 구조를 도시한 도면이다.
도 5는 일 실시예에 따른 <timeSeriesInstance> 자원 생성을 위한 요청 메시지를 처리하는 절차를 설명하기 위한 도면이다.
도 6은 일 실시예에 따른 요청 메시지의 동작 파라미터에 따른 메시지 코드와 응답 메시지 코드를 예시적으로 도시한 도면이다.
도 7은 데이터 처리 방식에 따라서 다양하게 표현되는 컨텐츠 처리 방법을 설명하기 위한 도면이다.
도 8은 종래 요청 메시지에 따라 대상 자원을 처리하는 동작을 설명하기 위한 도면이다.
도 9는 일 실시예에 따른 대상 자원에 대한 조회를 요청하는 요청 메시지에 대한 처리 동작을 설명하기 위한 도면이다.
도 10은 일 실시예에 따른 <timeSeriesInstance> 자원 조회를 위한 요청 메시지의 코드를 예시적으로 도시한 도면이다.
도 11은 일 실시예에 따른 도 10의 요청 메시지에 대한 응답 메시지의 코드를 예시적으로 도시한 도면이다.
도 12는 종래 도 11의 응답 메시지를 통해서 정보를 추출하는 동작을 설명하기 위한 도면이다.
도 13은 일 실시예에 따른 M2M 장치의 동작을 설명하기 위한 도면이다.
도 14는 일 실시예에 따른 ContentInfo 속성자원을 포함하는 시계열 자원의 구조를 예시적으로 도시한 도면이다.
도 15는 일 실시예에 따른 ContentInfo 속성자원을 포함하는 시계열 인스탄스 자원의 구조를 예시적으로 도시한 도면이다.
도 16은 일 실시예에 따른 시계열 인스탄스 자원에 대한 조회 요청 메시지에 따른 응답 메시지에서 정보를 추출하는 동작을 설명하기 위한 도면이다.
도 17은 일 실시예에 따른 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) 등이 될 수 있다.
공통 서비스 개체(Common Services Entity, CSE)(120)는 에너지(energy) 분야, 엔터프라이즈(enterprise) 분야, 헬스케어(Healthcare) 분야, 공공 서비스(Public Services) 분야, 주거(Residential) 분야, 소매(Retail) 분야, 운송(Transportation)분야, 그리고 기타 분야 등에서 공통적으로 필요한 집합적인 서비스 기능이다.
이러한 서비스 기능은 참조점(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 (Network Service Entity)로 기재할 수 있다. 또한, 본 명세서에서의 M2M 장치는 CSE 또는 AE를 의미하거나, CSE 또는 AE를 포함하는 장치를 의미하며, M2M 시스템을 구성하는 디바이스 또는 단말을 의미한다.
도 2는 일 실시예에 따른 M2M 시스템 구성도를 보다 구체적으로 도시한 도면이다.
도 2를 참조하면, 기반노드(Infrastructure Node, 250)는 M2M 통신을 제공하는데 필수적인 서버 기능을 수행한다. 기반노드(250)는 기반노드 응용개체(AE, 252)와 기반노드 공통서비스개체(CSE, 254)로 구성된다. 기반노드 공통서비스 개체(254)는 다양한 자원을 이용하여 구성된다. 252와 254는 Mca 참조점을 통하여 구분하고, 사물통신에 필요한 메시지, 특히 스케줄러 자원의 생성 (create), 삭제 (delete), 갱신 (update), 조회 (retrieve), 통지 (notify)하기 위한 요청메시지와 응답메시지의 구성과 처리에 사용한다.
중계노드(200)는 응용서비스노드(220)와 기반노드(250)의 M2M 통신 또는 Internet of Things, 사물통신 기능을 중계한다. 중계노드(200)는 중계노드 응용개체(202)와 중계노드 공통서비스개체(204)로 구성된다. 중계노드 공통서비스개체 (204)는 다양한 자원을 이용하여 구성된다. 202와 204는 Mca 참조점을 통하여 구분하며, 254와 204는 Mcc참조점을 이용하여 구분하고, 사물통신에 필요한 메시지, 특히 스케줄러 자원의 생성 (create), 삭제 (delete), 갱신 (update), 조회(retrieve), 통지 (notify)하기 위한 요청메시지와 응답메시지의 구성과 처리에 사용한다.
응용서비스노드(210)는 응용개체(212)와 중계노드 공통서비스개체(214)로 구성할 수 있다. 응용개체(212)는 기기의 목적상 요구되는 응용 기능을 처리한다. 응용서비스노드(210)의 공통서비스개체(214)는 다양한 자원을 이용하여 구성한다. 212와 214는 Mca 참조점을 통하여 구분하며, 214와 254는 Mcc참조점을 이용하여 구분하고, 사물통신에 필요한 메시지, 특히 스케줄러 자원의 생성(create), 삭제 (delete), 갱신 (update), 조회 (retrieve), 통지 (notify)하기 위한 요청메시지와 응답 메시지의 구성과 처리에 사용한다. 한편, 응용서비스노드(220)는 중계노드(200)를 통하여 기반노드(250)와 사물통신 기능을 수행할 수도 있다. 210과 220의 차이점은 노드를 구성하는 통신 인터페이스가 다른 것이 특징이다. 예를 들어, 220은 블루투스, ZigBee, Zwave, WiFi등의 초근거리 통신이 가능한 인터페이스를 이용하여 200을 통하여 100과 통신한다. 이에 반해, 210은 3G, LTE, 5G, Ethernet, Gigabit Ethernet, ADSL등의 통신 인터페이스를 이용하여 250과 통신한다.
응용전용노드(230, 240)는 공통서비스개체를 가지지 않고, 응용개체(242)만을 가지고 사물통신을 하는 경우를 대상으로 한다. 230은 3G, LTE, Ethernet, Gigabit Ethernet, ADSL등의 통신 인터페이스를 이용하여 250과 통신하는 경우이고, 240은 블루투스, ZigBee, Zwave, WiFi등의 초근거리 통신이 가능한 인터페이스를 이용하여 200을 통하여 250과 통신한다.
도 2에서 설명한 바와 같이, M2M 시스템은 기반노드, 중계노드, 응용 서비스 노드 및 응용전용 노드 중 적어도 하나 이상의 노드로 구성될 수 있으며, 각 노드는 CSE 또는 AE를 포함하여 구성될 수 있다. CSE와 AE는 각각의 참조점을 통해서 타 CSE 또는 AE와 통신을 수행할 수 있다.
도 3을 참조하면, 발신자(Originator, 300)는 요청 메시지를 수신자(Receiver, 310)로 전송한다(S320). 발신자(300)와 수신자(310)는 각각 M2M 장치일 수 있으며, 전술한 바와 같이 CSE 또는 AE일 수 있다. 또한, 발신자(300)와 수신자(310)는 CSE 또는 AE를 포함하는 노드 또는 서버 또는 장치일 수 있다.
요청 메시지는 하나 이상의 파라미터를 포함할 수 있다. 예를 들어, 요청 메시지에는 필수적인 파라미터와 선택적인 파라미터가 포함될 수 있다. 예를 들어, 송신 (From) 측 파라미터, 수신측 (To) 파라미터, 요청 식별 정보 (Request Identifier) 파라미터 및 동작 (Operation) 파라미터는 필수적인 파라미터로 포함된다. From 파라미터는 메시지를 전송하는 발원자에 대한 정보를 포함하고, To 파라미터는 메시지를 수신하는 수신자에 대한 정보를 포함한다. Request Identifier 파라미터는 해당 요청 메시지를 식별하기 위한 유일한 식별 정보를 포함한다. 또한, Operation 파라미터는 요청 메시지에서 요청하는 동작을 구분하기 위한 정보를 포함한다. 동작 파라미터는 생성(Create), 조회(Retrieve), 갱신(Update), 삭제(Delete), 통지(Notify) 중 어느 하나로 설정될 수 있다. 또한, 요청 메시지의 다양한 동작을 제어하기 위하여 선택적인 파라미터를 부가할 수 있다. 예를 들어 응답 유형 (Response Type)의 선택적인 파라미터는 수신자의 처리 방식을 블록킹 (blockingRequest) 방식, 동기화된 넌블록킹 (nonBlockingRequestSynch) 방식, 비동기화된 넌블록킹 (nonBlockingRequestAsynch) 방식, 수신자 맞춤형 (flexBlocking) 방식으로 지정할 수 있다.
수신자(310)는 요청 메시지가 수신되면, 해당 요청 메시지를 처리하기 위한 동작을 수행한다(S330). 예를 들어, 수신자(310)는 요청메시지(Request Message)를 송신한 발신자(300)가 해당 요청에 대한 권한을 가지고 있는지를 확인할 수 있다. 발신자(300)가 요청에 대한 권한을 가지고 있다고 판단되는 경우, 요청의 대상이 되는 리소스(requested resource)의 존재 여부를 확인한 후 요청 메시지를 처리한다. 또는, 수신자(310)는 요청 메시지의 동작 파라미터에 따라 해당하는 동작을 수행할 수 있다. 예를 들어, 동작 파라미터가 생성으로 설정되고, 특정 데이터의 변경, 추가, 삭제 등이 발생할 경우에 이를 발신자(300)측으로 알려주도록 지시하는 구독 기능이 설정되는 경우에 수신자(310)는 구독 정보를 생성하고, 해당 구독 정보에 해당하는 데이터에 변경, 추가, 삭제 등의 이벤트가 발생하는 경우에 이를 발신자(300) 측으로 통지할 수 있다.
수신자(310)는 요청 동작에 따른 처리 결과 정보를 생성하여 이를 응답메시지에 포함하여 발신자(300)로 전송한다(S340). S340 단계는 S330 단계 이전에 수행될 수도 있다. 즉, 수신자(310)는 요청 메시지를 수신하면, 이에 대한 단순 수신을 나타내는 ACK 응답 메시지를 생성하여 발신자(300)측으로 전송하고, 이후 S330 단계를 수행하여 요청 메시지를 처리할 수도 있다.
도 4는 본 발명의 일 실시예에 의한 공통 서비스 개체를 구성하는 도면이다. 도 4에서는 식별 정보의 처리 기능을 포함한다.
공통 서비스 개체가 제공하는 기능을 도 4와 같이 정리하면 식별(Addressing & Identification), 어플리케이션/서비스 계층 관리(Application and Service Layer Management), 데이터 관리 및 저장(Data Management & Repository), 위치(Location), 보안(Security), 통신 관리/전달 핸들링(Communication Management / Delivery Handling), 등록(Registration), 서비스 세션 관리(Service Session Management), 디바이스 관리(Device Management), 구독/알림(Subscription/Notification), 연결 관리(Connectivity Management), 디스커버리(Discovery), 서비스 과금/정산(Service Charging/Accounting), 네트워크 서비스 표출/서비스 실행 및 트리거링(Network Service Exposure / Service execution and triggering ), 그룹 관리(Group Management) 등이 있다.
물론, 상기 기능 이외에도 시맨틱스(Semantics), 데이터 분석(Data Analytics), 어플리케이션 인에이블먼트(Application Enablement), 네트워크 서비스 기능 관리(Network Service Function Management)등도 포함할 수 있다.
각각의 기능에 대해 살펴보면 다음과 같다.
ASM(Application and Service Layer Management)는 ADN, ASN, MN, IN의 AE와 CSE를 관리하는 것을 담당하며, 이는 CSE의 설정(configure), 트러블슈팅(troubleshoot), 업그레이드 기능과 AE의 업그레이드를 포함한다.
CMDH(Communication Management and Delivery Handling)는 다른 CSE, AE, NSE간의 통신을 책임진다. CMDH는 어느 시각에 어떤 통신 연결을 이용하여 통신을 전달할 것인지(CSE-CSE간 통신), 언제 필요하고 언제 허가되는지, 그리고 통신의 전달이 이후로 미루어질 때 통신 요청을 저장하는 것을 책임진다. CMDH는 통신에 대한 각 요청에 특화된 프로비전된 정책과 전달 핸들링 파라미터에 따라 수행된다. 기반 네트워크 데이터 전송 서비스를 이용한 통신에서 기반 네트워크는 동일한 전달 핸들링 기능을 지원할 수 있다. 이 경우 CMDH는 기반 네트워크를 사용할 수 있으며, 기반 네트워크에 동일한 전달 핸들링 기능을 액세스하는 프런트엔드로 동작할 수 있다.
DMR(Data Management and Repository)은 M2M 어플리케이션이 다른 개체와 데이터를 교환할 수 있도록 한다. DMR CSF는 데이터 저장 공간을 제공하고 이를 조정하는 기능을 제공한다. 또한 대량의 데이터를 수집하고 결합하거나, 데이터를 특정한 포맷으로 변환하거나, 또는 데이터를 분석 및 시맨틱 프로세싱을 위해 저장하는 기능을 포함한다. "데이터"라는 것은 M2M 디바이스로부터 투명하게 추출되는 로우 데이터(raw data)를 의미하거나 M2M 개체에 의해 계산 또는 결합되어 프로세싱된 데이터를 의미할 수 있다. 대량의 데이터를 수집하는 것은 빅데이터 저장 기능으로 알려진 것을 구성한다.
DMG(Device Management) CSF는 MN과 디바이스 노드 및 M2M 에어리어 네트워크에 있는 디바이스들의 디바이스 기능의 관리를 담당한다. 다음의 기능을 하나 이상 제공하는 디바이스 관리를 가능하게 한다. 어플리케이션 소프트웨어의 설치 및 세팅, 설정 세팅 및 프로비저닝, 펌웨어 업데이트, 로깅과 모니터링과 분석, 에어리어 네트워크의 토폴로지 관리, 그리고 에어리어 네트워크 관리 내의 디바이스를 포함한다.
DIS(디스커버리) CSF는 주어진 범위와 주제 내에서 허락된 권한(M2M 서비스 구독에서 허락된 것을 포함)과 주어진 범위 내에서 오리지네이터(Originator)로부터의 요청에 해당하는 정보와 리소스를 검색하는 것을 책임진다. 오리지네이터는 어플리케이션 또는 다른 CSE가 될 수 있다. 검색의 범위는 하나의 CSE가 되거나 다수의 CSE가 될 수 있다. 디스커버리 결과는 오리지네이터에게 리턴된다.
GMG(Group Management)는 요청과 관련된 그룹을 핸들링한다. 요청은 그룹과 그룹의 멤버십의 관리를 위해 전송되며 또한 그룹에 의해 지원되는 벌크 오퍼레이션도 담당한다. 그룹에 멤버를 추가 또는 삭제할 경우, 멤버가 그룹의 목적에 순응하는지를 확인할 필요가 있다. 벌크 오퍼레이션은 읽기, 쓰기, 구독하기, 알리기, 디바이스 관리 등을 포함한다. 요청 또는 구독은 그룹을 통하여 이루어지고, 그룹이 이러한 요청과 알림을 결합하는 것을 책임진다. 그룹의 멤버는 리소스에 대한 접근 권한에 대해 동일한 역할을 가진다. 이 경우, 접근 제어는 그룹에 의해 이루어진다. 기반 네트워크가 브로드캐스팅과 멀티캐스팅 기능을 제공할 경우, GMG CSF는 이러한 기능을 이용해야 한다.
LOC(Location) CSF는 위치 기반 서비스를 위해 M2M 노드(예를 들어 ASN, MN)의 지리적 위치 정보를 M2M AE가 습득할 수 있도록 한다. 동일한 또는 상이한 M2M 노드 내에 존재하는 M2M AE로부터 이러한 위치 정보가 요청될 수 있다.
NSE(Network Service Exposure) CSF는 M2M 어플리케이션을 대신하여 M2M 시스템으로부터의 서비스 요청에 대한 사용 가능하거나 지원 가능한 방식을 Mcn 참조점을 통하여 네트워크 서비스 기능을 액세스 하기 위해 기반 네트워크와의 통신을 관리한다. NSE CSF는 다른 CSF와 AF를 기반 네트워크에서 지원되는 특정한 기술과 메커니즘으로부터 은폐한다. 기반 네트워크로부터 제공되는 네트워크 서비스 기능은 디바이스 트리거링, 스몰 데이터 전송, 위치 알림, 폴리시 룰 셋팅, 위치 질의, IMS 서비스, 디바이스 관리 등을 포함하지만 이에 한정되지는 않는다. 이러한 기능들은 일반적인 전송 서비스를 포함하지 않는다.
REG(Registration)는 어플리케이션 또는 다른 CSE가 CSE에 등록하도록 핸들링하는 것을 담당하는데, 이는 CSE에서 제공되는 서비스를 사용하려는 개체의 등록을 허락하기 위함이다. REG CSF는 CSE에 대한 디바이스의 등록 뿐만 아니라 디바이스의 특성/속성의 등록도 핸들링한다.
SEC(Security)는 주의를 요하는(센서티브) 데이터 핸들링 기능, 보안 운영 기능, 보안 결합 설정 기능, 권한 부여와 액세스 제어 기능, 식별 보호 기능을 제공한다. SEC CSF가 제공하는 센서티브 데이터 핸들링 기능은 저장과 조작 과정에서 보안이 필요한 로컬 크리덴셜을 보호하는 기능을 제공한다. 센서티브 데이터 핸들링 기능 역시 보안 알고리즘을 사용한다. 이 기능은 다양한 암호기법이 분리된 보안 환경을 지원한다. 보안 운영 기능은 다음의 기능을 제공하는데, 먼저 센서티브 데이터 핸들링 기능에 의해 지원되도록 전용된 보안 환경의 생성과 운영 기능을 제공한다. 또한 보안 환경에서 보호되는 루트 크리덴셜의 포스트 프로비저닝을 지원하며, M2M 서비스와 M2M 어플리케이션 서비스와 관련된 구독의 프로비저닝과 운영을 지원한다. 보안 결합 설정 기능은 M2M 노드들 간의 보안 결합을 설정하여 기밀성, 통합성, 인증, 권한 부여가 가능하도록 한다. 권한 부여와 액세스 제어 기능은 프로비전된 보안 정책과 할당된 롤에 따라 권한 부여된 개체로의 서비스와 데이터 접근을 제어한다. 개체의 유일한 식별자가 권한 부여에 사용되며, 식별 보호 기능은 개체 또는 사용자와 결합된 실제 식별 정보와 링크되지 않도록 임시의 식별자로 기능하는 익명을 제공할 수 있다.
SCA(Service Charging and Accounting)는 서비스 계층의 과금 기능을 제공한다. 온라인 과금과 오프라인 과금을 포함하는 상이한 과금 모델들을 지원한다. SCA CSF는 과금 가능한 이벤트를 확보하고, 정보를 저장하며, 과금 기록과 과금 정보를 생성한다. SCA CSF는 기반 네트워크의 과금 시스템과 상호작용 할 수 있다. 그러나 SCA CSF는 최종 서비스 레벨의 과금 정보를 생성하고 기록할 책임을 가진다. 기반 노드 또는 서비스 계층 과금 서버의 SCA CSF는 과금을 위한 과금 정보를 핸들링하는 것을 책임진다.
SSM(Service Session Management) CSF는 단대단 서비스 계층 연결인 M2M 서비스 세션을 관리한다. SSM CSF는 M2M 어플리케이션들 간의, 또는 M2M 어플리케이션과 CSE 간의, 또는 CSE들 간의 M2M 서비스 세션을 관리한다. M2M 서비스 세션의 관리는 세션 상태의 관리, 세션 인증과 설립, 세션과 관련된 기반 네트워크 연결 및 서비스의 관리, CSE의 멀티 홉인 cse의 세션 확장의 조정, 세션 종단간의 정보의 교환, 그리고 세션의 종료를 포함한다. 주어진 M2M 서비스 세션내에서 다음 홉의 CSE 또는 어플리케이션으로/부터의 메시지 송수신을 위해 SSM CSF는 로컬 CSE 내의 CMDH CSF를 이용한다. SSM CSF는 세션 참가자의 보안 크리덴셜과 인증과 관련된 세션 관리를 위해 SEC CSF를 이용한다. SSM CSF는 세션에 특화된 과금 이벤트를 생성하며 로컬 CSE 내의 SCA CSF와도 통신한다.
SUB(Subscription and Notification)는 구독을 유지하는 알림을 제공하며, 리소스의 변화(예를 들어 리소스의 삭제)를 트래킹한다. 리소스의 구독은 M2M AE 또는 CSE에 의해 시작되며, 호스팅 CSE에 의해 접근 권한이 그랜트된다. 활성화된 구독 중에 호스팅 CSE는 구독된 리소스의 변화가 발생하는 경우 리소스 구독자가 수신하길 원하는 주소로 알림을 전송한다.
도 4 및 그에 대한 설명은 공통 서비스 개체를 구현하는 실시예들이며 본 발명이 이에 한정되지는 않는다.
한편, 본 실시예들에 적용될 수 있는 식별자(identifier)를 살펴보면 다음과 같다. M2M 식별자로는 M2M-SP-ID(M2M Service Provider Identifier), App-Inst-ID(Application Instance Identifier), App-ID(Application Identifier), CSE-ID(CSE Identifier), M2M-Node-ID(M2M Node Identifier/Device Identifier), M2M-Sub-ID(M2M Service Subscription Identifier), M2M-Request-ID(Request Identifier) 등이 있다.
oneM2M은 시스템을 구현하기 위해 충족시켜야 할 요구사항으로 전반적인 시스템 요구사항(Overall System Requirements), 관리 요구사항(Management Requirements), 데이터 모델과 의미 요구사항(Data Model & Semantics Requirements), 보안 요구사항(Security Requirements), 과금 요구사항(Charging Requirements), 운영 요구사항(Operational Requirements)을 제시하고 있다.
본 명세서에서는 M2M 시스템 기술, 특히 oneM2M 서비스 플랫폼 기술을 중심으로 설명한다. 그러나 이러한 설명이 M2M 서비스 플랫폼 기술에만 한정되는 것은 아니며, 기기간 통신, 즉 사물 통신을 제공하는 모든 시스템 및 구조와 이들 시스템에서 발생하는 통신 동작에 적용 가능하다.
또한, 본 명세서에서의 발신자, 발원자, 오리지네이터 등은 메시지를 전송하는 M2M 장치를 의미하는 것이며, 수신자, 리시버, 호스팅 CSE 등은 메시지를 수신하는 M2M 장치를 의미할 수 있다. 다만, 수신자도 응답 메시지를 전송할 수 있고, 발신자도 응답 메시지를 수신할 수 있다. 따라서, 특정 절차에서 요청 메시지를 최초로 전송하는 M2M 장치를 발신자 또는 Originator 또는 발원자로 기재하여 설명하고, 전송된 요청 메시지를 수신하는 M2M 장치를 수신자 또는 Receiver 또는 Hosting CSE로 기재하여 설명한다. 물론, 전술한 바와 같이, 발신자와 수신자 모두 메시지를 송수신할 수 있다.
또한, 본 명세서에서의 M2M 장치는 전술한 AE, CSE, NSE 등을 포함하는 다양한 노드를 의미하는 명칭으로 기재하여 설명하며, 이해의 편의를 위하여 호스팅 CSE를 중심으로 설명을 진행하나 이에 한정되는 것은 아니다. 즉, M2M 장치는 M2M 시스템을 구성하는 일 구성 장치를 의미하며, 요청 메시지를 수신하여 이에 대한 처리를 수행하고 응답 메시지를 전송하는 다양한 노드, 장치, 개체 등을 의미한다.
M2M 시스템에서 M2M 시스템을 구성하는 각 M2M 장치 및 해당 M2M 장치의 정보를 이용하여 사용자에게 응용 프로그램을 제공하는 어플리케이션 등은 서로 필요한 정보를 교환한다. 예를 들어, M2M 장치는 필요한 정보에 대한 생성, 조회, 삭제, 갱신 및 통지의 동작을 수행할 수 있으며, 다른 M2M 장치 및 어플리케이션 등은 해당 동작을 요청할 수 있다.
다만, M2M 시스템은 다수의 M2M 장치에 의해서 구성될 수 있으며, 개별 M2M 장치는 서로 다른 제조사나 오퍼레이터에 의해서 생산 및 동작될 수 있다. 또한, M2M 정보를 이용하는 어플리케이션의 경우에도 다양한 플랫폼에 기반하여 구성될 수 있다. 따라서, M2M 장치 간 또는 M2M 장치와 어플리케이션 간에 서로 다른 데이터 관리 정책(데이터 유형, 인코딩 방식 등)이 적용될 수 있다.
이와 같이, 서로 다른 데이터 관리 정책이 적용되는 경우에 다른 데이터 관리 정책을 사용하는 M2M 장치의 데이터를 빠르고 정확하게 디코딩하여 획득 및 사용하는 데에 문제점이 발생할 수 있다. 예를 들어, 서로 다른 인코딩 유형을 수행하는 M2M 장치 간에는 교환된 정보가 어떠한 유형으로 인코딩되었는지를 확인할 수 없을 수 있다. 따라서, 정보를 수신한 M2M 장치는 해당 정보에 대한 디코딩 동작을 자신의 장치에 적용된 인코딩 유형에 따라 수행하는 경우, 정보가 디코딩되지 않아서 정보를 획득할 수 없는 문제점이 존재한다.
아래에서는 이러한 문제점이 발생하는 상황을 M2M 장치 간의 데이터 송수신 동작을 중심으로 설명한다. 다만, 위에서 설명한 바와 같이 어플리케이션이 M2M 장치의 정보를 활용하는 경우에도 본 개시가 동일하게 적용될 수 있다.
한편, 본 명세서에서의 시계열 자원은 M2M 장치가 관리하는 데이터의 일 예일 뿐 다양한 자원에 동일하게 본 개시가 적용될 수 있다. 즉, 시계열 자원은 상수도 사용량, 전기 사용량과 같이 시계열적으로 수집 및 저장되는 데이터에 대한 자원을 의미하며, 본 개시는 시계열 자원 뿐만 아니라 M2M 장치가 저장하여 관리하는 모든 자원에 동일하게 적용될 수 있다. 아래에서는 필요에 따라 시계열 자원을 <timeSeries> 자원으로 기재하여 설명하며 시계열 자원의 부속자원으로 <timeSeriesInstance> 자원을 예시적으로 설명한다.
한편, M2M 장치는 각 자원에 대해서 부속자원 및 속성정보를 포함할 수 있으며, 부속자원과 속성정보는 그 목적에 따라 구분되어 저장 및 관리될 수 있다.
도 5는 일 실시예에 따른 <timeSeriesInstance> 자원 생성을 위한 요청 메시지를 처리하는 절차를 설명하기 위한 도면이다.
도 5를 참조하면, 발신자(300)는 시계열 인스탄스 자원에 대한 생성을 요청하는 요청 메시지를 수신자(310)로 전송할 수 있다(S310). 예를 들어, 요청 메시지는 필수적 파라미터와 선택적 파라미터를 요청 메시지에 포함시킬 수 있다. 일 예로, 요청 메시지는 송신측 파라미터와 수신측 파라미터, 동작 파라미터와 요청 식별 파라미터를 필수적으로 포함한다. 또한, 요청 메시지는 선택적으로 응답 유형 파라미터를 포함할 수 있다.
S510 단계의 경우에 시계열 인스탄스 자원에 대한 생성을 요청하는 요청 메시지이므로, 동작 파라미터는 생성을 지시하는 값으로 설정되고, 자원 타입은 시계열 인스탄스 자원을 지시하는 값으로 설정된다. 한편, 컨텐츠 파라미터는 생성하고자 하는 컨텐츠 정보를 포함한다.
수신자(310)는 요청 메시지를 수신하고, 해당 요청 메시지의 각 파라미터를 확인하여 지시된 동작을 수행함으로써, 요청 메시지를 처리한다(S520). 예를 들어, 수신자(310)는 시계열 자원의 부속자원으로 시계열 인스탄스 자원을 생성하고, 해당 시계열 인스탄스 자원에 요청 메시지에 포함된 컨텐츠 정보를 저장한다.
이후, 수신자(310)는 S520 단계의 처리 결과에 따라 응답 메시지를 발신자(300)에게 전송한다(S530). 예를 들어, 응답 메시지는 응답 상태 코드 정보 및 요청 식별 파라미터 정보를 포함할 수 있다. 일 예로, 요청 식별 파라미터 정보는 S510 단계의 요청 식별 파라미터 정보와 동일한 값으로 설정되어, 해당 응답 메시지가 어떤 요청 메시지에 대한 응답인지를 나타낸다. 다른 예로, 응답 상태 코드는 성공, 실패, 기타 유형을 지시하는 값으로 설정될 수 있으며, 해당 요청 메시지에 대한 처리가 성공하였는지, 실패하였는지 또는 기타 미리 설정된 유형의 동작이 발생하였는지를 지시한다.
이러한 동작을 통해서 발신자(300)는 수신자(310)에게 특정 자원의 생성을 요청할 수 있으며, 동일 또는 유사한 동작을 통해서 특정 자원에 대한 갱신, 조회, 삭제를 요청할 수도 있다. 또는 수신자(310)는 필요에 따라 특정 자원을 통지할 수도 있다.
도 6은 일 실시예에 따른 요청 메시지의 동작 파라미터에 따른 메시지 코드와 응답 메시지 코드를 예시적으로 도시한 도면이다.
도 6을 참조하면, 도 5의 생성 요청 메시지의 경우에 다양한 방식으로 전송될 수 있다.
일 예로, 도 5의 요청 메시지는 600과 같이 각 파라미터에 대한 값을 포함하여 전송될 수 있다. "to"는 수신측 파라미터로 해당 요청 메시지의 타켓 수신자를 지시한다. "from"은 송신측 파라미터로 요청 메시지를 전송하는 발신자를 지시한다. "op"는 동작 파라미터로 생성, 조회, 갱신, 삭제, 통지 중 어느 하나를 지시하도록 설정된다. 본 예에서는 생성을 지시하는 1로 설정된 경우를 개시하였다. "rqi"는 요청 식별 파라미터로 특정 값으로 설정될 수 있다. "pc"는 컨텐츠를 지시하는 것으로 본 예에서는 자동차, 속도, 날짜, 상태 등에 대한 정보를 포함한다.
요청 메시지는 JSON (JavaScript Object Notation) 형식으로 전송될 수 있으며, 600은 JSON 형식의 자료 구성 방식이다. 또한, 600은 인코딩 유형과 전송하는 데이터를 암호화하지 않는 경우, 즉 컨텐츠 보안이 없음을 암시적으로 나타낸다.
600의 요청 메시지를 수신한 수신자는 해당 요청 메시지 처리 동작을 수행하고 605 형식의 응답 메시지를 전송한다. 예를 들어, "rsc"는 응답 상태 코드 파라미터로 처리 성공(2001)을 지시하는 값으로 설정될 수 있으며, 요청 식별 파라미터는 600의 "rqi"와 동일한 값으로 설정된다. 발신자는 605 응답 메시지를 수신하여, 600의 요청 메시지에 따라 자원이 성공적으로 생성되었음을 인지한다.
한편, 650과 655는 동작 파라미터가 조회로 설정된 경우의 요청 메시지와 응답 메시지의 JSON 형식의 자료 구성 방식을 예시적으로 나타낸다.
650의 경우 동작 파라미터가 2로 설정되어, 조회를 지시하는 값으로 설정될 수 있으며, 특정 자원에 대한 조회 동작을 요청하는 것으로 600과 같이 컨텐츠는 포함하지 않을 수 있다.
수신자는 650 요청 메시지를 수신하면, 컨텐츠에 해당 요청된 자원의 정볼를 포함하여 응답 메시지를 655와 같이 구성하여 전송한다.
650과 655의 경우에도 각 메시지는 JSON (JavaScript Object Notation) 형식으로 전송될 수 있으며, JSON 형식의 자료 구성 방식을 도시하였다. 또한, 650과 655는 인코딩 유형과 전송하는 데이터를 암호화하지 않는 경우, 즉 컨텐츠 보안이 없음을 암시적으로 나타낸다.
다만, 데이터에 대한 미디어 유형, 인코딩 유형, 및 컨텐츠 보안 유형에 따라서 컨텐츠를 표현하는 방법은 매우 다양할 수 있다.
도 7은 데이터 처리 방식에 따라서 다양하게 표현되는 컨텐츠 처리 방법을 설명하기 위한 도면이다. 도 7을 참조하면, 도 6의 요청 메시지 및 응답 메시지와 동일한 컨텐츠라고 하더라도 도 7의 표와 같이 매우 다양한 케이스로 표현될 수 있다.
예를 들어, 미디어 유형은 XML, JSON, CBOR(Concise Binary Object Representation) 세 가지가 존재할 수 있으며, 인코딩 유형도 Plan, Base64와 같이 다양하게 존재할 수 있다. 또한, 도 7에는 개시되지 않았으나, 컨텐츠 보안 유형도 다양하게 설정도리 수 있다.
따라서, 미디어 유형이 3가지이고, 인코딩 유형이 3가지, 컨텐츠 보안 유형이 7가지인 경우에 동일한 컨텐츠 데이터를 표현하는 방법은 63가지의 경우의 수가 발생할 수 있다. 이와 같이, 도 7 이외에도 매우 다양한 형태의 표현 방식이 존재할 수 있다.
이와 같이, 특정 자원에 대해서는 미디어 유형 정보, 인코딩 유형 정보 및 컨텐츠 보안 유형 정보가 정의될 수 있다.
일 예로, 미디어 유형 정보는 RFC6838에 정의되고 있으며, 특정 관리주체(예를 들어, https://www.iana.org/assignments/media-types/media-types.xhtml)에서 관리될 수 있다.
다른 예로, 인코딩 유형 정보는 인코딩을 하지 않는 유형, 문자열과 같은 string data에 대한 Base64 인코딩 유형 및 binary data에 대한 Base64 인코딩 유형 등으로 아래 표 1과 같이 구분될 수 있다.
인코딩 유형 지시 값 인코딩 유형
0 Plain - no transfer encoding is applied
1 base64 encoding is applied on string data
2 base64 encoding is applied on binary data
또 다른 예로, 컨텐츠 보안 유형 정보는 아래 표 2와 같이 구분될 수 있다.
컨텐츠 보안 유형 지시 값 컨텐츠 보안 유형
0 ESData has not been applied to the content data.
1 ESData using JWE and/or JWS with Compact Serialization has been applied to the content data with no subsequent transfer encoding.
2 ESData using JWE and/or JWS with JSON Serialization has been applied to the content data with no subsequent transfer encoding.
3 ESData using JWE and/or JWS with JSON Serialization has been applied to the content data and subsequent base64 encoding (see [9]) has been applied.
4 ESData using XML encryption and/or XML-Signature has been applied to the content data has been applied with no subsequent transfer encoding.
5 ESData using XML encryption and/or XML-Signature has been applied to the content data and subsequent base64 encoding (see [9]) has been applied.
위에서 설명한 각 유형은 일부 예를 들어 표시한 것으로 이 외에도 설정에 따라 다양한 유형이 적용될 수 있다. 이와 같이, 다양한 미디어 유형, 인코딩 유형 및 컨텐츠 보안 유형이 적용될 수 있으므로, 특정 컨텐츠에 대해서 M2M 장치 또는 어플리케이션이 접근하는 경우에 어떤 유형인지를 사전에 인지할 수 없어서 원활한 정보 교환이 이루어지지 못하는 문제점이 발생할 수 있다.
즉, 해당 요청 메시지 또는 응답 메시지를 수신한 M2M 장치는 수신된 컨텐츠 정보가 어떤 미디어 유형, 인코딩 유형, 컨텐츠 보안 유형이 적용되었는지 확인할 수 없고, 프로토콜 규격에 정의된 각각의 유형에 대한 경우의 수(최대 63번)를 모두 조합하여 디코딩을 수행해야하는 문제점이 있다.
도 8은 종래 요청 메시지에 따라 대상 자원을 처리하는 동작을 설명하기 위한 도면이다.
도 8을 참조하면, 요청 메시지를 수신한 M2M 장치는 해당 장치에 미리 설정된 미디어 유형, 인코딩 유형 및 컨텐츠 보안 유형을 적용하여 대상 자원을 생성처리할 수 있다. 즉, 요청 메시지를 전송한 발신자 또는 해당 대상 자원을 사용할 가능성이 있는 어플리케이션과는 무관하게 대상 자원을 처리한다.
예를 들어, M2M 장치는 시계열 인스탄스 자원(<timeSeriesInstance> resource)의 생성을 요청하는 요청 메시지를 수신하면, 해당 요청 메시지의 요청 파라미터를 확인한다(S800). 요청 파라미터 확인에 실패하는 경우, 어떤 요청 메시지인지 확인이 되지 않으므로, M2M 장치는 에러 처리를 수행한다(S810). 이 경우, M2M 장치는 에러 상태에 미리 매핑되어 설정된 응답 상태 코드를 생성하고(S880), 응답 상태 코드를 포함하는 응답 메시지를 전송한다(S890).
한편, 요청 파라미터에 대한 확인이 성공하면, M2M 장치는 시계열 자원의 하위 속성정보에 포함되는 최대 인스탄스 숫자와 현재 저장된 인스탄스 숫자를 비교한다(S820). maxNrOfInstances는 시계열 자원의 최대 인스탄스 숫자를 나타내는 속성정보이고, currentNrOfInstances는 현재 인스탄스 숫자를 나타내는 속성정보이다. 현재 인스탄스 숫자는 요청 메시지에 의해서 지시된 인스탄스의 수를 제외하고 설정될 수도 있고, 포함하여 설정될 수도 있다.
현재 인스탄스 숫자가 최대 인스탄스 숫자를 초과하지 않는 경우에 M2M 장치는 시계열 자원의 하위 속성정보에 포함되는 최대 바이트 사이즈와 현재 바이트 사이즈를 비교한다(S830). CurrentByteSize는 현재 시계열 자원의 바이트 사이즈를 나타내는 속성정보이고, maxByteSize는 시계열 자원에 설정된 최대 바이트 사이즈를 나타내는 속성정보이다.
만약, 현재 바이트가 최대 바이트 사이즈를 초과하지 않는 경우에 M2M 장치는 요청 메시지에 의해서 지시된 시계열 인스탄스 자원을 생성한다(S850). 시계열 인스탄스 자원은 시계열 자원의 하위 부속자원으로 생성될 수 있다.
이와 달리, S820 및 S830 단계 중 어느 하나의 단계에서 현재 인스탄스 숫자 또는 현재 바이트 사이즈가 최대값을 초과하는 경우에 M2M 장치는 해당 요청 메시지를 처리할 수 없음을 지시할 수 없음으로 실패 처리를 수행한다(S840). 이 경우, M2M 장치는 해당 실패 처리 유형에 따라 미리 설정된 응답 상태 코드를 생성하고(S880), 응답 상태 코드를 포함하는 응답 메시지를 전송한다(S890).
S850 단계 이후에 M2M 장치는 시계열 인스탄스 자원이 추가로 생성되었으므로, 시계열 자원의 하위 속성정보 중 currentNrOfInstances 속성정보와 CurrentByteSize 속성정보의 값을 생성된 인스탄스 자원을 반영하여 갱신한다(S860).
이후, M2M 장치는 요청 메시지에 대해서 성공 처리를 수행하고(S870), 성공 처리에 매핑되어 설정된 응답 상태 코드를 생성하여(S880), 응답 메시지에 포함한 후 전송한다(S890).
이러한 일련의 동작을 통해서 M2M 장치는 요청 메시지를 처리한다. 다만, 종래에는 S850 단계에서 별도의 미디어 유형, 인코딩 유형 및 컨텐츠 보안 유형에 대한 내용을 확인하지 않고, M2M 장치에 설정된 정책에 따라 적용하였다. 즉, 종래에는 암묵적으로 대상 자원을 생성할 때 도 7의 케이스 중 어느 하나의 케이스를 적용하여 처리할 수 있다.
예를 들어, M2M 장치가 도 7의 CASE B의 형식을 적용하여 대상 자원을 생성한 경우에 다른 M2M 장치(AE 또는 CSE)는 대상 자원을 탐색하거나 및 사용하려면 선택적 파라미터인 자원 이름 속성 정보 및 라벨 속성정보를 이용하여야 한다. 왜냐하면 다른 M2M 장치는 Base64로 인코딩 된 컨텐츠로 자동차를 탐색 수 없기 때문이다. 만약, 대상 자원을 생성한 M2M 장치가 "자동차"로 라벨 속성정보를 생성하면, 다른 M2M 장치는 해당 라벨 속성정보를 이용하여 대상 자원을 찾을 수 있다. 그러나, 대상 자원에 대한 조회를 요청하는 새로운 발신자는 대상 자원의 컨텐츠 또는 컨텐츠 속성정보인 "ew0KCSJ0aGluZyI6ICJjYXIiLA0KCSJzdGF0dXMiOiAiZHJpdmUiLA0KCSJzcGVlZCI6ICIxMDAiDQp9"을 이해하거나 해석할 수 없다. 이는 대상 자원의 컨텐츠 또는 속성정보가 어떤 유형에 따라 인코딩 되었는지 알 수 없기 때문이다.
이러한 문제점은 대상 자원에 대한 조회를 요청하는 경우에도 유사하게 발생한다.
도 9는 일 실시예에 따른 대상 자원에 대한 조회를 요청하는 요청 메시지에 대한 처리 동작을 설명하기 위한 도면이다.
도 9를 참조하면, 발신자(300)는 특정 자원에 대한 조회(Retrieve) 동작을 요청하는 요청 메시지를 전송할 수 있다(S910). 예를 들어, 요청 메시지는 전술한 동작 파라미터, 수신측 파라미터, 송신측 파라미터 및 요청 식별 파라미터를 필수적으로 포함할 수 있다. 여기서, 동작 파라미터는 조회를 나타내는 값으로 설정된다.
수신자(310)는 요청 메시지를 수신하면, 요청된 동작 파라미터의 동작을 수행하여 조회 동작을 수행한다(S920).
이후, 수신자(310)는 조회된 대상 자원의 컨텐츠를 포함하여 응답 메시지를 발신자(300)에게 전송한다(S1030). 응답 메시지의 요청 식별 파라미터는 요청 메시지의 요청 식별 파라미터와 동일한 값으로 설정될 수 있다. 또한, 수신자(310)는 조회 요청에 대한 처리가 성공한 경우에 이를 지시하는 응답 상태 코드의 값(예를 들어, 2000)을 설정하여 응답 메시지에 포함하여 전송할 수 있다.
도 10과 도 11을 참조하여 도 9에서의 요청 메시지와 응답 메시지의 코드를 설명한다.
도 10은 일 실시예에 따른 <timeSeriesInstance> 자원 조회를 위한 요청 메시지의 코드를 예시적으로 도시한 도면이다.
도 10을 참조하면, 요청 메시지는 동작 파라미터가 2로 설정되어 대상 자원에 대한 조회를 요청하며, 송신측 파라미터, 수신측 파라미터가 포함된다. 또한, 요청 식별 파라미터가 특정 값으로 설정된다.
도 11은 일 실시예에 따른 도 10의 요청 메시지에 대한 응답 메시지의 코드를 예시적으로 도시한 도면이다.
도 11을 참조하면, 응답 메시지는 응답 상태 코드를 통해서 해당 요청 메시지에 대한 처리가 성공적으로 이루어졌음을 나타낸다. 또한, 요청 식별 파라미터는 요청 메시지의 값과 동일하게 설정된다. 컨텐츠 정보에는 조회의 대상이 되는 대상 자원에 대한 정보가 포함된다. 특히, 컨텐츠 정보의 "con"은 해당 자원에 대한 코드가 포함되며, 전술한 바와 같이 수신자가 해당 대상 자원을 저장한 도 7의 CASE B 형태로 포함될 수 있다.
도 12는 종래 도 11의 응답 메시지를 통해서 정보를 추출하는 동작을 설명하기 위한 도면이다.
도 12를 참조하면, 도 11의 응답 메시지 코드를 수신한 요청 메시지 발신자는 수신된 응답 메시지의 응답 상태 코드를 체크한다(S1200). 응답 상태 코드가 요청 메시지의 처리 성공을 지시하는 값으로 설정되면, 발신자는 요청 식별 파라미터가 요청 메시지의 요청 식별 파라미터와 동일한지 체크한다(S1210). S1200과 S1210은 그 순서가 바뀔 수 있다.
발신자는 S1210 단계의 판단 결과 동일한 것으로 판단되면, 컨텐츠가 존재하는지 판단한다(S1220). 컨텐츠가 존재하는 것으로 판단되면, 발신자는 해당 컨텐츠 파라미터에서 컨텐츠 정보를 추출한다(S1230). 다만, 도 11에서와 같이 컨텐츠 정보는 응답 메시지를 전송한 수신자의 데이터 관리 유형에 따라 포함되므로, 발신자는 추출된 컨텐츠 정보가 미리 설정된 발신자의 포맷에 일치하는지를 판단한다(S1240).
또한, S1200, S1210 및 S1220의 각 단계에서 응답 상태 코드가 실패로 지시되거나, 요청 식별 파라미터가 일치하지 않거나, 컨텐츠가 존재하지 않는 경우에 발신자는 에러 처리 동작을 수행한다(S1205).
한편, 발신자는 컨텐츠 정보를 발신자의 데이터 관리 유형을 적용하여 디코딩을 수행한다. 만약, 수신자와 발신자가 서로 다른 데이터 관리 유형을 사용하는 경우에 디코딩은 실패하게 된다. 또는, 발신자는 모든 데이터 관리 유형에 대해서 순차적으로 디코딩을 시도할 수도 있다.
다만, 컨텐츠 정보가 존재하고, 추출도 완료하였으나 포맷을 발신자가 알지 못해서 발신자가 디코딩에 실패하거나, 모든 경우의 수를 순차적으로 적용하여 디코딩을 수행하는 것은 정보 전달 기능에서 치명적인 문제점으로 작용할 수 있다. 즉, 정보가 제대로 교환되지 않거나, 교환된 정보의 획득에 불필요한 리소스가 사용되는 문제점이 있다.
이러한 문제점을 해결하기 위해서 도출된 본 개시는 대상 자원의 하위 속성정보에 데이터 유형에 대한 정보를 추가하여 정보 교환이 원활하게 이루어지도록 하고자 한다.
도 13은 일 실시예에 따른 M2M 장치의 동작을 설명하기 위한 도면이다.
도 13을 참조하면, M2M(Machine to Machine communication) 장치는 메시지를 처리하는 방법에 있어서, 동작 파라미터, 수신측 파라미터, 송신측 파라미터 및 요청 식별 파라미터를 포함하는 요청 메시지를 타 M2M 장치로부터 수신하는 단계를 수행한다(S1300).
예를 들어, 요청 메시지는 필수적 파라미터로 발신자를 지시하는 송신측 파라미터, 수신자를 지시하는 수신측 파라미터, 동작 유형을 지시하는 동작 파라미터와 요청과 응답을 식별하기 위한 요청 식별 파라미터를 포함한다. 또한, 각 동작 파라미터에 따라 선택적으로 컨텐츠 파라미터를 더 포함할 수도 있다. 예를 들어, 생성, 갱신 등의 동작을 지시하는 요청 메시지의 경우에 생성될 대상 자원, 갱신할 컨텐츠에 대한 컨텐츠 파라미터를 포함할 수 있다.
또한, M2M 장치는 자원 정보를 지시하는 속성정보를 포함하여 대상 자원을 동작 파리미터에 의해서 지시된 동작에 따라 처리하는 단계를 수행한다(S1310). 예를 들어, M2M 장치는 요청 메시지를 수신하면, 동작 파라미터에 기초하여 대상 자원을 처리한다.
예를 들어, 속성정보는 대상 자원에 대한 미디어 유형 정보, 인코딩 유형 정보 및 컨텐츠 보안 유형 정보 중 적어도 하나를 포함할 수 있다. 즉, 속성정보는 대상 자원에 적용된 미디어 유형 정보, 인코디 유형 정보 및 컨텐츠 보안 유형 정보 중 적어도 하나에 대한 정보를 포함할 수 있다.
또한, 대상 자원은 시계열 자원 또는 시계열 자원의 하위 부속자원인 시계열 인스탄스 자원일 수 있다. 또는, 대상 자원은 컨텐츠 인스탄스 자원일 수 있다. 즉, 대상 자원은 M2M 장치가 저장 및 관리하는 자원이거나, 해당 자원의 하위 부속자원일 수 있다.
예를 들어, 속성정보는 대상 자원의 하위 속성정보로 Contentinfo 속성정보일 수 있으며, Contentinfo 속성정보는 대상 자원에 적용된 미디어 유형 정보 및 인코딩 유형 정보를 필수적으로 포함하고, 컨텐츠 보안 유형 정보를 선택적으로 포함할 수 있다.
한편, M2M 장치는 대상 자원을 동작 파라미터에 따라 처리함에 있어서 속성정보를 이용할 수 있다.
일 예로, M2M 장치는 동작 파라미터가 생성을 지시하는 경우, 대상 자원에 적용된 미디어 유형 정보, 인코딩 유형 정보 및 컨텐츠 보안 유형 정보 중 적어도 하나의 정보를 Contentinfo 속성정보에 포함하고, Contentinfo 속성정보를 대상 자원의 하위 속성정보로 구성하여 대상 자원을 생성할 수 있다.
다른 예로, M2M 장치는 동작 파라미터가 조회를 지시하는 경우, 발신자가 요청한 조회 대상 자원을 특정하고, 해당 대상 자원에 적용되는 속성정보인 Contentinfo 속성정보를 응답 메시지에 포함할 정보로 특정할 수 있다.
이와 같이, 대상 자원과 해당 대상 자원에 대한 미디어 유형 정보, 인코딩 유형 정보 및 컨텐츠 보안 유형 정보 중 적어도 하나의 정보를 속성정보로 관리함으로써, M2M 장치 간 또는 어플리케이션이 해당 대상 자원에 대한 유형 정보를 명확하게 확인할 수 있다.
또한, M2M 장치는 요청 메시지에 대한 응답 정보를 포함하는 응답 메시지를 전송하는 단계를 수행한다(S1320). 예를 들어, M2M 장치는 동작 파리미터가 조회 또는 통지를 지시하는 경우, 대상 자원 및 속성정보를 포함하여 응답 메시지를 전송한다. 한편, 응답 메시지는 응답 상태 코드를 포함할 수 있으며, 동작 파라미터가 생성, 삭제 등을 지시하는 경우에 해당 동작의 처리 성공, 실패 등을 지시하는 값으로 응답 상태 코드가 설정될 수 있다.
또한, 응답 메시지는 요청 메시지에 포함된 요청 식별 파라미터의 값과 동일한 값으로 설정된 요청 식별 파라미터를 포함한다.
이 외에도, 응답 메시지는 요청 메시지의 응답 모드가 플렉스 블럭킹으로 지시된 경우에 M2M 장치가 처리한 응답 모드에 따라 개별 매핑되는 응답 상태 코드를 포함할 수 있다. 응답 모드는 해당 요청 메시지를 처리하는 동작을 구분하기 위한 것으로, 블럭킹, 동기식 넌블럭킹, 비동기식 넌블럭킹 및 플렉스 블럭킹으로 구분된다. 이 중 플렉스 블럭킹 모드는 수신자가 응답 모드를 결정하는 것으로, 발신자는 수신자가 선택한 응답 모드를 알 수 없다. 따라서, 응답 상태 코드의 성공 처리를 지시하는 값을 각 응답 모드에 따라 구분된 값으로 설정함으로써, 발신자는 응답 메시지를 수신하여 어떤 응답 모드에 따라 요청 메시지에 대한 응답 처리 동작을 수행하면 되는지 인지할 수 있다.
아래에서는 대상 자원이 시계열 자원인 경우와 시계열 인스탄스 자원인 경우의 속성정보 및 부속자원의 구성을 예시적으로 나타낸다.
도 14는 일 실시예에 따른 ContentInfo 속성자원을 포함하는 시계열 자원의 구조를 예시적으로 도시한 도면이다.
도 14를 참조하면, 시계열 자원(<timeseries> resource)는 contentInfo 속성정보를 포함하여 다양한 속성정보와 시계열 인스탄스 자원 등의 부속자원을 포함하여 구성될 수 있다.
예를 들어, contentInfo 속성 정보를 포함하는 <timeSeries> 자원은 표 3과 같이 구성될 수 있다.
Attributes of <timeSeries> Multiplicity RW/ RO/ WO Description <timeSeriesAnnc> Attributes
resourceType 1 RO See clause 9.6.1.3. NA
resourceID 1 RO See clause 9.6.1.3. NA
resourceName 1 WO See clause 9.6.1.3. NA
parentID 1 RO See clause 9.6.1.3. NA
expirationTime 1 RW See clause 9.6.1.3 MA
accessControlPolicyIDs 0..1 (L) RW See clause 9.6.1.3. If no accessControlPolicyIDs value is configured, the accessControlPolicyIDs of the parent resource shall be applied for privilege checking. MA
labels 0..1 (L) RW See clause 9.6.1.3. MA
creationTime 1 RO See clause 9.6.1.3. NA
lastModifiedTime 1 RO See clause 9.6.1.3. NA
stateTag 1 RO See clause 9.6.1.3. OA
announceTo 0..1 (L) RW See clause 9.6.1.3. NA
announcedAttribute 0..1 (L) RW See clause 9.6.1.3. NA
dynamicAuthorizationConsultationIDs 0..1 (L) RW See clause 9.6.1.3. OA
creator 1 RO See clause 9.6.1.3. NA
maxNrOfInstances 0..1 RW Maximum number of direct child <timeSeriesInstance> resources in the <timeSeries> resource. OA
maxByteSize 0..1 RW Maximum size in bytes of data that is allocated for the <timeSeriesInstance> resource for all direct child<timeSeriesInstance> resources. OA
maxInstanceAge 0..1 RW Maximum age of a direct child <timeSeriesInstance> resource in the <timeSeries> resource. The value is expressed in seconds. OA
currentNrOfnstances 1 RO Current number of direct child <timeSeriesInstance> resource in the <timeSeries> resource. It is limited by the maxNrOfInstances. The currentNrOfInstances attribute of the <timeSeries> resource shall be updated on successful creation or deletion of direct child < timeSeriesInstance > resource of <timeSeries > resource. OA
currentByteSize 1 RO Current size in bytes of data stored in all direct child <timeSeriesInstance> resources of a <timeSeries> resource. It is limited by the maxByteSize. The currentByteSize attribute of the <timeSeries> resource shall be updated on successful creation or deletion of direct child < timeSeriesInstance > resource of <timeSeries > resource. OA
periodicInterval 0..1 WO If the Time Sereis Data is periodic, this attribute shall contain the expected amount of time between two instances of Time Series Data. OA
missingDataDetect 0..1 WO Indicates whether the Receiver shall detect the missing Time Series Data if it is periodic. NA
ontologyRef 0..1 RW A reference (URI) of the ontology used to represent the information that is stored in the child <timeSeriesInstance> resources of the present <timeSeriesData> resource (see note). OA
missingDataMaxNr 0..1 RW Maximum number of entries in the missingDataList if the periodicInterval is set and the missingDataDetect is TRUE. OA
missingDataCurrentNr 0..1 RO Current number of the missing Time Series Data in the missingDataList. OA
missingDataList 0..1(L) RO The list of the dataGenerationTime value representing the missing Time Series Data in descending order by time if the periodicInterval is set and the missingDataDetect is TRUE. OA
missingDataDetectTimer 0..1 RW The missingDataDetectTimer after which a missing Time Series Data shall be considered lost by the hosting CSE. Note that the setting of this value may not apply in certain transports such as TCP, and as such the hosting CSE may reject proposed values or suggest different values. OA
contentInfo 0..1 WO This attribute contains information to understand the contents of the content attribute of <timeSeriesInstance>. It shall be composed of two mandatory components consisting of an Internet Media Type (as defined in the IETF RFC 6838) and an encoding type. In addition, an optional content security component may also be included. The format of this attribute is defined in oneM2M TS-0004　[3].If not present, the default shall be a media type of XML, an encoding type of plain text and no optional content security. OA
NOTE: The access to this URI is out of scope of oneM2M.
위 표 3에서는 설명의 편의를 위하여 일부 설명 부분을 "See clause 9.6.1.3."으로 기재하였으며, 해당 부분은 OneM2M TS-0001 문서의 해당 절을 참조하면 된다. 도 15는 일 실시예에 따른 ContentInfo 속성자원을 포함하는 시계열 인스탄스 자원의 구조를 예시적으로 도시한 도면이다.
도 15를 참조하면, 시계열 인스탄스 자원(<timeSeriesInstance> resource)도 미디어 유형, 인코딩 유형 및 컨텐츠 보안 유형 등을 지시하는 정보를 포함하는 contentInfo 속성정보를 포함할 수 있다.
예를 들어, <timeSeriesInstance> 자원은 <timeSeries> 자원의 데이터 객체를 나타낸다. <timeSeriesInstance> 자원은 일단 생성되면 수정할 수 없으며, 응용 객체(AE)는 명시적으로 <timeSeriesInstance> 자원을 삭제할 수 있어야 하며 정책에 따라 플랫폼에서 삭제할 수 있다. 플랫폼에 <timeSeriesInstance> 자원 보존에 대한 정책이 있는 경우에 해당 정책은 <timeSeries> 자원의 maxByteSize, maxNrOfInstances, maxInstanceAge 또는 이러한 속성정보의 조합으로 표현된다. 여러 정책이 시행되는 경우 가장 엄격한 정책이 적용된다. <timeSeriesInstance> 자원은 상위 <timeSeries> 자원과 동일한 액세스 제어 정책을 상속받으며, 자체 accessControlPolicyIDs 속성정보를 갖지 않는다는 점에서 차이점이 있다.
한편, <timeSeriesInstance> 자원은 표 4에 지정된 하위 부속자원을 포함할 수 있다.
Child Resources of < timeSeriesInstance > Child Resource Type Multiplicity Description <timeSeriesInstanceAnnc> Child Resource Types
[variable] <semanticDescriptor> 0..n See clause 9.6.30 <semanticDescriptor>, <semanticDescriptorAnnc>
위 표 4에서는 설명의 편의를 위하여 설명 부분을 "See clause 9.6.30."으로 기재하였으며, 해당 부분은 OneM2M TS-0001 문서의 해당 절을 참조하면 된다. 또한, <timeSeriesInstance> 자원은 표 5에 명시된 속성정보를 포함한다.
Attributes of <timeSeriesInstance> Multiplicity RW/ RO/ WO Description <timeSeriesInstanceAnnc> Attributes
resourceType 1 RO See clause 9.6.1.3. NA
resourceID 1 RO See clause 9.6.1.3. NA
resourceName 1 WO See clause 9.6.1.3. NA
parentID 1 RO See clause 9.6.1.3. NA
labels 0..1 (L) WO See clause 9.6.1.3. MA
creationTime 1 RO See clause 9.6.1.3. NA
expirationTime 1 WO See clause 9.6.1.3. NA
announceTo 0..1 (L) RW See clause 9.6.1.3. NA
announcedAttribute 0..1 (L) RW See clause 9.6.1.3. NA
lastModifiedTime 1 RO See clause 9.6.1.3. NA
contentInfo 1 WO This attribute is an information to understand the contents of content attribute. It shall be composed by three elements of Internet Media Type (as defined in the IETF RFC 6838), encoding type and content security. The delimeter shall be used ':' character as defined in oneM2M TS-0004　[3]. OA
dataGenerationTime 1 WO This attribute contains the time when the data was generated by the AE/CSE. OA
content 1 WO This attribute contains the data generated by the AE/CSE. OA
sequenceNr 0..1 WO This attribute contains the data sequence number generated by the AE/CSE OA
표 3과 같이 표 5에서는 설명의 편의를 위하여 일부 설명 부분을 "See clause 9.6.1.3."으로 기재하였으며, 해당 부분은 OneM2M TS-0001 문서의 해당 절을 참조하면 된다. 이와 같이, <timeSeriesInstance> 자원은 contentInfo 속성정보를 포함할 수 있다. contentInfo 속성정보는 컨텐츠 속성정보의 컨텐츠를 이해하기 위한 정보를 포함할 수 있다. 예를 들어, contentInfo 속성정보는 미디어 유형, 인코딩 유형 및 컨텐츠 보안 유형의 3가지 요소로 구성될 수 있다. 또한, 속성정보를 구분하는 기호(delimeter)는 ':' 문자를 사용한다.
이와 같이, <timeSeries> 자원은 부속자원으로 <timeSeriesInstance> 자원을 가질 수 있다. 전술한 바와 같이 <timeSeriesInstance> 자원도 미디어 유형 등을 지시하는 속성정보를 별도로 포함할 수 있으나, <timeSeriesInstance> 자원에서 생성하는 속성정보는 생성되는 시간에 따라 컨텐츠 속성정보의 값이 달라질 수 있다. 다만, 속성정보를 구성하는 항목은 동일하므로 <timeSeries> 자원에서 contentInfo 속성정보를 포함하는 경우에 <timeSeriesInstance> contentInfo 속성을 이용하는 경우에 비하여, <timeSeriesInstance> 자원을 전달하는데 있어서 통신량을 줄이는 효과가 있다. 또한, 저장 및 관리 측면에서도 데이터의 양을 줄일 수 있으며, 대규모로 <timeSeriesInstance> 자원 정보를 조회하여 추출하는 경우, 처리 방법을 단순화 할 수 있다.
따라서, <timeSeriesInstance> 자원에서 전술한 유형 정보를 포함하는 속성정보가 구성될 수도 있고, 필요에 따라 상위 자원인 <timeSeries> 자원에서 전술한 유형 정보를 포함하는 속성정보가 구성될 수도 있다.
한편, 미디어 유형, 인코딩 유형 및 컨텐츠 보안 유형을 지시하는 속성정보는 컨텐츠 인스탄스 자원의 속성정보로 구성될 수도 있다.
예를 들어, 종래에는 일반적인 데이터를 표현하는 <contentInstance> 자원을 구성하는데 있어서, contentInfo 속성정보가 컨텐츠 보안에 대한 정보가 없어서, 암호화된 데이터를 처리할 수 없는 문제점이 있었다. 즉, <contentInstance> 자원의 content 속성정보의 내용이 암호화 하는 경우, 수신자가 콘텐츠의 내용을 정확히 이해하기 위해서는 최소 7가지의 가능성을 확인하여야 내용을 알 수 있었다. 특히 의료 등 전문적인 데이터는 관계자만 데이터를 열람할 수 있으므로 반드시 데이터의 저장 또는 전송 단계에서 암호화가 필요하다. 따라서 암호화된 일반적인 데이터를 이용하여 응용 서비스 개발을 위한 정보를 획득도 매우 어려웠다.
따라서, 일반적인 데이터 <contentInstance> 자원에 대해서도 전술한 본 개시가 적용되어 일반적인 데이터 <contentInstance> 자원에서도 미디어 유형, 인코딩 유형 및 컨텐츠 보안 유형에 대한 정보를 포함하는 contentInfo 속성정보가 구성될 수 있다. 즉, <contentInstance> 자원을 구성하는 contentInfo 속성정보는 미디어 유형, 인코딩 유형 및 컨텐츠 보안의 3가지 요소로 구성될 수 있다. 또한, 속성정보를 구분하는 기호(delimeter)는 ':' 문자를 사용할 수 있다.
예를 들어, 표 6과 같이 contentInfo 속성정보를 포함하는 <contentInstance> 자원은 다양한 속성정보를 포함할 수 있다.
Attributes of <contentInstance> Multiplicity RW/ RO/ WO Description <contentInstanceAnnc> Attributes
resourceType 1 RO See clause 9.6.1.3. NA
resourceID 1 RO See clause 9.6.1.3. NA
resourceName 1 WO See clause 9.6.1.3. NA
parentID 1 RO See clause 9.6.1.3. NA
labels 0..1 (L) WO See clause 9.6.1.3. MA
expirationTime 1 WO See clause 9.6.1.3. NA
creationTime 1 RO See clause 9.6.1.3. NA
lastModifiedTime 1 RO See clause 9.6.1.3. NA
stateTag 1 RO See clause 9.6.1.3.The stateTag attribute of the parent resource should be incremented first and copied into this stateTag attribute when a new instance is added to the parent resource. OA
announceTo 0..1 (L) WO See clause 9.6.1.3. NA
announcedAttribute 0..1 (L) WO See clause 9.6.1.3. NA
dynamicAuthorizationConsultationIDs 0..1 (L) RW See clause 9.6.1.3. OA
creator 0..1 RO See clause 9.6.1.3. NA
contentInfo 0..1 WO This attribute contains information to understand the contents of content attribute. It shall be composed of two mandatory components consisting of Internet Media Type (as defined in the IETF RFC 6838) and an encoding type. In addition, an optional content security component may also be included. The format of this attribute is defined in oneM2M TS-0004　[3].If not present, the default shall be a media type of XML, an encoding type of plain text and no optional content security. OA
contentSize 1 RO Size in bytes of the content attribute. OA
contentRef 0..1 RW This attribute contains a list of name-value pairs. Each entry expresses and associative reference to a <contentInstance> resource. The name of the entry indicates the relationship and the value of the entry the indicates reference (URI) to the resource. OA
ontologyRef 0..1 WO A reference (URI) of the ontology used to represent the information that is stored in the contentInstances resources of the <container> resource. If this attribute is not present, the contentInstance resource inherits the ontologyRef from the parent <container> resource if present (see　note). OA
content 1 WO Actual content of a contentInstance. This content may be opaque data for understandable with the help of the contentInfo. This may, for example, be an image taken by a security camera, or a temperature measurement taken by a temperature sensor. OA
NOTE: Access to this URI is out of scope of oneM2M.
표 6에서도 설명의 편의를 위하여 일부 설명 부분을 "See clause 9.6.1.3."으로 기재하였으며, 해당 부분은 OneM2M TS-0001 문서의 해당 절을 참조하면 된다.
전술한 바와 같이 본 개시의 경우에 컨텐츠를 M2M 장치가 응답 메시지에 포함하여 전송함에 있어서, 해당 조회의 대상이 되는 대상 자원 컨텐츠의 미디어 유형, 인코딩 유형 및 컨텐츠 보안 유형 중 적어도 하나의 정보를 포함하는 속성정보를 함께 전송한다. 딸다서, 요청 메시지를 전송한 발신자는 응답 메시지를 이용하여 디코딩 실패 또는 디코딩에 많은 자원을 낭비하는 문제점이 발생하지 않는다.
아래에서는 본 개시를 적용한 경우에 컨텐츠를 포함하는 응답 메시지를 수신한 발신자의 동작에 대해서 도면을 참조하여 설명한다.
도 16은 일 실시예에 따른 시계열 인스탄스 자원에 대한 조회 요청 메시지에 따른 응답 메시지에서 정보를 추출하는 동작을 설명하기 위한 도면이다.
도 16을 참조하면, 응답 메시지를 수신한 요청 메시지 발신자는 수신된 응답 메시지의 응답 상태 코드를 체크한다(S1600). 응답 상태 코드가 요청 메시지의 처리 성공을 지시하는 값으로 설정되면, 발신자는 요청 식별 파라미터가 요청 메시지의 요청 식별 파라미터와 동일한지 체크한다(S1610). S1600과 S1610은 그 순서가 바뀔 수 있다.
발신자는 S1610 단계의 판단 결과 동일한 것으로 판단되면, 컨텐츠가 존재하는지 판단한다(S1620). 컨텐츠가 존재하는 것으로 판단되면, 발신자는 해당 컨텐츠의 대상 자원에 대한 속성정보를 체크한다(S1630).
일 예로, 대상 자원인 시계열 자원인 경우에 시계열 자원의 ContentInfo 속성정보를 확인하여 시계열 자원에 대한 미디어 유형, 인코딩 유형 및 컨텐츠 보안 유형 중 적어도 하나의 정보를 확인한다.
다른 예로, 대상 자원인 시계열 인스탄스 자원인 경우에 시계열 인스탄스 자원의 ContentInfo 속성정보 또는 상위자원인 시계열 자원의 ContentInfo 속성정보를 확인하여 시계열 인스탄스 자원에 대한 미디어 유형, 인코딩 유형 및 컨텐츠 보안 유형 중 적어도 하나의 정보를 확인한다.
또 다른 예로, 대상 자원인 컨텐츠 인스탄스 자원인 경우에 컨텐츠 인스탄스 자원의 ContentInfo 속성정보 또는 상위자원인 컨텐츠 자원의 ContentInfo 속성정보를 확인하여 컨텐츠 인스탄스 자원에 대한 미디어 유형, 인코딩 유형 및 컨텐츠 보안 유형 중 적어도 하나의 정보를 확인한다.
이후, 발신자는 확인된 속성정보의 유형 정보에 따라 컨텐츠 정보를 추출한다(S1640). 즉, 전술한 속성정보에 의해서 특정된 미디어 유형 또는 인코딩 유형 또는 컨텐츠 보안 유형을 이용하여 컨텐츠 정보를 디코딩함으로써, 디코딩 실패 또는 디코딩에 자원이 낭비되는 현상을 방지할 수 있다.
또한, S1600, S1610 및 S1620의 각 단계에서 응답 상태 코드가 실패로 지시되거나, 요청 식별 파라미터가 일치하지 않거나, 컨텐츠가 존재하지 않는 경우에 발신자는 에러 처리 동작을 수행한다(S1605).
이상에서 설명한 바와 같이, 대상 자원은 미디어 유형, 인코딩 유형 및 컨텐츠 보안 유형 정보 중 적어도 하나의 정보를 속성정보로 포함하고, M2M 장치는 해당 속성정보를 이용하여 대상 자원을 디코딩함으로써, 디코딩 실패 및 불필요한 자원의 낭비를 방지할 수 있다.
이하에서는 도 1 내지 도 16을 참조하여 설명한 본 실시예를 모두 실시할 수 있는 M2M 장치의 구성을 도면을 참조하여 다시 한 번 설명한다.
도 17은 일 실시예에 따른 M2M 장치의 구조를 도시한 도면이다.
도 17을 참조하면, M2M(Machine to Machine communication) 장치(1700)는 동작 파라미터, 수신측 파라미터, 송신측 파라미터 및 요청 식별 파라미터를 포함하는 요청 메시지를 타 M2M 장치로부터 수신하는 수신부(1730)와 자원 정보를 지시하는 속성정보를 포함하여 대상 자원을 동작 파리미터에 의해서 지시된 동작에 따라 처리하는 제어부(1710) 및 요청 메시지에 대한 응답 정보를 포함하는 응답 메시지를 전송하는 송신부(1720)를 포함할 수 있다.
예를 들어, 요청 메시지는 필수적 파라미터로 발신자를 지시하는 송신측 파라미터, 수신자를 지시하는 수신측 파라미터, 동작 유형을 지시하는 동작 파라미터와 요청과 응답을 식별하기 위한 요청 식별 파라미터를 포함한다. 또한, 요청 메시지는 각 동작 파라미터에 따라 선택적으로 컨텐츠 파라미터를 더 포함할 수도 있다. 예를 들어, 생성, 갱신 등의 동작을 지시하는 요청 메시지의 경우에 생성될 대상 자원, 갱신할 컨텐츠에 대한 컨텐츠 파라미터를 포함할 수 있다.
또한, 제어부(1710)는 요청 메시지를 수신하면, 동작 파라미터에 기초하여 대상 자원을 처리한다.
예를 들어, 속성정보는 대상 자원에 대한 미디어 유형 정보, 인코딩 유형 정보 및 컨텐츠 보안 유형 정보 중 적어도 하나를 포함할 수 있다. 즉, 속성정보는 대상 자원에 적용된 미디어 유형 정보, 인코디 유형 정보 및 컨텐츠 보안 유형 정보 중 적어도 하나에 대한 정보를 포함할 수 있다.
또한, 대상 자원은 시계열 자원 또는 시계열 자원의 하위 부속자원인 시계열 인스탄스 자원일 수 있다. 또는, 대상 자원은 컨텐츠 인스탄스 자원일 수 있다. 즉, 대상 자원은 M2M 장치가 저장 및 관리하는 자원이거나, 해당 자원의 하위 부속자원일 수 있다.
예를 들어, 속성정보는 대상 자원의 하위 속성정보로 Contentinfo 속성정보일 수 있으며, Contentinfo 속성정보는 대상 자원에 적용된 미디어 유형 정보 및 인코딩 유형 정보를 필수적으로 포함하고, 컨텐츠 보안 유형 정보를 선택적으로 포함할 수 있다.
한편, 제어부(1710)는 대상 자원을 동작 파라미터에 따라 처리함에 있어서 속성정보를 이용할 수 있다.
일 예로, 제어부(1710)는 동작 파라미터가 생성을 지시하는 경우, 대상 자원에 적용된 미디어 유형 정보, 인코딩 유형 정보 및 컨텐츠 보안 유형 정보 중 적어도 하나의 정보를 Contentinfo 속성정보에 포함하고, Contentinfo 속성정보를 대상 자원의 하위 속성정보로 구성하여 대상 자원을 생성할 수 있다.
다른 예로, 제어부(1710)는 동작 파라미터가 조회를 지시하는 경우, 발신자가 요청한 조회 대상 자원을 특정하고, 해당 대상 자원에 적용되는 속성정보인 Contentinfo 속성정보를 응답 메시지에 포함할 정보로 특정할 수 있다.
송신부(1720)는 동작 파리미터가 조회 또는 통지를 지시하는 경우, 대상 자원 및 속성정보를 포함하여 응답 메시지를 전송한다. 한편, 응답 메시지는 응답 상태 코드를 포함할 수 있으며, 동작 파라미터가 생성, 삭제 등을 지시하는 경우에 해당 동작의 처리 성공, 실패 등을 지시하는 값으로 응답 상태 코드가 설정될 수 있다.
이 외에도, 제어부(1710)는 본 실시예에 따른 대상 자원에 연계하여 미디어 유형, 인코딩 유형 및 컨텐츠 보안 유형에 대한 정보를 속성정보로 관리하는 데에 따른 전반적인 M2M 장치(1700)의 동작을 제어한다.
또한, 송신부(1720) 및 수신부(1730)는 발신자, 타 M2M 장치, M2M 시스템을 구성하는 다른 노드 및 어플리케이션 사용자 단말기 중 적어도 하나와 본 실시예를 수행하는 데에 필요한 메시지, 신호 및 데이터를 송수신하는 데에 사용된다.
본 명세서에서의 "시스템", "프로세서", "컨트롤러", "컴포넌트", "모듈", "인터페이스", "모델", "유닛" 등의 용어는 일반적으로 컴퓨터 관련 엔티티 하드웨어, 하드웨어와 소프트웨어의 조합, 소프트웨어 또는 실행 중인 소프트웨어를 의미할 수 있다. 예를 들어, 전술한 구성요소는 프로세서에 의해서 구동되는 프로세스, 프로세서, 컨트롤러, 제어 프로세서, 개체, 실행 스레드, 프로그램 및/또는 컴퓨터일 수 있지만 이에 국한되지 않는다. 예를 들어, 컨트롤러 또는 프로세서에서 실행 중인 애플리케이션과 컨트롤러 또는 프로세서가 모두 구성 요소가 될 수 있습니다. 하나 이상의 구성 요소가 프로세스 및/또는 실행 스레드 내에 있을 수 있으며 구성 요소는 한 시스템에 위치하거나 두 대 이상의 시스템에 배포될 수 있다.
전술한 실시예에서 언급한 표준내용 또는 표준문서들은 명세서의 설명을 간략하게 하기 위해 생략한 것으로 본 명세서의 일부를 구성한다. 따라서, 위 표준내용 및 표준문서들의 일부의 내용을 본 명세서에 추가하거나 청구범위에 기재하는 것은 본 발명의 범위에 해당하는 것으로 해석되어야 한다.
이상의 설명은 본 발명의 기술 사상을 예시적으로 설명한 것에 불과한 것으로서, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자라면 본 발명의 본질적인 특성에서 벗어나지 않는 범위에서 다양한 수정 및 변형이 가능할 것이다. 따라서, 본 발명에 개시된 실시예들은 본 발명의 기술 사상을 한정하기 위한 것이 아니라 설명하기 위한 것이고, 이러한 실시예에 의하여 본 발명의 기술사상의 범위가 한정되는 것은 아니다. 본 발명의 보호 범위는 아래의 청구범위에 의하여 해석되어야 하며, 그와 동등한 범위 내에 있는 모든 기술 사상은 본 발명의 권리범위에 포함되는 것으로 해석되어야 할 것이다.
CROSS-REFERENCE TO RELATED APPLICATION
본 특허출원은 2017년 06월 23일 한국에 출원한 특허출원번호 제 10-2017-0079775호 및 2017년 06월 28일 한국에 출원한 특허출원번호 제 10-2017-0082083호및 2017년 07월 06일 한국에 출원한 특허출원번호 제 10-2017-0086171호 및 2018년 06월 21일 한국에 출원한 특허출원번호 제 10-2018-0071308호에 대해 미국 특허법 119(a)조 (35 U.S.C § 119(a))에 따라 우선권을 주장하며, 그 모든 내용은 참고문헌으로 본 특허출원에 병합된다. 아울러, 본 특허출원은 미국 이외에 국가에 대해서도 위와 동일한 이유로 우선권을 주장하면 그 모든 내용은 참고문헌으로 본 특허출원에 병합된다.

Claims (16)

  1. M2M(Machine to Machine communication) 장치가 메시지를 처리하는 방법에 있어서,
    동작 파라미터, 수신측 파라미터, 송신측 파라미터 및 요청 식별 파라미터를 포함하는 요청 메시지를 타 M2M 장치로부터 수신하는 단계;
    자원 정보를 지시하는 속성정보를 포함하여 대상 자원을 상기 동작 파리미터에 의해서 지시된 동작에 따라 처리하는 단계; 및
    상기 요청 메시지에 대한 응답 정보를 포함하는 응답 메시지를 전송하는 단계를 포함하는 방법.
  2. 제 1 항에 있어서,
    상기 속성정보는,
    상기 대상 자원에 대한 미디어 유형 정보, 인코딩 유형 정보 및 컨텐츠 보안 유형 정보 중 적어도 하나를 포함하는 것을 특징으로 하는 방법.
  3. 제 1 항에 있어서,
    상기 대상 자원은,
    시계열 자원 또는 시계열 인스탄스 자원인 것을 특징으로 하는 방법.
  4. 제 1 항에 있어서,
    상기 대상 자원은,
    컨텐츠 인스탄스 자원인 것을 특징으로 하는 방법.
  5. 제 1 항에 있어서,
    상기 속성정보는,
    Contentinfo 속성정보이며,
    상기 대상 자원에 적용된 미디어 유형 정보 및 인코딩 유형 정보를 필수적으로 포함하고, 컨텐츠 보안 유형 정보를 선택적으로 포함하는 것을 특징으로 하는 방법.
  6. 제 5 항에 있어서,
    상기 처리하는 단계는,
    상기 동작 파라미터가 생성을 지시하는 경우, 상기 대상 자원에 적용된 상기 미디어 유형 정보, 상기 인코딩 유형 정보 및 상기 컨텐츠 보안 유형 정보 중 적어도 하나의 정보를 상기 Contentinfo 속성정보에 포함하고,
    상기 Contentinfo 속성정보를 상기 대상 자원의 하위 속성정보로 구성하여 상기 대상 자원을 생성하는 것을 특징으로 하는 방법.
  7. 제 5 항에 있어서,
    상기 응답 메시지는,
    상기 동작 파리미터가 조회 또는 통지를 지시하는 경우, 상기 대상 자원 및 속성정보를 포함하는 것을 특징으로 하는 방법.
  8. 제 1 항에 있어서,
    상기 응답 메시지는,
    상기 요청 메시지에 포함된 상기 요청 식별 파라미터의 값과 동일한 값으로 설정된 요청 식별 파라미터를 포함하는 것을 특징으로 하는 방법.
  9. 메시지를 처리하는 M2M(Machine to Machine communication) 장치에 있어서,
    동작 파라미터, 수신측 파라미터, 송신측 파라미터 및 요청 식별 파라미터를 포함하는 요청 메시지를 타 M2M 장치로부터 수신하는 수신부;
    자원 정보를 지시하는 속성정보를 포함하여 대상 자원을 상기 동작 파리미터에 의해서 지시된 동작에 따라 처리하는 제어부; 및
    상기 요청 메시지에 대한 응답 정보를 포함하는 응답 메시지를 전송하는 송신부를 포함하는 M2M 장치.
  10. 제 9 항에 있어서,
    상기 속성정보는,
    상기 대상 자원에 대한 미디어 유형 정보, 인코딩 유형 정보 및 컨텐츠 보안 유형 정보 중 적어도 하나를 포함하는 것을 특징으로 하는 M2M 장치.
  11. 제 9 항에 있어서,
    상기 대상 자원은,
    시계열 자원 또는 시계열 인스탄스 자원인 것을 특징으로 하는 M2M 장치.
  12. 제 9 항에 있어서,
    상기 대상 자원은,
    컨텐츠 인스탄스 자원인 것을 특징으로 하는 M2M 장치.
  13. 제 9 항에 있어서,
    상기 속성정보는,
    Contentinfo 속성정보이며,
    상기 대상 자원에 적용된 미디어 유형 정보 및 인코딩 유형 정보를 필수적으로 포함하고, 컨텐츠 보안 유형 정보를 선택적으로 포함하는 것을 특징으로 하는 M2M 장치.
  14. 제 13 항에 있어서,
    상기 제어부는,
    상기 동작 파라미터가 생성을 지시하는 경우, 상기 대상 자원에 적용된 상기 미디어 유형 정보, 상기 인코딩 유형 정보 및 상기 컨텐츠 보안 유형 정보 중 적어도 하나의 정보를 상기 Contentinfo 속성정보에 포함하고,
    상기 Contentinfo 속성정보를 상기 대상 자원의 하위 속성정보로 구성하여 상기 대상 자원을 생성하는 것을 특징으로 하는 M2M 장치.
  15. 제 13 항에 있어서,
    상기 응답 메시지는,
    상기 동작 파리미터가 조회 또는 통지를 지시하는 경우, 상기 대상 자원 및 속성정보를 포함하는 것을 특징으로 하는 M2M 장치.
  16. 제 9 항에 있어서,
    상기 응답 메시지는,
    상기 요청 메시지에 포함된 상기 요청 식별 파라미터의 값과 동일한 값으로 설정된 요청 식별 파라미터를 포함하는 것을 특징으로 하는 M2M 장치.
PCT/KR2018/007070 2017-06-23 2018-06-22 M2m 시스템에서 메시지를 처리하는 방법 및 그 장치 WO2018236179A1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US16/626,280 US11533597B2 (en) 2017-06-23 2018-06-22 Method for processing message in M2M system and device therefor

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
KR20170079775 2017-06-23
KR10-2017-0079775 2017-06-23
KR20170082083 2017-06-28
KR10-2017-0082083 2017-06-28
KR20170086171 2017-07-06
KR10-2017-0086171 2017-07-06
KR1020180071308A KR102051839B1 (ko) 2017-06-23 2018-06-21 M2m 시스템에서 메시지를 처리하는 방법 및 그 장치
KR10-2018-0071308 2018-06-21

Publications (1)

Publication Number Publication Date
WO2018236179A1 true WO2018236179A1 (ko) 2018-12-27

Family

ID=64735813

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2018/007070 WO2018236179A1 (ko) 2017-06-23 2018-06-22 M2m 시스템에서 메시지를 처리하는 방법 및 그 장치

Country Status (1)

Country Link
WO (1) WO2018236179A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113875209A (zh) * 2019-05-13 2021-12-31 现代自动车株式会社 用于在m2m系统中删除资源的方法和装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20160082967A (ko) * 2013-11-08 2016-07-11 엘지전자 주식회사 M2m 통신 시스템에서 구독 및 통지를 위한 방법 및 이를 위한 장치
KR20170001942A (ko) * 2015-06-26 2017-01-05 주식회사 케이티 M2m 시스템에서 요청 메시지를 처리하는 방법 및 그 장치
KR20170007691A (ko) * 2015-07-09 2017-01-19 주식회사 케이티 M2m 시스템에서 응답 정보를 수신하는 방법 및 그 장치
KR20170010300A (ko) * 2015-07-17 2017-01-26 주식회사 케이티 M2m 시스템에서 요청 메시지를 처리하는 방법 및 그 장치
KR20170052477A (ko) * 2015-10-30 2017-05-12 주식회사 케이티 M2m 시스템에서 데이터를 처리하는 방법 및 장치

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20160082967A (ko) * 2013-11-08 2016-07-11 엘지전자 주식회사 M2m 통신 시스템에서 구독 및 통지를 위한 방법 및 이를 위한 장치
KR20170001942A (ko) * 2015-06-26 2017-01-05 주식회사 케이티 M2m 시스템에서 요청 메시지를 처리하는 방법 및 그 장치
KR20170007691A (ko) * 2015-07-09 2017-01-19 주식회사 케이티 M2m 시스템에서 응답 정보를 수신하는 방법 및 그 장치
KR20170010300A (ko) * 2015-07-17 2017-01-26 주식회사 케이티 M2m 시스템에서 요청 메시지를 처리하는 방법 및 그 장치
KR20170052477A (ko) * 2015-10-30 2017-05-12 주식회사 케이티 M2m 시스템에서 데이터를 처리하는 방법 및 장치

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113875209A (zh) * 2019-05-13 2021-12-31 现代自动车株式会社 用于在m2m系统中删除资源的方法和装置

Similar Documents

Publication Publication Date Title
WO2015069038A1 (ko) M2m 통신 시스템에서 구독 및 통지를 위한 방법 및 이를 위한 장치
WO2014129802A1 (ko) M2m 서비스 설정 변경 방법 및 이를 위한 장치
WO2016195199A1 (ko) 무선 통신 시스템에서 폴링 채널을 통해 요청을 처리하기 위한 방법 및 이를 위한 장치
WO2015046960A1 (ko) M2m 시스템에서 통지 메시지 전달 방법 및 이를 위한 장치
WO2018034494A1 (ko) 챗봇 간에 사용자의 이벤트를 공유하는 방법 및 장치
WO2012141556A2 (en) Machine-to-machine node erase procedure
WO2013025085A2 (en) Apparatus and method for supporting family cloud in cloud computing system
WO2016126021A1 (ko) 무선 통신 시스템에서 통지 수신 중단 요청을 처리하기 위한 방법 및 이를 위한 장치
WO2016064235A2 (ko) 무선 통신 시스템에서 그룹 멤버의 자식 자원을 관리하기 위한 방법 및 이를 위한 장치
WO2021091307A1 (ko) 무선 통신 시스템에서 mbs 서비스 제공에 대한 mbs 서비스 세션의 설정을 위한 장치 및 방법
WO2017073876A1 (ko) 무선 통신 시스템에서 서비스 요청을 처리하기 위한 방법 및 이를 위한 장치
WO2016013846A1 (ko) 무선 통신 시스템에서 요청 메시지를 처리하기 위한 방법 및 이를 위한 장치
WO2021141291A1 (ko) 무선 통신 시스템에서 네트워크 트래픽을 수집하는 방법 및 장치
WO2019235804A1 (en) Method and apparatus for installing and managing profile using message service
EP3824594A1 (en) Apparatus and method for ssp device and server to negotiate digital certificates
WO2018101565A1 (ko) 네트워크 가상화 환경에서 보안 관리를 위한 구조
KR102051839B1 (ko) M2m 시스템에서 메시지를 처리하는 방법 및 그 장치
WO2018236137A1 (ko) M2m 시스템에서 요청 메시지를 처리하는 방법 및 그 장치
WO2019098678A1 (ko) 보안 서비스를 제공하기 위한 방법 및 이를 위한 장치
WO2018236179A1 (ko) M2m 시스템에서 메시지를 처리하는 방법 및 그 장치
WO2017082506A1 (ko) 무선 통신 시스템에서 통지 수신 중단 요청을 처리하기 위한 방법 및 이를 위한 장치
WO2016209053A1 (en) Communication method in terminal and terminal suitable for the same
WO2017014381A1 (ko) 무선 통신 시스템에서 자원의 동기를 유지하기 위한 방법 및 이를 위한 장치
WO2010090465A2 (ko) 통신 시스템에서 세션 히스토리 송수신 방법
WO2020166927A1 (ko) 구독 및 통지를 수행하는 방법 및 장치

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: 18820376

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18820376

Country of ref document: EP

Kind code of ref document: A1