CN107113311B

CN107113311B - Method and apparatus for communication in a unified machine-to-machine system

Info

Publication number: CN107113311B
Application number: CN201580072631.7A
Authority: CN
Inventors: 陶源; 于琦; 甄斌
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2015-01-08
Filing date: 2015-01-08
Publication date: 2020-12-08
Anticipated expiration: 2035-01-08
Also published as: WO2016109967A1; CN107113311A

Abstract

The embodiment of the invention provides a method and a device for communication in a oneM2M system. The method comprises the steps of receiving a first Request message in a non-blocking synchronous communication mode sent by a last entity, wherein the first Request message comprises a Request Resource Creator parameter. The Request Resource Creator parameter is either a default value or an identifier of the last entity that created a < Request > Resource for the first Request message. When < request > resources are not created for the first request message, sending the first request message to a next entity. After receiving the request message, the embodiment of the invention is used for indicating the entity which does not create the resource with the < request > to forward the request message to the next entity by adding new parameters so as to continue communication when the creation of the resource with the < request > fails.

Description

Method and apparatus for communication in a unified machine-to-machine system

Technical Field

The embodiment of the invention relates to the field of communication, in particular to a method and a device for communication in a unified machine-to-machine system.

Background

With the development of the internet of things technology, a globalized standard organization unifies Machine-to-Machine (oneM 2M for short), which aims to efficiently deploy a Machine-to-Machine (M2M) communication system and promote the integration of the M2M global standard and industry application. The existing oneM2M system adopts a layered architecture, and the whole architecture is divided into an Application Layer (English), a Common Service Layer (English) and an underlying Network Service Layer (English). An Application Entity (AE) in the Application layer contains an instantiated end-to-end oneM2M solution. A Common Service Entity (CSE) in the Common Service layer includes instantiated Common Service functions, and the CSE is a core layer in oneM2M, and manages and is responsible for aggregating application layer information to form a resource pool and simultaneously coordinate underlying network transmission, thereby playing a role of a platform. And the management of an underlying Network Entity (NSE) in the underlying Network Service layer is responsible for the underlying Network transmission and provides underlying Network support for the common Service layer.

There are 3 reference points (i.e., interfaces) between layers in the oneM2M system. Wherein Mca: the interface between the AE and the CSE is responsible for AE-to-CSE or CSE-to-AE communications, enables the AE to use services provided by the CSE, and enables the CSE to communicate with the AE in reverse. Mcc/Mcc': the interface between the two CSEs is responsible for the communication between the CSEs, enabling one CSE to use the functionality provided by the other CSE. Mcn: the interface between the CSE and the NSE is responsible for the CSE-to-NSE or NSE-to-CSE communication, enabling the CSE to use the services provided by the bearer network to the upper layers.

The existing oneM2M standard adopts representation layer State Transfer (REST) to obtain a framework. Information and data information of AE and CSE in oneM2M system can be represented by resources. Meanwhile, behavior in oneM2M system may be implemented using the following five operations: create (english: Create), acquire (english: Retrieve), Update (english: Update), Delete (english: Delete), and Notify (english: Notify). Where Create is used for CSE or AE to Create a resource on other CSE. Retrieve is used to Retrieve attributes of resources stored on the CSE. Update is used to Update information stored in the attributes of the target resource. Delete is used to Delete resources on the CSE. Notify is used to Notify information.

The existing oneM2M standard defines 3 communication modes of Blocking (English), Non-Blocking Synchronous (English) and Non-Blocking Asynchronous (English). In the non-blocking synchronous communication mode, when the target resource is stored in the Hosting general service entity (English), the initiating entity (English) may send a request message to the Hosting CSE requesting to operate on the target resource. The request message sent by the Originator can reach the Hosting CSE through the forwarding of a transit CSE. The transit CSE, upon receiving the request message, needs to create a request < request > resource to complete the continued communication process.

There may be multiple hops between Originator and Hosting CSE, that is, the request message sent by Originator reaches Hosting CSE through forwarding of multiple Transit CSE. For multiple transit CSEs, each transit CSE needs to create a request < request > resource in order to complete the continued communication process. However, for some transit CSEs, the < request > resource cannot be created, e.g., the transit CSE does not support the < request > resource type or the transit CSE has limited capacity. For example, some transit CSEs may create a < request > resource, but not create a < request > resource, depending on the circumstances. In these cases, when the previous N (N is a positive integer greater than 1) transit CSEs have successfully created the < request > resource, and the N +1 th transit or Hosting CSE cannot create the < request > resource, a message that the creation of the < request > resource failed is replied. Thus, if a certain entity < request > resource fails to be created, the communication process of the Originator requesting to operate on the target resource cannot be continued.

Disclosure of Invention

Embodiments of the present invention provide a method and an apparatus for unifying communications in a machine-to-machine system, so that communications can be continued even when a < request > resource is failed to be created.

In a first aspect, a method for unifying communication in a machine-to-machine M2M system is provided, including: receiving a first Request message in a non-blocking synchronous communication mode sent by a previous entity, wherein the first Request message comprises a Request Resource Creator parameter, the Request Resource Creator parameter is a default value or an identifier of an entity which creates a Request < Request > Resource aiming at the first Request message, and the first Request message is used for an initiating entity originor to Request a Hosting general service entity Hosting CSE where a target Resource is located to operate the target Resource; transmitting the first request message to a next entity when a < request > resource is not created for the first request message.

With reference to the first aspect, in an implementation manner of the first aspect, a first reply message sent by the next entity is received, where the first reply message includes address information of a < request > resource created by a next entity that creates the < request > resource for the first request message; and sending the first reply message to the last entity.

With reference to the first aspect and the foregoing implementation manner, in another implementation manner of the first aspect, a first obtaining request message sent by the previous entity is received, where the first obtaining request message includes address information of a < request > resource created by the entity that creates the < request > resource for the next request message, and the first obtaining request message is used to request the entity that creates the < request > resource for the next time to obtain the processing result of the target resource; and sending the first acquisition request message to the next entity.

With reference to the first aspect and the foregoing implementation manner of the first aspect, in another implementation manner of the first aspect, a second reply message sent by the next entity is received, where the second reply message includes the processing result of the target resource; sending the second reply message to the last entity.

With reference to the first aspect and the foregoing implementation manner of the first aspect, in another implementation manner of the first aspect, before the sending the first request message to the next entity, the method further includes: determining whether to create a < request > resource for the first request message.

With reference to the first aspect and the foregoing implementation manner of the first aspect, in another implementation manner of the first aspect, the determining whether to create a < request > resource for the first request message includes: determining whether to create a < request > resource for the first request message based on capacity and/or supported < request > resource types.

With reference to the first aspect and the foregoing implementation manner of the first aspect, in another implementation manner of the first aspect, the method is performed by a transit CSE, and the method further includes: creating a < request > resource when it is determined that the < request > resource is created for the first request message; sending a third reply message to the last entity, the third reply message including address information of the created < request > resource; generating a second Request message, wherein the second Request message comprises the Request Resource Creator parameter, and the Request Resource Creator parameter is set as an identifier of the transit CSE; sending the second request message to the next entity.

With reference to the first aspect and the foregoing implementation manner of the first aspect, in another implementation manner of the first aspect, a fourth reply message sent by the next entity is received, where the fourth reply message includes the processing result of the target resource; updating the < request > resource created by the transit CSE according to the fourth reply message; receiving a second acquisition request message sent by the previous entity, where the second acquisition request message includes address information of a created < request > resource, and the second acquisition request message is used for the previous entity to request the transit CSE to acquire the processing result of the target resource; and sending a fifth reply message to the last entity, wherein the fifth reply message comprises the processing result of the target resource.

In a second aspect, a method for unifying communication in a machine-to-machine oneM2M system is provided, the method comprising: receiving a first request message in a non-blocking synchronous communication mode sent by a last entity, wherein the first request message is used for initiating an entity originor to request a Hosting general service entity Hosting CSE where a target resource is located to operate the target resource; generating a Request Resource Creator parameter set to a default value or an identifier of an entity that created a Request < Request > Resource for the first Request message, when the Request < Request > Resource is not created for the first Request message; generating a second Request message, wherein the second Request message comprises the Request Resource Creator parameter; sending the generate second request message to a next entity.

With reference to the second aspect, in an implementation manner of the second aspect, a first reply message sent by the next entity is received, where the first reply message includes address information of a < request > resource created by a next entity that creates the < request > resource for the first request message; and sending the first reply message to the last entity.

With reference to the second aspect and the foregoing implementation manner, in another implementation manner of the second aspect, a first obtaining request message sent by the previous entity is received, where the first obtaining request message includes address information of a < request > resource created by the entity that creates the < request > resource for the first request message next, and the first obtaining request message is used to request the entity that creates the < request > resource next to obtain the processing result of the target resource; and sending the first acquisition request message to the next entity.

With reference to the second aspect and the foregoing implementation manner of the second aspect, in another implementation manner of the second aspect, a second reply message sent by the next entity is received, where the second reply message includes the processing result of the target resource; sending the second reply message to the last entity.

With reference to the second aspect and the foregoing implementation manner of the second aspect, in another implementation manner of the second aspect, the determining whether to create a < request > resource for the first request message includes: determining whether to create a < request > resource for the first request message based on capacity and/or supported < request > resource types.

With reference to the second aspect and the foregoing implementation manner of the second aspect, in another implementation manner of the second aspect, the method is performed by a transit CSE, and the method further includes: creating a < request > resource when it is determined that the < request > resource is created for the first request message; sending a third reply message to the last entity, the third reply message including address information of the created < request > resource; generating a third Request message, wherein the third Request message comprises the Request Resource Creator parameter, and the Request Resource Creator parameter is set as an identifier of the transit CSE; sending the third request message to the next entity.

With reference to the second aspect and the foregoing implementation manner of the second aspect, in another implementation manner of the second aspect, a fourth reply message sent by the next entity is received, where the fourth reply message includes the processing result of the target resource; updating the < request > resource created by the transit CSE according to the fourth reply message; receiving a second acquisition request message sent by the previous entity, where the second acquisition request message includes address information of a created < request > resource, and the second acquisition request message is used for the previous entity to request the transit CSE to acquire the processing result of the target resource; and sending a fifth reply message to the last entity, wherein the fifth reply message comprises the processing result of the target resource.

In a third aspect, a method for unifying communication in a machine-to-machine oneM2M system is provided, and the method includes: receiving a first request message in a non-blocking synchronous communication mode sent by a previous entity, wherein a response type RT parameter carried by the first request message comprises a request resource indication field, the first request message is used for initiating an entity originor to request a Hosting CSE (generic service entity) where a target resource is located to operate the target resource, and the request resource indication field is a default value or an identifier of an entity which is used for creating a request < request > resource aiming at the first request message. Transmitting the first request message to a next entity when a request < request > resource is not created for the first request message.

With reference to the third aspect, in an implementation manner of the third aspect, a first reply message sent by the next entity is received, where the first reply message includes address information of a < request > resource created by a next entity that creates the < request > resource for the first request message; and sending the first reply message to the last entity.

With reference to the third aspect and the foregoing implementation manner of the third aspect, in another implementation manner of the third aspect, a first obtaining request message sent by the previous entity is received, where the first obtaining request message includes address information of a < request > resource created by the entity that creates the < request > resource next to the first obtaining request message, and the first obtaining request message is used to request the entity that creates the < request > resource next to the entity that creates the < request > resource to obtain the processing result of the target resource; and sending the first acquisition request message to the next entity.

With reference to the third aspect and the foregoing implementation manner of the third aspect, in another implementation manner of the third aspect, a second reply message sent by the next entity is received, where the second reply message includes the processing result of the target resource; sending the second reply message to the last entity.

With reference to the third aspect and the foregoing implementation manner of the third aspect, in another implementation manner of the third aspect, before the sending the first request message to the next entity, the method further includes: determining whether to create a < request > resource for the first request message.

With reference to the third aspect and the foregoing implementation manner of the third aspect, in another implementation manner of the third aspect, the determining whether to create a < request > resource for the first request message includes: determining whether to create a < request > resource for the first request message based on capacity and/or supported < request > resource types.

With reference to the third aspect and the foregoing implementation manner of the third aspect, in another implementation manner of the third aspect, the method is performed by a transit CSE, and the method further includes: creating a < request > resource when it is determined that the < request > resource is created for the first request message; sending a third reply message to the last entity, the third reply message including address information of the created < request > resource; generating a second request message, wherein the second request message comprises the request resource indication field, and the request resource indication field is set as an identifier of the transit CSE; sending the second request message to the next entity.

With reference to the third aspect and the foregoing implementation manner of the third aspect, in another implementation manner of the third aspect, a fourth reply message sent by the next entity is received, where the fourth reply message includes the processing result of the target resource; updating the < request > resource created by the transit CSE according to the fourth reply message; receiving a second acquisition request message sent by the previous entity, where the second acquisition request message includes address information of a created < request > resource, and the second acquisition request message is used for the previous entity to request the transit CSE to acquire the processing result of the target resource; and sending a fifth reply message to the last entity, wherein the fifth reply message comprises the processing result of the target resource.

In a fourth aspect, there is provided a method of unifying communications in a machine-to-machine M2M system, comprising: receiving a request message in a non-blocking synchronous communication mode sent by a last entity, wherein the request message is used for initiating an entity originor to request a Hosting general service entity Hosting CSE where a target resource is located to operate the target resource; when the < Request > resource is Not created for the first Request message, sending an indication message to the previous entity, wherein the indication message comprises a Request resource Not creation Request Not Create parameter, the Request Not Create parameter comprises an identifier of a next entity, and the indication message is used for indicating the previous entity to send the first Request message to the next entity.

With reference to the fourth aspect and the foregoing implementation manner of the fourth aspect, in another implementation manner of the fourth aspect, the method further includes: it is determined whether to create a < request > resource for the request message.

With reference to the fourth aspect and the foregoing implementation manner of the fourth aspect, in another implementation manner of the fourth aspect, the determining whether to create a < request > resource for the request message includes: determining whether to create a < request > resource for the request message based on the capacity and/or supported < request > resource types.

In a fifth aspect, a method for unifying communications in a machine-to-machine M2M system is provided, which is to send a request message in a non-blocking synchronous communication mode to a next entity, where the request message is used for an initiating entity Originator to request a Hosting generic service entity (generic service entity) CSE where a target resource is located to operate on the target resource; receiving an indication message sent by the next entity, wherein the indication message comprises that a Request resource does Not Create a Request Not Create parameter, the Request Not Create parameter comprises an identifier of a first entity, and the indication message is used for indicating a local entity to send the Request message to the first entity; sending the request message to the first entity.

In a sixth aspect, a method of unifying communication in a machine-to-machine oneM2M system is provided, comprising: receiving a request message in a non-blocking synchronous communication mode sent by a transit Common Service Entity (CSE), wherein the request message is used for initiating an entity Originator to request to operate a target resource; and when a request < request > resource is not created for the request message, sending indication information to the transit CSE according to the request message, wherein the indication information is used for indicating the transit CSE to resend the request message after the first time.

With reference to the sixth aspect, in an implementation manner of the sixth aspect, the determining unit is specifically configured to: determining whether to create the < request > resource for the target resource according to whether the < request > resource type is supported and/or whether the capacity exceeds a first threshold.

With reference to the sixth aspect and the foregoing implementation manner of the sixth aspect, in another implementation manner of the sixth aspect, the target resource is processed according to the request message, so as to obtain the processing result of the target resource.

With reference to the sixth aspect and the foregoing implementation manner of the fourth aspect, in another implementation manner of the fourth aspect, the method further includes: receiving the request message retransmitted by the transit CSE; and sending a reply message to the transit CSE, wherein the reply message comprises the processing result of the target resource.

With reference to the sixth aspect and the foregoing implementation manner of the sixth aspect, in another implementation manner of the sixth aspect, the first duration is longer than a duration required for processing the target resource.

With reference to the sixth aspect and the foregoing implementation manner of the sixth aspect, in another implementation manner of the sixth aspect, the method further includes: resending the indication message to the transit CSE when processing of the target resource is not completed after a first time period; or after a second time length, the request message sent by the transit CSE is not received, and the processing result of the target resource is discarded; and after the third time length, receiving a request message sent again by the transit CSE.

In a seventh aspect, a method of unifying communication in a machine-to-machine oneM2M system is provided, comprising: sending a request message in a non-blocking synchronous communication mode to a Hosting CSE, wherein the request message is used for an initiating entity Originator to request the Hosting CSE to access a target resource; and receiving indication information sent by the Hosting CSE according to the request message, wherein the indication information is used for indicating that the request message is sent again after the first time period.

With reference to the seventh aspect, in an implementation manner of the seventh aspect, the method further includes: resending the request message to the Hosting CSE; and receiving a reply message sent by the Hosting CSE, wherein the reply message comprises the processing result of the target resource.

With reference to the seventh aspect and the foregoing implementation manner, in another implementation manner of the seventh aspect, the first duration is longer than a duration required for processing the target resource.

With reference to the seventh aspect and the foregoing implementation manner, in another implementation manner of the seventh aspect, the method further includes: after a first time period, receiving an indication message sent again by the Hosting CSE; or after a third duration, sending the request message to the Hosting CSE again.

In an eighth aspect, there is provided an apparatus for unifying communications in a machine to machine oneM2M system, where the first receiving unit is configured to receive a first Request message in a non-blocking synchronous communication mode sent by a previous entity, the first Request message includes a Request Resource Creator parameter, the Request Resource Creator parameter is a default value or an identifier of an entity that has created a Request < Request > Resource for the first Request message, and the first Request message is used to initiate the entity Originator to Request a Hosting CSE, where a Hosting universal service entity of a target Resource, to operate the target Resource; the first transmitting unit is configured to transmit the first request message to a next entity when a < request > resource is not created for the first request message received by the first receiving unit.

With reference to the eighth aspect, in an implementation manner of the eighth aspect, the apparatus further includes: a second receiving unit, configured to receive a first reply message sent by the next entity, where the first reply message includes address information of a < request > resource created by a next entity that creates the < request > resource for the first request message; and a second sending unit, configured to send the first reply message to the previous entity.

With reference to the eighth aspect and the foregoing implementation manner, in another implementation manner of the eighth aspect, the apparatus further includes: a third receiving unit, configured to receive a first obtaining request message sent by the previous entity, where the first obtaining request message includes address information of a < request > resource created by the entity that creates the < request > resource next to the first obtaining request message, and the first obtaining request message is used to request the entity that creates the < request > resource next to the entity that creates the < request > resource to obtain the processing result of the target resource; a third sending unit, configured to send the first get request message to the next entity.

With reference to the eighth aspect and the foregoing implementation manner, in another implementation manner of the eighth aspect, the apparatus further includes: a fourth receiving unit, configured to receive a second reply message sent by the next entity, where the second reply message includes the processing result of the target resource; a fourth sending unit, configured to send the second reply message to the previous entity.

With reference to the eighth aspect and the foregoing implementation manner, in another implementation manner of the eighth aspect, the apparatus further includes: a determining unit for determining whether to create a < request > resource for the first request message.

With reference to the eighth aspect and the foregoing implementation manner, in another implementation manner of the eighth aspect, the determination unit is specifically configured to: determining whether to create a < request > resource for the first request message based on capacity and/or supported < request > resource types.

With reference to the eighth aspect and the foregoing implementation manner, in another implementation manner of the eighth aspect, the apparatus is a transit CSE, and the apparatus further includes: a creating unit configured to create a < request > resource when it is determined that the < request > resource is created for the first request message; a fifth sending unit, configured to send a third reply message to the previous entity, where the third reply message includes address information of the created < request > resource; a generating unit, configured to generate a second Request message, where the second Request message includes the Request Resource Creator parameter, and the Request Resource Creator parameter is set as an identifier of the transit CSE; a sixth sending unit, configured to send the second request message to the next entity.

