Method and apparatus for deleting resources in an M2M system

Abstract

The present invention aims to delete a resource in a machine-to-machine (M2M) system. A method of operating an M2M device in the M2M system includes: generating a request message containing information associated with deletion of a resource performed in response to an operation; and sending the request message to a peer M2M device. The information contains at least one of information notifying that the resource is deleted in response to the operation, information indicating the resource, information indicating at least one operation as a condition for the deletion, information indicating the content of the condition, and information for identifying an entity performing the operation causing the deletion.

Description

Technical Field

[0001] The present disclosure relates to a method and apparatus for deleting resources in a machine-to-machine (M2M) system, and more particularly, to a method and apparatus for identifying a service entity that provides a suitable service platform for an application in the M2M system. Background Art

[0002] Recently, the introduction of machine-to-machine (M2M) systems has occurred. M2M communication may refer to communication performed between machines without human intervention. M2M may refer to machine type communication (MTC), Internet of Things (IoT), or device-to-device (D2D). In the following description, the term "M2M" is used for ease of explanation, but the present disclosure is not limited thereto. A terminal used for M2M communication may be an M2M terminal or an M2M device. An M2M terminal may typically be a device with low mobility while sending a small amount of data. Here, the M2M terminal may be used in conjunction with an M2M server that centrally stores and manages machine-to-machine communication information.

[0003] In addition, M2M terminals can be applied to various systems such as object tracking, vehicle linkage, and power metering.

[0004] Meanwhile, for M2M terminals, the oneM2M Standardization Organization provides requirements for M2M communications, object-to-object communications, and IoT technologies, as well as architecture, application program interface (API) specifications, security solutions, and interoperability technologies. The oneM2M Standardization Organization's specifications provide a framework to support various applications and services, such as smart cities, smart grids, connected cars, home automation, security, and health. Summary of the Invention

[0005] The present disclosure relates to providing a method and apparatus for setting a condition for deleting resources in an M2M system.

[0006] The present disclosure aims to provide a method and apparatus for deleting resources without an explicit request based on satisfaction of a condition in an M2M system.

[0007] According to an embodiment of the present disclosure, a method for operating a machine-to-machine (M2M) device in an M2M system includes generating a request message including information associated with deletion of a resource performed in response to an operation, and transmitting the request message to a counterpart M2M device. The information includes at least one of information notifying that the resource is deleted in response to the operation, information indicating the resource, information indicating at least one operation that is a condition for the deletion, information indicating the content of the condition, and information identifying an entity that performed the operation that caused the deletion.

[0008] According to an embodiment of the present disclosure, a method for operating an M2M device in an M2M system includes: receiving a request message including information associated with deletion of a resource performed in response to an operation; and deleting the resource when a condition set based on the information is satisfied. The information includes at least one of information notifying that the resource is deleted in response to the operation, information indicating the resource, information indicating at least one operation that is a condition for deletion, information indicating the content of the condition, and information identifying an entity that performed the operation that caused the deletion.

[0009] According to an embodiment of the present disclosure, an M2M device in an M2M system includes: a transceiver configured to transmit and receive signals; and a processor configured to control the transceiver. The processor generates a request message including information associated with deleting a resource in response to an operation, and transmits the request message to a peer M2M device. The request message includes at least one of information notifying that the resource is to be deleted in response to the operation, information indicating the resource, information indicating at least one operation that is a condition for deletion, information indicating the content of the condition, and information identifying the entity that performed the operation that resulted in the deletion.

[0010] According to the present disclosure, data in an M2M system can be appropriately deleted according to characteristics of applications or data.

[0011] Effects obtained in the present disclosure are not limited to the above-mentioned effects, and other effects not mentioned above can be clearly understood by those skilled in the art from the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 is a diagram illustrating a layered structure of a machine-to-machine (M2M) system according to the present disclosure.

[0013] Figure 2 is a diagram illustrating reference points in an M2M system according to the present disclosure.

[0014] Figure 3 is a diagram illustrating each node in an M2M system according to the present disclosure.

[0015] Figure 4 is a diagram illustrating a public service function in an M2M system according to the present disclosure.

[0016] Figure 5 is a diagram illustrating an initiator and a receiver exchanging messages in an M2M system according to the present disclosure.

[0017] Figure 6 is a diagram illustrating a process of deleting resources according to an explicit request in an M2M system according to the present disclosure.

[0018] Figure 7is a diagram illustrating a process of deleting resources according to a volatility feature in an M2M system according to the present disclosure.

[0019] Figure 8 is a diagram illustrating a method for operating an apparatus for requesting a creation request in an M2M system according to the present disclosure.

[0020] Figure 9 is a diagram illustrating a method for operating an apparatus for creating resources in an M2M system according to the present disclosure.

[0021] Figure 10 is a diagram illustrating an example of a process for creating and deleting a resource having a volatile characteristic in an M2M system according to the present disclosure.

[0022] Figure 11 is a diagram illustrating a configuration of an M2M device in an M2M system according to the present disclosure.

[0023] Figure 12 is a diagram illustrating an example of utilizing resources having a volatile characteristic in an M2M system according to the present disclosure. DETAILED DESCRIPTION

[0024] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings, which is easy for those skilled in the art to implement. However, the present disclosure can be implemented in many different forms and is not limited to the embodiments described herein.

