KR20180108279A - Transaction Management Method on M2M Platform - Google Patents

Abstract

Provided is a method for managing transactions in an M2M platform. According to the present invention, a CSE performs transaction management instead of an AE in an M2M system, thereby reducing a load of the AE due to the transaction management and enabling effective transaction management in a platform level. The method comprises the steps of: generating first resources; generating second resources; and managing the second resources.

Description

Transaction Management Method on M2M Platform < RTI ID = 0.0 >

The present invention relates to M2M (Machine to Machine) / IoT (Internet of Things) technology, and more particularly to a method for transaction management in M2M platform.

IoT (Internet of Things), M2M (Machine to Machine), etc. are used to refer to concepts and technologies for connecting objects to a network or establishing a communication network between objects using communication devices attached to objects, And object intelligence communication.

In this network environment, communication network between object and object as well as person-to-person and person-to-object communication becomes possible and information sharing among all objects becomes possible, which is an essential technical element for evolving into the future ubiquitous information service society.

In the M2M / IoT system, transaction management is performed by an AE (Application Entity) in the M2M / IoT system. However, there is a problem that not only the AE is overloaded but also the transaction management is not effective.

SUMMARY OF THE INVENTION It is an object of the present invention to provide a method for CSE (Common Service Entity) in an M2M system to perform transaction management instead of AE.

According to an aspect of the present invention, there is provided a transaction method including: generating a first resource for transaction management by a first CSE (Common Service Entity) at the request of an originator; The second CSEs creating second resources for the transaction tasks at the request of the first CSE; And the first CSE managing the second resources using the first resource.

The first resource may then include a transaction state attribute indicating the state of the transactional tasks.

The first resource may also include a constructor attribute to notify of an update of the transaction state attribute.

Only the constructor and the first CSE can update the transaction state attribute to Commit.

It can also include transaction timer attributes to execute transactional tasks.

The first resource may include an attribute indicating a method of processing transaction tasks when the transaction tasks can not be completely committed, and an attribute indicating a method of processing the first resource after both transaction tasks are committed.

In addition, the second resource may include an attribute indicating the status of the transaction task.

According to another aspect of the present invention, there is provided a transaction system comprising: a first CSE (Common Service Entity) for generating a first resource for transaction management at the request of an originator; And second CSEs for generating second resources for the transaction tasks at the request of the first CSE, wherein the first CSE manages the second resources using the first resource.

As described above, according to the embodiments of the present invention, in the M2M system, the CSE performs transaction management instead of AE, thereby reducing load of AE due to transaction management and enabling efficient transaction management at the platform level.

1 is a flowchart showing a transaction configuration process,
FIG. 2 is a flowchart showing a process of transmitting a transaction commit result,
FIG. 3 illustrates a child resource of a < transactionMgmt > resource,
Figure 4 shows the properties of the < transactionMgmt > resource,
FIG. 5 illustrates a child resource of a < transactiont > resource,
Figure 6 shows the properties of the < transaction > resource,
FIG. 7 is a diagram illustrating an M2M system to which the present invention is applicable, and FIG.
8 is an internal block diagram of the electronic devices shown in Fig.

Hereinafter, the present invention will be described in detail with reference to the drawings.

In the embodiment of the present invention, a solution for supporting the transaction mechanism in oneM2M is presented. Specifically, in order to apply transactions to oneM2M system, CSE (Common Service Entity) performs transaction management instead of AE (Application Entity).

A transaction consists of one or more tasks, each of which can have different tasks.

1. Transaction procedure

1 and 2 are flowcharts provided in explanation of a transaction service method according to an embodiment of the present invention.

In the transaction mechanism proposed in the embodiment of the present invention, the CSE provides a transaction management service as a platform for the AE.

The transaction management service verifies that it can perform transactions on target resources, processes transactions on targets when it can not perform all of the target transactions, confirms by explicit command or timer based transaction .