With reference to the eighth aspect and the foregoing implementation manner, in another implementation manner of the eighth aspect, the apparatus further includes: a fifth receiving unit, configured to receive a fourth reply message sent by the next entity, where the fourth reply message includes the processing result of the target resource; an updating unit, configured to update the < request > resource created by the transit CSE according to the fourth reply message; a sixth receiving unit, configured to receive a second obtaining request message sent by the previous entity, where the second obtaining request message includes address information of a created < request > resource, and the second obtaining request message is used for the previous entity to request the transit CSE to obtain the processing result of the target resource; a seventh sending unit, configured to send a fifth reply message to the previous entity, where the fifth reply message includes the processing result of the target resource.

In a ninth aspect, an apparatus for unifying communications in a machine-to-machine oneM2M system is provided, in which a first receiving unit is configured to receive a first request message in a non-blocking synchronous communication mode sent by a previous entity, where the first request message is used to initiate an entity Originator to request a Hosting generic service entity Hosting CSE where a target resource is located to operate the target resource; a first generating unit, configured to generate a Request Resource Creator parameter when a Request < Request > Resource is not created for the first Request message, where the Request Resource Creator parameter is set to a default value or an identifier of an entity that created the Request < Request > Resource for the first Request message; a second generating unit, configured to generate a second Request message, where the second Request message includes the Request Resource Creator parameter; a first sending unit, configured to send the second request message to a next entity.

With reference to the ninth aspect, in an implementation manner of the ninth aspect, the apparatus further includes: a second receiving unit, configured to receive a first reply message sent by the next entity, where the first reply message includes address information of a < request > resource created by a next entity that creates the < request > resource for the first request message; and a second sending unit, configured to send the first reply message to the previous entity.

With reference to the ninth aspect and the foregoing implementation manner, in another implementation manner of the ninth aspect, the apparatus further includes: a third receiving unit, configured to receive a first obtaining request message sent by the previous entity, where the first obtaining request message includes address information of a < request > resource created by the entity that creates the < request > resource next to the first obtaining request message, and the first obtaining request message is used to request the entity that creates the < request > resource next to the entity that creates the < request > resource to obtain the processing result of the target resource; a third sending unit, configured to send the first get request message to the next entity.

With reference to the ninth aspect and the foregoing implementation manner, in another implementation manner of the ninth aspect, the apparatus further includes: a fourth receiving unit, configured to receive a second reply message sent by the next entity, where the second reply message includes the processing result of the target resource; a fourth sending unit, configured to send the second reply message to the previous entity.

With reference to the ninth aspect and the foregoing implementation manner, in another implementation manner of the ninth aspect, the apparatus further includes: a determining unit for determining whether to create a < request > resource for the first request message.

With reference to the ninth aspect and the foregoing implementation manner, in another implementation manner of the ninth aspect, the determination unit is specifically configured to: determining whether to create a < request > resource for the first request message based on capacity and/or supported < request > resource types.

With reference to the ninth aspect and the foregoing implementation manner, in another implementation manner of the ninth aspect, the apparatus is a transit CSE, and the apparatus further includes: a creating unit configured to create a < request > resource when it is determined that the < request > resource is created for the first request message; a fifth sending unit, configured to send a third reply message to the previous entity, where the third reply message includes address information of the created < request > resource; a third generating unit, configured to generate a third Request message, where the third Request message includes the Request Resource Creator parameter, and the Request Resource Creator parameter is set as an identifier of the transit CSE; a sixth sending unit, configured to send the third request message to the next entity.

With reference to the ninth aspect and the foregoing implementation manner, in another implementation manner of the ninth aspect, the apparatus further includes: a fifth receiving unit, configured to receive a fourth reply message sent by the next entity, where the fourth reply message includes the processing result of the target resource; an updating unit, configured to update the < request > resource created by the transit CSE according to the fourth reply message; a sixth receiving unit, configured to receive a second obtaining request message sent by the previous entity, where the second obtaining request message includes address information of a created < request > resource, and the second obtaining request message is used for the previous entity to request the transit CSE to obtain the processing result of the target resource; a seventh sending unit, configured to send a fifth reply message to the previous entity, where the fifth reply message includes the processing result of the target resource.

In a tenth aspect, there is provided an apparatus for unifying communications in a machine to machine oneM2M system, where the first receiving unit is configured to receive a first request message in a non-blocking synchronous communication mode sent by a previous entity, a response type RT parameter carried in the first request message includes a request resource indication field, the first request message is used to initiate an entity Originator to request a Hosting generic service entity (sgsn) Hosting CSE where a target resource is located to perform an operation on the target resource, and the request resource indication field is a default value or an identifier of a previous entity that creates a request < request > resource for the first request message; the first transmitting unit is configured to transmit the first request message to a next entity when a < request > resource is not created for the first request message received by the first receiving unit.

With reference to the tenth aspect, in an implementation manner of the tenth aspect, the apparatus further includes: a second receiving unit, configured to receive a first reply message sent by the next entity, where the first reply message includes address information of a < request > resource created by a next entity that creates the < request > resource for the first request message; and a second sending unit, configured to send the first reply message to the previous entity.

With reference to the tenth aspect and the foregoing implementation manner, in another implementation manner of the tenth aspect, the apparatus further includes: a third receiving unit, configured to receive a first obtaining request message sent by the previous entity, where the first obtaining request message includes address information of a < request > resource created by the entity that creates the < request > resource next to the first obtaining request message, and the first obtaining request message is used to request the entity that creates the < request > resource next to the entity that creates the < request > resource to obtain the processing result of the target resource; a third sending unit, configured to send the first get request message to the next entity.

With reference to the tenth aspect and the foregoing implementation manner, in another implementation manner of the tenth aspect, the apparatus further includes: a fourth receiving unit, configured to receive a second reply message sent by the next entity, where the second reply message includes the processing result of the target resource; a fourth sending unit, configured to send the second reply message to the previous entity.

With reference to the tenth aspect and the foregoing implementation manner, in another implementation manner of the tenth aspect, the apparatus further includes: a determining unit for determining whether to create a < request > resource for the first request message.

With reference to the tenth aspect and the foregoing implementation manner, in another implementation manner of the tenth aspect, the determination unit is specifically configured to: determining whether to create a < request > resource for the first request message based on capacity and/or supported < request > resource types.

With reference to the tenth aspect and the foregoing implementation manner, in another implementation manner of the tenth aspect, the apparatus is a transit CSE, and the apparatus further includes: a creating unit configured to create a < request > resource when it is determined that the < request > resource is created for the first request message; a fifth sending unit, configured to send a third reply message to the previous entity, where the third reply message includes address information of the created < request > resource; a generating unit, configured to generate a second request message, where the second request message includes the request resource indication field, and the request resource indication field is set as an identifier of the transit CSE; a sixth sending unit, configured to send the second request message to the next entity.

With reference to the tenth aspect and the foregoing implementation manner, in another implementation manner of the tenth aspect, the apparatus further includes: a fifth receiving unit, configured to receive a fourth reply message sent by the next entity, where the fourth reply message includes the processing result of the target resource; an updating unit, configured to update the < request > resource created by the transit CSE according to the fourth reply message; a sixth receiving unit, configured to receive a second obtaining request message sent by the previous entity, where the second obtaining request message includes address information of a created < request > resource, and the second obtaining request message is used for the previous entity to request the transit CSE to obtain the processing result of the target resource; a seventh sending unit, configured to send a fifth reply message to the previous entity, where the fifth reply message includes the processing result of the target resource.

In an eleventh aspect, there is provided an apparatus for unifying communication in a machine-to-machine oneM2M system, comprising: a receiving unit, configured to receive a request message in a non-blocking synchronous communication mode sent by a previous entity, where the first request message is used to initiate an entity Originator to request a Hosting generic service entity Hosting CSE where a target resource is located to operate the target resource; a sending unit, configured to send, when the Request message does Not Create a < Request > resource for the first receiving unit, an indication message to the previous entity, where the indication message includes a Request Not Create parameter, the Request Not Create parameter includes an identifier of a next entity, and the indication message is used to indicate that the previous entity sends the Request message to the next entity.

With reference to the eleventh aspect, in an implementation manner of the eleventh aspect, the apparatus further includes: a determination unit for determining whether to create a < request > resource for the request message.

With reference to the eleventh aspect and the foregoing implementation manner, in another implementation manner of the eleventh aspect, the determining unit is specifically configured to: determining whether to create a < request > resource for the request message based on the capacity and/or supported < request > resource types.

In a twelfth aspect, there is provided an apparatus for unifying communication in a machine-to-machine oneM2M system, comprising: a first sending unit, configured to send a request message in a non-blocking synchronous communication mode to a next entity, where the request message is used to initiate an entity Originator to request a Hosting generic service entity Hosting CSE where a target resource is located to operate the target resource; a receiving unit, configured to receive an indication message sent by the next entity, where the indication message includes that a Request resource does Not Create a Request Not Create parameter, the Request Not Create parameter includes an identifier of a first entity, and the indication message is used to indicate that a local entity sends the Request message to the first entity; a second sending unit, configured to send the request message to the first entity.

In a thirteenth aspect, there is provided an apparatus for unifying communication in a machine-to-machine oneM2M system, comprising: a first receiving unit, configured to receive a request message in a non-blocking synchronous communication mode sent by a transit generic service entity CSE, where the request message is used to initiate an entity Originator to request to operate a target resource; a first sending unit, configured to send, according to the request message, indication information to the transit CSE when a request < request > resource is not created for the request message received by the receiving unit, where the indication information is used to indicate the transit CSE to resend the request message after a first time period.

With reference to the thirteenth aspect, in an implementation manner of the thirteenth aspect, the apparatus further includes: and the processing unit is used for processing the target resource according to the request message to obtain the processing result of the target resource.

With reference to the thirteenth aspect and the foregoing implementation manner, in another implementation manner of the thirteenth aspect, the apparatus further includes: a second receiving unit, configured to receive the request message retransmitted by the transit CSE; a second sending unit, configured to send a reply message to the transit CSE, where the reply message includes the processing result of the target resource.

With reference to the thirteenth aspect and the foregoing implementation manner, in another implementation manner of the thirteenth aspect, the first duration is longer than a duration required for processing the target resource.

With reference to the thirteenth aspect and the foregoing implementation manner, in another implementation manner of the thirteenth aspect, the apparatus further includes: a third sending unit, configured to, when the request message sent by the transit CSE is not received after the first time period or the target resource is not processed, resend the indication message to the transit CSE.

In a fourteenth aspect, there is provided an apparatus for unifying communication in a machine-to-machine oneM2M system, comprising: a first sending unit, configured to send a request message in a non-blocking synchronous communication mode to a Hosting CSE, where the request message is used for an initiating entity Originator to request the Hosting CSE to access a target resource; a first receiving unit, configured to receive indication information sent by the Hosting CSE according to the request message, where the indication message is used to indicate that the request message is to be sent again after a first time period.

With reference to the fourteenth aspect, in an implementation manner of the fourteenth aspect, the apparatus further includes: the device further comprises: a second sending unit, configured to resend the request message to the Hosting CSE; a second receiving unit, configured to receive a reply message sent by the Hosting CSE, where the reply message includes a processing result of the target resource.

With reference to the fourteenth aspect and the foregoing implementation manner, in another implementation manner of the fourteenth aspect, the first duration is longer than a duration required for processing the target resource.

With reference to the fourteenth aspect and the foregoing implementation manner, in another implementation manner of the fourteenth aspect, the apparatus further includes: a third receiving unit, configured to receive, after the first duration, an indication message that the Hosting CSE retransmits.

When the oneM2M system of the embodiment of the present invention uses the non-blocking synchronous communication mode to perform communication, after receiving a Request message for adding a Request Resource Creator parameter sent by a previous entity, the oneM2M system forwards the Request message to the next entity through an entity that does not create a < Request > Resource, so that the communication can still be performed when the creation of the < Request > Resource of the local entity fails.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings needed to be used in the embodiments of the present invention will be briefly described below, and it is obvious that the drawings described below are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.

FIG. 1 is a schematic diagram of a system scenario of an embodiment of the invention.

Fig. 2 is a schematic flow chart of a method of communication in the oneM2M system according to one embodiment of the invention.

Fig. 3 is a schematic flow chart of a method of communication in the oneM2M system according to another embodiment of the present invention.

Fig. 4 is a schematic flow chart of a method of communication in the oneM2M system according to yet another embodiment of the present invention.

Fig. 5 is a schematic flow chart of a method of communication in the oneM2M system according to yet another embodiment of the present invention.

Fig. 6 is a schematic flow chart of a method of communication in the oneM2M system according to yet another embodiment of the present invention.

Fig. 7 is a schematic flow chart of a method of communication in the oneM2M system according to yet another embodiment of the present invention.

Fig. 8 is a schematic flow chart of a method of communication in the oneM2M system according to yet another embodiment of the present invention.

Fig. 9 is a schematic interaction flow diagram of a method of communication in the oneM2M system of one embodiment of the invention.

Fig. 10 is a schematic interaction flow diagram of a method of communication in the oneM2M system according to another embodiment of the invention.

Fig. 11 is a schematic interaction flow diagram of a method of communication in the oneM2M system according to yet another embodiment of the invention.

Fig. 12 is a schematic interaction flow diagram of a method of communication in the oneM2M system according to yet another embodiment of the invention.

Fig. 13 is a schematic interaction flow diagram of a method of communication in the oneM2M system according to yet another embodiment of the invention.

Fig. 14 is a schematic interaction flow diagram of a method of communication in the oneM2M system according to yet another embodiment of the invention.

Fig. 15 is a schematic interaction flow diagram of a method of communication in the oneM2M system according to yet another embodiment of the invention.

Fig. 16 is a schematic block diagram of a device communicating in the oneM2M system according to an embodiment of the present invention.

Fig. 17 is a schematic block diagram of a device for communication in the oneM2M system according to another embodiment of the present invention.

Fig. 18 is a schematic block diagram of a device for communication in the oneM2M system according to still another embodiment of the present invention.

Fig. 19 is a schematic block diagram of a device for communication in the oneM2M system according to still another embodiment of the present invention.

Fig. 20 is a schematic block diagram of a device communicating in the oneM2M system according to still another embodiment of the present invention.

Fig. 21 is a schematic block diagram of a device for communication in the oneM2M system according to still another embodiment of the present invention.

Fig. 22 is a schematic block diagram of a device for communication in the oneM2M system according to still another embodiment of the present invention.

Fig. 23 is a schematic block diagram of a device communicating in the oneM2M system according to an embodiment of the present invention.

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, not all, embodiments of the present invention. All other embodiments, which can be obtained by a person skilled in the art without any inventive step based on the embodiments of the present invention, shall fall within the scope of protection of the present invention.

Fig. 1 is a schematic illustration of a system scenario of an embodiment of the invention.

oneM2M systems to which embodiments of the invention are applicable include Originator, N transit CSEs (such as CSE1,.... CSEN in fig. 1), and a hotting CSE. The Originator in the embodiment of the invention may be AE or CSE. The Hosting CSE in the embodiment of the invention is a CSE for storing target resources.

In the non-blocking synchronous communication mode, when the target resource is stored in the Hosting CSE, the Originator may send a request message to the Hosting CSE requesting access to the target resource. The request message sent by the Originator can reach the Hosting CSE through the forwarding of the transit CSE.

As shown in FIG. 1, step 101Originator sends a request message to the Hosting CSE requesting a target resource stored in the Hosting CSE. The CSE1 first receives the request message. Transit CSE1 may not support the < request > resource type in step 102. When transit CSE1 does not create a < request > resource, it replies with a message that the creation of the < request > resource failed. Similarly, if the former N transit CSEs all create the < request > resource, the N +1 th transit or the home CSE replies a message that creating the < request > resource fails when the < request > resource cannot be created. Thus, the process of requesting the Hosting CSE by the Originator to operate on the target resource terminates.

For example, as shown in fig. 1, one entity sends a request message to the next entity in steps 103, 104 or 106. For example, at step 103, transit CSE1 sends a request message to transit CSE 2. Step 106, the transit CSE N +1 sends a request message to the hosting CSE. In steps 102, 105 or 107, the entity CSE (which may be a transit CSE or a hosting CSE) determines whether to create a < request > resource. When the entity cannot create the < request > resource, a message that the creation of the < request > resource fails is replied. In order to continue the communication process, an entity that does not create the < request > resource needs to be bypassed or transmitted through to implement the process of continuing the communication.

The application scenario of the embodiment of the present invention is that after the entity receives the request message, when determining whether to create the < request > resource, and according to the determination result, the process of requesting the Hosting CSE by the Originator to operate the target resource is continuously executed.

The first embodiment is as follows:

fig. 2 is a schematic flow chart of a method of communication in the oneM2M system according to one embodiment of the invention. The method of fig. 2 may be performed by a transit CSE.

A first request message in a non-blocking synchronous communication mode sent by a last entity is received 201. The first Request message includes a Request Resource Creator parameter. Where the Request Resource Creator parameter is a default value or an identifier of the entity that last created the Request < Request > Resource for the first Request message. The first request message is used for the initiation entity Originator to request the Hosting general service entity Hosting CSE where the target resource is located to operate the target resource.

202, when the < request > resource is not created for the first request message, the first request message is sent to the next entity.

The default value refers to the initial value of an attribute, parameter, before it is modified. Here, the default value is a default initial value.

The first request message is used by the Originator to request the Hosting CSE to operate on the target resource. The first request message carries a Response Type (RT) parameter, and when the RT parameter is set to "nonblockagrequestsynch", it indicates that a non-blocking synchronization mode is requested for communication. The request message may include an identifier of the Originator, an identifier of the Hosting CSE where the target resource is located.

The Originator in the embodiment of the present invention may be AE or CSE, which is not limited in the present invention.

The first Request message includes a Request Resource Creator parameter, which is a default value or an identifier of an entity that last created the Request < Request > Resource for the first Request message.

For example, the Request Resource Creator parameter in the first Request message sent by the Originator to the transit CSE1 is a default value. When the CSE1 does not create a < request > resource for the first request message, the CSE1 forwards the first request message, which the Originator sends to the transit CSE1, to the CSE 2. The Request Resource Creator parameter in the first Request message is still the default value at this time.

For another example, the Request Resource Creator parameter in the first Request message sent by the Originator to the transit CSE1 is a default value. When both transit CSEs 1 and 2 create a < Request > Resource for the first Request message, the Request Resource Creator parameter included in the first Request message sent by transit CSE2 to the next entity is the identifier of the entity that created the < Request > Resource last, i.e., CSE 1-ID.

The embodiment of the present invention does not limit the identifier of the entity. The embodiment of the present invention is described by taking the ID of the entity as an example, but the present invention is not limited thereto. The embodiment of the present invention does not limit the format of the ID. For example, the CSE-ID format may be: /CSE090112// www.m2mprovider.com/C3219. The AE-ID format may be: m2 pro v com CSE 3219/C9886. However, the embodiments of the present invention are not limited thereto.

Optionally, as an embodiment, when the transit CSE does not create a < request > resource for the request message, the transit CSE receives a first reply message sent by a next entity, and sends the first reply message to a previous entity. Wherein the first reply message includes address information of a < request > resource created next for an entity that created the < request > resource for the first request message. The first reply message may further include an identifier of an entity that creates the < request > resource next to the request message, an identifier of an entity that creates the < request > resource last to the request message, or an identifier of an Originator. The first reply message is for replying to the previous entity address information of the < request > resource created by the entity that created the < request > resource for the request message next.

For example, transit CSE2 does not create a < request > resource. Transit CSE2 receives the reply message sent by transit CSE3 and forwards the reply message to transit CSE 1. When transit CSE1 has created the < request > resource, the reply message sent by transit CSE3 includes an identifier of the Hosting CSE, an identifier of transit CSE1, and address information of the < request > resource created by the next entity that created the < request > resource for the request message. When the transit CSE1 does not create the < request > resource, the reply message sent by the transit CSE3 includes an identifier of the Hosting CSE, an identifier of the Originator, and address information of the < request > resource created by the next entity that created the < request > resource for the request message. Here, the next entity for creating the < request > resource for the request message may be a transit CSE or a home CSE.