[0025] In the present disclosure, unless otherwise specifically stated, the terms first, second, etc. are used only to distinguish one component from another component, and do not limit the order or importance of the components, etc. Therefore, within the scope of the present disclosure, a first component in one embodiment may be referred to as a second component in another embodiment, and similarly, a second component in one embodiment may be referred to as a first component.

[0026] In the present disclosure, when a component is referred to as being “linked,” “coupled,” or “connected” to another component, it is understood that not only a direct connection relationship but also an indirect connection relationship through an intermediate component may be included. In addition, when a component is referred to as “including” or “having” another component, it may mean that the other component is further included rather than excluded unless explicitly described otherwise.

[0027] In this disclosure, components that are distinguished from each other are intended to clearly illustrate each feature. However, this does not necessarily mean that the components are separate. That is, multiple components can be integrated into a single hardware or software unit, or a single component can be distributed across multiple hardware or software units. Therefore, unless otherwise specified, such integrated or distributed embodiments are also included in the scope of this disclosure.

[0028] In the present disclosure, the components described in the various embodiments are not necessarily essential components, and some components may be optional components. Therefore, embodiments consisting of a subset of the components described in one embodiment are also included in the scope of the present disclosure. In addition, embodiments that include other components in addition to the components described in the various embodiments are also included in the scope of the present disclosure.

[0029] In the following description of the embodiments of the present disclosure, when the known functions and configurations incorporated herein may make the subject matter of the present disclosure rather unclear, detailed descriptions of the known functions and configurations incorporated herein will be omitted. Parts in the drawings that are not related to the description of the present disclosure are omitted, and similar parts are represented by similar reference numerals.

[0030] In addition, this specification describes a network based on machine-to-machine (M2M) communication, and operations in the M2M communication network may be performed in the process of network control and data transmission in a system managing the communication network.

[0031] In this specification, an M2M terminal may be a terminal that performs M2M communication. However, considering backward compatibility, an M2M terminal may be a terminal operating in a wireless communication system. In other words, an M2M terminal may refer to a terminal operating based on an M2M communication network, but is not limited thereto. An M2M terminal may operate based on another wireless communication network and is not limited to the above embodiments.

[0032] In addition, an M2M terminal may be fixed or have mobility. In addition, an M2M server refers to a server for M2M communication and may be a fixed station or a mobile station.

[0033] In addition, in this specification, entity may refer to hardware such as M2M device, M2M gateway and M2M server. In addition, for example, entity may be used to refer to software configuration in the layered structure of M2M system, and is not limited to the above embodiments.

[0034] In addition, for example, the present disclosure mainly describes an M2M system, but is not limited to being applicable to an M2M system.

[0035] In addition, an M2M server may be a server that communicates with an M2M terminal or another M2M server. Furthermore, an M2M gateway may be a connection point between an M2M terminal and an M2M server. For example, when an M2M terminal and an M2M server are on different networks, the M2M terminal and the M2M server may be connected to each other via an M2M gateway. Here, for example, both the M2M gateway and the M2M server may be M2M terminals, and the present invention is not limited to the above-described embodiments.

[0036] oneM2M is the de facto standards organization that was established to develop a common IoT service platform that shares and integrates an application service infrastructure (platform) environment, rather than a fragmented service platform development structure limited to individual industries like energy, transportation, defense and public services. oneM2M aims to address requirements for object-to-object communication and IoT technologies, architectures, application program interface (API) specifications, security solutions and interoperability. For example, the specifications of oneM2M provide a framework to support various applications and services such as smart cities, smart grids, connected cars, home automation, security and health. In this regard, oneM2M has developed a set of standards that define a single horizontal platform for data exchange and sharing between all applications. oneM2M can also consider applications across different industrial sectors. Just like an operating system, oneM2M provides a framework to connect different technologies, creating a distributed software layer that promotes unification. The distributed software layer is implemented in a common service layer between the M2M applications and the communication hardware / software (HW / SW) rendering data transmission. For example, the common service layer can be Figure 1 A portion of the hierarchical structure is shown.

[0037] Figure 1 is a diagram illustrating a layered structure of a machine-to-machine (M2M) system according to the present disclosure.

[0038] refer to Figure 1 The layered structure of an M2M system may consist of an application layer 110, a public service layer 120, and a network service layer 130. Here, the application layer 110 may be a layer that operates based on a specific application. For example, the application may be a fleet tracking application, a remote blood glucose monitoring application, an energy metering application, or a control application. In other words, the application layer may be a layer for a specific application. Here, an entity operating based on the application layer may be an application entity (AE).

[0039] The public service layer 120 may be a layer for a public service function (CSF). For example, the public service layer 120 may be a layer for providing public services such as data management, device management, M2M service subscription management, and location services. For example, an entity operating based on the public service layer 120 may be a public service entity (CSE).

[0040] The Common Services Layer 120 can provide a set of services grouped into CSFs based on their functionality. A large number of instantiated CSFs constitute a CSE. A CSE can interface with applications (e.g., Application Entities or AEs in oneM2M terminology), other CSEs, and the underlying network (e.g., Network Service Entities or NSEs in oneM2M terminology).

[0041] The network service layer 130 may provide services such as device management, location service, and device triggering for the public service layer 120. Here, an entity operating based on the network service layer 130 may be a network service entity (NSE).

[0042] Figure 2 is a diagram illustrating reference points in an M2M system according to the present disclosure.