To this end, as shown in FIG. 1, an originator (AE) 10 first creates a <transactionMgmt> resource in the CSE 20. The <transactionMgmt> resource is a configuration for transaction management that has individual transaction tasks that target multiple resources.

Since the oneM2M transaction is a resource manipulation, the individual / child transaction represented by the <transaction> resource is the oneM2M request primitive.

When the <transactionMgmt> resource is created, the <transactionMgmt> resource hosting CSE 200 sends a <transaction> generation request to the target resources. If so, a <transaction> resource is created and a confirmation message is sent to the <transactionMgmt> resource hosting CSE 200.

Each transaction for a request primitive can be executed by a timer or an explicit instruction. As shown in FIG. 2, when the request transaction is successfully performed, the <transaction> resource hosting CSE 30-1, ..., 30-n transmits the result through the <Notify> request to the <transactionMgmt> resource hosting CSE 20 Or the <transactionMgmt> resource to the originating originator (AE) 10.

2. <transactionMgmt> Resources

The <transactionMgmt> resource represents one or more oneM2M primitive transaction (s) managed by the hosting CSE as target resources. The Originator creates a <transactionMgmt> resource with a request primitive associated with the target. Different transaction targets can be executed by sharing the same primitive.

When the <trasactionMgmt> resource is created, the <trasactionMgmt> resource hosting CSE creates the <transaction> resource as a child of the target resource. The target resource may be hosted by another CSE.

<transactionMgmt> Hosting the Resource The CSE processes its own <transaction> resources and performs transaction management (eg Init, Confirmed, Commit, Commited, Abort and Aborted) on behalf of Originator.

The <transactionMgmt> resource can contain information such as a creator, a transaction timer, a transaction status, an error handling method, a transaction managmenet method, primitives, targets) are included as attributes.

When the creator attribute is set, the hosting CSE notifies the creator of a notification request for an update of the transaction state attribute. The transaction timer (transactionTimer) attribute can be set from the Operation Execution Time parameter value, if provided. The transaction status attribute indicates the status of the associated transaction tasks. If the <transaction> resource creation fails, all transactions can be aborted according to the uncommitableTransactionHandling property. When all <transaction> resource creation completes successfully, the hosting CSE updates the transactionStatus of the <transaction> resource to "Confirmed". If the request primitive of all transaction tasks is successfully executed, the <transactionMgmt> resource can be automatically deleted according to the transactionMgmtHandling attribute. The requestPrimitives attribute contains a primitive message associated with the target resource. Also, the resultAggregation attribute is set to "Aggregate" and the hosting CSE contains the transactionInitiator attribute of the <transaction> resource creation message with the same value as the <transactionMgmt> resource's constructor.

The <transactionMgmt> resource may include the child resources tabulated in FIG. 3, and may include the attributes tabulated in FIG.

4, the <transactionMgmt> resource includes resourceType property, resourceID property, resourceName attribute, expirationTime attribute, parentID attribute, creationTime attribute, lastModifiedTime attribute, accessControlPolicyIDs attribute, labels attribute, creator attribute, transactionTimer attribute, transactionStatus attribute, an uncommitableTransactionHandling property, a transactionMgmtHandling property, a requestPrimitives property, and a resultAggregation property.

Here, the expirationTime value is selected by the Transaction Timeout parameter associated with the transaction request message. The creator is the initiator of the entire transaction in the <transactionMgmt> resource.

If the <transactionMgmt> creation request contains an Operation Execution Time parameter, its value is set to the transactionTimer attribute. Therefore, this value should be sent to the Operation Execution Time parameter parameter to implicitly generate the <Transaction> resource. If this value is not set, the transaction must be committed by updating the transacctionStatus property to "Commit".

The transactionStatus attribute contains the state of the associated transaction (for example, Init, Confirmed, Commit, Commited, Abort, and Aborted). With the exception of the hosting CSE, only the creator can update this attribute with the value "Commit" to commit the associated transaction.