The embodiment of the invention does not limit the address information of the < request > resource. For example, the address information of the < request > Resource may be a Universal Resource Identifier (URI), or may be a Resource Identifier (Resource ID). The embodiment of the present invention only takes the address information of the < request > Resource as the URI or Resource ID as an example for exemplary explanation. The embodiment of the invention does not limit the format of the identifier. For example, the Resource ID may be in the following format: street X/house Y/roomZ/temperature, the Resource ID being used to characterize the address of the temperature of the room Z of the building Y where street X is stored.

Optionally, as an embodiment, when the transit CSE does not create a < request > resource for the request message, the transit CSE receives a first get request message sent by a previous entity, and forwards the first get request message to a next entity. The first get request message is used to request the next entity creating < request > resource to get the processing result of the target resource. The first get request message includes address information of the < request > resource created by the entity that created the < request > resource next to the first request message.

The first get request message may also include an identifier of the Originator or an identifier of the last entity that created the < request > resource for the first request message.

After forwarding the first acquisition request message to the next entity, the transit CSE receives a second reply message sent by the next entity, and forwards the second reply message to the previous entity. The first obtaining request message is used for requesting the next entity which creates the < request > resource aiming at the request message to obtain the processing result of the target resource. The second reply message includes a result of the processing of the target resource. Receiving the second reply message sent by the next entity comprises receiving a processing result of the target resource sent by the next entity. Therefore, when the transfer CSE does not create the < request > resource, the communication can be continued, and a large amount of signaling overhead and resource waste can be avoided.

The second reply message may also include an identifier of the entity that created the < request > resource next to the request message, an identifier of the entity that created the < request > resource last to the request message, or an identifier of the Originator.

For example, when transit CSE2 does not create a < request > resource, transit CSE2 receives a first get request message sent by transit CSE1 and, after receiving the first get request message, forwards the first get request message to transit CSE 3. When the transit CSE1 creates a < request > resource, the first get request message sent by the transit CSE1 includes an identifier of the transit CSE1 and address information of the < request > resource created by the entity that creates the < request > resource next. When the transit CSE1 does not create a < request > resource, the first get request message sent by the transit CSE1 includes an identifier of the Originator and address information of the < request > resource created by the entity that creates the < request > resource next.

Transit CSE2, after receiving the second reply message sent by transit CSE3, forwards the second reply message to transit CSE 1. When the transit CSE1 creates a < request > resource, the second reply message may include an identifier of the next entity that created the < request > resource for the target resource, an identifier of the transit CSE1, and a processing result for the target resource. When the transit CSE1 does not create the < request > resource, the second reply message may include an identifier of the entity that creates the < request > resource next for the target resource, an identifier of the Originator, and a result of processing the target resource.

It should be understood that the address information of the < request > Resource may be a URI or a Resource ID, which is not limited in the embodiment of the present invention.

Optionally, as an embodiment, before the transit CSE sends the first request message to the next entity, it may also be determined whether to create a < request > resource for the first request message.

The embodiment of the present invention may also determine whether to create a < request > resource for the first request message before sending the first request message to the next entity. In this way, communication can be continued whether the entity creates the < request > resource or does not create the < request > resource, so as to further enhance the flexibility of communication.

Optionally, as an embodiment of the present invention, the transit CSE may determine whether to create a < request > resource for the first request message according to the capacity and/or the supported < request > resource type.

The transit CSE may determine whether to create a < request > resource for the request message according to its own circumstances. For example, when the transit CSE does not support the < request > resource type, it is determined that the transit CSE does not create the < request > resource.

When the transit CSE capacity is limited, it is determined that the CSE does not create a < request > resource. The transit CSE capacity limitation may be insufficient remaining capacity to hold the created < request > resource. Or the processing result of the target resource has no value to the transit CSE, and the transit CSE has a limited remaining capacity, so that the transit CSE determines not to create the < request > resource according to its own policy. The transit CSE determines not to create the < request > resource or may be that the transit CSE has sufficient capacity to store the < request > resource but the result of processing the target resource is of no value to the transit CSE and the transit CSE determines not to create the < request > resource. In the embodiment of the present invention, the CSE may determine whether to create a < request > resource for a request message according to a capacity and/or a supported < request > resource type, which is an example, but the present invention is not limited thereto.

Optionally, as an embodiment, when the transit CSE determines to create a < request > resource for the first request message, the transit CSE may create the < request > resource. Next, a third reply message is sent to the upper entity. Then, a second request message is generated and sent to the next entity. Here, the third reply message includes address information of the < request > resource created by the transit CSE. The second Request message includes a Request Resource Creator parameter. Wherein, the Request Resource Creator parameter is set as the identifier of the transit CSE.

The second request message may also include an identifier of the Originator and an identifier of the Hosting CSE. The third reply message may also include an identifier of the transit CSE, an identifier of the last entity that created the < request > resource for the target resource, or an identifier of the Originator.

For example, when transit CSE1 determines to create a < request > resource, transit CSE1 creates a < request1> resource. Next, a third reply message is sent to the upper entity Originator. Here, the third reply message may include an identifier of the transit CSE1, an identifier of the Originator, and address information of the < request1> resource created by the transit CSE 1. Transit CSE1 generates a second request message after transit CSE1 creates a < request1> resource. The Request Resource Creator parameter in the second Request message may be set to an identifier of the transit CSE1, e.g., CSE 1-ID. Transit CSE1 generates a second request message and forwards the second request message to transit CSE 2.

For another example, when transit CSE3 determines to create a < request > resource, transit CSE3 creates a < request3> resource. Next, a third reply message is sent to the previous entity transit CSE 2. When the transit CSE2 does not create a < request > resource and the transit CSE1 creates a < request > resource, the third reply message may include an identifier of the transit CSE1, an identifier of the transit CSE3, and address information of the < request3> resource created by the transit CSE 3. Transit CSE3 generates a second request message after transit CSE3 creates a < request3> resource. Here, the Request Resource Creator parameter in the second Request message may be set to an identifier of the transit CSE3, e.g., CSE 3-ID. Transit CSE3 generates a second request message and sends the second request message to the next entity.

Optionally, as an embodiment, when the transit CSE creates a < request > resource for the request message, the transit CSE receives a fourth reply message sent by a next entity. Then, the transit CSE updates the < request > resource created by the transit CSE according to the fourth reply message. Then, the relay CSE receives the second acquisition request message sent by the previous entity, and sends a fifth reply message to the previous entity. The fourth reply message includes a result of the processing of the target resource. The second obtaining request message is used for the last entity to request the transit CSE to obtain the processing result of the target resource. The second acquire request message includes address information of the created < request > resource. The fifth reply message includes a result of the processing of the target resource.

The fourth reply message may also include an identifier of the next entity that created the < request > resource for the request message, an identifier of the transit CSE. The second acquire request message may further include an identifier of the last entity and address information of the created < request > resource. The fifth reply message may also include an identifier of the transit CSE, an identifier of the last entity that created the < request > resource for the request message, or an identifier of the Originator.

For example, when transit CSE1 creates a < request1> resource, transit CSE1 receives a fourth reply message sent by the next entity transit CSE 2. Then, the < request1> resource created by the transit CSE1 is updated according to the fourth reply message. Then, the transit CSE1 receives the second get request message sent by the previous entity Originator, and sends a fifth reply message to the previous entity. Here, when the transit CSE2 does not create the < request > resource and the transit CSE3 creates the < request2> resource, the fourth reply message may include an identifier of the transit CSE3, an identifier of the transit CSE1, and a processing result for the target resource. The second acquisition request message may include an identifier of the Originator and address information of the < request1> resource. The fifth reply message may include an identifier of the transit CSE1, an identifier of the Originator.

For another example, when transit CSE3 creates a < request3> resource, transit CSE3 receives a fourth reply message sent by the next entity transit CSE 2. Then, the < request3> resource created by the transit CSE3 is updated according to the fourth reply message. Then, the transit CSE3 receives the second acquire request message sent by the transit CSE2 of the previous entity, and sends a fifth reply message to the transit CSE2 of the previous entity. Here, when the transit CSE2 does not create the < request > resource and the transit CSE1 creates the < request1> resource, the fourth reply message may include an identifier of the transit CSE3, an identifier of an entity that creates the < request > resource next, and a processing result for the target resource. The second fetch request message may include an identifier of the transit CSE1 and address information of the < request3> resource. The fifth reply message includes an identifier of transit CSE1, an identifier of transit CSE3, and a result of processing of the target resource.

The embodiment of the invention is suitable for the condition that the Hosting CSE needs to create the < request > resource. The transit CSE may decide whether to create the < request > resource according to its own circumstances. The CSE may determine whether the local entity is a transit CSE or a home CSE according to the parameter carried in the request message.

Example two:

Fig. 3 is a schematic flow chart of a method of communication in the oneM2M system according to another embodiment of the present invention. The method of fig. 3 may be performed by a transit CSE.

301, a first request message in a non-blocking synchronous communication mode sent by a previous entity is received. The first request message is used for the initiation entity Originator to request the Hosting general service entity Hosting CSE where the target resource is located to operate the target resource.

302, when a Request < Request > Resource is not created for the first Request message, a Request Resource Creator parameter is generated. The Request Resource Creator parameter is set to a default value or an identifier of the last entity that created the Request < Request > Resource for the first Request message.

303, generating a second Request message, where the second Request message includes the Request Resource Creator parameter.

304, sending the second request message to the next entity.

When the oneM2M system of the embodiment of the present invention uses the non-blocking synchronous communication mode to perform communication, after receiving a Request message sent by a previous entity, the oneM2M system generates a Request Resource Creator parameter by an entity that does not create a < Request > Resource, and then sends a Request message including the Request Resource Creator parameter to a next entity, so that communication can still be performed when the creation of the < Request > Resource of the local entity fails.

The first request message is used by the Originator to request the Hosting CSE to operate on the target resource. The first request message carries an RT parameter, and when the RT parameter is set to "nonblockackrequestsync", it indicates that a non-blocking synchronization mode is requested for communication. The first request message may include an identifier of the Originator, an identifier of the Hosting CSE where the target resource is located.

In step 302, when the transit CSE does not create a Request < Request > Resource for the Request message, the transit CSE may generate a Request Resource Creator parameter. The Request Resource Creator parameter may be set to a default value or an identifier of the last entity that created the Request < Request > Resource for the Request message.

For example, the Request Resource Creator parameter may be set to a default value when the transit CSE does not create a < Request > Resource for the first transit or an entity before the transit CSE. When an entity that can create a < Request > Resource exists before the transit of the CSE, the Request Resource Creator parameter may be set to an identifier of the last entity that created the Request < Request > Resource for the Request message.

In step 303, a second Request message is generated according to the Request Resource Creator parameter. The second Request message includes the Request Resource Creator parameter.

In step 304, a second request message is sent to the next entity. Here sending the second Request message to the next entity comprises sending a Request Resource Creator parameter.

Specifically, for example, the Request message sent by the Originator to the transit CSE1 does not include the Request Resource Creator parameter. The relay CSE1 generates a Request Resource Creator parameter, and stores the Request Resource Creator parameter in the received Request message. Then, the relay CSE1 sends a Request message including a Request Resource Creator parameter to the relay CSE 2.

For another example, the Request message sent by the transit CSE N to the transit CSE N +1 does not include the Request Resource Creator parameter. The transit CSE N +1 generates a Request Resource Creator parameter and stores the Request Resource Creator parameter in the received Request message. Then, the transit CSE N +1 sends a Request message including the Request Resource Creator parameter to the next entity.

Transit CSE2, after receiving the second reply message sent by transit CSE3, forwards the second reply message to transit CSE 1. When the transit CSE1 creates a < request > resource, the second reply message may include an identifier of an entity that creates the < request > resource next for the target resource, an identifier of the transit CSE1, and a processing result for the target resource. When the transit CSE1 does not create the < request > resource, the second reply message may include an identifier of the entity that creates the < request > resource next for the target resource, an identifier of the Originator, and a result of processing the target resource.

The transit CSE may determine whether to create a < request > resource for the request message according to its own circumstances. Optionally, as an embodiment of the present invention, the transit CSE may determine whether to create a < request > resource for the first request message according to the capacity and/or the supported < request > resource type.

Optionally, as an embodiment, when the transit CSE determines to create a < request > resource for the first request message, the transit CSE may create the < request > resource. Next, a third reply message is sent to the upper entity. Then, a third request message is generated and sent to the next entity. Here, the third reply message includes address information of the < request > resource created by the transit CSE. The third Request message includes a Request Resource Creator parameter. Wherein, the Request Resource Creator parameter is set as the identifier of the transit CSE.

The third request message may also include an identifier of the Originator and an identifier of the Hosting CSE. The third reply message may also include an identifier of the transit CSE, an identifier of the last entity that created the < request > resource for the target resource, or an identifier of the Originator.

For example, when transit CSE1 determines to create a < request > resource, transit CSE1 creates a < request1> resource. Next, a third reply message is sent to the upper entity Originator. Here, the third reply message may include an identifier of the transit CSE1, an identifier of the Originator, and address information of the < request1> resource created by the transit CSE 1. Transit CSE1 generates a third request message after transit CSE1 creates a < request1> resource. The Request Resource Creator parameter in the third Request message may be set to an identifier of the transit CSE1, e.g., CSE 1-ID. The transit CSE1 generates a third request message and forwards the third request message to the transit CSE 2.

For another example, when transit CSE3 determines to create a < request > resource, transit CSE3 creates a < request3> resource. Next, a third reply message is sent to the previous entity transit CSE 2. When the transit CSE2 does not create a < request > resource and the transit CSE1 creates a < request > resource, the third reply message may include an identifier of the transit CSE1, an identifier of the transit CSE3, and address information of the < request3> resource created by the transit CSE 3. Transit CSE3 generates a third request message after transit CSE3 creates a < request3> resource. Here, the Request Resource Creator parameter in the third Request message may be set to an identifier of the transit CSE3, e.g., CSE 3-ID. Transit CSE3 generates a third request message and sends the third request message to the next entity.

For another example, when transit CSE3 creates a < request1> resource, transit CSE3 receives a fourth reply message sent by the next entity transit CSE 2. Then, the < request3> resource created by the transit CSE3 is updated according to the fourth reply message. Then, the transit CSE3 receives the second acquire request message sent by the transit CSE2 of the previous entity, and sends a fifth reply message to the transit CSE2 of the previous entity. Here, when the transit CSE2 does not create the < request > resource and the transit CSE1 creates the < request1> resource, the fourth reply message may include an identifier of the transit CSE3, an identifier of an entity that creates the < request > resource next, and a processing result for the target resource. The second fetch request message may include an identifier of the transit CSE1 and address information of the < request3> resource. The fifth reply message includes an identifier of transit CSE1, an identifier of transit CSE3, and a result of processing of the target resource.

Example three:

Fig. 4 is a schematic flow chart of a method of communication in the oneM2M system according to another embodiment of the present invention. The method of fig. 4 may be performed by a transit CSE.

401, a first request message in a non-blocking synchronous communication mode sent by a last entity is received. The response type RT parameter carried by the first request message includes a request resource indication field. The first request message is used for the initiation entity Originator to request the Hosting general service entity Hosting CSE where the target resource is located to operate the target resource. Wherein the request resource indication field is a default value or an identifier of an entity that has last created a request < request > resource for the first request message.

402, when a request < request > resource is not created for the first request message, the first request message is sent to the next entity.

When the oneM2M system of the embodiment of the present invention uses the non-blocking synchronous communication mode to perform communication, after receiving a request message that is sent by a previous entity and requests to operate a target resource, an identifier of the previous entity that creates a < request > resource is indicated by using a request resource indication field added in an RT parameter, so that an entity that does not create the < request > resource sends the request message to a next entity, and thus, communication can still be continued when the < request > resource is failed to be created.

The first request message is used by the Originator to request the Hosting CSE to operate on the target resource. The first request message carries a RT parameter, and when the RT parameter is set to "nonblocking request sync (null)", it indicates that a non-blocking synchronization mode is requested for communication, and the request resource indication field is a default value. The first request message may include an identifier of the Originator, an identifier of the Hosting CSE where the target resource is located.

In step 401, the request resource indication field may also be an identifier of an entity that has last created a request < request > resource for the first request message.

For example, after the transit CSE receives the first request message, if the transit CSE is the first transit CSE or no < request > resource is created by the entity before the transit CSE, the request resource indication field may be a default value at this time. If an entity creating a < request > resource exists before the transit of the CSE, the request resource indication field at this time may be an identifier of the last entity creating the < request > resource.

Generally, when the RT parameter indicates that communication is requested in a non-blocking synchronization mode and the request resource indication field is a default value, the RT parameter may be set to "nonblocking request sync (null)". The RT parameter may be set to "nonblocking request sync" only for indicating that communication in the non-blocking synchronization mode is requested. The RT parameter used for indicating that the communication is requested to adopt the non-blocking synchronous mode, and the RT parameter when the request resource indication field is the default value is different from the RT parameter used for only indicating that the communication is requested to adopt the non-blocking synchronous mode.

It should be understood that the present invention is not limited to the specific value of the default value of the request resource indication field.

It should be understood that, in the embodiment of the present invention, the identifier of the entity that creates the < request > resource is represented by the request resource indication field, but the present invention is not limited thereto. The identifier of the entity that created the < request > resource can also be represented by other parameters in the non-blocking communication mode.

Optionally, as an embodiment, when the transit CSE determines to create a < request > resource for the first request message, the transit CSE may create the < request > resource. Next, a third reply message is sent to the upper entity. Then, a second request message is generated and sent to the next entity. Here, the third reply message includes address information of the < request > resource created by the transit CSE. The second request message includes a request resource indication field. Wherein, the request resource indication field is set as the identifier of the transit CSE.

Example four:

Fig. 5 is a schematic flow chart of a method of communication in the oneM2M system according to another embodiment of the present invention. The method of fig. 5 may be performed by a transit CSE.

501, a request message in a non-blocking synchronous communication mode sent by a last entity is received. The request message is used for the Originator to request the Hosting CSE where the target resource is located to operate the target resource.

502, when the < request > resource is not created for the first request message, an indication message is sent to the upper entity. The indication message includes a Request Not to Create Request Not Create parameter. The Request Not Create parameter includes an identifier of the next entity. The indication message is used for indicating the last entity to send the first request message to the next entity.

When the oneM2M system of the embodiment of the present invention uses the non-blocking synchronous communication mode to perform communication, after the transit CSE receives a Request message that is sent by a previous entity and requests to operate a target resource, a new Request Not Create parameter is added to indicate that an entity that does Not Create a < Request > resource sends a Request message to other entities, so that communication can still be performed when the < Request > resource is failed to be created.

The request message is used by the Originator to request the Hosting CSE to operate on the target resource. The request message carries an RT parameter, and when the RT parameter is set to "nonblockackrequestsync", it indicates that a non-blocking synchronization mode is used for communication. The request message may include an identifier of the Originator, an identifier of the Hosting CSE where the target resource is located.

It should be understood that the embodiment of the present invention does not limit the specific form of the previous entity and the next entity. For example, the last entity may be the transit CSE, or the Originator. The next entity may be a transit CSE or a hotting CSE.

In the embodiment of the invention, before the indication message is sent to the upper entity by the transit CSE, whether the < request > resource is created for the request message can be determined according to the self condition. Optionally, as an embodiment of the present invention, the transit CSE may determine whether to create a < request > resource for the first request message according to the capacity and/or the supported < request > resource type. In this way, communication can be continued whether the entity creates the < request > resource or does not create the < request > resource, so as to further enhance the flexibility of communication.