[0043] refer to Figure 2 , the M2M system structure can be divided into field domain and infrastructure domain. Here, in each domain, each entity can perform communication through a reference point (e.g., Mca or Mcc). For example, the reference point can indicate the communication flow between each entity. Here, the reference Figure 2 , a reference point Mca between the AE 210 or 240 and the CSE 220 or 250 , a reference point Mcc between different CSEs, and a reference point Mcn between the CSE 220 or 250 and the NSE 230 or 260 may be set.

[0044] Figure 3 is a diagram illustrating each node in an M2M system according to the present disclosure.

[0045] refer to Figure 3 The infrastructure domain of a specific M2M service provider may provide a specific infrastructure node (IN) 310. Here, the CSE of the IN may communicate based on the reference point Mca between the AE and another infrastructure node. In this case, one IN may be provided for each M2M service provider. In other words, the IN may be a node that communicates with another infrastructure M2M terminal based on the infrastructure structure. Furthermore, conceptually, a node may be, for example, a logical entity or a software configuration.

[0046] Next, the application-specific node (ADN) 320 may be a node that includes at least one AE but does not include a CSE. Here, the ADN may be set up in the field domain. In other words, the ADN may be a node dedicated to the AE. For example, the ADN may be a node installed in hardware within an M2M terminal. Furthermore, the application service node (ASN) 330 may be a node that includes a CSE and at least one AE. The ASN may be set up in the field domain. In other words, the ASN may be a node that includes both the AE and the CSE. In this case, the ASN may be a node connected to the IN. For example, the ASN may be a node installed in hardware within an M2M terminal.

[0047] In addition, the intermediate node (MN) 340 can be a node including a CSE and zero or more AEs. Here, the MN can be set in the field. The MN can be connected to another MN or IN based on a reference point. In addition, for example, the MN can be set in the M2M gateway in hardware.

[0048] In addition, as an example, the non-M2M terminal node 350 (non-M2M device node, NoDN) is a node that does not include an M2M entity. The non-M2M terminal node 350 may be a node that performs management or cooperation with the M2M system.

[0049] Figure 4 is a diagram illustrating a public service function in an M2M system according to the present disclosure.

[0050] refer to Figure 4 , can provide public service functions. For example, the public service entity can set up at least one or more CSFs in application and service layer management 402, communication management and transmission processing 404, data management and storage 406, device management 408, discovery 410, group management 412, location 414, network service exposure / service execution and triggering 416, registration 418, security 420, service billing and calculation 422, service session management and subscription / notification 424. In this case, the M2M terminal can operate based on the public service functions. In addition, the public service functions are also possible in other embodiments and are not limited to the above embodiment.

[0051] Application and Service Layer Management 402CSF provides management of AE and CSE. Application and Service Layer Management 402CSF includes not only the configuration, problem resolution, and upgrade of CSE functions, but also the ability to upgrade AE.

[0052] The Communication Management and Delivery Process 404CSF provides communication with other CSEs, AEs, and NSEs. The Communication Management and Delivery Process 404CSF determines when and over what connection to deliver communications, and also determines to buffer communication requests so that they can be delivered later if necessary and permitted.

[0053] Data Management and Storage 406CSF provides data storage and delivery functions (e.g., data collection for aggregation, data reformatting, and data storage for analysis and semantic processing).

[0054] Device Management 408 The CSF provides management of device capabilities in the M2M gateway and M2M devices.

[0055] Discovery 410CSF provides information retrieval capabilities for applications and services based on screening criteria.

[0056] The Group Management 412CSF provides processing for group-related requests. The Group Management 412CSF enables the M2M system to support batch operations of many devices and applications.

[0057] Location 414CSF provides functionality that enables AE to obtain geographic location information.

[0058] Network Service Exposure / Service Execution and Triggering 416 The CSF manages communications with the underlying network to access network service functions.

[0059] Registration 418CSF provides the function of registering AE (or other remote CSE) with CSE.Registration 418CSF allows AE (or remote CSE) to use the services of CSE.

[0060] Security 420CSF provides security functions such as access control for the service layer, which includes identification, authentication and permission.

[0061] Service Billing and Calculation 422CSF provides billing functions for the service layer.

[0062] Subscription / Notification 424CSF provides functionality that allows subscription to events and notification of event occurrences.

[0063] Figure 5 is a diagram illustrating an initiator and a receiver exchanging messages in an M2M system according to the present disclosure.

[0064] refer to Figure 5 , initiator 501 can send a request message to receiver 520. Here, initiator 510 and receiver 520 can be the aforementioned M2M terminals. However, initiator 510 and receiver 520 are not limited to M2M terminals and can be other terminals. They are not limited to the aforementioned embodiments. Furthermore, for example, initiator 510 and receiver 520 can be the aforementioned nodes, entities, servers, or gateways. In other words, initiator 510 and receiver 520 can be hardware or software configurations and are not limited to the aforementioned embodiments.

[0065] Here, for example, the request message sent by initiator 510 may include at least one parameter. Here, for example, a parameter may be a mandatory parameter or an optional parameter. For example, mandatory parameters may include parameters related to the transmitting terminal, parameters related to the receiving terminal, identification parameters, and operation parameters. Optional parameters may also relate to other types of information. Here, parameters related to the transmitting terminal may be parameters for initiator 510. Furthermore, parameters related to the receiving terminal may be parameters for recipient 520. Furthermore, identification parameters may be parameters required for mutual identification.

[0066] In addition, the operation parameter can be a parameter used to distinguish the operation. For example, the operation parameter can be set to any one of create, retrieve, update, delete, and notify. In other words, the parameter may be used to distinguish the operation.

