WO2016109967A1 - 统一机器到机器系统中通信的方法和装置 - Google Patents

统一机器到机器系统中通信的方法和装置 Download PDF

Info

Publication number
WO2016109967A1
WO2016109967A1 PCT/CN2015/070381 CN2015070381W WO2016109967A1 WO 2016109967 A1 WO2016109967 A1 WO 2016109967A1 CN 2015070381 W CN2015070381 W CN 2015070381W WO 2016109967 A1 WO2016109967 A1 WO 2016109967A1
Authority
WO
WIPO (PCT)
Prior art keywords
request
resource
entity
request message
message
Prior art date
Application number
PCT/CN2015/070381
Other languages
English (en)
French (fr)
Inventor
陶源
于琦
甄斌
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to CN201580072631.7A priority Critical patent/CN107113311B/zh
Priority to PCT/CN2015/070381 priority patent/WO2016109967A1/zh
Publication of WO2016109967A1 publication Critical patent/WO2016109967A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming

Definitions

  • Embodiments of the present invention relate to the field of communications and, more particularly, to a method and apparatus for communicating in a unified machine-to-machine system.
  • the Global Standards Organization unified machine to machine (English: one Machine to Machine, referred to as: oneM2M) was established, which aims to efficiently deploy machine to machine (English: Machine to Machine, referred to as: M2M) Communication system to promote the integration of M2M global standards and industry applications.
  • the existing oneM2M system adopts a layered architecture. The entire architecture is divided into an application layer (English: Application Layer), a public service layer (English: Common Service Layer), and an underlying network service layer (English: Network Service Layer).
  • the application entity in the application layer (English: Application Entity, AE for short) contains an instantiated one-to-one oneM2M solution.
  • the public service entity (Common Service Entity, CSE for short) in the public service layer contains the instantiated public service function.
  • the CSE is the core layer in oneM2M.
  • the management is responsible for aggregating the application layer information to form a resource pool and coordinate the underlying network transmission. Play a role as a platform.
  • the underlying network entity (English: Network Service Entity, NSE) management in the underlying network service layer is responsible for the underlying network transmission and provides the underlying network support to the public service layer.
  • Mca the interface between AE and CSE, responsible for communication between AE to CSE or CSE to AE, enabling AE to use the services provided by CSE and enabling CSE to communicate with AE in reverse.
  • Mcc/Mcc' An interface between two CSEs that is responsible for communication between CSEs, enabling one CSE to use the functionality provided by another CSE.
  • Mcn The interface between the CSE and the NSE, responsible for communication between the CSE to the NSE or the NSE to the CSE, so that the CSE can use the bearer network to provide services to the upper layer.
  • the existing oneM2M standard adopts the representation layer state transformation (English: Representational State Transfer, referred to as: REST) to get the architecture.
  • the information and data information of AE and CSE in oneM2M system can be represented by resources.
  • the behavior in oneM2M system can be achieved by the following five operations: Create (English: Create), Get (English: retrieve), Update (English: Update), Delete (English: Delete), and Notification (English: Notify) .
  • Create is used for CSE or AE to create a resource on other CSE.
  • Retrieve is used to get stored in CSE
  • the properties of the resource Update is used to update the information stored in the properties of the target resource.
  • Delete is used to delete resources on the CSE.
  • Notify is used to notify the information.
  • the existing oneM2M standard defines three communication modes: Blocking, Non-Blocking Synchronous, and Non-Blocking Asynchronous.
  • the non-blocking synchronous communication mode when the target resource is stored in the hosted general service entity (English: Hosting CSE), the originating entity (English: Originator) may send a request message to the Hosting CSE to request to operate on the target resource.
  • the request message sent by the Originator can be forwarded to the Hosting CSE after being forwarded by a transit CSE.
  • the transit CSE needs to create a request ⁇ request> resource to complete the communication process.
  • the Originator and the Hosting CSE may be multi-hop. That is, the request message sent by the Originator is forwarded by multiple Transit CSEs to the Hosting CSE.
  • each transit CSE needs to create a request ⁇ request> resource.
  • ⁇ request> resources cannot be created.
  • the transit CSE does not support the ⁇ request> resource type or the capacity of the transit CSE is limited.
  • some transitive CSEs can create ⁇ request> resources, but do not create ⁇ request> resources according to their own circumstances. In these cases, the current face N (N is a positive integer greater than 1) transitive CSE has successfully created the ⁇ request> resource.
  • Embodiments of the present invention provide a method and apparatus for communicating in a unified machine-to-machine system, so that communication can continue even when ⁇ request> resource creation fails.
  • a method for communicating in a unified machine-to-machine M2M system comprising: receiving a first request message in a non-blocking synchronous communication mode sent by a previous entity, the first request message including a requesting resource creator a Request Resource Creator parameter, the Request Resource Creator parameter being a default value or an identifier of an entity that created a request ⁇ request> resource for the first request message, the first request message being used to initiate an entity Originator to a target
  • the hosting general service entity Hosting CSE where the resource is located, requests to operate on the target resource; when the ⁇ request> resource is not created for the first request message, the first request message is sent to the next entity.
  • the first reply message sent by the next entity is received, where the first reply message includes: creating a ⁇ request> resource for the first request message The address information of the ⁇ request> resource created by the entity; the first reply message is sent to the previous entity.
  • the first acquiring request message sent by the previous entity is received, where the first acquiring request message includes the next target
  • the first request message creates the address information of the ⁇ request> resource created by the entity of the ⁇ request> resource, and the first acquisition request message is used to request the entity that creates the ⁇ request> resource to acquire the target resource. Processing result; sending the first acquisition request message to the next entity.
  • the 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 previous entity.
  • the method before the sending, by the next entity, the first request message, the method further includes: determining whether the A request message creates a ⁇ request> resource.
  • determining whether to create a ⁇ request> resource for the first request message includes: according to a capacity and/or a supported ⁇ request> resource type Determining whether a ⁇ request> resource is created for the first request message.
  • the method is performed by a transit CSE, the method further comprising: when determining to create a ⁇ request> resource for the first request message Creating a ⁇ request> resource; sending a third reply message to the previous entity, the third reply message including address information of the created ⁇ request> resource; generating a second request message, the second request message including The Request Resource Creator parameter, the Request Resource Creator parameter is set to an identifier of the transit CSE; and the second request message is sent to the next entity.
  • the 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, the second obtaining The request message includes address information of the created ⁇ request> resource, and the second acquisition request message is used by the previous entity to request the transit CSE to obtain the processing result of the target resource; to the previous entity Sending a fifth reply message, where the fifth reply message includes the processing result of the target resource.
  • a method for communicating 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, where the first request message is used by The initiating entity Originator requests the hosted general service entity Hosting CSE where the target resource is located to operate the target resource; when the request ⁇ request> resource is not created for the first request message, the request resource creator Request Resource Creator parameter is generated.
  • 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; generating a second request message, the second request message including the Request a Resource Creator parameter; the generating the second request message is sent to the next entity.
  • the first reply message sent by the next entity is received, where the first reply message includes: creating a ⁇ request> resource for the first request message The address information of the ⁇ request> resource created by the entity; the first reply message is sent to the previous entity.
  • the first acquiring request message sent by the previous entity is received, where the first acquiring request message includes the next target
  • the first request message creates the address information of the ⁇ request> resource created by the entity of the ⁇ request> resource, and the first acquisition request message is used to request the entity that creates the ⁇ request> resource to acquire the target resource.
  • Processing result sending the first acquisition request message to the next entity.
  • the 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 previous entity.
  • the method before the sending, by the next entity, the first request message, the method further includes: determining whether the A request message creates a ⁇ request> resource.
  • determining whether to create a ⁇ request> resource for the first request message includes: according to capacity and/or support
  • the ⁇ request> resource type determines whether a ⁇ request> resource is created for the first request message.
  • the method is performed by a transit CSE, the method further comprising: when determining to create a ⁇ request> resource for the first request message Creating a ⁇ request> resource; sending a third reply message to the previous entity, the third reply message including address information of the created ⁇ request> resource; generating a third request message, the third request message including The Request Resource Creator parameter, the Request Resource Creator parameter is set to an identifier of the transit CSE; and the third request message is sent to the next entity.
  • the fourth reply message sent by the next entity is received, where the fourth reply message includes the processing result of the target resource And updating the ⁇ request> resource created by the transit CSE according to the fourth reply message; receiving a second acquiring request message sent by the previous entity, where the second obtaining request message includes the created ⁇ request> resource Address information, the second acquisition request message is used by the previous entity to obtain the processing result of the target resource from the transit CSE, and send a fifth reply message to the previous entity, the fifth The reply message includes the result of the processing of the target resource.
  • a method for communicating 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, where the first request message carries The response type RT parameter includes a request resource indication field, and the first request message is used by the initiating entity Originator to perform an operation on the target resource by the hosted general service entity Hosting CSE where the target resource is located, and the request resource indication field is a default value or An identifier of an entity that creates a request ⁇ request> resource for the first request message. When the request ⁇ request> resource is not created for the first request message, the first request message is sent to the next entity.
  • the first reply message sent by the next entity is received, where the first reply message includes a next creation of a ⁇ request> resource for the first request message.
  • the address information of the ⁇ request> resource created by the entity; the first reply message is sent to the previous entity.
  • the first acquiring request message sent by the previous entity is received, where the first acquiring request message includes Addressing the address information of the ⁇ request> resource created by the entity that creates the ⁇ request> resource for the first request message, where the first acquisition request message is used to request the entity that creates the ⁇ request> resource The processing result of the target resource; sending the first acquisition request message to the next entity.
  • the 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 previous entity.
  • the method before the sending, by the next entity, the first request message, the method further includes: determining whether the A request message creates a ⁇ request> resource.
  • determining whether to create a ⁇ request> resource for the first request message includes: according to a capacity and/or a supported ⁇ request> resource type Determining whether a ⁇ request> resource is created for the first request message.
  • the method is performed by a transit CSE, the method further comprising: when determining to create a ⁇ request> resource for the first request message Creating a ⁇ request> resource; sending a third reply message to the previous entity, the third reply message including address information of the created ⁇ request> resource; generating a second request message, the second request message including The request resource indication field, the request resource indication field is set as an identifier of the transit CSE; and the second request message is sent to the next entity.
  • the fourth reply message sent by the next entity is received, where the fourth reply message includes the processing result of the target resource And updating the ⁇ request> resource created by the transit CSE according to the fourth reply message; receiving a second acquiring request message sent by the previous entity, where the second obtaining request message includes the created ⁇ request> resource Address information, the second acquisition request message is used by the previous entity to obtain the processing result of the target resource from the transit CSE, and send a fifth reply message to the previous entity, the fifth The reply message includes the result of the processing of the target resource.
  • a fourth aspect provides a method for unifying communication in a machine-to-machine M2M system, comprising: receiving a request message in a non-blocking synchronous communication mode sent by a previous entity, the request cancellation The information is used by the initiating entity Originator to perform an operation on the target resource by the hosting general service entity Hosting CSE where the target resource is located; when the ⁇ request> resource is not created for the first request message, sending an indication to the previous entity a message, 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 next entity to the next entity The first request message is described.
  • the method further includes: determining whether to create a ⁇ request> resource for the request message.
  • determining whether to create a ⁇ request> resource for the request message includes: determining, according to the capacity and/or the supported ⁇ request> resource type A ⁇ request> resource is created for the request message.
  • a fifth aspect provides a method for unifying communication in a machine-to-machine M2M system, sending a request message in a non-blocking synchronous communication mode to a next entity, the request message being used to initiate an entity Originator to a hosted resource
  • the Common Service Entity Hosting CSE requests to operate on the target resource; and receives an indication message sent by the next entity, where the indication message includes that the request resource does not create a Request Not Create parameter, and the Request Not Create parameter includes the first entity An identifier, the indication message is used to instruct the local entity to send the request message to the first entity; and send the request message to the first entity.
  • a method for communicating in a machine-to-machine oneM2M system comprising: receiving a request message in a non-blocking synchronous communication mode sent by a transit universal service entity CSE, where the request message is used to initiate an entity Originator request pair The target resource is operated; when the request ⁇ request> resource is not created for the request message, the indication information is sent to the transit CSE according to the request message, where the indication information is used to indicate that the transit CSE is after the first duration The request message is resent.
  • the determining unit is specifically configured to: determine whether the target resource is determined according to whether the ⁇ request> resource type is supported and/or whether the capacity exceeds a first threshold. Create the ⁇ request> resource.
  • the target resource is processed according to the request message, and the processing result of the target resource is obtained.
  • the method further includes: receiving the request message retransmitted by the transit CSE; sending a reply message to the transit CSE, where the reply message includes the processing result of the target resource.
  • the first duration is greater than a duration required to process the target resource.
  • the method further includes: when the processing of the target resource is not completed after the first duration, to the transit CSE Resending the indication message; or not receiving the request message sent by the transit CSE after the second duration, discarding the processing result of the target resource; after the third duration, receiving the request message sent by the transit CSE again .
  • a seventh aspect a method for unifying communication in a machine-to-machine oneM2M system, comprising: sending a request message in a non-blocking synchronous communication mode to a hosted CSE, the request message being used to initiate an entity Originator to the Hosting The CSE requests access to the target resource, and receives the 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 resent after the first time period.
  • the method further includes: resending the request message to the Hosting CSE, and receiving a reply message sent by the Hosting CSE, where the reply message includes Describe the processing result of the target resource.
  • the first duration is greater than a duration required to process the target resource.
  • the method further includes: after the first duration, receiving an indication message that the Hosting CSE retransmits; or, in a third duration Thereafter, the request message is sent again to the Hosting CSE.
  • a device for unifying communication in a machine-to-machine oneM2M system is provided.
  • the 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 includes a request.
  • a resource creator request Resource Creator parameter the Request Resource Creator parameter being a default value or an identifier of an entity that created a request ⁇ request> resource for the first request message, the first request message being used to initiate an entity
  • the Originator requests the hosted CSE, where the target resource is located, to operate the target resource; the first sending unit is configured to: when the first request message received by the first receiving unit does not create a ⁇ request> resource Sending the first request message to the next entity.
  • the device further includes: a 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 an entity that creates a ⁇ request> resource for the first request message a second sending unit that sends the first reply message to the previous entity.
  • the device further includes: a third receiving unit, configured to receive a first acquiring request message sent by the previous entity,
  • the first acquisition request message includes address information of a ⁇ request> resource created by the entity that creates a ⁇ request> resource for the first request message, and the first acquisition request message is used to create the next one.
  • the request> resource entity requests to obtain the processing result of the target resource; and the third sending unit is configured to send the first acquiring request message to the next entity.
  • the device 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, and the fourth sending unit is configured to send the second reply message to the previous entity.
  • the apparatus further includes: a determining unit, configured to determine whether to create a ⁇ request> resource for the first request message.
  • the determining determining unit is specifically configured to: determine whether the first request is for the first request according to a capacity and/or a supported ⁇ request> resource type The message creates a ⁇ request> resource.
  • the device is a transit CSE
  • the device further includes: a creating unit, configured to: when determining to create a message for the first request message a request> resource, a ⁇ request> resource is created; a fifth sending unit is configured to send a third reply message to the previous entity, where the third reply message includes address information of the created ⁇ request> resource;
  • the second request message includes the Request Resource Creator parameter, the Request Resource Creator parameter is set as an identifier of the transit CSE, and a sixth sending unit, configured to go to the next The entity sends the second request message.
  • the device further includes: a fifth receiving unit, configured to receive a fourth reply message sent by the next entity, The fourth reply message includes the processing result 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; and the sixth receiving unit is configured to receive a second acquisition request message sent by the previous entity, the second acquisition request message includes address information of the created ⁇ request> resource, and the second acquisition request message is used by the previous entity to the transit CSE Requesting to obtain the processing result of the target resource; the seventh sending unit is configured to send a fifth reply message to the previous entity, where the fifth reply message includes the processing result of the target resource.
  • the ninth aspect provides a device for unifying communication 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, where the first request message is The initiating entity Originator requests the hosted CSE of the target resource to operate on the target resource; the first generating unit is configured to generate when the request ⁇ request> resource is not created for the first request message Requesting a resource creator Request Resource Creator parameter, the Request Resource Creator parameter being set to a default value or an identifier of an entity that created a request ⁇ request> resource for the first request message; and a second generating unit for generating a second request message, the second request message includes the Request Resource Creator parameter, and the first sending unit is configured to send the second request message to a next entity.
  • the device 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 an entity that creates a ⁇ request> resource for the first request message; and a second sending unit that sends the first reply message to the previous entity.
  • the device further includes: a third receiving unit, configured to receive a first acquiring request message sent by the previous entity,
  • the first acquisition request message includes address information of a ⁇ request> resource created by the entity that creates a ⁇ request> resource for the first request message, and the first acquisition request message is used to create the next one.
  • the request> resource entity requests to obtain the processing result of the target resource; and the third sending unit is configured to send the first acquiring request message to the next entity.
  • the apparatus further includes: a fourth receiving unit, configured to receive a second reply message sent by the next entity, The second reply message includes the processing result of the target resource, and the fourth sending unit is configured to send the second reply message to the previous entity.
  • the apparatus further includes: a determining unit, configured to determine whether to create a ⁇ request> resource for the first request message.
  • the determining determining unit is specifically configured to: determine whether the first request is for the first request according to a capacity and/or a supported ⁇ request> resource type The message creates a ⁇ request> resource.
  • the device is a transit CSE, and the device further includes: a creating unit, configured to: when determining to create a message for the first request message When the resource is requested, the ⁇ request> resource is created; the fifth sending unit is configured to send a third reply message to the previous entity, where the third reply message includes the address information of the created ⁇ request> resource; the third generation a unit, configured to generate a third request message, where the third request message includes the Request Resource Creator parameter, the Request Resource Creator parameter is set as an identifier of the transit CSE, and a sixth sending unit, configured to The next entity sends the third request message.
  • a creating unit configured to: when determining to create a message for the first request message When the resource is requested, the ⁇ request> resource is created
  • the fifth sending unit is configured to send a third reply message to the previous entity, where the third reply message includes the address information of the created ⁇ request> resource
  • the third generation a unit configured to generate a third request message, where the third request message includes the Request
  • the device 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, the update unit, configured to update the ⁇ request> resource created by the transit CSE according to the fourth reply message, and a sixth receiving unit, configured to receive the a second acquisition request message sent by an entity, where the second acquisition request message includes address information of the created ⁇ request> resource, and the second acquisition request message is used by the previous entity to request the acquisition of the intermediate CSE And 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.
  • 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
  • the update 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 the a second acquisition request message sent by an entity, where the second acquisition request message includes address information
  • a device for unifying communication in a machine-to-machine oneM2M system is provided.
  • the 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
  • the response type RT parameter carried by the request message includes a request resource indication field, and the first request message is used by the initiating entity Originator to perform an operation on the target resource by the hosted general service entity Hosting CSE where the target resource is located, the request resource indication
  • the field is the default value or the last one created the request ⁇ request> resource for the first request message
  • An identifier of the entity; the first sending unit is configured to send the first request message to the next entity when the first request message received by the first receiving unit does not create a ⁇ request> resource.
  • the device 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 an entity that creates a ⁇ request> resource for the first request message; and a second sending unit that sends the first reply message to the previous entity.
  • the device further includes: a third receiving unit, configured to receive a first acquiring request message sent by the previous entity,
  • the first acquisition request message includes address information of a ⁇ request> resource created by the entity that creates a ⁇ request> resource for the first request message, and the first acquisition request message is used to create the next one.
  • the request> resource entity requests to obtain the processing result of the target resource; and the third sending unit is configured to send the first acquiring request message to the next entity.
  • the device 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, and the fourth sending unit is configured to send the second reply message to the previous entity.
  • the apparatus further includes: a determining unit, configured to determine whether to create a ⁇ request> resource for the first request message.
  • the determining determining unit is specifically configured to: determine whether the first request is for the first request according to the capacity and/or the supported ⁇ request> resource type The message creates a ⁇ request> resource.
  • the device is a transit CSE
  • the device further includes: a creating unit, configured to: when determining to create a message for the first request message a request> resource, a ⁇ request> resource is created; a fifth sending unit is configured to send a third reply message to the previous entity, where the third reply message includes address information of the created ⁇ request> resource; For generating a second request message, the second request message includes the request resource indication field, the request resource indication field is set as an identifier of the transit CSE, and a sixth sending unit, configured to go to the next The entity sends the second request cancellation interest.
  • the device 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, the update unit, configured to update the ⁇ request> resource created by the transit CSE according to the fourth reply message, and a sixth receiving unit, configured to receive the a second acquisition request message sent by an entity, where the second acquisition request message includes address information of the created ⁇ request> resource, and the second acquisition request message is used by the previous entity to request the acquisition of the intermediate CSE And 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.
  • 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, the first request message The initiating entity Originator requests the hosted CSE of the target resource to operate on the target resource; the sending unit is configured to not create a ⁇ request> when the request message is received for the first receiving unit And sending an indication message to the previous entity, where the indication message includes a Request Not Create parameter, where the Request Not Create parameter includes an identifier of a next entity, where the indication message is used to indicate that the previous entity is The next entity sends the request message.
  • the apparatus further includes: a determining unit, configured to determine whether to create a ⁇ request> resource for the request message.
  • the determining unit is specifically configured to: determine whether to create the request message according to the capacity and/or the supported ⁇ request> resource type. Request>Resources.
  • a device for unifying communication in a machine-to-machine oneM2M system includes: 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
  • the initiating entity Originator requests the hosted CSE of the target resource to operate the target resource;
  • the receiving unit is configured to receive the indication message sent by the next entity, where the indication message includes the request resource does not create a Request a Not Create parameter, the Request Not Create parameter includes an identifier of the first entity, the indication message is used to indicate that the local entity sends the request message to the first entity, and the second sending unit is configured to An entity sends the request message.
  • a thirteenth aspect a device 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 universal service entity CSE, The request message is used to initiate an operation of the entity Originator request to the target resource; the first sending unit is configured to: when the request message received by the receiving unit does not create a request ⁇ request> resource, according to the request message The transit CSE sends indication information, where the indication information is used to indicate that the transit CSE resends the request message after the first duration.
  • the device further includes: a processing unit, configured to process the target resource according to the request message, to obtain the processing result of the target resource.
  • the device further includes: a second receiving unit, configured to receive the request message that is retransmitted by the transit CSE; And a unit, configured to send a reply message to the transit CSE, where the reply message includes the processing result of the target resource.
  • the first duration is greater than a duration required to process the target resource.
  • the apparatus further includes: a third sending unit, configured to not receive the sending of the transit CSE after the first duration When the message is requested or the processing of the target resource is not completed, the indication message is resent to the transit CSE.
  • a device for unifying communication in a machine-to-machine oneM2M system includes: a first sending unit, configured to send a request message in a non-blocking synchronous communication mode to a hosted CSE, where the request message is used The initiating entity Originator requests the Hosting CSE to access the target resource; the first receiving unit is configured to receive the indication information that is sent by the Hosting CSE according to the request message, where the indication message is used to indicate that the first time period is resent Request message.
  • the device further comprising: the device further comprising: And a unit, configured to receive a reply message sent by the Hosting CSE, where the reply message includes the processing result of the target resource.
  • the first duration is greater than the length of time required to process the target resource.
  • the device further includes: a third receiving unit, configured to receive, after the first duration, the re-sending of the Hosting CSE Indicate the message.
  • the oneM2M system of the embodiment of the present invention communicates using the non-blocking synchronous communication mode, after receiving the request message for adding the Request Resource Creator parameter sent by the previous entity, the request is forwarded to the next entity by the entity that does not create the ⁇ request> resource.
  • the message can continue to communicate when the local entity ⁇ request> resource creation fails.
  • FIG. 1 is a schematic diagram of a system scenario according to an embodiment of the present invention.
  • FIG. 2 is a schematic flow chart of a method of communication in a oneM2M system according to an embodiment of the present invention.
  • FIG. 3 is a schematic flowchart of a method for communication in a oneM2M system according to another embodiment of the present invention.
  • FIG. 4 is a schematic flow chart of a method of communication in a oneM2M system according to still another embodiment of the present invention.
  • FIG. 5 is a schematic flowchart of a method for communication in a oneM2M system according to still another embodiment of the present invention.
  • FIG. 6 is a schematic flowchart of a method for communication in a oneM2M system according to still another embodiment of the present invention.
  • FIG. 7 is a schematic flowchart of a method for communication in a oneM2M system according to still another embodiment of the present invention.
  • FIG. 8 is a schematic flowchart of a method for communication in a oneM2M system according to still another embodiment of the present invention.
  • FIG. 9 is a schematic interaction flow diagram of a method of communication in a oneM2M system in accordance with an embodiment of the present invention.
  • FIG. 10 is a schematic interaction flowchart of a method for communication in a oneM2M system according to another embodiment of the present invention.
  • FIG. 11 is a schematic interaction flow diagram of a method of communication in a oneM2M system in accordance with still another embodiment of the present invention.
  • FIG. 12 is a schematic interaction flowchart of a method of communication in a oneM2M system according to still another embodiment of the present invention.
  • FIG. 13 is a schematic interaction flow diagram of a method of communication in a oneM2M system in accordance with still another embodiment of the present invention.
  • FIG. 14 is a schematic interaction flow diagram of a method of communication in a oneM2M system in accordance with still another embodiment of the present invention.
  • 15 is a schematic interaction flow diagram of a method of communication in a oneM2M system in accordance with still another embodiment of the present invention.
  • 16 is a schematic block diagram of an apparatus for communication in a oneM2M system in accordance with an embodiment of the present invention.
  • 17 is a schematic block diagram of an apparatus for communication in a oneM2M system according to another embodiment of the present invention.
  • Figure 18 is a schematic block diagram of an apparatus for communication in a oneM2M system in accordance with still another embodiment of the present invention.
  • Figure 19 is a schematic block diagram of an apparatus for communication in a oneM2M system in accordance with still another embodiment of the present invention.
  • Figure 20 is a schematic block diagram of an apparatus for communication in a oneM2M system in accordance with still another embodiment of the present invention.
  • Figure 21 is a schematic block diagram of an apparatus for communication in a oneM2M system in accordance with still another embodiment of the present invention.
  • Figure 22 is a schematic block diagram of an apparatus for communication in a oneM2M system in accordance with still another embodiment of the present invention.
  • FIG. 23 is a schematic block diagram of an apparatus for communication in a oneM2M system in accordance with an embodiment of the present invention.
  • FIG. 1 is a schematic diagram of a system scenario of an embodiment of the present invention.
  • the oneM2M system applicable to the embodiments of the present invention includes an Originator, N transitive CSEs (such as CSE1, ..., CSEN in FIG. 1) and Hosting CSE.
  • the Originator in the embodiment of the present invention may be an AE or a CSE.
  • the Hosting CSE in the embodiment of the present invention is a CSE that stores a target resource.
  • the Originator can send a request message to the Hosting CSE requesting access to the target resource.
  • the request message sent by the Originator can be forwarded to the Hosting CSE after being forwarded by the transit CSE.
  • step 101 the Originator sends a request message to the Hosting CSE requesting the target resource stored in the Hosting CSE.
  • CSE1 first receives the request message.
  • Step 102 relay CSE1 may not support the ⁇ request> resource type.
  • the relay CSE1 does not create a ⁇ request> resource, it replies to the message that the ⁇ request> resource failed to be created.
  • the N+1th transit or Hosting CSE cannot create a ⁇ request> resource, reply to the message that the ⁇ request> resource failed to be created.
  • the process by the Originator requesting the Hosting CSE to operate on the target resource is terminated.
  • an entity sends a request message to the next entity.
  • the transit CSE1 sends a request message to the transit CSE2.
  • the transit CSE N+1 sends a request message to the managed CSE.
  • the entity CSE (which may be a transit CSE, or a hosted CSE) determines whether to create a ⁇ request> resource. When the entity cannot create a ⁇ request> resource, it replies to the message that the ⁇ request> resource failed to be created. In order to continue the communication process, it is necessary to bypass or transparently pass the entity that does not create the ⁇ request> resource to implement the process of continuing communication.
  • the application scenario of the embodiment of the present invention is to perform the process of requesting the Hosting CSE to perform the operation on the target resource by determining whether to create the ⁇ request> resource after receiving the request message, and continuing to perform the operation by the Originator to the Hosting CSE according to the determined result.
  • Embodiment 1 is a diagrammatic representation of Embodiment 1:
  • FIG. 2 is a schematic flow chart of a method of communication in a oneM2M system according to an embodiment of the present invention.
  • the method of Figure 2 can be performed by a transit CSE.
  • the 201 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 Request Resource Creator parameter.
  • the Request Resource Creator parameter is a default value or an identifier of an entity that created a request ⁇ request> resource for the first request message.
  • the first request message is used by the originating entity Originator to request the hosted CSE of the target resource to operate on the target resource.
  • the oneM2M system of the embodiment of the present invention communicates using the non-blocking synchronous communication mode, after receiving the request message for adding the Request Resource Creator parameter sent by the previous entity, The request message is forwarded to the next entity by the entity that does not create the ⁇ request> resource, so that the communication can still continue when the local entity ⁇ request> resource creation fails.
  • the default value refers to the initial value of an attribute and parameter before it is modified.
  • the default is the 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 (English: response type, abbreviated as RT) parameter.
  • RT response type
  • the request message may include an identifier of the Originator and an identifier of the Hosting CSE where the target resource is located.
  • the Originator in the embodiment of the present invention may be an AE or a CSE, which is not limited by the present invention.
  • the first request message includes a Request Resource Creator parameter, the Request Resource Creator parameter being a default value or an identifier of an entity that created the request ⁇ request> resource for the first request message.
  • the Request Resource Creator parameter in the first request message sent by the Originator to the transit CSE1 is a default value.
  • the CSE1 forwards the first request message sent by the Originator to the transit CSE1 to the CSE2.
  • the Request Resource Creator parameter in the first request message is still the default value.
  • the Request Resource Creator parameter in the first request message sent by the Originator to the transit CSE1 is a default value.
  • the request resource Creator parameter included in the first request message sent by the transit CSE2 to the next entity is the entity that created the ⁇ request> resource. Identifier, CSE1-ID.
  • the identifier of the entity is not limited in the embodiment of the present invention.
  • the embodiment of the present invention is merely exemplified by taking the ID of the entity as an example, but the present invention is not limited thereto.
  • the format of the ID is not limited in the embodiment of the present invention.
  • the CSE-ID format can be: /CSE090112//www.m2mprovider.com/C3219.
  • the AE-ID format can be: /m2m.prov.com/CSE3219/C9886.
  • embodiments of the invention are not limited thereto.
  • the transit CSE when the transit CSE does not create a ⁇ request> resource for the request message, the transit CSE receives the first reply message sent by the next entity, and sends the first reply message to the upper entity.
  • the first reply message includes the next one created for the first request message.
  • Request> The address information of the ⁇ request> resource created by the entity of the resource.
  • the first reply message may also include an identifier of the next entity that creates the ⁇ request> resource for the request message, an identifier of the entity that created the ⁇ request> resource for the request message, or an identifier of the Originator.
  • the first reply message is used to reply to the address information of the ⁇ request> resource created by the entity that creates the ⁇ request> resource for the request message to the next entity.
  • transiting CSE2 does not create a ⁇ request> resource.
  • the transit CSE2 receives the reply message sent by the CSE3 and forwards the reply message to the transit CSE1.
  • the reply message sent by the transit CSE3 includes the identifier of the Hosting CSE, the identifier of the transit CSE1, and the address of the ⁇ request> resource created by the entity that creates the ⁇ request> resource for the request message. information.
  • the reply message sent by the transit CSE3 includes the identifier of the Hosting CSE, the identifier of the Originator, and the address information of the ⁇ request> resource created by the entity that creates the ⁇ request> resource for the request message. .
  • the next entity that creates a ⁇ request> resource for the request message can be a transit CSE or a Hosting CSE.
  • the address information of the ⁇ request> resource is not limited in the embodiment of the present invention.
  • the address information of the ⁇ request> resource may be a universal resource identifier (English: Uniform Resource Identifier, URI for short) or a resource identifier (Resource ID, Resource ID for short).
  • the embodiment of the present invention is exemplified by taking the address information of the ⁇ request> resource as a URI or a Resource ID as an example.
  • the format of the identifier is not limited in the embodiment of the present invention.
  • the Resource ID may be in the format: streetX/houseY/roomZ/temperature, which is used to characterize the address of the temperature of the room Z of the building Y storing the street X.
  • the transit CSE when the relay CSE does not create a ⁇ request> resource for the request message, the transit CSE receives the first acquisition request message sent by the previous entity, and forwards the first acquisition request message to the next entity.
  • the first acquisition request message is used to request the entity that creates the ⁇ request> resource to obtain the processing result of the target resource.
  • the first acquisition request message includes address information of the ⁇ request> resource created by the entity that creates the ⁇ request> resource for the next request message.
  • the first acquisition request message may further include an identifier of the Originator or an identifier of an entity that created the ⁇ request> resource for the first request message.
  • the transit CSE After forwarding the first acquisition request message to the next entity, the transit CSE receives the second reply message sent by the next entity, and forwards the second reply message to the next entity.
  • the first The get request message is used to request the entity that creates the ⁇ request> resource for the request message to obtain the processing result of the target resource.
  • the second reply message includes the result of processing the target resource.
  • Receiving the second reply message sent by the next entity includes receiving a processing result of the target resource sent by the next entity. In this way, when the transit CSE does not create a ⁇ request> resource, 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 next entity that creates the ⁇ request> resource for the request message, an identifier of the entity that created the ⁇ request> resource for the request message, or an identifier of the Originator.
  • the transit CSE2 receives the first acquisition request message sent by the relay CSE1, and after receiving the first acquisition request message, forwards the first acquisition request message to the transit CSE3.
  • the transit CSE1 creates a ⁇ request> resource
  • the first get request message sent by the transit CSE1 includes the identifier of the transit CSE1 and the address information of the ⁇ request> resource created by the entity that creates the ⁇ request> resource.
  • the first get request message sent by the transit CSE1 includes the identifier of the Originator and the address information of the ⁇ request> resource created by the entity that creates the ⁇ request> resource.
  • the transit CSE2 After receiving the second reply message sent by the relay CSE3, the transit CSE2 forwards the second reply message to the transit CSE1.
  • the second reply message may include an identifier of an entity that creates a ⁇ request> resource for the target resource, an identifier of the transit CSE1, and a processing result of the target resource.
  • the second reply message may include an identifier of an entity that creates a ⁇ request> resource for the target resource, an identifier of the Originator, and a processing result of the target resource.
  • the address information of the ⁇ request> resource may be a URI or a Resource ID, which is not limited in this embodiment of the present invention.
  • the transit CSE may also determine 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 by sending the first request message to the next entity. In this way, communication can be continued regardless of whether the entity creates a ⁇ request> resource or does not create a ⁇ request> resource to further enhance communication flexibility.
  • the transit CSE may be based on capacity and/or supported ⁇
  • the request> resource type determines whether a ⁇ request> resource is created for the first request message.
  • the transit CSE can determine whether to create a ⁇ request> resource for the request message according to its own situation. For example, when the transit CSE does not support the ⁇ request> resource type, it is determined that the transit CSE does not create a ⁇ request> resource.
  • the transit CSE capacity When the transit CSE capacity is limited, it is determined that the CSE does not create a ⁇ request> resource.
  • the limited capacity of the transit CSE may be insufficient for the remaining capacity to save the created ⁇ request> resource. It is also possible that the processing result of the target resource has no value for the transit CSE, and the remaining capacity of the transit CSE is limited. Therefore, the transit CSE determines not to create the ⁇ request> resource according to its own policy. The transit CSE determines that the ⁇ request> resource is not created. It may also be that the transit CSE has sufficient capacity to save the ⁇ request> resource, but the processing result of the target resource has no value for the transit CSE, and the transit CSE determines not to create the ⁇ request> resource.
  • the relay CSE may be exemplified by determining whether to create a ⁇ request> resource for the request message according to the capacity and/or the supported ⁇ request> resource type, but the present invention is not limited thereto.
  • the transit CSE may create a ⁇ request> resource.
  • a third reply message is sent to the previous entity.
  • a second request message is generated and a second request message is sent to the next entity.
  • 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.
  • the Request Resource Creator parameter is set to 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 entity that created the ⁇ request> resource for the target resource, or an identifier of the Originator.
  • the transit CSE1 when the relay CSE1 determines to create a ⁇ request> resource, the transit CSE1 creates a ⁇ request1> resource. Then, a third reply message is sent to the next entity Originator.
  • the third reply message may include an identifier of the relay CSE1, an identifier of the Originator, and address information of the ⁇ request1> resource created by the relay CSE1.
  • the transit CSE1 After the transfer CSE1 creates the ⁇ request1> resource, the transit CSE1 generates a second request message.
  • the Request Resource Creator parameter in the second request message may be set to an identifier of the transit CSE1, for example, CSE1-ID. After the transit CSE1 generates the second request message, it forwards the second request message to the transit CSE2.
  • the transit CSE3 when the transfer CSE3 determines to create a ⁇ request> resource, the transit CSE3 creates a ⁇ request3> resource. Then, the last entity transits CSE2 to send a third reply message.
  • 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 CSE3.
  • the transit CSE3 After the CSE3 creates the ⁇ request3> resource, the transit CSE3 generates a second request message.
  • the Request Resource Creator parameter in the second request message may be set to an identifier of the transit CSE3, for example, CSE3-ID. After the transit CSE3 generates the second request message, the second request message is sent to the next entity.
  • the transit CSE when the intermediate CSE creates a ⁇ request> resource for the request message, receives the fourth reply message sent by the next entity. Then, the transit CSE updates the ⁇ request> resource created by the transit CSE according to the fourth reply message. Then, the transit CSE receives the second acquisition request message sent by the previous entity, and sends a fifth reply message to the upper entity.
  • the fourth reply message includes the processing result of the target resource.
  • the second acquisition request message is used by the previous entity to obtain a processing result for the target resource from the transit CSE.
  • the second acquisition request message includes address information of the created ⁇ request> resource.
  • the fifth reply message includes the processing result of the target resource.
  • the fourth reply message may also include an identifier of the next entity that creates the ⁇ request> resource for the request message, and an identifier of the transit CSE.
  • the second acquisition request message may further include an identifier of the previous 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.
  • the transit CSE1 receives the fourth reply message sent by the next entity to the CSE2. Then, the ⁇ request1> resource created by the relay CSE1 is updated according to the fourth reply message. Then, the transit CSE1 receives the second acquisition request message sent by the previous entity Originator, and sends a fifth reply message to the upper entity.
  • the relay CSE2 does not create a ⁇ request> resource
  • the transit CSE3 creates a ⁇ request2> resource
  • the fourth reply message may include an identifier of the transit CSE3, an identifier of the transit CSE1, and a processing result of 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.
  • the transit CSE3 receives the fourth reply message sent by the next entity to the CSE2. Then, the ⁇ request3> resource created by the relay CSE3 is updated according to the fourth reply message. Then, the transit CSE3 receives the last entity to send the CSE2 to send The second acquisition request message, and sends a fifth reply message to the upper entity relay CSE2.
  • the relay CSE2 does not create a ⁇ request> resource
  • the fourth reply message may include an identifier of the transit CSE3, an identifier of the next entity that creates the ⁇ request> resource, and an identifier for the target resource. process result.
  • the second acquisition request message may include an identifier of the relay CSE1 and address information of the ⁇ request3> resource.
  • the fifth reply message includes an identifier of the transit CSE1, an identifier of the transit CSE3, and a processing result for the target resource.
  • the embodiment of the present invention is applicable to the case where the Hosting CSE needs to create a ⁇ request> resource.
  • the transit CSE can decide whether to create a ⁇ request> resource according to its own situation.
  • the CSE can determine whether the local entity is a transit CSE or a Hosting CSE according to parameters carried in the request message.
  • Embodiment 2 is a diagrammatic representation of Embodiment 1:
  • FIG. 3 is a schematic flowchart of a method for communication in a oneM2M system according to another embodiment of the present invention.
  • the method of Figure 3 can be performed by a transit CSE.
  • 301 Receive a first request message in a non-blocking synchronous communication mode sent by a previous entity.
  • the first request message is used by the originating entity Originator to request the hosted CSE of the target resource to operate on the target resource.
  • the request resource creator Request Resource Creator parameter is generated.
  • the Request Resource Creator parameter is set to the default value or the identifier of the entity that created the request ⁇ request> resource for the first request message.
  • the Request Resource Creator parameter is generated by the entity that does not create the ⁇ request> resource, and then the next entity is sent, including The request message of the Request Resource Creator parameter, so that the local entity ⁇ request> resource creation can still continue to communicate when the resource creation 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 the RT parameter, and when the RT parameter is set to "nonBlockingRequestSynch", it indicates that the request is to communicate in the non-blocking synchronization mode.
  • the first request message may include an identifier of the Originator and a Hosting CSE where the target resource is located Identifier.
  • the Originator in the embodiment of the present invention may be an AE or a CSE, which is not limited by the present invention.
  • the transit CSE may generate a Request Resource Creator parameter.
  • the Request Resource Creator parameter can be set to the default value or the identifier of the last entity that created the request ⁇ request> resource for the request message.
  • the Request Resource Creator parameter can be set to the default value.
  • the Request Resource Creator parameter can be set to the identifier of the entity that created the request ⁇ request> resource for the request message.
  • a second request message is generated according to the Request Resource Creator parameter.
  • the second request message includes the Request Resource Creator parameter.
  • a second request message is sent to the next entity.
  • Sending the second request message to the next entity here includes sending the Request Resource Creator parameter.
  • the Request Resource Creator parameter is not included in the request message sent by the Originator to the transit CSE1.
  • the transit CSE1 generates a Request Resource Creator parameter and saves the Request Resource Creator parameter in the received request message.
  • the relay CSE1 sends a request message including the Request Resource Creator parameter to the transit CSE2.
  • the request message Creator parameter is not included in the request message sent by the transit CSE N to the transit CSE N+1.
  • the transit CSE N+1 generates a Request Resource Creator parameter and saves 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.
  • the transit CSE when the transit CSE does not create a ⁇ request> resource for the request message, the transit CSE receives the first reply message sent by the next entity, and sends the first reply message to the upper entity.
  • the first reply message includes address information of a ⁇ request> resource created by an entity that creates a ⁇ request> resource for the first request message.
  • the first reply message may also include an identifier of the next entity that creates the ⁇ request> resource for the request message, an identifier of the entity that created the ⁇ request> resource for the request message, or an identifier of the Originator.
  • the first reply message is used to reply to the next entity to create a ⁇ request> resource for the request message.
  • transiting CSE2 does not create a ⁇ request> resource.
  • the transit CSE2 receives the reply message sent by the CSE3 and forwards the reply message to the transit CSE1.
  • the reply message sent by the transit CSE3 includes the identifier of the Hosting CSE, the identifier of the transit CSE1, and the address of the ⁇ request> resource created by the entity that creates the ⁇ request> resource for the request message. information.
  • the reply message sent by the transit CSE3 includes the identifier of the Hosting CSE, the identifier of the Originator, and the address information of the ⁇ request> resource created by the entity that creates the ⁇ request> resource for the request message. .
  • the next entity that creates a ⁇ request> resource for the request message can be a transit CSE or a Hosting CSE.
  • the transit CSE when the relay CSE does not create a ⁇ request> resource for the request message, the transit CSE receives the first acquisition request message sent by the previous entity, and forwards the first acquisition request message to the next entity.
  • the first acquisition request message is used to request the entity that creates the ⁇ request> resource to obtain the processing result of the target resource.
  • the first acquisition request message includes address information of the ⁇ request> resource created by the entity that creates the ⁇ request> resource for the next request message.
  • the first acquisition request message may further include an identifier of the Originator or an identifier of an entity that created the ⁇ request> resource for the first request message.
  • the transit CSE After forwarding the first acquisition request message to the next entity, the transit CSE receives the second reply message sent by the next entity, and forwards the second reply message to the next entity.
  • the first acquisition request message is used to request an entity that creates a ⁇ request> resource for the request message to obtain a processing result of the target resource.
  • the second reply message includes the result of processing the target resource.
  • Receiving the second reply message sent by the next entity includes receiving a processing result of the target resource sent by the next entity. In this way, when the transit CSE does not create a ⁇ request> resource, 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 next entity that creates the ⁇ request> resource for the request message, an identifier of the entity that created the ⁇ request> resource for the request message, or an identifier of the Originator.
  • the transit CSE2 receives the first acquisition request message sent by the relay CSE1, and after receiving the first acquisition request message, forwards the first acquisition request message to the transit CSE3.
  • transfer CSE1 The first acquisition request message sent includes the identifier of the relay CSE1 and the address information of the ⁇ request> resource created by the entity that creates the ⁇ request> resource.
  • the first get request message sent by the transit CSE1 includes the identifier of the Originator and the address information of the ⁇ request> resource created by the entity that creates the ⁇ request> resource.
  • the transit CSE2 After receiving the second reply message sent by the relay CSE3, the transit CSE2 forwards the second reply message to the transit CSE1.
  • the second reply message may include an identifier of an entity that creates a ⁇ request> resource for the target resource, an identifier of the transit CSE1, and a processing result of the target resource.
  • the second reply message may include an identifier of an entity that creates a ⁇ request> resource for the target resource, an identifier of the Originator, and a processing result of the target resource.
  • the address information of the ⁇ request> resource may be a URI or a Resource ID, which is not limited in this embodiment of the present invention.
  • the transit CSE may also determine 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 by sending the first request message to the next entity. In this way, communication can be continued regardless of whether the entity creates a ⁇ request> resource or does not create a ⁇ request> resource to further enhance communication flexibility.
  • the transit CSE can determine whether to create a ⁇ request> resource for the request message according to its own situation.
  • 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 create a ⁇ request> resource.
  • a third reply message is sent to the previous entity.
  • a third request message is generated and a third request message is sent to the next entity.
  • 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.
  • the Request Resource Creator parameter is set to 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 further include an identifier of the transit CSE, and the last one for the target resource The identifier of the entity that built the ⁇ request> resource or the identifier of the Originator.
  • the transit CSE1 when the relay CSE1 determines to create a ⁇ request> resource, the transit CSE1 creates a ⁇ request1> resource. Then, a third reply message is sent to the next entity Originator.
  • the third reply message may include an identifier of the relay CSE1, an identifier of the Originator, and address information of the ⁇ request1> resource created by the relay CSE1.
  • the transit CSE1 After the transfer CSE1 creates the ⁇ request1> resource, the transit CSE1 generates a third request message.
  • the Request Resource Creator parameter in the third request message may be set to an identifier of the transit CSE1, for example, CSE1-ID. After the transit CSE1 generates the third request message, it forwards the third request message to the transit CSE2.
  • the transit CSE3 when the transfer CSE3 determines to create a ⁇ request> resource, the transit CSE3 creates a ⁇ request3> resource. Then, the last entity transits CSE2 to send a third reply message.
  • 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 CSE3.
  • the transit CSE3 After the CSE3 creates the ⁇ request3> resource, the transit CSE3 generates a third request message.
  • the Request Resource Creator parameter in the third request message may be set to an identifier of the transit CSE3, for example, CSE3-ID. After the transit CSE3 generates the third request message, the third request message is sent to the next entity.
  • the transit CSE when the intermediate CSE creates a ⁇ request> resource for the request message, receives the fourth reply message sent by the next entity. Then, the transit CSE updates the ⁇ request> resource created by the transit CSE according to the fourth reply message. Then, the transit CSE receives the second acquisition request message sent by the previous entity, and sends a fifth reply message to the upper entity.
  • the fourth reply message includes the processing result of the target resource.
  • the second acquisition request message is used by the previous entity to obtain a processing result for the target resource from the transit CSE.
  • the second acquisition request message includes address information of the created ⁇ request> resource.
  • the fifth reply message includes the processing result of the target resource.
  • the fourth reply message may also include an identifier of the next entity that creates the ⁇ request> resource for the request message, and an identifier of the transit CSE.
  • the second acquisition request message may further include an identifier of the previous 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.
  • the transit CSE1 receives the fourth reply message sent by the next entity to the CSE2. Then, update the relay CSE1 according to the fourth reply message. Created ⁇ request1> resource. Then, the transit CSE1 receives the second acquisition request message sent by the previous entity Originator, and sends a fifth reply message to the upper entity.
  • the relay CSE2 does not create a ⁇ request> resource
  • the transit CSE3 creates a ⁇ request2> resource
  • the fourth reply message may include an identifier of the transit CSE3, an identifier of the transit CSE1, and a processing result of 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.
  • the transit CSE3 receives the fourth reply message sent by the next entity to the CSE2. Then, the ⁇ request3> resource created by the relay CSE3 is updated according to the fourth reply message. Then, the transit CSE3 receives the second acquisition request message sent by the previous entity transit CSE2, and sends a fifth reply message to the next entity transit CSE2.
  • the relay CSE2 does not create a ⁇ request> resource
  • the fourth reply message may include an identifier of the transit CSE3, an identifier of the next entity that creates the ⁇ request> resource, and an identifier for the target resource. process result.
  • the second acquisition request message may include an identifier of the relay CSE1 and address information of the ⁇ request3> resource.
  • the fifth reply message includes an identifier of the transit CSE1, an identifier of the transit CSE3, and a processing result for the target resource.
  • the embodiment of the present invention is applicable to the case where the Hosting CSE needs to create a ⁇ request> resource.
  • the transit CSE can decide whether to create a ⁇ request> resource according to its own situation.
  • the CSE can determine whether the local entity is a transit CSE or a Hosting CSE according to parameters carried in the request message.
  • Embodiment 3 is a diagrammatic representation of Embodiment 3
  • FIG. 4 is a schematic flowchart of a method for communication in a oneM2M system according to another embodiment of the present invention.
  • the method of Figure 4 can be performed by a transit CSE.
  • the response type RT parameter carried by the first request message includes a request resource indication field.
  • the first request message is used by the originating entity Originator to request the hosted CSE of the target resource to operate on the target resource.
  • the request resource indication field is a default value or an identifier of an entity that creates a request ⁇ request> resource for the first request message.
  • the RT is utilized.
  • the request resource indication field added in the parameter indicates the identifier of the last entity that created the ⁇ request> resource, so that the entity that does not create the ⁇ request> resource sends the request message to the next entity, so that the ⁇ request> resource creation fails. Communication can still be continued.
  • the Originator in the embodiment of the present invention may be an AE or a CSE, which is not limited by the present invention.
  • 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 the RT parameter.
  • the RT parameter is set to "nonBlockingRequestSynch(null)"
  • the request resource indication field is a default value.
  • the first request message may include an identifier of the Originator and an identifier of the Hosting CSE where the target resource is located.
  • the request resource indication field may also be an identifier of the entity that created the request ⁇ request> resource for the first request message.
  • the request resource indication field may be the default value. If there is an entity that creates a ⁇ request> resource before the transit CSE, then the request resource indication field may be the identifier of the last entity that created the ⁇ request> resource.
  • the RT parameter when it is used to indicate that the request is to communicate in the non-blocking synchronization mode, and the request resource indication field is the default value, the RT parameter may be set to "nonBlockingRequestSynch(null)".
  • the RT parameter can be set to "nonBlockingRequestSynch" when it is only used to indicate that the request is communicating in non-blocking synchronous mode. It is used to indicate that the request communicates in the non-blocking synchronization mode, and the RT parameter when the request resource indication field is the default value is different from the value of the RT parameter used only to indicate that the request to communicate using the non-blocking synchronization mode.
  • the identifier of the entity that creates the ⁇ request> resource is represented by the request resource indication field in the embodiment of the present invention, but the present invention is not limited thereto. It is also possible to use other parameters in the non-blocking communication mode to represent the identifier of the entity that created the ⁇ request> resource.
  • the transit CSE when the transit CSE does not create a ⁇ request> resource for the request message, the transit CSE receives the first reply message sent by the next entity, and sends the first reply message to the upper entity.
  • the first reply message includes address information of a ⁇ request> resource created by an entity that creates a ⁇ request> resource for the first request message.
  • the first reply message can also The identifier of the entity that includes the next ⁇ request> resource for the request message, the identifier of the entity that created the ⁇ request> resource for the request message, or the identifier of the Originator.
  • the first reply message is used to reply to the address information of the ⁇ request> resource created by the entity that creates the ⁇ request> resource for the request message to the next entity.
  • transiting CSE2 does not create a ⁇ request> resource.
  • the transit CSE2 receives the reply message sent by the CSE3 and forwards the reply message to the transit CSE1.
  • the reply message sent by the transit CSE3 includes the identifier of the Hosting CSE, the identifier of the transit CSE1, and the address of the ⁇ request> resource created by the entity that creates the ⁇ request> resource for the request message. information.
  • the reply message sent by the transit CSE3 includes the identifier of the Hosting CSE, the identifier of the Originator, and the address information of the ⁇ request> resource created by the entity that creates the ⁇ request> resource for the request message. .
  • the next entity that creates a ⁇ request> resource for the request message can be a transit CSE or a Hosting CSE.
  • the transit CSE when the relay CSE does not create a ⁇ request> resource for the request message, the transit CSE receives the first acquisition request message sent by the previous entity, and forwards the first acquisition request message to the next entity.
  • the first acquisition request message is used to request the entity that creates the ⁇ request> resource to obtain the processing result of the target resource.
  • the first acquisition request message includes address information of the ⁇ request> resource created by the entity that creates the ⁇ request> resource for the next request message.
  • the first acquisition request message may further include an identifier of the Originator or an identifier of an entity that created the ⁇ request> resource for the first request message.
  • the transit CSE After forwarding the first acquisition request message to the next entity, the transit CSE receives the second reply message sent by the next entity, and forwards the second reply message to the next entity.
  • the first acquisition request message is used to request an entity that creates a ⁇ request> resource for the request message to obtain a processing result of the target resource.
  • the second reply message includes the result of processing the target resource.
  • Receiving the second reply message sent by the next entity includes receiving a processing result of the target resource sent by the next entity. In this way, when the transit CSE does not create a ⁇ request> resource, 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 next entity that creates the ⁇ request> resource for the request message, an identifier of the entity that created the ⁇ request> resource for the request message, or an identifier of the Originator.
  • the transit CSE2 receives the first acquisition request message sent by the relay CSE1, and after receiving the first acquisition request message, forwards the first acquisition request message to the transit CSE3.
  • the transit CSE1 creates a ⁇ request> resource
  • the first get request message sent by the transit CSE1 includes the identifier of the transit CSE1 and the address information of the ⁇ request> resource created by the entity that creates the ⁇ request> resource.
  • the first get request message sent by the transit CSE1 includes the identifier of the Originator and the address information of the ⁇ request> resource created by the entity that creates the ⁇ request> resource.
  • the transit CSE2 After receiving the second reply message sent by the relay CSE3, the transit CSE2 forwards the second reply message to the transit CSE1.
  • the second reply message may include an identifier of an entity that creates a ⁇ request> resource for the target resource, an identifier of the transit CSE1, and a processing result of the target resource.
  • the second reply message may include an identifier of an entity that creates a ⁇ request> resource for the target resource, an identifier of the Originator, and a processing result of the target resource.
  • the address information of the ⁇ request> resource may be a URI or a Resource ID, which is not limited in this embodiment of the present invention.
  • the transit CSE may also determine 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 by sending the first request message to the next entity. In this way, communication can be continued regardless of whether the entity creates a ⁇ request> resource or does not create a ⁇ request> resource to further enhance communication flexibility.
  • the transit CSE can determine whether to create a ⁇ request> resource for the request message according to its own situation.
  • 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 create a ⁇ request> resource.
  • a third reply message is sent to the previous entity.
  • a second request message is generated and a second request message is sent to the next entity.
  • 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.
  • the request resource indication field is set to an 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 entity that created the ⁇ request> resource for the target resource, or an identifier of the Originator.
  • the transit CSE1 when the relay CSE1 determines to create a ⁇ request> resource, the transit CSE1 creates a ⁇ request1> resource. Then, a third reply message is sent to the next entity Originator.
  • the third reply message may include an identifier of the relay CSE1, an identifier of the Originator, and address information of the ⁇ request1> resource created by the relay CSE1.
  • the transit CSE1 After the transfer CSE1 creates the ⁇ request1> resource, the transit CSE1 generates a second request message.
  • the Request Resource Creator parameter in the second request message may be set to an identifier of the transit CSE1, for example, CSE1-ID. After the transit CSE1 generates the second request message, it forwards the second request message to the transit CSE2.
  • the transit CSE3 when the transfer CSE3 determines to create a ⁇ request> resource, the transit CSE3 creates a ⁇ request3> resource. Then, the last entity transits CSE2 to send a third reply message.
  • 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 CSE3.
  • the transit CSE3 After the CSE3 creates the ⁇ request3> resource, the transit CSE3 generates a second request message.
  • the Request Resource Creator parameter in the second request message may be set to an identifier of the transit CSE3, for example, CSE3-ID. After the transit CSE3 generates the second request message, the second request message is sent to the next entity.
  • the transit CSE when the intermediate CSE creates a ⁇ request> resource for the request message, receives the fourth reply message sent by the next entity. Then, the transit CSE updates the ⁇ request> resource created by the transit CSE according to the fourth reply message. Then, the transit CSE receives the second acquisition request message sent by the previous entity, and sends a fifth reply message to the upper entity.
  • the fourth reply message includes the processing result of the target resource.
  • the second acquisition request message is used by the previous entity to obtain a processing result for the target resource from the transit CSE.
  • the second acquisition request message includes address information of the created ⁇ request> resource.
  • the fifth reply message includes the processing result of the target resource.
  • the fourth reply message may also include an identifier of the next entity that creates the ⁇ request> resource for the request message, and an identifier of the transit CSE.
  • the second acquisition request message may further include an identifier of the previous 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.
  • the transit CSE1 receives the fourth reply message sent by the next entity to the CSE2. Then, the ⁇ request1> resource created by the relay CSE1 is updated according to the fourth reply message. Then, the transit CSE1 receives the second acquisition request message sent by the previous entity Originator, and sends a fifth reply message to the upper entity.
  • the relay CSE2 does not create a ⁇ request> resource
  • the transit CSE3 creates a ⁇ request2> resource
  • the fourth reply message may include an identifier of the transit CSE3, an identifier of the transit CSE1, and a processing result of 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.
  • the transit CSE3 receives the fourth reply message sent by the next entity to the CSE2. Then, the ⁇ request3> resource created by the relay CSE3 is updated according to the fourth reply message. Then, the transit CSE3 receives the second acquisition request message sent by the previous entity transit CSE2, and sends a fifth reply message to the next entity transit CSE2.
  • the relay CSE2 does not create a ⁇ request> resource
  • the fourth reply message may include an identifier of the transit CSE3, an identifier of the next entity that creates the ⁇ request> resource, and an identifier for the target resource. process result.
  • the second acquisition request message may include an identifier of the relay CSE1 and address information of the ⁇ request3> resource.
  • the fifth reply message includes an identifier of the transit CSE1, an identifier of the transit CSE3, and a processing result for the target resource.
  • the embodiment of the present invention is applicable to the case where the Hosting CSE needs to create a ⁇ request> resource.
  • the transit CSE can decide whether to create a ⁇ request> resource according to its own situation.
  • the CSE can determine whether the local entity is a transit CSE or a Hosting CSE according to parameters carried in the request message.
  • Embodiment 4 is a diagrammatic representation of Embodiment 4:
  • FIG. 5 is a schematic flowchart of a method for communication in a oneM2M system according to another embodiment of the present invention.
  • the method of Figure 5 can be performed by a transit CSE.
  • 501 Receive a request message in a non-blocking synchronous communication mode sent by a previous entity.
  • the request message is used by the Originator to request the Hosting CSE where the target resource is located to operate on the target resource.
  • the indication message is sent to the upper entity.
  • the indication message includes requesting the resource not to create a Request Not Create parameter.
  • the Request Not Create parameter includes the identifier of the next entity.
  • the indication message is used to indicate that the previous entity sends the first request message to the next entity.
  • the transit CSE adds a new Request Not Create parameter to indicate that the request is not created after receiving the request message sent by the previous entity to operate the target resource.
  • the request> resource entity sends a request message to other entities to continue communication when the ⁇ request> resource creation fails.
  • the request message is used by the Originator to request the Hosting CSE to operate on the target resource.
  • the request message carries the RT parameter, and when the RT parameter is set to "nonBlockingRequestSynch", it indicates that the request is to communicate in the non-blocking synchronization mode.
  • the request message may include an identifier of the Originator and an identifier of the Hosting CSE where the target resource is located.
  • the Originator in the embodiment of the present invention may be an AE or a CSE, which is not limited by the present invention.
  • the previous entity can be a transit CSE or an Originator.
  • the next entity can be a transit CSE or a Hosting CSE.
  • the embodiment of the present invention can determine whether to create a ⁇ request> resource for the request message according to its own situation before the intermediate CSE sends the indication message to the upper entity.
  • 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 regardless of whether the entity creates a ⁇ request> resource or does not create a ⁇ request> resource to further enhance communication flexibility.
  • the transit CSE when the transit CSE does not support the ⁇ request> resource type, it is determined that the transit CSE does not create a ⁇ request> resource. When the remaining capacity of the transit CSE is insufficient, it is not enough to save the created ⁇ request> resource and it is determined that the ⁇ request> resource is not created. When the transit CSE does not need to save the processing result of the target resource, and the remaining capacity of the transit CSE is limited, the transit CSE may determine not to create the ⁇ request> resource according to its own policy. The transit CSE can also not create a ⁇ request> resource when the transfer CSE does not need to save the processing result of the target resource although there is sufficient capacity to save the ⁇ request> resource.
  • Embodiment 5 is a diagrammatic representation of Embodiment 5:
  • FIG. 6 is a schematic flowchart of a method for communication in a oneM2M system according to still another embodiment of the present invention.
  • the method of Figure 6 can be performed by a transit CSE.
  • the indication message includes requesting the resource not to create a Request Not Create parameter.
  • the Request Not Create parameter includes an identifier of the first entity.
  • the indication message is used to instruct the local entity to send a request message to the first entity.
  • the oneM2M system of the embodiment of the present invention communicates using the non-blocking synchronous communication mode
  • the transit CSE receives the request message sent by the previous entity to operate the target resource
  • the previous entity adds the new Request Not Create parameter.
  • An entity that does not create a ⁇ request> resource sends a request message to other entities to continue communication when the ⁇ request> resource creation fails.
  • the request message is used by the Originator to request the Hosting CSE to operate on the target resource.
  • the request message carries the RT parameter, and when the RT parameter is set to "nonBlockingRequestSynch", it indicates that the request is to communicate in the non-blocking synchronization mode.
  • the request message may include an identifier of the Originator and an identifier of the Hosting CSE where the message target resource is located.
  • the next entity sends an indication message to the transit CSE.
  • the indication message is used to instruct the local entity (ie, the transit CSE) to send a request message to another entity (eg, the first entity).
  • the indication message includes requesting the resource not to create a Request Not Create parameter.
  • the Request Not Create parameter includes an identifier of the first entity.
  • FIG. 7 is a schematic flowchart of a method for communication in a oneM2M system according to still another embodiment of the present invention.
  • the method of Figure 7 can be performed by the Hosting CSE.
  • the ⁇ request> resource is not created for the request message, send the indication information to the transit CSE according to the request message.
  • the indication information is used to indicate that the transit CSE resends the request message after the first time period.
  • the Hosting CSE After receiving the request message sent by the previous entity to operate the target resource, the Hosting CSE sends an indication message to the previous entity to indicate that the previous entity resends the request message after a period of time, so that the ⁇ request> resource creation fails. You can still continue to communicate.
  • the Originator in the embodiment of the present invention may be an AE or a CSE, which is not limited by the present invention.
  • the indication message may include an identifier of the previous entity, an identifier of the transit CSE, and a Request Not Create parameter.
  • the time when the transit CSE resends the request message is located at the time required for the Hosting CSE to process the target resource. In this way, when the Hosting CSE does not create the ⁇ request> resource, the process of requesting the target resource by the Originator to the Hosting CSE can be continued. In turn, the waste of resources caused by the termination of communication and a large amount of signaling overhead are avoided.
  • the Hosting CSE when receiving the request message sent by the transit CSE and not creating the ⁇ request> resource, the Hosting CSE processes the target resource according to the request message, and obtains a processing result of the target resource.
  • the Hosting CSE does not create a ⁇ request> resource and cannot save the processing result of the target resource. However, the processing result of the target resource can be sent to the relay.
  • the Hosting CSE receives the request message for the retransmission of the CSE after a period of time. Then, a reply message is sent to the transit CSE according to the request message.
  • the sending of the reply message by the Hosting CSE to the transit CSE includes sending the 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 a result of processing the target resource.
  • the transit CSE2 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 CSE1 in the previous entity.
  • the indication message may include an identifier of the transit CSE2, an identifier of the 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 the process of requesting the Hosting CSE to operate on the target resource by the Originator.
  • the Request Not Create parameter includes the identifier of the next entity relaying CSE4.
  • the transit CSE1 After receiving the indication message sent by the relay CSE2, the transit CSE1 cancels the registration information on the transit CSE2 and registers it on the transit CSE3. Communication is established between the transit CSE1 and the transit CSE3.
  • the transit CSE1 may send a request message to the transit CSE3 to skip the process of the transit CSE2 to continue to perform the operation of the target resource by the Originator to the Hosting CSE.
  • the embodiment of the present invention avoids the successful creation of the ⁇ request> resource in the previous N transits by skipping the transit CSE that does not create the ⁇ request> resource, and the N+1th transitive CSE does not create the ⁇ request> resource.
  • the N+1th transit CSE replies to create a ⁇ request> resource, causing a large amount of signaling overhead and resource waste.
  • the first duration is greater than the duration required to process the target resource.
  • the Hosting CSE may resend the indication message to the transit CSE.
  • the indication message is used to indicate that the relay sends the request message again after a period of time.
  • the Hosting CSE may discard the processing result of the target resource.
  • the transit CSE can send the request message to the Hosting CSE again after the third time.
  • the Hosting CSE processes the request message as a new information, and restarts the processing of the target resource to obtain the processing result of the target resource.
  • the first duration, the second duration, and the third duration are not limited.
  • the second duration is greater than the first duration.
  • the third duration is greater than the second duration.
  • FIG. 8 is a schematic flowchart of a method for communication in a oneM2M system according to still another embodiment of the present invention.
  • the method of Figure 8 can be performed by the peer entity of the Hosting CSE.
  • the 802. Receive an indication information that is sent by the Hosting CSE according to the request message.
  • the indication message is used to indicate that the request message is resent after the first time period.
  • the oneM2M system in the embodiment of the present invention uses the non-blocking synchronous communication mode to communicate, after the next entity sends a request message requesting operation on the target resource, the local entity is instructed to receive the indication message sent by the next entity. The request message is then resent, so that the ⁇ request> resource creation can still continue to communicate when it fails.
  • the transit CSE may resend the request message to the Hosting CSE after a period of time.
  • the transit CSE can receive the reply message sent by the Hosting CSE after the Hosting CSE processes the target resource.
  • the reply message includes the result of processing the target resource.
  • the relay CSE receiving the reply message includes receiving the processing result of the target resource.
  • the transit CSE can 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 target resource by the Originator to the Hosting CSE can be continued. In turn, resource waste and a large amount of signaling overhead caused by communication failure can be avoided.
  • the first duration is greater than the duration required to process the target resource.
  • the Hosting CSE may resend the indication message to the transit CSE.
  • the indication message is used to indicate that the relay sends the request message again after a period of time.
  • the Hosting CSE may discard the processing result of the target resource.
  • the transit CSE can send the request message to the Hosting CSE again after the third time.
  • the Hosting CSE processes the request message as a new information, and restarts the processing of the target resource to obtain the processing result of the target resource.
  • the peer entity of the Hosting CSE is used as the transit CSE3 as an example.
  • the transit CSE3 resends the request message to the Hosting CSE after the first time the request message is sent for a period of time to obtain the processing result of the target resource sent by the Hosting CSE.
  • the length of time may be greater than the time required for the Hosting CSE to complete processing the target resource.
  • FIG. 9 is a schematic interaction flow diagram of a method of communication in a oneM2M system in accordance with an embodiment of the present invention.
  • the embodiment of FIG. 9 does not create a ⁇ request> resource by three transit CSEs, and only the Hosting CSE creates a ⁇ request> resource as an example for exemplary description.
  • the Originator sends a request message to the Hosting CSE, and the transit CSE1 receives the request message.
  • the Originator sends a request message to the Hosting CSE where the target resource is located.
  • the request message carries the RT parameter.
  • the RT parameter is set to “nonBlockingRequestSynch”
  • the request indicates that the request is adopted.
  • 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 Request Resource Creator parameter.
  • the Request Resource Creator parameter is the default.
  • the Originator completes registration on the transit CSE1, and the transit CSE1 can first receive the request message.
  • the transit CSE1 forwards the request message to the transit CSE2.
  • the Originator completes registration on the transit CSE1, and the transit CSE1 first receives the request message sent by the previous entity Originator.
  • the transit CSE1 can determine whether to create a ⁇ request> resource according to its own situation. For example, if the transit CSE1 does not support the ⁇ request> resource type, then it is determined that the ⁇ request> resource is not created. When the transit CSE1 determines not to create the ⁇ request> resource, the transit CSE1 forwards the request message to the transit CSE2.
  • the transit CSE2 forwards the request message to the transit CSE3.
  • the transit CSE2 receives the request message sent by the previous entity to transfer CSE1.
  • the transit CSE2 can also determine whether to create a ⁇ request> resource according to its own situation. For example, if the capacity of the transit CSE2 is limited, the transit CSE2 determines not to create a ⁇ request> resource. When the transit CSE2 determines not to create the ⁇ request> resource, the transit CSE2 forwards the request message to the transit CSE3.
  • the transit CSE3 forwards the request message to the Hosting CSE.
  • the transit CSE3 receives the request message sent by the previous entity to transfer CSE2.
  • the transit CSE3 can also determine whether to create a ⁇ request> resource according to its own situation. When the transit CSE3 determines not to create the ⁇ request> resource, the transit CSE3 forwards the request message to the Hosting CSE.
  • Hosting CSE processes the target resource and creates a ⁇ request> resource.
  • the Hosting CSE After receiving the request message sent by CSE3, the Hosting CSE processes the target resource. At the same time, the Hosting CSE can create a ⁇ request> resource after receiving the request message sent by the CSE3.
  • Hosting CSE sends a reply message to transit CSE3.
  • the Hosting CSE After the Hosting CSE creates the ⁇ request> resource, it sends a reply message to the CSE3 in the previous entity.
  • the reply message sent by the Hosting CSE may include the identifier of the Hosting CSE, the identifier of the Originator, and the address information of the ⁇ request> resource created by the Hosting CSE.
  • the address information of the ⁇ request> resource may be a URI or an ID, which is not limited by the embodiment of the present invention.
  • the transit CSE3 forwards the reply message to the transit CSE2.
  • the transit CSE3 After receiving the reply message sent by the Hosting CSE, the transit CSE3 forwards the reply message to the CSE2 in the previous entity.
  • the transit CSE2 forwards the reply message to the transit CSE1.
  • the transit CSE2 After receiving the reply message sent by the relay CSE3, the transit CSE2 forwards the reply message to the CSE1 in the previous entity.
  • the transit CSE1 forwards the reply message to the Originator.
  • the transit CSE1 After receiving the reply message sent by the relay CSE2, the transit CSE1 forwards the reply message to the next entity Originator.
  • the Originator sends a get request message to the transit CSE1.
  • the Originator After receiving the reply message sent by CSE1, the Originator sends a Get Request message to CSE1 in the next entity.
  • the get request message sent by the Originator may include the identifier of the Originator and the address information of the Hosting CSE creation ⁇ request> resource.
  • the get request message is used to obtain the processing result of the target resource from the Hosting CSE requesting the ⁇ request> resource.
  • the transit CSE1 first receives the get request message.
  • the transit CSE1 forwards the acquisition request message to the transit CSE2.
  • the transit CSE1 After receiving the get request message sent by the Originator, the transit CSE1 forwards the get request message to the next entity transfer CSE2.
  • the transit CSE2 forwards the acquisition request message to the transit CSE3.
  • the transit CSE2 After receiving the acquisition request message sent by the relay CSE1, the transit CSE2 forwards the acquisition request message to the next entity transfer CSE3.
  • the transit CSE3 forwards the acquisition request message to the Hosting CSE.
  • the transit CSE3 After receiving the acquisition request message sent by the relay CSE2, the transit CSE3 forwards the acquisition request message to the next entity Hosting CSE.
  • Hosting CSE updates the ⁇ request> resource created by Hosting CSE itself.
  • the Hosting CSE After receiving the acquisition request message sent by the CSE3, the Hosting CSE obtains the processing result of the target resource if the processing of the target resource has been completed. The Hosting CSE saves the processing result of the target resource in the ⁇ request> resource created by itself to update the ⁇ request> resource created by itself.
  • the Hosting CSE sends a reply message to the transit CSE3.
  • the host entity After the Hosting CSE obtains the processing result of the target resource, the host entity sends a reply message to the CSE3.
  • the reply message sent by Hosting CSE includes the identifier of Hosting CSE. The identifier of the Originator and the result of processing the target resource.
  • the Hosting CSE sends a reply message to the transit CSE3, including sending the processing result of the target resource to the transit CSE3.
  • the transit CSE3 forwards the reply message to the transit CSE2.
  • the transit CSE3 After receiving the reply message sent by the Hosting CSE, the transit CSE3 forwards the reply message to the CSE2 to the previous entity, so that the transit CSE2 obtains the processing result of the target resource.
  • the transit CSE2 forwards the reply message to the transit CSE1.
  • the transit CSE2 After receiving the reply message sent by the relay CSE3, the transit CSE2 forwards the reply message to the CSE1 to the intermediate entity, so that the transit CSE1 obtains the processing result of the target resource.
  • the transit CSE1 forwards the reply message to the Originator.
  • the transit CSE1 After receiving the reply message sent by the relay CSE2, the transit CSE1 forwards the reply message to the next entity Originator, so that the Originator obtains the processing result of the target resource.
  • the Originator receives the reply message sent by the relay CSE1, including receiving the processing result of the target resource.
  • the Originator obtains the processing result of the target resource, that is, completes the communication process of the entire Originator requesting the target resource from the Hosting CSE.
  • the embodiment of FIG. 9 is an example in which the Originator sends a request message to the Hosting CSE, and after three transitive CSEs, and the three transitive CSEs do not create a ⁇ request> resource, the embodiment of the present invention does not perform the number of the transit CSE. limit.
  • the embodiment of FIG. 10 will send a request message to the Hosting CSE by the Originator, and after three CSEs are transferred, the CSE1 is created to create a ⁇ request> resource, and the transfer CSE2 and the transit CSE3 do not create a ⁇ request> resource as an example for exemplary description.
  • FIG. 10 is a schematic interaction flowchart of a method for communication in a oneM2M system according to another embodiment of the present invention.
  • the Originator sends a request message to the Hosting CSE, and the transit CSE1 first receives the request message.
  • the Originator sends a request message to the Hosting CSE where the target resource is located.
  • the request message carries the RT parameter.
  • the RT parameter is set to "nonBlockingRequestSynch"
  • the request message sent by the Originator is used by the Originator to request the Hosting CSE to operate on the target resource.
  • 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 Request Resource Creator parameter.
  • the Request Resource Creator parameter is the default. The Originator completes registration on the transit CSE1, and the transit CSE1 can first receive the request message.
  • the Originator completes registration on the transit CSE1, and the transit CSE1 first receives the request message sent by the previous entity Originator.
  • the transit CSE1 can determine whether to create a ⁇ request> resource according to its own situation. For example, if the transit CSE1 supports the creation of a ⁇ request> resource, it is determined to create a ⁇ request1> resource.
  • the transit CSE1 sends a reply message to the Originator.
  • the transfer CSE1 After the transfer CSE1 creates the ⁇ request1> resource, it sends a reply message to the next entity Originator.
  • the reply message sent by the relay CSE1 may include the identifier of the transit CSE1, the identifier of the Originator, and the address information of the ⁇ request 1> resource created by the transit CSE1.
  • the reply message sent by the relay CSE1 is used to send the address information of the ⁇ request 1> resource created by the relay CSE1 to the originator, so that the originator sends a get request message to the transit CSE1 to obtain the processing result of the target resource.
  • Transit CSE1 generates a request message for transiting CSE1, and sends a request message for relaying CSE1 to CSE2 to the next entity.
  • Transit CSE1 can set the Request Resource Creator parameter to the identifier of the transit CSE1.
  • a request message for relaying CSE1 is generated according to the Request Resource Creator parameter.
  • the request message for transiting CSE1 may include an identifier of the Originator, an identifier of the Hosting CSE, and a request resource creator Request Resource Creator parameter, and the identifier of the transit CSE1 is located in the Request Resource Creator parameter.
  • the transit CSE1 After the transit CSE1 generates the request message for transiting CSE1, the next entity transits CSE2 to send a request message for transiting CSE1.
  • the request message of the transit CSE1 is used to request the processing result of the target resource to the Hosting CSE.
  • the transit CSE2 forwards the CSE3 to the next entity to forward the request message of the relay CSE1.
  • the transit CSE2 After the transit CSE2 receives the request message of the transit CSE1 sent by the relay CSE1, the next entity transits the CSE3 to forward the request message of the transit CSE1.
  • the transit CSE3 forwards the request message of the relay CSE1 to the next entity Hosting CSE.
  • the transit CSE3 After the transit CSE3 receives the request message of the transit CSE1 sent by the relay CSE2, the next entity Hosting CSE forwards the request message of the transit CSE1.
  • Hosting CSE processes the target resource and creates a ⁇ request2> resource.
  • the Hosting CSE After receiving the request message for the relay CSE1 sent by the CSE3, the Hosting CSE starts to Target resources are processed. After receiving the request message of the relay CSE1 sent by the CSE3, the Hosting CSE determines to create the ⁇ request2> resource according to its own situation.
  • Hosting CSE sends a reply message to CSE3 to an entity.
  • the Hosting CSE After the Hosting CSE creates the ⁇ request2> resource, it sends a reply message to the CSE3 to the next entity.
  • the reply message sent by the Hosting CSE may include a Hosting CSE identifier, an identifier of the transit CSE1, and address information of the ⁇ request 2> resource created by the Hosting CSE.
  • the address information of the ⁇ request 2> resource is not limited in the embodiment of the present invention.
  • the address information of the resource can be a URI or a Resource ID.
  • the transit CSE3 forwards the reply message to the transit CSE2.
  • the transit CSE3 After receiving the reply message sent by the Hosting CSE, the transit CSE3 forwards the reply message in step 1008 to the CSE2.
  • the transit CSE2 forwards the reply message to the transit CSE1.
  • the transit CSE2 After receiving the reply message sent by the relay CSE3, the transit CSE2 forwards the reply message in step 1008 to the upper entity CSE1.
  • the transit CSE1 sends a get request message to the transit CSE2.
  • the transit CSE1 After receiving the reply message sent by the relay CSE2, the transit CSE1 sends a get request message to the transit CSE2.
  • the acquisition request message sent by the relay CSE1 may include the identifier of the transit CSE1 and the address information of the ⁇ request2> resource created by the Hosting CSE.
  • the acquisition request message sent by the relay CSE1 is used to obtain the processing result of the target resource from the Hosting CSE requesting the ⁇ request2> resource.
  • the transit CSE2 first receives the get request message.
  • the transit CSE2 forwards the acquisition request message to the transit CSE3.
  • the transit CSE2 After receiving the acquisition request message sent by the relay CSE1, the transit CSE2 forwards the acquisition request message to the next entity transfer CSE3.
  • the transit CSE3 forwards the acquisition request message to the Hosting CSE.
  • the transit CSE3 After receiving the acquisition request message sent by the relay CSE2, the transit CSE3 forwards the acquisition request message to the next entity Hosting CSE.
  • Hosting CSE updates the ⁇ request 2> resource created by Hosting CSE itself.
  • the Hosting CSE After receiving the acquisition request message sent by the CSE3, the Hosting CSE obtains the processing result of the target resource if the processing of the target resource has been completed. The Hosting CSE saves the processing result of the target resource in the ⁇ request2> resource created by itself to update the ⁇ request2> resource.
  • Hosting CSE sends a reply message to transit CSE3.
  • the host entity After the Hosting CSE obtains the processing result of the target resource, the host entity sends a reply message to the CSE3.
  • the reply message sent by the Hosting CSE may include an identifier of the Hosting CSE, an identifier of the transit CSE1, and a processing result of the target resource.
  • the reply message sent by the Hosting CSE to the transit CSE3 includes sending the processing result of the target resource to the transit CSE3.
  • the transit CSE3 forwards the reply message to the transit CSE2.
  • the transit CSE3 After receiving the reply message sent by the Hosting CSE, the transit CSE3 forwards the reply message in step 1015 to the CSE2 to the intermediate entity, so that the transit CSE2 obtains the processing result of the target resource.
  • the transit CSE2 forwards the reply message to the transit CSE1.
  • the transit CSE2 After receiving the second reply message sent by the relay CSE3, the transit CSE2 forwards the reply message in step 1015 to the CSI1 to the intermediate entity, so that the transit CSE1 obtains the processing result of the target resource.
  • the transit CSE1 updates the ⁇ request 1> resource created by the CSE1 itself according to the reply message.
  • the transit CSE1 After receiving the reply message in step 1015 sent by the relay CSE2, the transit CSE1 receives the processing result of the target resource.
  • the transit CSE 1 saves the processing result of the target resource in the ⁇ request 1> resource created by itself to update the ⁇ request1> resource.
  • the Originator sends a get request message to the transit CSE1.
  • Originator sends a Get Request message to CSE1 in the next entity.
  • the get request message sent by the Originator to the transit CSE1 includes the identifier of the Originator and the address information of the ⁇ request1> resource.
  • the Originator sends an Acquire Request message to the transit CSE1 for the Originator to request the transfer CSE1 to obtain the processing result of the target resource.
  • the transit CSE1 sends a reply message to the Originator.
  • the transit CSE1 After receiving the get request message sent by the previous entity Originator, the transit CSE1 sends a reply message to the Originator.
  • the reply message sent by the relay CSE1 may include an identifier to the Originator, an identifier of the transit CSE1, and a processing result for the target resource.
  • the Originator receives the reply message sent by the relay CSE1 and receives the processing result of the target resource. This completes the communication process in which the entire Originator requests the host resource from the Hosting CSE.
  • the embodiment of Figure 11 will send a request message to the Hosting CSE with the Originator, passing through three Transit CSE, transit CSE1 and transit CSE3 create ⁇ request> resources, while transit CSE2 does not create ⁇ request> resources as an example for illustrative purposes.
  • FIG. 11 is a schematic interaction flow diagram of a method of communication in a oneM2M system in accordance with still another embodiment of the present invention.
  • the Originator sends a request message to the Hosting CSE, and the transit CSE1 first receives the request message.
  • the Originator sends a request message to the Hosting CSE where the target resource is located.
  • the request message carries the RT parameter.
  • the RT parameter is set to "nonBlockingRequestSynch"
  • the request message sent by the Originator is used by the Originator to request the Hosting CSE to operate on the target resource.
  • the request message sent by the Originator includes the identifier of the Originator, the identifier of the Hosting CSE where the target resource is located, and the request resource creator Request Resource Creator parameter.
  • the Request Resource Creator parameter is the default. Originator completes registration in transit CSE1, and transit CSE1 can receive the request message first.
  • the Originator completes the registration in the transit CSE1, and the transit CSE1 first receives the request message sent by the previous entity Originator.
  • the transit CSE1 can determine whether to create a ⁇ request> resource according to its own situation. For example, if the transit CSE1 supports the creation of a ⁇ request> resource, it is determined to create a ⁇ request1> resource.
  • the transit CSE1 sends a reply message to the Originator.
  • the transfer CSE1 After the transfer CSE1 creates the ⁇ request1> resource, it sends a reply message to the next entity Originator.
  • the reply message sent by the relay CSE1 includes the identifier of the transit CSE1, the identifier of the Originator, and the address information of the ⁇ request 1> resource created by the transit CSE1.
  • the reply message sent by the relay CSE1 is used to send the address information of the ⁇ request 1> resource created by the relay CSE1 to the originator, so that the originator sends a get request message to the transit CSE1 to obtain the processing result of the target resource.
  • the transit CSE1 generates a request message for relaying CSE1, and sends a request message for relaying CSE1 to the next entity transit CSE2.
  • Transit CSE1 can set the Request Resource Creator parameter to the identifier of the transit CSE1.
  • a request message for relaying CSE1 is generated according to the Request Resource Creator parameter.
  • the request message for transiting CSE1 includes the identifier of the Originator, the identifier of the Hosting CSE, and the request resource creator Request Resource Creator parameter, and the identifier of the transit CSE1 is located in the Request. Resource Creator parameters.
  • the transit CSE1 After the transit CSE1 generates the request message for transiting CSE1, the next entity transits CSE2 to send a request message for transiting CSE1.
  • the request message of the transit CSE1 is used to request the processing result of the target resource to the Hosting CSE.
  • the identifier of the transit CSE1 is not limited in the embodiment of the present invention.
  • the identifier of the transit CSE1 may be CSE1-ID.
  • the transit CSE2 forwards the CSE3 to the next entity to forward the request message of the relay CSE1.
  • the transit CSE2 After the transit CSE2 receives the request message of the transit CSE1 sent by the relay CSE1, the next entity transits the CSE3 to forward the request message of the transit CSE1.
  • transit CSE3 creates a ⁇ request2> resource.
  • the transit CSE3 After receiving the request message sent by the relay CSE2, the transit CSE3 determines whether to create a ⁇ request> resource according to its own situation. For example, transit CSE3 supports creating ⁇ request> resources and creating ⁇ request2> resources.
  • the transit CSE3 sends a reply message to the CSE2 in a physical entity.
  • the CSE2 After the CRE3 is created, the CSE2 sends a reply message to the next entity.
  • the reply message sent by the relay CSE3 includes the transit CSE3 identifier, the identifier of the transit CSE1, and the address information of the ⁇ request 2> resource created by the transit CSE3.
  • the address information of the ⁇ request 2> resource is not limited in the embodiment of the present invention.
  • the address information of the resource can be either a URI or a Resource ID.
  • the transit CSE2 forwards the reply message to the transit CSE1.
  • the transit CSE2 After receiving the reply message sent by the relay CSE3, the transit CSE2 forwards the reply message to the CSE1 in the previous entity.
  • the transit CSE3 generates a request message and sends a request message to the Hosting CSE.
  • Transit CSE3 generates a request message for relaying CSE3.
  • the request message of the relay CSE3 may include an identifier of the Originator, an identifier of the Hosting CSE, and a request resource creator Request Resource Creator parameter, and the identifier of the transit CSE3 is located in the Request Resource Creator parameter.
  • the request message for transiting CSE3 is used by the Originator to request the target resource from the Hosting CSE.
  • the transit CSE3 sends the request message of the transit CSE3 to the Hosting CSE.
  • Hosting CSE processes the target resource and creates a ⁇ request3> resource.
  • the Hosting CSE After receiving the request message of the relay CSE3 sent by the CSE3, the Hosting CSE starts to process the target resource. And, after receiving the request message of the relay CSE3 sent by the CSE3, the Hosting CSE creates a ⁇ request3> resource.
  • the Hosting CSE sends a reply message to the CSE3 in a physical entity.
  • the Hosting CSE After the Hosting CSE creates the ⁇ request3> resource, it sends a reply message to the CSE3 in the previous entity.
  • 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 ⁇ request 3> resource created by the Hosting CSE.
  • the address information of the ⁇ request 3> resource is not limited in the embodiment of the present invention.
  • the address information of the resource can be either a URI or an ID.
  • the transit CSE3 sends a get request message to the Hosting CSE.
  • the transit CSE3 After receiving the reply message sent by the Hosting CSE, the transit CSE3 sends a get request message to the Hosting CSE.
  • the acquisition request message sent by CSE3 includes the identifier of the transit CSE3 and the address information of the ⁇ request 3> resource created by the Hosting CSE.
  • Hosting CSE updates the ⁇ request 3> resource created by Hosting CSE itself.
  • the Hosting CSE After receiving the acquisition request message sent by the CSE3, the Hosting CSE obtains the processing result of the target resource if the processing of the target resource has been completed. The Hosting CSE saves the processing result of the target resource in the ⁇ request3> resource created by itself to update the ⁇ request3> resource.
  • the Hosting CSE sends a reply message to the transit CSE3.
  • the Hosting CSE After obtaining the processing result of the target resource, the Hosting CSE sends a reply message to the CSE3 to the picking entity.
  • the reply message sent by the Hosting CSE includes the identifier of the Hosting CSE, the identifier of the transit CSE3, and the processing result of the target resource.
  • the Hosting CSE sends a reply message to the transit CSE3, including sending the processing result of the target resource to the transit CSE3.
  • the transit CSE3 updates the ⁇ request 2> resource created by the CSE3 itself according to the reply message sent by the Hosting CSE.
  • the transit CSE3 After receiving the reply message sent by the Hosting CSE, the transit CSE3 receives the processing result of the target resource.
  • the transit CSE 3 saves the processing result of the target resource in the ⁇ request 2> resource created by itself to update the ⁇ request2> resource created by the transit CSE3 itself.
  • the transit CSE1 sends a get request message to the transit CSE2.
  • the transit CSE1 sends a get request message to the next entity transit CSE2.
  • the acquisition request message sent by the relay CSE1 includes the identifier of the transit CSE1 and the address information of the ⁇ request2> resource created by the transit CSE3.
  • the transit CSE2 forwards the acquisition request message to the transit CSE3.
  • the transit CSE2 After the transit CSE2 receives the get request message sent by the relay CSE1, it is in the next entity.
  • the CSE3 forwards the get request message.
  • the transit CSE3 sends a reply message to the transit CSE2.
  • the transit CSE3 After receiving the acquisition request message sent by the relay CSE2, the transit CSE3 sends a reply message to the CSE2 to the previous entity.
  • the reply message sent by the relay CSE3 includes the identifier of the transit CSE1, the identifier of the transit CSE3, and the processing result of the target resource.
  • the transit CSE2 forwards the reply message to the transit CSE1.
  • the transit CSE2 After receiving the reply message sent by the relay CSE3, the transit CSE2 forwards the reply message to the CSE2 in the previous entity.
  • the transit CSE1 updates the ⁇ request 1> resource created by the CSE1 itself according to the reply message sent by the transit CSE2.
  • the transit CSE1 After receiving the reply message sent by CSE2, the transit CSE1 receives the processing result of the target resource.
  • the transit CSE 1 saves the processing result of the target resource in the ⁇ request 1> resource created by itself to update the ⁇ request1> resource created by the transit CSE1 itself.
  • the Originator sends a get request message to the transit CSE1.
  • Originator sends a Get Request message to CSE1 in the next entity.
  • the get request message sent by the Originator includes the identifier of the Originator and the address information of the ⁇ request 1> resource.
  • the Get Request message sent by the Originator is used by the Originator to request the transit CSE1 to obtain the processing result of the target resource.
  • the transit CSE1 sends a reply message to the Originator.
  • the transit CSE1 After receiving the get request message sent by the previous entity Originator, the transit CSE1 sends a reply message to the Originator.
  • the reply message sent by the relay CSE1 includes the identifier of the transit CSE1, the identifier of the Originator, and the processing result of the target resource. Transmitting CSE1 to send a reply message to the Originator includes sending a result of processing the target resource to the Originator.
  • the Originator receives the reply message sent by the transit CSE1, that is, receives the processing result of the target resource sent by the transit CSE1, to complete the communication process of the entire Originator requesting the target resource from the Hosting CSE.
  • FIG. 12 is a schematic interaction flowchart of a method of communication in a oneM2M system according to another embodiment of the present invention.
  • the embodiment of FIG. 12 does not create a ⁇ request> resource in three transit CSEs, and only the Hosting CSE creates a ⁇ request> resource as an example for exemplary description.
  • the Originator sends a request message to the Hosting CSE, and the relay CSE1 receives the request. Message.
  • the Originator sends a request message to the Hosting CSE where the target resource is located.
  • the request message carries the RT parameter.
  • the RT parameter is set to "nonBlockingRequestSynch"
  • 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 the default.
  • the Originator completes registration on CSE1, and the transit CSE1 can receive the request message first.
  • the transit CSE1 forwards the request message to the transit CSE2.
  • the Originator completes registration on the transit CSE1, and the transit CSE1 first receives the request message sent by the previous entity Originator.
  • the transit CSE1 can determine whether to create a ⁇ request> resource according to its own situation. When the transit CSE1 determines not to create the ⁇ request> resource, the transit CSE1 forwards the request message to the transit CSE2.
  • the transit CSE2 forwards the request message to the transit CSE3.
  • the transit CSE2 receives the request message sent by the previous entity to transfer CSE1.
  • the transit CSE2 can also determine whether to create a ⁇ request> resource according to its own situation. When the transit CSE2 determines not to create the ⁇ request> resource, the transit CSE2 forwards the request message to the transit CSE3.
  • the transit CSE3 forwards the request message to the Hosting CSE.
  • the transit CSE3 receives the request message sent by the previous entity to transfer CSE2.
  • the transit CSE3 can also determine whether to create a ⁇ request> resource according to its own situation. When the transit CSE3 determines not to create the ⁇ request> resource, the transit CSE3 forwards the request message to the Hosting CSE.
  • Hosting CSE processes the target resource and creates a ⁇ request> resource.
  • the Hosting CSE After receiving the request message sent by CSE3, the Hosting CSE processes the target resource. At the same time, the Hosting CSE can create a ⁇ request> resource after receiving the request message sent by the CSE3.
  • the Hosting CSE sends a reply message to the transit CSE3.
  • the Hosting CSE After the Hosting CSE creates the ⁇ request> resource, it sends a reply message to the CSE3 in the previous entity.
  • the reply message sent by the Hosting CSE may include the identifier of the Hosting CSE, the identifier of the Originator, and the address information of the ⁇ request> resource created by the Hosting CSE.
  • the address information of the ⁇ request> resource may be a URI or an ID, which is not limited by the embodiment of the present invention.
  • the transit CSE3 forwards the reply message to the transit CSE2.
  • the transit CSE3 After receiving the reply message sent by the Hosting CSE, the transit CSE3 forwards the reply message to the CSE2 in the previous entity.
  • the transit CSE2 forwards the reply message to the transit CSE1.
  • the transit CSE2 After receiving the reply message sent by the relay CSE3, the transit CSE2 forwards the reply message to the CSE1 in the previous entity.
  • the transit CSE1 forwards the reply message to the Originator.
  • the transit CSE1 After receiving the reply message sent by the relay CSE2, the transit CSE1 forwards the reply message to the next entity Originator.
  • the Originator sends a get request message to the transit CSE1.
  • the Originator After receiving the reply message sent by CSE1, the Originator sends a Get Request message to CSE1 in the next entity.
  • the get request message sent by the Originator may include the identifier of the Originator and the address information of the Hosting CSE creation ⁇ request> resource.
  • the get request message is used to obtain the processing result of the target resource from the Hosting CSE requesting the ⁇ request> resource.
  • the transit CSE1 first receives the get request message.
  • the transit CSE1 forwards the acquisition request message to the transit CSE2.
  • the transit CSE1 After receiving the get request message sent by the Originator, the transit CSE1 forwards the get request message to the next entity transfer CSE2.
  • the transit CSE2 forwards the acquisition request message to the transit CSE3.
  • the transit CSE2 After receiving the acquisition request message sent by the relay CSE1, the transit CSE2 forwards the acquisition request message to the next entity transfer CSE3.
  • the transit CSE3 forwards the acquisition request message to the Hosting CSE.
  • the transit CSE3 After receiving the acquisition request message sent by the relay CSE2, the transit CSE3 forwards the acquisition request message to the next entity Hosting CSE.
  • Hosting CSE updates the ⁇ request> resource created by Hosting CSE itself.
  • the Hosting CSE After receiving the acquisition request message sent by the CSE3, the Hosting CSE obtains the processing result of the target resource if the processing of the target resource has been completed. The Hosting CSE saves the processing result of the target resource in the ⁇ request> resource created by itself to update the ⁇ request> resource created by itself.
  • Hosting CSE sends a reply message to transit CSE3.
  • the host entity After the Hosting CSE obtains the processing result of the target resource, the host entity sends a reply message to the CSE3.
  • the reply message sent by Hosting CSE includes the identifier of Hosting CSE. The identifier of the Originator and the result of processing the target resource.
  • the Hosting CSE sends a reply message to the transit CSE3, including sending the processing result of the target resource to the transit CSE3.
  • the transit CSE3 forwards the reply message to the transit CSE2.
  • the transit CSE3 After receiving the reply message sent by the Hosting CSE, the transit CSE3 forwards the reply message to the CSE2 to the previous entity, so that the transit CSE2 obtains the processing result of the target resource.
  • the transit CSE2 forwards the reply message to the transit CSE1.
  • the transit CSE2 After receiving the reply message sent by the relay CSE3, the transit CSE2 forwards the reply message to the CSE1 to the intermediate entity, so that the transit CSE1 obtains the processing result of the target resource.
  • the transit CSE1 forwards the reply message to the Originator.
  • the transit CSE1 After receiving the reply message sent by the relay CSE2, the transit CSE1 forwards the reply message to the next entity Originator, so that the Originator obtains the processing result of the target resource.
  • the Originator receives the reply message sent by the relay CSE1, including receiving the processing result of the target resource.
  • the Originator obtains the processing result of the target resource, that is, completes the communication process of the entire Originator requesting the target resource from the Hosting CSE.
  • FIG. 13 is a schematic interaction flowchart of a method of communication in a oneM2M system according to another embodiment of the present invention.
  • the embodiment of FIG. 13 will send a request message to the Hosting CSE by the Originator, and through three transit CSEs, the transit CSE1 and the transit CSE3 create a ⁇ request> resource, and the transit CSE2 does not create a ⁇ request> resource as an example for exemplary description.
  • the Originator sends a request message to the Hosting CSE, and the transit CSE1 first receives the request message.
  • the Originator sends a request message to the Hosting CSE where the target resource is located.
  • the request message carries the RT parameter.
  • the RT parameter is set to "nonBlockingRequestSynch"
  • the request message sent by the Originator is used by the Originator to request the Hosting CSE to operate on the target resource.
  • 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 request resource indication field.
  • the request resource indication field is the default.
  • the Originator completes registration at CSE1, and the transit CSE1 can first receive the request message.
  • Transit CSE1 can determine whether to create ⁇ according to its own situation Request>Resources. For example, if the transit CSE1 supports the creation of a ⁇ request> resource, it is determined to create a ⁇ request1> resource.
  • the transit CSE1 sends a reply message to the Originator.
  • the transfer CSE1 After the transfer CSE1 creates the ⁇ request1> resource, it sends a reply message to the next entity Originator.
  • the reply message sent by the relay CSE1 includes the identifier of the transit CSE1, the identifier of the Originator, and the address information of the ⁇ request 1> resource created by the transit CSE1.
  • the reply message sent by the relay CSE1 is used to send the address information of the ⁇ request 1> resource created by the relay CSE1 to the originator, so that the originator sends a get request message to the transit CSE1 to obtain the processing result of the target resource.
  • the transit CSE1 generates a request message for relaying CSE1, and sends a request message for relaying CSE1 to the next entity transit CSE2.
  • the transit CSE1 can set the request resource indication field to the identifier of the transit CSE1 to generate a request message for the transit CSE1.
  • the request message for transiting 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.
  • the next entity transits CSE2 to send a request message for transiting CSE1.
  • the request message of the transit CSE1 is used to request the processing result of the target resource to the Hosting CSE.
  • the transit CSE2 forwards the CSE3 request message for forwarding CSE1 to the next entity.
  • the transit CSE2 After the transit CSE2 receives the request message of the transit CSE1 sent by the relay CSE1, the next entity transits the CSE3 to forward the request message of the transit CSE1.
  • transit CSE3 creates a ⁇ request2> resource.
  • the transit CSE3 After receiving the request message sent by the relay CSE2, the transit CSE3 determines whether to create a ⁇ request> resource according to its own situation. For example, transit CSE3 supports creating ⁇ request> resources and creating ⁇ request2> resources.
  • Transit CSE3 sends a reply message to CSE2 to an entity.
  • the CSE2 After the CRE3 is created, the CSE2 sends a reply message to the next entity.
  • the reply message sent by the relay CSE3 includes the transit CSE3 identifier, the identifier of the transit CSE1, and the address information of the ⁇ request 2> resource created by the transit CSE3.
  • the transit CSE2 forwards the reply message to the transit CSE1.
  • the transit CSE2 After receiving the reply message sent by the relay CSE3, the transit CSE2 forwards the reply message to the CSE1 in the previous entity.
  • the request resource indication field is set to the identifier of the transit CSE3, and a request message for the transit CSE3 can be generated.
  • the request message of the relay CSE3 may include an identifier of the Originator, an identifier of the Hosting transit CSE, and a request resource indication field, and the identifier of the transit CSE3 is located in the request resource indication field.
  • Hosting CSE processes the target resource and creates a ⁇ request3> resource.
  • the Hosting CSE After receiving the request message of the relay CSE3 sent by the CSE3, the Hosting CSE starts to process the target resource. And, after receiving the request message of the relay CSE3 sent by the CSE3, the Hosting CSE creates a ⁇ request3> resource.
  • Hosting CSE sends a reply message to CSE3 to an entity.
  • the Hosting CSE After the Hosting CSE creates the ⁇ request3> resource, it sends a reply message to the CSE3 in the previous entity.
  • 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 ⁇ request 3> resource created by the Hosting CSE.
  • the transit CSE3 sends a get request message to the Hosting CSE.
  • the transit CSE3 After receiving the reply message sent by the Hosting CSE, the transit CSE3 sends a get request message to the Hosting CSE.
  • the acquisition request message sent by the relay CSE3 includes the identifier of the transit CSE3 and the address information of the ⁇ request 3> resource created by the Hosting CSE.
  • Hosting CSE updates the ⁇ request 3> resource created by Hosting CSE itself.
  • the Hosting CSE After receiving the acquisition request message sent by the CSE3, the Hosting CSE obtains the processing result of the target resource if the processing of the target resource has been completed. The Hosting CSE saves the processing result of the target resource in the ⁇ request3> resource created by itself to update the ⁇ request3> resource.
  • the Hosting CSE sends a reply message to the transit CSE3.
  • the Hosting CSE After obtaining the processing result of the target resource, the Hosting CSE sends a reply message to the CSE3 to the picking entity.
  • the reply message sent by the Hosting CSE includes the identifier of the Hosting CSE, the identifier of the CSE3, and the processing result of the target resource.
  • the Hosting CSE sends a reply message to the transit CSE3, including sending the processing result of the target resource to the transit CSE3.
  • the transit CSE3 updates the ⁇ request 2> resource created by the CSE3 itself according to the reply message sent by the Hosting CSE.
  • the transit CSE3 After receiving the reply message sent by the Hosting CSE, the transit CSE3 receives the processing result of the target resource.
  • the transit CSE 3 saves the processing result of the target resource in the ⁇ request 2> resource created by itself to update the ⁇ request2> resource created by the transit CSE3 itself.
  • the transit CSE1 sends a get request message to the transit CSE2.
  • the transit CSE1 sends a get request message to the next entity transit CSE2.
  • the acquisition request message sent by the relay CSE1 includes the identifier of the transit CSE1 and the address information of the ⁇ request2> resource created by the transit CSE3.
  • the transit CSE2 forwards the acquisition request message to the transit CSE3.
  • the transit CSE2 After the transit CSE2 receives the get request message sent by the relay CSE1, the next entity transits the CSE3 to forward the get request message.
  • the transit CSE3 sends a reply message to the transit CSE2.
  • the transit CSE3 After receiving the acquisition request message sent by the relay CSE2, the transit CSE3 sends a reply message to the CSE2 to the previous entity.
  • the reply message sent by the relay CSE3 includes the identifier of the transit CSE1, the identifier of the transit CSE3, and the processing result of the target resource.
  • the transit CSE2 forwards the reply message to the transit CSE1.
  • the transit CSE2 After receiving the reply message sent by the relay CSE3, the transit CSE2 forwards the reply message to the CSE2 in the previous entity.
  • the transit CSE1 updates the ⁇ request 1> resource created by the CSE1 itself according to the reply message sent by the transit CSE2.
  • the transit CSE1 After receiving the reply message sent by CSE2, the transit CSE1 receives the processing result of the target resource.
  • the transit CSE1 saves the processing result of the target resource in the ⁇ request 1> resource created by itself, to update the ⁇ request1> resource created by the transit CSE1 itself.
  • the Originator sends a get request message to the transit CSE1.
  • Originator sends a Get Request message to CSE1 in the next entity.
  • the get request message sent by the Originator includes the identifier of the Originator and the address information of the ⁇ request 1> resource.
  • the Get Request message sent by the Originator is used by the Originator to request the transit CSE1 to obtain the processing result of the target resource.
  • the transit CSE1 sends a reply message to the Originator.
  • the transit CSE1 After receiving the get request message sent by the previous entity Originator, the transit CSE1 sends a reply message to the Originator.
  • the reply message sent by the relay CSE1 includes the identifier of the transit CSE1, the identifier of the Originator, and the processing result of the target resource.
  • Transit CSE1 to Originator Sending a reply message includes sending a result of processing the target resource to the Originator.
  • the Originator receives the reply message sent by the transit CSE1, that is, receives the processing result of the target resource sent by the transit CSE1, to complete the communication process of the entire Originator requesting the target resource from the Hosting CSE.
  • the embodiment of FIG. 14 will send a request message to the Hosting CSE by the Originator, and after three CSEs are transferred, the CSE1 is created to create a ⁇ request> resource, and when the CSE2 does not create a ⁇ request> resource, the transfer of the ⁇ request> resource is skipped.
  • CSE2 the communication between the transit CSE1 and the transit CSE3 is completed to complete the process in which the Originator requests the Hosting CSE to operate on the target resource.
  • FIG. 14 is a schematic interaction flow diagram of a method of communication in a oneM2M system in accordance with still another embodiment of the present invention.
  • the Originator sends a request message to the Hosting CSE, and the transit CSE1 first receives the request message.
  • the Originator sends a request message to the Hosting CSE where the target resource is located.
  • the request message carries the RT parameter.
  • the RT parameter is set to "nonBlockingRequestSynch"
  • the request message is used by the Originator to request the Hosting CSE to operate on the target resource.
  • the request message includes the identifier of the Originator and the identifier of the Hosting CSE where the target resource is located.
  • the Originator completes the registration in the transit CSE1, and the transit CSE1 first receives the request message.
  • the Originator completes the registration in the transit CSE1, and the transit CSE1 first receives the request message sent by the previous entity Originator.
  • the transit CSE1 can determine whether to create a ⁇ request> resource according to its own situation. For example, when transit CSE1 supports the creation of a ⁇ request> resource, the transit CSE1 creates a ⁇ request1> resource.
  • the transit CSE1 sends a reply message to the Originator.
  • the transfer CSE1 After the transfer CSE1 creates the ⁇ request1> resource, it sends a reply message to the next entity Originator.
  • the reply message sent by the relay CSE1 to the Originator includes the identifier of the transit CSE1, the identifier of the Originator, and the address information of the ⁇ request 1> resource created by the transit CSE1.
  • the reply message sent by the relay CSE1 to the Originator is used to send the address information of the ⁇ request 1> resource created by the relay CSE1 to the Originator, so that the Originator can send the acquisition to the transit CSE1.
  • Request a message to get the result of processing the target resource.
  • Transit CSE1 sends a request message to CSE2 to the next entity.
  • the CSE2 sends a request message to the next entity after the ⁇ request1> resource is created.
  • the request message sent by the relay CSE1 to the next entity transit CSE2 is used to request the processing result of the target resource to the Hosting CSE.
  • the request message includes the identifier of the Originator and the identifier of the Hosting CSE where the target resource is located.
  • the request message sent by the relay CSE1 to the next entity transit CSE2 is the same as the request message sent by the Originator to the Hosting CSE.
  • the transit CSE2 determines not to create a ⁇ request> resource.
  • the transit CSE2 can determine whether to create a ⁇ request> resource according to its own situation. For example, if the transit CSE2 does not support the ⁇ request> resource type, then the transit CSE2 determines not to create the ⁇ request> resource.
  • the transit CSE2 sends an indication message to the transit CSE1.
  • the upward entity sends a notification message to the CSE1.
  • the indication message sent by the transit CSE2 to the transit CSE1 includes the identifier of the transit CSE1, the identifier of the transit CSE2, and the request resource do not create a Request Not Create parameter, and the Request Not Create parameter includes the identifier of the transit CSE3.
  • the indication message sent by the transit CSE2 to the transit CSE1 is used to indicate that the previous entity transits the CSE1 to send the CSE3 request message to the next entity, so as to bypass the non-created ⁇ request> resource transfer CSE2 and continue to execute the Originator to the Hosting CSE request to operate on the target resource. the process of.
  • the transit CSE1 cancels the registration information on the transit CSE2 and registers it on the transit CSE3.
  • the transit CSE1 After receiving the indication information sent by the relay CSE2, the transit CSE1 cancels the registration information on the transit CSE2, and registers with the transit CSE3 to establish communication between the transit CSE1 and the transit CSE3.
  • the transit CSE1 sends a request message to the transit CSE3.
  • the transit CSE1 After the transit CSE1 completes registration on the transit CSE3, it sends a request message to the transit CSE3. Transmit CSE1 to the request message sent by the transit CSE3.
  • the request message sent by the transit CSE1 to the transit CSE3 includes the identifier of the Originator and the identifier of the Hosting CSE where the target resource is located.
  • 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.
  • the relay CSE3 creates a ⁇ request2> resource.
  • the transit CSE3 After receiving the request message sent by CSE1, the transit CSE3 can determine whether to create a ⁇ request> resource according to its own situation. Transit CSE3 can create ⁇ request2> resources.
  • the transit CSE3 sends a reply message to the transit CSE1.
  • the transit CSE3 When the transit CSE3 determines to create the ⁇ request2> resource, the transit CSE3 sends a reply message to the transit CSE1.
  • the reply message sent by the transit CSE3 to the transit CSE1 includes the identifier of the transit CSE3, the identifier of the transit CSE1, and the address information of the ⁇ request2> resource created by the transit CSE3.
  • the transit CSE3 sends a request message to the Hosting CSE.
  • the transit CSE3 sends a request message to the next entity Hosting CSE.
  • the request message sent by the relay CSE3 is used to request the processing result of the target resource to the Hosting CSE.
  • the transit CSE3 sends a request message to the next entity Hosting CSE after determining to create the ⁇ request2> resource.
  • the request message sent by the relay CSE3 includes the identifier of the Originator and the identifier of the Hosting CSE where the target resource is located.
  • 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 the same.
  • Hosting CSE processes the target resource and creates a ⁇ request3> resource.
  • the Hosting CSE After receiving the request message sent by CSE3, the Hosting CSE starts to process the target resource. And, after receiving the request message sent by the CSE3, the Hosting CSE creates a ⁇ request3> resource.
  • Hosting CSE sends a reply message to transit CSE3.
  • the Hosting CSE After the Hosting CSE creates the ⁇ request3> resource, it sends a reply message to the transit CSE3.
  • the Hosting CSE sends a reply message to the transit CSE3, including the identifier of the transit CSE3, the identifier of the Hosting CSE, and the address information of the ⁇ request3> resource created by the Hosting CSE.
  • the Hosting CSE If the Hosting CSE has completed processing the target resource, it will get the result of processing the target resource. Then, the processing result of the target resource is saved in the ⁇ request3> resource created by itself to update the ⁇ request3> resource.
  • the CSE3 sends a get request message to the Hosting CSE.
  • the CSE3 sends a Get Request message to the next entity Hosting CSE.
  • the acquisition request message sent by the relay CSE3 includes the identifier of the transit CSE3 and the address information of the ⁇ request3> resource.
  • the acquisition request message sent by the transit CSE3 is used to request the processing result of the target resource to the Hosting CSE.
  • the Hosting CSE sends a reply message to the transit CSE3.
  • the Hosting CSE After receiving the acquisition request message sent by the 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 the identifier of the Hosting CSE, the identifier of the transit CSE3, and the processing result of the target resource.
  • the sending of the reply message by the Hosting CSE to the CSE3 includes sending the processing result of the target resource to the transit CSE3.
  • the transit CSE3 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.
  • the transit CSE1 sends a get request message to the transit CSE3.
  • the transit CSE1 sends a get request message to the transit CSE3.
  • the acquisition request message sent by the relay CSE1 includes the identifier of the transit CSE1 and the address information of the ⁇ request2> resource.
  • the acquisition request message sent by the transit CSE1 is used to request the processing result of the target resource to the transit CSE3.
  • the transit CSE3 sends a reply message to the transit CSE1.
  • the transit CSE3 After receiving the acquisition request message sent by CSE1, the transit CSE3 sends a reply message to the transit CSE1 according to the acquisition request message.
  • the reply message sent by the relay CSE3 includes the identifier of the Hosting CSE, the identifier of the transit CSE3, and the processing result of the target resource.
  • the Hosting CSE sends a reply message to the transit CSE3, including sending the processing result of the target resource to the transit CSE3.
  • the relay CSE1 After receiving the reply message sent by CSE3, the relay CSE1 saves the processing result of the target resource in the ⁇ request1> resource to update the ⁇ request1> resource created by itself.
  • the Originator sends a get request message to the transit CSE1.
  • the Originator sends a Get Request message to the transit CSE1.
  • the get request message sent by the Originator includes the identifier of the Originator and the address information of the ⁇ request1> resource.
  • the acquisition request message sent by the Originator is used to request the processing result of the target resource to the transit CSE1.
  • the transit CSE1 sends a reply message to the Originator.
  • the transit CSE1 After receiving the acquisition request message sent by the Originator, the transit CSE1 sends a reply message to the Originator according to the acquisition request message.
  • the reply message sent by the relay CSE1 includes the identifier of the transit CSE3, the identifier of the transit CSE1, and the processing result of the target resource. Transmitting CSE1 to send a reply message to the Originator includes sending a result of processing the target resource to the Originator.
  • the embodiment of FIG. 15 will send a request message to the Hosting CSE by the Originator, and after two transitive CSEs, create a ⁇ request> resource in the transit CSE1 and the transit CSE2, and Hosting CSE
  • the Hosting CSE processes the target resource after receiving the request message, and retransmits the request message based on the transit CSE2 when the processing result of the target resource is obtained, and returns the processing of the target resource to the transit CSE2.
  • the process of the Originator requesting the Hosting CSE to operate on the target resource is completed.
  • Embodiment 14 is a diagrammatic representation of Embodiment 14:
  • 15 is a schematic interaction flow diagram of a method of communication in a oneM2M system in accordance with still another embodiment of the present invention.
  • the Originator sends a request message to the Hosting CSE, and the transit CSE1 first receives the request message.
  • the Originator sends a request message to the Hosting CSE where the target resource is located.
  • the request message carries the RT parameter.
  • the RT parameter is set to "nonBlockingRequestSynch"
  • the request message is used by the Originator to request the Hosting CSE to operate on the target resource.
  • the request message includes the identifier of the Originator and the identifier of the Hosting CSE where the target resource is located.
  • the Originator completes registration on the transit CSE1, and the transit CSE1 first receives the request message.
  • the Originator completes the registration in the transit CSE1, and the transit CSE1 first receives the request message sent by the previous entity Originator.
  • the transit CSE1 can determine whether to create a ⁇ request> resource according to its own situation. For example, when transit CSE1 supports the creation of a ⁇ request> resource, the transit CSE1 creates a ⁇ request1> resource.
  • the transit CSE1 sends a reply message to the Originator.
  • the transfer CSE1 After the transfer CSE1 creates the ⁇ request1> resource, it sends a reply message to the next entity Originator.
  • the reply message sent by the relay CSE1 to the Originator includes the identifier of the transit CSE1, the identifier of the Originator, and the address information of the ⁇ request 1> resource created by the transit CSE1.
  • the reply message sent by the relay CSE1 to the Originator is used to send the address information of the ⁇ request 1> resource created by the relay CSE1 to the Originator, so that the Originator sends a get request message to the transit CSE1 to obtain the processing result of the target resource.
  • Transit CSE1 sends a request message to CSE2 to the next entity.
  • the CSE2 sends a request message to the next entity after the ⁇ request1> resource is created.
  • the request message sent by the relay CSE1 to the next entity transit CSE2 is used to request the processing result of the target resource to the Hosting CSE.
  • Transit CSE1 sent to transit CSE2 The request message includes the identifier of the Originator and the identifier of the Hosting CSE where the target resource is located.
  • the request message sent by the relay CSE1 to the next entity transit CSE2 is the same as the request message sent by the Originator to the Hosting CSE.
  • the transit CSE2 determines whether to create a ⁇ request> resource according to its own situation. Transfer CSE2 to create a ⁇ request2> resource.
  • the transit CSE2 sends a reply message to the transit CSE1.
  • the transfer CSE2 After the transfer CSE2 creates the ⁇ request2> resource, it sends a reply message to the transit CSE1.
  • the reply message sent by the transit CSE2 to the transit CSE1 includes the identifier of the transit CSE2, the identifier of the transit CSE1, and the address information of the ⁇ request2> resource created by the transit CSE2.
  • the reply message sent by the transit CSE2 to the transit CSE1 includes the transit CSE2 sending the address information of the ⁇ request2> resource created by the transit CSE2 to the transit CSE1, so that the Originator sends a get request message to the transit CSE1 to obtain the processing result of the target resource.
  • the transit CSE2 sends a request message to the next entity Hosting CSE.
  • the CSE2 sends a request message to the next entity Hosting CSE.
  • the request message sent by the relay CSE2 is used to request the processing result of the target resource to the Hosting CSE.
  • the transit CSE2 sends a request message to the next entity Hosting CSE after creating the ⁇ request2> resource.
  • the request message sent by the transit CSE2 to the Hosting CSE includes the identifier of the Originator and the identifier of the Hosting CSE where the target resource is located.
  • the Hosting CSE processes the target resource and does not create a ⁇ request> resource.
  • the Hosting CSE After receiving the request message sent by CSE2, the Hosting CSE starts processing the target resource. Moreover, the Hosting CSE can determine whether to create a ⁇ request> resource according to its own situation. The Hosting CSE determines that the ⁇ request> resource may not be created.
  • the Hosting CSE sends an indication message to the transit CSE2.
  • the Hosting CSE After determining that the ⁇ request> resource is not created, the Hosting CSE sends an indication message to the CSE2 in the previous entity.
  • the indication message sent by the Hosting CSE to the transit CSE2 includes the identifier of the Hosting CSE, the identifier of the transit CSE2, and the request resource do not create the Request Not Create parameter.
  • the indication message is used to request that the relay CSE2 resend the request message to the Hosting CSE after a period of time T. The time when the CSE2 resends the request message is located in the request resource does not create the Request Not Create parameter.
  • T can be determined based on the time required by Hosting CSE to complete the processing of the target resource. For example, T can be greater than Hosting CSE is expected to complete the target The time required for the processing of the source.
  • the Hosting CSE When receiving the request message sent by CSE2, the Hosting CSE starts to process the target resource. 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 the creation of the ⁇ request> resource, the process of the Originator requesting the Hosting CSE to operate on the target resource can be continued.
  • the transit CSE2 resends the request message to the Hosting CSE.
  • the CSE2 After sending the request message to the Hosting CSE for a period of time T, the CSE2 resends the request message to the Hosting CSE.
  • the request message also includes a first parameter carrying the ID of ⁇ request>.
  • the Hosting CSE can determine whether it is the same request message through the first parameter. For example, when the first parameter of the ⁇ request> ID carried in the resent request message is the same as the first parameter included in the request message received by the Hosting CSE for the first time, the Hosting CSE can determine the same request message.
  • the Hosting CSE sends the processing result of the target resource to the transit CSE2.
  • Step 1510 The Hosting CSE processes the target resource, and after the processing is completed, obtains a processing result for the target resource.
  • the Hosting CSE sends the processing result of the target resource to the upper entity CSE2.
  • step 1511 when the Hosting CSE receives the request message and determines that it is the same request message, it can directly send the processing result of the target resource to the transit CSE2 after the processing of the target resource is completed, and is no longer needed.
  • the transit CSE2 sends a get request message to the Hosting CSE.
  • the transit CSE2 updates the ⁇ request2> resource created by itself.
  • the transit CSE2 After receiving the processing result of the target resource sent by the Hosting CSE, the transit CSE2 saves the processing result of the target resource in the ⁇ request2> resource created by itself to update the ⁇ request2> resource.
  • the transit CSE1 sends a get request message to the transit CSE2.
  • the transit CSE1 sends a get request message to the transit CSE2.
  • the acquisition request message sent by the transit CSE1 to the transit CSE2 includes the identifier of the transit CSE1 and the address information of the ⁇ request2> resource.
  • the transit CSE2 sends a reply message to the transit CSE1.
  • the ⁇ request2> resource sends a reply message to the transit CSE1.
  • the reply message sent by the transit CSE2 to the transit CSE1 may include an identifier of the transit CSE2, an identifier of the transit CSE1, and a processing result of the target resource.
  • the transit CSE1 updates the ⁇ request1> resource created by itself.
  • the transit CSE1 After receiving the reply message sent by the relay CSE2, the transit CSE1 receives the processing result of the target resource sent by the transit CSE2, and saves the processing result of the target resource in the ⁇ request1> resource created by itself to update ⁇ request1> Resources.
  • the Originator sends a get request message to the transit CSE1.
  • Originator sends a Get Request message to CSE1 in the next entity.
  • the get request message sent by the Originator to the transit CSE1 may include an identifier of the Originator and address information of the ⁇ request1> resource.
  • the acquisition request message sent by the Originator to the transit CSE1 is used to request the processing result of the target resource to the transit CSE1.
  • the transit CSE1 sends a reply message to the Originator.
  • the transit CSE1 After receiving the get request message sent by the Originator, the transit CSE1 sends a reply message to the Originator.
  • the reply message sent by the relay CSE1 to the Originator may include an identifier of the Originator, an identifier of the transit CSE1, and a processing result of the target resource.
  • the Originator receives the reply message sent by the relay CSE1, that is, receives the processing result of the target resource. This completes the entire process of the Originator requesting the host resource from the Hosting CSE.
  • FIG. 16 is a schematic block diagram of an apparatus for communication in a oneM2M system in accordance with an embodiment of the present invention.
  • the apparatus 160 of FIG. 16 may be a relay CSE, including a first receiving unit 1601 and a first transmitting unit 1602.
  • the first receiving unit 1601 is configured to receive the first request message in the non-blocking synchronous communication mode sent by the last entity.
  • the first request message includes a request resource creator Request Resource Creator parameter.
  • the Request Resource Creator parameter is the default value or the identifier of the entity that created the request ⁇ request> resource for the first request message.
  • the first request message is used by 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: when the first request message received for the first receiving unit is not invasive When the ⁇ request> resource is created, the first request message is sent to the next entity.
  • the oneM2M system of the embodiment of the present invention communicates using the non-blocking synchronous communication mode, after receiving the request message for adding the Request Resource Creator parameter sent by the previous entity, the request is forwarded to the next entity by the entity that does not create the ⁇ request> resource.
  • the message can continue to communicate when the local entity ⁇ request> resource creation fails.
  • the device 160 further includes a second receiving unit and a second sending unit.
  • the second receiving unit is configured to receive a first reply message sent by the next entity.
  • the first reply message includes address information of a ⁇ request> resource created by an entity that creates a ⁇ request> resource for the first request message.
  • the second sending unit sends the first reply message to the previous entity.
  • the device 160 further includes a third receiving unit and a third sending unit.
  • the third receiving unit is configured to receive a first acquisition request message sent by the last entity.
  • the first acquisition request message includes address information of a ⁇ request> resource created by an entity that creates a ⁇ request> resource for the first request message.
  • the first acquisition request message is used to request the entity that creates the ⁇ request> resource to obtain the processing result of the target resource.
  • the third sending unit is configured to send a first acquisition request message to the next entity.
  • the device 160 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 the next entity.
  • the second reply message includes the result of processing the target resource.
  • the fourth sending unit is configured to send a second reply message to the upper entity.
  • the device 160 further includes a determining unit.
  • the determining unit is configured to determine whether to create a ⁇ request> resource for the first request message.
  • 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.
  • the apparatus 160 further includes a creating unit, a fifth sending unit, a generating unit, and a sixth sending 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 a third reply message to the upper entity.
  • the third reply message includes the address information of the created ⁇ request> resource.
  • the generating unit is configured to generate a second request message.
  • the second request message includes a Request Resource Creator parameter. Set the Request Resource Creator parameter to the identifier of the transit CSE.
  • the sixth sending unit is configured to send a second request message to the next entity.
  • the device 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 the next entity.
  • the fourth reply message includes the processing result 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 acquisition request message sent by the previous entity.
  • the second acquisition request message includes address information of the created ⁇ request> resource.
  • the second acquisition request message is used by the previous entity to obtain the processing result of the target resource from the transit CSE.
  • the seventh sending unit is configured to send a fifth reply message to the upper entity.
  • the fifth reply message includes the processing result of the target resource.
  • the apparatus for communicating in the M2M system may correspond to the method of communication in the M2M system of the embodiment of the present invention, and each unit/module in the apparatus and the other operations and/or functions described above are respectively implemented in FIG.
  • the corresponding flow of the illustrated method and the corresponding flow of the relevant CSE in the methods shown in FIG. 9, FIG. 10 and FIG. 11 are not described herein for brevity.
  • FIG. 17 is a schematic block diagram of an apparatus for communication in a 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 the first request message in the non-blocking synchronous communication mode sent by the last entity.
  • the first request message is used by the originating entity Originator to request the hosted CSE of the target resource to operate on the target resource.
  • the first generating unit 1702 is configured to generate a request resource creator Request Resource Creator parameter when the 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 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 a second request message to the next entity.
  • the Request Resource Creator parameter is generated by the entity that does not create the ⁇ request> resource, and then the next entity is sent, including The request message of the Request Resource Creator parameter, so that the local entity ⁇ request> resource creation can still continue to communicate when the resource creation fails.
  • the apparatus further includes a second receiving unit and a second sending unit.
  • the second receiving unit is configured to receive a first reply message sent by the next entity.
  • the first reply message includes address information of a ⁇ request> resource created by an entity that creates a ⁇ request> resource for the first request message.
  • the second sending unit is configured to send the first reply message to the upper entity.
  • the apparatus 170 further includes a third receiving unit and a third sending unit.
  • the third receiving unit is configured to receive a first acquisition request message sent by the last entity.
  • the first acquisition request message includes address information of a ⁇ request> resource created by an entity that creates a ⁇ request> resource for the first request message.
  • the first acquisition request message is used to request the entity that creates the ⁇ request> resource to obtain the processing result of the target resource.
  • the third sending unit is configured to send a first acquisition request message to the next entity.
  • 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 the next entity.
  • the second reply message includes the result of processing the target resource.
  • the fourth sending unit is configured to send a second reply message to the upper entity.
  • the device 170 further includes a determining unit.
  • the determining unit is configured to determine whether to create a ⁇ request> resource for the first request message.
  • 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.
  • the apparatus 170 further includes a creating unit, a fifth sending unit, a third generating unit, and a sixth sending 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 a third reply message to the upper entity.
  • the third reply message includes the address information of the created ⁇ request> resource.
  • the third generating unit is configured to generate a third request message.
  • the third request message includes a Request Resource Creator parameter. Set the Request Resource Creator parameter to the identifier of the transit CSE.
  • the sixth sending unit is configured to send a third request message to the next entity.
  • 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 the next entity.
  • the fourth reply message includes the processing result 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 acquisition request message sent by the previous entity.
  • the second acquisition request message includes address information of the created ⁇ request> resource.
  • the second acquisition request message is used by the previous entity to obtain the processing result of the target resource from the transit CSE.
  • the seventh sending unit is configured to send the first entity Five reply messages.
  • the fifth reply message includes the processing result of the target resource.
  • the apparatus for communicating in the M2M system may correspond to the method of communication in the M2M system of the embodiment of the present invention, and each unit/module in the apparatus and the other operations and/or functions described above are respectively implemented in FIG.
  • the corresponding process of the relevant CSE in the method shown is not repeated here for the sake of brevity.
  • FIG. 18 is a schematic block diagram of an apparatus for communication in a 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 the first request message in the non-blocking synchronous communication mode sent by the last 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 the last entity that created the request ⁇ request> resource for the first request message.
  • the first request message is used by the originating entity Originator to request the hosted CSE of the target resource to operate on the target resource.
  • the first sending unit 1802 is configured to send a first request message to the next entity when the request ⁇ request> resource is not created for the first request message.
  • the request resource indication field added in the RT parameter is used to indicate the previous creation.
  • ⁇ request> An identifier of the entity of the resource, such that the entity that does not create the ⁇ request> resource sends a request message to the next entity, so that communication can continue even when the ⁇ request> resource creation fails.
  • the device 180 further includes a second receiving unit and a second sending unit.
  • the second receiving unit is configured to receive a first reply message sent by the next entity.
  • the first reply message includes address information of a ⁇ request> resource created by an entity that creates a ⁇ request> resource for the first request message.
  • the second sending unit sends the first reply message to the previous entity.
  • the apparatus 180 further includes a third receiving unit and a third sending unit.
  • the third receiving unit is configured to receive a first acquisition request message sent by the last entity.
  • the first acquisition request message includes address information of a ⁇ request> resource created by an entity that creates a ⁇ request> resource for the first request message.
  • the first acquisition request message is used to request the entity that creates the ⁇ request> resource to obtain the processing result of the target resource.
  • the third sending unit is configured to send a first acquisition request message to the next entity.
  • 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 the next entity.
  • Second reply message Includes the results of processing the target resource.
  • the fourth sending unit is configured to send a second reply message to the upper entity.
  • the device 180 further includes a determining unit.
  • the determining unit is configured to determine whether to create a ⁇ request> resource for the first request message.
  • 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.
  • the apparatus 180 further includes a creating unit, a fifth sending unit, a generating unit, and a sixth sending 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 a third reply message to the upper entity.
  • the third reply message includes the address information of the created ⁇ request> resource.
  • the generating unit is configured to generate a second request message.
  • the second request message includes a request resource indication field. Set the request resource indication field to the identifier of the transit CSE.
  • the sixth sending unit is configured to send a second request message to the next entity.
  • 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 the next entity.
  • the fourth reply message includes the processing result 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 acquisition request message sent by the previous entity.
  • the second acquisition request message includes address information of the created ⁇ request> resource.
  • the second acquisition request message is used by the previous entity to obtain the processing result of the target resource from the transit CSE.
  • the seventh sending unit is configured to send a fifth reply message to the upper entity.
  • the fifth reply message includes the processing result of the target resource.
  • the apparatus for communication in the M2M system may correspond to the method of communication in the M2M system of the embodiment of the present invention, and each unit/module in the apparatus and the other operations and/or functions described above are respectively implemented in FIG.
  • the corresponding flow of the illustrated method and the corresponding flow of the relevant CSE in the method shown in FIG. 13 are not repeated herein for brevity.
  • FIG. 19 is a schematic block diagram of an apparatus for communication in a 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 a non-blocking synchronous communication mode sent by the last entity.
  • the first request message is used by the originating entity Originator to request the hosted CSE of the target resource to operate on the target resource.
  • the sending unit 1902 is configured to send an indication message to the upper entity when the request message received for the first receiving unit does not create a ⁇ request> resource.
  • the indication message includes requesting the resource not to create a Request Not Create parameter.
  • the Request Not Create parameter includes the identifier of the next entity.
  • the indication message is used to indicate that the previous entity sends a request message to the next entity.
  • the transit CSE adds a new Request Not Create parameter to indicate that the request is not created after receiving the request message sent by the previous entity to operate the target resource.
  • the request> resource entity sends a request message to other entities to continue communication when the ⁇ request> resource creation fails.
  • the apparatus further comprises a determining unit.
  • the determining unit is operative to determine whether to create a ⁇ request> resource for the request message.
  • 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 communicating in the M2M system may correspond to the method of communication in the M2M system of the embodiment of the present invention, and each unit/module in the apparatus and the other operations and/or functions described above are respectively implemented in FIG.
  • the corresponding flow of the method shown in FIG. 14 and the method shown in FIG. 14 is omitted here for brevity.
  • FIG. 20 is a schematic block diagram of an apparatus for communication in a oneM2M system in accordance with still another embodiment of the present invention.
  • the apparatus 200 of FIG. 20 includes a first transmitting unit 2001, a receiving unit 2002, and a second transmitting 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 by the initiating entity Originator to request the hosted general service entity Hosting CSE where the target resource is located to operate on the target resource.
  • the first receiving unit 2002 is configured to receive an indication message sent by the next entity.
  • the indication message includes requesting the resource not to create a Request Not Create parameter.
  • the Request Not Create parameter includes an identifier of the first entity.
  • the indication message is used to instruct the local entity to send a 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 that issues the Originator and an identifier of the Hosting CSE where the target resource is located.
  • the request message is used by 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 the request resource does not create a Request Not Create parameter. The time when the transit CSE resends the request message is located in the request resource and does not create the Request Not Create parameter.
  • the oneM2M system of the embodiment of the present invention communicates using the non-blocking synchronous communication mode
  • the transit CSE receives the request message sent by the previous entity to operate the target resource
  • the previous entity adds the new Request Not Create parameter.
  • An entity that does not create a ⁇ request> resource sends a request message to other entities to continue communication when the ⁇ request> resource creation fails.
  • the apparatus 200 further includes: the second sending unit is configured to resend the request message to the Hosting CSE.
  • the second receiving unit is configured to receive a reply message sent by the Hosting CSE.
  • the reply message includes the identifier of the Hosting CSE, the identifier of the Originator, and the processing result of the target resource.
  • the apparatus for communication in the oneM2M system may correspond to the method of communication in the oneM2M system of the embodiment of the present invention, and the respective units/modules in the apparatus and the other operations and/or functions described above are respectively implemented in FIG.
  • the corresponding flow of the method shown in FIG. 14 and the related method of the transfer CSE in the method shown in FIG. 14 will not be repeated here for brevity.
  • Embodiment 20 is a diagrammatic representation of Embodiment 20.
  • FIG. 21 is a schematic block diagram of an apparatus for communication in a oneM2M system in accordance with 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 a non-blocking synchronous communication mode sent by the transit CSE.
  • the request message is used by the Originator request to operate on the target resource.
  • the first sending unit 2102 is configured to: when the request message received for the unit does not create the request ⁇ request> resource, send the indication information to the transit CSE according to the request message.
  • the indication information is used to indicate that the transit CSE resends the request message after the first time period.
  • the Hosting CSE sends an indication message to the previous entity to indicate the previous entity after receiving the request message sent by the previous entity to operate the target resource.
  • the request message is resent after a certain period of time, so that the communication can continue to be continued when the ⁇ request> resource creation fails.
  • the device 210 further includes a processing unit.
  • the processing unit is configured to process the target resource according to the request message, and obtain a processing result for the target resource.
  • the device 210 further includes a second receiving unit and a second sending unit.
  • the second receiving unit is configured to receive a request message for retransmission by the transit CSE.
  • the second sending unit is configured to send a reply message to the transit CSE.
  • the reply message includes the result of processing the target resource.
  • the first duration is greater than the duration required to process the target resource.
  • the device 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 processing of the target resource is not completed after the first time period.
  • 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, a request message that the transit CSE transmits again.
  • the apparatus for communication in the oneM2M system may correspond to the method of communication in the oneM2M system of the embodiment of the present invention, and the respective units/modules in the apparatus and the other operations and/or functions described above are respectively implemented in FIG.
  • the corresponding flow of the related method and the related method of the Hosting CSE in the method shown in FIG. 15 is omitted here for brevity.
  • FIG. 22 is a schematic block diagram of an apparatus for communication in a oneM2M system in accordance with still another embodiment of the present invention.
  • the apparatus 220 of FIG. 22 includes 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 Hosting CSE.
  • the request message is used by the Originator to request the Hosting CSE to operate on the target resource.
  • the first receiving unit 2202 is configured to receive indication information that is sent by the Hosting CSE according to the request message.
  • the indication message is used to indicate that the request message is resent after the first time period of the transit CSE.
  • the oneM2M system in the embodiment of the present invention uses the non-blocking synchronous communication mode to communicate, after the next entity sends a request message requesting operation on the target resource, the local entity is instructed to receive the indication message sent by the next entity. The request message is then resent, so that the ⁇ request> resource creation can still continue to communicate when it fails.
  • the device 220 further includes a second sending unit and a second receiving unit.
  • the second sending unit is configured to resend the request message to the Hosting CSE.
  • the second receiving unit is configured to receive a reply message sent by the Hosting CSE.
  • the reply message includes the result of processing the target resource.
  • the first duration is greater than the duration required to process the target resource.
  • the device 220 further includes a third receiving unit and a third sending unit.
  • the third receiving unit is configured to receive an indication that the Hosting CSE resends after the first duration Message.
  • the third sending unit is configured to send the request message to the Hosting CSE again after the third time period.
  • the apparatus for communication in the M2M system may correspond to the method of communication in the M2M system of the embodiment of the present invention, and each unit/module in the apparatus and the other operations and/or functions described above are respectively implemented in FIG. Corresponding processes of the illustrated method and corresponding processes of the relevant CSE in the method shown in FIG. 15 are not described herein for brevity.
  • FIG. 23 is a schematic block diagram of an apparatus for communication in a oneM2M system according to an embodiment of the present invention.
  • the apparatus 230 of FIG. 23 includes a transmitter 2301, a receiver 2302, a processor 2303, and a memory 2304.
  • the various components of device 230 are coupled together by a bus system 2305.
  • a schematic block diagram of the relay CSE of the first embodiment may be as shown in the block diagram of FIG.
  • the receiver 2302 can receive the first request message in the non-blocking synchronous communication mode sent by the previous entity.
  • the first request message includes a request resource creator Request Resource Creator parameter.
  • the first request message is used by the initiating entity Originator to request the hosted general service entity Hosting CSE where the target resource is located to operate on the target resource.
  • the Request Resource Creator parameter is the default value or the identifier of the entity that created the request ⁇ request> resource for the first request message.
  • the transmitter 2301 may be configured to send a first request message to the next entity when the first request message received for the first receiving unit does not create a ⁇ request> resource.
  • the oneM2M system of the embodiment of the present invention communicates using the non-blocking synchronous communication mode, after receiving the request message for adding the Request Resource Creator parameter sent by the previous entity, the request is forwarded to the next entity by the entity that does not create the ⁇ request> resource.
  • the message can continue to communicate when the local entity ⁇ request> resource creation fails.
  • the receiver 2302 may be configured to receive a first reply message sent by the next entity.
  • the first reply message includes address information of a ⁇ request> resource created by an entity that creates a ⁇ request> resource for the first request message.
  • the transmitter 2301 can be configured to send the first reply message to the previous entity.
  • the receiver 2302 may be configured to receive a first acquisition request message sent by a previous entity.
  • the first acquisition request message includes address information of a ⁇ request> resource created by an entity that creates a ⁇ request> resource for the first request message.
  • the first acquisition request message is used to request the entity that creates the ⁇ request> resource to obtain the processing result of the target resource.
  • the transmitter 2301 can be configured to send a first acquisition request message to the next entity.
  • the receiver 2302 may be configured to receive a second reply message sent by the next entity.
  • the second reply message includes the result of processing the target resource.
  • the transmitter 2301 can be configured to send a second reply message to the next entity.
  • the processor 2303 may be configured to determine whether to create a ⁇ request> resource for the first request message.
  • the processor 2303 is specifically configured to determine, according to the capacity and/or the supported ⁇ request> resource type, whether to create a ⁇ request> resource for the first request message.
  • the processor 2303 is configured to create a ⁇ request> resource when determining to create a ⁇ request> resource for the first request message.
  • the transmitter 2301 is configured to send a third reply message to the upper entity.
  • the third reply message includes the address information of the created ⁇ request> resource.
  • the processor 2303 is further 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 also configured to send a second request message to the next entity.
  • the receiver 2302 is further configured to receive a fourth reply message sent by the next entity.
  • the fourth reply message includes the processing result of the target resource.
  • the processor 2303 is further configured to update the ⁇ request> resource created by the transit CSE according to the fourth reply message.
  • the receiver 2302 is further configured to receive a second acquisition request message sent by the last entity.
  • the second acquisition request message includes address information of the created ⁇ request> resource.
  • the second acquisition request message is used by the previous entity to obtain the processing result of the target resource from the transit CSE.
  • the transmitter 2301 is further configured to send a fifth reply message to the upper entity.
  • the fifth reply message includes the processing result of the target resource.
  • the relay CSE 230 can implement the related operations of FIG. 2 of the foregoing method embodiments, and can implement the operations of the related CSEs in FIG. 9, FIG. 10 and FIG. 11, and will not be described in detail in order to avoid repetition.
  • a schematic block diagram of the relay CSE of the second embodiment may be as shown in the block diagram of FIG.
  • 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 by the originating entity Originator to request the hosted CSE of the target resource to operate on the target resource.
  • the processor 2303 is configured to generate a request resource creator Request Resource Creator parameter when the request ⁇ request> resource is not created for the first request message.
  • the Request Resource Creator parameter is set to the default value or the identifier of the entity that created the request ⁇ request> resource for the first request message.
  • the processor 2303 is configured to generate a second request message according to the second request message.
  • the second request message includes a Request Resource Creator parameter.
  • the transmitter 2301 is configured to send a second request message to the next entity.
  • the Request Resource Creator parameter is generated by the entity that does not create the ⁇ request> resource, and then the next entity is sent, including The request message of the Request Resource Creator parameter, so that the local entity ⁇ request> resource creation can still continue to communicate when the resource creation fails.
  • the receiver 2302 may be configured to receive a first reply message sent by the next entity.
  • the first reply message includes address information of a ⁇ request> resource created by an entity that creates a ⁇ request> resource for the first request message.
  • the transmitter 2301 can be configured to send the first reply message to the previous entity.
  • the receiver 2302 may be configured to receive a first acquisition request message sent by a previous entity.
  • the first acquisition request message includes address information of a ⁇ request> resource created by an entity that creates a ⁇ request> resource for the first request message.
  • the first acquisition request message is used to request the entity that creates the ⁇ request> resource to obtain the processing result of the target resource.
  • the transmitter 2301 can be configured to send a first acquisition request message to the next entity.
  • the receiver 2302 may be configured to receive a second reply message sent by the next entity.
  • the second reply message includes the result of processing the target resource.
  • the transmitter 2301 can be configured to send a second reply message to the next entity.
  • the processor 2303 may be configured to determine whether to create a ⁇ request> resource for the first request message.
  • the processor 2303 is specifically configured to determine, according to the capacity and/or the supported ⁇ request> resource type, whether to create a ⁇ request> resource for the first request message.
  • the processor 2303 is configured to create a ⁇ request> resource when determining to create a ⁇ request> resource for the first request message.
  • the transmitter 2301 is configured to send a third reply message to the upper entity.
  • the third reply message includes the address information of the created ⁇ request> resource.
  • the processor 2303 is further 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 also configured to send a third request message to the next entity.
  • the receiver 2402 is further configured to receive the sending by the next entity.
  • Fourth reply message includes the processing result of the target resource.
  • the processor 2303 is further configured to update the ⁇ request> resource created by the transit CSE according to the fourth reply message.
  • the receiver 2302 is further configured to receive a second acquisition request message sent by the last entity.
  • the second acquisition request message includes address information of the created ⁇ request> resource.
  • the second acquisition request message is used by the previous entity to obtain the processing result of the target resource from the transit CSE.
  • the transmitter 2301 is further configured to send a fifth reply message to the upper entity.
  • the fifth reply message includes the processing result of the target resource.
  • a schematic block diagram of the relay CSE of the third embodiment may be as shown in the block diagram of FIG.
  • the receiver 2302 may be configured to receive the first request message in the non-blocking synchronous communication mode sent by the previous entity.
  • the first request message includes the carried response type RT parameter including the request resource indication field.
  • the first request message is used by the originating entity Originator to request the hosted CSE of the target resource to operate on the target resource.
  • the request resource indication field 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 send the first request message received by the receiver 2302 to the next entity when the request ⁇ request> resource is not created for the first request message.
  • the request resource indication field added in the RT parameter is used to indicate the previous creation.
  • ⁇ request> An identifier of the entity of the resource, such that the entity that does not create the ⁇ request> resource sends a request message to the next entity, so that communication can continue even when the ⁇ request> resource creation fails.
  • the receiver 2302 may be configured to receive a first reply message sent by the next entity.
  • the first reply message includes address information of a ⁇ request> resource created by an entity that creates a ⁇ request> resource for the first request message.
  • the transmitter 2301 can be configured to send the first reply message to the previous entity.
  • the receiver 2302 may be configured to receive a first acquisition request message sent by a previous entity.
  • the first acquisition request message includes address information of a ⁇ request> resource created by an entity that creates a ⁇ request> resource for the first request message.
  • the first acquisition request message is used to request the entity that creates the ⁇ request> resource to obtain the processing result of the target resource.
  • the transmitter 2501 can be configured to send a first acquisition request message to the next entity.
  • the receiver 2302 may be configured to receive a second reply message sent by the next entity.
  • the second reply message includes the result of processing the target resource.
  • Transmitter 2301 Can be used to send a second reply message to the next entity.
  • the processor 2303 may be configured to determine whether to create a ⁇ request> resource for the first request message.
  • the processor 2303 is specifically configured to determine, according to the capacity and/or the supported ⁇ request> resource type, whether to create a ⁇ request> resource for the first request message.
  • the processor 2303 is configured to create a ⁇ request> resource when determining to create a ⁇ request> resource for the first request message.
  • the transmitter 2301 is configured to send a third reply message to the upper entity.
  • the third reply message includes the address information of the created ⁇ request> resource.
  • the processor 2503 is further 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 also configured to send a second request message to the next entity.
  • the receiver 2302 is further configured to receive a fourth reply message sent by the next entity.
  • the fourth reply message includes the processing result of the target resource.
  • the processor 2303 is further configured to update the ⁇ request> resource created by the transit CSE according to the fourth reply message.
  • the receiver 2302 is further configured to receive a second acquisition request message sent by the last entity.
  • the second acquisition request message includes address information of the created ⁇ request> resource.
  • the second acquisition request message is used by the previous entity to obtain the processing result of the target resource from the transit CSE.
  • the transmitter 2301 is further configured to send a fifth reply message to the upper entity.
  • the fifth reply message includes the processing result of the target resource.
  • a schematic block diagram of the relay CSE of the fourth embodiment may be as shown in the block diagram of FIG.
  • the receiver 2302 can receive the request message in the non-blocking synchronous communication mode sent by the previous entity.
  • the first request message is used by the originating entity Originator to request the hosted CSE of the target resource to operate on the target resource.
  • the transmitter 2301 may be configured to send an indication message to the upper entity when the request message received for the first receiving unit does not create a ⁇ request> resource.
  • the indication message includes requesting the resource not to create a Request Not Create.
  • the parameter Request Not Create parameter includes the identifier of the next entity.
  • the indication message is used to indicate that the previous entity sends a request message to the next entity.
  • the transit CSE adds a new Request Not Create parameter to indicate that the request is not created after receiving the request message sent by the previous entity to operate the target resource.
  • the request> resource entity sends a request message to other entities to continue communication when the ⁇ request> resource creation fails.
  • the processor 2303 may be configured to determine whether to create a ⁇ request> resource for the request message.
  • the processor 2303 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.
  • a schematic block diagram of the relay CSE of the fifth embodiment may be as shown in the block diagram of FIG.
  • the transmitter 2301 can be configured to send a request message in the non-blocking synchronous communication mode to the next entity.
  • the request message is used by the originating entity Originator to request the hosted CSE to operate on the target resource.
  • the receiver 2302 is configured to receive an indication message sent by the next entity.
  • the indication message includes requesting the resource not to create a Request Not Create parameter.
  • the Request Not Create parameter includes an identifier of the first entity.
  • the indication message is used to instruct the local entity to send a request message to the first entity.
  • the transmitter 2301 is further configured to send a request message to the first entity.
  • the oneM2M system of the embodiment of the present invention communicates using the non-blocking synchronous communication mode
  • the transit CSE receives the request message sent by the previous entity to operate the target resource
  • the previous entity adds the new Request Not Create parameter.
  • An entity that does not create a ⁇ request> resource sends a request message to other entities to continue communication when the ⁇ request> resource creation fails.
  • a schematic block diagram of the relay CSE of the sixth embodiment can be as shown in the block diagram of FIG.
  • 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 by the Originator request to operate on the target resource.
  • the transmitter 2301 is configured to: when the request message received for the receiving unit does not create the request ⁇ request> resource, send the indication information to the transit CSE according to the request message.
  • the indication information is used to indicate that the transit CSE resends the request message after the first time period.
  • the Hosting CSE sends an indication message to the previous entity to indicate the previous entity after receiving the request message sent by the previous entity to operate the target resource.
  • the request message is resent after a certain period of time, so that the communication can continue to be continued when the ⁇ request> resource creation fails.
  • the processor 2303 is configured to process the target resource according to the request message to obtain a processing result of the target resource.
  • the receiver 2302 is configured to receive the retransmission of the transit CSE. Request message.
  • the transmitter 2301 is configured to send a reply message to the transit CSE.
  • the reply message includes the result of processing the target resource.
  • the first duration is greater than the duration required to process the target resource.
  • the transmitter 2301 is configured to resend the indication message to the transit CSE when the processing of the target resource is not completed after the first duration.
  • 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 that the relay CSE transmits again after the third time period.
  • a schematic block diagram of the relay CSE of Embodiment 7 may be as shown in the block diagram of FIG.
  • the transmitter 2301 can be configured to send a request message in the non-blocking synchronous communication mode to the hosting Hosting CSE.
  • the request message is used by the Originator to request the Hosting CSE to operate on the target resource.
  • the receiver 2302 is configured to receive indication information that is sent by the Hosting CSE according to the request message.
  • the indication message is used to indicate that the request message is resent after the first time period of the transit CSE.
  • the oneM2M system in the embodiment of the present invention uses the non-blocking synchronous communication mode to communicate, after the next entity sends a request message requesting operation on the target resource, the local entity is instructed to receive the indication message sent by the next entity. The request message is then resent, so that the ⁇ request> resource creation can still continue to communicate when it fails.
  • the transmitter 2301 is configured to resend the request message to the Hosting CSE.
  • the receiver 2302 is configured to receive a reply message sent by the Hosting CSE.
  • the reply message includes the result of processing the target resource.
  • the first duration is greater than the duration required to process the target resource.
  • the receiver 2302 is configured to receive an indication message that the Hosting CSE retransmits after the first duration.
  • the transmitter 2301 is configured to send a request message to the Hosting CSE again after the third time period.
  • the processor controls the operation of the device and can be used to process signals.
  • the memory can include read only memory and random access memory and provides instructions and data to the processor.
  • the transmitter and receiver can be coupled to an antenna.
  • the various components of the device are coupled together by a bus system, wherein the bus system includes a power bus, a control bus, and a status signal bus in addition to the data bus. But for clarity For the sake of illustration, various buses are labeled as bus systems in the figure.
  • the method disclosed in the foregoing embodiments of the present invention may be applied to a processor or implemented by a processor.
  • each step of the above method may be completed by an integrated logic circuit of hardware in a processor or an instruction in a 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, a discrete gate or transistor logic device, a discrete hardware component, or may implement or perform the embodiments of the present invention.
  • a general purpose processor can be a microprocessor or any conventional processor or the like.
  • the steps of the method disclosed in the embodiments of the present invention may be directly implemented as a hardware processor, or may be performed by a combination of hardware and software modules in the processor.
  • the software module can be located in a conventional storage medium such as random access memory, flash memory, read only memory, programmable read only memory or electrically erasable programmable memory, registers, and the like.
  • the storage medium is located in the memory, and the processor reads the information in the memory and combines the hardware to complete the steps of the above method.
  • the size of the sequence numbers of the above processes does not mean the order of execution, and the order of execution of each process should be determined by its function and internal logic, and should not be taken to the embodiments of the present invention.
  • the implementation process constitutes any limitation.
  • B corresponding to A means that B is associated with A, and B can be determined according to A.
  • determining B from A does not mean that B is only determined based on A, and that B can also be determined based on A and/or other information.
  • the disclosed systems, devices, and methods may be implemented in other manners.
  • the device embodiments described above are merely illustrative.
  • the division of the unit is only a logical function division.
  • there may be another division manner for example, multiple units or components may be combined or Can be integrated into another system, or some features can be ignored or not executed.
  • Another point that is shown or discussed between each other The coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interface, device or unit, and may be in an electrical, mechanical or other form.
  • the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed to multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of the embodiment.
  • the functions may be stored in a computer readable storage medium if implemented in the form of a software functional unit and sold or used as a standalone product.
  • the technical solution of the present invention which is essential or contributes to the prior art, or a part of the technical solution, may be embodied in the form of a software product, which is stored in a storage medium, including
  • the instructions are used to cause a computer device (which may be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in various embodiments of the present invention.
  • the foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and the like. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明实施例提供了一种oneM2M系统中通信的方法和装置。该方法包括接收上一个实体发送的非阻塞同步通信模式下的第一请求消息，第一请求消息包括请求资源创建者Request Resource Creator参数。Request Resource Creator参数为缺省值或上一个针对第一请求消息创建＜request＞资源的实体的标识符。当针对所述第一请求消息不创建＜request＞资源时，向下一个实体发送第一请求消息。本发明实施例在接收请求消息之后，通过增加新的参数用于指示不创建＜request＞资源的实体向下一个实体转发该请求消息，以在＜request＞资源创建失败时继续进行通信。

Description

统一机器到机器系统中通信的方法和装置 技术领域
本发明实施例涉及通信领域，并且更具体地，涉及一种统一机器到机器系统中通信的方法和装置。
背景技术
随着物联网技术的发展，全球化标准组织统一机器到机器(英文：one Machine to Machine,简称：oneM2M)随之成立，它旨在高效地部署机器到机器(英文：Machine to Machine，简称：M2M)通信系统，推动M2M全球标准与行业应用融合。现有oneM2M体系采用分层构架，整个构架分为应用层(英文：Application Layer)、公共服务层(英文：Common Service Layer)和底层网络服务层(英文：Network Service Layer)。应用层中的应用实体(英文：Application Entity，简称：AE)包含实例化的端到端oneM2M解决方案。公共服务层中的公共服务实体(英文：Common Service Entity，简称：CSE)包含实例化的公共服务功能，CSE是oneM2M中的核心层，管理负责汇聚应用层信息形成资源池同时协调底层网络传输，起到平台的作用。底层网络服务层中的底层网络实体(英文：Network Service Entity，简称：NSE)管理负责底层网络传输，向公共服务层提供底层网络支持。
oneM2M体系中层与层之间的参考点(即接口)有3种。其中，Mca：AE与CSE之间的接口，负责AE到CSE或CSE到AE间的通信，使AE能够使用CSE提供的业务，并使CSE能够反向与AE通信。Mcc/Mcc’：两个CSE间的接口，负责CSE间的通信，使一个CSE能使用另一个CSE所提供的功能。Mcn：CSE与NSE之间的接口，负责CSE到NSE或NSE到CSE间的通信，使CSE能使用承载网络提供给上层的业务。
现有oneM2M标准采用了表示层状态转化(英文：Representational State Transfer，简称：REST)得到架构。oneM2M系统中AE、CSE的信息和数据信息都可以用资源来表示。同时，oneM2M系统中的行为可以使用下列五种操作来实现：创建(英文：Create)、获取(英文：Retrieve)、更新(英文：Update)、删除(英文：Delete)和通知(英文：Notify)。其中，Create用于CSE或者AE在其他CSE上创建一个资源。Retrieve用于获取存储在CSE 上的资源的属性。Update用于更新存储在目标资源的属性中的信息。Delete用于删除CSE上的资源。Notify用于通知信息。
现有oneM2M标准中定义了阻塞(英文：Blocking)、非阻塞同步(英文：Non-Blocking Synchronous)、非阻塞异步(英文：Non-Blocking Asynchronous)3种通信模式。在非阻塞同步通信模式下，当目标资源存储在托管通用服务实体(英文：Hosting CSE)中时，发起实体(英文：Originator)可以向Hosting CSE发送请求消息，请求对目标资源进行操作。Originator发送的请求消息经过一个中转CSE的转发可以到达Hosting CSE。中转CSE在收到请求消息之后，需要创建请求＜request＞资源以完成继续通信过程。
Originator与Hosting CSE之间可能是多跳的，即Originator发送的请求消息经过多个Transit CSE的转发到达Hosting CSE。对于多个中转CSE，为了完成继续通信过程，每个中转CSE都需要创建请求＜request＞资源。但是，对于一些中转CSE无法创建＜request＞资源，例如，中转CSE不支持＜request＞资源类型或中转CSE的容量有限。还比如，一些中转CSE可以创建＜request＞资源，但根据自身情况不创建＜request＞资源。在这些情况下，当前面N(N为大于1的正整数)个中转CSE都已成功创建＜request＞资源，第N+1个中转或Hosting CSE无法创建＜request＞资源时，回复创建＜request＞资源失败的消息。这样，如果某一个实体＜request＞资源创建失败，Originator请求对目标资源进行操作的通信过程无法继续进行。
发明内容
本发明实施例提供一种统一机器到机器系统中通信的方法和装置，从而能够在＜request＞资源创建失败时仍然可以继续进行通信。
第一方面，提供了一种统一机器到机器M2M系统中通信的方法，包括：接收上一个实体发送的非阻塞同步通信模式下的第一请求消息，所述第一请求消息包括请求资源创建者Request Resource Creator参数，所述Request Resource Creator参数为缺省值或上一个针对所述第一请求消息创建请求＜request＞资源的实体的标识符，所述第一请求消息用于发起实体Originator向目标资源所在的托管通用服务实体Hosting CSE请求对所述目标资源进行操作；当针对所述第一请求消息不创建＜request＞资源时，向下一个实体发送所述第一请求消息。
结合第一方面，在第一方面的一种实现方式中，接收所述下一个实体发送的第一回复消息，所述第一回复消息包括下一个针对所述第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息；向所述上一个实体发送所述第一回复消息。
结合第一方面及其上述实现方式，在第一方面的另一种实现方式中，接收所述上一个实体发送的第一获取请求消息，所述第一获取请求消息包括所述下一个针对所述第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息，所述第一获取请求消息用于向所述下一个创建＜request＞资源的实体请求获取所述对目标资源的处理结果；向所述下一个实体发送所述第一获取请求消息。
结合第一方面及其上述实现方式，在第一方面的另一种实现方式中，接收所述下一个实体发送的第二回复消息，所述第二回复消息包括所述对目标资源的处理结果；向所述上一个实体发送所述第二回复消息。
结合第一方面及其上述实现方式，在第一方面的另一种实现方式中，在所述向下一个实体发送所述第一请求消息之前，所述方法还包括：确定是否针对所述第一请求消息创建＜request＞资源。
结合第一方面及其上述实现方式，在第一方面的另一种实现方式中，确定是否针对所述第一请求消息创建＜request＞资源包括：根据容量和/或支持的＜request＞资源类型确定是否针对所述第一请求消息创建＜request＞资源。
结合第一方面及其上述实现方式，在第一方面的另一种实现方式中，所述方法由中转CSE执行，所述方法还包括：当确定针对所述第一请求消息创建＜request＞资源时，创建＜request＞资源；向所述上一个实体发送第三回复消息，所述第三回复消息包括创建的＜request＞资源的地址信息；生成第二请求消息，所述第二请求消息包括所述Request Resource Creator参数，所述Request Resource Creator参数设置为所述中转CSE的标识符；向所述下一个实体发送所述第二请求消息。
结合第一方面及其上述实现方式，在第一方面的另一种实现方式中，接收所述下一个实体发送的第四回复消息，所述第四回复消息包括所述对目标资源的处理结果；根据所述第四回复消息更新所述中转CSE创建的所述＜request＞资源；接收所述上一个实体发送的第二获取请求消息，所述第二获 取请求消息包括创建的＜request＞资源的地址信息，所述第二获取请求消息用于所述上一个实体向所述中转CSE请求获取所述对目标资源的处理结果；向所述上一个实体发送第五回复消息，所述第五回复消息包括所述对目标资源的处理结果。
第二方面，提供了一种统一机器到机器oneM2M系统中通信的方法，其特征在于，包括：接收上一个实体发送的非阻塞同步通信模式下的第一请求消息，所述第一请求消息用于发起实体Originator向目标资源所在的托管通用服务实体Hosting CSE请求对所述目标资源进行操作；当针对所述第一请求消息不创建请求＜request＞资源时，生成请求资源创建者Request Resource Creator参数，所述Request Resource Creator参数设置为缺省值或上一个针对所述第一请求消息创建请求＜request＞资源的实体的标识符；生成第二请求消息，所述第二请求消息包括所述Request Resource Creator参数；向下一个实体发送所述生成第二请求消息。
结合第二方面，在第二方面的一种实现方式中，接收所述下一个实体发送的第一回复消息，所述第一回复消息包括下一个针对所述第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息；向所述上一个实体发送所述第一回复消息。
结合第二方面及其上述实现方式，在第二方面的另一种实现方式中，接收所述上一个实体发送的第一获取请求消息，所述第一获取请求消息包括所述下一个针对所述第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息，所述第一获取请求消息用于向所述下一个创建＜request＞资源的实体请求获取所述对目标资源的处理结果；向所述下一个实体发送所述第一获取请求消息。
结合第二方面及其上述实现方式，在第二方面的另一种实现方式中，接收所述下一个实体发送的第二回复消息，所述第二回复消息包括所述对目标资源的处理结果；向所述上一个实体发送所述第二回复消息。
结合第一方面及其上述实现方式，在第一方面的另一种实现方式中，在所述向下一个实体发送所述第一请求消息之前，所述方法还包括：确定是否针对所述第一请求消息创建＜request＞资源。
结合第二方面及其上述实现方式，在第二方面的另一种实现方式中，确定是否针对所述第一请求消息创建＜request＞资源包括：根据容量和/或支持 的＜request＞资源类型确定是否针对所述第一请求消息创建＜request＞资源。
结合第二方面及其上述实现方式，在第二方面的另一种实现方式中，所述方法由中转CSE执行，所述方法还包括：当确定针对所述第一请求消息创建＜request＞资源时，创建＜request＞资源；向所述上一个实体发送第三回复消息，所述第三回复消息包括创建的＜request＞资源的地址信息；生成第三请求消息，所述第三请求消息包括所述Request Resource Creator参数，所述Request Resource Creator参数设置为所述中转CSE的标识符；向所述下一个实体发送所述第三请求消息。
结合第二方面及其上述实现方式，在第二方面的另一种实现方式中，接收所述下一个实体发送的第四回复消息，所述第四回复消息包括所述对目标资源的处理结果；根据所述第四回复消息更新所述中转CSE创建的所述＜request＞资源；接收所述上一个实体发送的第二获取请求消息，所述第二获取请求消息包括创建的＜request＞资源的地址信息，所述第二获取请求消息用于所述上一个实体向所述中转CSE请求获取所述对目标资源的处理结果；向所述上一个实体发送第五回复消息，所述第五回复消息包括所述对目标资源的处理结果。
第三方面，提供了一种统一机器到机器oneM2M系统中通信的方法，其特征在于，包括：接收上一个实体发送的非阻塞同步通信模式下的第一请求消息，所述第一请求消息携带的响应类型RT参数包括请求资源指示字段，所述第一请求消息用于发起实体Originator向目标资源所在的托管通用服务实体Hosting CSE请求对目标资源进行操作，请求资源指示字段为缺省值或上一个针对所述第一请求消息创建请求＜request＞资源的实体的标识符。当针对所述第一请求消息不创建请求＜request＞资源时，向下一个实体发送所述第一请求消息。
结合第三方面，在第三方面的一种实现方式中，接收所述下一个实体发送的第一回复消息，所述第一回复消息包括下一个针对所述第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息；向所述上一个实体发送所述第一回复消息。
结合第三方面及其上述实现方式，在第三方面的另一种实现方式中，接收所述上一个实体发送的第一获取请求消息，所述第一获取请求消息包括所 述下一个针对所述第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息，所述第一获取请求消息用于向所述下一个创建＜request＞资源的实体请求获取所述对目标资源的处理结果；向所述下一个实体发送所述第一获取请求消息。
结合第三方面及其上述实现方式，在第三方面的另一种实现方式中，接收所述下一个实体发送的第二回复消息，所述第二回复消息包括所述对目标资源的处理结果；向所述上一个实体发送所述第二回复消息。
结合第三方面及其上述实现方式，在第三方面的另一种实现方式中，在所述向下一个实体发送所述第一请求消息之前，所述方法还包括：确定是否针对所述第一请求消息创建＜request＞资源。
结合第三方面及其上述实现方式，在第三方面的另一种实现方式中，确定是否针对所述第一请求消息创建＜request＞资源包括：根据容量和/或支持的＜request＞资源类型确定是否针对所述第一请求消息创建＜request＞资源。
结合第三方面及其上述实现方式，在第三方面的另一种实现方式中，所述方法由中转CSE执行，所述方法还包括：当确定针对所述第一请求消息创建＜request＞资源时，创建＜request＞资源；向所述上一个实体发送第三回复消息，所述第三回复消息包括创建的＜request＞资源的地址信息；生成第二请求消息，所述第二请求消息包括所述请求资源指示字段，所述请求资源指示字段设置为所述中转CSE的标识符；向所述下一个实体发送所述第二请求消息。
结合第三方面及其上述实现方式，在第三方面的另一种实现方式中，接收所述下一个实体发送的第四回复消息，所述第四回复消息包括所述对目标资源的处理结果；根据所述第四回复消息更新所述中转CSE创建的所述＜request＞资源；接收所述上一个实体发送的第二获取请求消息，所述第二获取请求消息包括创建的＜request＞资源的地址信息，所述第二获取请求消息用于所述上一个实体向所述中转CSE请求获取所述对目标资源的处理结果；向所述上一个实体发送第五回复消息，所述第五回复消息包括所述对目标资源的处理结果。
第四方面，提供了一种统一机器到机器M2M系统中的通信的方法，包括：接收上一个实体发送的非阻塞同步通信模式下的请求消息，所述请求消 息用于发起实体Originator向目标资源所在的托管通用服务实体Hosting CSE请求对所述目标资源进行操作；当针对所述第一请求消息不创建＜request＞资源时，向所述上一个实体发送指示消息，所述指示消息包括请求资源不创建Request Not Create参数，所述Request Not Create参数包括下一个实体的标识符，所述指示消息用于指示所述上一个实体向所述下一个实体发送所述第一请求消息。
结合第四方面及其上述实现方式，在第四方面的另一种实现方式中，所述方法还包括：确定是否针对所述请求消息创建＜request＞资源。
结合第四方面及其上述实现方式，在第四方面的另一种实现方式中，确定是否针对所述请求消息创建＜request＞资源包括：根据容量和/或支持的＜request＞资源类型确定是否针对所述请求消息创建＜request＞资源。
第五方面，提供了一种统一机器到机器M2M系统中的通信的方法，向下一个实体发送非阻塞同步通信模式下的请求消息，所述请求消息用于发起实体Originator向目标资源所在的托管通用服务实体Hosting CSE请求对所述目标资源进行操作；接收所述下一个实体发送的指示消息，所述指示消息包括请求资源不创建Request Not Create参数，所述Request Not Create参数包括第一实体的标识符，所述指示消息用于指示本地实体向所述第一实体发送所述请求消息；向所述第一实体发送所述请求消息。
第六方面，提供了一种统一机器到机器oneM2M系统中通信的方法，包括：接收中转通用服务实体CSE发送的非阻塞同步通信模式下的请求消息，所述请求消息用于发起实体Originator请求对目标资源进行操作；当针对所述请求消息不创建请求＜request＞资源时，根据所述请求消息向所述中转CSE发送指示信息，所述指示信息用于指示所述中转CSE在第一时长之后重新发送所述请求消息。
结合第六方面，在第六方面的一种实现方式中，所述确定单元具体用于：根据是否支持所述＜request＞资源类型和/或是否容量超过第一阈值确定是否针对所述目标资源创建所述＜request＞资源。
结合第六方面及其上述实现方式，在第六方面的另一种实现方式中，根据所述请求消息对所述目标资源进行处理，得到所述对目标资源的处理结果。
结合第六方面及其上述实现方式，在第四方面的另一种实现方式中，所 述方法还包括：接收所述中转CSE重新发送的所述请求消息；向所述中转CSE发送回复消息，所述回复消息包括所述对目标资源的处理结果。
结合第六方面及其上述实现方式，在第六方面的另一种实现方式中，所所述第一时长大于处理所述目标资源所需的时长。
结合第六方面及其上述实现方式，在第六方面的另一种实现方式中，所所述方法还包括：在第一时长之后未完成对所述目标资源的处理时，向所述中转CSE重新发送所述指示消息；或者，在第二时长之后未收到所述中转CSE发送的请求消息，丢弃对所述目标资源的处理结果；在第三时长之后，接收中转CSE再次发送的请求消息。
第七方面，提供了一种统一机器到机器oneM2M系统中的通信的方法，包括：向托管Hosting CSE发送非阻塞同步通信模式下的请求消息，所述请求消息用于发起实体Originator向所述Hosting CSE请求访问目标资源；接收所述Hosting CSE根据所述请求消息发送的指示信息，所述指示消息用于指示第一时长之后重新发送所述请求消息。
结合第七方面，在第七方面的一种实现方式中，所述方法还包括：向所述Hosting CSE重新发送所述请求消息；接收所述Hosting CSE发送的回复消息，所述回复消息包括所述对目标资源的处理结果。
结合第七方面及上述实现方式，在第七方面的另一种实现方式中，所述第一时长大于处理所述目标资源所需的时长。
结合第七方面及上述实现方式，在第七方面的另一种实现方式中，所述方法还包括：在第一时长之后，接收所述Hosting CSE重新发送的指示消息；或者，在第三时长之后，向所述Hosting CSE再次发送所述请求消息。
第八方面，提供了一种统一机器到机器oneM2M系统中的通信的装置，第一接收单元用于接收上一个实体发送的非阻塞同步通信模式下的第一请求消息，第一请求消息包括请求资源创建者Request Resource Creator参数，所述Request Resource Creator参数为缺省值或上一个针对所述第一请求消息创建请求＜request＞资源的实体的标识符，所述第一请求消息用于发起实体Originator向目标资源所在的托管通用服务实体Hosting CSE请求对所述目标资源进行操作；第一发送单元用于当针对所述第一接收单元接收的所述第一请求消息不创建＜request＞资源时，向下一个实体发送所述第一请求消息。
结合第八方面，在第八方面的一种实现方式中，所述装置还包括：第二 接收单元，用于接收所述下一个实体发送的第一回复消息，所述第一回复消息包括下一个针对所述第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息；第二发送单元，向所述上一个实体发送所述第一回复消息。
结合第八方面及上述实现方式，在第八方面的另一种实现方式中，所述装置还包括：第三接收单元，用于接收所述上一个实体发送的第一获取请求消息，所述第一获取请求消息包括所述下一个针对所述第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息，所述第一获取请求消息用于向所述下一个创建＜request＞资源的实体请求获取所述对目标资源的处理结果；第三发送单元，用于向所述下一个实体发送所述第一获取请求消息。
结合第八方面及上述实现方式，在第八方面的另一种实现方式中，所述装置还包括：第四接收单元，用于接收所述下一个实体发送的第二回复消息，所述第二回复消息包括所述对目标资源的处理结果；第四发送单元，用于向所述上一个实体发送所述第二回复消息。
结合第八方面及上述实现方式，在第八方面的另一种实现方式中，所述装置还包括：确定单元，用于确定是否针对所述第一请求消息创建＜request＞资源。
结合第八方面及上述实现方式，在第八方面的另一种实现方式中，所述确定确定单元具体用于：根据容量和/或支持的＜request＞资源类型确定是否针对所述第一请求消息创建＜request＞资源。
结合第八方面及上述实现方式，在第八方面的另一种实现方式中，所述装置为中转CSE，所述装置还包括：创建单元，用于当确定针对所述第一请求消息创建＜request＞资源时，创建＜request＞资源；第五发送单元，用于向所述上一个实体发送第三回复消息，所述第三回复消息包括创建的＜request＞资源的地址信息；生成单元，用于生成第二请求消息，所述第二请求消息包括所述Request Resource Creator参数，所述Request Resource Creator参数设置为所述中转CSE的标识符；第六发送单元，用于向所述下一个实体发送所述第二请求消息。
结合第八方面及上述实现方式，在第八方面的另一种实现方式中，所述装置还包括：第五接收单元，用于接收所述下一个实体发送的第四回复消息， 所述第四回复消息包括所述对目标资源的处理结果；更新单元，用于根据所述第四回复消息更新所述中转CSE创建的所述＜request＞资源；第六接收单元，用于接收所述上一个实体发送的第二获取请求消息，所述第二获取请求消息包括创建的＜request＞资源的地址信息，所述第二获取请求消息用于所述上一个实体向所述中转CSE请求获取所述对目标资源的处理结果；第七发送单元，用于向所述上一个实体发送第五回复消息，所述第五回复消息包括所述对目标资源的处理结果。
第九方面，提供了一种统一机器到机器oneM2M系统中的通信的装置，第一接收单元用于接收上一个实体发送的非阻塞同步通信模式下的第一请求消息，所述第一请求消息用于发起实体Originator向目标资源所在的托管通用服务实体Hosting CSE请求对所述目标资源进行操作；第一生成单元，用于当针对所述第一请求消息不创建请求＜request＞资源时，生成请求资源创建者Request Resource Creator参数，所述Request Resource Creator参数设置为缺省值或上一个针对所述第一请求消息创建请求＜request＞资源的实体的标识符；第二生成单元，用于生成第二请求消息，所述第二请求消息包括所述Request Resource Creator参数；第一发送单元，用于向下一个实体发送所述第二请求消息。
结合第九方面，在第九方面的一种实现方式中，所述装置还包括：第二接收单元，用于接收所述下一个实体发送的第一回复消息，所述第一回复消息包括下一个针对所述第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息；第二发送单元，向所述上一个实体发送所述第一回复消息。
结合第九方面及上述实现方式，在第九方面的另一种实现方式中，所述装置还包括：第三接收单元，用于接收所述上一个实体发送的第一获取请求消息，所述第一获取请求消息包括所述下一个针对所述第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息，所述第一获取请求消息用于向所述下一个创建＜request＞资源的实体请求获取所述对目标资源的处理结果；第三发送单元，用于向所述下一个实体发送所述第一获取请求消息。
结合第九方面及上述实现方式，在第九方面的另一种实现方式中，所述装置还包括：第四接收单元，用于接收所述下一个实体发送的第二回复消息， 所述第二回复消息包括所述对目标资源的处理结果；第四发送单元，用于向所述上一个实体发送所述第二回复消息。
结合第九方面及上述实现方式，在第九方面的另一种实现方式中，所述装置还包括：确定单元，用于确定是否针对所述第一请求消息创建＜request＞资源。
结合第九方面及上述实现方式，在第九方面的另一种实现方式中，所述确定确定单元具体用于：根据容量和/或支持的＜request＞资源类型确定是否针对所述第一请求消息创建＜request＞资源。
结合第九方面及上述实现方式，在第九方面的另一种实现方式中，所述装置为中转CSE，所述装置还包括：创建单元，用于当确定针对所述第一请求消息创建＜request＞资源时，创建＜request＞资源；第五发送单元，用于向所述上一个实体发送第三回复消息，所述第三回复消息包括创建的＜request＞资源的地址信息；第三生成单元，用于生成第三请求消息，所述第三请求消息包括所述Request Resource Creator参数，所述Request Resource Creator参数设置为所述中转CSE的标识符；第六发送单元，用于向所述下一个实体发送所述第三请求消息。
结合第九方面及上述实现方式，在第九方面的另一种实现方式中，所述装置还包括：第五接收单元，用于接收所述下一个实体发送的第四回复消息，所述第四回复消息包括所述对目标资源的处理结果；更新单元，用于根据所述第四回复消息更新所述中转CSE创建的所述＜request＞资源；第六接收单元，用于接收所述上一个实体发送的第二获取请求消息，所述第二获取请求消息包括创建的＜request＞资源的地址信息，所述第二获取请求消息用于所述上一个实体向所述中转CSE请求获取所述对目标资源的处理结果；第七发送单元，用于向所述上一个实体发送第五回复消息，所述第五回复消息包括所述对目标资源的处理结果。
第十方面，提供了一种统一机器到机器oneM2M系统中的通信的装置，第一接收单元用于用于接收上一个实体发送的非阻塞同步通信模式下的第一请求消息，所述第一请求消息携带的响应类型RT参数包括请求资源指示字段，所述第一请求消息用于发起实体Originator向目标资源所在的托管通用服务实体Hosting CSE请求对所述目标资源进行操作，所述请求资源指示字段为缺省值或上一个针对所述第一请求消息创建请求＜request＞资源的 实体的标识符；第一发送单元用于当针对所述第一接收单元接收的所述第一请求消息不创建＜request＞资源时，向下一个实体发送所述第一请求消息。
结合第十方面，在第十方面的一种实现方式中，所述装置还包括：第二接收单元，用于接收所述下一个实体发送的第一回复消息，所述第一回复消息包括下一个针对所述第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息；第二发送单元，向所述上一个实体发送所述第一回复消息。
结合第十方面及上述实现方式，在第十方面的另一种实现方式中，所述装置还包括：第三接收单元，用于接收所述上一个实体发送的第一获取请求消息，所述第一获取请求消息包括所述下一个针对所述第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息，所述第一获取请求消息用于向所述下一个创建＜request＞资源的实体请求获取所述对目标资源的处理结果；第三发送单元，用于向所述下一个实体发送所述第一获取请求消息。
结合第十方面及上述实现方式，在第十方面的另一种实现方式中，所述装置还包括：第四接收单元，用于接收所述下一个实体发送的第二回复消息，所述第二回复消息包括所述对目标资源的处理结果；第四发送单元，用于向所述上一个实体发送所述第二回复消息。
结合第十方面及上述实现方式，在第十方面的另一种实现方式中，所述装置还包括：确定单元，用于确定是否针对所述第一请求消息创建＜request＞资源。
结合第十方面及上述实现方式，在第十方面的另一种实现方式中，所述确定确定单元具体用于：根据容量和/或支持的＜request＞资源类型确定是否针对所述第一请求消息创建＜request＞资源。
结合第十方面及上述实现方式，在第十方面的另一种实现方式中，所述装置为中转CSE，所述装置还包括：创建单元，用于当确定针对所述第一请求消息创建＜request＞资源时，创建＜request＞资源；第五发送单元，用于向所述上一个实体发送第三回复消息，所述第三回复消息包括创建的＜request＞资源的地址信息；生成单元，用于生成第二请求消息，所述第二请求消息包括所述请求资源指示字段，所述请求资源指示字段设置为所述中转CSE的标识符；第六发送单元，用于向所述下一个实体发送所述第二请求消 息。
结合第十方面及上述实现方式，在第十方面的另一种实现方式中，所述装置还包括：第五接收单元，用于接收所述下一个实体发送的第四回复消息，所述第四回复消息包括所述对目标资源的处理结果；更新单元，用于根据所述第四回复消息更新所述中转CSE创建的所述＜request＞资源；第六接收单元，用于接收所述上一个实体发送的第二获取请求消息，所述第二获取请求消息包括创建的＜request＞资源的地址信息，所述第二获取请求消息用于所述上一个实体向所述中转CSE请求获取所述对目标资源的处理结果；第七发送单元，用于向所述上一个实体发送第五回复消息，所述第五回复消息包括所述对目标资源的处理结果。
第十一方面，提供了一种统一机器到机器oneM2M系统中的通信的装置，包括：接收单元，用于接收上一个实体发送的非阻塞同步通信模式下的请求消息，所述第一请求消息用于发起实体Originator向目标资源所在的托管通用服务实体Hosting CSE请求对所述目标资源进行操作；发送单元，用于当针对所述第一接收单元结收地所述请求消息不创建＜request＞资源时，向所述上一个实体发送指示消息，所述指示消息包括Request Not Create参数，所述Request Not Create参数包括下一个实体的标识符，所述指示消息用于指示所述上一个实体向所述下一个实体发送所述请求消息。
结合第十一方面，在第十一方面的一种实现方式中，装置还包括：确定单元，用于确定是否针对所述请求消息创建＜request＞资源。
结合第十一方面及上述实现方式，在第十一方面的另一种实现方式中，确定单元具体用于：根据容量和/或支持的＜request＞资源类型确定是否针对所述请求消息创建＜request＞资源。
第十二方面，提供了一种统一机器到机器oneM2M系统中的通信的装置，包括：第一发送单元，用于向下一个实体发送非阻塞同步通信模式下的请求消息，所述请求消息用于发起实体Originator向目标资源所在的托管通用服务实体Hosting CSE请求对所述目标资源进行操作；接收单元，用于接收所述下一个实体发送的指示消息，所述指示消息包括请求资源不创建Request Not Create参数，所述Request Not Create参数包括第一实体的标识符，所述指示消息用于指示本地实体向所述第一实体发送所述请求消息；第二发送单元，用于向所述第一实体发送所述请求消息。
第十三方面，提供了一种统一机器到机器oneM2M系统中的通信的装置，包括：第一接收单元，用于接收中转通用服务实体CSE发送的非阻塞同步通信模式下的请求消息，所述请求消息用于发起实体Originator请求对目标资源进行操作；第一发送单元，用于当针对所述接收单元接收的所述请求消息不创建请求＜request＞资源时，根据所述请求消息向所述中转CSE发送指示信息，所述指示信息用于指示所述中转CSE在第一时长之后重新发送所述请求消息。
结合第十三方面，在第十三方面的一种实现方式中，装置还包括：处理单元，用于根据所述请求消息对所述目标资源进行处理，得到所述对目标资源的处理结果。
结合第十三方面及上述实现方式，在第十三方面的另一种实现方式中，装置还包括：第二接收单元，用于接收所述中转CSE重新发送的所述请求消息；第二发送单元，用于向所述中转CSE发送回复消息，所述回复消息包括所述对目标资源的处理结果。
结合第十三方面及上述实现方式，在第十三方面的另一种实现方式中，所述第一时长大于处理所述目标资源所需的时长。
结合第十三方面及上述实现方式，在第十三方面的另一种实现方式中，所述装置还包括：第三发送单元，用于在第一时长之后未收到所述中转CSE发送的请求消息或未完成对所述目标资源的处理时，向所述中转CSE重新发送所述指示消息。
第十四方面，提供了一种统一机器到机器oneM2M系统中的通信的装置，包括：第一发送单元，用于向托管Hosting CSE发送非阻塞同步通信模式下的请求消息，所述请求消息用于发起实体Originator向所述Hosting CSE请求访问目标资源；第一接收单元，用于接收所述Hosting CSE根据所述请求消息发送的指示信息，所述指示消息用于指示第一时长之后重新发送所述请求消息。
结合第十四方面，在第十四方面的一种实现方式中，装置还包括：所述装置还包括：第二发送单元，用于向所述Hosting CSE重新发送所述请求消息；第二接收单元，用于接收所述Hosting CSE发送的回复消息，所述回复消息包括所述对目标资源的处理结果。
结合第十四方面及上述实现方式，在第十四方面的另一种实现方式中， 所述第一时长大于处理所述目标资源所需的时长。
结合第十四方面及上述实现方式，在第十四方面的另一种实现方式中，所述装置还包括：第三接收单元，用于在第一时长之后，接收所述Hosting CSE重新发送的指示消息。
本发明实施例的oneM2M系统使用非阻塞同步通信模式进行通信时，在接收上一个实体发送的增加Request Resource Creator参数的请求消息之后，通过不创建＜request＞资源的实体向下一个实体转发该请求消息，以使得本地实体＜request＞资源创建失败时仍然可以继续进行通信。
附图说明
为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例中所需要使用的附图作简单地介绍，显而易见地，下面所描述的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本发明实施例的系统场景的示意图。
图2是本发明一个实施例的oneM2M系统中通信的方法的示意性流程图。
图3是本发明另一实施例的oneM2M系统中通信的方法的示意性流程图。
图4是本发明再一实施例的oneM2M系统中通信的方法的示意性流程图。
图5是本发明再一实施例的oneM2M系统中通信的方法的示意性流程图。
图6是本发明再一实施例的oneM2M系统中通信的方法的示意性流程图。
图7是本发明再一实施例的oneM2M系统中通信的方法的示意性流程图。
图8是本发明再一实施例的oneM2M系统中通信的方法的示意性流程图。
图9是本发明一个实施例的oneM2M系统中通信的方法的示意性交互流程图。
图10是本发明另一实施例的oneM2M系统中通信的方法的示意性交互流程图。
图11是本发明再一实施例的oneM2M系统中通信的方法的示意性交互流程图。
图12是本发明再一实施例的oneM2M系统中通信的方法的示意性交互流程图。
图13是本发明再一实施例的oneM2M系统中通信的方法的示意性交互流程图。
图14是本发明再一实施例的oneM2M系统中通信的方法的示意性交互流程图。
图15是本发明再一实施例的oneM2M系统中通信的方法的示意性交互流程图。
图16是本发明一个实施例的oneM2M系统中通信的装置的示意性框图。
图17是本发明另一实施例的oneM2M系统中通信的装置的示意性框图。
图18是本发明再一实施例的oneM2M系统中通信的装置的示意性框图。
图19是本发明再一实施例的oneM2M系统中通信的装置的示意性框图。
图20是本发明再一实施例的oneM2M系统中通信的装置的示意性框图。
图21是本发明再一实施例的oneM2M系统中通信的装置的示意性框图。
图22是本发明再一实施例的oneM2M系统中通信的装置的示意性框图。
图23是本发明一个实施例的oneM2M系统中通信的装置的示意性框图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明的一部分实施例，而不是全部实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都应属于本发明保护的范围。
图1是本发明实施例的系统场景的示意性图。
本发明实施例可应用的oneM2M系统包括Originator、N个中转CSE(如图1中的CSE1、……CSEN)和Hosting CSE。本发明实施例中的Originator可以为AE或CSE。本发明实施例中的Hosting CSE为存储目标资源的CSE。
在非阻塞同步通信模式下，当目标资源存储在Hosting CSE中时， Originator可以向Hosting CSE发送请求消息，请求访问目标资源。Originator发送的请求消息经过中转CSE的转发可以到达Hosting CSE。
如图1所示，步骤101Originator向Hosting CSE发送请求消息，请求Hosting CSE中存储的目标资源。CSE1首先收到该请求消息。步骤102中转CSE1可能不支持＜request＞资源类型。当中转CSE1不创建＜request＞资源时，回复创建＜request＞资源失败的消息。同理，如果前面N个中转CSE均创建＜request＞资源，第N+1个中转或Hosting CSE无法创建＜request＞资源时，回复创建＜request＞资源失败的消息。这样，由Originator向Hosting CSE请求对目标资源进行操作的过程终止。
例如图1所示，在步骤103、104或106中，一个实体向下一个实体发送请求消息。例如，步骤103，中转CSE1向中转CSE2发送请求消息。步骤106，中转CSE N+1向托管CSE发送请求消息。在步骤102、105或107中，实体CSE(可以是中转CSE，也可以是托管CSE)确定是否创建＜request＞资源。当实体无法创建＜request＞资源时，回复创建＜request＞资源失败的消息。为了继续进行通信过程，就需要绕过或透传不创建＜request＞资源的实体以实现继续通信的过程。
本发明实施例应用场景是通过在实体接收请求消息后，通过确定是否创建＜request＞资源时，并根据确定结果继续执行由Originator向Hosting CSE请求对目标资源进行操作的过程。
实施例一：
图2是本发明一个实施例的oneM2M系统中通信的方法的示意性流程图。图2的方法可以由中转CSE执行。
201，接收上一个实体发送的非阻塞同步通信模式下的第一请求消息。第一请求消息包括请求资源创建者Request Resource Creator参数。其中，Request Resource Creator参数为缺省值或上一个针对第一请求消息创建请求＜request＞资源的实体的标识符。第一请求消息用于发起实体Originator向目标资源所在的托管通用服务实体Hosting CSE请求对目标资源进行操作。
202，当针对第一请求消息不创建＜request＞资源时，向下一个实体发送第一请求消息。
本发明实施例的oneM2M系统使用非阻塞同步通信模式进行通信时，在接收上一个实体发送的增加Request Resource Creator参数的请求消息之后， 通过不创建＜request＞资源的实体向下一个实体转发该请求消息，以使得本地实体＜request＞资源创建失败时仍然可以继续进行通信。
缺省值指的是一个属性、参数在被修改前的初始值。这里，缺省值为默认的初始值。
第一请求消息用于由Originator向Hosting CSE请求对目标资源进行操作。第一请求消息携带响应类型(英文：response type，简称：RT)参数，将RT参数设置为“nonBlockingRequestSynch”时，表示请求采用非阻塞同步模式进行通信。请求消息可以包括Originator的标识符、目标资源所在的Hosting CSE的标识符。
本发明实施例中的Originator可以为AE，也可以为CSE，本发明对此不做限定。
第一请求消息包括Request Resource Creator参数，Request Resource Creator参数为缺省值或上一个针对第一请求消息创建请求＜request＞资源的实体的标识符。
例如，Originator向中转CSE1发送的第一请求消息中的Request Resource Creator参数为缺省值。当CSE1针对第一请求消息不创建＜request＞资源时，CSE1向CSE2转发Originator向中转CSE1发送的第一请求消息。此时第一请求消息中的Request Resource Creator参数仍然为缺省值。
再如，Originator向中转CSE1发送的第一请求消息中的Request Resource Creator参数为缺省值。当中转CSE1和中转CSE2均针对上述第一请求消息创建＜request＞资源时，中转CSE2向下一个实体发送的第一请求消息中包括的Request Resource Creator参数为上一个创建＜request＞资源的实体的标识符，即CSE1-ID。
本发明实施例对实体的标识符不做限定。本发明实施例仅以实体的ID为例进行示例性说明，但本发明并不限定于此。本发明实施例对ID的格式也不做限定。例如，CSE-ID格式可以为：/CSE090112//www.m2mprovider.com/C3219。AE-ID格式可以为：/m2m.prov.com/CSE3219/C9886。但本发明实施例并不限定于此。
可选地，作为一个实施例，中转CSE针对请求消息不创建＜request＞资源时，中转CSE接收下一个实体发送的第一回复消息，并向上一个实体发送第一回复消息。其中，第一回复消息包括下一个针对第一请求消息创建＜ request＞资源的实体创建的＜request＞资源的地址信息。第一回复消息还可以包括下一个针对请求消息创建＜request＞资源的实体的标识符、上一个针对请求消息创建＜request＞资源的实体的标识符或Originator的标识符。第一回复消息用于向上一个实体回复下一个针对请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息。
例如，中转CSE2不创建＜request＞资源。中转CSE2接收中转CSE3发送的回复消息，并向中转CSE1转发该回复消息。在中转CSE1已创建＜request＞资源时，中转CSE3发送的回复消息包括Hosting CSE的标识符、中转CSE1的标识符和下一个针对请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息。在中转CSE1不创建＜request＞资源时，中转CSE3发送的回复消息包括Hosting CSE的标识符、Originator的标识符和下一个针对请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息。这里下一个针对请求消息创建＜request＞资源的实体可以为中转CSE，也可以为Hosting CSE。
本发明实施例对＜request＞资源的地址信息不做限定。例如，＜request＞资源的地址信息可以为通用资源标识符(英文：Uniform Resource Identifier，简称：URI)，也可以为资源的标识符(英文：Resource Identification，简称：Resource ID)。本发明实施例仅以＜request＞资源的地址信息为URI或Resource ID为例进行示例性说明。本发明实施例对标识符的格式不做限定。例如，Resource ID可以为如下格式：streetX/houseY/roomZ/temperature，该Resource ID用于表征存储街道X的大楼Y的房间Z的温度的地址。
可选地，作为一个实施例，当中转CSE针对请求消息不创建＜request＞资源时，中转CSE接收上一个实体发送的第一获取请求消息，并向下一个实体转发第一获取请求消息。第一获取请求消息用于向下一个创建＜request＞资源的实体请求获取对目标资源的处理结果。第一获取请求消息包括所述下一个针对第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息。
第一获取请求消息还可以包括Originator的标识符或上一个针对第一请求消息创建＜request＞资源的实体的标识符。
中转CSE在向下一个实体转发第一获取请求消息之后，接收下一个实体发送的第二回复消息，并向上一个实体转发该第二回复消息。其中，第一 获取请求消息用于向下一个针对请求消息创建＜request＞资源的实体请求获取对目标资源的处理结果。第二回复消息包括对目标资源的处理结果。接收下一个实体发送的第二回复消息包括接收下一个实体发送的对目标资源的处理结果。这样，在中转CSE不创建＜request＞资源时，可以继续进行通信，能够避免大量的信令开销和资源浪费。
第二回复消息还可以包括下一个针对请求消息创建＜request＞资源的实体的标识符、上一个针对请求消息创建＜request＞资源的实体的标识符或Originator的标识符。
例如，当中转CSE2不创建＜request＞资源时，中转CSE2接收中转CSE1发送的第一获取请求消息，并在接收第一获取请求消息之后，向中转CSE3转发该第一获取请求消息。当中转CSE1创建＜request＞资源时，中转CSE1发送的第一获取请求消息包括中转CSE1的标识符和下一个创建＜request＞资源的实体创建的＜request＞资源的地址信息。当中转CSE1不创建＜request＞资源时，中转CSE1发送的第一获取请求消息包括Originator的标识符和下一个创建＜request＞资源的实体创建的＜request＞资源的地址信息。
中转CSE2在接收中转CSE3发送的第二回复消息之后，向中转CSE1转发该第二回复消息。当中转CSE1创建＜request＞资源时，第二回复消息可以包括下一个针对所述目标资源创建＜request＞资源的实体的标识符、中转CSE1的标识符和对目标资源的处理结果。当中转CSE1不创建＜request＞资源时，第二回复消息可以包括下一个针对所述目标资源创建＜request＞资源的实体的标识符、Originator的标识符和对目标资源的处理结果。
应理解，＜request＞资源的地址信息可以是URI或Resource ID，本发明实施例对此不做限定。
可选地，作为一个实施例，中转CSE向下一个实体发送第一请求消息之前，还可以确定是否针对第一请求消息创建＜request＞资源。
本发明实施例通过在向下一个实体发送第一请求消息之前，还可以通过确定是否针对第一请求消息创建＜request＞资源。这样，无论在实体创建＜request＞资源还是不创建＜request＞资源时，均可以继续进行通信，以进一步增强通信的灵活性。
可选地，作为本发明的实施例，中转CSE可以根据容量和/或支持的＜ request＞资源类型确定是否针对第一请求消息创建＜request＞资源。
中转CSE可以根据自身情况确定是否针对请求消息创建＜request＞资源。例如，当中转CSE不支持＜request＞资源类型时，确定该中转CSE不创建＜request＞资源。
当中转CSE容量有限时，确定该CSE不创建＜request＞资源。中转CSE容量有限可以是剩余容量不足，不足以保存创建的＜request＞资源。也可以是对目标资源的处理结果对中转CSE没有价值，且中转CSE剩余容量有限，所以，中转CSE根据自身策略，确定不创建＜request＞资源。中转CSE确定不创建＜request＞资源还可能是中转CSE虽然有足够的容量保存＜request＞资源，但对目标资源的处理结果对中转CSE没有价值，中转CSE确定不创建＜request＞资源。本发明实施例中转CSE可以根据容量和/或支持的＜request＞资源类型确定是否针对请求消息创建＜request＞资源为例进行示例性说明，但本发明并不限定于此。
可选地，作为一个实施例，当中转CSE确定针对第一请求消息创建＜request＞资源时，中转CSE可以创建＜request＞资源。接着，向上一个实体发送第三回复消息。然后，生成第二请求消息，并向下一个实体发送第二请求消息。这里，第三回复消息包括中转CSE创建的＜request＞资源的地址信息。第二请求消息包括Request Resource Creator参数。其中，Request Resource Creator参数设置为中转CSE的标识符。
第二请求消息还可以包括Originator的标识符和Hosting CSE的标识符。第三回复消息还可以包括中转CSE的标识符、上一个针对所述目标资源创建＜request＞资源的实体的标识符或Originator的标识符。
例如，当中转CSE1确定创建＜request＞资源时，中转CSE1创建＜request1＞资源。接着，向上一个实体Originator发送第三回复消息。这里，第三回复消息可以包括中转CSE1的标识符、Originator的标识符和中转CSE1创建的＜request1＞资源的地址信息。中转CSE1创建＜request1＞资源后，中转CSE1生成第二请求消息。第二请求消息中Request Resource Creator参数可以设置为中转CSE1的标识符，例如，CSE1-ID。中转CSE1生成第二请求消息后向中转CSE2转发该第二请求消息。
再如，当中转CSE3确定创建＜request＞资源时，中转CSE3创建＜request3＞资源。接着，向上一个实体中转CSE2发送第三回复消息。当中转 CSE2不创建＜request＞资源，而中转CSE1创建＜request＞资源时，第三回复消息可以包括中转CSE1的标识符、中转CSE3的标识符和中转CSE3创建的＜request3＞资源的地址信息。中转CSE3创建＜request3＞资源后，中转CSE3生成第二请求消息。这里，第二请求消息中Request Resource Creator参数可以设置为中转CSE3的标识符，例如，CSE3-ID。中转CSE3生成第二请求消息后向下一个实体发送第二请求消息。
可选地，作为一个实施例，当中转CSE针对请求消息创建＜request＞资源时，中转CSE接收下一个实体发送的第四回复消息。接着，中转CSE根据第四回复消息更新中转CSE创建的＜request＞资源。然后，中转CSE接收上一个实体发送的第二获取请求消息，并向上一个实体发送第五回复消息。第四回复消息包括对目标资源的处理结果。第二获取请求消息用于上一个实体向中转CSE请求获取对目标资源的处理结果。第二获取请求消息包括创建的＜request＞资源的地址信息。第五回复消息包括对目标资源的处理结果。
第四回复消息还可以包括下一个针对请求消息创建＜request＞资源的实体的标识符、中转CSE的标识符。第二获取请求消息还可以包括上一个实体的标识符和创建的＜request＞资源的地址信息。第五回复消息还可以包括中转CSE的标识符、上一个针对请求消息创建＜request＞资源的实体的标识符或Originator的标识符。
例如，当中转CSE1创建＜request1＞资源时，中转CSE1接收下一个实体中转CSE2发送的第四回复消息。接着，根据第四回复消息更新中转CSE1创建的＜request1＞资源。然后，中转CSE1接收上一个实体Originator发送的第二获取请求消息，并向上一个实体发送第五回复消息。这里，当中转CSE2不创建＜request＞资源，中转CSE3创建＜request2＞资源时，第四回复消息可以包括中转CSE3的标识符、中转CSE1的标识符和对目标资源的处理结果。第二获取请求消息可以包括Originator的标识符和＜request1＞资源的地址信息。第五回复消息可以包括中转CSE1的标识符、Originator的标识符。
再如，当中转CSE3创建＜request3＞资源时，中转CSE3接收下一个实体中转CSE2发送的第四回复消息。接着，根据第四回复消息更新中转CSE3创建的＜request3＞资源。然后，中转CSE3接收上一个实体中转CSE2发送 的第二获取请求消息，并向上一个实体中转CSE2发送第五回复消息。这里，当中转CSE2不创建＜request＞资源，中转CSE1创建＜request1＞资源时，第四回复消息可以包括中转CSE3的标识符、下一个创建＜request＞资源的实体的标识符和对目标资源的处理结果。第二获取请求消息可以包括中转CSE1的标识符和＜request3＞资源的地址信息。第五回复消息包括中转CSE1的标识符、中转CSE3的标识符和对目标资源的处理结果。
本发明实施例适用于Hosting CSE需要创建＜request＞资源的情况。中转CSE可以按照自身情况决定是否创建＜request＞资源。CSE可以根据请求消息中携带的参数判断本地实体是中转CSE还是Hosting CSE。
实施例二：
图3是本发明另一实施例的oneM2M系统中通信的方法的示意性流程图。图3的方法可以由中转CSE执行。
301，接收上一个实体发送的非阻塞同步通信模式下的第一请求消息。第一请求消息用于发起实体Originator向目标资源所在的托管通用服务实体Hosting CSE请求对目标资源进行操作。
302，当针对第一请求消息不创建请求＜request＞资源时，生成请求资源创建者Request Resource Creator参数。Request Resource Creator参数设置为缺省值或上一个针对第一请求消息创建请求＜request＞资源的实体的标识符。
303，生成第二请求消息，所述第二请求消息包括所述Request Resource Creator参数。
304，向下一个实体发送所述第二请求消息。
本发明实施例的oneM2M系统使用非阻塞同步通信模式进行通信时，在接收上一个实体发送的请求消息之后，通过不创建＜request＞资源的实体生成Request Resource Creator参数，然后向下一个实体发送包括Request Resource Creator参数的请求消息，以使得本地实体＜request＞资源创建失败时仍然可以继续进行通信。
第一请求消息用于由Originator向Hosting CSE请求对目标资源进行操作。第一请求消息携带RT参数，将RT参数设置为“nonBlockingRequestSynch”时，表示请求采用非阻塞同步模式进行通信。第一请求消息可以包括Originator的标识符、目标资源所在的Hosting CSE 的标识符。
本发明实施例中的Originator可以为AE，也可以为CSE，本发明对此不做限定。
步骤302中，当中转CSE针对请求消息不创建请求＜request＞资源时，中转CSE可以生成Request Resource Creator参数。Request Resource Creator参数可以设置为缺省值或上一个针对请求消息创建请求＜request＞资源的实体的标识符。
例如，当中转CSE为第一个中转或中转CSE之前的实体均不创建＜request＞资源时，Request Resource Creator参数可以设置为缺省值。当中转CSE之前存在可以创建＜request＞资源的实体时，Request Resource Creator参数可以设置为上一个针对请求消息创建请求＜request＞资源的实体的标识符。
步骤303中，根据Request Resource Creator参数生成第二请求消息。第二请求消息包括所述Request Resource Creator参数。
步骤304中，向下一个实体发送第二请求消息。这里向下一个实体发送第二请求消息包括发送Request Resource Creator参数。
具体地，例如，Originator向中转CSE1发送的请求消息中不包括Request Resource Creator参数。中转CSE1生成Request Resource Creator参数，并将Request Resource Creator参数保存在接收到的请求消息中。然后，中转CSE1向中转CSE2发送包括Request Resource Creator参数的请求消息。
再如，中转CSE N向中转CSE N+1发送的请求消息中不包括Request Resource Creator参数。中转CSE N+1生成Request Resource Creator参数，并将Request Resource Creator参数保存在接收到的请求消息中。然后，中转CSE N+1向下一个实体发送包括Request Resource Creator参数的请求消息。
可选地，作为一个实施例，中转CSE针对请求消息不创建＜request＞资源时，中转CSE接收下一个实体发送的第一回复消息，并向上一个实体发送第一回复消息。其中，第一回复消息包括下一个针对第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息。第一回复消息还可以包括下一个针对请求消息创建＜request＞资源的实体的标识符、上一个针对请求消息创建＜request＞资源的实体的标识符或Originator的标识符。第一回复消息用于向上一个实体回复下一个针对请求消息创建＜request＞资 源的实体创建的＜request＞资源的地址信息。
例如，中转CSE2不创建＜request＞资源。中转CSE2接收中转CSE3发送的回复消息，并向中转CSE1转发该回复消息。在中转CSE1已创建＜request＞资源时，中转CSE3发送的回复消息包括Hosting CSE的标识符、中转CSE1的标识符和下一个针对请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息。在中转CSE1不创建＜request＞资源时，中转CSE3发送的回复消息包括Hosting CSE的标识符、Originator的标识符和下一个针对请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息。这里下一个针对请求消息创建＜request＞资源的实体可以为中转CSE，也可以为Hosting CSE。
可选地，作为一个实施例，当中转CSE针对请求消息不创建＜request＞资源时，中转CSE接收上一个实体发送的第一获取请求消息，并向下一个实体转发第一获取请求消息。第一获取请求消息用于向下一个创建＜request＞资源的实体请求获取对目标资源的处理结果。第一获取请求消息包括所述下一个针对第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息。
第一获取请求消息还可以包括Originator的标识符或上一个针对第一请求消息创建＜request＞资源的实体的标识符。
中转CSE在向下一个实体转发第一获取请求消息之后，接收下一个实体发送的第二回复消息，并向上一个实体转发该第二回复消息。其中，第一获取请求消息用于向下一个针对请求消息创建＜request＞资源的实体请求获取对目标资源的处理结果。第二回复消息包括对目标资源的处理结果。接收下一个实体发送的第二回复消息包括接收下一个实体发送的对目标资源的处理结果。这样，在中转CSE不创建＜request＞资源时，可以继续进行通信，能够避免大量的信令开销和资源浪费。
第二回复消息还可以包括下一个针对请求消息创建＜request＞资源的实体的标识符、上一个针对请求消息创建＜request＞资源的实体的标识符或Originator的标识符。
例如，当中转CSE2不创建＜request＞资源时，中转CSE2接收中转CSE1发送的第一获取请求消息，并在接收第一获取请求消息之后，向中转CSE3转发该第一获取请求消息。当中转CSE1创建＜request＞资源时，中转CSE1 发送的第一获取请求消息包括中转CSE1的标识符和下一个创建＜request＞资源的实体创建的＜request＞资源的地址信息。当中转CSE1不创建＜request＞资源时，中转CSE1发送的第一获取请求消息包括Originator的标识符和下一个创建＜request＞资源的实体创建的＜request＞资源的地址信息。
中转CSE2在接收中转CSE3发送的第二回复消息之后，向中转CSE1转发该第二回复消息。当中转中转CSE1创建＜request＞资源时，第二回复消息可以包括下一个针对所述目标资源创建＜request＞资源的实体的标识符、中转CSE1的标识符和对目标资源的处理结果。当中转CSE1不创建＜request＞资源时，第二回复消息可以包括下一个针对所述目标资源创建＜request＞资源的实体的标识符、Originator的标识符和对目标资源的处理结果。
应理解，＜request＞资源的地址信息可以是URI或Resource ID，本发明实施例对此不做限定。
可选地，作为一个实施例，中转CSE向下一个实体发送第一请求消息之前，还可以确定是否针对第一请求消息创建＜request＞资源。
本发明实施例通过在向下一个实体发送第一请求消息之前，还可以通过确定是否针对第一请求消息创建＜request＞资源。这样，无论在实体创建＜request＞资源还是不创建＜request＞资源时，均可以继续进行通信，以进一步增强通信的灵活性。
中转CSE可以根据自身情况确定是否针对请求消息创建＜request＞资源。可选地，作为本发明的实施例，中转CSE可以根据容量和/或支持的＜request＞资源类型确定是否针对第一请求消息创建＜request＞资源。
可选地，作为一个实施例，当中转CSE确定针对第一请求消息创建＜request＞资源时，中转CSE可以创建＜request＞资源。接着，向上一个实体发送第三回复消息。然后，生成第三请求消息，并向下一个实体发送第三请求消息。这里，第三回复消息包括中转CSE创建的＜request＞资源的地址信息。第三请求消息包括Request Resource Creator参数。其中，Request Resource Creator参数设置为中转CSE的标识符。
第三请求消息还可以包括Originator的标识符和Hosting CSE的标识符。第三回复消息还可以包括中转CSE的标识符、上一个针对所述目标资源创 建＜request＞资源的实体的标识符或Originator的标识符。
例如，当中转CSE1确定创建＜request＞资源时，中转CSE1创建＜request1＞资源。接着，向上一个实体Originator发送第三回复消息。这里，第三回复消息可以包括中转CSE1的标识符、Originator的标识符和中转CSE1创建的＜request1＞资源的地址信息。中转CSE1创建＜request1＞资源后，中转CSE1生成第三请求消息。第三请求消息中Request Resource Creator参数可以设置为中转CSE1的标识符，例如，CSE1-ID。中转CSE1生成第三请求消息后向中转CSE2转发该第三请求消息。
再如，当中转CSE3确定创建＜request＞资源时，中转CSE3创建＜request3＞资源。接着，向上一个实体中转CSE2发送第三回复消息。当中转CSE2不创建＜request＞资源，而中转CSE1创建＜request＞资源时，第三回复消息可以包括中转CSE1的标识符、中转CSE3的标识符和中转CSE3创建的＜request3＞资源的地址信息。中转CSE3创建＜request3＞资源后，中转CSE3生成第三请求消息。这里，第三请求消息中Request Resource Creator参数可以设置为中转CSE3的标识符，例如，CSE3-ID。中转CSE3生成第三请求消息后向下一个实体发送第三请求消息。
可选地，作为一个实施例，当中转CSE针对请求消息创建＜request＞资源时，中转CSE接收下一个实体发送的第四回复消息。接着，中转CSE根据第四回复消息更新中转CSE创建的＜request＞资源。然后，中转CSE接收上一个实体发送的第二获取请求消息，并向上一个实体发送第五回复消息。第四回复消息包括对目标资源的处理结果。第二获取请求消息用于上一个实体向中转CSE请求获取对目标资源的处理结果。第二获取请求消息包括创建的＜request＞资源的地址信息。第五回复消息包括对目标资源的处理结果。
第四回复消息还可以包括下一个针对请求消息创建＜request＞资源的实体的标识符、中转CSE的标识符。第二获取请求消息还可以包括上一个实体的标识符和创建的＜request＞资源的地址信息。第五回复消息还可以包括中转CSE的标识符、上一个针对请求消息创建＜request＞资源的实体的标识符或Originator的标识符。
例如，当中转CSE1创建＜request1＞资源时，中转CSE1接收下一个实体中转CSE2发送的第四回复消息。接着，根据第四回复消息更新中转CSE1 创建的＜request1＞资源。然后，中转CSE1接收上一个实体Originator发送的第二获取请求消息，并向上一个实体发送第五回复消息。这里，当中转CSE2不创建＜request＞资源，中转CSE3创建＜request2＞资源时，第四回复消息可以包括中转CSE3的标识符、中转CSE1的标识符和对目标资源的处理结果。第二获取请求消息可以包括Originator的标识符和＜request1＞资源的地址信息。第五回复消息可以包括中转CSE1的标识符、Originator的标识符。
再如，当中转CSE3创建＜request1＞资源时，中转CSE3接收下一个实体中转CSE2发送的第四回复消息。接着，根据第四回复消息更新中转CSE3创建的＜request3＞资源。然后，中转CSE3接收上一个实体中转CSE2发送的第二获取请求消息，并向上一个实体中转CSE2发送第五回复消息。这里，当中转CSE2不创建＜request＞资源，中转CSE1创建＜request1＞资源时，第四回复消息可以包括中转CSE3的标识符、下一个创建＜request＞资源的实体的标识符和对目标资源的处理结果。第二获取请求消息可以包括中转CSE1的标识符和＜request3＞资源的地址信息。第五回复消息包括中转CSE1的标识符、中转CSE3的标识符和对目标资源的处理结果。
本发明实施例适用于Hosting CSE需要创建＜request＞资源的情况。中转CSE可以按照自身情况决定是否创建＜request＞资源。CSE可以根据请求消息中携带的参数判断本地实体是中转CSE还是Hosting CSE。
实施例三：
图4是本发明另一实施例的oneM2M系统中通信的方法的示意性流程图。图4的方法可以由中转CSE执行。
401，接收上一个实体发送的非阻塞同步通信模式下的第一请求消息。第一请求消息携带的响应类型RT参数包括请求资源指示字段。第一请求消息用于发起实体Originator向目标资源所在的托管通用服务实体Hosting CSE请求对目标资源进行操作。其中，请求资源指示字段为缺省值或上一个针对第一请求消息创建请求＜request＞资源的实体的标识符。
402，当针对第一请求消息不创建请求＜request＞资源时，向下一个实体发送第一请求消息。
本发明实施例的oneM2M系统使用非阻塞同步通信模式进行通信时，在接收上一个实体发送的请求对目标资源进行操作的请求消息之后，利用RT 参数中增加的请求资源指示字段来指示上一个创建＜request＞资源的实体的标识符，以使得不创建＜request＞资源的实体向下一个实体发送请求消息，这样，在＜request＞资源创建失败时仍然可以继续进行通信。
本发明实施例中的Originator可以为AE，也可以为CSE，本发明对此不做限定。
第一请求消息用于由Originator向Hosting CSE请求对目标资源进行操作。第一请求消息携带RT参数，将RT参数设置为“nonBlockingRequestSynch(null)”时，表示请求采用非阻塞同步模式进行通信，且请求资源指示字段为缺省值。第一请求消息可以包括Originator的标识符、目标资源所在的Hosting CSE的标识符。
步骤401中，请求资源指示字段还可以为上一个针对第一请求消息创建请求＜request＞资源的实体的标识符。
例如，当中转CSE接收第一请求消息之后，如果中转CSE为第一个中转CSE或者中转CSE之前的实体均不创建＜request＞资源，那么此时请求资源指示字段可以为缺省值。如果中转CSE之前存在创建＜request＞资源的实体，那么此时请求资源指示字段可以为上一个创建＜request＞资源的实体的标识符。
一般地，用于表示请求采用非阻塞同步模式进行通信，且请求资源指示字段为缺省值时，RT参数可以设置为“nonBlockingRequestSynch(null)”。仅用于表示请求采用非阻塞同步模式进行通信时，RT参数可以设置为“nonBlockingRequestSynch”。用于表示请求采用非阻塞同步模式进行通信，且请求资源指示字段为缺省值时的RT参数与仅用于表示请求采用非阻塞同步模式进行通信的RT参数的值不同。
应理解，本发明对请求资源指示字段的缺省值的具体数值不做限定。
应理解，本发明实施例中利用请求资源指示字段来表示创建＜request＞资源的实体的标识符，但本发明并不限定于此。还可以用非阻塞通信模式下其他参数来表示创建＜request＞资源的实体的标识符。
可选地，作为一个实施例，中转CSE针对请求消息不创建＜request＞资源时，中转CSE接收下一个实体发送的第一回复消息，并向上一个实体发送第一回复消息。其中，第一回复消息包括下一个针对第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息。第一回复消息还可 以包括下一个针对请求消息创建＜request＞资源的实体的标识符、上一个针对请求消息创建＜request＞资源的实体的标识符或Originator的标识符。第一回复消息用于向上一个实体回复下一个针对请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息。
例如，中转CSE2不创建＜request＞资源。中转CSE2接收中转CSE3发送的回复消息，并向中转CSE1转发该回复消息。在中转CSE1已创建＜request＞资源时，中转CSE3发送的回复消息包括Hosting CSE的标识符、中转CSE1的标识符和下一个针对请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息。在中转CSE1不创建＜request＞资源时，中转CSE3发送的回复消息包括Hosting CSE的标识符、Originator的标识符和下一个针对请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息。这里下一个针对请求消息创建＜request＞资源的实体可以为中转CSE，也可以为Hosting CSE。
可选地，作为一个实施例，当中转CSE针对请求消息不创建＜request＞资源时，中转CSE接收上一个实体发送的第一获取请求消息，并向下一个实体转发第一获取请求消息。第一获取请求消息用于向下一个创建＜request＞资源的实体请求获取对目标资源的处理结果。第一获取请求消息包括所述下一个针对第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息。
第一获取请求消息还可以包括Originator的标识符或上一个针对第一请求消息创建＜request＞资源的实体的标识符。
中转CSE在向下一个实体转发第一获取请求消息之后，接收下一个实体发送的第二回复消息，并向上一个实体转发该第二回复消息。其中，第一获取请求消息用于向下一个针对请求消息创建＜request＞资源的实体请求获取对目标资源的处理结果。第二回复消息包括对目标资源的处理结果。接收下一个实体发送的第二回复消息包括接收下一个实体发送的对目标资源的处理结果。这样，在中转CSE不创建＜request＞资源时，可以继续进行通信，能够避免大量的信令开销和资源浪费。
第二回复消息还可以包括下一个针对请求消息创建＜request＞资源的实体的标识符、上一个针对请求消息创建＜request＞资源的实体的标识符或Originator的标识符。
例如，当中转CSE2不创建＜request＞资源时，中转CSE2接收中转CSE1发送的第一获取请求消息，并在接收第一获取请求消息之后，向中转CSE3转发该第一获取请求消息。当中转CSE1创建＜request＞资源时，中转CSE1发送的第一获取请求消息包括中转CSE1的标识符和下一个创建＜request＞资源的实体创建的＜request＞资源的地址信息。当中转CSE1不创建＜request＞资源时，中转CSE1发送的第一获取请求消息包括Originator的标识符和下一个创建＜request＞资源的实体创建的＜request＞资源的地址信息。
中转CSE2在接收中转CSE3发送的第二回复消息之后，向中转CSE1转发该第二回复消息。当中转CSE1创建＜request＞资源时，第二回复消息可以包括下一个针对所述目标资源创建＜request＞资源的实体的标识符、中转CSE1的标识符和对目标资源的处理结果。当中转CSE1不创建＜request＞资源时，第二回复消息可以包括下一个针对所述目标资源创建＜request＞资源的实体的标识符、Originator的标识符和对目标资源的处理结果。
应理解，＜request＞资源的地址信息可以是URI或Resource ID，本发明实施例对此不做限定。
可选地，作为一个实施例，中转CSE向下一个实体发送第一请求消息之前，还可以确定是否针对第一请求消息创建＜request＞资源。
本发明实施例通过在向下一个实体发送第一请求消息之前，还可以通过确定是否针对第一请求消息创建＜request＞资源。这样，无论在实体创建＜request＞资源还是不创建＜request＞资源时，均可以继续进行通信，以进一步增强通信的灵活性。
中转CSE可以根据自身情况确定是否针对请求消息创建＜request＞资源。可选地，作为本发明的实施例，中转CSE可以根据容量和/或支持的＜request＞资源类型确定是否针对第一请求消息创建＜request＞资源。
可选地，作为一个实施例，当中转CSE确定针对第一请求消息创建＜request＞资源时，中转CSE可以创建＜request＞资源。接着，向上一个实体发送第三回复消息。然后，生成第二请求消息，并向下一个实体发送第二请求消息。这里，第三回复消息包括中转CSE创建的＜request＞资源的地址信息。第二请求消息包括请求资源指示字段。其中，请求资源指示字段设置为中转CSE的标识符。
第二请求消息还可以包括Originator的标识符和Hosting CSE的标识符。第三回复消息还可以包括中转CSE的标识符、上一个针对所述目标资源创建＜request＞资源的实体的标识符或Originator的标识符。
例如，当中转CSE1确定创建＜request＞资源时，中转CSE1创建＜request1＞资源。接着，向上一个实体Originator发送第三回复消息。这里，第三回复消息可以包括中转CSE1的标识符、Originator的标识符和中转CSE1创建的＜request1＞资源的地址信息。中转CSE1创建＜request1＞资源后，中转CSE1生成第二请求消息。第二请求消息中Request Resource Creator参数可以设置为中转CSE1的标识符，例如，CSE1-ID。中转CSE1生成第二请求消息后向中转CSE2转发该第二请求消息。
再如，当中转CSE3确定创建＜request＞资源时，中转CSE3创建＜request3＞资源。接着，向上一个实体中转CSE2发送第三回复消息。当中转CSE2不创建＜request＞资源，而中转CSE1创建＜request＞资源时，第三回复消息可以包括中转CSE1的标识符、中转CSE3的标识符和中转CSE3创建的＜request3＞资源的地址信息。中转CSE3创建＜request3＞资源后，中转CSE3生成第二请求消息。这里，第二请求消息中Request Resource Creator参数可以设置为中转CSE3的标识符，例如，CSE3-ID。中转CSE3生成第二请求消息后向下一个实体发送第二请求消息。
可选地，作为一个实施例，当中转CSE针对请求消息创建＜request＞资源时，中转CSE接收下一个实体发送的第四回复消息。接着，中转CSE根据第四回复消息更新中转CSE创建的＜request＞资源。然后，中转CSE接收上一个实体发送的第二获取请求消息，并向上一个实体发送第五回复消息。第四回复消息包括对目标资源的处理结果。第二获取请求消息用于上一个实体向中转CSE请求获取对目标资源的处理结果。第二获取请求消息包括创建的＜request＞资源的地址信息。第五回复消息包括对目标资源的处理结果。
第四回复消息还可以包括下一个针对请求消息创建＜request＞资源的实体的标识符、中转CSE的标识符。第二获取请求消息还可以包括上一个实体的标识符和创建的＜request＞资源的地址信息。第五回复消息还可以包括中转CSE的标识符、上一个针对请求消息创建＜request＞资源的实体的标识符或Originator的标识符。
例如，当中转CSE1创建＜request1＞资源时，中转CSE1接收下一个实体中转CSE2发送的第四回复消息。接着，根据第四回复消息更新中转CSE1创建的＜request1＞资源。然后，中转CSE1接收上一个实体Originator发送的第二获取请求消息，并向上一个实体发送第五回复消息。这里，当中转CSE2不创建＜request＞资源，中转CSE3创建＜request2＞资源时，第四回复消息可以包括中转CSE3的标识符、中转CSE1的标识符和对目标资源的处理结果。第二获取请求消息可以包括Originator的标识符和＜request1＞资源的地址信息。第五回复消息可以包括中转CSE1的标识符、Originator的标识符。
再如，当中转CSE3创建＜request3＞资源时，中转CSE3接收下一个实体中转CSE2发送的第四回复消息。接着，根据第四回复消息更新中转CSE3创建的＜request3＞资源。然后，中转CSE3接收上一个实体中转CSE2发送的第二获取请求消息，并向上一个实体中转CSE2发送第五回复消息。这里，当中转CSE2不创建＜request＞资源，中转CSE1创建＜request1＞资源时，第四回复消息可以包括中转CSE3的标识符、下一个创建＜request＞资源的实体的标识符和对目标资源的处理结果。第二获取请求消息可以包括中转CSE1的标识符和＜request3＞资源的地址信息。第五回复消息包括中转CSE1的标识符、中转CSE3的标识符和对目标资源的处理结果。
本发明实施例适用于Hosting CSE需要创建＜request＞资源的情况。中转CSE可以按照自身情况决定是否创建＜request＞资源。CSE可以根据请求消息中携带的参数判断本地实体是中转CSE还是Hosting CSE。
实施例四：
图5是本发明另一实施例的oneM2M系统中通信的方法的示意性流程图。图5的方法可以由中转CSE执行。
501，接收上一个实体发送的非阻塞同步通信模式下的请求消息。请求消息用于Originator向目标资源所在的Hosting CSE请求对目标资源进行操作。
502，当针对第一请求消息不创建＜request＞资源时，向上一个实体发送指示消息。指示消息包括请求资源不创建Request Not Create参数。Request Not Create参数包括下一个实体的标识符。指示消息用于指示上一个实体向下一个实体发送第一请求消息。
本发明实施例的oneM2M系统使用非阻塞同步通信模式进行通信时，中转CSE在接收上一个实体发送的请求对目标资源进行操作的请求消息之后，增加新的Request Not Create参数用于指示不创建＜request＞资源的实体向其他实体发送请求消息，以在＜request＞资源创建失败时仍然可以继续进行通信。
请求消息用于由Originator向Hosting CSE请求对目标资源进行操作。请求消息携带RT参数，将RT参数设置为“nonBlockingRequestSynch”时，表示请求采用非阻塞同步模式进行通信。请求消息可以包括Originator的标识符、目标资源所在的Hosting CSE的标识符。
本发明实施例中的Originator可以为AE，也可以为CSE，本发明对此不做限定。
应理解，本发明实施例对上一个实体和下一个实体的具体形式不做限定。例如，上一个实体可以为中转CSE，也可以为Originator。下一个实体可以为中转CSE，也可以是Hosting CSE。
本发明实施例通过中转CSE在向上一个实体发送指示消息之前，还可以根据自身情况确定是否针对请求消息创建＜request＞资源。可选地，作为本发明的实施例，中转CSE可以根据容量和/或支持的＜request＞资源类型确定是否针对第一请求消息创建＜request＞资源。这样，无论在实体创建＜request＞资源还是不创建＜request＞资源时，均可以继续进行通信，以进一步增强通信的灵活性。
例如，当中转CSE不支持＜request＞资源类型时，确定该中转CSE不创建＜request＞资源。当中转CSE剩余容量不足，不足以保存创建的＜request＞资源时可以确定不创建＜request＞资源。当中转CSE不需要保存对目标资源的处理结果，且中转CSE剩余容量有限时，中转CSE可以根据自身策略，确定不创建＜request＞资源。中转CSE还可以在虽然有足够的容量保存＜request＞资源，但中转CSE不需要保存对目标资源的处理结果时，中转CSE可以不创建＜request＞资源。
实施例五：
图6是本发明再一实施例的oneM2M系统中通信的方法的示意性流程图。图6的方法可以由中转CSE执行。
601，向下一个实体发送非阻塞同步通信模式下的请求消息。请求消息 用于Originator向目标资源所在的Hosting CSE请求对目标资源进行操作。
602，接收下一个实体发送的指示消息。指示消息包括请求资源不创建Request Not Create参数。Request Not Create参数包括第一实体的标识符。指示消息用于指示本地实体向第一实体发送请求消息。
603，向第一实体发送请求消息。
本发明实施例的oneM2M系统使用非阻塞同步通信模式进行通信时，中转CSE在接收上一个实体发送的请求对目标资源进行操作的请求消息之后，上一个实体通过增加新的Request Not Create参数用于指示不创建＜request＞资源的实体向其他实体发送请求消息，以在＜request＞资源创建失败时仍然可以继续进行通信。
请求消息用于由Originator向Hosting CSE请求对目标资源进行操作。请求消息携带RT参数，将RT参数设置为“nonBlockingRequestSynch”时，表示请求采用非阻塞同步模式进行通信。请求消息可以包括Originator的标识符、消息目标资源所在的Hosting CSE的标识符。
中转CSE在向下一个实体发送请求消息之后，当下一个实体不创建＜request＞资源时，下一个实体向中转CSE发送指示消息。指示消息用于指示本地实体(即，中转CSE)向另一实体(例如，第一实体)发送请求消息。指示消息包括请求资源不创建Request Not Create参数。Request Not Create参数包括第一实体的标识符。中转CSE接收到指示消息之后，向第一实体发送请求消息。请求消息用于请求与第一实体建立连接。
这样，在中转CSE不创建＜request＞资源时，可以继续进行通信，能够避免大量的信令开销和资源浪费。
实施例六：
图7是本发明再一实施例的oneM2M系统中通信的方法的示意性流程图。图7的方法可以由Hosting CSE执行。
701，接收中转CSE发送的非阻塞同步通信模式下的请求消息。请求消息用于Originator请求对目标资源进行操作；
702，当针对请求消息不创建＜request＞资源时，根据请求消息向中转CSE发送指示信息。指示信息用于指示中转CSE在第一时长之后重新发送请求消息。
本发明实施例的oneM2M系统使用非阻塞同步通信模式进行通信时， Hosting CSE在接收上一个实体发送的请求对目标资源进行操作的请求消息之后，通过向上一个实体发送指示消息，以指示上一个实体一段时间之后重新发送请求消息，这样使得＜request＞资源创建失败时仍然可以继续进行通信。
本发明实施例中的Originator可以为AE，也可以为CSE，本发明对此不做限定。
指示消息可以包括上一个实体的标识符、中转CSE的标识符和Request Not Create参数。
中转CSE重新发送请求消息的时间位于预计Hosting CSE处理目标资源所需要的时间。这样，在Hosting CSE不创建＜request＞资源时，依然可以继续执行由Originator向Hosting CSE请求对目标资源进行操作的过程。进而避免通信终止而造成的资源浪费和大量的信令开销。
可选地，作为一个实施例，Hosting CSE在收到中转CSE发送的请求消息并不创建＜request＞资源时，根据请求消息对目标资源进行处理，得到对目标资源的处理结果。
Hosting CSE不创建＜request＞资源，无法保存对目标资源的处理结果。但可以向中转发送对目标资源的处理结果。可选地，Hosting CSE在一段时间之后接收中转CSE重新发送的请求消息。然后，根据请求消息向中转CSE发送回复消息。Hosting CSE向中转CSE发送回复消息包括向中转CSE发送对目标资源的处理结果。回复消息可以包括Hosting CSE的标识符、Originator的标识符和对目标资源的处理结果。
例如，当Hosting CSE不创建＜request＞资源且中转CSE2不创建＜request＞资源时，中转CSE2向上一个实体中转CSE1发送指示消息。指示消息可以包括中转CSE2的标识符、中转CSE1的标识符和Request Not Create参数。指示消息用于指示中转CSE2向中转CSE3发送请求消息，以继续执行由Originator向Hosting CSE请求对目标资源进行操作的过程。这里，Request Not Create参数包括下一个实体中转CSE4的标识符。中转CSE1在收到中转CSE2发送的指示消息之后，注销在中转CSE2上的注册信息，并注册到中转CSE3上。中转CSE1与中转CSE3之间建立通信。中转CSE1可以向中转CSE3发送请求消息，以跳过中转CSE2继续执行由Originator向Hosting CSE请求对目标资源进行操作的过程。
本发明的实施例通过跳过不创建＜request＞资源的中转CSE，以避免在前面N个中转均成功创建＜request＞资源，而第N+1个中转CSE不创建＜request＞资源的情况下，第N+1个中转CSE回复创建＜request＞资源失败，造成大量的信令开销和资源浪费。
可选地，作为一个实施例，第一时长大于处理所述目标资源所需的时长。
在第一时长之后，如果Hosting CSE还未完成对目标资源的处理，那么Hosting CSE可以向中转CSE重新发送指示消息。指示消息用于指示中转在一段时间之后再次发送请求消息。
在第二时长之后，如果Hosting CSE未收到中转CSE重新发送的请求消息，Hosting CSE可以丢弃对目标资源的处理结果。当中转CSE可以在第三时长之后，向Hosting CSE再次发送请求消息。当Hosting CSE接收到中转CSE再次发送的请求消息之后，把该请求消息当成一个新的信息进行处理，重新开始执行对目标资源的处理过程，以获得对目标资源的处理结果。
这里，对第一时长、第二时长和第三时长不做限定。一般地，第二时长大于第一时长。第三时长大于第二时长。
实施例七：
图8是本发明再一实施例的oneM2M系统中通信的方法的示意性流程图。图8的方法可以由Hosting CSE的对端实体执行。
801，向Hosting CSE发送非阻塞同步通信模式下的请求消息。请求消息用于Originator向Hosting CSE请求对目标资源进行操作。
802，接收Hosting CSE根据请求消息发送的指示信息。指示消息用于指示第一时长之后重新发送请求消息。
本发明实施例的oneM2M系统使用非阻塞同步通信模式进行通信时，在向下一个实体发送请求对目标资源进行操作的请求消息之后，通过接收下一个实体发送的指示消息，以指示本地实体一段时间之后重新发送请求消息，这样使得＜request＞资源创建失败时仍然可以继续进行通信。
可选地，作为一个实施例，当Hosting CSE不创建＜request＞资源时，中转CSE可以在一段时间之后向Hosting CSE重新发送请求消息。中转CSE可以在Hosting CSE对目标资源进行处理完成后，接收Hosting CSE发送的回复消息。回复消息包括对目标资源的处理结果。中转CSE接收回复消息包括接收对目标资源的处理结果。
中转CSE可以在一段时间之后向Hosting CSE重新发送请求消息。这样，在Hosting CSE不创建＜request＞资源时，依然可以继续执行由Originator向Hosting CSE请求对目标资源进行处理的过程。进而可以避免通信失败而造成的资源浪费和大量的信令开销。
可选地，作为一个实施例，第一时长大于处理目标资源所需的时长。在第一时长后向Hosting CSE重新发送请求消息，也就是在预计Hosting CSE完成对目标资源的处理之后向Hosting CSE重新发送请求消息。
在第一时长之后，如果Hosting CSE还未完成对目标资源的处理，那么Hosting CSE可以向中转CSE重新发送指示消息。指示消息用于指示中转在一段时间之后再次发送请求消息。
在第二时长之后，如果Hosting CSE未收到中转CSE重新发送的请求消息，Hosting CSE可以丢弃对目标资源的处理结果。当中转CSE可以在第三时长之后，向Hosting CSE再次发送请求消息。当Hosting CSE接收到中转CSE再次发送的请求消息之后，把该请求消息当成一个新的信息进行处理，重新开始执行对目标资源的处理过程，以获得对目标资源的处理结果。
具体地，以Hosting CSE的对端实体为中转CSE3为例进行说明。当Hosting CSE不创建＜request＞资源时，中转CSE3在第一次发送请求消息间隔一段时间之后重新向Hosting CSE发送请求消息以得到Hosting CSE发送的对目标资源的处理结果。一段时间长度可以大于预计Hosting CSE完成处理目标资源所需的时间。这样，在Hosting CSE不创建＜request＞资源时，也可以继续执行Originator向Hosting CSE请求对目标资源进行操作的过程。
下面将结合图9至图15详细描述本发明实施例的Originator、中转CSE和Hosting CSE三者之间的交互流程。
实施例八：
图9是本发明一个实施例的oneM2M系统中通信的方法的示意性交互流程图。图9的实施例以三个中转CSE均不创建＜request＞资源，只有Hosting CSE创建＜request＞资源为例进行示例性说明。
901，Originator向Hosting CSE发送请求消息，中转CSE1收到该请求消息。
Originator向目标资源所在的Hosting CSE发送请求消息，请求消息携带RT参数，将RT参数设置为“nonBlockingRequestSynch”时，表示请求采用 非阻塞同步模式进行通信。请求消息用于由Originator向Hosting CSE请求对目标资源进行操作。请求消息可以包括Originator的标识符、目标资源所在的Hosting CSE的标识符和请求资源创建者Request Resource Creator参数。Request Resource Creator参数为缺省值。Originator在中转CSE1上完成注册，中转CSE1可以首先收到该请求消息。
902，中转CSE1向中转CSE2转发该请求消息。
Originator在中转CSE1上完成注册，中转CSE1首先收到上一个实体Originator发送的请求消息。中转CSE1可以根据自身情况确定是否创建＜request＞资源。例如，中转CSE1不支持＜request＞资源类型，则确定不创建＜request＞资源。当中转CSE1确定不创建＜request＞资源时，中转CSE1向中转CSE2转发该请求消息。
903，中转CSE2向中转CSE3转发该请求消息。
中转CSE2收到上一个实体中转CSE1发送的请求消息。中转CSE2也可以根据自身情况确定是否创建＜request＞资源。例如，中转CSE2容量有限，则中转CSE2确定不创建＜request＞资源。当中转CSE2确定不创建＜request＞资源时，中转CSE2向中转CSE3转发该请求消息。
904，中转CSE3向Hosting CSE转发该请求消息。
中转CSE3收到上一个实体中转CSE2发送的请求消息。中转CSE3也可以根据自身情况确定是否创建＜request＞资源。当中转CSE3确定不创建＜request＞资源时，中转CSE3向Hosting CSE转发该请求消息。
905，Hosting CSE对目标资源进行处理，并创建＜request＞资源。
Hosting CSE在接收中转CSE3发送的请求消息之后，对目标资源进行处理。同时，Hosting CSE在接收中转CSE3发送的请求消息之后，可以创建＜request＞资源。
906，Hosting CSE向中转CSE3发送回复消息。
Hosting CSE创建＜request＞资源后，向上一个实体中转CSE3发送回复消息。Hosting CSE发送的回复消息可以包括Hosting CSE的标识符、Originator的标识符和Hosting CSE创建的＜request＞资源的地址信息。
应理解，＜request＞资源的地址信息可以为URI或ID，本发明实施例对此不做限定。
907，中转CSE3向中转CSE2转发该回复消息。
中转CSE3在收到Hosting CSE发送的回复消息之后，向上一个实体中转CSE2转发该回复消息。
908，中转CSE2向中转CSE1转发该回复消息。
中转CSE2在收到中转CSE3发送的回复消息之后，向上一个实体中转CSE1转发该回复消息。
909，中转CSE1向Originator转发该回复消息。
中转CSE1在收到中转CSE2发送的回复消息之后，向上一个实体Originator转发该回复消息。
910，Originator向中转CSE1发送获取请求消息。
Originator在收到中转CSE1发送的回复消息之后，向下一个实体中转CSE1发送获取请求消息。Originator发送的获取请求消息可以包括Originator的标识符和Hosting CSE创建＜request＞资源的地址信息。获取请求消息用于向创建＜request＞资源的Hosting CSE请求获取对目标资源的处理结果。中转CSE1首先收到获取请求消息。
911，中转CSE1向中转CSE2转发该获取请求消息。
中转CSE1在收到Originator发送的获取请求消息之后，向下一个实体中转CSE2转发该获取请求消息。
912，中转CSE2向中转CSE3转发该获取请求消息。
中转CSE2在收到中转CSE1发送的获取请求消息之后，向下一个实体中转CSE3转发该获取请求消息。
913，中转CSE3向Hosting CSE转发该获取请求消息。
中转CSE3在收到中转CSE2发送的获取请求消息之后，向下一个实体Hosting CSE转发该获取请求消息。
914，Hosting CSE更新Hosting CSE自身创建的＜request＞资源。
Hosting CSE在收到中转CSE3发送的获取请求消息之后，如果已经完成对目标资源的处理，得到对目标资源的处理结果。Hosting CSE将对目标资源的处理结果保存在自身创建的＜request＞资源中，以更新自身创建的＜request＞资源。
915，Hosting CSE向中转CSE3发送回复消息。
Hosting CSE在得到对目标资源的处理结果后，向上一个实体中转CSE3发送回复消息。Hosting CSE发送的回复消息包括Hosting CSE的标识符、 Originator的标识符和对目标资源的处理结果。Hosting CSE向中转CSE3发送回复消息包括向中转CSE3发送对目标资源的处理结果。
916，中转CSE3向中转CSE2转发回复消息。
中转CSE3在收到Hosting CSE发送的回复消息后，向上一个实体中转CSE2转发回复消息，以使得中转CSE2得到对目标资源的处理结果。
917，中转CSE2向中转CSE1转发回复消息。
中转CSE2在收到中转CSE3发送的回复消息后，向上一个实体中转CSE1转发回复消息，以使得中转CSE1得到对目标资源的处理结果。
918，中转CSE1向Originator转发回复消息。
中转CSE1在收到中转CSE2发送的回复消息后，向上一个实体Originator转发回复消息，以使得Originator得到对目标资源的处理结果。
Originator接收中转CSE1发送的回复消息包括接收对目标资源的处理结果。Originator得到对目标资源的处理结果，即完成整个Originator向Hosting CSE请求目标资源的通信过程。
图9的实施例以Originator向Hosting CSE发送请求消息，经过三个中转CSE，且三个中转CSE均不创建＜request＞资源为例进行示例性说明，本发明实施例对中转CSE的数目不做限制。图10的实施例将以Originator向Hosting CSE发送请求消息，经过三个中转CSE，中转CSE1创建＜request＞资源，而中转CSE2和中转CSE3均不创建＜request＞资源为例进行示例性说明。
实施例九：
图10是本发明另一实施例的oneM2M系统中通信的方法的示意性交互流程图。
1001，Originator向Hosting CSE发送请求消息，中转CSE1首先收到该请求消息。
Originator向目标资源所在的Hosting CSE发送请求消息，请求消息携带RT参数，将RT参数设置为“nonBlockingRequestSynch”时，表示请求采用非阻塞同步模式进行通信。Originator发送的请求消息用于由Originator向Hosting CSE请求对目标资源进行操作。Originator发送的请求消息可以包括Originator的标识符、目标资源所在的Hosting CSE的标识符和请求资源创建者Request Resource Creator参数。Request Resource Creator参数为缺省值。 Originator在中转CSE1上完成注册，中转CSE1可以首先收到该请求消息。
1002，中转CSE1创建＜request＞资源。
Originator在中转CSE1上完成注册，中转CSE1首先收到上一个实体Originator发送的请求消息。中转CSE1可以根据自身情况确定是否创建＜request＞资源。例如，中转CSE1支持创建＜request＞资源，则确定创建＜request1＞资源。
1003，中转CSE1向Originator发送回复消息。
中转CSE1创建＜request1＞资源之后，向上一个实体Originator发送回复消息。中转CSE1发送的回复消息可以包括中转CSE1的标识符、Originator的标识符、以及中转CSE1创建的＜request 1＞资源的地址信息。中转CSE1发送的回复消息用于向Originator发送中转CSE1创建的所述＜request 1＞资源的地址信息，以便于Originator向中转CSE1发送获取请求消息以获取对目标资源的处理结果。
1004，中转CSE1生成中转CSE1的请求消息，并向下一个实体中转CSE2发送中转CSE1的请求消息。
中转CSE1可以将Request Resource Creator参数设置为中转CSE1的标识符。根据Request Resource Creator参数生成中转CSE1的请求消息。中转CSE1的请求消息可以包括Originator的标识符、Hosting CSE的标识符和请求资源创建者Request Resource Creator参数，中转CSE1的标识符位于Request Resource Creator参数。中转CSE1生成中转CSE1的请求消息之后，向下一个实体中转CSE2发送中转CSE1的请求消息。中转CSE1的请求消息用于请求向Hosting CSE获取对目标资源的处理结果。
1005，中转CSE2向下一个实体中转CSE3转发中转CSE1的请求消息。
中转CSE2收到中转CSE1发送的中转CSE1的请求消息之后，向下一个实体中转CSE3转发中转CSE1的请求消息。
1006，中转CSE3向下一个实体Hosting CSE转发中转CSE1的请求消息。
中转CSE3收到中转CSE2发送的中转CSE1的请求消息之后，向下一个实体Hosting CSE转发中转CSE1的请求消息。
1007，Hosting CSE对目标资源进行处理，并创建＜request2＞资源。
Hosting CSE收到中转CSE3发送的中转CSE1的请求消息之后，开始对 目标资源进行处理。Hosting CSE收到中转CSE3发送的中转CSE1的请求消息之后，根据自身情况，确定创建＜request2＞资源。
1008，Hosting CSE向上一个实体中转CSE3发送回复消息。
Hosting CSE在创建＜request2＞资源之后，向上一个实体中转CSE3发送回复消息。Hosting CSE发送的回复消息可以包括Hosting CSE标识符、中转CSE1的标识符、以及Hosting CSE创建的＜request 2＞资源的地址信息。
本发明实施例对＜request 2＞资源的地址信息不做限定。＜request 2＞资源的地址信息可以为URI或Resource ID。
1009，中转CSE3向中转CSE2转发回复消息。
中转CSE3在收到Hosting CSE发送的回复消息之后，向上一个实体中转CSE2转发步骤1008中的回复消息。
1010，中转CSE2向中转CSE1转发回复消息。
中转CSE2在收到中转CSE3发送的回复消息之后，向上一个实体CSE1转发步骤1008中的回复消息。
1011，中转CSE1向中转CSE2发送获取请求消息。
中转CSE1在收到中转CSE2发送的回复消息之后，向中转CSE2发送获取请求消息。中转CSE1发送的获取请求消息可以包括中转CSE1的标识符和Hosting CSE创建的＜request2＞资源的地址信息。中转CSE1发送的获取请求消息用于向创建＜request2＞资源的Hosting CSE请求获取对目标资源的处理结果。中转CSE2首先收到获取请求消息。
1012，中转CSE2向中转CSE3转发获取请求消息。
中转CSE2在收到中转CSE1发送的获取请求消息之后，向下一个实体中转CSE3转发该获取请求消息。
1013，中转CSE3向Hosting CSE转发获取请求消息。
中转CSE3在收到中转CSE2发送的获取请求消息之后，向下一个实体Hosting CSE转发该获取请求消息。
1014，Hosting CSE更新Hosting CSE自身创建的＜request 2＞资源。
Hosting CSE在收到中转CSE3发送的获取请求消息之后，如果已经完成对目标资源的处理，得到对目标资源的处理结果。Hosting CSE将对目标资源的处理结果保存在自身创建的＜request2＞资源中，以更新＜request2＞资源。
1015，Hosting CSE向中转CSE3发送回复消息。
Hosting CSE在得到对目标资源的处理结果后，向上一个实体中转CSE3发送回复消息。Hosting CSE发送的回复消息可以包括Hosting CSE的标识符、中转CSE1的标识符和对目标资源的处理结果。Hosting CSE向中转CSE3发送的回复消息包括向中转CSE3发送对目标资源的处理结果。
1016，中转CSE3向中转CSE2转发回复消息。
中转CSE3在收到Hosting CSE发送的回复消息后，向上一个实体中转CSE2转发步骤1015中的回复消息，以使得中转CSE2得到对目标资源的处理结果。
1017，中转CSE2向中转CSE1转发回复消息。
中转CSE2在收到中转CSE3发送的第二回复消息后，向上一个实体中转CSE1转发步骤1015中的回复消息，以使得中转CSE1得到对目标资源的处理结果。
1018，中转CSE1根据回复消息更新中转CSE1自身创建的＜request 1＞资源。
中转CSE1在收到中转CSE2发送的步骤1015中的回复消息之后，即收到对目标资源的处理结果。中转CSE 1将对目标资源的处理结果保存在自身创建的＜request 1＞资源中，以更新＜request1＞资源。
1019，Originator向中转CSE1发送获取请求消息。
Originator向下一个实体中转CSE1发送获取请求消息。Originator向中转CSE1发送的获取请求消息包括Originator的标识符和＜request1＞资源的地址信息。Originator向中转CSE1发送的获取请求消息用于Originator向中转CSE1请求获取对目标资源的处理结果。
1020，中转CSE1向Originator发送回复消息。
中转CSE1收到上一个实体Originator发送的获取请求消息之后，向Originator发送回复消息。中转CSE1发送的回复消息可以包括向Originator的标识符、中转CSE1的标识符和对目标资源的处理结果。
Originator收到中转CSE1发送的回复消息即收到对目标资源的处理结果。这样即完成整个Originator向Hosting CSE请求目标资源的通信过程。
实施例十：
图11的实施例将以Originator向Hosting CSE发送请求消息，经过三个 中转CSE，中转CSE1和中转CSE3创建＜request＞资源，而中转CSE2不创建＜request＞资源为例进行示例性说明。
图11是本发明再一实施例的oneM2M系统中通信的方法的示意性交互流程图。
1101，Originator向Hosting CSE发送请求消息，中转CSE1首先收到该请求消息。
Originator向目标资源所在的Hosting CSE发送请求消息，请求消息携带RT参数，将RT参数设置为“nonBlockingRequestSynch”时，表示请求采用非阻塞同步模式进行通信。Originator发送的请求消息用于由Originator向Hosting CSE请求对目标资源进行操作。Originator发送的请求消息包括Originator的标识符、目标资源所在的Hosting CSE的标识符和请求资源创建者Request Resource Creator参数。Request Resource Creator参数为缺省值。Originator在中转CSE1完成注册，中转CSE1可以首先收到该请求消息。
1102，中转CSE1创建＜request＞资源。
Originator在中转CSE1完成注册，中转CSE1首先收到上一个实体Originator发送的请求消息。中转CSE1可以根据自身情况确定是否创建＜request＞资源。例如，中转CSE1支持创建＜request＞资源，则确定创建＜request1＞资源。
1103，中转CSE1向Originator发送回复消息。
中转CSE1创建＜request1＞资源之后，向上一个实体Originator发送回复消息。中转CSE1发送的回复消息包括中转CSE1的标识符、Originator的标识符、以及中转CSE1创建的所述＜request 1＞资源的地址信息。中转CSE1发送的回复消息用于向Originator发送中转CSE1创建的所述＜request 1＞资源的地址信息，以便于Originator向中转CSE1发送获取请求消息以获取对目标资源的处理结果。
1104，中转CSE1生成中转CSE1的请求消息，并向下一个实体中转CSE2发送中转CSE1的请求消息。
中转CSE1可以将Request Resource Creator参数设置为中转CSE1的标识符。根据Request Resource Creator参数生成中转CSE1的请求消息。中转CSE1的请求消息包括Originator的标识符、Hosting CSE的标识符和请求资源创建者Request Resource Creator参数，中转CSE1的标识符位于Request  Resource Creator参数。中转CSE1生成中转CSE1的请求消息之后，向下一个实体中转CSE2发送中转CSE1的请求消息。中转CSE1的请求消息用于请求向Hosting CSE获取对目标资源的处理结果。
本发明实施例对中转CSE1的标识符不做限定。例如，中转CSE1的标识符可以是CSE1-ID。
1105，中转CSE2向下一个实体中转CSE3转发中转CSE1的请求消息。
中转CSE2收到中转CSE1发送的中转CSE1的请求消息之后，向下一个实体中转CSE3转发中转CSE1的请求消息。
1106，中转CSE3创建＜request2＞资源。
中转CSE3收到中转CSE2发送的请求消息之后，根据自身情况，确定是否创建＜request＞资源。例如，中转CSE3支持创建＜request＞资源，创建＜request2＞资源。
1107，中转CSE3向上一个实体中转CSE2发送回复消息。
中转CSE3在创建＜request2＞资源之后，向上一个实体中转CSE2发送回复消息。中转CSE3发送的回复消息包括中转CSE3标识符、中转CSE1的标识符、以及中转CSE3创建的＜request 2＞资源的地址信息。
本发明实施例对＜request 2＞资源的地址信息不做限定。＜request 2＞资源的地址信息可以URI，也可以为Resource ID。
1108，中转CSE2向中转CSE1转发回复消息。
中转CSE2在收到中转CSE3发送的回复消息之后，向上一个实体中转CSE1转发该回复消息。
1109，中转CSE3生成请求消息，并向Hosting CSE发送请求消息。
中转CSE3生成中转CSE3的请求消息。中转CSE3的请求消息可以包括Originator的标识符、Hosting CSE的标识符和请求资源创建者Request Resource Creator参数，中转CSE3的标识符位于所述Request Resource Creator参数。中转CSE3的请求消息用于Originator向Hosting CSE请求目标资源。
中转CSE3向Hosting CSE发送该中转CSE3的请求消息。
1110，Hosting CSE对目标资源进行处理，并创建＜request3＞资源。
Hosting CSE收到中转CSE3发送的中转CSE3的请求消息之后，开始对目标资源进行处理。并且，Hosting CSE收到中转CSE3发送的中转CSE3的请求消息之后，创建＜request3＞资源。
1111，Hosting CSE向上一个实体中转CSE3发送回复消息。
Hosting CSE在创建＜request3＞资源之后，向上一个实体中转CSE3发送回复消息。Hosting CSE发送的回复消息包括Hosting CSE标识符、中转CSE3的标识符、以及Hosting CSE创建的＜request 3＞资源的地址信息。
本发明实施例对＜request 3＞资源的地址信息不做限定。＜request 3＞资源的地址信息可以为URI，也可以为ID。
1112，中转CSE3向Hosting CSE发送获取请求消息。
中转CSE3在收到Hosting CSE发送的回复消息之后，向Hosting CSE发送获取请求消息。CSE3发送的获取请求消息包括中转CSE3的标识符和Hosting CSE创建的＜request 3＞资源的地址信息。
1113，Hosting CSE更新Hosting CSE自身创建的＜request 3＞资源。
Hosting CSE在收到中转CSE3发送的获取请求消息之后，如果已经完成对目标资源的处理，得到对目标资源的处理结果。Hosting CSE将对目标资源的处理结果保存在自身创建的＜request3＞资源中，以更新＜request3＞资源。
1114，Hosting CSE向中转CSE3发送回复消息。
Hosting CSE在得到对目标资源的处理结果后，向上一挑实体中转CSE3发送回复消息。Hosting CSE发送的回复消息包括Hosting CSE的标识符、中转CSE3的标识符和对目标资源的处理结果。Hosting CSE向中转CSE3发送回复消息包括向中转CSE3发送对目标资源的处理结果。
1115，中转CSE3根据Hosting CSE发送的回复消息更新中转CSE3自身创建的＜request 2＞资源。
中转CSE3在收到Hosting CSE发送的回复消息之后，即收到对目标资源的处理结果。中转CSE 3将对目标资源的处理结果保存在自身创建的＜request 2＞资源中，以更新中转CSE3自身创建的＜request2＞资源。
1116，中转CSE1向中转CSE2发送获取请求消息。
中转CSE1向下一个实体中转CSE2发送获取请求消息。中转CSE1发送的获取请求消息包括中转CSE1的标识符和中转CSE3创建的＜request2＞资源的地址信息。
1117，中转CSE2向中转CSE3转发获取请求消息。
中转CSE2收到中转CSE1发送的获取请求消息之后，向下一个实体中 转CSE3转发获取请求消息。
1118，中转CSE3向中转CSE2发送回复消息。
中转CSE3在收到中转CSE2发送的获取请求消息之后，向上一个实体中转CSE2发送回复消息。中转CSE3发送的回复消息包括中转CSE1的标识符、中转CSE3的标识符和对目标资源的处理结果。
1119，中转CSE2向中转CSE1转发回复消息。
中转CSE2收到中转CSE3发送的回复消息后，向上一个实体中转CSE2转发该回复消息。
1120，中转CSE1根据中转CSE2发送的回复消息，更新中转CSE1自身创建的＜request 1＞资源。
中转CSE1在收到中转CSE2发送的回复消息之后，即收到对目标资源的处理结果。中转CSE 1将对目标资源的处理结果保存在自身创建的＜request 1＞资源中，以更新中转CSE1自身创建的＜request1＞资源。
1121，Originator向中转CSE1发送获取请求消息。
Originator向下一个实体中转CSE1发送获取请求消息。Originator发送的获取请求消息包括Originator的标识符和＜request 1＞资源的地址信息。Originator发送的获取请求消息用于Originator向中转CSE1请求获取对目标资源的处理结果。
1122，中转CSE1向Originator发送回复消息。
中转CSE1收到上一个实体Originator发送的获取请求消息之后，向Originator发送回复消息。中转CSE1发送的回复消息包括中转CSE1的标识符、Originator的标识符和对目标资源的处理结果。中转CSE1向Originator发送回复消息包括向Originator发送对目标资源的处理结果。
Originator收到中转CSE1发送的回复消息，即收到中转CSE1发送的对目标资源的处理结果，以完成整个Originator向Hosting CSE请求目标资源的通信过程。
实施例十一：
图12是本发明另一实施例的oneM2M系统中通信的方法的示意性交互流程图。图12的实施例以三个中转CSE均不创建＜request＞资源，只有Hosting CSE创建＜request＞资源为例进行示例性说明。
1201，Originator向Hosting CSE发送请求消息，中转CSE1收到该请求 消息。
Originator向目标资源所在的Hosting CSE发送请求消息，请求消息携带RT参数，将RT参数设置为“nonBlockingRequestSynch”时，表示请求采用非阻塞同步模式进行通信。请求消息用于由Originator向Hosting CSE请求对目标资源进行操作。请求消息可以包括Originator的标识符、目标资源所在的Hosting CSE的标识符和请求资源指示字段。请求资源指示字段为缺省值。Originator在CSE1上完成注册，中转CSE1可以首先收到该请求消息。
1202，中转CSE1向中转CSE2转发该请求消息。
Originator在中转CSE1上完成注册，中转CSE1首先收到上一个实体Originator发送的请求消息。中转CSE1可以根据自身情况确定是否创建＜request＞资源。当中转CSE1确定不创建＜request＞资源时，中转CSE1向中转CSE2转发该请求消息。
1203，中转CSE2向中转CSE3转发该请求消息。
中转CSE2收到上一个实体中转CSE1发送的请求消息。中转CSE2也可以根据自身情况确定是否创建＜request＞资源。当中转CSE2确定不创建＜request＞资源时，中转CSE2向中转CSE3转发该请求消息。
1204，中转CSE3向Hosting CSE转发该请求消息。
中转CSE3收到上一个实体中转CSE2发送的请求消息。中转CSE3也可以根据自身情况确定是否创建＜request＞资源。当中转CSE3确定不创建＜request＞资源时，中转CSE3向Hosting CSE转发该请求消息。
1205，Hosting CSE对目标资源进行处理，并创建＜request＞资源。
Hosting CSE在接收中转CSE3发送的请求消息之后，对目标资源进行处理。同时，Hosting CSE在接收中转CSE3发送的请求消息之后，可以创建＜request＞资源。
1206，Hosting CSE向中转CSE3发送回复消息。
Hosting CSE创建＜request＞资源后，向上一个实体中转CSE3发送回复消息。Hosting CSE发送的回复消息可以包括Hosting CSE的标识符、Originator的标识符和Hosting CSE创建的＜request＞资源的地址信息。
应理解，＜request＞资源的地址信息可以为URI或ID，本发明实施例对此不做限定。
1207，中转CSE3向中转CSE2转发该回复消息。
中转CSE3在收到Hosting CSE发送的回复消息之后，向上一个实体中转CSE2转发该回复消息。
1208，中转CSE2向中转CSE1转发该回复消息。
中转CSE2在收到中转CSE3发送的回复消息之后，向上一个实体中转CSE1转发该回复消息。
1209，中转CSE1向Originator转发该回复消息。
中转CSE1在收到中转CSE2发送的回复消息之后，向上一个实体Originator转发该回复消息。
1210，Originator向中转CSE1发送获取请求消息。
Originator在收到中转CSE1发送的回复消息之后，向下一个实体中转CSE1发送获取请求消息。Originator发送的获取请求消息可以包括Originator的标识符和Hosting CSE创建＜request＞资源的地址信息。获取请求消息用于向创建＜request＞资源的Hosting CSE请求获取对目标资源的处理结果。中转CSE1首先收到获取请求消息。
1211，中转CSE1向中转CSE2转发该获取请求消息。
中转CSE1在收到Originator发送的获取请求消息之后，向下一个实体中转CSE2转发该获取请求消息。
912，中转CSE2向中转CSE3转发该获取请求消息。
中转CSE2在收到中转CSE1发送的获取请求消息之后，向下一个实体中转CSE3转发该获取请求消息。
1213，中转CSE3向Hosting CSE转发该获取请求消息。
中转CSE3在收到中转CSE2发送的获取请求消息之后，向下一个实体Hosting CSE转发该获取请求消息。
1214，Hosting CSE更新Hosting CSE自身创建的＜request＞资源。
Hosting CSE在收到中转CSE3发送的获取请求消息之后，如果已经完成对目标资源的处理，得到对目标资源的处理结果。Hosting CSE将对目标资源的处理结果保存在自身创建的＜request＞资源中，以更新自身创建的＜request＞资源。
1215，Hosting CSE向中转CSE3发送回复消息。
Hosting CSE在得到对目标资源的处理结果后，向上一个实体中转CSE3发送回复消息。Hosting CSE发送的回复消息包括Hosting CSE的标识符、 Originator的标识符和对目标资源的处理结果。Hosting CSE向中转CSE3发送回复消息包括向中转CSE3发送对目标资源的处理结果。
1216，中转CSE3向中转CSE2转发回复消息。
中转CSE3在收到Hosting CSE发送的回复消息后，向上一个实体中转CSE2转发回复消息，以使得中转CSE2得到对目标资源的处理结果。
1217，中转CSE2向中转CSE1转发回复消息。
中转CSE2在收到中转CSE3发送的回复消息后，向上一个实体中转CSE1转发回复消息，以使得中转CSE1得到对目标资源的处理结果。
1218，中转CSE1向Originator转发回复消息。
中转CSE1在收到中转CSE2发送的回复消息后，向上一个实体Originator转发回复消息，以使得Originator得到对目标资源的处理结果。
Originator接收中转CSE1发送的回复消息包括接收对目标资源的处理结果。Originator得到对目标资源的处理结果，即完成整个Originator向Hosting CSE请求目标资源的通信过程。
实施例十二：
图13是本发明另一实施例的oneM2M系统中通信的方法的示意性交互流程图。图13的实施例将以Originator向Hosting CSE发送请求消息，经过三个中转CSE，中转CSE1和中转CSE3创建＜request＞资源，而中转CSE2不创建＜request＞资源为例进行示例性说明。
1301，Originator向Hosting CSE发送请求消息，中转CSE1首先收到该请求消息。
Originator向目标资源所在的Hosting CSE发送请求消息，请求消息携带RT参数，将RT参数设置为“nonBlockingRequestSynch”时，表示请求采用非阻塞同步模式进行通信。Originator发送的请求消息用于由Originator向Hosting CSE请求对目标资源进行操作。Originator发送的请求消息包括Originator的标识符、目标资源所在的Hosting CSE的标识符和请求资源创建者请求资源指示字段。请求资源指示字段为缺省值。Originator在CSE1完成注册，中转CSE1可以首先收到该请求消息。
1302，中转CSE1创建＜request＞资源。
Originator在中转CSE1完成注册，中转CSE1首先收到上一个实体Originator发送的请求消息。中转CSE1可以根据自身情况确定是否创建＜ request＞资源。例如，中转CSE1支持创建＜request＞资源，则确定创建＜request1＞资源。
1303，中转CSE1向Originator发送回复消息。
中转CSE1创建＜request1＞资源之后，向上一个实体Originator发送回复消息。中转CSE1发送的回复消息包括中转CSE1的标识符、Originator的标识符、以及中转CSE1创建的所述＜request 1＞资源的地址信息。中转CSE1发送的回复消息用于向Originator发送中转CSE1创建的所述＜request 1＞资源的地址信息，以便于Originator向中转CSE1发送获取请求消息以获取对目标资源的处理结果。
1304，中转CSE1生成中转CSE1的请求消息，并向下一个实体中转CSE2发送中转CSE1的请求消息。
中转CSE1可以将请求资源指示字段设置为中转CSE1的标识符，即可生成中转CSE1的请求消息。中转CSE1的请求消息包括Originator的标识符、Hosting CSE的标识符和请求资源指示字段，中转CSE1的标识符位于请求资源指示字段。中转CSE1生成中转CSE1的请求消息之后，向下一个实体中转CSE2发送中转CSE1的请求消息。中转CSE1的请求消息用于请求向Hosting CSE获取对目标资源的处理结果。
1305，中转CSE2向下一个实体中转CSE3转发中转CSE1的请求消息。
中转CSE2收到中转CSE1发送的中转CSE1的请求消息之后，向下一个实体中转CSE3转发中转CSE1的请求消息。
1306，中转CSE3创建＜request2＞资源。
中转CSE3收到中转CSE2发送的请求消息之后，根据自身情况，确定是否创建＜request＞资源。例如，中转CSE3支持创建＜request＞资源，创建＜request2＞资源。
1307，中转CSE3向上一个实体中转CSE2发送回复消息。
中转CSE3在创建＜request2＞资源之后，向上一个实体中转CSE2发送回复消息。中转CSE3发送的回复消息包括中转CSE3标识符、中转CSE1的标识符、以及中转CSE3创建的＜request 2＞资源的地址信息。
1308，中转CSE2向中转CSE1转发回复消息。
中转CSE2在收到中转CSE3发送的回复消息之后，向上一个实体中转CSE1转发该回复消息。
1309，中转CSE3生成请求消息，并向Hosting CSE发送请求消息。
将请求资源指示字段设置为中转CSE3的标识符，即可生成中转CSE3的请求消息。中转CSE3的请求消息可以包括Originator的标识符、Hosting中转CSE的标识符和请求资源指示字段，中转CSE3的标识符位于请求资源指示字段。中转CSE3生成中转CSE3的请求消息之后，向下一个实体Hosting中转CSE发送中转CSE3的请求消息。中转CSE3的请求消息用于请求向Hosting CSE获取对目标资源的处理结果。
1310，Hosting CSE对目标资源进行处理，并创建＜request3＞资源。
Hosting CSE收到中转CSE3发送的中转CSE3的请求消息之后，开始对目标资源进行处理。并且，Hosting CSE收到中转CSE3发送的中转CSE3的请求消息之后，创建＜request3＞资源。
1311，Hosting CSE向上一个实体中转CSE3发送回复消息。
Hosting CSE在创建＜request3＞资源之后，向上一个实体中转CSE3发送回复消息。Hosting CSE发送的回复消息包括Hosting CSE标识符、中转CSE3的标识符、以及Hosting CSE创建的＜request 3＞资源的地址信息。
1312，中转CSE3向Hosting CSE发送获取请求消息。
中转CSE3在收到Hosting CSE发送的回复消息之后，向Hosting CSE发送获取请求消息。中转CSE3发送的获取请求消息包括中转CSE3的标识符和Hosting CSE创建的＜request 3＞资源的地址信息。
1313，Hosting CSE更新Hosting CSE自身创建的＜request 3＞资源。
Hosting CSE在收到中转CSE3发送的获取请求消息之后，如果已经完成对目标资源的处理，得到对目标资源的处理结果。Hosting CSE将对目标资源的处理结果保存在自身创建的＜request3＞资源中，以更新＜request3＞资源。
1114，Hosting CSE向中转CSE3发送回复消息。
Hosting CSE在得到对目标资源的处理结果后，向上一挑实体中转CSE3发送回复消息。Hosting CSE发送的回复消息包括Hosting CSE的标识符、CSE3的标识符和对目标资源的处理结果。Hosting CSE向中转CSE3发送回复消息包括向中转CSE3发送对目标资源的处理结果。
1315，中转CSE3根据Hosting CSE发送的回复消息更新中转CSE3自身创建的＜request 2＞资源。
中转CSE3在收到Hosting CSE发送的回复消息之后，即收到对目标资源的处理结果。中转CSE 3将对目标资源的处理结果保存在自身创建的＜request 2＞资源中，以更新中转CSE3自身创建的＜request2＞资源。
1316，中转CSE1向中转CSE2发送获取请求消息。
中转CSE1向下一个实体中转CSE2发送获取请求消息。中转CSE1发送的获取请求消息包括中转CSE1的标识符和中转CSE3创建的＜request2＞资源的地址信息。
1317，中转CSE2向中转CSE3转发获取请求消息。
中转CSE2收到中转CSE1发送的获取请求消息之后，向下一个实体中转CSE3转发获取请求消息。
1318，中转CSE3向中转CSE2发送回复消息。
中转CSE3在收到中转CSE2发送的获取请求消息之后，向上一个实体中转CSE2发送回复消息。中转CSE3发送的回复消息包括中转CSE1的标识符、中转CSE3的标识符和对目标资源的处理结果。
1319，中转CSE2向中转CSE1转发回复消息。
中转CSE2收到中转CSE3发送的回复消息后，向上一个实体中转CSE2转发该回复消息。
1320，中转CSE1根据中转CSE2发送的回复消息，更新中转CSE1自身创建的＜request 1＞资源。
中转CSE1在收到中转CSE2发送的回复消息之后，即收到对目标资源的处理结果。中转CSE1将对目标资源的处理结果保存在自身创建的＜request 1＞资源中，以更新中转CSE1自身创建的＜request1＞资源。
1321，Originator向中转CSE1发送获取请求消息。
Originator向下一个实体中转CSE1发送获取请求消息。Originator发送的获取请求消息包括Originator的标识符和＜request 1＞资源的地址信息。Originator发送的获取请求消息用于Originator向中转CSE1请求获取对目标资源的处理结果。
1322，中转CSE1向Originator发送回复消息。
中转CSE1收到上一个实体Originator发送的获取请求消息之后，向Originator发送回复消息。中转CSE1发送的回复消息包括中转CSE1的标识符、Originator的标识符和对目标资源的处理结果。中转CSE1向Originator 发送回复消息包括向Originator发送对目标资源的处理结果。
Originator收到中转CSE1发送的回复消息，即收到中转CSE1发送的对目标资源的处理结果，以完成整个Originator向Hosting CSE请求目标资源的通信过程。
实施例十三：
图14的实施例将以Originator向Hosting CSE发送请求消息，经过三个中转CSE，中转CSE1创建＜request＞资源，当中转CSE2不创建＜request＞资源时，跳过不创建＜request＞资源的中转CSE2，中转CSE1和中转CSE3之间建立通信，以完成Originator向Hosting CSE请求对目标资源进行操作的过程。
图14是本发明再一实施例的oneM2M系统中通信的方法的示意性交互流程图。
1401，Originator向Hosting CSE发送请求消息，中转CSE1首先收到该请求消息。
Originator向目标资源所在的Hosting CSE发送请求消息，请求消息携带RT参数，将RT参数设置为“nonBlockingRequestSynch”时，表示请求采用非阻塞同步模式进行通信。请求消息用于由Originator向Hosting CSE请求对目标资源进行操作。请求消息包括Originator的标识符、目标资源所在的Hosting CSE的标识符。Originator在中转CSE1完成注册，中转CSE1首先收到该请求消息。
1402，中转CSE1创建＜request＞资源。
Originator在中转CSE1完成注册，中转CSE1首先收到上一个实体Originator发送的请求消息。中转CSE1可以根据自身情况确定是否创建＜request＞资源。例如，中转CSE1支持创建＜request＞资源时，中转CSE1创建＜request1＞资源。
1403，中转CSE1向Originator发送回复消息。
中转CSE1创建＜request1＞资源之后，向上一个实体Originator发送回复消息。中转CSE1向Originator发送的回复消息包括中转CSE1的标识符、Originator的标识符、以及中转CSE1创建的＜request 1＞资源的地址信息。中转CSE1向Originator发送的回复消息用于向Originator发送中转CSE1创建的＜request 1＞资源的地址信息，以便于Originator向中转CSE1发送获取 请求消息以获取对目标资源的处理结果。
1404，中转CSE1向下一个实体中转CSE2发送请求消息。
中转CSE1在创建＜request1＞资源之后，向下一个实体中转CSE2发送请求消息。中转CSE1向下一个实体中转CSE2发送的请求消息用于请求向Hosting CSE获取对目标资源的处理结果。请求消息包括Originator的标识符、目标资源所在的Hosting CSE的标识符。这里，中转CSE1向下一个实体中转CSE2发送的请求消息和Originator向Hosting CSE发送的请求消息相同。
1405，中转CSE2确定不创建＜request＞资源。
中转CSE2接收中转CSE1发送的请求消息之后，可以根据自身情况确定是否创建＜request＞资源。例如，中转CSE2不支持＜request＞资源类型，则中转CSE2确定不创建＜request＞资源。
1406，中转CSE2向中转CSE1发送指示信息。
当中转CSE2确定不创建＜request＞资源时，向上一个实体中转CSE1发送指示消息。中转CSE2向中转CSE1发送的指示消息包括中转CSE1的标识符、中转CSE2的标识符和请求资源不创建Request Not Create参数，Request Not Create参数包括中转CSE3的标识符。中转CSE2向中转CSE1发送的指示消息用于指示上一个实体中转CSE1向下一个实体中转CSE3发送请求消息，以绕过不创建＜request＞资源中转CSE2继续执行Originator向Hosting CSE请求对目标资源进行操作的过程。
1407，中转CSE1注销在中转CSE2上的注册信息，并注册到中转CSE3上。
中转CSE1收到中转CSE2发送的指示信息之后，注销在中转CSE2上的注册信息，并注册到中转CSE3上，建立中转CSE1和中转CSE3之间的通信。
1408，中转CSE1向中转CSE3发送请求消息。
中转CSE1在中转CSE3上完成注册后，向中转CSE3发送请求消息。中转CSE1向中转CSE3发送的请求消息。中转CSE1向中转CSE3发送的请求消息包括Originator的标识符、目标资源所在的Hosting CSE的标识符。这里，中转CSE1向中转CSE3发送的请求消息和Originator向Hosting CSE发送的请求消息相同。
1409，中转CSE3创建＜request2＞资源。
中转CSE3接收中转CSE1发送的请求消息之后，可以根据自身情况确定是否创建＜request＞资源。中转CSE3可以创建＜request2＞资源。
1410，中转CSE3向中转CSE1发送回复消息。
在中转CSE3确定创建＜request2＞资源时，中转CSE3向中转CSE1发送回复消息。中转CSE3向中转CSE1发送的回复消息包括中转CSE3的标识符、中转CSE1的标识符和中转CSE3创建的＜request2＞资源的地址信息。
1411，中转CSE3向Hosting CSE发送请求消息。
中转CSE3向下一个实体Hosting CSE发送请求消息。中转CSE3发送的请求消息用于请求向Hosting CSE获取对目标资源的处理结果。中转CSE3在确定创建＜request2＞资源之后，向下一个实体Hosting CSE发送请求消息。中转CSE3发送的请求消息包括Originator的标识符、目标资源所在的Hosting CSE的标识符。这里，中转CSE3向Hosting CSE发送的请求消息、Originator向Hosting CSE发送的请求消息、以及中转CSE1向中转CSE3发送请求消息均相同。
1412，Hosting CSE对目标资源进行处理，并创建＜request3＞资源。
Hosting CSE收到中转CSE3发送的请求消息之后，开始对目标资源进行处理。并且，Hosting CSE收到中转CSE3发送的请求消息之后，创建＜request3＞资源。
1413，Hosting CSE向中转CSE3发送回复消息。
Hosting CSE创建＜request3＞资源后，向中转CSE3发送回复消息。Hosting CSE向中转CSE3发送回复消息包括中转CSE3的标识符、Hosting CSE的标识符和Hosting CSE创建的＜request3＞资源的地址信息。
1414，Hosting CSE更新自身创建的＜request3＞资源。
Hosting CSE如果已经完成对目标资源的处理，得到对目标资源的处理结果。那么，将对目标资源的处理结果保存在自身创建的＜request3＞资源中以更新＜request3＞资源。
1415，CSE3向Hosting CSE发送获取请求消息。
CSE3向下一个实体Hosting CSE发送获取请求消息。中转CSE3发送的获取请求消息包括中转CSE3的标识符和＜request3＞资源的地址信息。中转CSE3发送的获取请求消息用于请求向Hosting CSE获取对目标资源的处理结果。
1416，Hosting CSE向中转CSE3发送回复消息。
Hosting CSE接收中转CSE3发送的获取请求消息之后，根据获取请求消息向中转CSE3发送回复消息。Hosting CSE发送的回复消息包括Hosting CSE的标识符、中转CSE3的标识符和对目标资源的处理结果。Hosting CSE向CSE3发送回复消息包括向中转CSE3发送对目标资源的处理结果。
1417，中转CSE3更新＜request2＞资源。
中转CSE3在接收Hosting CSE发送的回复消息之后，将对目标资源的处理结果保存在＜request2＞资源中以更新自身创建的＜request2＞资源。
1418，中转CSE1向中转CSE3发送获取请求消息。
中转CSE1向中转CSE3发送获取请求消息。中转CSE1发送的获取请求消息包括中转CSE1的标识符和＜request2＞资源的地址信息。中转CSE1发送的获取请求消息用于请求向中转CSE3获取对目标资源的处理结果。
1419，中转CSE3向中转CSE1发送回复消息。
中转CSE3接收中转CSE1发送的获取请求消息之后，根据获取请求消息向中转CSE1发送回复消息。中转CSE3发送的回复消息包括Hosting CSE的标识符、中转CSE3的标识符和对目标资源的处理结果。Hosting CSE向中转CSE3发送回复消息包括向中转CSE3发送对目标资源的处理结果。
1420，中转CSE1更新＜request1＞资源。
中转CSE1在接收中转CSE3发送的回复消息之后，将对目标资源的处理结果保存在＜request1＞资源中以更新自身创建的＜request1＞资源。
1421，Originator向中转CSE1发送获取请求消息。
Originator向中转CSE1发送获取请求消息。Originator发送的获取请求消息包括Originator的标识符和＜request1＞资源的地址信息。Originator发送的获取请求消息用于请求向中转CSE1获取对目标资源的处理结果。
1422，中转CSE1向Originator发送回复消息。
中转CSE1接收Originator发送的获取请求消息之后，根据获取请求消息向Originator发送回复消息。中转CSE1发送的回复消息包括中转CSE3的标识符、中转CSE1的标识符和对目标资源的处理结果。中转CSE1向Originator发送回复消息包括向Originator发送对目标资源的处理结果。
图15的实施例将以Originator向Hosting CSE发送请求消息，经过两个中转CSE，在中转CSE1和中转CSE2均创建＜request＞资源，而Hosting CSE 不创建＜request＞资源时，Hosting CSE在收到请求消息之后，对目标资源进行处理，并在得到对目标资源的处理结果时基于中转CSE2重新发送请求消息，向中转CSE2返回对目标资源的处理结果，以完成Originator向Hosting CSE请求对目标资源进行操作的过程。
实施例十四：
图15是本发明再一实施例的oneM2M系统中通信的方法的示意性交互流程图。
1501，Originator向Hosting CSE发送请求消息，中转CSE1首先收到该请求消息。
Originator向目标资源所在的Hosting CSE发送请求消息，请求消息携带RT参数，将RT参数设置为“nonBlockingRequestSynch”时，表示请求采用非阻塞同步模式进行通信。请求消息用于由Originator向Hosting CSE请求对目标资源进行操作。请求消息包括Originator的标识符、目标资源所在的Hosting CSE的标识符。Originator在中转CSE1上完成注册，中转CSE1首先收到该请求消息。
1502，中转CSE1创建＜request＞资源。
Originator在中转CSE1完成注册，中转CSE1首先收到上一个实体Originator发送的请求消息。中转CSE1可以根据自身情况确定是否创建＜request＞资源。例如，中转CSE1支持创建＜request＞资源时，中转CSE1创建＜request1＞资源。
1503，中转CSE1向Originator发送回复消息。
中转CSE1创建＜request1＞资源之后，向上一个实体Originator发送回复消息。中转CSE1向Originator发送的回复消息包括中转CSE1的标识符、Originator的标识符、以及中转CSE1创建的＜request 1＞资源的地址信息。中转CSE1向Originator发送的回复消息用于向Originator发送中转CSE1创建的＜request 1＞资源的地址信息，以便于Originator向中转CSE1发送获取请求消息以获取对目标资源的处理结果。
1504，中转CSE1向下一个实体中转CSE2发送请求消息。
中转CSE1在创建＜request1＞资源之后，向下一个实体中转CSE2发送请求消息。中转CSE1向下一个实体中转CSE2发送的请求消息用于请求向Hosting CSE获取对目标资源的处理结果。中转CSE1向中转CSE2发送的请 求消息包括Originator的标识符、目标资源所在的Hosting CSE的标识符。这里，中转CSE1向下一个实体中转CSE2发送的请求消息和Originator向Hosting CSE发送的请求消息相同。
1505，中转CSE2创建＜request2＞资源。
中转CSE2根据自身情况，确定是否创建＜request＞资源。中转CSE2可以创建＜request2＞资源。
1506，中转CSE2向中转CSE1发送回复消息。
中转CSE2创建＜request2＞资源之后，向中转CSE1发送回复消息。中转CSE2向中转CSE1发送的回复消息包括中转CSE2的标识符、中转CSE1的标识符和中转CSE2创建的＜request2＞资源的地址信息。中转CSE2向中转CSE1发送的回复消息包括中转CSE2向中转CSE1发送中转CSE2创建的＜request2＞资源的地址信息，以便于Originator向中转CSE1发送获取请求消息以获取对目标资源的处理结果。
1507，中转CSE2向下一个实体Hosting CSE发送请求消息。
CSE2向下一个实体Hosting CSE发送请求消息。中转CSE2发送的请求消息用于请求向Hosting CSE获取对目标资源的处理结果。中转CSE2在创建＜request2＞资源之后，向下一个实体Hosting CSE发送请求消息。中转CSE2向Hosting CSE发送的请求消息包括Originator的标识符、目标资源所在的Hosting CSE的标识符。
1508，Hosting CSE对目标资源进行处理，并不创建＜request＞资源。
Hosting CSE收到中转CSE2发送的请求消息之后，开始对目标资源进行处理。并且，Hosting CSE可以根据自身情况确定是否创建＜request＞资源。Hosting CSE确定可以不创建＜request＞资源。
1509，Hosting CSE向中转CSE2发送指示消息。
Hosting CSE在确定不创建＜request＞资源之后，向上一个实体中转CSE2发送指示消息。Hosting CSE向中转CSE2发送的指示消息包括Hosting CSE的标识符、中转CSE2的标识符和请求资源不创建Request Not Create参数。指示消息用于请求中转CSE2在一段时间T之后重新向Hosting CSE发送请求消息。中转CSE2重新发送请求消息的时间位于请求资源不创建Request Not Create参数。T可以根据Hosting CSE预计完成对目标资源的处理所需要的时间来确定。例如，T可以大于Hosting CSE预计完成对目标资 源的处理所需要的时间。
1510，Hosting CSE完成对目标资源的处理。
Hosting CSE在收到中转CSE2发送的请求消息时，开始对目标资源进行处理。一段时间之后，Hosting CSE完成对目标资源的处理，得到对目标资源的处理结果。这样，可以在Hosting CSE不支持创建＜request＞资源时，继续执行Originator向Hosting CSE请求对目标资源进行操作的过程。
1511，中转CSE2向Hosting CSE重新发送请求消息。
CSE2在向Hosting CSE发送请求消息一段时间T之后，重新向Hosting CSE发送请求消息。
请求消息还包括携带＜request＞的ID的第一参数。Hosting CSE可以通过第一参数判断是否为同一个请求消息。例如，当重新发送的请求消息中携带的＜request＞的ID的第一参数与Hosting CSE第一次收到的请求消息中包括的第一参数相同时，Hosting CSE可以判断为同一个请求消息。
1512，Hosting CSE向中转CSE2发送对目标资源的处理结果。
步骤1510Hosting CSE对目标资源进行处理，在处理完成之后，得到对目标资源的处理结果。Hosting CSE向上一个实体CSE2发送对目标资源的处理结果。
这里，在步骤1511中，当Hosting CSE收到请求消息后，判断为同一个请求消息时，可以直接在对目标资源的处理完成之后，向中转CSE2发送对目标资源的处理结果，而不再需要中转CSE2向Hosting CSE发送获取请求消息。
1513，中转CSE2更新自身创建的＜request2＞资源。
中转CSE2在收到Hosting CSE发送的对目标资源的处理结果后，将对目标资源的处理结果保存在自身创建的＜request2＞资源中，以更新＜request2＞资源。
1514，中转CSE1向中转CSE2发送获取请求消息。
中转CSE1向中转CSE2发送获取请求消息。中转CSE1向中转CSE2发送的获取请求消息包括中转CSE1的标识符和＜request2＞资源的地址信息。
1515，中转CSE2向中转CSE1发送回复消息。
中转CSE2在收到中转CSE1发送的获取请求消息之后，根据更新后的 ＜request2＞资源向中转CSE1发送回复消息。中转CSE2向中转CSE1发送的回复消息可以包括中转CSE2的标识符、中转CSE1的标识符和对目标资源的处理结果。
1516，中转CSE1更新自身创建的＜request1＞资源。
中转CSE1在收到中转CSE2发送的回复消息之后，即收到中转CSE2发送的对目标资源的处理结果，将对目标资源的处理结果保存在自身创建的＜request1＞资源中，以更新＜request1＞资源。
1517，Originator向中转CSE1发送获取请求消息。
Originator向下一个实体中转CSE1发送获取请求消息。Originator向中转CSE1发送的获取请求消息可以包括Originator的标识符和＜request1＞资源的地址信息。Originator向中转CSE1发送的获取请求消息用于向中转CSE1请求对目标资源的处理结果。
1518，中转CSE1向Originator发送回复消息。
中转CSE1在收到Originator发送的获取请求消息之后，向Originator发送回复消息。中转CSE1向Originator发送的回复消息可以包括Originator的标识符、中转CSE1的标识符和对目标资源的处理结果。
Originator收到中转CSE1发送的回复消息，即收到对目标资源的处理结果。这样可以完成Originator向Hosting CSE请求目标资源的通信全过程。
上文中结合图2至图15，详细描述了根据本发明实施例的M2M系统中通信的方法、过程和交互，下面将结合图16至图29，详细描述根据本发明实施例的M2M系统中通信的装置。
实施例十五：
图16是本发明一个实施例的oneM2M系统中通信的装置的示意性框图。图16的装置160可以为中转CSE，包括第一接收单元1601和第一发送单元1602。
第一接收单元1601用于接收上一个实体发送的非阻塞同步通信模式下的第一请求消息。第一请求消息包括请求资源创建者Request Resource Creator参数。Request Resource Creator参数为缺省值或上一个针对第一请求消息创建请求＜request＞资源的实体的标识符。第一请求消息用于Originator向目标资源所在的Hosting CSE请求对所述目标资源进行操作。
第一发送单元1602用于当针对第一接收单元接收的第一请求消息不创 建＜request＞资源时，向下一个实体发送第一请求消息。
本发明实施例的oneM2M系统使用非阻塞同步通信模式进行通信时，在接收上一个实体发送的增加Request Resource Creator参数的请求消息之后，通过不创建＜request＞资源的实体向下一个实体转发该请求消息，以使得本地实体＜request＞资源创建失败时仍然可以继续进行通信。
可选地，作为一个实施例，装置160还包括第二接收单元和第二发送单元。第二接收单元用于接收下一个实体发送的第一回复消息。第一回复消息包括下一个针对第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息。第二发送单元向所述上一个实体发送所述第一回复消息。
可选地，作为一个实施例，装置160还包括第三接收单元和第三发送单元。第三接收单元用于接收上一个实体发送的第一获取请求消息。第一获取请求消息包括下一个针对第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息。第一获取请求消息用于向下一个创建＜request＞资源的实体请求获取对目标资源的处理结果。第三发送单元用于向下一个实体发送第一获取请求消息。
可选地，作为一个实施例，装置160还包括第四接收单元和第四发送单元。第四接收单元用于接收下一个实体发送的第二回复消息。第二回复消息包括对目标资源的处理结果。第四发送单元用于向上一个实体发送第二回复消息。
可选地，作为一个实施例，装置160还包括确定单元。确定单元用于确定是否针对第一请求消息创建＜request＞资源。
可选地，作为一个实施例，确定单元具体用于根据容量和/或支持的＜request＞资源类型确定是否针对第一请求消息创建＜request＞资源。
可选地，作为一个实施例，装置160还包括创建单元、第五发送单元、生成单元和第六发送单元。创建单元用于当确定针对所述第一请求消息创建＜request＞资源时，创建＜request＞资源。第五发送单元用于向上一个实体发送第三回复消息。第三回复消息包括创建的＜request＞资源的地址信息。生成单元用于生成第二请求消息。第二请求消息包括Request Resource Creator参数。将Request Resource Creator参数设置为中转CSE的标识符。第六发送单元用于向下一个实体发送第二请求消息。
可选地，作为一个实施例，装置160还包括第五接收单元、更新单元、 第六接收单元和第七发送单元。第五接收单元用于接收下一个实体发送的第四回复消息。第四回复消息包括对目标资源的处理结果。更新单元用于根据第四回复消息更新中转CSE创建的所述＜request＞资源。第六接收单元用于接收上一个实体发送的第二获取请求消息。第二获取请求消息包括创建的＜request＞资源的地址信息。第二获取请求消息用于上一个实体向中转CSE请求获取所述对目标资源的处理结果。第七发送单元用于向上一个实体发送第五回复消息。第五回复消息包括对目标资源的处理结果。
根据本发明实施例的M2M系统中通信的装置可对应于本发明实施例的M2M系统中通信的方法，并且，装置中的各个单元/模块和上述其他操作和/或功能分别为了实现图2中所示方法的相应流程和图9、图10和图11所示的方法中相关CSE的相应流程，为了简洁，在此不再赘述。
实施例十六：
图17是本发明另一实施例的oneM2M系统中通信的装置的示意性框图。图17的装置170包括接收单元1701、生成单元1702、更新单元1703和发送单元1704。
第一接收单元1701用于接收上一个实体发送的非阻塞同步通信模式下的第一请求消息。第一请求消息用于发起实体Originator向目标资源所在的托管通用服务实体Hosting CSE请求对目标资源进行操作。
第一生成单元1702用于当针对第一请求消息不创建请求＜request＞资源时，生成请求资源创建者Request Resource Creator参数。其中，Request Resource Creator参数设置为缺省值或上一个针对第一请求消息创建请求＜request＞资源的实体的标识符。
第二生成单元1703用于用于生成第二请求消息，所述第二请求消息包括所述Request Resource Creator参数。
第一发送单元1704用于向下一个实体发送第二请求消息。
本发明实施例的oneM2M系统使用非阻塞同步通信模式进行通信时，在接收上一个实体发送的请求消息之后，通过不创建＜request＞资源的实体生成Request Resource Creator参数，然后向下一个实体发送包括Request Resource Creator参数的请求消息，以使得本地实体＜request＞资源创建失败时仍然可以继续进行通信。
可选地，作为一个实施例，装置还包括第二接收单元和第二发送单元。 第二接收单元用于接收下一个实体发送的第一回复消息。第一回复消息包括下一个针对第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息。第二发送单元用于向上一个实体发送第一回复消息。
可选地，作为一个实施例，装置170还包括第三接收单元和第三发送单元。第三接收单元用于接收上一个实体发送的第一获取请求消息。第一获取请求消息包括下一个针对第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息。第一获取请求消息用于向下一个创建＜request＞资源的实体请求获取对目标资源的处理结果。第三发送单元用于向下一个实体发送第一获取请求消息。
可选地，作为一个实施例，装置170还包括第四接收单元和第四发送单元。第四接收单元用于接收下一个实体发送的第二回复消息。第二回复消息包括对目标资源的处理结果。第四发送单元用于向上一个实体发送第二回复消息。
可选地，作为一个实施例，装置170还包括确定单元。确定单元用于确定是否针对第一请求消息创建＜request＞资源。
可选地，作为一个实施例，确定单元具体用于根据容量和/或支持的＜request＞资源类型确定是否针对第一请求消息创建＜request＞资源。
可选地，作为一个实施例，装置170还包括创建单元、第五发送单元、第三生成单元和第六发送单元。创建单元用于当确定针对所述第一请求消息创建＜request＞资源时，创建＜request＞资源。第五发送单元用于向上一个实体发送第三回复消息。第三回复消息包括创建的＜request＞资源的地址信息。第三生成单元用于生成第三请求消息。第三请求消息包括Request Resource Creator参数。将Request Resource Creator参数设置为中转CSE的标识符。第六发送单元用于向下一个实体发送第三请求消息。
可选地，作为一个实施例，装置170还包括第五接收单元、更新单元、第六接收单元和第七发送单元。第五接收单元用于接收下一个实体发送的第四回复消息。第四回复消息包括对目标资源的处理结果。更新单元用于根据第四回复消息更新中转CSE创建的所述＜request＞资源。第六接收单元用于接收上一个实体发送的第二获取请求消息。第二获取请求消息包括创建的＜request＞资源的地址信息。第二获取请求消息用于上一个实体向中转CSE请求获取所述对目标资源的处理结果。第七发送单元用于向上一个实体发送第 五回复消息。第五回复消息包括对目标资源的处理结果。根据本发明实施例的M2M系统中通信的装置可对应于本发明实施例的M2M系统中通信的方法，并且，装置中的各个单元/模块和上述其他操作和/或功能分别为了实现图3中所示方法中相关CSE的相应流程，为了简洁，在此不再赘述。
实施例十七：
图18是本发明另一实施例的oneM2M系统中通信的装置的示意性框图。图18的装置180包括接收单元1801和发送单元1802。
第一接收单元1801用于接收上一个实体发送的非阻塞同步通信模式下的第一请求消息。第一请求消息携带的响应类型RT参数包括请求资源指示字段。请求资源指示字段为缺省值或上一个针对第一请求消息创建请求＜request＞资源的实体的标识符。第一请求消息用于发起实体Originator向目标资源所在的托管通用服务实体Hosting CSE请求对目标资源进行操作。
第一发送单元1802用于当针对第一请求消息不创建请求＜request＞资源时，向下一个实体发送第一请求消息。
本发明实施例的oneM2M系统使用非阻塞同步通信模式进行通信时，在接收上一个实体发送的请求对目标资源进行操作的请求消息之后，利用RT参数中增加的请求资源指示字段来指示上一个创建＜request＞资源的实体的标识符，以使得不创建＜request＞资源的实体向下一个实体发送请求消息，这样，在＜request＞资源创建失败时仍然可以继续进行通信。
可选地，作为一个实施例，装置180还包括第二接收单元和第二发送单元。第二接收单元用于接收下一个实体发送的第一回复消息。第一回复消息包括下一个针对第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息。第二发送单元向所述上一个实体发送所述第一回复消息。
可选地，作为一个实施例，装置180还包括第三接收单元和第三发送单元。第三接收单元用于接收上一个实体发送的第一获取请求消息。第一获取请求消息包括下一个针对第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息。第一获取请求消息用于向下一个创建＜request＞资源的实体请求获取对目标资源的处理结果。第三发送单元用于向下一个实体发送第一获取请求消息。
可选地，作为一个实施例，装置180还包括第四接收单元和第四发送单元。第四接收单元用于接收下一个实体发送的第二回复消息。第二回复消息 包括对目标资源的处理结果。第四发送单元用于向上一个实体发送第二回复消息。
可选地，作为一个实施例，装置180还包括确定单元。确定单元用于确定是否针对第一请求消息创建＜request＞资源。
可选地，作为一个实施例，确定单元具体用于根据容量和/或支持的＜request＞资源类型确定是否针对第一请求消息创建＜request＞资源。
可选地，作为一个实施例，装置180还包括创建单元、第五发送单元、生成单元和第六发送单元。创建单元用于当确定针对所述第一请求消息创建＜request＞资源时，创建＜request＞资源。第五发送单元用于向上一个实体发送第三回复消息。第三回复消息包括创建的＜request＞资源的地址信息。生成单元用于生成第二请求消息。第二请求消息包括请求资源指示字段。将请求资源指示字段设置为中转CSE的标识符。第六发送单元用于向下一个实体发送第二请求消息。
可选地，作为一个实施例，装置180还包括第五接收单元、更新单元、第六接收单元和第七发送单元。第五接收单元用于接收下一个实体发送的第四回复消息。第四回复消息包括对目标资源的处理结果。更新单元用于根据第四回复消息更新中转CSE创建的所述＜request＞资源。第六接收单元用于接收上一个实体发送的第二获取请求消息。第二获取请求消息包括创建的＜request＞资源的地址信息。第二获取请求消息用于上一个实体向中转CSE请求获取所述对目标资源的处理结果。第七发送单元用于向上一个实体发送第五回复消息。第五回复消息包括对目标资源的处理结果。
根据本发明实施例的M2M系统中通信的装置可对应于本发明实施例的M2M系统中通信的方法，并且，装置中的各个单元/模块和上述其他操作和/或功能分别为了实现图4中所示方法的相应流程和图13所示的方法中相关CSE的相应流程，为了简洁，在此不再赘述。
实施例十八：
图19是本发明另一实施例的oneM2M系统中通信的装置的示意性框图。图19的装置190包括接收单元1901和发送单元1902。
接收单元1901用于接收上一个实体发送的非阻塞同步通信模式下的请求消息。第一请求消息用于发起实体Originator向目标资源所在的托管通用服务实体Hosting CSE请求对目标资源进行操作。
发送单元1902用于当针对第一接收单元接收的请求消息不创建＜request＞资源时，向上一个实体发送指示消息。指示消息包括请求资源不创建Request Not Create参数。Request Not Create参数包括下一个实体的标识符。指示消息用于指示上一个实体向下一个实体发送请求消息。
本发明实施例的oneM2M系统使用非阻塞同步通信模式进行通信时，中转CSE在接收上一个实体发送的请求对目标资源进行操作的请求消息之后，增加新的Request Not Create参数用于指示不创建＜request＞资源的实体向其他实体发送请求消息，以在＜request＞资源创建失败时仍然可以继续进行通信。
可选地，作为一个实施例，装置还包括确定单元。确定单元用于确定是否针对请求消息创建＜request＞资源。
可选地，作为一个实施例，确定单元具体用于根据容量和/或支持的＜request＞资源类型确定是否针对请求消息创建＜request＞资源。
根据本发明实施例的M2M系统中通信的装置可对应于本发明实施例的M2M系统中通信的方法，并且，装置中的各个单元/模块和上述其他操作和/或功能分别为了实现图5中所示方法和图14所示的方法中相关中转CSE的相应流程，为了简洁，在此不再赘述。
实施例十九：
图20是本发明再一实施例的oneM2M系统中通信的装置的示意性框图。图20的装置200包括第一发送单元2001、接收单元2002和第二发送单元2003。
第一发送单元2001用于向下一个实体发送非阻塞同步通信模式下的请求消息，所述请求消息用于发起实体Originator向目标资源所在的托管通用服务实体Hosting CSE请求对目标资源进行操作。
第一接收单元2002用于接收下一个实体发送的指示消息。指示消息包括请求资源不创建Request Not Create参数。Request Not Create参数包括第一实体的标识符。指示消息用于指示本地实体向第一实体发送请求消息。
第二发送单元2003用于向第一实体发送请求消息。
请求消息可以包括发Originator的标识符和目标资源所在的Hosting CSE的标识符。请求消息用于Originator向Hosting CSE请求对目标资源进行操作。
指示消息可以包括Hosting CSE的标识符、中转CSE的标识符和请求资源不创建Request Not Create参数。中转CSE重新发送请求消息的时间位于请求资源不创建Request Not Create参数。
本发明实施例的oneM2M系统使用非阻塞同步通信模式进行通信时，中转CSE在接收上一个实体发送的请求对目标资源进行操作的请求消息之后，上一个实体通过增加新的Request Not Create参数用于指示不创建＜request＞资源的实体向其他实体发送请求消息，以在＜request＞资源创建失败时仍然可以继续进行通信。
可选地，作为一个实施例，装置200还包括：第二发送单元用于向Hosting CSE重新发送请求消息。第二接收单元用于接收Hosting CSE发送的回复消息。回复消息包括Hosting CSE的标识符、Originator的标识符和对目标资源的处理结果。
根据本发明实施例的oneM2M系统中通信的装置可对应于本发明实施例的oneM2M系统中通信的方法，并且，装置中的各个单元/模块和上述其他操作和/或功能分别为了实现图6中所示方法和图14所示的方法中相关中转CSE的的相应流程，为了简洁，在此不再赘述。
实施例二十：
图21是本发明再一实施例的oneM2M系统中通信的装置的示意性框图。图21的装置210包括第一接收单元2101和第一发送单元2102。
第一接收单元2101用于接收中转CSE发送的非阻塞同步通信模式下的请求消息。请求消息用于Originator请求对目标资源进行操作。
第一发送单元2102用于当针对单元接收的请求消息不创建请求＜request＞资源时，根据请求消息向中转CSE发送指示信息。指示信息用于指示中转CSE在第一时长之后重新发送请求消息。
本发明实施例的oneM2M系统使用非阻塞同步通信模式进行通信时，Hosting CSE在接收上一个实体发送的请求对目标资源进行操作的请求消息之后，通过向上一个实体发送指示消息，以指示上一个实体一段时间之后重新发送请求消息，这样使得＜request＞资源创建失败时仍然可以继续进行通信。
可选地，作为一个实施例，装置210还包括处理单元。处理单元用于根据请求消息对目标资源进行处理，得到对目标资源的处理结果。
可选地，作为一个实施例，装置210还包括第二接收单元和第二发送单元。第二接收单元用于接收中转CSE重新发送的请求消息。第二发送单元用于向中转CSE发送回复消息。回复消息包括对目标资源的处理结果。
可选地，作为一个实施例，第一时长大于处理目标资源所需的时长。
可选地，作为一个实施例，装置60还包括第三发送单元或者还包括丢弃单元和第三接收单元。第三发送单元用于在第一时长之后未完成对目标资源的处理时，向中转CSE重新发送指示消息。或者，丢弃单元用于在第二时长之后未收到中转CSE发送的请求消息时，丢弃对目标资源的处理结果。第三接收单元用于在第三时长之后，接收中转CSE再次发送的请求消息。
根据本发明实施例的oneM2M系统中通信的装置可对应于本发明实施例的oneM2M系统中通信的方法，并且，装置中的各个单元/模块和上述其他操作和/或功能分别为了实现图7中所示方法和图15所示的方法中相关Hosting CSE的的相应流程，为了简洁，在此不再赘述。
实施例二十一：
图22是本发明再一实施例的oneM2M系统中通信的装置的示意性框图。图22的装置220包括第一发送单元2201和第一接收单元2202。
第一发送单元2201用于向托管Hosting CSE发送非阻塞同步通信模式下的请求消息。请求消息用于Originator向Hosting CSE请求对目标资源进行操作。
第一接收单元2202用于接收Hosting CSE根据请求消息发送的指示信息。指示消息用于指示中转CSE第一时长之后重新发送请求消息。
本发明实施例的oneM2M系统使用非阻塞同步通信模式进行通信时，在向下一个实体发送请求对目标资源进行操作的请求消息之后，通过接收下一个实体发送的指示消息，以指示本地实体一段时间之后重新发送请求消息，这样使得＜request＞资源创建失败时仍然可以继续进行通信。
可选地，作为一个实施例，装置220还包括第二发送单元和第二接收单元。第二发送单元用于向Hosting CSE重新发送请求消息。第二接收单元用于接收Hosting CSE发送的回复消息。回复消息包括对目标资源的处理结果。
可选地，作为一个实施例，第一时长大于处理目标资源所需的时长。
可选地，作为一个实施例，装置220还包括第三接收单元和第三发送单元。第三接收单元用于在第一时长之后，接收Hosting CSE重新发送的指示 消息。或者，第三发送单元用于在第三时长之后，向Hosting CSE再次发送请求消息。
根据本发明实施例的M2M系统中通信的装置可对应于本发明实施例的M2M系统中通信的方法，并且，装置中的各个单元/模块和上述其他操作和/或功能分别为了实现图8中所示方法的相应流程和图15所示的方法中相关CSE的相应流程，为了简洁，在此不再赘述。
实施例二十二：
图23是本发明实施例的oneM2M系统中通信的装置的示意性框图。图23的装置230包括发射机2301、接收机2302、处理器2303和存储器2304。装置230的各个组件通过总线系统2305耦合在一起。
实施例一的中转CSE的示意性框图可以如图23的框图。
具体地，接收机2302可以接收上一个实体发送的非阻塞同步通信模式下的第一请求消息。第一请求消息包括请求资源创建者Request Resource Creator参数。第一请求消息用于发起实体Originator向目标资源所在的托管通用服务实体Hosting CSE请求对所述目标资源进行操作。Request Resource Creator参数为缺省值或上一个针对第一请求消息创建请求＜request＞资源的实体的标识符。
发射机2301可以用于当针对第一接收单元接收的第一请求消息不创建＜request＞资源时，向下一个实体发送第一请求消息。
本发明实施例的oneM2M系统使用非阻塞同步通信模式进行通信时，在接收上一个实体发送的增加Request Resource Creator参数的请求消息之后，通过不创建＜request＞资源的实体向下一个实体转发该请求消息，以使得本地实体＜request＞资源创建失败时仍然可以继续进行通信。
可选地，作为一个实施例，接收机2302可以用于接收下一个实体发送的第一回复消息。第一回复消息包括下一个针对第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息。发射机2301可以用于向所述上一个实体发送所述第一回复消息。
可选地，作为一个实施例，接收机2302可以用于接收上一个实体发送的第一获取请求消息。第一获取请求消息包括下一个针对第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息。第一获取请求消息用于向下一个创建＜request＞资源的实体请求获取对目标资源的处理结 果。发射机2301可以用于向下一个实体发送第一获取请求消息。
可选地，作为一个实施例，接收机2302可以用于接收下一个实体发送的第二回复消息。第二回复消息包括对目标资源的处理结果。发射机2301可以用于向上一个实体发送第二回复消息。
可选地，作为一个实施例，处理器2303可以用于确定是否针对第一请求消息创建＜request＞资源。
可选地，作为一个实施例，处理器2303具体用于根据容量和/或支持的＜request＞资源类型确定是否针对第一请求消息创建＜request＞资源。
可选地，作为一个实施例，处理器2303用于用于当确定针对所述第一请求消息创建＜request＞资源时，创建＜request＞资源。发射机2301用于向上一个实体发送第三回复消息。第三回复消息包括创建的＜request＞资源的地址信息。处理器2303还用于生成第二请求消息。第二请求消息包括Request Resource Creator参数。Request Resource Creator参数设置为中转CSE的标识符。发射机2302还用于向下一个实体发送第二请求消息。
可选地，作为一个实施例，接收机2302还用于接收下一个实体发送的第四回复消息。第四回复消息包括对目标资源的处理结果。处理器2303还用于根据第四回复消息更新中转CSE创建的所述＜request＞资源。接收机2302还用于接收上一个实体发送的第二获取请求消息。第二获取请求消息包括创建的＜request＞资源的地址信息。第二获取请求消息用于上一个实体向中转CSE请求获取所述对目标资源的处理结果。发射机2301还用于向上一个实体发送第五回复消息。第五回复消息包括对目标资源的处理结果。
中转CSE 230能够实现前述方法实施例图2的有关操作，以及能够实现图9、图10和图11中相关CSE的操作，为避免重复，不再详细描述。
实施例二的中转CSE的示意性框图可以如图23的框图。
具体地，接收机2302用于接收上一个实体发送的非阻塞同步通信模式下的第一请求消息。第一请求消息用于发起实体Originator向目标资源所在的托管通用服务实体Hosting CSE请求对目标资源进行操作。
处理器2303用于当针对第一请求消息不创建请求＜request＞资源时，生成请求资源创建者Request Resource Creator参数。Request Resource Creator参数设置为缺省值或上一个针对第一请求消息创建请求＜request＞资源的实体的标识符。
处理器2303用于根据生成第二请求消息。第二请求消息包括Request Resource Creator参数。
发射机2301用于向下一个实体发送第二请求消息。
本发明实施例的oneM2M系统使用非阻塞同步通信模式进行通信时，在接收上一个实体发送的请求消息之后，通过不创建＜request＞资源的实体生成Request Resource Creator参数，然后向下一个实体发送包括Request Resource Creator参数的请求消息，以使得本地实体＜request＞资源创建失败时仍然可以继续进行通信。
可选地，作为一个实施例，接收机2302可以用于接收下一个实体发送的第一回复消息。第一回复消息包括下一个针对第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息。发射机2301可以用于向所述上一个实体发送所述第一回复消息。
可选地，作为一个实施例，接收机2302可以用于接收上一个实体发送的第一获取请求消息。第一获取请求消息包括下一个针对第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息。第一获取请求消息用于向下一个创建＜request＞资源的实体请求获取对目标资源的处理结果。发射机2301可以用于向下一个实体发送第一获取请求消息。
可选地，作为一个实施例，接收机2302可以用于接收下一个实体发送的第二回复消息。第二回复消息包括对目标资源的处理结果。发射机2301可以用于向上一个实体发送第二回复消息。
可选地，作为一个实施例，处理器2303可以用于确定是否针对第一请求消息创建＜request＞资源。
可选地，作为一个实施例，处理器2303具体用于根据容量和/或支持的＜request＞资源类型确定是否针对第一请求消息创建＜request＞资源。
可选地，作为一个实施例，处理器2303用于用于当确定针对所述第一请求消息创建＜request＞资源时，创建＜request＞资源。发射机2301用于向上一个实体发送第三回复消息。第三回复消息包括创建的＜request＞资源的地址信息。处理器2303还用于生成第三请求消息。第三请求消息包括Request Resource Creator参数。Request Resource Creator参数设置为中转CSE的标识符。发射机2302还用于向下一个实体发送第三请求消息。
可选地，作为一个实施例，接收机2402还用于接收下一个实体发送的 第四回复消息。第四回复消息包括对目标资源的处理结果。处理器2303还用于根据第四回复消息更新中转CSE创建的所述＜request＞资源。接收机2302还用于接收上一个实体发送的第二获取请求消息。第二获取请求消息包括创建的＜request＞资源的地址信息。第二获取请求消息用于上一个实体向中转CSE请求获取所述对目标资源的处理结果。发射机2301还用于向上一个实体发送第五回复消息。第五回复消息包括对目标资源的处理结果。
实施例三的的中转CSE的示意性框图可以如图23的框图。
具体地，接收机2302可以用于接收上一个实体发送的非阻塞同步通信模式下的第一请求消息.第一请求消息包括携带的响应类型RT参数包括请求资源指示字段。第一请求消息用于发起实体Originator向目标资源所在的托管通用服务实体Hosting CSE请求对目标资源进行操作。请求资源指示字段为缺省值或上一个针对第一请求消息创建请求＜request＞资源的实体的标识符。
发射机2301可以用于当针对所述第一请求消息不创建请求＜request＞资源时，向下一个实体发送接收机2302接收的第一请求消息。
本发明实施例的oneM2M系统使用非阻塞同步通信模式进行通信时，在接收上一个实体发送的请求对目标资源进行操作的请求消息之后，利用RT参数中增加的请求资源指示字段来指示上一个创建＜request＞资源的实体的标识符，以使得不创建＜request＞资源的实体向下一个实体发送请求消息，这样，在＜request＞资源创建失败时仍然可以继续进行通信。
可选地，作为一个实施例，接收机2302可以用于接收下一个实体发送的第一回复消息。第一回复消息包括下一个针对第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息。发射机2301可以用于向所述上一个实体发送所述第一回复消息。
可选地，作为一个实施例，接收机2302可以用于接收上一个实体发送的第一获取请求消息。第一获取请求消息包括下一个针对第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息。第一获取请求消息用于向下一个创建＜request＞资源的实体请求获取对目标资源的处理结果。发射机2501可以用于向下一个实体发送第一获取请求消息。
可选地，作为一个实施例，接收机2302可以用于接收下一个实体发送的第二回复消息。第二回复消息包括对目标资源的处理结果。发射机2301 可以用于向上一个实体发送第二回复消息。
可选地，作为一个实施例，处理器2303可以用于确定是否针对第一请求消息创建＜request＞资源。
可选地，作为一个实施例，处理器2303具体用于根据容量和/或支持的＜request＞资源类型确定是否针对第一请求消息创建＜request＞资源。
可选地，作为一个实施例，处理器2303用于用于当确定针对所述第一请求消息创建＜request＞资源时，创建＜request＞资源。发射机2301用于向上一个实体发送第三回复消息。第三回复消息包括创建的＜request＞资源的地址信息。处理器2503还用于生成第二请求消息。第二请求消息包括请求资源指示字段。请求资源指示字段设置为中转CSE的标识符。发射机2302还用于向下一个实体发送第二请求消息。
可选地，作为一个实施例，接收机2302还用于接收下一个实体发送的第四回复消息。第四回复消息包括对目标资源的处理结果。处理器2303还用于根据第四回复消息更新中转CSE创建的所述＜request＞资源。接收机2302还用于接收上一个实体发送的第二获取请求消息。第二获取请求消息包括创建的＜request＞资源的地址信息。第二获取请求消息用于上一个实体向中转CSE请求获取所述对目标资源的处理结果。发射机2301还用于向上一个实体发送第五回复消息。第五回复消息包括对目标资源的处理结果。
实施例四的中转CSE的示意性框图可以如图23的框图。
具体地，接收机2302可以接收上一个实体发送的非阻塞同步通信模式下的请求消息。第一请求消息用于发起实体Originator向目标资源所在的托管通用服务实体Hosting CSE请求对目标资源进行操作。
发射机2301可以用于当针对第一接收单元接收的请求消息不创建＜request＞资源时，向上一个实体发送指示消息。指示消息包括请求资源不创建Request Not Create。参数Request Not Create参数包括下一个实体的标识符。指示消息用于指示上一个实体向下一个实体发送请求消息。
本发明实施例的oneM2M系统使用非阻塞同步通信模式进行通信时，中转CSE在接收上一个实体发送的请求对目标资源进行操作的请求消息之后，增加新的Request Not Create参数用于指示不创建＜request＞资源的实体向其他实体发送请求消息，以在＜request＞资源创建失败时仍然可以继续进行通信。
可选地，作为一个实施例，处理器2303可以用于确定是否针对请求消息创建＜request＞资源。
可选地，作为一个实施例，处理器2303具体用于根据容量和/或支持的＜request＞资源类型确定是否针对请求消息创建＜request＞资源。
实施例五的中转CSE的示意性框图可以如图23的框图。
具体地，发射机2301可以用于向下一个实体发送非阻塞同步通信模式下的请求消息。请求消息用于发起实体Originator向目标资源所在的托管通用服务实体Hosting CSE请求对目标资源进行操作.
接收机2302用于接收下一个实体发送的指示消息。指示消息包括请求资源不创建Request Not Create参数。Request Not Create参数包括第一实体的标识符。指示消息用于指示本地实体向第一实体发送请求消息。
发射机2301还用于向第一实体发送请求消息。
本发明实施例的oneM2M系统使用非阻塞同步通信模式进行通信时，中转CSE在接收上一个实体发送的请求对目标资源进行操作的请求消息之后，上一个实体通过增加新的Request Not Create参数用于指示不创建＜request＞资源的实体向其他实体发送请求消息，以在＜request＞资源创建失败时仍然可以继续进行通信。
实施例六的中转CSE的示意性框图可以如图23的框图。
具体地，接收机2802用于接收中转CSE发送的非阻塞同步通信模式下的请求消息。请求消息用于Originator请求对目标资源进行操作。
发射机2301用于当针对接收单元接收的请求消息不创建请求＜request＞资源时，根据请求消息向中转CSE发送指示信息。指示信息用于指示中转CSE在第一时长之后重新发送请求消息。
本发明实施例的oneM2M系统使用非阻塞同步通信模式进行通信时，Hosting CSE在接收上一个实体发送的请求对目标资源进行操作的请求消息之后，通过向上一个实体发送指示消息，以指示上一个实体一段时间之后重新发送请求消息，这样使得＜request＞资源创建失败时仍然可以继续进行通信。
可选地，作为一个实施例，处理器2303用于根据请求消息对目标资源进行处理，得到对目标资源的处理结果。
可选地，作为一个实施例，接收机2302用于接收中转CSE重新发送的 请求消息。发射机2301用于向中转CSE发送回复消息。回复消息包括对目标资源的处理结果。
可选地，作为一个实施例，第一时长大于处理目标资源所需的时长。
可选地，作为一个实施例，发射机2301用于在第一时长之后未完成对目标资源的处理时，向中转CSE重新发送指示消息。或者，处理器2303用于在第二时长之后未收到中转CSE发送的请求消息时，丢弃对目标资源的处理结果。接收机2302用于在第三时长之后，接收中转CSE再次发送的请求消息。
用于在第一时长之后未收到中转CSE发送的请求消息或未完成对目标资源的处理时，向中转CSE重新发送指示消息。
实施例七的中转CSE的示意性框图可以如图23的框图。
具体地，发射机2301可以用于向托管Hosting CSE发送非阻塞同步通信模式下的请求消息。请求消息用于Originator向Hosting CSE请求对目标资源进行操作。
接收机2302用于接收Hosting CSE根据请求消息发送的指示信息。指示消息用于指示中转CSE第一时长之后重新发送请求消息。
本发明实施例的oneM2M系统使用非阻塞同步通信模式进行通信时，在向下一个实体发送请求对目标资源进行操作的请求消息之后，通过接收下一个实体发送的指示消息，以指示本地实体一段时间之后重新发送请求消息，这样使得＜request＞资源创建失败时仍然可以继续进行通信。
可选地，作为一个实施例，发射机2301用于向Hosting CSE重新发送请求消息。接收机2302用于接收Hosting CSE发送的回复消息。回复消息包括对目标资源的处理结果。
可选地，作为一个实施例，第一时长大于处理目标资源所需的时长。
可选地，作为一个实施例，接收机2302用于在第一时长之后，接收Hosting CSE重新发送的指示消息。或者，发射机2301用于在第三时长之后，向Hosting CSE再次发送请求消息。
处理器控制装置的操作，并可用于处理信号。存储器可以包括只读存储器和随机存取存储器，并向处理器提供指令和数据。发射机和接收机可以耦合到天线。装置的各个组件通过总线系统耦合在一起，其中总线系统除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚 说明起见，在图中将各种总线都标为总线系统。
上述本发明实施例揭示的方法可以应用于处理器中，或者由处理器实现。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。处理器可以是通用处理器、数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本发明实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。
应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本发明的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。
应理解，在本发明的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。
应理解，在本发明实施例中，“与A相应的B”表示B与A相关联，根据A可以确定B。但还应理解，根据A确定B并不意味着仅仅根据A确定B，还可以根据A和/或其它信息确定B。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间 的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (74)

  1. 一种统一机器到机器oneM2M系统中通信的方法，其特征在于，包括：
    接收上一个实体发送的非阻塞同步通信模式下的第一请求消息，所述第一请求消息包括请求资源创建者Request Resource Creator参数，所述Request Resource Creator参数为缺省值或上一个针对所述第一请求消息创建请求＜request＞资源的实体的标识符，所述第一请求消息用于发起实体Originator向目标资源所在的托管通用服务实体Hosting CSE请求对所述目标资源进行操作；
    当针对所述第一请求消息不创建请求＜request＞资源时，向下一个实体发送所述第一请求消息。
  2. 如权利要求1所述的方法，其特征在于，所述方法还包括：
    接收所述下一个实体发送的第一回复消息，所述第一回复消息包括下一个针对所述第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息；
    向所述上一个实体发送所述第一回复消息。
  3. 如权利要求2所述的方法，其特征在于，所述方法还包括：
    接收所述上一个实体发送的第一获取请求消息，所述第一获取请求消息包括所述下一个针对所述第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息，所述第一获取请求消息用于向所述下一个创建＜request＞资源的实体请求获取对所述目标资源的处理结果；
    向所述下一个实体发送所述第一获取请求消息。
  4. 如权利要求3所述的方法，其特征在于，所述方法还包括：
    接收所述下一个实体发送的第二回复消息，所述第二回复消息包括所述对目标资源的处理结果；
    向所述上一个实体发送所述第二回复消息。
  5. 如权利要求1至4中任一项所述的方法，其特征在于，在所述向下一个实体发送所述第一请求消息之前，所述方法还包括：
    确定是否针对所述第一请求消息创建＜request＞资源。
  6. 如权利要求5所述的方法，其特征在于，所述确定是否针对所述第 一请求消息创建＜request＞资源包括：
    根据容量和/或支持的＜request＞资源类型确定是否针对所述第一请求消息创建＜request＞资源。
  7. 如权利要求5或6所述的方法，其特征在于，所述方法由中转CSE执行，所述方法还包括：
    当确定针对所述第一请求消息创建＜request＞资源时，创建＜request＞资源；
    向所述上一个实体发送第三回复消息，所述第三回复消息包括创建的＜request＞资源的地址信息；
    生成第二请求消息，所述第二请求消息包括所述Request Resource Creator参数，所述Request Resource Creator参数设置为所述中转CSE的标识符；
    向所述下一个实体发送所述第二请求消息。
  8. 如权利要求7所述的方法，其特征在于，所述方法还包括：
    接收所述下一个实体发送的第四回复消息，所述第四回复消息包括对所述目标资源的处理结果；
    根据所述第四回复消息更新所述中转CSE创建的＜request＞资源；
    接收所述上一个实体发送的第二获取请求消息，所述第二获取请求消息包括所述中转CSE创建的＜request＞资源的地址信息，所述第二获取请求消息用于所述上一个实体向所述中转CSE请求获取所述对所述目标资源的处理结果；
    向所述上一个实体发送第五回复消息，所述第五回复消息包括所述对所述目标资源的处理结果。
  9. 一种统一机器到机器oneM2M系统中通信的方法，其特征在于，包括：
    接收上一个实体发送的非阻塞同步通信模式下的第一请求消息，所述第一请求消息用于发起实体Originator向目标资源所在的托管通用服务实体Hosting CSE请求对所述目标资源进行操作；
    当针对所述第一请求消息不创建请求＜request＞资源时，生成请求资源创建者Request Resource Creator参数，所述Request Resource Creator参数设置为缺省值或上一个针对所述第一请求消息创建请求＜request＞资源的实 体的标识符；
    生成第二请求消息，所述第二请求消息包括所述Request Resource Creator参数；
    向下一个实体发送所述第二请求消息。
  10. 如权利要求9所述的方法，其特征在于，所述方法还包括：
    接收所述下一个实体发送的第一回复消息，所述第一回复消息包括下一个针对所述第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息；
    向所述上一个实体发送所述第一回复消息。
  11. 如权利要求10所述的方法，其特征在于，所述方法还包括：
    接收所述上一个实体发送的第一获取请求消息，所述第一获取请求消息包括所述下一个针对所述第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息，所述第一获取请求消息用于向所述下一个创建＜request＞资源的实体请求获取对所述目标资源的处理结果；
    向所述下一个实体发送所述第一获取请求消息。
  12. 如权利要求11所述的方法，其特征在于，所述方法还包括：
    接收所述下一个实体发送的第二回复消息，所述第二回复消息包括所述对目标资源的处理结果；
    向所述上一个实体发送所述第二回复消息。
  13. 如权利要求9至12中任一项所述的方法，其特征在于，在所述向下一个实体发送所述第一请求消息之前，所述方法还包括：
    确定是否针对所述第一请求消息创建＜request＞资源。
  14. 如权利要求13所述的方法，其特征在于，所述确定是否针对所述第一请求消息创建＜request＞资源包括：
    根据容量和/或支持的＜request＞资源类型确定是否针对所述第一请求消息创建＜request＞资源。
  15. 如权利要求13或14所述的方法，其特征在于，所述方法由中转CSE执行，所述方法还包括：
    当确定针对所述第一请求消息创建＜request＞资源时，创建＜request＞资源；
    向所述上一个实体发送第三回复消息，所述第三回复消息包括创建的＜ request＞资源的地址信息；
    生成第三请求消息，所述第三请求消息包括所述Request Resource Creator参数，所述Request Resource Creator参数设置为所述中转CSE的标识符；
    向所述下一个实体发送所述第三请求消息。
  16. 如权利要求15所述的方法，其特征在于，所述方法还包括：
    接收所述下一个实体发送的第四回复消息，所述第四回复消息包括对所述目标资源的处理结果；
    根据所述第四回复消息更新所述中转CSE创建的＜request＞资源；
    接收所述上一个实体发送的第二获取请求消息，所述第二获取请求消息包括所述中转CSE创建的＜request＞资源的地址信息，所述第二获取请求消息用于所述上一个实体向所述中转CSE请求获取所述对所述目标资源的处理结果；
    向所述上一个实体发送第五回复消息，所述第五回复消息包括所述对所述目标资源的处理结果。
  17. 一种统一机器到机器oneM2M系统中通信的方法，其特征在于，包括：
    接收上一个实体发送的非阻塞同步通信模式下的第一请求消息，所述第一请求消息携带的响应类型RT参数包括请求资源指示字段，所述第一请求消息用于发起实体Originator向目标资源所在的托管通用服务实体HostingCSE请求对所述目标资源进行操作，所述请求资源指示字段为缺省值或上一个针对所述第一请求消息创建请求＜request＞资源的实体的标识符；
    当针对所述第一请求消息不创建请求＜request＞资源时，向下一个实体发送所述第一请求消息。
  18. 如权利要求17所述的方法，其特征在于，所述方法还包括：
    接收所述下一个实体发送的第一回复消息，所述第一回复消息包括下一个针对所述第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息；
    向所述上一个实体发送所述第一回复消息。
  19. 如权利要求18所述的方法，其特征在于，所述方法还包括：
    接收所述上一个实体发送的第一获取请求消息，所述第一获取请求消息 包括所述下一个针对所述第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息，所述第一获取请求消息用于向所述下一个创建＜request＞资源的实体请求获取对所述目标资源的处理结果；
    向所述下一个实体发送所述第一获取请求消息。
  20. 如权利要求19所述的方法，其特征在于，所述方法还包括：
    接收所述下一个实体发送的第二回复消息，所述第二回复消息包括所述对目标资源的处理结果；
    向所述上一个实体发送所述第二回复消息。
  21. 如权利要求17至20中任一项所述的方法，其特征在于，在所述向下一个实体发送所述第一请求消息之前，所述方法还包括：
    确定是否针对所述第一请求消息创建＜request＞资源。
  22. 如权利要求21所述的方法，其特征在于，所述确定是否针对所述第一请求消息创建＜request＞资源包括：
    根据容量和/或支持的＜request＞资源类型确定是否针对所述第一请求消息创建＜request＞资源。
  23. 如权利要求21或22所述的方法，其特征在于，所述方法由中转CSE执行，所述方法还包括：
    当确定针对所述第一请求消息创建＜request＞资源时，创建＜request＞资源；
    向所述上一个实体发送第三回复消息，所述第三回复消息包括创建的＜request＞资源的地址信息；
    生成第二请求消息，所述第二请求消息包括所述请求资源指示字段，所述请求资源指示字段设置为所述中转CSE的标识符；
    向所述下一个实体发送所述第二请求消息。
  24. 如权利要求23所述的方法，其特征在于，所述方法还包括：
    接收所述下一个实体发送的第四回复消息，所述第四回复消息包括对所述目标资源的处理结果；
    根据所述第四回复消息更新所述中转CSE创建的＜request＞资源；
    接收所述上一个实体发送的第二获取请求消息，所述第二获取请求消息包括所述中转CSE创建的＜request＞资源的地址信息，所述第二获取请求消息用于所述上一个实体向所述中转CSE请求获取所述对所述目标资源的处 理结果；
    向所述上一个实体发送第五回复消息，所述第五回复消息包括所述对所述目标资源的处理结果。
  25. 一种统一机器到机器oneM2M系统中通信的方法，其特征在于，包括：
    接收上一个实体发送的非阻塞同步通信模式下的请求消息，所述请求消息用于发起实体Originator向目标资源所在的托管通用服务实体Hosting CSE请求对所述目标资源进行操作；
    当针对所述第一请求消息不创建＜request＞资源时，向所述上一个实体发送指示消息，所述指示消息包括请求资源不创建Request Not Create参数，所述Request Not Create参数包括下一个实体的标识符，所述指示消息用于指示所述上一个实体向所述下一个实体发送所述第一请求消息。
  26. 如权利要求25所述的方法，其特征在于，所述方法还包括：
    确定是否针对所述请求消息创建＜request＞资源。
  27. 如权利要求26所述的方法，其特征在于，所述确定是否针对所述请求消息创建＜request＞资源包括：
    根据容量和/或支持的＜request＞资源类型确定是否针对所述请求消息创建＜request＞资源。
  28. 一种统一机器到机器oneM2M系统中通信的方法，其特征在于，包括：
    向下一个实体发送非阻塞同步通信模式下的请求消息，所述请求消息用于发起实体Originator向目标资源所在的托管通用服务实体Hosting CSE请求对所述目标资源进行操作；
    接收所述下一个实体发送的指示消息，所述指示消息包括请求资源不创建Request Not Create参数，所述Request Not Create参数包括第一实体的标识符，所述指示消息用于指示本地实体向所述第一实体发送所述请求消息；
    向所述第一实体发送所述请求消息。
  29. 一种统一机器到机器oneM2M系统中的通信的方法，其特征在于，包括：
    接收中转通用服务实体CSE发送的非阻塞同步通信模式下的请求消息，所述请求消息用于发起实体Originator请求对目标资源进行操作；
    当针对所述请求消息不创建请求＜request＞资源时，根据所述请求消息向所述中转CSE发送指示信息，所述指示信息用于指示所述中转CSE在第一时长之后重新发送所述请求消息。
  30. 如权利要求29所述的方法，其特征在于，所述方法还包括：
    根据所述请求消息对所述目标资源进行处理，得到所述对目标资源的处理结果。
  31. 如权利要求29或30所述的方法，其特征在于，所述方法还包括：
    接收所述中转CSE重新发送的所述请求消息；
    向所述中转CSE发送回复消息，所述回复消息包括所述对目标资源的处理结果。
  32. 如权利要求29至31中任一项所述的方法，其特征在于，所述第一时长大于处理所述目标资源所需的时长。
  33. 如权利要求29至32中任一项所述的方法，其特征在于，所述方法还包括：
    在第一时长之后未完成对所述目标资源的处理时，向所述中转CSE重新发送所述指示消息；或者，
    在第二时长之后未收到所述中转CSE发送的请求消息时，丢弃对所述目标资源的处理结果；
    在第三时长之后，接收中转CSE再次发送的请求消息。
  34. 一种统一机器到机器oneM2M系统中的通信的方法，其特征在于，包括：
    向托管Hosting CSE发送非阻塞同步通信模式下的请求消息，所述请求消息用于发起实体Originator向所述Hosting CSE请求对目标资源进行操作；
    接收所述Hosting CSE根据所述请求消息发送的指示信息，所述指示消息用于指示第一时长之后重新发送所述请求消息。
  35. 如权利要求34所述的方法，其特征在于，所述方法还包括：
    向所述Hosting CSE重新发送所述请求消息；
    接收所述Hosting CSE发送的回复消息，所述回复消息包括所述对目标资源的处理结果。
  36. 如权利要求34或35所述的方法，其特征在于，所述第一时长大于处理所述目标资源所需的时长。
  37. 如权利要求34至36中任一项所述的方法，其特征在于，所述方法还包括：
    在第一时长之后，接收所述Hosting CSE重新发送的指示消息；或者，
    在第三时长之后，向所述Hosting CSE再次发送所述请求消息。
  38. 一种统一机器到机器oneM2M系统中通信的装置，其特征在于，包括：
    第一接收单元，用于接收上一个实体发送的非阻塞同步通信模式下的第一请求消息，所述第一请求消息包括请求资源创建者Request Resource Creator参数，所述Request Resource Creator参数为缺省值或上一个针对所述第一请求消息创建请求＜request＞资源的实体的标识符，所述第一请求消息用于发起实体Originator向目标资源所在的托管通用服务实体Hosting CSE请求对所述目标资源进行操作；
    第一发送单元，用于当针对所述第一接收单元接收的所述第一请求消息不创建＜request＞资源时，向下一个实体发送所述第一请求消息。
  39. 如权利要求38所述的装置，其特征在于，所述装置还包括：
    第二接收单元，用于接收所述下一个实体发送的第一回复消息，所述第一回复消息包括下一个针对所述第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息；
    第二发送单元，向所述上一个实体发送所述第一回复消息。
  40. 如权利要求39所述的装置，其特征在于，所述装置还包括：
    第三接收单元，用于接收所述上一个实体发送的第一获取请求消息，所述第一获取请求消息包括所述下一个针对所述第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息，所述第一获取请求消息用于向所述下一个创建＜request＞资源的实体请求获取所述对目标资源的处理结果；
    第三发送单元，用于向所述下一个实体发送所述第一获取请求消息。
  41. 如权利要求40所述的装置，其特征在于，所述装置还包括：
    第四接收单元，用于接收所述下一个实体发送的第二回复消息，所述第二回复消息包括所述对目标资源的处理结果；
    第四发送单元，用于向所述上一个实体发送所述第二回复消息。
  42. 如权利要求38至41中任一项所述的装置，其特征在于，所述装置 还包括：
    确定单元，用于确定是否针对所述第一请求消息创建＜request＞资源。
  43. 如权利要求42所述的装置，其特征在于，所述确定确定单元具体用于：
    根据容量和/或支持的＜request＞资源类型确定是否针对所述第一请求消息创建＜request＞资源。
  44. 如权利要求42或43所述的装置，其特征在于，所述装置为中转CSE，所述装置还包括：
    创建单元，用于当确定针对所述第一请求消息创建＜request＞资源时，创建＜request＞资源；
    第五发送单元，用于向所述上一个实体发送第三回复消息，所述第三回复消息包括创建的＜request＞资源的地址信息；
    生成单元，用于生成第二请求消息，所述第二请求消息包括所述Request Resource Creator参数，所述Request Resource Creator参数设置为所述中转CSE的标识符；
    第六发送单元，用于向所述下一个实体发送所述第二请求消息。
  45. 如权利要求44所述的装置，其特征在于，所述装置还包括：
    第五接收单元，用于接收所述下一个实体发送的第四回复消息，所述第四回复消息包括所述对目标资源的处理结果；
    更新单元，用于根据所述第四回复消息更新所述中转CSE创建的所述＜request＞资源；
    第六接收单元，用于接收所述上一个实体发送的第二获取请求消息，所述第二获取请求消息包括创建的＜request＞资源的地址信息，所述第二获取请求消息用于所述上一个实体向所述中转CSE请求获取所述对目标资源的处理结果；
    第七发送单元，用于向所述上一个实体发送第五回复消息，所述第五回复消息包括所述对目标资源的处理结果。
  46. 一种统一机器到机器oneM2M系统中通信的装置，其特征在于，包括：
    第一接收单元，用于接收上一个实体发送的非阻塞同步通信模式下的第一请求消息，所述第一请求消息用于发起实体Originator向目标资源所在的 托管通用服务实体Hosting CSE请求对所述目标资源进行操作；
    第一生成单元，用于当针对所述第一请求消息不创建请求＜request＞资源时，生成请求资源创建者Request Resource Creator参数，所述Request Resource Creator参数设置为缺省值或上一个针对所述第一请求消息创建请求＜request＞资源的实体的标识符；
    第二生成单元，用于生成第二请求消息，所述第二请求消息包括所述Request Resource Creator参数；
    第一发送单元，用于向下一个实体发送所述第二请求消息。
  47. 如权利要求46所述的装置，其特征在于，所述装置还包括：
    第二接收单元，用于接收所述下一个实体发送的第一回复消息，所述第一回复消息包括下一个针对所述第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息；
    第二发送单元，用于向所述上一个实体发送所述第一回复消息。
  48. 如权利要求47所述的装置，其特征在于，所述装置还包括：
    第三接收单元，用于接收所述上一个实体发送的第一获取请求消息，所述第一获取请求消息包括所述下一个针对所述第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息，所述第一获取请求消息用于向所述下一个创建＜request＞资源的实体请求获取对所述目标资源的处理结果；
    第三发送单元，用于向所述下一个实体发送所述第一获取请求消息。
  49. 如权利要求48所述的装置，其特征在于，所述装置还包括：
    第四接收单元，用于接收所述下一个实体发送的第二回复消息，所述第二回复消息包括所述对目标资源的处理结果；
    第四发送单元，用于向所述上一个实体发送所述第二回复消息。
  50. 如权利要求46至49中任一项所述的装置，其特征在于，所述装置还包括：
    确定单元，用于确定是否针对所述第一请求消息创建＜request＞资源。
  51. 如权利要求50所述的装置，其特征在于，所述确定单元具体用于根据容量和/或支持的＜request＞资源类型确定是否针对所述第一请求消息创建＜request＞资源。
  52. 如权利要求50或51所述的装置，其特征在于，所述装置为中转 CSE，所述装置还包括：
    创建单元，用于当确定针对所述第一请求消息创建＜request＞资源时，创建＜request＞资源；
    第五发送单元，用于向所述上一个实体发送第三回复消息，所述第三回复消息包括创建的＜request＞资源的地址信息；
    第三生成单元，用于生成第三请求消息，所述第三请求消息包括所述Request Resource Creator参数，所述Request Resource Creator参数设置为所述中转CSE的标识符；
    第六发送单元，用于向所述下一个实体发送所述第三请求消息。
  53. 如权利要求52所述的装置，其特征在于，所述装置还包括：
    第五接收单元，用于接收所述下一个实体发送的第四回复消息，所述第四回复消息包括对所述目标资源的处理结果；
    更新单元，用于根据所述第四回复消息更新所述中转CSE创建的＜request＞资源；
    第六接收单元，用于接收所述上一个实体发送的第二获取请求消息，所述第二获取请求消息包括所述中转CSE创建的＜request＞资源的地址信息，所述第二获取请求消息用于所述上一个实体向所述中转CSE请求获取所述对所述目标资源的处理结果；
    第七发送单元，用于向所述上一个实体发送第五回复消息，所述第五回复消息包括所述对所述目标资源的处理结果。
  54. 一种统一机器到机器oneM2M系统中通信的装置，其特征在于，包括：
    第一接收单元，用于接收上一个实体发送的非阻塞同步通信模式下的第一请求消息，所述第一请求消息携带的响应类型RT参数包括请求资源指示字段，所述第一请求消息用于发起实体Originator向目标资源所在的托管通用服务实体Hosting CSE请求对所述目标资源进行操作，所述请求资源指示字段为缺省值或上一个针对所述第一请求消息创建请求＜request＞资源的实体的标识符；
    第一发送单元，用于当针对所述第一请求消息不创建请求＜request＞资源时，向下一个实体发送所述第一接收单元接收的所述第一请求消息。
  55. 如权利要求54所述的装置，其特征在于，所述装置还包括：
    第二接收单元，用于接收所述下一个实体发送的第一回复消息，所述第一回复消息包括下一个针对所述第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息；
    第二发送单元，用于向所述上一个实体发送所述第一回复消息。
  56. 如权利要求55所述的装置，其特征在于，所述装置还包括：
    第三接收单元，用于接收所述上一个实体发送的第一获取请求消息，所述第一获取请求消息包括所述下一个针对所述第一请求消息创建＜request＞资源的实体创建的＜request＞资源的地址信息，所述第一获取请求消息用于向所述下一个创建＜request＞资源的实体请求获取对所述目标资源的处理结果；
    第三发送单元，用于向所述下一个实体发送所述第一获取请求消息。
  57. 如权利要求56所述的装置，其特征在于，所述装置还包括：
    第四接收单元，用于接收所述下一个实体发送的第二回复消息，所述第二回复消息包括所述对目标资源的处理结果；
    第四发送单元，用于向所述上一个实体发送所述第二回复消息。
  58. 如权利要求54至57中任一项所述的装置，其特征在于，所述装置还包括：
    确定单元，用于确定是否针对所述第一请求消息创建＜request＞资源。
  59. 如权利要求58所述的方法，其特征在于，所述确定单元具体用于根据容量和/或支持的＜request＞资源类型确定是否针对所述第一请求消息创建＜request＞资源。
  60. 如权利要求58或59所述的装置，其特征在于，所述装置为中转CSE执行，所述装置还包括：
    创建单元，用于当确定针对所述第一请求消息创建＜request＞资源时，创建＜request＞资源；
    第五发送单元，用于向所述上一个实体发送第三回复消息，所述第三回复消息包括创建的＜request＞资源的地址信息；
    生成单元，用于生成第二请求消息，所述第二请求消息包括所述请求资源指示字段，所述请求资源指示字段设置为所述中转CSE的标识符；
    第六发送单元，用于向所述下一个实体发送所述第二请求消息。
  61. 如权利要求60所述的装置，其特征在于，所述装置还包括：
    第五接收单元，用于接收所述下一个实体发送的第四回复消息，所述第四回复消息包括对所述目标资源的处理结果；
    更新单元，用于根据所述第四回复消息更新所述中转CSE创建的＜request＞资源；
    第六接收单元，用于接收所述上一个实体发送的第二获取请求消息，所述第二获取请求消息包括所述中转CSE创建的＜request＞资源的地址信息，所述第二获取请求消息用于所述上一个实体向所述中转CSE请求获取所述对所述目标资源的处理结果；
    第七发送单元，用于向所述上一个实体发送第五回复消息，所述第五回复消息包括所述对所述目标资源的处理结果。
  62. 一种统一机器到机器oneM2M系统中通信的装置，其特征在于，包括：
    接收单元，用于接收上一个实体发送的非阻塞同步通信模式下的请求消息，所述第一请求消息用于发起实体Originator向目标资源所在的托管通用服务实体Hosting CSE请求对所述目标资源进行操作；
    发送单元，用于当针对所述第一接收单元结收地所述请求消息不创建＜request＞资源时，向所述上一个实体发送指示消息，所述指示消息包括请求资源不创建Request Not Create参数，所述Request Not Create参数包括下一个实体的标识符，所述指示消息用于指示所述上一个实体向所述下一个实体发送所述请求消息。
  63. 如权利要求61所述的装置，其特征在于，所述装置还包括：
    确定单元，用于确定是否针对所述请求消息创建＜request＞资源。
  64. 如权利要求63所述的装置，其特征在于，所述确定单元具体用于：
    根据容量和/或支持的＜request＞资源类型确定是否针对所述请求消息创建＜request＞资源。
  65. 一种统一机器到机器oneM2M系统中通信的装置，其特征在于，包括：
    第一发送单元，用于向下一个实体发送非阻塞同步通信模式下的请求消息，所述请求消息用于发起实体Originator向目标资源所在的托管通用服务实体Hosting CSE请求对所述目标资源进行操作；
    第一接收单元，用于接收所述下一个实体发送的指示消息，所述指示消 息包括请求资源不创建Request Not Create参数，所述Request Not Create参数包括第一实体的标识符，所述指示消息用于指示本地实体向所述第一实体发送所述请求消息；
    第二发送单元，用于向所述第一实体发送所述请求消息。
  66. 一种统一机器到机器oneM2M系统中的通信的装置，其特征在于，包括：
    第一接收单元，用于接收中转通用服务实体CSE发送的非阻塞同步通信模式下的请求消息，所述请求消息用于发起实体Originator请求对目标资源进行操作；
    第一发送单元，用于当针对所述接收单元接收的所述请求消息不创建请求＜request＞资源时，根据所述请求消息向所述中转CSE发送指示信息，所述指示信息用于指示所述中转CSE在第一时长之后重新发送所述请求消息。
  67. 如权利要求66所述的装置，其特征在于，所述装置还包括：
    处理单元，用于根据所述请求消息对所述目标资源进行处理，得到所述对目标资源的处理结果。
  68. 如权利要求66或67所述的装置，其特征在于，所述装置还包括：
    第二接收单元，用于接收所述中转CSE重新发送的所述请求消息；
    第二发送单元，用于向所述中转CSE发送回复消息，所述回复消息包括所述对目标资源的处理结果。
  69. 如权利要求66至68中任一项所述的装置，其特征在于，所述第一时长大于处理所述目标资源所需的时长。
  70. 如权利要求66至69中任一项所述的装置，其特征在于，所述装置还包括：
    第三发送单元，用于在第一时长之后未完成对所述目标资源的处理时，向所述中转CSE重新发送所述指示消息；或者，
    丢弃单元，用于在第二时长之后未收到所述中转CSE发送的请求消息时，丢弃对所述目标资源的处理结果；
    第三接收单元，用于在第三时长之后，接收所述中转CSE再次发送的请求消息。
  71. 一种统一机器到机器oneM2M系统中的通信的装置，其特征在于，包括：
    第一发送单元，用于向托管Hosting CSE发送非阻塞同步通信模式下的请求消息，所述请求消息用于发起实体Originator向所述Hosting CSE请求对目标资源进行操作；
    第一接收单元，用于接收所述Hosting CSE根据所述请求消息发送的指示信息，所述指示消息用于指示第一时长之后重新发送所述请求消息。
  72. 如权利要求71所述的装置，其特征在于，所述装置还包括：
    第二发送单元，用于向所述Hosting CSE重新发送所述请求消息；
    第二接收单元，用于接收所述Hosting CSE发送的回复消息，所述回复消息包括所述对目标资源的处理结果。
  73. 如权利要求71或72所述的装置，其特征在于，所述第一时长大于处理所述目标资源所需的时长。
  74. 如权利要求71至73中任一项所述的装置，其特征在于，所述装置还包括：
    第三接收单元，用于在第一时长之后，接收所述Hosting CSE重新发送的指示消息；或者，
    第三发送单元，用于在第三时长之后，向所述Hosting CSE再次发送所述请求消息。
PCT/CN2015/070381 2015-01-08 2015-01-08 统一机器到机器系统中通信的方法和装置 WO2016109967A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201580072631.7A CN107113311B (zh) 2015-01-08 2015-01-08 统一机器到机器系统中通信的方法和装置
PCT/CN2015/070381 WO2016109967A1 (zh) 2015-01-08 2015-01-08 统一机器到机器系统中通信的方法和装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2015/070381 WO2016109967A1 (zh) 2015-01-08 2015-01-08 统一机器到机器系统中通信的方法和装置

Publications (1)

Publication Number Publication Date
WO2016109967A1 true WO2016109967A1 (zh) 2016-07-14

Family

ID=56355425

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2015/070381 WO2016109967A1 (zh) 2015-01-08 2015-01-08 统一机器到机器系统中通信的方法和装置

Country Status (2)

Country Link
CN (1) CN107113311B (zh)
WO (1) WO2016109967A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018066926A1 (ko) * 2016-10-07 2018-04-12 주식회사 케이티 M2m 시스템에서 요청 메시지를 전달하는 방법 및 그 장치

Families Citing this family (1)

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

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014109597A1 (ko) * 2013-01-11 2014-07-17 엘지전자 주식회사 M2m(machine-to-machine)시스템에서 게이트웨이 변경 방법 및 이를 위한 장치
CN104093118A (zh) * 2014-03-05 2014-10-08 中兴通讯股份有限公司 一种资源通告的方法、机器对机器节点和系统
CN104104713A (zh) * 2014-02-24 2014-10-15 中兴通讯股份有限公司 设备触发消息处理方法、承载网网元、m2m节点及系统
WO2014169804A1 (zh) * 2013-11-26 2014-10-23 中兴通讯股份有限公司 公共业务实体注册方法和系统
WO2014180438A1 (zh) * 2013-11-04 2014-11-13 中兴通讯股份有限公司 M2m应用的远程注册方法、装置、系统及存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014109597A1 (ko) * 2013-01-11 2014-07-17 엘지전자 주식회사 M2m(machine-to-machine)시스템에서 게이트웨이 변경 방법 및 이를 위한 장치
WO2014180438A1 (zh) * 2013-11-04 2014-11-13 中兴通讯股份有限公司 M2m应用的远程注册方法、装置、系统及存储介质
WO2014169804A1 (zh) * 2013-11-26 2014-10-23 中兴通讯股份有限公司 公共业务实体注册方法和系统
CN104104713A (zh) * 2014-02-24 2014-10-15 中兴通讯股份有限公司 设备触发消息处理方法、承载网网元、m2m节点及系统
CN104093118A (zh) * 2014-03-05 2014-10-08 中兴通讯股份有限公司 一种资源通告的方法、机器对机器节点和系统

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018066926A1 (ko) * 2016-10-07 2018-04-12 주식회사 케이티 M2m 시스템에서 요청 메시지를 전달하는 방법 및 그 장치

Also Published As

Publication number Publication date
CN107113311A (zh) 2017-08-29
CN107113311B (zh) 2020-12-08

Similar Documents

Publication Publication Date Title
EP3993347A1 (en) Method and device for application migration
US20200383035A1 (en) Communications method and apparatus
WO2018082490A1 (zh) 用户终端位置区域更新方法、接入网实体、用户终端及核心网实体
US11606306B2 (en) Packet transmission method and apparatus
US20220377819A1 (en) Method and apparatus for establishing data transmission link and computer-readable storage medium
CN110324246B (zh) 一种通信方法及装置
KR102456859B1 (ko) 5g 시스템에서 제공하는 서비스 파라미터를 단말과 네트워크에 프로비져닝하는 방법
US10560929B2 (en) Resource request method and system, device, and network side node
WO2019196811A1 (zh) 通信方法和相关装置
RU2725179C1 (ru) Связь машинного типа с использованием услуги передачи мобильных исходящих коротких сообщений без международного абонентского телефонного номера мобильной станции
US11432349B2 (en) Group creation method, apparatus, and system
JP2021517430A (ja) 通信方法、装置、及びシステム
WO2021051420A1 (zh) 一种dns缓存记录的确定方法及装置
WO2021135650A1 (zh) 通信方法及装置
WO2020001439A1 (zh) 一种配置方法及装置
WO2020034371A1 (en) Managing access and mobility functions
JP2019508958A (ja) Ｕｅコンテキスト情報を再開する方法、デバイス及びシステム
US20140120917A1 (en) Communication system, communication method, base station , and management device
TWI775009B (zh) 用於行動通訊系統之基地台及其資料傳輸方法
CN112740723B (zh) 用于5gc的低时延消息传递服务
JP6425107B2 (ja) 通信処理システム、グループメッセージ処理方法、通信処理装置およびその制御方法と制御プログラム
WO2016109967A1 (zh) 统一机器到机器系统中通信的方法和装置
AU2020246484B2 (en) Terminal management and control method, apparatus, and system
WO2021163901A1 (zh) 一种会话处理方法及其装置
WO2019238050A1 (zh) 一种通信方法及装置

Legal Events

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

Ref document number: 15876475

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15876475

Country of ref document: EP

Kind code of ref document: A1