For example, when the transit CSE does not support the < request > resource type, it is determined that the transit CSE does not create the < request > resource. It may be determined not to create the < request > resource when the transit CSE has insufficient remaining capacity to hold the created < request > resource. When the transit CSE does not need to store the processing result of the target resource and the transit CSE has limited residual capacity, the transit CSE may determine not to create the < request > resource according to its own policy. The transit CSE may also not create the < request > resource when the transit CSE does not need to save the processing result for the target resource, although there is sufficient capacity to save the < request > resource.

Example five:

fig. 6 is a schematic flow chart of a method of communication in the oneM2M system according to yet another embodiment of the present invention. The method of fig. 6 may be performed by a transit CSE.

601, sending a request message in non-blocking synchronous communication mode to the next entity. The request message is used for the Originator to request the Hosting CSE where the target resource is located to operate the target resource.

And 602, receiving an indication message sent by the next entity. The indication message includes a Request Not to Create Request Not Create parameter. The Request Not Create parameter includes an identifier of the first entity. The indication message is used for indicating the local entity to send the request message to the first entity.

603 sending a request message to the first entity.

When the oneM2M system of the embodiment of the present invention uses the non-blocking synchronous communication mode to perform communication, after the transit CSE receives a Request message that is sent by the previous entity and requests to operate a target resource, the previous entity sends the Request message to other entities by adding a new Request Not Create parameter for indicating that an entity that does Not Create a < Request > resource is Not created, so that communication can still be performed when the < Request > resource is failed to be created.

The request message is used by the Originator to request the Hosting CSE to operate on the target resource. The request message carries an RT parameter, and when the RT parameter is set to "nonblockackrequestsync", it indicates that a non-blocking synchronization mode is used for communication. The request message may include an identifier of the Originator, an identifier of the Hosting CSE where the message target resource is located.

After the transit CSE sends the request message to the next entity, when the next entity does not create the < request > resource, the next entity sends an indication message to the transit CSE. The indication message is used to indicate that the local entity (i.e., the transit CSE) sends a request message to another entity (e.g., the first entity). The indication message includes a Request Not to Create Request Not Create parameter. The Request Not Create parameter includes an identifier of the first entity. And after receiving the indication message, the transit CSE sends a request message to the first entity. The request message is for requesting establishment of a connection with a first entity.

Therefore, when the transfer CSE does not create the < request > resource, the communication can be continued, and a large amount of signaling overhead and resource waste can be avoided.

Example six:

fig. 7 is a schematic flow chart of a method of communication in the oneM2M system according to yet another embodiment of the present invention. The method of FIG. 7 may be performed by the Hosting CSE.

701, receiving a request message in a non-blocking synchronous communication mode sent by a transit CSE. The request message is used for the originor to request the operation on the target resource;

and 702, when the < request > resource is not created for the request message, sending indication information to the transit CSE according to the request message. The indication information is used to indicate the transit CSE to resend the request message after the first time period.

When the oneM2M system of the embodiment of the present invention uses the non-blocking synchronous communication mode for communication, after receiving a request message that is sent by a previous entity and requests to operate a target resource, the Hosting CSE sends an indication message to the previous entity to indicate the previous entity to resend the request message after a period of time, so that the communication can still be continued when the creation of the < request > resource fails.

The indication message may include an identifier of the last entity, an identifier of the transit CSE, and a Request Not Create parameter.

The time for the transit CSE to resend the request message is at a time expected to be required for the home CSE to process the target resource. In this way, when the Hosting CSE does not create the < request > resource, the process of requesting the Hosting CSE by the Originator to operate on the target resource can still be continuously executed. And further resource waste and a large amount of signaling overhead caused by communication termination are avoided.

Optionally, as an embodiment, when receiving the request message sent by the transit CSE and not creating a < request > resource, the home CSE processes the target resource according to the request message to obtain a processing result of the target resource.

The Hosting CSE cannot create a < request > resource and cannot store the processing result of the target resource. But may forward the processing results for the target resource to the relay. Optionally, the Hosting CSE receives the request message for relaying CSE resending after a period of time. And then, sending a reply message to the transit CSE according to the request message. The sending of the reply message by the Hosting CSE to the transit CSE comprises sending a processing result of the target resource to the transit CSE. The reply message may include an identifier of the Hosting CSE, an identifier of the Originator, and the results of the processing of the target resource.

For example, when the Hosting CSE does not create a < request > resource and the transit CSE2 does not create a < request > resource, the transit CSE2 sends an indication message to the previous entity transit CSE 1. The indication message may include an identifier of transit CSE2, an identifier of transit CSE1, and a Request Not Create parameter. The indication message is used to instruct the transit CSE2 to send a request message to the transit CSE3 to continue executing the process of requesting the operation on the target resource from the Hosting CSE by the Originator. Here, the Request Not Create parameter includes an identifier of the next entity transit CSE 4. The transit CSE1, after receiving the indication message sent by the transit CSE2, deregisters the registration information on the transit CSE2 and registers on the transit CSE 3. Communication is established between transit CSE1 and transit CSE 3. Transit CSE1 may send a request message to transit CSE3 to skip transit CSE2 to continue executing the process of the Originator requesting the Hosting CSE to operate on the target resource.

The embodiment of the invention avoids the failure of replying and creating < request > resources by the (N + 1) th transit CSE under the condition that the < request > resources are successfully created in the former N transit and the < request > resources are not created by the (N + 1) th transit CSE by skipping the transit CSE which does not create the < request > resources, thereby causing a great deal of signaling overhead and resource waste.

Optionally, as an embodiment, the first duration is longer than a duration required to process the target resource.

After the first time period, the Hosting CSE can resend the indication message to the transit CSE if the Hosting CSE has not completed processing the target resource. The indication message is used to indicate that the relay sends the request message again after a period of time.

After the second duration, if the Hosting CSE does not receive the request message retransmitted by the transit CSE, the Hosting CSE can discard the processing result of the target resource. And after the transit CSE can be in the third time length, the request message is sent to the Hosting CSE again. And after receiving the request message sent again by the transit CSE, the Hosting CSE processes the request message as a new message and restarts to execute the processing process of the target resource so as to obtain the processing result of the target resource.

Here, the first period, the second period, and the third period are not limited. Typically, the second duration is greater than the first duration. The third duration is greater than the second duration.

Example seven:

fig. 8 is a schematic flow chart of a method of communication in the oneM2M system according to yet another embodiment of the present invention. The method of FIG. 8 may be performed by a correspondent entity of the Hosting CSE.

801 sends a request message in non-blocking synchronous communication mode to the Hosting CSE. The request message is used for the Originator to request the Hosting CSE to operate on the target resource.

And 802, receiving indication information sent by the Hosting CSE according to the request message. The indication message is used to indicate that the request message is to be resent after the first time period.

When the oneM2M system of the embodiment of the present invention uses the non-blocking synchronous communication mode to perform communication, after sending a request message requesting to operate a target resource to a next entity, the oneM2M system receives an indication message sent by the next entity to indicate a local entity to resend the request message after a period of time, so that the communication can still be continued when the creation of the < request > resource fails.

Optionally, as an embodiment, when the Hosting CSE does not create the < request > resource, the transit CSE may resend the request message to the Hosting CSE after a period of time. The transit CSE may receive a reply message sent by the home CSE after the home CSE completes processing of the target resource. The reply message includes the processing result for the target resource. The transit CSE receiving the reply message includes receiving a processing result for the target resource.

The transit CSE may resend the request message to the Hosting CSE after a period of time. In this way, when the Hosting CSE does not create the < request > resource, the process of requesting the Hosting CSE by the Originator to process the target resource can still be continuously executed. And further resource waste and a large amount of signaling overhead caused by communication failure can be avoided.

Optionally, as an embodiment, the first duration is longer than a duration required to process the target resource. The request message is resent to the Hosting CSE for a first time period, i.e., after the Hosting CSE is expected to complete processing of the target resource.

Specifically, the peer entity of the Hosting CSE is taken as the transit CSE3 for example. When the Hosting CSE does not create the < request > resource, the transit CSE3 resends the request message to the Hosting CSE after the first request message sending interval is a period of time to obtain the processing result of the target resource sent by the Hosting CSE. The length of the period of time may be greater than the time expected to be required for the Hosting CSE to complete processing the target resource. In this way, when the Hosting CSE does not create the < request > resource, the process of the Originator requesting the Hosting CSE to operate the target resource can be continuously executed.

The interaction flow among the Originator, the transit CSE and the Hosting CSE according to the embodiment of the present invention will be described in detail with reference to fig. 9 to 15.

Example eight:

fig. 9 is a schematic interaction flow diagram of a method of communication in the oneM2M system of one embodiment of the invention. The embodiment of fig. 9 is exemplified by the case that no three transit CSEs create a < request > resource, but the Hosting CSE creates a < request > resource.

901, the Originator sends a request message to the Hosting CSE, and the relay CSE1 receives the request message.

The origin sends a request message to the Hosting CSE where the target resource is located, the request message carries the RT parameter, and when the RT parameter is set to 'nonBlockingRequestSynch', the request is communicated in a non-blocking synchronization mode. The request message is used by the Originator to request the Hosting CSE to operate on the target resource. The Request message may include an identifier of the Originator, an identifier of the Hosting CSE where the target Resource is located, and a Request Resource Creator parameter. The Request Resource Creator parameter is a default value. The Originator completes registration with the transit CSE1 and the transit CSE1 may first receive the request message.

Transit CSE1 forwards the request message to transit CSE 2.

The Originator completes registration with the transit CSE1, and the transit CSE1 first receives the request message sent by the last entity Originator. The transit CSE1 may determine whether to create a < request > resource based on its own circumstances. For example, transit CSE1 does not support a < request > resource type, then it is determined that the < request > resource is not to be created. When transit CSE1 determines that the < request > resource is not created, transit CSE1 forwards the request message to transit CSE 2.

903, transit CSE2 forwards the request message to transit CSE 3.

Transit CSE2 receives the request message sent by last entity transit CSE 1. The transit CSE2 may also determine whether to create a < request > resource based on its own circumstances. For example, transit CSE2 is limited in capacity, then transit CSE2 determines that the < request > resource is not created. When transit CSE2 determines that the < request > resource is not created, transit CSE2 forwards the request message to transit CSE 3.

At 904, transit CSE3 forwards the request message to the Hosting CSE.

Transit CSE3 receives the request message sent by last entity transit CSE 2. The transit CSE3 may also determine whether to create a < request > resource based on its own circumstances. When transit CSE3 determines that the < request > resource is not created, transit CSE3 forwards the request message to the Hosting CSE.

905, the Hosting CSE processes the target resource and creates a < request > resource.

The Hosting CSE processes the target resource after receiving the request message sent by the transit CSE 3. Meanwhile, the Hosting CSE may create a < request > resource after receiving the request message sent by the transit CSE 3.

906, the Hosting CSE sends a reply message to the transit CSE 3.

After creating < request > resource, the Hosting CSE sends reply message to the transit CSE3 of the previous entity. The reply message sent by the Hosting CSE may include an identifier of the Hosting CSE, an identifier of the Originator, and address information of the < request > resource created by the Hosting CSE.

It should be understood that the address information of the < request > resource may be a URI or an ID, which is not limited in the embodiment of the present invention.

907, transit CSE3 forwards the reply message to transit CSE 2.

After receiving the reply message sent by the home CSE, the transit CSE3 forwards the reply message to the transit CSE2 of the previous entity.

908, transit CSE2 forwards the reply message to transit CSE 1.

After receiving the reply message sent by transit CSE3, transit CSE2 forwards the reply message to transit CSE1 of the previous entity.

909, transit CSE1 forwards the reply message to Originator.

The transit CSE1 forwards the reply message to the last entity Originator after receiving the reply message sent by the transit CSE 2.

91O, origin sends a get request message to the transit CSE 1.

After receiving the reply message sent by the transit CSE1, the Originator sends a get request message to the next entity transit CSE 1. The get request message sent by the Originator may include an identifier of the Originator and address information of the Hosting CSE creation < request > resource. The acquisition request message is used for requesting the Hosting CSE creating the < request > resource to acquire the processing result of the target resource. Transit CSE1 first receives the get request message.

911, transit CSE1 forwards the get request message to transit CSE 2.

After receiving the get request message sent by the Originator, the transit CSE1 forwards the get request message to the next transit CSE 2.

At 912, transit CSE2 forwards the get request message to transit CSE 3.

After receiving the acquire request message sent by the transit CSE1, the transit CSE2 forwards the acquire request message to the next entity transit CSE 3.

913, transit CSE3 forwards the get request message to the Hosting CSE.

After receiving the get request message sent by the transit CSE2, the transit CSE3 forwards the get request message to the next entity Hosting CSE.

914, the Hosting CSE updates the < request > resource created by the Hosting CSE itself.

After receiving the acquisition request message sent by the transit CSE3, the home CSE obtains a processing result of the target resource if the processing of the target resource is completed. And the Hosting CSE saves the processing result of the target resource in the < request > resource created by the Hosting CSE so as to update the < request > resource created by the Hosting CSE.

915, the Hosting CSE sends a reply message to the transit CSE 3.

After obtaining the processing result of the target resource, the Hosting CSE sends a reply message to the relay CSE3 of the previous entity. The reply message sent by the Hosting CSE includes an identifier of the Hosting CSE, an identifier of the origin, and a result of the processing of the target resource. Sending the reply message by the Hosting CSE to the transit CSE3 includes sending the processing result for the target resource to the transit CSE 3.

Relay CSE3 forwards the reply message to relay CSE 2.

After receiving the reply message sent by the home CSE, the transit CSE3 forwards the reply message to the transit CSE2 of the previous entity, so that the transit CSE2 obtains the processing result of the target resource.

917, transit CSE2 forwards the reply message to transit CSE 1.

After receiving the reply message sent by the transit CSE3, the transit CSE2 forwards the reply message to the transit CSE1 of the previous entity, so that the transit CSE1 obtains a processing result of the target resource.

918, transit CSE1 forwards the reply message to the Originator.

After receiving the reply message sent by the transit CSE2, the transit CSE1 forwards the reply message to the previous entity Originator, so that the Originator obtains the processing result of the target resource.

The Originator receiving the reply message sent by the transit CSE1 includes receiving the processing result for the target resource. The Originator obtains the processing result of the target resource, namely, the communication process of requesting the target resource from the Hosting CSE by the whole Originator is completed.

The embodiment of fig. 9 is exemplarily illustrated by an example that the Originator sends the request message to the Hosting CSE, the request message passes through three transit CSEs, and none of the three transit CSEs creates a < request > resource, and the embodiment of the present invention does not limit the number of the transit CSEs. The embodiment of fig. 10 will be exemplarily illustrated by an example in which the Originator sends a request message to the Hosting CSE, and the transit CSE1 creates a < request > resource through three transit CSEs, while neither the transit CSE2 nor the transit CSE3 creates a < request > resource.

Example nine:

1001, Originator sends a request message to the Hosting CSE, which transit CSE1 first receives.

The origin sends a request message to the Hosting CSE where the target resource is located, the request message carries the RT parameter, and when the RT parameter is set to 'nonBlockingRequestSynch', the request is communicated in a non-blocking synchronization mode. The request message sent by the Originator is used for requesting the Hosting CSE to operate on the target resource by the Originator. The Request message sent by the Originator may include an identifier of the Originator, an identifier of the Hosting CSE where the target Resource is located, and a Request Resource Creator parameter. The Request Resource Creator parameter is a default value. The Originator completes registration with the transit CSE1 and the transit CSE1 may first receive the request message.

At 1002, transit CSE1 creates a < request > resource.

The Originator completes registration with the transit CSE1, and the transit CSE1 first receives the request message sent by the last entity Originator. The transit CSE1 may determine whether to create a < request > resource based on its own circumstances. For example, transit CSE1 supports the creation of a < request > resource, then it is determined to create a < request1> resource.

1003, the transit CSE1 sends a reply message to the Originator.

After the transit CSE1 creates the < request1> resource, it sends a reply message to the previous entity Originator. The reply message sent by transit CSE1 may include an identifier of transit CSE1, an identifier of the Originator, and address information of the < request1> resource created by transit CSE 1. The reply message sent by the transit CSE1 is used to send the address information of the < request1> resource created by the transit CSE1 to the origin, so that the origin sends a get request message to the transit CSE1 to get the processing result of the target resource.

1004, the transit CSE1 generates a request message of the transit CSE1 and sends the request message of the transit CSE1 to the next entity transit CSE 2.

The transit CSE1 may set a Request Resource Creator parameter to the identifier of the transit CSE 1. And generating a Request message for transferring the CSE1 according to the Request Resource Creator parameter. The Request message of the transit CSE1 may include an identifier of the origin, an identifier of the Hosting CSE, and a Request Resource Creator parameter, with the identifier of the transit CSE1 located in the Request Resource Creator parameter. After generating the request message of the transit CSE1, the transit CSE1 sends the request message of the transit CSE1 to the next entity transit CSE 2. The request message of transit CSE1 is used to request acquisition of the processing result for the target resource to the Hosting CSE.

1005, transit CSE2 forwards the request message of transit CSE1 to the next entity transit CSE 3.

After receiving the request message of the transit CSE1 sent by the transit CSE1, the transit CSE2 forwards the request message of the transit CSE1 to the next entity transit CSE 3.

1006, the transit CSE3 forwards the request message of the transit CSE1 to the next entity, the home CSE.

After receiving the request message of the transit CSE1 sent by the transit CSE2, the transit CSE3 forwards the request message of the transit CSE1 to the next entity Hosting CSE.

1007, the Hosting CSE processes the target resource and creates a < request2> resource.

And after receiving the request message of the transit CSE1 sent by the transit CSE3, the Hosting CSE starts to process the target resource. After receiving the request message of the transit CSE1 sent by the transit CSE3, the Hosting CSE determines to create the < request2> resource according to the self condition.

1008, the Hosting CSE sends a reply message to the previous entity relay CSE 3.

The Hosting CSE sends a reply message to the transit CSE3 of the previous entity after creating the < request2> resource. The reply message sent by the Hosting CSE may include the Hosting CSE identifier, the identifier of the transit CSE1, and address information for the < request2> resource created by the Hosting CSE.

The embodiment of the invention does not limit the address information of the < request2> resource. The address information of the < request2> Resource may be a URI or a Resource ID.

1009 transit CSE3 forwards the reply message to transit CSE 2.

After receiving the reply message sent by the home CSE, the transit CSE3 forwards the reply message in step 1008 to the previous entity transit CSE 2.

At 1010, transit CSE2 forwards the reply message to transit CSE 1.

After receiving the reply message sent by transit CSE3, transit CSE2 forwards the reply message in step 1008 to last entity CSE 1.

1011, the transit CSE1 sends a get request message to the transit CSE 2.

The transit CSE1 sends the acquire request message to the transit CSE2 after receiving the reply message sent by the transit CSE 2. The get request message sent by the transit CSE1 may include an identifier of the transit CSE1 and address information of the < request2> resource created by the Hosting CSE. The acquisition request message sent by the transit CSE1 is used to request the home CSE that created the < request2> resource to acquire the processing result of the target resource. Transit CSE2 first receives the get request message.

1012, transit CSE2 forwards the get request message to transit CSE 3.

1013, the transit CSE3 forwards the get request message to the Hosting CSE.

1014, the Hosting CSE updates the < request2> resource created by the Hosting CSE itself.

After receiving the acquisition request message sent by the transit CSE3, the home CSE obtains a processing result of the target resource if the processing of the target resource is completed. The Hosting CSE saves the processing result of the target resource in the < request2> resource created by the Hosting CSE to update the < request2> resource.

1015, the Hosting CSE sends a reply message to the transit CSE 3.

After obtaining the processing result of the target resource, the Hosting CSE sends a reply message to the relay CSE3 of the previous entity. The reply message sent by the Hosting CSE may include an identifier of the Hosting CSE, an identifier of the transit CSE1, and a result of the processing of the target resource. The reply message sent by the Hosting CSE to the transit CSE3 includes the results of the processing of the target resource sent to the transit CSE 3.

Transit CSE3 forwards the reply message to transit CSE2, 1016.