[0067] Here, upon receiving a request message from the initiator 510, the receiver 520 may process the message. For example, the receiver 520 may perform an operation included in the request message. For the operation, the receiver 520 may determine whether the parameters are valid and authorized. Here, if the parameters are valid and authorized, the receiver 520 may check whether the requested resource exists and may perform processing accordingly.

[0068] For example, when an event occurs, the initiator 510 may send a request message including a notification parameter to the receiver 520. The receiver 520 may check the notification parameter included in the request message and perform an operation accordingly. The receiver 520 may send a response message to the initiator 510.

[0069] like Figure 5 The message exchange process using the request message and the response message shown can be performed between an AE and a CSE based on the reference point Mca or between CSEs based on the reference point Mcc. In other words, the initiator 510 can be an AE or a CSE, and the receiver 520 can be an AE or a CSE. Figure 5 The message exchange process shown can be initiated by either the AE or the CSE.

[0070] The request from the requester to the recipient over the reference points Mca and Mcc may include at least one mandatory parameter and at least one optional parameter. In other words, each defined parameter may be mandatory or optional depending on the requested operation. For example, the response message may include at least one of the parameters listed in Table 1 below.

[0071] Table 1

[0072]

[0073]

[0074] The screening criteria conditions that can be used in a request message or a response message can be defined as shown in Table 2 and Table 3 below.

[0075] Table 2

[0076]

[0077]

[0078]

[0079]

[0080] Table 3

[0081]

[0082]

[0083] The response to a request to access a resource via the reference points Mca and Mcc may include at least one mandatory parameter and at least one optional parameter. In other words, each defined parameter may be mandatory or optional depending on the requested operation or mandatory response code. For example, the request message may include at least one of the parameters listed in Table 4 below.

[0084] Table 4

[0085]

[0086]

[0087] A normal resource comprises a complete representation of the data that forms the basis of the information to be managed. Unless qualified as "virtual" or "public", the resource types in this document are normal resources.

[0088] Virtual resources are used to trigger processing and / or retrieve results. However, virtual resources have no permanent representation in CSE.

[0089] The announcement resource contains a set of properties of the original resource. When the original resource changes, the announcement resource is automatically updated by the original resource's hosting CSE. The announcement resource contains a link to the original resource.

[0090] Resource advertisement enables resource discovery. An advertised resource at a remote CSE can be used to create a sub-resource at the remote CSE that does not exist as a sub-resource of the original resource or is not its advertised sub-resource.

[0091] To support resource advertisements, additional columns in resource templates can specify attributes to be advertised for inclusion in the associated advertised resource type. For each advertised <resourceType>, adding the suffix "Annc" to the original <resourceType> can be used to indicate its associated advertised resource type. For example, the resource <containerAnnc> can be indicated as the resource type advertised by the <container> resource, while <grouβAnnc> can be indicated as the resource type advertised by the <group> resource.

[0092] Resources are specified based on the CSE. Resources are the CSE representations of components and elements in the oneM2M system. Application data and commands representing other CSEs, AEs, and sensors are communicated to the CSE as resource representations.

[0093] Resources are uniquely addressable entities in the oneM2M architecture. Resources can be transferred and manipulated using Create, Retrieve, Update, and Delete (CRUD) operations.

[0094] A child resource is a sub-resource of another resource that is a parent resource. The parent resource includes a reference to at least one child resource.

[0095] Attributes store information associated with a resource. When a set of attributes is not common to all resources, the set of attributes is not enumerated in the graphical representation of the resource.

[0096] Attributes are categorized as universal attributes, public attributes, and resource-specific attributes. Universal attributes appear on every resource, while public attributes appear on multiple resources and have the same meaning no matter where they appear.

[0097] Table 5 below shows examples of properties that are virtual or undeclared and are common and generic to each resource type.

[0098] Table 5

[0099]

[0100]

[0101] Table 6 below shows examples of attributes that are virtual or undeclared and that are common and commonly used in multiple resource types rather than all resource types.

[0102] Table 6

[0103]

[0104]

[0105]

[0106]

[0107]

[0108] The oneM2M system supports expiration timers for deleting resources from the hosting CSE after a specific amount of time / specific date. IoT services with temporary access and characteristics can use expiration timers. With expiration timers, resources can be deleted after a given time interval. The oneM2M mechanism for deleting current data is limited to support various emerging IoT / M2M applications. For example, in the case of a chat application using images / photos, when the user reads the received data, the data is deleted within 10 seconds, but when the user does not read the data, the data is deleted after 24 hours. As another example, in the case of services involving security and privacy, any data involving personal information should not be shared with other users and stored in the platform. In the case of medical and wearable IoT services, medical data should only be read by dedicated medical experts (e.g., doctors) and the data should be deleted after that.

[0109] As mentioned above, depending on the characteristics of the data or application, an algorithm is needed to delete data under predetermined conditions. Here, the predetermined condition is not just the passage of a specific time, but can also be defined in various ways. For example, the data deletion condition can be associated with the corresponding data operation (e.g., reading, retrieving, etc.).

[0110] To this end, the present disclosure proposes a method for deleting data based on an operation on the data. According to an embodiment of the present disclosure, a volatile feature can be assigned to the data. The volatile feature can be assigned to the resource that stores the data. In the following, "creation of a resource" will be used in the same meaning as "creation of data", and "deletion of a resource" will be used in the same meaning as "deletion of data". When the volatile feature is not used, the deletion of the resource after the operation is completed can be performed under an explicit request. The process is as follows Figure 6 Shown in.