The uncommitableTransactionHandling attribute indicates how to handle the <transaction> resource (eg Abort, Retry) when it can not commit all related transactions. If not set, the default action is "Abort". When the hosting CSE interrupts the <transactionMgmt> resource, it notifies the constructor.

The transactionMgmtHandling attribute indicates how to handle the <transactionManagement> resource (eg Delete, Remain) after a successful commit of all transactions. If not set, the default action is "Delete".

The requestPrimitives attribute contains the request primitive message and the associated target resource. The resultAggregation attribute indicates whether the <transactionMgmt> resource hosting CSE aggregates the results of individual transaction execution results. If not set, the default action is "aggregate".

3. <transaction> Resources

A <transaction> resource is a sub-resource of all resources that are transaction targets, excluding virtual resources. The <transaction> creation request is generated only by the CSE hosting the associated <transactionMgmt> resource. AE can not initiate this request.

When the CSE receives a <transaction> resource creation request targeted at a transaction target resource, the CSE verifies that the request can be successfully executed or is currently executable. If so, the CSE creates a <transaction> resource with the children of the target resource. Otherwise, the CSE does not create a <transaction> resource.

The request primitive of a <transaction> resource has a transactionTimer attribute or is executed by an explicit commit command. This transaction task is only performed when the transactionStatus attribute is "Confirmed". The commit command is a <transaction> update request that modifies the transactionStatus attribute to the value "Commit". If the transaction is successful, the TransactionStatus attribute is updated to "Commited" by the hosting CSE.

The <transaction> delete request suspends the transaction to the parent / target resource. If commit is timer-based, deleting a <transaction> resource by another primitive (eg, parent parent resource deletion) will abort the transaction.

When a transaction is performed, the execution result of requestPrimitive is passed to the <transactionMgmt> resource hosting CSE as a Notify request, unless the <transaction> resource has a transactionInitiator attribute. When the transactionInitiator attribute is set, a Notify request is sent to the transactionInitiator.

The < transaction > resource may include the child resources tabulated in FIG. 5 and may include the attributes tabulated in FIG.

6, the < transaction > resource includes resourceType property, resourceID property, resourceName property, expirationTime attribute, parentID attribute, creationTime attribute, lastModifiedTime attribute, accessControlPolicyIDs attribute, labels attribute, creator attribute, transactionID attribute, transactionStatus attribute, requestPrimitive attribute, and transactionInitiator attribute.

Here, the expirationTime value is selected by the Transaction Timeout parameter associated with the transaction request message. And creator represents the creator of the <transaction> resource. Also, transactionID represents the resource ID of the associated <transactionMgmt> resource.

The transactionStatus attribute indicates the status of the transaction (for example, Init, Confirmed, Commit, Commited). When this resource is created, this value is set to "Init". Except hosting CSE. Only the creator can commit this transaction by updating this attribute with the value "Commit".

The requestPrimitive attribute contains the request primitive to be executed on the parent resource.

The transactionInitiator attribute contains the entity ID that generated the associated <transactionMgmt> resource. If not set, the result of the executed request is sent to the <management Mgmt> resource hosting CSE as a notification request. Otherwise, a notification is sent to the transactionInitiator.

4. M2M system

7 is a diagram illustrating an M2M system to which the present invention is applicable. The M2M system to which the present invention can be applied includes a server 100-1, gateways 100-21 and 100-22, devices 100-31, 100-32, 100-33, 100 -34) are connected and constructed so that they can communicate with each other.

The number of electronic devices shown in Fig. 7, such as the server 100-1, the gateways 100-21 and 100-22, and the devices 100-31, 100-32, 100-33, 100-34) are illustrative, the technical idea of the present invention can be applied to the case of implementing them differently.

Furthermore, it is needless to say that the connection structure of the electronic devices shown in Fig. 7 can also be replaced in other ways as needed.