After receiving the reply message sent by the Hosting CSE, the transit CSE3 forwards the reply message in step 1015 to the previous transit CSE2, so that the transit CSE2 obtains the processing result of the target resource.

1017, transit CSE2 forwards the reply message to transit CSE 1.

After receiving the second reply message sent by the transit CSE3, the transit CSE2 forwards the reply message in step 1015 to the transit CSE1 of the previous entity, so that the transit CSE1 obtains a processing result of the target resource.

1018, the transit CSE1 updates the < request1> resource created by the transit CSE1 itself according to the reply message.

The transit CSE1 receives the processing result of the target resource after receiving the reply message in step 1015 sent by the transit CSE 2. The relay CSE1 saves the processing result for the target resource in the < request1> resource created by itself to update the < request1> resource.

1019, the Originator sends a get request message to the transit CSE 1.

The Originator sends a get request message to the next entity transit CSE 1. The get request message that the Originator sends to the transit CSE1 includes an identifier of the Originator and address information of < request1> resource. The get request message sent by the Originator to the transit CSE1 is used for the Originator to request the transit CSE1 to get the processing result of the target resource.

1020, transit CSE1 sends a reply message to the Originator.

After receiving the get request message sent by the last entity Originator, the transit CSE1 sends a reply message to the Originator. The reply message sent by the transit CSE1 may include an identifier to the Originator, an identifier of the transit CSE1, and the processing result for the target resource.

The Originator receives the reply message sent by the transit CSE1, namely the processing result of the target resource. Thus, the whole Originator completes the communication process of requesting the target resource from the Hosting CSE.

Example ten:

the embodiment of fig. 11 will be exemplarily illustrated by an example in which the Originator sends a request message to the Hosting CSE, creates a < request > resource through three transit CSEs, transit CSE1 and transit CSE3, and transit CSE2 does not create the < request > resource.

1101, the Originator sends a request message to the Hosting CSE, and the transit CSE1 first receives the request message.

The origin sends a request message to the Hosting CSE where the target resource is located, the request message carries the RT parameter, and when the RT parameter is set to 'nonBlockingRequestSynch', the request is communicated in a non-blocking synchronization mode. The request message sent by the Originator is used for requesting the Hosting CSE to operate on the target resource by the Originator. The Request message sent by the Originator includes an identifier of the Originator, an identifier of the Hosting CSE where the target Resource is located, and a Request Resource Creator parameter. The Request Resource Creator parameter is a default value. The Originator completes registration with the transit CSE1 and the transit CSE1 may first receive the request message.

1102, transit CSE1 creates a < request > resource.

The Originator completes registration in the transit CSE1, and the transit CSE1 first receives the request message sent by the last entity Originator. The transit CSE1 may determine whether to create a < request > resource based on its own circumstances. For example, transit CSE1 supports the creation of a < request > resource, then it is determined to create a < request1> resource.

1103, transit CSE1 sends a reply message to Originator.

After the transit CSE1 creates the < request1> resource, it sends a reply message to the previous entity Originator. The reply message sent by the transit CSE1 includes an identifier of the transit CSE1, an identifier of the Originator, and address information of the < request1> resource created by the transit CSE 1. The reply message sent by the transit CSE1 is used to send the address information of the < request1> resource created by the transit CSE1 to the origin, so that the origin sends a get request message to the transit CSE1 to get the processing result of the target resource.

1104, the transit CSE1 generates a request message of the transit CSE1 and sends the request message of the transit CSE1 to the next entity transit CSE 2.

The transit CSE1 may set a Request Resource Creator parameter to the identifier of the transit CSE 1. And generating a Request message for transferring the CSE1 according to the Request Resource Creator parameter. The Request message of the transit CSE1 includes an identifier of the origin, an identifier of the Hosting CSE, and a Request Resource Creator parameter, and the identifier of the transit CSE1 is located in the Request Resource Creator parameter. After generating the request message of the transit CSE1, the transit CSE1 sends the request message of the transit CSE1 to the next entity transit CSE 2. The request message of transit CSE1 is used to request acquisition of the processing result for the target resource to the Hosting CSE.

The identifier of the transit CSE1 is not limited in the embodiments of the present invention. For example, the identifier of transit CSE1 may be CSE 1-ID.

1105, transit CSE2 forwards the request message for transit CSE1 to the next entity transit CSE 3.

1106, transit CSE3 creates a < request2> resource.

After receiving the request message sent by the transit CSE2, the transit CSE3 determines whether to create a < request > resource according to its own condition. For example, transit CSE3 supports the creation of < request > resources, and the creation of < request2> resources.

1107, transit CSE3 sends a reply message to the previous entity transit CSE 2.

Transit CSE3 sends a reply message to the previous entity transit CSE2 after creating the < request2> resource. The reply message sent by transit CSE3 includes the transit CSE3 identifier, the transit CSE1 identifier, and the address information of the < request2> resource created by transit CSE 3.

Transit CSE2 forwards the reply message to transit CSE1 1108.

1109, the transit CSE3 generates a request message and sends the request message to the Hosting CSE.

Transit CSE3 generates a request message for transit CSE 3. The Request message of transit CSE3 may include an identifier of the origin, an identifier of the Hosting CSE, and a Request Resource Creator parameter, at which the identifier of transit CSE3 is located. The request message of transit CSE3 is used for the Originator to request the target resource from the Hosting CSE.

The transit CSE3 sends a request message for the transit CSE3 to the Hosting CSE.

1110, the Hosting CSE processes the target resource and creates a < request3> resource.

And after receiving the request message of the transit CSE3 sent by the transit CSE3, the Hosting CSE starts to process the target resource. And, after receiving the request message of the transit CSE3 sent by the transit CSE3, the home CSE creates a < request3> resource.

1111, the Hosting CSE sends a reply message to the previous entity transit CSE 3.

The Hosting CSE sends a reply message to the transit CSE3 of the previous entity after creating the < request3> resource. The reply message sent by the Hosting CSE includes the Hosting CSE identifier, the identifier of the transit CSE3, and the address information of the < request3> resource created by the Hosting CSE.

The embodiment of the invention does not limit the address information of the < request3> resource. The address information of the < request3> resource may be a URI or an ID.

1112, transit CSE3 sends an acquire request message to the Hosting CSE.

After receiving the reply message sent by the home CSE, the transit CSE3 sends an acquisition request message to the home CSE. The get request message sent by the CSE3 includes an identifier of the transit CSE3 and address information of the < request3> resource created by the Hosting CSE.

1113, the Hosting CSE updates the < request3> resource created by the Hosting CSE itself.

After receiving the acquisition request message sent by the transit CSE3, the home CSE obtains a processing result of the target resource if the processing of the target resource is completed. The Hosting CSE saves the processing result of the target resource in the < request3> resource created by the Hosting CSE to update the < request3> resource.

1114, the Hosting CSE sends a reply message to the transit CSE 3.

After obtaining the processing result of the target resource, the Hosting CSE sends a reply message to the relay CSE3 of the previous choosing entity. The reply message sent by the Hosting CSE includes an identifier of the Hosting CSE, an identifier of the transit CSE3, and a result of processing the target resource. Sending the reply message by the Hosting CSE to the transit CSE3 includes sending the processing result for the target resource to the transit CSE 3.

1115, the transit CSE3 updates the < request2> resource created by the transit CSE3 itself according to the reply message sent by the Hosting CSE.

The transit CSE3 receives the processing result of the target resource after receiving the reply message sent by the home CSE. The relay CSE3 saves the processing result of the target resource in the < request2> resource created by itself to update the < request2> resource created by the relay CSE3 itself.

1116, transit CSE1 sends a get request message to transit CSE 2.

Transit CSE1 sends a get request message to the next entity transit CSE 2. The acquire request message sent by the transit CSE1 includes an identifier of the transit CSE1 and address information of the < request2> resource created by the transit CSE 3.

1117, the transit CSE2 forwards the acquire request message to the transit CSE 3.

1118, transit CSE3 sends a reply message to transit CSE 2.

After receiving the acquire request message sent by the transit CSE2, the transit CSE3 sends a reply message to the previous entity transit CSE 2. The reply message sent by transit CSE3 includes the identifier of transit CSE1, the identifier of transit CSE3, and the processing result for the target resource.

1119, transit CSE2 forwards the reply message to transit CSE 1.

After receiving the reply message sent by the transit CSE3, the transit CSE2 forwards the reply message to the transit CSE2 of the previous entity.

1120, the transit CSE1 updates the < request1> resource created by the transit CSE1 itself according to the reply message sent by the transit CSE 2.

The transit CSE1 receives the processing result of the target resource after receiving the reply message sent by the transit CSE 2. The relay CSE1 saves the processing result of the target resource in the < request1> resource created by itself to update the < request1> resource created by the relay CSE1 itself.

1121, Originator sends a get request message to transit CSE 1.

The Originator sends a get request message to the next entity transit CSE 1. The get request message sent by Originator includes the identifier of Originator and the address information of < request1> resource. The get request message sent by originor is used for the originor to request the transit CSE1 to get the processing result of the target resource.

1122, the transit CSE1 sends a reply message to the Originator.

After receiving the get request message sent by the last entity Originator, the transit CSE1 sends a reply message to the Originator. The reply message sent by the transit CSE1 includes the identifier of the transit CSE1, the identifier of the Originator, and the processing result for the target resource. The transit CSE1 sending a reply message to the Originator includes sending the results of the processing of the target resource to the Originator.

The Originator receives the reply message sent by the transit CSE1, that is, the processing result of the target resource sent by the transit CSE1, so as to complete the communication process that the Originator requests the destination resource from the Hosting CSE.

Example eleven:

fig. 12 is a schematic interaction flow diagram of a method of communication in the oneM2M system according to another embodiment of the invention. The embodiment of fig. 12 is exemplified by the case that no three transit CSEs create a < request > resource, but the Hosting CSE creates a < request > resource.

1201, the Originator sends a request message to the Hosting CSE, which the relay CSE1 receives.

The origin sends a request message to the Hosting CSE where the target resource is located, the request message carries the RT parameter, and when the RT parameter is set to 'nonBlockingRequestSynch', the request is communicated in a non-blocking synchronization mode. The request message is used by the Originator to request the Hosting CSE to operate on the target resource. The request message may include an identifier of the Originator, an identifier of the Hosting CSE where the target resource is located, and a request resource indication field. The request resource indication field is a default value. The Originator completes the registration at CSE1 and transit CSE1 may first receive the request message.

1202, transit CSE1 forwards the request message to transit CSE 2.

The Originator completes registration with the transit CSE1, and the transit CSE1 first receives the request message sent by the last entity Originator. The transit CSE1 may determine whether to create a < request > resource based on its own circumstances. When transit CSE1 determines that the < request > resource is not created, transit CSE1 forwards the request message to transit CSE 2.

1203, transit CSE2 forwards the request message to transit CSE 3.

Transit CSE2 receives the request message sent by last entity transit CSE 1. The transit CSE2 may also determine whether to create a < request > resource based on its own circumstances. When transit CSE2 determines that the < request > resource is not created, transit CSE2 forwards the request message to transit CSE 3.

1204, transit CSE3 forwards the request message to the Hosting CSE.

1205, the Hosting CSE processes the target resource and creates a < request > resource.

1206, the Hosting CSE sends a reply message to the transit CSE 3.

1207, transit CSE3 forwards the reply message to transit CSE 2.

1208, transit CSE2 forwards the reply message to transit CSE 1.

1209, transit CSE1 forwards the reply message to the Originator.

121O, Originator sends a get request message to transit CSE 1.

1211, the transit CSE1 forwards the get request message to the transit CSE 2.

At 912, transit CSE2 forwards the get request message to transit CSE 3.

1213, transit CSE3 forwards the get request message to the Hosting CSE.

1214, the Hosting CSE updates the < request > resource that the Hosting CSE itself created.

1215, the Hosting CSE sends a reply message to the transit CSE 3.

Transit CSE3 forwards the reply message to transit CSE2, 1216.

1217, transit CSE2 forwards the reply message to transit CSE 1.

1218, transit CSE1 forwards the reply message to the Originator.

Example twelve:

fig. 13 is a schematic interaction flow diagram of a method of communication in the oneM2M system according to another embodiment of the invention. The embodiment of fig. 13 will be exemplarily illustrated by an example in which the Originator sends a request message to the Hosting CSE, creates a < request > resource through three transit CSEs, transit CSE1 and transit CSE3, and transit CSE2 does not create the < request > resource.

1301, the Originator sends a request message to the Hosting CSE, and the relay CSE1 first receives the request message.

The origin sends a request message to the Hosting CSE where the target resource is located, the request message carries the RT parameter, and when the RT parameter is set to 'nonBlockingRequestSynch', the request is communicated in a non-blocking synchronization mode. The request message sent by the Originator is used for requesting the Hosting CSE to operate on the target resource by the Originator. The request message sent by Originator includes an identifier of Originator, an identifier of the Hosting CSE where the target resource is located, and a request resource creator request resource indication field. The request resource indication field is a default value. The Originator completes the registration at CSE1 and transit CSE1 may first receive the request message.

1302, the transit CSE1 creates a < request > resource.

1303, transit CSE1 sends a reply message to Originator.

At 1304, the transit CSE1 generates a request message of the transit CSE1 and sends the request message of the transit CSE1 to the next entity transit CSE 2.

Transit CSE1 may set the request resource indication field to the identifier of transit CSE1, i.e., may generate a request message for transit CSE 1. The request message of the transit CSE1 includes an identifier of the Originator, an identifier of the Hosting CSE, and a request resource indication field, and the identifier of the transit CSE1 is located in the request resource indication field. After generating the request message of the transit CSE1, the transit CSE1 sends the request message of the transit CSE1 to the next entity transit CSE 2. The request message of transit CSE1 is used to request acquisition of the processing result for the target resource to the Hosting CSE.

1305, transit CSE2 forwards the request message of transit CSE1 to the next entity transit CSE 3.

1306, transit CSE3 creates a < request2> resource.

1307, transit CSE3 sends a reply message to the previous entity transit CSE 2.

1308, transit CSE2 forwards the reply message to transit CSE 1.

1309, the transit CSE3 generates a request message and sends the request message to the Hosting CSE.

Setting the request resource indication field to the identifier of transit CSE3 may generate a request message for transit CSE 3. The request message of the transit CSE3 may include an identifier of the Originator, an identifier of the Hosting transit CSE, and a request resource indication field, with the identifier of the transit CSE3 located in the request resource indication field. After the transit CSE3 generates the request message of the transit CSE3, it sends the request message of the transit CSE3 to the next entity Hosting transit CSE. The request message of transit CSE3 is used to request acquisition of the processing result for the target resource to the Hosting CSE.

131O, the Hosting CSE processes the target resource and creates a < request3> resource.

1311, the Hosting CSE sends a reply message to the previous entity transit CSE 3.

1312, the transit CSE3 sends a get request message to the Hosting CSE.

After receiving the reply message sent by the home CSE, the transit CSE3 sends an acquisition request message to the home CSE. The get request message sent by the transit CSE3 includes an identifier of the transit CSE3 and address information of the < request3> resource created by the Hosting CSE.

1313, the Hosting CSE updates the < request3> resource created by the Hosting CSE itself.

1114, the Hosting CSE sends a reply message to the transit CSE 3.

After obtaining the processing result of the target resource, the Hosting CSE sends a reply message to the relay CSE3 of the previous choosing entity. The reply message sent by the Hosting CSE includes an identifier of the Hosting CSE, an identifier of CSE3, and a result of processing the target resource. Sending the reply message by the Hosting CSE to the transit CSE3 includes sending the processing result for the target resource to the transit CSE 3.

1315, the transit CSE3 updates the < request2> resource created by the transit CSE3 itself according to the reply message sent by the Hosting CSE.

1316, transit CSE1 sends a get request message to transit CSE 2.

1317, transit CSE2 forwards the get request message to transit CSE 3.

1318, transit CSE3 sends a reply message to transit CSE 2.

1319, transit CSE2 forwards the reply message to transit CSE 1.

1320, the transit CSE1 updates the < request1> resource created by the transit CSE1 itself according to the reply message sent by the transit CSE 2.

The transit CSE1 receives the processing result of the target resource after receiving the reply message sent by the transit CSE 2. The transit CSE1 saves the processing result for the target resource in the < request1> resource created by itself to update the < request1> resource created by the transit CSE1 itself.

1321, the Originator sends a get request message to the transit CSE 1.

1322, transit CSE1 sends a reply message to Originator.

Example thirteen:

the embodiment of fig. 14 will send a request message to the Hosting CSE by the Originator, create the < request > resource through three transit CSEs, transit CSE1 skips transit CSE2 that does not create the < request > resource when transit CSE2 does not create the < request > resource, and establish communication between transit CSE1 and transit CSE3 to complete the process of the Originator requesting the Hosting CSE to operate on the target resource.

1401, the Originator sends a request message to the Hosting CSE, which the relay CSE1 first receives.

The origin sends a request message to the Hosting CSE where the target resource is located, the request message carries the RT parameter, and when the RT parameter is set to 'nonBlockingRequestSynch', the request is communicated in a non-blocking synchronization mode. The request message is used by the Originator to request the Hosting CSE to operate on the target resource. The request message includes an identifier of the Originator, an identifier of the Hosting CSE where the target resource is located. The Originator completes registration with the transit CSE1 and the transit CSE1 first receives the request message.

1402, the transit CSE1 creates a < request > resource.

The Originator completes registration in the transit CSE1, and the transit CSE1 first receives the request message sent by the last entity Originator. The transit CSE1 may determine whether to create a < request > resource based on its own circumstances. For example, when the transit CSE1 supports creation of a < request > resource, the transit CSE1 creates a < request1> resource.

1403, transit CSE1 sends a reply message to Originator.

After the transit CSE1 creates the < request1> resource, it sends a reply message to the previous entity Originator. The reply message sent by the transit CSE1 to the Originator includes the identifier of the transit CSE1, the identifier of the Originator, and the address information of the < request1> resource created by the transit CSE 1. The reply message sent by the transit CSE1 to the Originator is used to send the address information of the < request1> resource created by the transit CSE1 to the Originator, so that the Originator sends a get request message to the transit CSE1 to get the processing result of the target resource.

1404, transit CSE1 sends a request message to the next entity transit CSE 2.

Transit CSE1 sends a request message to the next entity transit CSE2 after creating the < request1> resource. The request message sent by the transit CSE1 to the next entity transit CSE2 is used to request the acquisition of the processing result of the target resource to the Hosting CSE. The request message includes an identifier of the Originator, an identifier of the Hosting CSE where the target resource is located. Here, the request message sent by the transit CSE1 to the next entity transit CSE2 is the same as the request message sent by the Originator to the Hosting CSE.

1405, transit CSE2 determines not to create a < request > resource.

After receiving the request message sent by the transit CSE1, the transit CSE2 may determine whether to create the < request > resource according to its own condition. For example, transit CSE2 does not support a < request > resource type, then transit CSE2 determines that a < request > resource is not to be created.

1406, transit CSE2 sends indication information to transit CSE 1.

When transit CSE2 determines that the < request > resource is not created, an indication message is sent to the previous entity transit CSE 1. The indication message sent by the transit CSE2 to the transit CSE1 includes an identifier of the transit CSE1, an identifier of the transit CSE2, and a Request resource Not Create Request Not Create parameter, which includes an identifier of the transit CSE 3. The indication message sent by the transit CSE2 to the transit CSE1 is used to instruct the previous entity transit CSE1 to send the request message to the next entity transit CSE3, so as to bypass the process of not creating the < request > resource transit CSE2 and continuing to execute the Originator to request the Hosting CSE to operate the target resource.

1407, the transit CSE1 deregisters the registration information on the transit CSE2 and registers to the transit CSE 3.

After receiving the indication information sent by the transit CSE2, the transit CSE1 deregisters the registration information on the transit CSE2, registers the registration information on the transit CSE3, and establishes communication between the transit CSE1 and the transit CSE 3.