[0111] Figure 6 1 is a diagram illustrating a process of deleting resources according to an explicit request in an M2M system according to the present disclosure. Figure 6 In FIG, AE-1 610a is a producer that creates resources, while AE-2 610b is a consumer that uses data. Although AE-1 610a and AE-2 610b are shown as different entities, AE-1 610a and AE-2 610b may be the same entity in some cases.

[0112] refer to Figure 6AE-1 610a requests CSE 620 to create and subscribe to <Resource 1> 622. Therefore, CSE 620 creates <Resource 1> 622. Here, AE-1 610a predetermines that <Resource 1> 622 will be deleted after creation and when read by any user. For example, <Resource 1> 622 is a placeholder for storing data from AE-1 610a and is expected to be consumed by AE-2 610b.

[0113] Next, AE-2 610b retrieves <Resource 1> 622 stored in CSE 620. Specifically, AE-2 610b reads <Resource 1> 622. Therefore, CSE 620 notifies AE-1 610a to retrieve <Resource 1> 622. Having been notified by CSE 620 of the retrieval of <Resource 1> 622, AE-1 610a requests CSE 620 to delete <Resource 1> 622. CSE 620 deletes <Resource 1> 622 at AE-1 610a's request.

[0114] As in reference Figure 6 In the process described above, when the AE does not notify the data or resource of the volatile feature, the AE monitors the occurrence of events of the resource (e.g., retrieval or reading) and explicitly requests deletion. Therefore, the present disclosure proposes a method for deleting a resource without an explicit request by notifying the existence of the volatile feature when the resource is created. In this case, it is possible to Figure 7 Modifications shown Figure 6 process.

[0115] Figure 7 FIG. 1 is a diagram illustrating a process of deleting resources according to a volatile feature in an M2M system according to the present disclosure. Figure 7 In FIG, AE-1 710a is a producer that creates resources, and AE-2 710b is a consumer that uses data. Although AE-1 710a and AE-2 710b are shown as different entities, AE-1 710a and AE-2 710b may be the same entity in some cases.

[0116] refer to Figure 7AE-1 710a requests CSE 720 to create and subscribe to <Resource 1> 722. Consequently, CSE 720 creates <Resource 1> 722. Here, <Resource 1> 722 is created with the volatile attribute, and deletion criteria are transmitted to CSE 720. The deletion criteria can be transmitted in various ways according to the various embodiments described below. Next, AE-2 710b retrieves <Resource 1> 722 stored in CSE 720. That is, AE-2 710b reads <Resource 1> 722. Next, based on the volatile attribute of <Resource 1> 722 and the deletion criteria, CSE 720 deletes <Resource 1> 722.

[0117] As in reference Figure 7 In the described process, the signaling for deleting the resource can be omitted by notifying the CSE that created the resource that the resource has a volatile characteristic.

[0118] The conditions for deleting a resource with volatile characteristics can be defined differently. In addition, different attributes can be used depending on the condition. Examples of attributes used according to each condition are shown in Table 7 below. Table 7 is an example of a high-level use case of attributes for resource deletion.

[0119] Table 7

[0120]

[0121] Figure 8 is a diagram illustrating a method for operating an apparatus for requesting a creation request in an M2M system according to the present disclosure. Figure 8 The operation subject may be the AE of the device requesting to create a resource. Figure 8 The operating entity of the process is called a "device".

[0122] refer to Figure 8 , in step S801, the device generates a request message including information associated with the deletion of a resource performed in response to an operation. The request message may be a message requesting the creation of a resource, including information associated with the deletion of the resource. Here, the operation is related to the resource to be deleted, and may be, for example, a read operation (e.g., retrieval). As another example, the operation may be at least one of update, create, delete, and notify. According to an embodiment, the information associated with the deletion of a resource may include at least one of information indicating that the resource is deleted in response to a specific operation, information indicating the resource to be deleted, information indicating an operation as a condition for deletion, information indicating the content of the condition (e.g., the number of operations), and information for identifying the entity that performs the operation that results in the deletion. For example, the information associated with the deletion of a resource may have a counter type that decreases according to the occurrence of the operation.

[0123] In step S803, the device sends a request message. Thus, the conditions for deleting the resource specified by the request message are set by the peer device, and when the set conditions are met, the resource can be deleted without a separate explicit request. Here, the request message may be a message requesting the creation of the resource to be deleted or a message different from the message requesting the creation of the resource. When the request message is a message different from the message requesting the creation of the resource to be deleted, although not in Figure 8 As shown in , the device may send a message requesting creation of the resource to be deleted before the current step S803.

[0124] Figure 9 is a diagram illustrating a method for operating an apparatus for creating resources in an M2M system according to the present disclosure. Figure 9 The operation subject may be the service layer or CSE of the device requesting to create resources. Figure 9 The operating entity of the process is called a "device".

[0125] refer to Figure 9 In step S901, the device receives a request message including information associated with the deletion of a resource performed in response to an operation. The request message may be a message requesting the creation of a resource, including information associated with the deletion of the resource. Here, the operation is related to the resource to be deleted, and may be, for example, a read operation (e.g., retrieval). As another example, the operation may be at least one of update, create, delete, and notify. According to an embodiment, the information associated with the deletion of a resource may include at least one of information indicating that the resource is deleted in response to a specific operation, information indicating the resource to be deleted, information indicating an operation as a condition for deletion, information indicating the content of the condition (e.g., the number of operations), and information for identifying the entity that performs the operation that results in the deletion. For example, the information associated with the deletion of a resource may have a counter type.