All the electronic devices shown in FIG. 7 can perform the function of the <transactionMgmt> resource hosting CSE of the oneM2M platform. In other words, both the server 100-1, the gateways 100-21 and 100-22, and the devices 100-31, 100-32, 100-33, and 100-34, as the <transactionMgmt> resource hosting CSE, Transaction management.

8 is an internal block diagram of the electronic devices shown in Fig. The configurations necessary for implementing the embodiment of the present invention include all of the servers 100-1, the gateways 100-21 and 100-22, the devices 100-31, 100-32, 100-33, and 100-34 Common. Therefore, they are collectively referred to as "100" in Fig. 6, and are collectively referred to as electronic devices hereinafter.

8, electronic devices according to another embodiment of the present invention include a communication unit 110, a processor 120, a storage unit 130, and a function block 140. [

The communication unit 110 is communication interface means for communicating with an external device and accessing an external network.

Processor 120 includes at least one AE (Application Entr) and a CSE (Common Service Entity). Depending on the type and function of the electronic device, AE may not be included.

The processor 120 performs transaction management as described above, and the storage unit 130 provides storage space necessary for the processor 120 to perform transaction management.

The function block 140 performs the function of the electronic device itself. For example, if the electronic device is the server 100-1, the virtual machines that provide the service correspond to the function block 140. [

5. Modifications

Up to now, a preferred embodiment of the transaction management method in the oneM2M platform has been described in detail.

In the above embodiment, the method of setting the transaction timer uses the Operation Execution Time parameter. Instead of using a parameter, the originator may present the attribute value provided in the request. In this case, the transactionTimer of the <transactionMgmt> resource must be "RW".

It should be noted that the names of the resources shown in the above embodiments are all exemplary and can be changed.

Further, it is assumed that the < transaction > resource is generated as a child of the target resource, but is merely an example. It is also possible to create a <transaction> resource that is not a child of the target resource, but another resource linked to it.

It goes without saying that the technical idea of the present invention can also be applied to a computer-readable recording medium having a computer program for performing the functions of the apparatus and method according to the present embodiment. In addition, the technical idea according to various embodiments of the present invention may be embodied in computer-readable code form recorded on a computer-readable recording medium. The computer-readable recording medium is any data storage device that can be read by a computer and can store data. For example, the computer-readable recording medium may be a ROM, a RAM, a CD-ROM, a magnetic tape, a floppy disk, an optical disk, a hard disk drive, or the like. In addition, the computer readable code or program stored in the computer readable recording medium may be transmitted through a network connected between the computers.

While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it is to be understood that the invention is not limited to the disclosed exemplary embodiments, but, on the contrary, It will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the present invention.

Application Entity (AE)
Common Sservice Entity (CSE)
<transactionMgmt> Resources
<transactiont> Resources

Claims (8)

The first CSE (Common Service Entity) generating a first resource for transaction management at the request of the Originator;
The second CSEs creating second resources for the transaction tasks at the request of the first CSE;
And the first CSE managing the second resources using the first resource.
The method according to claim 1,
The first resource comprises:
And a transaction state attribute indicating the state of the transaction tasks.
The method of claim 2,
The first resource comprises:
And a constructor property to notify of notification of an update of the transaction state attribute.
The method of claim 3,
Only the constructor and the first CSE,
Wherein transaction state attributes can be updated to Commit.
The method according to claim 1,
And a transaction timer attribute for executing transaction tasks.
The method according to claim 1,
The first resource comprises:
An attribute indicating a method of processing transaction tasks when the transaction tasks can not be all committed; and an attribute indicating a method of processing a first resource after both transaction tasks have been committed.
The method according to claim 1,
The second resource,
The attribute indicating the status of the transaction task.
A first CSE (Common Service Entity) for generating a first resource for transaction management at the request of the originator; And
Second CSEs for generating second resources for transactional tasks at the request of the first CSE,
In the first CSE,
And managing the second resources using the first resource.

Images