1408, transit CSE1 sends a request message to transit CSE 3.

Transit CSE1 sends a request message to transit CSE3 after completing registration with transit CSE 3. Transit CSE1 transmits the request message to transit CSE 3. The relay CSE1 sends the request message to the relay CSE3 including an identifier of the Originator, an identifier of the Hosting CSE where the target resource is located. Here, the request message sent by the transit CSE1 to the transit CSE3 is the same as the request message sent by the Originator to the Hosting CSE.

1409, the transit CSE3 creates a < request2> resource.

After receiving the request message sent by the transit CSE1, the transit CSE3 may determine whether to create the < request > resource according to its own condition. The transit CSE3 may create a < request2> resource.

1410, transit CSE3 sends a reply message to transit CSE 1.

When transit CSE3 determines to create a < request2> resource, transit CSE3 sends a reply message to transit CSE 1. The reply message sent by transit CSE3 to transit CSE1 includes the identifier of transit CSE3, the identifier of transit CSE1, and the address information of the < request2> resource created by transit CSE 3.

1411, the transit CSE3 sends a request message to the Hosting CSE.

The transit CSE3 sends a request message to the next entity, the home CSE. The request message sent by the transit CSE3 is used to request to obtain the processing result of the target resource from the Hosting CSE. The transit CSE3 sends a request message to the next entity, the Hosting CSE, after determining that the < request2> resource was created. The request message sent by the transit CSE3 includes an identifier of the Originator, an identifier of the Hosting CSE where the target resource is located. Here, the request message sent by the transit CSE3 to the Hosting CSE, the request message sent by the Originator to the Hosting CSE, and the request message sent by the transit CSE1 to the transit CSE3 are all the same.

1412, the Hosting CSE processes the target resource and creates a < request3> resource.

And after receiving the request message sent by the transit CSE3, the Hosting CSE starts to process the target resource. And, after receiving the request message sent by the transit CSE3, the Hosting CSE creates a < request3> resource.

1413, the Hosting CSE sends a reply message to the transit CSE 3.

After creating < request3> resource, the Hosting CSE sends a reply message to the transit CSE 3. The Hosting CSE sends a reply message to the Hosting CSE3 including an identifier of the Hosting CSE3, an identifier of the Hosting CSE, and address information of the < request3> resource created by the Hosting CSE.

1414, the Hosting CSE updates the < request3> resource it created.

And if the Hosting CSE finishes the processing of the target resource, obtaining a processing result of the target resource. Then, the processing result for the target resource is saved in the < request3> resource created by itself to update the < request3> resource.

1415, the CSE3 sends a get request message to the Hosting CSE.

The CSE3 sends a get request message to the next entity, the Hosting CSE. The acquire request message sent by the transit CSE3 includes an identifier of the transit CSE3 and address information of the < request3> resource. The acquisition request message sent by the transit CSE3 is used to request acquisition of the processing result of the target resource to the Hosting CSE.

1416, the Hosting CSE sends a reply message to the transit CSE 3.

After receiving the acquisition request message sent by the transit CSE3, the Hosting CSE sends a reply message to the transit CSE3 according to the acquisition request message. The reply message sent by the Hosting CSE includes an identifier of the Hosting CSE, an identifier of the transit CSE3, and a result of processing the target resource. Sending the reply message by the Hosting CSE to CSE3 includes sending the results of the processing of the target resource to the transit CSE 3.

1417, the transit CSE3 updates the < request2> resource.

After receiving the reply message sent by the Hosting CSE, the transit CSE3 saves the processing result of the target resource in the < request2> resource to update the < request2> resource created by itself.

1418, transit CSE1 sends a get request message to transit CSE 3.

Transit CSE1 sends a get request message to transit CSE 3. The acquire request message sent by the transit CSE1 includes an identifier of the transit CSE1 and address information of the < request2> resource. The acquisition request message sent by the transit CSE1 is used to request acquisition of the processing result of the target resource to the transit CSE 3.

1419, transit CSE3 sends a reply message to transit CSE 1.

After receiving the acquisition request message sent by the transit CSE1, the transit CSE3 sends a reply message to the transit CSE1 according to the acquisition request message. The reply message sent by the transit CSE3 includes an identifier of the Hosting CSE, an identifier of the transit CSE3, and a result of processing the target resource. Sending the reply message by the Hosting CSE to the transit CSE3 includes sending the processing result for the target resource to the transit CSE 3.

1420, transit CSE1 updates the < request1> resource.

After receiving the reply message sent by the transit CSE3, the transit CSE1 saves the processing result of the target resource in the < request1> resource to update the < request1> resource created by itself.

1421, the Originator sends a get request message to the transit CSE 1.

The Originator sends a get request message to the transit CSE 1. The get request message sent by Originator includes identifier of Originator and address information of < request1> resource. The get request message sent by the Originator is used to request to get the processing result of the target resource to the transit CSE 1.

1422, transit CSE1 sends a reply message to Originator.

After receiving the get request message sent by the Originator, the transit CSE1 sends a reply message to the Originator according to the get request message. The reply message sent by transit CSE1 includes the identifier of transit CSE3, the identifier of transit CSE1, and the processing result for the target resource. The transit CSE1 sending a reply message to the Originator includes sending the results of the processing of the target resource to the Originator.

The embodiment of fig. 15 will send a request message to the home CSE by Originator, and when the transit CSE passes through two transit CSEs, and creates a < request > resource in both transit CSEs 1 and 2, and the home CSE does not create a < request > resource, the home CSE processes the target resource after receiving the request message, and resends the request message based on the transit CSE2 when obtaining the processing result of the target resource, and returns the processing result of the target resource to the transit CSE2, so as to complete the process of Originator requesting the home CSE to operate the target resource.

Example fourteen:

1501, the Originator sends a request message to the Hosting CSE, which the transit CSE1 first receives.

The origin sends a request message to the Hosting CSE where the target resource is located, the request message carries the RT parameter, and when the RT parameter is set to 'nonBlockingRequestSynch', the request is communicated in a non-blocking synchronization mode. The request message is used by the Originator to request the Hosting CSE to operate on the target resource. The request message includes an identifier of the Originator, an identifier of the Hosting CSE where the target resource is located. The Originator completes registration with transit CSE1 and transit CSE1 first receives the request message.

1502, transit CSE1 creates a < request > resource.

1503, transit CSE1 sends a reply message to the Originator.

1504, the transit CSE1 sends a request message to the next entity transit CSE 2.

Transit CSE1 sends a request message to the next entity transit CSE2 after creating the < request1> resource. The request message sent by the transit CSE1 to the next entity transit CSE2 is used to request the acquisition of the processing result of the target resource to the Hosting CSE. The relay CSE1 sends the request message to the relay CSE2 including an identifier of the Originator, an identifier of the Hosting CSE where the target resource is located. Here, the request message sent by the transit CSE1 to the next entity transit CSE2 is the same as the request message sent by the Originator to the Hosting CSE.

1505, the transit CSE2 creates a < request2> resource.

The transit CSE2 determines whether to create a < request > resource based on its own circumstances. The transit CSE2 may create a < request2> resource.

1506, transit CSE2 sends a reply message to transit CSE 1.

Transit CSE2 sends a reply message to transit CSE1 after creating the < request2> resource. The reply message sent by transit CSE2 to transit CSE1 includes the identifier of transit CSE2, the identifier of transit CSE1, and the address information of the < request2> resource created by transit CSE 2. The reply message sent by the transit CSE2 to the transit CSE1 includes address information of < request2> resource created by the transit CSE2 sent by the transit CSE2 to the transit CSE1, so that the Originator sends a get request message to the transit CSE1 to get the processing result of the target resource.

1507, the transit CSE2 sends a request message to the next entity, the Hosting CSE.

The CSE2 sends a request message to the next entity, the Hosting CSE. The request message sent by the transit CSE2 is used to request to obtain the processing result of the target resource from the Hosting CSE. The transit CSE2 sends a request message to the next entity, the Hosting CSE, after creating the < request2> resource. The request message sent by the transit CSE2 to the Hosting CSE includes an identifier of the origin, and an identifier of the Hosting CSE where the target resource is located.

1508, the Hosting CSE processes the target resource and does not create a < request > resource.

And after receiving the request message sent by the transit CSE2, the Hosting CSE starts to process the target resource. And, the Hosting CSE can determine whether to create the < request > resource according to the self condition. The Hosting CSE determines that < request > resources may not be created.

1509, the Hosting CSE sends an indication message to the transit CSE 2.

The Hosting CSE sends an indication message to the previous entity transit CSE2 after determining that the < request > resource is not created. The indication message sent by the home CSE to transit CSE2 includes an identifier of the home CSE, an identifier of transit CSE2, and a Request resource Not Create Request Not Create parameter. The indication message is used to request the transit CSE2 to resend the request message to the Hosting CSE after a period of time T. The transit CSE2 resends the Request message at a time when the Request resource does Not Create the Request Not Create parameter. T may be determined based on the time that the Hosting CSE expects to take to complete processing of the target resource. For example, T may be greater than the time that the Hosting CSE expects to be needed to complete processing of the target resource.

1510, the Hosting CSE completes processing of the target resource.

The Hosting CSE starts processing the target resource when receiving the request message sent by the transit CSE 2. After a period of time, the Hosting CSE completes the processing of the target resource and obtains the processing result of the target resource. In this way, when the Hosting CSE does not support creating the < request > resource, the process of the Originator requesting the Hosting CSE to operate the target resource can be continuously executed.

1511, the transit CSE2 resends the request message to the Hosting CSE.

The CSE2 resends the request message to the Hosting CSE after sending the request message to the Hosting CSE for a period of time T.

The request message also includes a first parameter carrying an ID of < request >. The Hosting CSE can judge whether the request message is the same through the first parameter. For example, when the first parameter of the ID of < request > carried in the retransmitted request message is the same as the first parameter included in the request message received by the home CSE for the first time, the home CSE may determine that the request message is the same.

1512, the Hosting CSE sends the processing result for the target resource to the transit CSE 2.

Step 1510, the Hosting CSE processes the target resource, and after the processing is completed, a processing result of the target resource is obtained. The Hosting CSE sends the results of the processing of the target resource to an upper entity CSE 2.

Here, in step 1511, when the requesting message is received by the home CSE and the same requesting message is determined, the result of processing the target resource may be sent to the relay CSE2 directly after the processing of the target resource is completed, and the relay CSE2 is no longer required to send the acquisition requesting message to the home CSE.

1513, the transit CSE2 updates the < request2> resource it created.

After receiving the processing result of the target resource sent by the Hosting CSE, the transit CSE2 stores the processing result of the target resource in the < request2> resource created by itself, so as to update the < request2> resource.

1514, transit CSE1 sends a get request message to transit CSE 2.

Transit CSE1 sends a get request message to transit CSE 2. The acquire request message sent by transit CSE1 to transit CSE2 includes an identifier of transit CSE1 and address information of < request2> resource.

1515, transit CSE2 sends a reply message to transit CSE 1.

After receiving the acquisition request message sent by the transit CSE1, the transit CSE2 sends a reply message to the transit CSE1 according to the updated < request2> resource. The reply message sent by transit CSE2 to transit CSE1 may include an identifier of transit CSE2, an identifier of transit CSE1, and a result of processing the target resource.

1516, the transit CSE1 updates the < request1> resource it created.

After receiving the reply message sent by the transit CSE2, that is, after receiving the processing result of the target resource sent by the transit CSE2, the transit CSE1 stores the processing result of the target resource in the < request1> resource created by itself, so as to update the < request1> resource.

1517, the Originator sends a get request message to the transit CSE 1.

The Originator sends a get request message to the next entity transit CSE 1. The get request message that the Originator sends to the transit CSE1 may include an identifier of the Originator and address information of < request1> resource. The get request message sent by the Originator to the transit CSE1 is used to request the processing result of the target resource from the transit CSE 1.

1518, transit CSE1 sends a reply message to Originator.

The transit CSE1 sends a reply message to Originator after receiving the get request message sent by Originator. The reply message sent by transit CSE1 to the Originator may include an identifier of the Originator, an identifier of transit CSE1, and the results of the processing of the target resource.

The Originator receives the reply message sent by the transit CSE1, namely, receives the processing result of the target resource. This completes the whole communication process of Originator requesting target resource from the Hosting CSE.

The method, process and interaction of communication in the M2M system according to the embodiment of the present invention are described in detail above with reference to fig. 2 to 15, and the apparatus of communication in the M2M system according to the embodiment of the present invention is described in detail below with reference to fig. 16 to 29.

Example fifteen:

fig. 16 is a schematic block diagram of a device communicating in the oneM2M system according to an embodiment of the present invention. The apparatus 160 of fig. 16 may be a transit CSE, and includes a first receiving unit 1601 and a first transmitting unit 1602.

The first receiving unit 1601 is configured to receive a first request message in a non-blocking synchronous communication mode sent by a previous entity. The first Request message includes a Request Resource Creator parameter. The Request Resource Creator parameter is a default value or an identifier of the last entity that created the Request < Request > Resource for the first Request message. The first request message is used for the Originator to request the Hosting CSE where the target resource is located to operate on the target resource.

The first sending unit 1602 is configured to send the first request message to the next entity when the < request > resource is not created for the first request message received by the first receiving unit.

Optionally, as an embodiment, the apparatus 160 further includes a second receiving unit and a second transmitting unit. The second receiving unit is used for receiving a first reply message sent by a next entity. The first reply message includes address information of a < request > resource created by the entity that creates the < request > resource next to the first request message. The second sending unit sends the first reply message to the last entity.

Optionally, as an embodiment, the apparatus 160 further includes a third receiving unit and a third transmitting unit. The third receiving unit is configured to receive a first get request message sent by a previous entity. The first get request message includes address information of a < request > resource created by an entity that creates the < request > resource next to the first request message. The first get request message is used to request the next entity creating < request > resource to get the processing result of the target resource. The third sending unit is configured to send the first get request message to a next entity.

Optionally, as an embodiment, the apparatus 160 further includes a fourth receiving unit and a fourth transmitting unit. The fourth receiving unit is configured to receive a second reply message sent by a next entity. The second reply message includes a result of the processing of the target resource. The fourth sending unit is configured to send the second reply message to the previous entity.

Optionally, as an embodiment, the apparatus 160 further includes a determination unit. The determination unit is configured to determine whether to create a < request > resource for the first request message.

Optionally, as an embodiment, the determining unit is specifically configured to determine whether to create a < request > resource for the first request message according to the capacity and/or the supported < request > resource type.

Optionally, as an embodiment, the apparatus 160 further includes a creating unit, a fifth transmitting unit, a generating unit, and a sixth transmitting unit. The creating unit is configured to create a < request > resource when it is determined that the < request > resource is created for the first request message. The fifth sending unit is configured to send the third reply message to the previous entity. The third reply message includes address information of the created < request > resource. The generating unit is used for generating a second request message. The second Request message includes a Request Resource Creator parameter. The Request Resource Creator parameter is set to the identifier of the transit CSE. The sixth sending unit is configured to send the second request message to the next entity.

Optionally, as an embodiment, the apparatus 160 further includes a fifth receiving unit, an updating unit, a sixth receiving unit, and a seventh transmitting unit. The fifth receiving unit is configured to receive a fourth reply message sent by a next entity. The fourth reply message includes a result of the processing of the target resource. The updating unit is configured to update the < request > resource created by the transit CSE according to the fourth reply message. The sixth receiving unit is configured to receive a second get request message sent by a previous entity. The second acquire request message includes address information of the created < request > resource. The second obtaining request message is used for the last entity to request the transit CSE to obtain the processing result of the target resource. The seventh sending unit is configured to send the fifth reply message to the previous entity. The fifth reply message includes a result of the processing of the target resource.

The apparatus for communication in the M2M system according to the embodiment of the present invention may correspond to the method for communication in the M2M system according to the embodiment of the present invention, and each unit/module in the apparatus and the other operations and/or functions described above are not described again for brevity, in order to implement the corresponding flow of the method shown in fig. 2 and the corresponding flow of the relevant CSE in the methods shown in fig. 9, fig. 10, and fig. 11, respectively.

Example sixteen:

fig. 17 is a schematic block diagram of a device for communication in the oneM2M system according to another embodiment of the present invention. The apparatus 170 of fig. 17 includes a receiving unit 1701, a generating unit 1702, an updating unit 1703, and a transmitting unit 1704.

The first receiving unit 1701 is configured to receive a first request message in the non-blocking synchronous communication mode sent by a previous entity. The first request message is used for the initiation entity Originator to request the Hosting general service entity Hosting CSE where the target resource is located to operate the target resource.

The first generating unit 1702 is configured to generate a Request Resource Creator parameter when a Request < Request > Resource is not created for the first Request message. Wherein the Request Resource Creator parameter is set to a default value or an identifier of an entity that last created the Request < Request > Resource for the first Request message.

The second generating unit 1703 is configured to generate a second Request message, where the second Request message includes the Request Resource Creator parameter.

The first sending unit 1704 is configured to send the second request message to the next entity.

Optionally, as an embodiment, the apparatus further includes a second receiving unit and a second sending unit. The second receiving unit is used for receiving a first reply message sent by a next entity. The first reply message includes address information of a < request > resource created by the entity that creates the < request > resource next to the first request message. The second sending unit is configured to send the first reply message to the previous entity.

Optionally, as an embodiment, the apparatus 170 further includes a third receiving unit and a third sending unit. The third receiving unit is configured to receive a first get request message sent by a previous entity. The first get request message includes address information of a < request > resource created by an entity that creates the < request > resource next to the first request message. The first get request message is used to request the next entity creating < request > resource to get the processing result of the target resource. The third sending unit is configured to send the first get request message to a next entity.

Optionally, as an embodiment, the apparatus 170 further includes a fourth receiving unit and a fourth sending unit. The fourth receiving unit is configured to receive a second reply message sent by a next entity. The second reply message includes a result of the processing of the target resource. The fourth sending unit is configured to send the second reply message to the previous entity.

Optionally, as an embodiment, the apparatus 170 further includes a determination unit. The determination unit is configured to determine whether to create a < request > resource for the first request message.

Optionally, as an embodiment, the apparatus 170 further includes a creating unit, a fifth transmitting unit, a third generating unit, and a sixth transmitting unit. The creating unit is configured to create a < request > resource when it is determined that the < request > resource is created for the first request message. The fifth sending unit is configured to send the third reply message to the previous entity. The third reply message includes address information of the created < request > resource. The third generating unit is used for generating a third request message. The third Request message includes a Request Resource Creator parameter. The Request Resource Creator parameter is set to the identifier of the transit CSE. The sixth sending unit is configured to send the third request message to the next entity.

Optionally, as an embodiment, the apparatus 170 further includes a fifth receiving unit, an updating unit, a sixth receiving unit, and a seventh sending unit. The fifth receiving unit is configured to receive a fourth reply message sent by a next entity. The fourth reply message includes a result of the processing of the target resource. The updating unit is configured to update the < request > resource created by the transit CSE according to the fourth reply message. The sixth receiving unit is configured to receive a second get request message sent by a previous entity. The second acquire request message includes address information of the created < request > resource. The second obtaining request message is used for the last entity to request the transit CSE to obtain the processing result of the target resource. The seventh sending unit is configured to send the fifth reply message to the previous entity. The fifth reply message includes a result of the processing of the target resource. The apparatus for communication in the M2M system according to the embodiment of the present invention may correspond to the method for communication in the M2M system according to the embodiment of the present invention, and each unit/module in the apparatus and the other operations and/or functions described above are respectively for implementing a corresponding flow of the relevant CSE in the method shown in fig. 3, and are not described herein again for brevity.

Example seventeen:

fig. 18 is a schematic block diagram of a device communicating in the oneM2M system according to another embodiment of the present invention. The apparatus 180 of fig. 18 includes a receiving unit 1801 and a transmitting unit 1802.