[0126] In step S903, the device sets a condition for deleting the resource. That is, the device sets the condition for deleting the resource based on the information associated with the resource deletion included in the request message. For example, when the resource deletion information indicates the number of times a specific operation (e.g., retrieval) has been performed, the device may generate a parameter indicating the remaining number of times the specific operation has been performed as a condition for deleting the resource.

[0127] In step S905, the device checks whether the condition for deleting the resource is met. For example, when the condition is the number of times a specific operation has been performed, the device checks whether the number of times the operation has been performed on the resource has reached a specified number. To this end, the device can decrement a counter initialized to the specified number of times each time an operation occurs.

[0128] When the deletion condition is met, the device deletes the resource in step S907. However, regardless of whether the deletion condition is met, the resource can be deleted under a separate request. When the resource is deleted upon request before the deletion condition is met, the device can stop the current process without executing steps S905 and S907.

[0129] Figure 10 is a diagram illustrating an example of a process for creating and deleting a resource having a volatile characteristic in an M2M system according to the present disclosure.

[0130] refer to Figure 10 In step S1001, AE#1 1010a requests to create a resource with a volatile feature. That is, AE#1 1010a sends a request message regarding resource creation, and the request message includes information indicating the volatile feature of the resource. In addition, the request message may include further information notifying conditions for deleting the resource.

[0131] In step S1003, IN-CSE 1020 performs local processing. In other words, IN-CSE 1020 creates the requested resource with the given volatility information. Specifically, IN-CSE 1020 creates the requested resource and sets conditions for resource deletion. In step S1005, IN-CSE 1020 sends a response message to AE#1 1010a.

[0132] In step S1007, AE#2 1010b sends a request message for resource retrieval to IN-CSE 1020. Here, the request message requests retrieval of the resource created by the request message in step S1001. In step S1009, IN-CSE 1020 sends a response message to AE#2 1010b. The response message may include data contained in the requested resource.

[0133] In step S1011, IN-CSE 1020 performs local processing. In other words, if the deletion condition is met, IN-CSE 1020 deletes the resource. Specifically, the deletion condition may be met by the request in step S1007. In this case, IN-CSE 1020 deletes the resource created in step S1003. On the other hand, if the condition is not met, IN-CSE 1020 may not delete the resource.

[0134] As described above, a resource can be set to be volatile. To this end, the AE transmits information about the conditions for deleting the resource to the hosting CSE, either through the operation that creates the resource or a separate operation. The hosting CSE then sets the conditions based on the transmitted information. Various embodiments of such transmitted information or information indicating the set conditions are described below.

[0135] According to an embodiment, readCounter / readDeleteCounter can be defined as information about deleting resources. The IoT system performs self-deletion after the user reads the resource. To this end, readCounter / readDeleteCounter can be defined as public attributes in Table 8.

[0136] Table 8

[0137]

[0138] Since readDeletionCtr includes a self-deletion indication, it is different from readCtr. readCtr can be used for deletion using another self-deletion indication, which means that readCtr can be used for different operations. However, readDeletionCtr includes a self-deletion indication and can therefore delete resources without other deletion requests or indications. When a resource is created, this new type of public attribute can be created at the same time. When an initiator wants to create a new resource in the hosting CSE, the initiator can send a request together with information about the resource information including some attributes to the hosting CSE. readCtr and / or readDeletionCtr can be included in the creation request message. Based on the counter, resources can be deleted without interrupting the initiator, which simplifies the process of deleting messages and reduces time and overhead.

[0139] According to an embodiment, as information about deleting a resource, a volatile attribute can be defined. That is, volatileAttr can be added as an attribute. The added attribute can be defined as one of the public attributes. Alternatively, the added attribute can be an attribute of data associated with a resource (such as contentInstance or container). The attribute provides conditions and information about deleting the resource. For example, the attribute may include an indication that the resource should be deleted under certain conditions. As another example, the attribute may include default behavior information that is set to be deleted once the data is read or after an expiration time even if the data is not read. As another example, the attribute may include information about the following conditions: data should not be updated within a certain time interval, the value should be greater than a certain value, the data should be read by a certain application, and the data should be read a predetermined number of times.

[0140] VolatileAttr acts as a delete indicator. Like readCtr, another attribute can be a condition for deletion. Unlike readDeletionCtr, readCtr does not have a self-deletion implication. To use this type of attribute as a condition for deletion, an additional delete indicator / command is required.

[0141] The newly defined volatileAttr can easily become a deletion indicator. For example, when the initiator wants to use a predefined attribute as a deletion condition, the initiator can indicate the deletion condition through volatileAttr, and when the indicated deletion condition is met, the resource can be deleted accordingly. Through the volatileAttr indication, the initiator can use another predefined attribute as a deletion condition. In addition, since volatileAttr has the meaning of a deletion condition, no additional deletion indication is required. In particular, in the oneM2M system, volatileAttr is a very simple and effective method to implement the self-deletion function.