The first receiving unit 1801 is configured to receive a first request message in the non-blocking synchronous communication mode sent by a previous entity. The response type RT parameter carried by the first request message includes a request resource indication field. The request resource indication field is a default value or an identifier of an entity that has last created a request < request > resource for the first request message. The first request message is used for the initiation entity Originator to request the Hosting general service entity Hosting CSE where the target resource is located to operate the target resource.

The first sending unit 1802 is configured to send a first request message to a next entity when a request < request > resource is not created for the first request message.

Optionally, as an embodiment, the apparatus 180 further includes a second receiving unit and a second sending unit. The second receiving unit is used for receiving a first reply message sent by a next entity. The first reply message includes address information of a < request > resource created by the entity that creates the < request > resource next to the first request message. The second sending unit sends the first reply message to the last entity.

Optionally, as an embodiment, the apparatus 180 further includes a third receiving unit and a third sending unit. The third receiving unit is configured to receive a first get request message sent by a previous entity. The first get request message includes address information of a < request > resource created by an entity that creates the < request > resource next to the first request message. The first get request message is used to request the next entity creating < request > resource to get the processing result of the target resource. The third sending unit is configured to send the first get request message to a next entity.

Optionally, as an embodiment, the apparatus 180 further includes a fourth receiving unit and a fourth sending unit. The fourth receiving unit is configured to receive a second reply message sent by a next entity. The second reply message includes a result of the processing of the target resource. The fourth sending unit is configured to send the second reply message to the previous entity.

Optionally, as an embodiment, the apparatus 180 further includes a determination unit. The determination unit is configured to determine whether to create a < request > resource for the first request message.

Optionally, as an embodiment, the apparatus 180 further includes a creating unit, a fifth transmitting unit, a generating unit, and a sixth transmitting unit. The creating unit is configured to create a < request > resource when it is determined that the < request > resource is created for the first request message. The fifth sending unit is configured to send the third reply message to the previous entity. The third reply message includes address information of the created < request > resource. The generating unit is used for generating a second request message. The second request message includes a request resource indication field. The request resource indication field is set to the identifier of the transit CSE. The sixth sending unit is configured to send the second request message to the next entity.

Optionally, as an embodiment, the apparatus 180 further includes a fifth receiving unit, an updating unit, a sixth receiving unit, and a seventh sending unit. The fifth receiving unit is configured to receive a fourth reply message sent by a next entity. The fourth reply message includes a result of the processing of the target resource. The updating unit is configured to update the < request > resource created by the transit CSE according to the fourth reply message. The sixth receiving unit is configured to receive a second get request message sent by a previous entity. The second acquire request message includes address information of the created < request > resource. The second obtaining request message is used for the last entity to request the transit CSE to obtain the processing result of the target resource. The seventh sending unit is configured to send the fifth reply message to the previous entity. The fifth reply message includes a result of the processing of the target resource.

The apparatus for communication in the M2M system according to the embodiment of the present invention may correspond to the method for communication in the M2M system according to the embodiment of the present invention, and each unit/module in the apparatus and the other operations and/or functions described above are respectively for implementing the corresponding flow of the method shown in fig. 4 and the corresponding flow of the relevant CSE in the method shown in fig. 13, and are not described again here for brevity.

Example eighteen:

fig. 19 is a schematic block diagram of a device communicating in the oneM2M system according to another embodiment of the present invention. The apparatus 190 of fig. 19 includes a receiving unit 1901 and a transmitting unit 1902.

The receiving unit 1901 is configured to receive a request message in the non-blocking synchronous communication mode sent by a previous entity. The first request message is used for the initiation entity Originator to request the Hosting general service entity Hosting CSE where the target resource is located to operate the target resource.

The transmitting unit 1902 is configured to transmit an indication message to an upper entity when a < request > resource is not created for a request message received by the first receiving unit. The indication message includes a Request Not to Create Request Not Create parameter. The Request Not Create parameter includes an identifier of the next entity. The indication message is used to instruct the previous entity to send a request message to the next entity.

Optionally, as an embodiment, the apparatus further includes a determination unit. The determination unit is configured to determine whether to create a < request > resource for the request message.

Optionally, as an embodiment, the determining unit is specifically configured to determine whether to create a < request > resource for the request message according to the capacity and/or the supported < request > resource type.

The apparatus for communication in the M2M system according to the embodiment of the present invention may correspond to the method for communication in the M2M system according to the embodiment of the present invention, and each unit/module in the apparatus and the other operations and/or functions described above are respectively for implementing the corresponding flow of the relevant transit CSE in the method shown in fig. 5 and the method shown in fig. 14, and are not described again here for brevity.

Example nineteenth:

fig. 20 is a schematic block diagram of a device communicating in the oneM2M system according to still another embodiment of the present invention. The apparatus 200 of fig. 20 includes a first transmission unit 2001, a reception unit 2002, and a second transmission unit 2003.

The first sending unit 2001 is configured to send a request message in the non-blocking synchronous communication mode to the next entity, where the request message is used to initiate the entity Originator to request the Hosting generic service entity Hosting CSE where the target resource is located to operate the target resource.

The first receiving unit 2002 is configured to receive an indication message sent by a next entity. The indication message includes a Request Not to Create Request Not Create parameter. The Request Not Create parameter includes an identifier of the first entity. The indication message is used for indicating the local entity to send the request message to the first entity.

The second sending unit 2003 is configured to send a request message to the first entity.

The request message may include an identifier of the initiator and an identifier of the Hosting CSE where the target resource is located. The request message is used for the Originator to request the Hosting CSE to operate on the target resource.

The indication message may include an identifier of the Hosting CSE, an identifier of the transit CSE, and a Request Not Create parameter. The time for the transit CSE to resend the Request message is located when the Request resource does Not Create the Request Not Create parameter.

Optionally, as an embodiment, the apparatus 200 further includes: the second sending unit is used for resending the request message to the Hosting CSE. The second receiving unit is used for receiving the reply message sent by the Hosting CSE. The reply message includes an identifier of the Hosting CSE, an identifier of the Originator, and a result of the processing of the target resource.

The apparatus for communication in the oneM2M system according to the embodiment of the present invention may correspond to the method for communication in the oneM2M system according to the embodiment of the present invention, and each unit/module in the apparatus and the other operations and/or functions described above are respectively for implementing the corresponding flow of the relevant transit CSE in the method shown in fig. 6 and the method shown in fig. 14, and are not described herein again for brevity.

Example twenty:

fig. 21 is a schematic block diagram of a device for communication in the oneM2M system according to still another embodiment of the present invention. The apparatus 210 of fig. 21 includes a first receiving unit 2101 and a first transmitting unit 2102.

The first receiving unit 2101 is configured to receive a request message in the non-blocking synchronous communication mode sent by the transit CSE. The request message is used for the Originator to request the operation on the target resource.

The first sending unit 2102 is configured to send indication information to the relay CSE according to the request message when the request < request > resource is not created for the request message received by the unit. The indication information is used to indicate the transit CSE to resend the request message after the first time period.

Optionally, as an embodiment, the apparatus 210 further includes a processing unit. The processing unit is used for processing the target resource according to the request message to obtain a processing result of the target resource.

Optionally, as an embodiment, the apparatus 210 further includes a second receiving unit and a second sending unit. The second receiving unit is used for receiving the request message retransmitted by the transit CSE. The second sending unit is configured to send a reply message to the transit CSE. The reply message includes the processing result for the target resource.

Optionally, as an embodiment, the apparatus 60 further includes a third sending unit or further includes a discarding unit and a third receiving unit. The third sending unit is configured to resend the indication message to the transit CSE when the target resource is not processed after the first duration. Or, the discarding unit is configured to discard the processing result of the target resource when the request message sent by the transit CSE is not received after the second duration. The third receiving unit is configured to receive, after the third duration, the request message sent again by the transit CSE.

The apparatus for communication in the oneM2M system according to the embodiment of the present invention may correspond to the method for communication in the oneM2M system according to the embodiment of the present invention, and each unit/module in the apparatus and the other operations and/or functions described above are not described herein again for brevity in order to implement the corresponding flow of the relevant hotting CSE in the method shown in fig. 7 and the method shown in fig. 15, respectively.

Example twenty one:

fig. 22 is a schematic block diagram of a device for communication in the oneM2M system according to still another embodiment of the present invention. The apparatus 220 of fig. 22 comprises a first transmitting unit 2201 and a first receiving unit 2202.

The first sending unit 2201 is configured to send a request message in the non-blocking synchronous communication mode to the Hosting CSE. The request message is used for the Originator to request the Hosting CSE to operate on the target resource.

The first receiving unit 2202 is configured to receive indication information sent by the Hosting CSE according to the request message. The indication message is used for indicating that the request message is retransmitted after the first time length of the transit CSE.

Optionally, as an embodiment, the apparatus 220 further includes a second sending unit and a second receiving unit. The second sending unit is used for resending the request message to the Hosting CSE. The second receiving unit is used for receiving the reply message sent by the Hosting CSE. The reply message includes the processing result for the target resource.

Optionally, as an embodiment, the apparatus 220 further includes a third receiving unit and a third transmitting unit. The third receiving unit is configured to receive, after the first duration, an indication message retransmitted by the Hosting CSE. Or, the third sending unit is configured to send the request message to the Hosting CSE again after the third duration.

The apparatus for communication in the M2M system according to the embodiment of the present invention may correspond to the method for communication in the M2M system according to the embodiment of the present invention, and each unit/module in the apparatus and the other operations and/or functions described above are respectively for implementing the corresponding flow of the method shown in fig. 8 and the corresponding flow of the relevant CSE in the method shown in fig. 15, and are not described again here for brevity.

Example twenty two:

fig. 23 is a schematic block diagram of a device communicating in the oneM2M system according to an embodiment of the present invention. The apparatus 230 of fig. 23 comprises a transmitter 2301, a receiver 2302, a processor 2303 and a memory 2304. The various components of the device 230 are coupled together by a bus system 2305.

A schematic block diagram of the transit CSE of embodiment one may be as in the block diagram of fig. 23.

Specifically, the receiver 2302 can receive a first request message in a non-blocking synchronous communication mode sent by a previous entity. The first Request message includes a Request Resource Creator parameter. The first request message is used for the initiation entity Originator to request the Hosting general service entity Hosting CSE where the target resource is located to operate the target resource. The Request Resource Creator parameter is a default value or an identifier of the last entity that created the Request < Request > Resource for the first Request message.

The transmitter 2301 may be configured to transmit the first request message to a next entity when the < request > resource is not created for the first request message received by the first receiving unit.

Optionally, as an embodiment, the receiver 2302 may be configured to receive a first reply message sent by a next entity. The first reply message includes address information of a < request > resource created by the entity that creates the < request > resource next to the first request message. A transmitter 2301 may be configured to send the first reply message to the last entity.

Optionally, as an embodiment, the receiver 2302 may be configured to receive a first acquisition request message sent by a last entity. The first get request message includes address information of a < request > resource created by an entity that creates the < request > resource next to the first request message. The first get request message is used to request the next entity creating < request > resource to get the processing result of the target resource. The transmitter 2301 may be used to send a first get request message to a next entity.

Optionally, as an embodiment, the receiver 2302 may be used to receive a second reply message sent by a next entity. The second reply message includes a result of the processing of the target resource. The transmitter 2301 may be used to send a second reply message to the upper entity.

Optionally, as an embodiment, the processor 2303 may be configured to determine whether to create a < request > resource for the first request message.

Optionally, as an embodiment, the processor 2303 is specifically configured to determine whether to create a < request > resource for the first request message according to a capacity and/or a supported < request > resource type.

Optionally, as an embodiment, the processor 2303 is configured to create a < request > resource when it is determined that the < request > resource is created for the first request message. The transmitter 2301 is configured to send a third reply message to the previous entity. The third reply message includes address information of the created < request > resource. The processor 2303 is also configured to generate a second request message. The second Request message includes a Request Resource Creator parameter. The Request Resource Creator parameter is set to the identifier of the transit CSE. The transmitter 2302 is further configured to transmit a second request message to a next entity.

Optionally, as an embodiment, the receiver 2302 is further configured to receive a fourth reply message sent by a next entity. The fourth reply message includes a result of the processing of the target resource. The processor 2303 is further configured to update the < request > resource created by the transit CSE according to a fourth reply message. Receiver 2302 is further configured to receive a second get request message sent by a previous entity. The second acquire request message includes address information of the created < request > resource. The second obtaining request message is used for the last entity to request the transit CSE to obtain the processing result of the target resource. The transmitter 2301 is also configured to send a fifth reply message to the previous entity. The fifth reply message includes a result of the processing of the target resource.

Transit CSE 230 is capable of performing operations associated with the foregoing method embodiments of fig. 2, and is capable of performing operations associated with CSEs of fig. 9, 10, and 11, and will not be described in detail to avoid repetition.

A schematic block diagram of the transit CSE of the second embodiment may be as shown in the block diagram of fig. 23.

Specifically, the receiver 2302 is configured to receive a first request message in a non-blocking synchronous communication mode sent by a previous entity. The first request message is used for the initiation entity Originator to request the Hosting general service entity Hosting CSE where the target resource is located to operate the target resource.

The processor 2303 is configured to generate a Request Resource Creator parameter when a Request < Request > Resource is not created for the first Request message. The Request Resource Creator parameter is set to a default value or an identifier of the last entity that created the Request < Request > Resource for the first Request message.

The processor 2303 is configured to generate a second request message based. The second Request message includes a Request Resource Creator parameter.

The transmitter 2301 is configured to send a second request message to a next entity.

Optionally, as an embodiment, the processor 2303 is configured to create a < request > resource when it is determined that the < request > resource is created for the first request message. The transmitter 2301 is configured to send a third reply message to the previous entity. The third reply message includes address information of the created < request > resource. The processor 2303 is also configured to generate a third request message. The third Request message includes a Request Resource Creator parameter. The Request Resource Creator parameter is set to the identifier of the transit CSE. The transmitter 2302 is further configured to transmit a third request message to a next entity.

Optionally, as an embodiment, the receiver 2402 is further configured to receive a fourth reply message sent by a next entity. The fourth reply message includes a result of the processing of the target resource. The processor 2303 is further configured to update the < request > resource created by the transit CSE according to a fourth reply message. Receiver 2302 is further configured to receive a second get request message sent by a previous entity. The second acquire request message includes address information of the created < request > resource. The second obtaining request message is used for the last entity to request the transit CSE to obtain the processing result of the target resource. The transmitter 2301 is also configured to send a fifth reply message to the previous entity. The fifth reply message includes a result of the processing of the target resource.

A schematic block diagram of the transit CSE of the third embodiment may be as shown in the block diagram of fig. 23.

Specifically, the receiver 2302 may be configured to receive a first request message in a non-blocking synchronous communication mode sent by a previous entity. The first request message is used for the initiation entity Originator to request the Hosting general service entity Hosting CSE where the target resource is located to operate the target resource. The request resource indication field is a default value or an identifier of an entity that has last created a request < request > resource for the first request message.

The transmitter 2301 may be configured to send the first request message received by the receiver 2302 to a next entity when a request < request > resource is not created for the first request message.

Optionally, as an embodiment, the receiver 2302 may be configured to receive a first acquisition request message sent by a last entity. The first get request message includes address information of a < request > resource created by an entity that creates the < request > resource next to the first request message. The first get request message is used to request the next entity creating < request > resource to get the processing result of the target resource. Transmitter 2501 may be configured to transmit a first get request message to a next entity.

Optionally, as an embodiment, the processor 2303 is configured to create a < request > resource when it is determined that the < request > resource is created for the first request message. The transmitter 2301 is configured to send a third reply message to the previous entity. The third reply message includes address information of the created < request > resource. The processor 2503 is also configured to generate a second request message. The second request message includes a request resource indication field. The request resource indication field is set to the identifier of the transit CSE. The transmitter 2302 is further configured to transmit a second request message to a next entity.

A schematic block diagram of the transit CSE of the fourth embodiment may be as shown in the block diagram of fig. 23.

Specifically, the receiver 2302 may receive a request message in a non-blocking synchronous communication mode sent by a previous entity. The first request message is used for the initiation entity Originator to request the Hosting general service entity Hosting CSE where the target resource is located to operate the target resource.

The transmitter 2301 may be configured to send an indication message to an upper entity when a < request > resource is not created for a request message received by a first receiving unit. The indication message includes that the requesting resource does Not Create a Request Not Create. The parameter Request Not Create parameter includes the identifier of the next entity. The indication message is used to instruct the previous entity to send a request message to the next entity.

Alternatively, the processor 2303 may be used to determine whether to create a < request > resource for a request message, as an embodiment.

Optionally, as an embodiment, the processor 2303 is specifically configured to determine whether to create a < request > resource for the request message according to a capacity and/or a supported < request > resource type.

A schematic block diagram of a transit CSE of embodiment five may be as in the block diagram of fig. 23.

In particular, the transmitter 2301 may be used to transmit a request message in a non-blocking synchronous communication mode to a next entity. The request message is used for the initiation entity originor to request the Hosting CSE where the target resource is located to operate the target resource.

Receiver 2302 is configured to receive an indication message sent by a next entity. The indication message includes a Request Not to Create Request Not Create parameter. The Request Not Create parameter includes an identifier of the first entity. The indication message is used for indicating the local entity to send the request message to the first entity.

The transmitter 2301 is also configured to send a request message to the first entity.

A schematic block diagram of a transit CSE of embodiment six may be as in the block diagram of fig. 23.

Specifically, the receiver 2802 is configured to receive a request message in a non-blocking synchronous communication mode sent by the transit CSE. The request message is used for the Originator to request the operation on the target resource.

The transmitter 2301 is configured to transmit indication information to the relay CSE according to the request message when the request < request > resource is not created for the request message received by the receiving unit. The indication information is used to indicate the transit CSE to resend the request message after the first time period.

Optionally, as an embodiment, the processor 2303 is configured to process the target resource according to the request message, and obtain a processing result of the target resource.

Optionally, as an embodiment, the receiver 2302 is configured to receive a request message for relaying a CSE retransmission. Transmitter 2301 is configured to send a reply message to the transit CSE. The reply message includes the processing result for the target resource.

Optionally, as an embodiment, the transmitter 2301 is configured to resend the indication message to the transit CSE when the target resource is not processed after the first time period. Alternatively, the processor 2303 is configured to discard the processing result of the target resource when the request message sent by the transit CSE is not received after the second duration. The receiver 2302 is configured to receive a request message sent again by the transit CSE after the third duration.

And the processor is configured to resend the indication message to the transit CSE when the request message sent by the transit CSE is not received after the first time period or the processing on the target resource is not completed.

A schematic block diagram of a transit CSE of embodiment seven may be as in the block diagram of fig. 23.

In particular, the transmitter 2301 may be configured to send a request message in a non-blocking synchronous communication mode to a Hosting CSE. The request message is used for the Originator to request the Hosting CSE to operate on the target resource.

The receiver 2302 is configured to receive indication information sent by the Hosting CSE according to the request message. The indication message is used for indicating that the request message is retransmitted after the first time length of the transit CSE.

Optionally, as an embodiment, the transmitter 2301 is configured to resend the request message to the Hosting CSE. Receiver 2302 is used to receive a reply message sent by the Hosting CSE. The reply message includes the processing result for the target resource.

Optionally, as an embodiment, the receiver 2302 is configured to receive an indication message sent again by the Hosting CSE after the first duration. Alternatively, the transmitter 2301 is configured to send the request message to the Hosting CSE again after the third duration.

The processor controls the operation of the device and may be used to process the signals. The memory may include both read-only memory and random access memory, and provides instructions and data to the processor. The transmitter and receiver may be coupled to an antenna. The various components of the device are coupled together by a bus system that includes a power bus, a control bus, and a status signal bus in addition to a data bus. For clarity of illustration, however, the various buses are labeled as a bus system in the figures.