[0142] According to an embodiment, a volatile resource indicator may be defined as information about deleting a resource. The request message may include various optional parameters. The volatile resource indicator may be added as an optional parameter to indicate that the resource created with this parameter has a volatile feature. In addition, filtering criteria describing the conditions for deleting a resource may be added to the request message. When no filtering criteria exist, a default behavior may be used to delete the read resource. The volatile resource indicator may be applied to a create operation. The volatile resource indicator may be defined in Table 9 below.

[0143] Table 9

[0144]

[0145] Like volatileAttr, the volatile resource indicator can be a very simple and effective way to implement self-deletion functionality. According to an embodiment, deleteReadCtr can be defined as information about deleting a resource. deleteReadCtr can be defined as an optional parameter to indicate that a resource created with this parameter should be deleted when its value is 0. The initial value of this parameter is greater than 0 and decreases each time a resource is read.

[0146] According to an embodiment, deleteCtr and readCtr may be defined as information about deleting a resource. deleteCtr may be defined as an optional parameter. When the value of readCtr is the same as the value of deleteCtr, it indicates that the resource created with that parameter should be deleted. The initial value of deleteCtr is greater than 0. readCtr may be defined as an optional parameter to track the number of read operations on a resource with that parameter. The initial value of readCtr is 0 and is incremented each time a resource is read.

[0147] According to an embodiment, as information about deleting resources, a counter for each operation (e.g., createCtr, readCtr, WriteCtr, deleteCtr, and notifyCtr) may be defined. The system may have a separate counter for each operation in order to track the number of times each operation of a resource is performed. createCtr, readCtr, WriteCtr, deleteCtr, and notifyCtr are used for create operations, retrieval operations, update operations, delete operations, and notification operations, respectively. deleteCtr may be defined as an optional parameter to indicate that when the value of the counter for a particular operation is the same as the value of deleteCtr, the resource created with the parameter should be deleted. The initial value of this parameter is greater than 0, and the target operation (e.g., read, write, notify) may be specified. For example, the value "1: read" may be understood as deleting the resource when a retrieval operation is performed on the resource.

[0148] According to an embodiment, as information about deleting resources, operationCtr and deleteCtr may be defined. operationCtr may be defined as an optional parameter used to count the number of specific operations. This parameter may consist of 5 tuples with integer values ​​corresponding to create, retrieve, update, delete, and notify. The initial value of each tuple is 0 and is incremented when the corresponding operation is performed on the resource. For example, when there is a retrieval operation on a resource, the second tuple is incremented and the result is <0, 1, 0, 0, 0>. operationCtr may be used for other purposes. For example, when a user reads a resource a specific number of times, the tuple corresponding to the retrieval may be used to delete the resource. deleteCtr may be defined as an optional parameter used to indicate that when the value of the counter for a specific operation is the same as the value of deleteCtr, the resource created with the parameter should be deleted. The initial value of this parameter is greater than 0 and the target operation (e.g., read, write, notify) may be specified. For example, the value "1: read" may be understood as deleting the resource when a retrieval operation is performed on the resource once.

[0149] Figure 11 is a diagram illustrating a configuration of an M2M device in an M2M system according to the present disclosure.

[0150] refer to Figure 11 , the M2M device 1110 may include a processor 1112 for controlling the device and a transceiver 1114 for transmitting and receiving signals. Here, the processor 1112 may control the transceiver 1114. In addition, the M2M device 1110 may communicate with another M2M device 1120. The other M2M device 1120 may further include a processor 1124 and a transceiver 1122, and the processor 1124 and the transceiver 1122 may perform the same functions as the processor 1112 and the transceiver 1114.

[0151] For example, the initiator and receiver described above could be Figure 11 One of the M2M devices 1110 and 1120. In addition, Figure 11 The devices 1110 and 1120 may be different devices. For example, Figure 11 The devices 1110 and 1120 may be communication devices, vehicles or base stations. In other words, Figure 11 The devices 1110 and 1120 refer to devices that can perform communication and are not limited to the above-described embodiments.

[0152] According to the above embodiments of the present disclosure, resources can be deleted without explicit request but under set conditions. Resources with volatile characteristics (deleted without explicit request) can be applied to various scenarios. For example, an example of using resources with volatile characteristics is as follows.

[0153] Figure 12 is a diagram illustrating an example of utilizing a resource having a volatile feature in an M2M system according to the present disclosure. Figure 12 , a vehicle 1210a equipped with sensors 1212 operates as an AE and sends event data recorder (EDR) data to the oneM2M IoT platform 1220. The EDR data can be stored in the oneM2M IoT platform 1220 and read by an application 1210b or a third party 1210c.

[0154] In the automotive industry, cloud-based EDR systems are a key system feature for enabling autonomous driving. Sensor data collected from vehicle 1210a is transmitted to the oneM2M IoT platform 1220 for analysis of collisions or accidents. Because sensor data is not only personal but also includes highly sensitive information about an individual's car, it is desirable for the service provider not to retain at least a portion of the event data. Therefore, the volatility feature described in the above-described embodiment can be applied to at least a portion of the EDR data.

[0155] As another example, resources with volatile characteristics may be used for healthcare and physical examination services for immigrants.

[0156] Passengers will occasionally have their medical conditions checked and basic information stored. Medical conditions are checked for infectious diseases. Healthcare and medical examination services enable fast and secure immigration.

[0157] Biomedical data (e.g., temperature, electrocardiogram (ECG) signals, etc.) is analyzed in the IoT cloud platform. The analysis results are transmitted to a security gateway or officials. In the event that a passenger removes the wearable device (e.g., oneM2M Wearable ASN), the wearable device detects the removal and deletes all stored information, preventing others from maliciously using the information.

[0158] Additionally, data in the cloud IoT platform can be deleted based on rules. There can be multiple criteria for deleting stored data. According to various embodiments, deletion of stored data can be performed based on various body signals, predetermined signals, and the user's location based on detection mechanisms. For example, if a passenger's paired signal is not detected within a given time period, the device can delete personal information. As another example, the device can delete personal information when a specific signal is received. As yet another example, the device can delete personal information when a passenger enters a specific area.

[0159] The above-mentioned embodiments of the present disclosure may be implemented by various means. For example, the embodiments of the present disclosure may be implemented by hardware, firmware, software or a combination thereof.

[0160] The foregoing description of the preferred embodiments of the present disclosure has been presented for those skilled in the art to implement and perform the present disclosure. Although the foregoing description has been presented with reference to the preferred embodiments of the present disclosure, it will be apparent to those skilled in the art that various modifications and changes may be made to the present disclosure without departing from the spirit or scope of the present disclosure as defined by the appended claims. Therefore, the present disclosure is not intended to be limited to the embodiments shown herein, but rather to the widest scope consistent with the principles and novel features disclosed herein. In addition, although the preferred embodiments of the present specification have been specifically shown and described, it should be understood that the present specification is not limited to the above-described embodiments, but on the contrary, those skilled in the art will understand that various changes and modifications may be made without departing from the spirit and scope of the present specification as defined by the appended claims, and that these changes and modifications should not be understood separately from the technical ideas and viewpoints of the present specification.

[0161] In this specification, both the present disclosure and the method disclosure are explained, and the descriptions of the two disclosures can be supplemented as needed.

[0162] In addition, the present disclosure has been described with reference to the preferred embodiments of the present disclosure. It will be understood by those skilled in the art that various changes may be made to the form and details thereof without departing from the essential characteristics of the present disclosure. Therefore, the disclosed embodiments should be considered in an illustrative rather than a restrictive sense. The scope of the present disclosure is limited by the appended claims rather than the foregoing description, and all differences within the scope of their equivalents should be interpreted as included in the present disclosure.

Claims

1. A method for operating an M2M device in a machine-to-machine (M2M) system, the method comprising the following steps: Generate a request message for creating a resource, wherein the resource includes a <contentinstance> a resource, the corresponding attribute comprising data and a counter, wherein the counter has an initial value greater than 0 and is decremented by 1 for each retrieval operation performed on the resource, wherein the retrieval operation comprises another M2M device reading data of the resource, and when the counter becomes 0, the resource including the data and the counter should be deleted; and< / contentinstance> The request message is sent to the hosting common service entity CSE to create the resource.

2. The method according to claim 1, wherein The corresponding attributes also include: resourceType, resourceID, resourceName, parentID, creationTime and lastModifiedTime.

3. The method of claim 1, wherein the data comprises one or more of: sensor data, security data, health or medical data, biomedical data, or personal data. The method according to claim 1 , wherein the M2M device comprises at least one of a CSE or an application entity (AE).

5. The method according to claim 1, further comprising: In response to the request message, a response message is received from the hosting common service entity CSE.

6. A method for operating an M2M device in a machine-to-machine (M2M) system, the method comprising the following steps: Receive a request message for creating a resource, wherein the resource includes a <contentinstance> a resource, the corresponding attribute comprising data and a counter, wherein the counter has an initial value greater than 0 and is decremented by 1 for each retrieval operation performed on the resource, wherein the retrieval operation comprises another M2M device reading data of the resource, and when the counter becomes 0, the resource including the data and the counter should be deleted; and< / contentinstance> The resource is created in response to the request message.

7. The method according to claim 6, wherein: The corresponding attributes also include: resourceType, resourceID, resourceName, parentID, creationTime and lastModifiedTime.

8. The method of claim 6, wherein the data comprises one or more of: sensor data, security data, health or medical data, biomedical data, or personal data. 9 . The method according to claim 6 , wherein the M2M device comprises at least one of a Common Service Entity (CSE) or an Application Entity (AE).

10. The method according to claim 6, wherein: The request message is received from an application entity (AE), and the method further comprises: In response to the request message, a response message is sent to the AE.

11. An M2M device in a machine-to-machine (M2M) system, the M2M device comprising: a transceiver operatively coupled to the processor, The transceiver and the processor are configured as follows: Generate a request message for creating a resource, wherein the resource includes a <contentinstance>a resource, the corresponding attribute comprising data and a counter, wherein the counter has an initial value greater than 0 and is decremented by 1 for each retrieval operation performed on the resource, wherein the retrieval operation comprises another M2M device reading data of the resource, and when the counter becomes 0, the resource including the data and the counter should be deleted; and< / contentinstance> The request message is sent to the hosting common service entity CSE to create the resource.

12. The M2M device according to claim 11, wherein: The corresponding attributes also include: resourceType, resourceID, resourceName, parentID, creationTime and lastModifiedTime. 13 . The M2M device of claim 11 , wherein the data comprises one or more of: sensor data, security data, health or medical data, biomedical data, or personal data. The M2M apparatus according to claim 11 , wherein the M2M device comprises at least one of a CSE or an application entity (AE).

15. The M2M device according to claim 11, wherein the transceiver and the processor are further configured to: In response to the request message, a response message is received from the hosting common service entity CSE.

Images