The method disclosed by the embodiment of the invention can be applied to a processor or realized by the processor. In implementation, the steps of the above method may be performed by integrated logic circuits of hardware in a processor or instructions in the form of software. The processor may be a general purpose processor, a digital signal processor, an application specific integrated circuit, a field programmable gate array or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or the like that implement or perform the methods, steps, and logic blocks disclosed in embodiments of the present invention. A general purpose processor may be a microprocessor or any conventional processor or the like. The steps of a method disclosed in connection with the embodiments of the present invention may be directly implemented by a hardware processor, or may be implemented by a combination of hardware and software modules in the processor. The software module may be located in ram, flash memory, rom, prom, or eprom, registers, etc. storage media as is well known in the art. The storage medium is located in a memory, and a processor reads information in the memory and completes the steps of the method in combination with hardware of the processor.

It should be appreciated that reference throughout this specification to "one embodiment" or "an embodiment" means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

It should be understood that, in various embodiments of the present invention, the sequence numbers of the above-mentioned processes do not mean the execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

It should be understood that in the present embodiment, "B corresponding to a" means that B is associated with a, from which B can be determined. It should also be understood that determining B from a does not mean determining B from a alone, but may be determined from a and/or other information.

It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present invention may be embodied in the form of a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.

The above description is only for the specific embodiments of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present invention, and all the changes or substitutions should be covered within the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the appended claims.

Claims

1. A method of unifying communication in a machine-to-machine oneM2M system, comprising:

receiving a first Request message in a non-blocking synchronous communication mode sent by a previous entity, wherein the first Request message comprises a Request Resource Creator parameter, the Request Resource Creator parameter is a default value or an identifier of an entity which creates a Request < Request > Resource aiming at the first Request message, and the first Request message is used for an initiating entity Originator to Request a Hosting general service entity Hosting CSE where a target Resource is located to operate the target Resource;

sending the first request message to a next entity when no request < request > resource is created for the first request message.

2. The method of claim 1, wherein the method further comprises:

receiving a first reply message sent by the next entity, wherein the first reply message comprises address information of a resource which is created by the next entity aiming at the resource which is created by the first request message and is less than the request;

and sending the first reply message to the last entity.

3. The method of claim 2, wherein the method further comprises:

receiving a first obtaining request message sent by the last entity, wherein the first obtaining request message comprises address information of resources which are created by the next entity aiming at the resources which are created by the first request message and are less than the request, and the first obtaining request message is used for requesting the next entity which creates the resources which are less than the request to obtain a processing result of a target resource;

and sending the first acquisition request message to the next entity.

4. The method of claim 3, wherein the method further comprises:

receiving a second reply message sent by the next entity, wherein the second reply message comprises a processing result of the target resource;

Sending the second reply message to the last entity.

5. The method of any of claims 1 to 4, wherein prior to the sending of the first request message to the next entity, the method further comprises:

determining whether to create a < request > resource for the first request message.

6. The method of claim 5, wherein the determining whether to create a < request > resource for the first request message comprises:

determining whether to create a < request > resource for the first request message based on capacity and/or supported < request > resource types.

7. The method of claim 5, wherein the method is performed by a transit CSE, the method further comprising:

creating a < request > resource when it is determined that a < request > resource is created for the first request message;

sending a third reply message to the last entity, wherein the third reply message comprises the created address information of resources with the value of < request >;

generating a second Request message, wherein the second Request message comprises the Request Resource Creator parameter, and the Request Resource Creator parameter is set as an identifier of the transit CSE;

Sending the second request message to the next entity.

8. The method of claim 7, wherein the method further comprises:

receiving a fourth reply message sent by the next entity, wherein the fourth reply message comprises a processing result of the target resource;

updating < request > resources created by the transfer CSE according to the fourth reply message;

receiving a second acquisition request message sent by the previous entity, where the second acquisition request message includes address information of resources < request > created by the transit CSE, and the second acquisition request message is used for the previous entity to request the transit CSE to acquire the processing result of the target resource;

and sending a fifth reply message to the last entity, wherein the fifth reply message comprises the processing result of the target resource.

9. A method of unifying communication in a machine-to-machine oneM2M system, comprising:

receiving a first request message in a non-blocking synchronous communication mode sent by a last entity, wherein the first request message is used for initiating an entity originor to request a Hosting general service entity Hosting CSE where a target resource is located to operate the target resource;

When a Request < Request > Resource is not created for the first Request message, generating a Request Resource Creator parameter set to a default value or an identifier of an entity that created the Request < Request > Resource for the first Request message;

generating a second Request message, wherein the second Request message comprises the Request Resource Creator parameter;

sending the second request message to a next entity.

10. The method of claim 9, wherein the method further comprises:

and sending the first reply message to the last entity.

11. The method of claim 10, wherein the method further comprises:

And sending the first acquisition request message to the next entity.

12. The method of claim 11, wherein the method further comprises:

sending the second reply message to the last entity.

13. The method according to any of claims 9 to 12, wherein before the sending of the first request message to the next entity, the method further comprises:

14. The method of claim 13, wherein the determining whether to create a < request > resource for the first request message comprises:

15. The method of claim 13, wherein the method is performed by a transit CSE, the method further comprising:

generating a third Request message, wherein the third Request message comprises the Request Resource Creator parameter, and the Request Resource Creator parameter is set as an identifier of the transit CSE;

sending the third request message to the next entity.

16. The method of claim 15, wherein the method further comprises:

17. A method of unifying communication in a machine-to-machine oneM2M system, comprising:

receiving a first request message in a non-blocking synchronous communication mode sent by a last entity, wherein a response type RT parameter carried by the first request message comprises a request resource indication field, the first request message is used for initiating an entity originor to request a Hosting general service entity (HSE) where a target resource is located to operate the target resource, and the request resource indication field is a default value or an identifier of a last entity which creates a request < request > resource aiming at the first request message;

18. The method of claim 17, wherein the method further comprises:

and sending the first reply message to the last entity.

19. The method of claim 18, wherein the method further comprises:

and sending the first acquisition request message to the next entity.

20. The method of claim 19, wherein the method further comprises:

sending the second reply message to the last entity.

21. The method according to any of claims 17 to 20, wherein before said sending said first request message to said next entity, said method further comprises:

22. The method of claim 21, wherein the determining whether to create a < request > resource for the first request message comprises:

23. The method of claim 21, wherein the method is performed by a transit CSE, the method further comprising:

generating a second request message, wherein the second request message comprises the request resource indication field, and the request resource indication field is set as an identifier of the transit CSE;

sending the second request message to the next entity.

24. The method of claim 23, wherein the method further comprises:

25. A method of unifying communication in a machine-to-machine oneM2M system, comprising:

receiving a request message in a non-blocking synchronous communication mode sent by a last entity, wherein the request message is used for initiating an entity originor to request a Hosting general service entity Hosting CSE where a target resource is located to operate the target resource;

when a < Request > resource is Not created for the Request message, sending an indication message to the previous entity, wherein the indication message comprises a Request Not Create parameter of Request Not Create of the Request resource, the Request Not Create parameter comprises an identifier of a next entity, and the indication message is used for indicating the previous entity to send the Request message to the next entity.

26. The method of claim 25, wherein the method further comprises:

it is determined whether a < request > resource is created for the request message.

27. The method of claim 26, wherein the determining whether to create a < request > resource for the request message comprises:

Determining whether to create a < request > resource for the request message based on the capacity and/or supported < request > resource type.

28. A method of unifying communication in a machine-to-machine oneM2M system, comprising:

sending a request message in a non-blocking synchronous communication mode to a next entity, wherein the request message is used for an initiating entity Originator to request a Hosting general service entity Hosting CSE where a target resource is located to operate the target resource;

receiving an indication message sent by the next entity, wherein the indication message comprises that a Request resource does Not Create a Request Not Create parameter, the Request Not Create parameter comprises an identifier of a first entity, and the indication message is used for indicating a local entity to send the Request message to the first entity;

sending the request message to the first entity.

29. A method of unifying communications in a machine-to-machine oneM2M system, comprising:

receiving a request message in a non-blocking synchronous communication mode sent by a transit Common Service Entity (CSE), wherein the request message is used for initiating an entity Originator to request to operate a target resource;

and when the request < request > resource is not created for the request message, sending indication information to the transit CSE according to the request message, wherein the indication information is used for indicating the transit CSE to resend the request message after the first time.

30. The method of claim 29, wherein the method further comprises:

and processing the target resource according to the request message to obtain a processing result of the target resource.

31. The method of claim 29 or 30, further comprising:

receiving the request message retransmitted by the transit CSE;

and sending a reply message to the transit CSE, wherein the reply message comprises the processing result of the target resource.

32. The method of claim 29, wherein the first time period is greater than a time period required to process the target resource.

33. The method of claim 29, wherein the method further comprises:

resending the indication message to the transit CSE when processing of the target resource is not completed after a first time period; alternatively, the first and second electrodes may be,

discarding the processing result of the target resource when the request message sent by the transit CSE is not received after a second time length;

and after the third time length, receiving a request message sent again by the transit CSE.

34. A method of unifying communications in a machine-to-machine oneM2M system, comprising:

Sending a request message in a non-blocking synchronous communication mode to a Hosting CSE, wherein the request message is used for an initiating entity Originator to request the Hosting CSE to operate a target resource;

and receiving indication information sent by the Hosting CSE according to the request message, wherein the indication information is used for indicating that the request message is sent again after the first time period.

35. The method of claim 34, wherein the method further comprises:

resending the request message to the Hosting CSE;

and receiving a reply message sent by the Hosting CSE, wherein the reply message comprises the processing result of the target resource.

36. The method of claim 34 or 35, wherein the first time period is greater than a time period required to process the target resource.

37. The method of claim 34, wherein the method further comprises:

after a first time period, receiving an indication message sent again by the Hosting CSE; alternatively, the first and second electrodes may be,

after a third duration, the request message is sent again to the Hosting CSE.

38. An apparatus for communicating in a unified machine-to-machine oneM2M system, comprising:

A first receiving unit, configured to receive a first Request message in a non-blocking synchronous communication mode sent by a previous entity, where the first Request message includes a Request Resource Creator parameter, the Request Resource Creator parameter is a default value or an identifier of a previous entity that creates a Request < Request > Resource for the first Request message, and the first Request message is used to initiate an entity Originator to Request a Hosting CSE, where a target Resource is located, to operate the target Resource;

a first sending unit, configured to send the first request message to a next entity when a < request > resource is not created for the first request message received by the first receiving unit.

39. The apparatus of claim 38, wherein the apparatus further comprises:

a second receiving unit, configured to receive a first reply message sent by the next entity, where the first reply message includes address information of a < request > resource created by a next entity that creates the < request > resource for the first request message;

and a second sending unit, configured to send the first reply message to the previous entity.

40. The apparatus of claim 39, wherein the apparatus further comprises:

a third receiving unit, configured to receive a first obtaining request message sent by the previous entity, where the first obtaining request message includes address information of a resource that is < request > created by the next entity that creates the resource < request > for the first request message, and the first obtaining request message is used to request the entity that creates the resource < request > for the next entity to obtain a processing result of a target resource;

a third sending unit, configured to send the first get request message to the next entity.

41. The apparatus of claim 40, wherein the apparatus further comprises:

a fourth receiving unit, configured to receive a second reply message sent by the next entity, where the second reply message includes a processing result of the target resource;

a fourth sending unit, configured to send the second reply message to the previous entity.

42. The apparatus of any one of claims 38 to 41, further comprising:

a determining unit configured to determine whether to create a < request > resource for the first request message.

43. The apparatus as recited in claim 42, wherein said determining unit is specifically configured to:

44. The apparatus of claim 42, wherein the apparatus is a transit CSE, the apparatus further comprising:

a creation unit configured to create a < request > resource when it is determined that the < request > resource is created for the first request message;

a fifth sending unit, configured to send a third reply message to the previous entity, where the third reply message includes address information of the created resource that is < request >;

a generating unit, configured to generate a second Request message, where the second Request message includes the Request Resource Creator parameter, and the Request Resource Creator parameter is set as an identifier of the transit CSE;

a sixth sending unit, configured to send the second request message to the next entity.

45. The apparatus of claim 44, wherein the apparatus further comprises:

a fifth receiving unit, configured to receive a fourth reply message sent by the next entity, where the fourth reply message includes the processing result of the target resource;

An updating unit, configured to update the < request > resource created by the transit CSE according to the fourth reply message;

a sixth receiving unit, configured to receive a second obtaining request message sent by the previous entity, where the second obtaining request message includes address information of resources that are created and < request > and is used for the previous entity to request the transit CSE to obtain the processing result of the target resource;

a seventh sending unit, configured to send a fifth reply message to the previous entity, where the fifth reply message includes the processing result of the target resource.

46. An apparatus for communicating in a unified machine-to-machine oneM2M system, comprising:

a first receiving unit, configured to receive a first request message in a non-blocking synchronous communication mode sent by a previous entity, where the first request message is used to initiate an entity Originator to request a Hosting general service entity Hosting CSE where a target resource is located to operate the target resource;

a first generating unit, configured to generate a Request Resource Creator parameter when no Request < Request > Resource is created for the first Request message, where the Request Resource Creator parameter is set to a default value or an identifier of an entity that created a Request < Request > Resource for the first Request message last;

A second generating unit, configured to generate a second Request message, where the second Request message includes the Request Resource Creator parameter;

a first sending unit, configured to send the second request message to a next entity.

47. The apparatus of claim 46, wherein the apparatus further comprises:

a second sending unit, configured to send the first reply message to the previous entity.

48. The apparatus of claim 47, wherein the apparatus further comprises:

49. The apparatus of claim 48, wherein the apparatus further comprises:

50. The apparatus of any one of claims 46 to 49, further comprising:

51. The apparatus of claim 50, wherein the means for determining is specifically configured to determine whether to create a < request > resource for the first request message based on a capacity and/or a supported < request > resource type.

52. The apparatus of claim 50, wherein the apparatus is a transit CSE, the apparatus further comprising:

a third generating unit, configured to generate a third Request message, where the third Request message includes the Request Resource Creator parameter, and the Request Resource Creator parameter is set as an identifier of the transit CSE;

a sixth sending unit, configured to send the third request message to the next entity.

53. The apparatus of claim 52, wherein the apparatus further comprises:

a fifth receiving unit, configured to receive a fourth reply message sent by the next entity, where the fourth reply message includes a processing result of the target resource;

a sixth receiving unit, configured to receive a second obtaining request message sent by the previous entity, where the second obtaining request message includes address information of a resource that is created by the transit CSE and is less than a request, and the second obtaining request message is used for the previous entity to request the transit CSE to obtain the processing result of the target resource;

54. An apparatus for communicating in a unified machine-to-machine oneM2M system, comprising:

a first receiving unit, configured to receive a first request message in a non-blocking synchronous communication mode sent by a previous entity, where a response type RT parameter carried in the first request message includes a request resource indication field, the first request message is used to initiate an entity Originator to request a Hosting CSE, where a target resource is located, to operate the target resource, and the request resource indication field is a default value or an identifier of an entity that has created a request < request > resource for the first request message;

a first sending unit, configured to send the first request message received by the first receiving unit to a next entity when a request < request > resource is not created for the first request message.

55. The apparatus of claim 54, wherein the apparatus further comprises:

56. The apparatus of claim 55, wherein the apparatus further comprises:

57. The apparatus of claim 56, wherein the apparatus further comprises:

58. The apparatus of any one of claims 54 to 57, further comprising:

59. The apparatus of claim 58, wherein the means for determining is specifically configured to determine whether to create a < request > resource for the first request message based on a capacity and/or a supported < request > resource type.

60. The apparatus of claim 58, wherein the apparatus is to perform for a transit CSE, the apparatus further comprising:

a generating unit, configured to generate a second request message, where the second request message includes the request resource indication field, and the request resource indication field is set as an identifier of the transit CSE;

61. The apparatus of claim 60, wherein the apparatus further comprises:

62. An apparatus for communicating in a unified machine-to-machine oneM2M system, comprising:

a receiving unit, configured to receive a request message in a non-blocking synchronous communication mode sent by a previous entity, where the request message is used to initiate an entity originor to request a Hosting CSE, where a target resource is located, to operate the target resource;

A sending unit, configured to send, when the Request message does Not Create < Request > resource for the receiving unit, an indication message to the previous entity, where the indication message includes that the Request resource does Not Create a Request Not Create parameter, the Request Not Create parameter includes an identifier of a next entity, and the indication message is used to indicate that the previous entity sends the Request message to the next entity.

63. The apparatus of claim 61, wherein the apparatus further comprises:

a determination unit configured to determine whether to create a < request > resource for the request message.

64. The apparatus as claimed in claim 63, wherein said determining unit is specifically configured to:

65. An apparatus for communicating in a unified machine-to-machine oneM2M system, comprising:

a first sending unit, configured to send a request message in a non-blocking synchronous communication mode to a next entity, where the request message is used to initiate an entity Originator to request a Hosting generic service entity Hosting CSE where a target resource is located to operate the target resource;

A first receiving unit, configured to receive an indication message sent by the next entity, where the indication message includes that a Request resource does Not Create a Request Not Create parameter, the Request Not Create parameter includes an identifier of a first entity, and the indication message is used to indicate that a local entity sends the Request message to the first entity;

a second sending unit, configured to send the request message to the first entity.

66. An apparatus for unifying communications in a machine-to-machine oneM2M system, comprising:

a first receiving unit, configured to receive a request message in a non-blocking synchronous communication mode sent by a transit generic service entity CSE, where the request message is used to initiate an entity Originator to request to operate a target resource;

a first sending unit, configured to send, according to the request message, indication information to the transit CSE when a request < request > resource is not created for the request message received by the receiving unit, where the indication information is used to indicate the transit CSE to resend the request message after a first time period.

67. The apparatus of claim 66, wherein the apparatus further comprises:

And the processing unit is used for processing the target resource according to the request message to obtain the processing result of the target resource.

68. The apparatus of claim 66 or 67, further comprising:

a second receiving unit, configured to receive the request message retransmitted by the transit CSE;

a second sending unit, configured to send a reply message to the transit CSE, where the reply message includes the processing result of the target resource.

69. The apparatus of claim 66, wherein the first time period is greater than a time period required to process the target resource.

70. The apparatus of claim 66, wherein the apparatus further comprises:

a third sending unit, configured to, when the target resource is not processed after the first time period, resend the indication message to the transit CSE; alternatively, the first and second electrodes may be,

a discarding unit, configured to discard a processing result of the target resource when the request message sent by the transit CSE is not received after a second duration;

and a third receiving unit, configured to receive, after a third duration, the request message sent again by the transit CSE.

71. An apparatus for unifying communications in a machine-to-machine oneM2M system, comprising:

a first sending unit, configured to send a request message in a non-blocking synchronous communication mode to a Hosting CSE, where the request message is used to initiate an entity Originator to request the Hosting CSE to operate a target resource;

a first receiving unit, configured to receive indication information sent by the Hosting CSE according to the request message, where the indication message is used to indicate that the request message is to be sent again after a first time period.

72. The apparatus of claim 71, wherein the apparatus further comprises:

a second sending unit, configured to resend the request message to the Hosting CSE;

a second receiving unit, configured to receive a reply message sent by the Hosting CSE, where the reply message includes a processing result of the target resource.

73. The apparatus of claim 71 or 72, wherein the first time duration is greater than a time duration required to process the target resource.

74. The apparatus for communicating of claim 71, the apparatus further comprising:

a third receiving unit, configured to receive, after the first duration, an indication message retransmitted by the Hosting CSE; alternatively, the first and second electrodes may be,

A third sending unit, configured to send the request message to the Hosting CSE again after a third duration.

75. A computer-readable storage medium, characterized in that it stores a computer program which, when executed by hardware, is capable of implementing the method of any one of claims 1 to 37.

76. An apparatus for unifying communications in a machine-to-machine oneM2M system, comprising:

a transmitter, a receiver, a processor, and a memory;

wherein the transmitter, receiver and processor are configured to execute computer programs stored in the memory to perform the method of any of claims 1 to 37.