WO2015070441A1

WO2015070441A1 - M2m network and application, common services entity, and information reply method

Info

Publication number: WO2015070441A1
Application number: PCT/CN2013/087249
Authority: WO
Inventors: 陶源; 于琦
Original assignee: 华为技术有限公司
Priority date: 2013-11-15
Filing date: 2013-11-15
Publication date: 2015-05-21

Abstract

The present invention relates to an M2M network and application, a common services entity and an information reply method. The M2M network comprises a target common services entity and at least one application. The method comprises: receiving, by the target common services entity, service request information, the service request information including a specific time; and sending, by the target common services entity, acknowledgement information to the application within the specific time. By means of the M2M network and application, the common services entity and the information reply method of the present invention, the service request information received by the target common services entity includes the specific time, so that the target common services entity can send the acknowledgement information to the application within the specific time.

Description

M2M network and application, general business entity, information recovery method

The present invention relates to the field of communications technologies, and in particular, to an M2M network and application, a general service entity, and an information recovery method. Background art

Machine-to-Machine (M2M) communication is a networked application and service centered on machine intelligent interaction. By embedding wireless or wired communication modules and application processing logic inside the book machine, no manual is required. The data communication of interventions meets the information needs of users in monitoring, command and dispatch, data acquisition and measurement.

The overall goal of the oneM2M standards organization for machine communication is to create an open standard for the Service Capability Layer (SCL) of M2M communication to facilitate the establishment of a future network that integrates various devices and services, enabling M2M services to interoperate. Enables M2M applications to share basic services and implement them independently of the network.

The M2M network architecture defined by the oneM2M standard mainly includes an Application Entity (AE), a Common Service Entity (CSE), and an Underlying Network Service Entity (NSE). On the M2M device specified by the oneM2M standard, the M2M AE and the M2M CSE communicate via the Mca Reference Point, and the CSE uses the Mcc reference point for communication; the CSE communicates with the NSE through the Men reference point.

The European Telecommunication Standardization Institute (ETSI) M2M standard uses a method of aggregating request information in a storage and forwarding mechanism, allowing a tolerable request processing delay time set according to AE or CSE (Tolerable Request Processing Delay Time). , TRPDT ) and request category (RCAT), store the request information in the local CSE until the CSE establishes a communication link that conforms to RCAT ( The storage time cannot exceed the time defined by the TRPDT), and the request information sent to the same target CSE can be aggregated and then sent.

In summary, the prior art cannot control the time at which the target CSE replies to the confirmation information. Summary of the invention

technical problem

In view of this, the technical problem to be solved by the present invention is how to control the time at which the target CSE replies to the acknowledgment information.

Solution book

In order to solve the above technical problem, in a first aspect, the present invention provides a device-to-machine M2M network information recovery method, the M2M network includes a target general service entity and at least one application, and the method includes:

The target general service entity receives service request information, where the service request information includes a specific time;

The target general service entity sends confirmation information to the application within the specific time. In conjunction with the first aspect, in a first possible implementation, the target general service entity receives the service request information, including: the target general service entity receiving the first service request information from the application.

With reference to the first aspect, in a second possible implementation manner, the M2M network further includes a local general service entity, where the target general service entity receives the service request information, including: the target general service entity receives the local a second service request information generated by the general service entity according to the first service request information received from the application;

The target general service entity sends confirmation information to the application within the specific time, including:

The target general service entity passes the local general service entity during the specific time Send confirmation information to the application.

With reference to the second possible implementation manner of the first aspect, in a third possible implementation, the first service request information further includes a request type RCAT and a tolerable request processing delay time TRPDT, where the target general service is Receiving, by the local general service entity, the second service request information generated by the local general service entity according to the first service request information received by the application, where: if the communication link corresponding to the RCAT is established, Receiving, by the target general service entity, the second service request information that is sent by the local general service entity immediately; or

If the local communication time of the local general service entity does not exceed the TRPDT, the target general service entity receives the delayed transmission of the local general service entity if the communication link corresponding to the RCAT is not established. The second service request information, where the local processing time is the time when the local general service entity establishes the communication link; if the local processing time of the local general service entity exceeds the TRPDT, the local general service entity Returning a failure message to the application.

With reference to the first aspect, in a fourth possible implementation, the M2M network further includes a local general service entity, where the target general service entity receives the service request information, including: the target general service entity receives the local a second service request information that is aggregated by the general service entity according to the plurality of first service request information received from the application;

After the target general service entity aggregates the respective acknowledgment information into the aggregation information, the aggregation information is sent to the local general service entity, and the local general service entity separates the aggregation information. Sending corresponding confirmation information to each of the applications, where the remaining time is determined by the local general service entity according to a specific time included in the plurality of the first service request information and a local processing time of the local general service entity, The aggregate information includes the respective confirmation information. With reference to the fourth possible implementation manner of the first aspect, in a fifth possible implementation, the first service request information further includes an RCAT and a TRPDT, where the target general service entity receives the local general service The second service request information that is aggregated by the entity according to the multiple first service request information received by the application includes:

If the local communication time of the local general service entity does not exceed the TRPDT, the local general service entity determines a delay time, and the local general service entity is in the case that the communication link corresponding to the RCAT is not established. The plurality of the first service request information received from the application is aggregated in a delay time, and the target general service entity receives the aggregated second service request information from the local general service entity, The local processing time is the time at which the local general service entity establishes the communication link.

In order to solve the above technical problem, in a second aspect, the present invention provides an information recovery method for an M2M network, where the M2M network includes a target general service entity and at least one application, and the method includes:

The application sends first service request information, where the first service request information includes a specific time;

The application receives confirmation information returned by the target general service entity according to a specific time within the specific time.

With reference to the second aspect, in a first possible implementation, the application sends the first service request information, where the application sends the first service request information to the target general service entity;

And receiving, by the application, the confirmation information returned by the target general service entity according to the specific time in the specific time, the method includes: the application receiving the confirmation information from the target general service entity in the specific time.

With reference to the second aspect, in a second possible implementation, the M2M network further includes a local general service entity, where the application sends the first service request information, including: the application to the The local general service entity sends the first service request information, so that the local general service entity sends the second service request information to the target general service entity according to the first service request information;

Receiving the confirmation information returned by the target general service entity according to the specific time in the specific time, the method includes: receiving, by the application, the target general service entity from the local general service entity in the specific time The confirmation information returned.

In order to solve the above technical problem, the third aspect of the present invention provides a general service entity of an M2M network, including:

The receiving module is configured to receive service request information, where the service request information includes a specific time, and the sending module is configured to communicate with the receiving module, and send the confirmation information to the application within the specific time.

In conjunction with the third aspect, in a first possible implementation, the receiving module is further configured to receive the first service request information from the application.

With reference to the third aspect, in a second possible implementation, the receiving module is further configured to receive second service request information generated by the local general service entity according to the first service request information received from the application;

The sending module is further configured to send the confirmation information to the application by the local universal service entity during the specific time.

With reference to the second possible implementation manner of the third aspect, in a third possible implementation, the first service request information further includes a request type RCAT and a tolerable request processing delay time TRPDT, where the receiving module uses Receiving, by the local general service entity, the second service request information, if the communication link corresponding to the RCAT is established, the receiving module is further configured to receive, according to the local general service entity, Decoding, by the application, the second service request information generated by the first service request information; or

The sending module is further configured to: if the communication link corresponding to the RCAT is not established, if The local processing time of the local general service entity does not exceed the TRPDT, and the second service request information delayed by the local general service entity is received.

With reference to the third aspect, in a fourth possible implementation, the receiving module is configured to receive, by the local common service entity, a second service request that is aggregated according to multiple first service request information received from the application Information

The receiving module is further configured to: after the aggregation information is aggregated into the aggregation information, send the aggregation information to the local general service entity, where the local general service entity performs the aggregation information After the separation, respectively sending corresponding confirmation information to each of the applications, where the remaining time is determined by the local general service entity according to a specific time included in the plurality of first service request information and local to the local general service entity The processing time is determined, and the aggregation information includes the respective confirmation information.

With reference to the fourth possible implementation manner of the third aspect, in a fifth possible implementation, the first service request information further includes an RCAT and a TRPDT, where the communication link corresponding to the RCAT is not established. If the local processing time of the local general service entity does not exceed the TRPDT, the local general service entity determines a delay time, and the local general service entity receives the received time from the application within the delay time. The first service request information is aggregated, and the receiving module is further configured to receive the aggregated second service request information from the local general service entity, where the local processing time is established by the local general service entity. The time of the communication link.

In order to solve the above technical problem, in a fourth aspect, the present invention provides an application of an M2M network, including:

a sending module, configured to send first service request information, where the first service request information includes a specific time;

And a receiving module, configured to receive, during the specific time, the confirmation information returned by the general service entity according to a specific time. With reference to the fourth aspect, in a first possible implementation, the sending module is further configured to send the first service request information to the general service entity; the receiving module is further configured to use the specific time Receiving the confirmation information from the general service entity.

With reference to the fourth aspect, in a second possible implementation, the M2M network further includes a local general service entity, where the sending module is further configured to send the first service request information to the general service entity, so that Transmitting, by the local general service entity, the second service request request information to the general service entity according to the first service request information;

The receiving module is further configured to receive, by the local general service entity, the confirmation information book returned by the general service entity during the specific time.

In order to solve the above technical problem, in a fifth aspect, the present invention provides an M2M network, including: a target general service entity and at least one application;

The target general service entity adopts the general service entity of the M2M network described in any one of the above;

The application employs the application of the M2M network described in any of the above.

In combination with the fifth aspect, in the first possible implementation manner, the method further includes:

a local general service entity, configured to receive first service request information sent by the application; and send second service request information to the target general service entity.

Beneficial effect

The M2M network and application, the general service entity, and the information reply method of the present invention, the service request information received by the target general service entity includes a specific time, so that the target general service entity can send the confirmation information to the application within a specific time.

Further features and aspects of the present invention will become apparent from the Detailed Description of the Drawing. DRAWINGS The accompanying drawings, which are incorporated in FIG

1A is a flow chart showing a method for recovering information of a machine-to-machine M2M network according to Embodiment 1 of the present invention;

1B is a schematic diagram of an information recovery method of an M2M network applied to a oneM2M architecture according to Embodiment 1 of the present invention;

2 is a flowchart of a method for replying information of an M2M network according to a second embodiment of the present invention; FIG. 3 is a flowchart of a method for replying information of an M2M network according to Embodiment 3 of the present invention; FIG. 4 is a flowchart of an M2M network according to Embodiment 4 of the present invention; FIG. 5 is a structural block diagram of a general service entity of an M2M network according to Embodiment 5 of the present invention; FIG. 6 is a structural block diagram of an application of an M2M network according to Embodiment 6 of the present invention;

7 is a structural block diagram of an M2M network according to Embodiment 7 of the present invention;

8 is a structural block diagram of a general service entity of an M2M network according to Embodiment 8 of the present invention; and FIG. 9 is a structural block diagram of an application of an M2M network according to Embodiment 9 of the present invention. detailed description

Various exemplary embodiments, features, and aspects of the invention are described in detail below with reference to the drawings. The same reference numerals in the drawings denote the same or similar elements. The various aspects of the embodiments are shown in the drawings, and the drawings are not necessarily drawn to scale unless otherwise indicated.

The word "exemplary" is used exclusively herein to mean "serving as an example, embodiment, or illustrative." Any embodiment described herein as "exemplary" is not necessarily to be construed as preferred or advantageous.

In addition, numerous specific details are set forth in the Detailed Description of the <RTIgt; Those skilled in the art will appreciate that the invention may be practiced without some specific details. In other instances, well-known methods, means, components, and circuits are not described in detail to facilitate the invention. Example 1

1A is a flow chart showing a method for replying information of a machine-to-machine M2M network according to Embodiment 1 of the present invention. As shown in FIG. 1A, the M2M network may include a general service entity and at least one application, where the general service entity may include a local general service entity and a target general service entity, and the information recovery method of the M2M network may include:

Step 110: The target general service entity receives service request information, where the service request information includes a specific time. Say

Step 120: The target general service entity sends the acknowledgement information to the application within the specific time. Book

Specifically, the M2M network can adopt a variety of architectures. FIG. 1B is a schematic diagram of an M2M network information recovery method applied to a oneM2M architecture according to Embodiment 1 of the present invention. As shown in FIG. 1B, an M2M network architecture defined by the oneM2M standard includes an Application Dedicated Node and an application. Four functional entities: Application Service Node, Middle Node, and Infrastructure Node. As shown in Case 1 and Case 2 in IB, a node that can only include an Application Entity (AE) is called an application-specific node; as shown in Case 3 and Case 4 in FIG. 1B, the AE may be included and may include a general service entity ( The node of the Common Service Entity (CSE) is called an application service node; in addition, both the intermediate node and the infrastructure node can include AE or CSE.

As shown in FIG. 1B, in case 2, case 3, the application dedicated node 11 and the application service node 13 can communicate with the infrastructure node 17 through the intermediate node 15. In case 1, case 4, the application-specific node and the application service node can also communicate directly with the infrastructure node.

In the embodiment of the present invention, the application entity AE may include or provide at least one application, where the application may be an application, an application module, an application logic unit, or the like. A generic business entity may be a module that has the functionality of a CSE, where the application and the generic business entity may be on the same node. Another M2M network architecture can be adopted by the European Telecommunication Standardization Institute (ETSI) M2M standard. ETSI

The application of the M2M network may be a module with an AE function, and the local general service entity and the target general service entity may be modules with a Service Capability Layer (SCL) function, wherein the application and the general service entity may also be on the same node. . The application or SCL can set the Tolerable Request Processing Delay Time (TRPDT) and the request type (request cat says egory, RCAT).

In the embodiment of the present invention, the application may determine whether the general service entity receives the valid confirmation information by using the specific time included in the first service request information, for example, the application judgment starts from the issuance of the first service request information, within a specific time. Whether the confirmation message returned by the target general service entity is received, and if yes, the transmission process is successful. The service request information may include other information such as the payload target general service entity address, and the payload may include specific content of the service request. For example, in the medical related M2M network, the load may be information such as blood pressure and heartbeat of the patient reported by the application.

It should be noted that the purpose of setting the specific time for the application is to enable the target general business entity to obtain the urgency of replying to the service request information. In a possible implementation, the application is successful if it receives the confirmation information returned by the target general service entity even if the application exceeds the specified time. It is optional for the application to time the process of receiving the confirmation message. If the application is timing, it can be known which target common business entity replies can't always respond to a specific time, and the application can take some measures such as shortening the specific time.

In a possible implementation manner, step 110 is different in different scenarios: Scenario 1. The M2M network includes a target general service entity and at least one application.

In this scenario, the step 110 may specifically include: the target general service entity receiving the first service request information from the application.

The step 120 may specifically include: sending, by the target general service entity, the acknowledgement information to the application within the specific time. Scenario 2: The M2M network includes a target general service entity, a local general service entity, and at least one application.

In this scenario, you can include any of the following methods:

Method one, a single business request.

In the first method, the step 110 may include: the target general service entity receiving the second service request information generated by the local general service entity according to the first service request information received from the application. Say

The first service request information may further include a request type RCAT and a tolerable request processing delay time TRPDT, where the target general book service entity receives, according to the local general service entity, according to the received from the application. The second service request information generated by the first service request information may specifically include:

And in a case that the communication link corresponding to the RCAT is established, the target general service entity receives the second service request information that is sent by the local general service entity immediately.

And in the case that the communication link corresponding to the RCAT is not established, if the local processing time of the local general service entity does not exceed the TRPDT, the target general service entity receives the delayed transmission of the local general service entity. The second service request information; if the local processing time of the local general service entity exceeds the TRPDT, the local general service entity returns failure information to the application.

In the first method, the step 120 may include: sending, by the local universal service entity, the acknowledgement information to the application by using the local universal service entity.

Method 2, aggregated business request.

In the second method, the step 110 may include: the target general service entity receiving the second service request information that is aggregated by the local general service entity according to the plurality of the first service request information received from the application.

The first service request information may further include RCAT and TRPDT, and the target general service The entity may receive, by the local common service entity, the second service request information that is aggregated according to the received multiple service request information, which may include:

If the local communication time of the local general service entity does not exceed the TRPDT, the local general service entity determines a delay time, and the local general service entity is in the case that the communication link corresponding to the RCAT is not established. Aggregating a plurality of the first service request information received from the application, and the target general service entity receives the aggregated second service request information from the local general service entity, The local processing time is the time at which the local general service entity establishes the communication link.

In the second mode, the step 120 may include: in the remaining time, after the target general service entity aggregates the respective confirmation information into the aggregation information, sending the aggregation information to the local general service entity, where the local information is sent by the local And the common service entity separately sends the corresponding acknowledgment information to each of the applications, where the remaining time is determined by the local general service entity according to a specific time and time included in the plurality of the first service request information. The local processing time of the local general service entity is determined, and the aggregation information includes the respective confirmation information.

In the information replying method of the M2M network of the embodiment, the service request information received by the target general service entity includes a specific time, so that the target general service entity can send the confirmation information to the application within a specific time.

Example 2

2 is a flowchart of a method for replying information of an M2M network according to Embodiment 2 of the present invention. The M2M network includes a target general service entity and at least one application. As shown in FIG. 2, the information recovery method of the M2M network mainly includes:

Step 210: The application sends the first service request information, where the first service request information includes a specific time.

Step 220: The application receives the confirmation information returned by the target general service entity according to a specific time in the specific time. Specifically, step 210 is different in different scenarios:

Scenario 1. The M2M network includes a target general service entity and at least one application.

In this scenario, the step 210 may specifically include: the application sending the first service request information to the target general service entity.

The step 220 may specifically include: the application receiving the confirmation information from the target general service entity within the specific time.

Scenario 2: The M2M network includes a target general service entity, a local general service entity, and at least one application.

In this scenario, the step 210 may include: the M2M network further includes a local general service entity, where the application sends the first service request information to the local general service entity, so that the local general service entity And sending second service request information to the target general service entity according to the first service request information.

The step 220 may specifically include: receiving, by the application, the confirmation information returned by the target general service entity from the local universal service entity within the specific time.

In the information replying method of the M2M network of the embodiment, the application can determine the specific time of the target general service entity by using the specific time included in the first service request information, so that the target general service entity can reply the confirmation information within a specific time.

Example 3

FIG. 3 is a flowchart of a method for replying information of an M2M network according to Embodiment 3 of the present invention. As shown in FIG. 3, the M2M network may include a target general service entity, a local general service entity, an application 1 and an application 2. The main processes of the information recovery method of the M2M network include:

Step 300: The application 1 sends a first service request information (request) to the local general service entity. The first service request information may include time information such as: a specific time, and may also include information such as a payload and an address of a target general service entity.

Step 310: The local general service entity (Local CSE) receives the first service of the application 1 After the information is obtained, the second service request information may be generated according to the first service request information, and the generated second service request information is sent to the target general service entity (Target CSE). If the transmission time of the service request information or the like is not considered, the specific time included in the second service request information may be equal to a specific time in the first service request information.

Step 320: The application 2 sends the first service request information to the local general service entity.

The first service request information may include a specific time, a payload, and an address of the target general service entity. The sequence of the step 300 and the step 320 may be in no particular order. In step 320, the application 2 sends the first service request information and the first service request information sent by the application 1 in step 300.

The specific content may be the same and may be different. The specific time may be the same or different, and the addresses of the target general business entities are the same. For example, the load information in the first service request information of the application 2 may be the body temperature information of the patient collected by the application 2 in the M2M network. It should be noted that Application 1 and Application 2 may be located at the same or different nodes from the local general service entity. For example, referring to case 3 in FIG. 1B, the application 11 can communicate with the target general service entity included in the infrastructure node 17 through the local general service entity on the intermediate node 14, and the application 11 can also directly interact with the infrastructure node 17 in case 1. The target general business entity communication included. Step 330: After receiving the first service request information of the application 2, the local general service entity generates second service request information according to the first service request information, and sends the second service request information to the target general service entity. Step 340: After the target general service entity aggregates the respective confirmation information into the aggregation information, the aggregation information is sent to the local general service entity, where the aggregation information includes the respective confirmation information and the address of the local general service entity. . Specifically, after receiving the first service request information of the application 1, the target general service entity may generate confirmation information 1 (notification1), and the notification1 may correspond to a notification ID. After receiving the first service request information sent by the application 2, the target general service entity may generate an identifier. For notification 2 of 2, notification can also correspond to a notification ID. After the acknowledgment information is generated, the target general service entity may directly send the acknowledgment information to the corresponding application through the local general service entity, or may send the acknowledgment information to be sent after a certain delay time (less than a specific time). .

If the target general service entity determines that the address of the local general service entity that the acknowledgment information 1 and the acknowledgment information 2 need to be sent is the same, the acknowledgment information 1 and the acknowledgment information 2 can be aggregated to obtain the aggregated information, otherwise the aggregation cannot be performed. The goal is that when the general service entity aggregates the confirmation information 1 and the confirmation information 2, it can judge when to reply according to the specific time of the two. For example, the specific time of the confirmation information 1 is 1 second, and the specific time of the confirmation information 2 is 0.5 seconds. When the target general service entity receives the first service request information of the application 1 at the time of 0.3 seconds, the application 2 is received. The first service request information, the target general service entity can compare the specific time of the confirmation information 1 and the confirmation information 2, and the time of the delay, thereby determining that: the aggregate information needs to be sent before the time of 0.8 seconds, for example, the target general service entity can be at 0.7. The aggregate information is sent at the second time, and the aggregated information can also be sent at the time of 0.6 seconds, as long as the time smaller than the specific time is selected.

There are many ways in which a target general business entity can aggregate multiple acknowledgments. The target general service entity generates an acknowledgement information subframe including the payload and the acknowledgement information identifier according to each acknowledgement information, and then splices a plurality of such acknowledgement information subframes together, and adds a local general service entity address to be sent to. The frame header forms an aggregated information frame and can define the maximum allowable length of the aggregated information frame.

Step 350: The target general service entity sends the aggregation information to the local general service entity.

Step 360: The local general service entity receives the aggregation information replied by the target general service entity, and separates the aggregation information to obtain the confirmation information 1 and the confirmation information 2.

Step 370: The local general service entity may separately send the confirmation information to the corresponding application 1 and application 2 according to the identifier of the confirmation information.

The information reply method of the M2M network in this embodiment, the service received by the target general service entity The request information includes a specific time to enable the target general service entity to send confirmation information to the application within a specific time. Further, the general business entity can reduce or confirm the information aggregation or separation.

Signaling that needs to be transmitted in M2M network communication.

Example 4

4 is a flowchart of a method for replying information of an M2M network according to Embodiment 4 of the present invention. As shown in FIG. 4, the M2M network may include a target general service entity, a local general service entity, an application 1 and an application 2. The information replying party of the M2M network mainly includes:

Step 400: Application 1 and Application 2 respectively send the first service request information to the local general service entity. Specifically, the first service request information may include information such as a specific time, a payload, and an address of the target general service entity, a request type RCAT, and a tolerable request processing delay time TRPDT. In this case, the local general service entity (CSE or SCL) can store the first service request information until an RCAT compliant communication link is established. The value of the RCAT is used to determine whether the communication link is established. The value of the TRPDT determines whether the transmission is delayed. The storage time of the first service request information in the local general service entity cannot exceed the time defined by the TRPDT. The local general service entity can send the information. The request information to the same target general business entity is aggregated and then sent.

Step 410: After receiving the first service request information of the application 1, the local general service entity determines whether to save or send the first service request information according to the specific time, the TRPDT, and the RCAT value. Specifically, the following can be included:

Case 1: In the case that the communication link corresponding to the RCAT is established, the local general service entity generates the second service request information according to the first service request, and immediately sends the second service request information to the target general service entity.

Case 2: In the case that the communication link corresponding to the RCAT is not established, if the processing time of the local general service entity does not exceed the specific time and the TRPDT time, the local general service entity delays forwarding the first service request information to the The target general business entity, the local processing time includes the construction The time at which the communication link corresponding to the RCAT is established.

Specifically, the local general service entity determines whether the time for saving the delayed transmission exceeds a specific time, any one of the parameter time values of the TRPDT. In an actual M2M network design, the specific time length may be greater than the TRPDT time length. In this case, when the local general service entity considers whether to save the delayed transmission, only the TRPDT time may be considered, if the local general service entity saves the first service request. When the information exceeds the TRPDT time, a failed response is returned to the application 1.

In a possible implementation manner, when the general service entity saves the first service request information and delays sending, if the first service request information from the application 2 is received within the time of saving the delayed transmission, The two first service request information are aggregated into the second service request information. The local general service entity calculates the remaining time of each specific time according to the specific time, TRPDT and RCAT information of the first service request information sent by the two applications, and uses the calculated remaining time as the specific time of the target general service entity. And sending, to the target general service entity, the payload and the target general service entity address information, where the specific time may be different from the specific time of the first service request information and the second service request information.

If the time spent transmitting the first service request in the M2M network is ignored, and the remaining time calculation method for calculating the specific time of replying the confirmation information is calculated, the time spent in the processing of the local general service entity may be subtracted for the specific time, and the remaining is selected in practice. The time is less than a specific time minus the time spent processing the local general business entity. For example, if the specific time for the application 1 to send the first service request information is 1 second, and the time for the local general service entity to process the first service request is 0.5 seconds, then the remaining time of the second service request information sent to the target general service entity is It is 0.5 seconds. The specific time that the application 2 sends the first service request information is 0.8 seconds, and the time taken by the local general service entity to process the first service request is 0.5 seconds, and the remaining time of the second service request information sent to the target general service entity is 0.3 seconds. The local general service entity may compare the remaining time of the first service request information included in the second service request, and may select the time with the smallest remaining time as the remaining time of the second service request. It should be noted that the specific calculation manner of the remaining time of the second service request may be determined according to actual conditions. For example, in practice, you need to consider the transmission time of the service request in the M2M network. When calculating the remaining time, you should also consider the impact of the transmission time on the remaining time. The way to calculate the remaining time is: the specific time minus the local general service entity processing. The time spent is subtracted from the transmission time of the service request, and the remaining time selected in the actual is less than the calculated time. The smallest time among the remaining time is also selected as the remaining time included in the second service request.

Step 420: The local general service entity sends the second service request information to the target general service entity according to the first service request information.

Step 430: The target general-purpose book service entity separates the second service request information, obtains two service request information including the remaining time, and generates a confirmation according to the first service request information that is sent by the application 1 and includes the specific time. Information 1 (notification1), notificationl may correspond to a notification (notification ID). According to the first service request information including the specific time sent by the application 2, the confirmation information 2 (notification2) with the identifier 2 may be generated, and the notification2 may also correspond to one. Identification ID. And for the remaining time, the target general service entity aggregates the confirmation information 1 and the confirmation information 2 to generate aggregate information. A plurality of acknowledgment information sub-frames may be aggregated. For details, refer to the description of Embodiment 4, and details are not described herein again.

Step 440: The target general service entity sends the aggregation information to the local general service entity.

Step 450: The local general service entity separates the aggregation information, and obtains the confirmation information 1 and the confirmation information.

2.

Step 460: The local general service entity sends the confirmation information 1 to the application 1, and sends the confirmation information 2 to the application 2.

In the information replying method of the M2M network of the embodiment, the service request information received by the target general service entity includes a specific time, so that the target general service entity can send the confirmation information to the application within a specific time. Further, the general service entity aggregates the acknowledgement information and/or the service request information, which can reduce the signaling that needs to be transmitted in the M2M network communication. Example 5

FIG. 5 is a structural block diagram of a general service entity of an M2M network according to Embodiment 5 of the present invention. As shown in FIG. 5, the general service entity 500 of the M2M network mainly includes:

The receiving module 510 is configured to receive service request information, where the service request information includes a specific time, where the specific time is determined by a specific time in the first service request information sent by the application;

The sending module 520 is in communication with the receiving module block 510 for transmitting acknowledgement information to the application within the specific time.

Specifically, in a possible implementation, the receiving module 510 is further configured to receive the first service request information from the application.

In a possible implementation manner, the receiving module 510 is further configured to receive second service request information generated by the local general service entity according to the first service request information received from the application;

The receiving module 520 is further configured to send the confirmation information to the application by the local general service entity during the specific time.

In a possible implementation manner, the first service request information further includes a request type RCAT and a tolerable request processing delay time TRPDT, where the receiving module 510 is configured to establish a communication link corresponding to the RCAT. In the case that the second service request information that is sent by the local general service entity is received, the receiving module 510 is further configured to receive, by the local general service entity, the first service request information received from the application. Generated second service request information; or

The receiving module 520 is further configured to: if the local processing time of the local general service entity does not exceed the TRPDT, if the communication link corresponding to the RCAT is not established, receive the delayed transmission of the local general service entity. The second service request information.

In a possible implementation, the receiving module 510 is configured to receive by the local universal a second service request information that is aggregated by the service entity according to the plurality of the first service request information received from the application;

The sending module 520 is further configured to: after the aggregation information is aggregated into the aggregation information, the aggregation information is sent to the local general service entity, and the local general service entity separates the aggregation information. And sending, to each of the applications, corresponding confirmation information, where the remaining time is determined by the local general service entity according to a specific time included in the plurality of the first service request information and a locality of the local general service entity The processing time is determined, and the aggregation information includes the respective confirmation information.

In a possible implementation, the first service request information further includes an RCAT and a TRPDT, where the local processing time of the local general service entity is not established, if the communication link corresponding to the RCAT is not established. Not exceeding the TRPDT, the local general service entity determines a delay time, and the local general service entity aggregates a plurality of the first service request information received from the application during the delay time, The receiving module 510 is further configured to receive the aggregated second service request information from the local universal service entity, where the local processing time is a time when the local universal service entity establishes the communication link.

In this embodiment, the service request information received by the target general service entity includes a specific time, so that the target general service entity can send the confirmation information to the application within a specific time.

Example 6

FIG. 6 is a structural block diagram of an application of an M2M network according to Embodiment 6 of the present invention. As shown in FIG. 6, the application 600 of the M2M network mainly includes:

The sending module 610 is configured to send first service request information, where the first service request information includes a specific time.

The receiving module 620 is configured to receive, during the specific time, the confirmation information returned by the general service entity according to a specific time.

Specifically, in a scenario where the application directly sends the service request information to the general service entity, the sending The sending module 610 is further configured to send the first service request information to the general service entity. The receiving module 620 is further configured to receive the acknowledgement information from the universal service entity within the specific time.

In a possible implementation manner, the M2M network further includes a local general service entity, where the sending module 610 is further configured to send the first service request information to the general service entity, so that the local general service is The entity sends the second service request information to the general service entity according to the first service request information;

The receiving module 620 is further configured to receive, by the local general service entity, the acknowledgement information returned by the universal service entity during the specific time.

Example 7

FIG. 7 is a structural block diagram of an M2M network according to Embodiment 7 of the present invention. As shown in Figure 7, the M2M network 700 mainly includes:

The target general service entity 710, the target general service entity 710 adopts the general service entity 600 of the M2M network in the foregoing embodiment, and the specific features thereof may be referred to in the foregoing embodiment, and are not described herein again.

Application 720, the application 720 employs an application 700 of the M2M network as described in the above embodiments. The local general service entity 730 is configured to receive the first service request information sent by the application 720, and send the second service request information to the target general service entity 710.

In the M2M network of this embodiment, the specific time of the target general service entity can be determined by the specific time included in the first service request information, so that the target general service entity can reply the confirmation information within a specific time.

Example 8

FIG. 8 is a structural block diagram of a general service entity of an M2M network according to Embodiment 8 of the present invention. The M2M The general service entity 800 of the network may be a host server with computing power, a personal computer PC, or a portable computer or terminal that can be carried. The specific embodiments of the present invention do not limit the specific implementation of the computing node.

The general service entity 800 includes a processor 810, a communications interface 820, a memory 830, and a bus 840. Among them, the processor 810, the communication interface 820, and the memory 830 complete communication with each other through the bus 840.

Communication interface 820 is for communicating with network devices, such as virtual machine management centers, shared storage, and the like.

The processor 810 is for executing a program. The processor 81 may be a central processing unit CPU, or an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present invention.

Memory 830 is used to store files. The memory 830 may include a high speed RAM memory and may also include a non-volatile memory such as at least one disk memory. Memory 830 can also be a memory array. Memory 830 may also be partitioned, and the blocks may be combined into a virtual volume according to certain rules.

In a possible implementation manner, the M2M network includes a target general service entity and at least one application, and the program may be program code including computer operation instructions. This program can be used specifically for:

The target general service entity sends confirmation information to the application within the specific time. In a possible implementation manner, the target general service entity receiving the service request information includes: the target general service entity receiving the first service request information from the application.

In a possible implementation, the M2M network further includes a local general service entity, and the target general service entity receives the service request information, including: the target universal service entity Receiving second service request information generated by the local general service entity according to the first service request information received from the application;

The target general service entity sends confirmation information to the application through the local general service entity during the specified time.

In a possible implementation manner, the first service request information is further included in the request type.

RCAT and tolerable request processing delay time TRPDT, the target general service entity receiving second service request information generated by the local general service entity according to the first service request information received from the application receiving, including :

And in the case that the communication link corresponding to the RCAT is established, the target general service entity receives the second service request information that is sent by the local general service entity immediately; or

And in the case that the communication link corresponding to the RCAT is not established, if the local processing time of the local general service entity does not exceed the TRPDT, the target general service entity receives the delayed transmission of the local general service entity. The second service request information, where the local processing time is the time when the local general service entity establishes the communication link; if the local processing time of the local general service entity exceeds the TRPDT, the local general service entity The application returns a failure message.

In a possible implementation manner, the M2M network further includes a local general service entity, where the target general service entity receives the service request information, including: the target general service entity receives the local general service entity according to the Transmitting, by the application, a plurality of second service request information that is aggregated by the first service request information;

The target general service entity aggregates each confirmation information into aggregate information for the remaining time After the aggregation information is sent to the local general service entity, the local general service entity separates the aggregation information and sends corresponding confirmation information to each of the applications, where the remaining time is from the local The general service entity determines, according to a specific time included in the plurality of the first service request information and a local processing time of the local general service entity, where the aggregation information includes the respective confirmation information.

In a possible implementation manner, the first service request information further includes an RCAT and a TRPDT, and the target general service entity says to receive, by the local general service entity, according to the multiple received from the application. The second service request information that is aggregated by the first service request information includes: if the local processing time of the local general service entity does not exceed the TRPDT, if the communication link corresponding to the RCAT does not establish a book, Determining, by the local general service entity, a delay time, the local general service entity aggregating a plurality of the first service request information received from the application, the target general service entity from the local The general service entity receives the aggregated second service request information, where the local processing time is the time at which the local general service entity establishes the communication link.

Example 9

FIG. 9 is a structural block diagram of an application of an M2M network according to Embodiment 9 of the present invention. The application 900 of the M2M network may be a computing server host computer, a personal computer PC, or a portable portable computer or terminal. The specific embodiment of the present invention does not limit the specific implementation of the computing node.

The application 900 includes a processor 910, a communications interface 920, a memory 930, and a bus 940. The processor 910, the communication interface 920, and the memory 930 complete communication with each other through the bus 940.

The communication interface 920 is configured to communicate with a network device, where the network device includes, for example, virtual machine management Center, shared storage, etc.

The processor 910 is for executing a program. The processor 910 may be a central processing unit CPU, or an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present invention.

The memory 930 is used to store files. The memory 930 may include a high speed RAM memory and may also include a non-volatile memory such as at least one disk memory. Memory 930 can also be a memory array. The store 930 may also be partitioned, and the blocks may be combined into a virtual volume according to certain rules.

In a possible implementation, the M2M book network includes a target general service entity and at least one application, and the program may be program code including computer operation instructions. This program can be used specifically for:

In a possible implementation, the sending, by the application, the first service request information, the method includes: sending, by the application, the first service request information to the target general service entity;

In a possible implementation manner, the M2M network further includes a local general service entity, where the application sends the first service request information, where the application sends the first service request information to the local universal service entity. So that the local general service entity sends the second service request information to the target general service entity according to the first service request information;

Receiving, by the application, the target general service entity according to a specific time in the specific time The returned confirmation information includes: the application receiving the confirmation information returned by the target general service entity from the local general service entity within the specific time.

One of ordinary skill in the art will appreciate that the various exemplary units and algorithm steps in the embodiments described herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the solution. The skilled person can select different methods for a particular application to implement the described functionality, but such implementation should not be considered beyond the scope of the invention.

If the function is implemented in the form of computer software and sold or used as a stand-alone product, it may be considered to some extent that all or part of the technical solution of the present invention (for example, a part contributing to the prior art) is It is embodied in the form of computer software products. The computer software product is typically stored in a computer readable non-volatile storage medium, including instructions for causing a computer device (which may be a personal computer, server, or network device, etc.) to perform all of the methods of various embodiments of the present invention. Or part of the steps. The foregoing storage medium includes various media that can store program codes, such as a USB flash drive, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.

The above is only the specific embodiment of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art can easily think of changes or substitutions within the technical scope of the present invention. It should be covered by the scope of the present invention. Therefore, the scope of the invention should be determined by the scope of the claims.

Claims

claims

1. A machine-to-machine M2M network information reply method, characterized in that the M2M network includes a target general business entity and at least one application, and the method includes:

The target general business entity receives service request information, and the service request information includes a specific time;

The target general business entity sends confirmation information to the application within the specific time.

2. The information reply method of the M2M network according to claim 1, characterized in that the target general service entity receives the service request information, including: the target general service entity receives the first service request information from the application.

3. The information reply method of the M2M network according to claim 1, characterized in that the M2M network further includes a local universal service entity, and the target universal service entity receives the service request information, including: the target universal service entity Receive second service request information generated by the local general service entity based on the first service request information received from the application;

The target general business entity sends confirmation information to the application within the specific time, including:

Within the specific time, the target universal business entity sends confirmation information to the application through the local universal business entity.

4. The information reply method of the M2M network according to claim 3, characterized in that the first service request information also includes a request type RCAT and a tolerable request processing delay time TRPDT, and the target general service entity receives The second service request information generated by the local universal service entity according to the first service request information received from the application includes: When the communication link corresponding to the RCAT has been established, the target universal The business entity receives the second service request information immediately sent by the local general business entity; or

When the communication link corresponding to the RCAT is not established, if the local processing time of the local general service entity does not exceed the TRPDT, the target general service entity receives the delay sent by the local general service entity. The second service request information, the local processing time is Claims

The time when the local universal service entity establishes the communication link; if the local processing time of the local universal service entity exceeds the TRPDT, the local universal service entity returns failure information to the application.

5. The information reply method of the M2M network according to claim 1, characterized in that the M2M network further includes a local universal service entity, and the target universal service entity receives the service request information, including: the target universal service entity receiving second service request information aggregated by the local general service entity based on a plurality of first service request information received from the application;

In the remaining time, after the target general business entity aggregates each confirmation information into aggregate information, it sends the aggregate information to the local general business entity, and the local general business entity separates the aggregate information and then separately Send corresponding confirmation information to each of the applications, and the remaining time is determined by the local general business entity according to the specific time included in the plurality of first service request information and the local processing time of the local general business entity, The aggregate information includes the individual confirmation information.

6. The information reply method of the M2M network according to claim 5, characterized in that the first service request information also includes RCAT and TRPDT, and the target general service entity receives the information from the local general service entity according to the Apply second service request information aggregated from multiple received first service request information, including:

When the communication link corresponding to the RCAT is not established, if the local processing time of the local general service entity does not exceed the TRPDT, the local general service entity determines the delay time, and the local general service entity determines the delay time. Aggregate the plurality of first service request information received from the application within the delay time, and the target universal service entity receives the aggregated second service request information from the local universal service entity, and the The local processing time is the time for the local general service entity to establish the communication link. claims

7. An information reply method for an M2M network, characterized in that the M2M network includes a target general service entity and at least one application, and the method includes:

The application sends first service request information, and the first service request information includes a specific time;

The application receives the confirmation information returned by the target general business entity according to the specific time within the specific time.

8. The information reply method of the M2M network according to claim 7, characterized in that: the application sends the first service request information, including: the application sends the first service request information to the target general service entity;

The application receiving the confirmation information returned by the target general business entity according to the specific time within the specific time includes: the application receiving the confirmation information from the target general business entity within the specific time.

9. The information reply method of the M2M network according to claim 7, characterized in that the M2M network further includes a local general service entity, and the application sends the first service request information, including: the application sends the first service request information to the local The universal business entity sends the first service request information, so that the local universal business entity sends the second service request information to the target universal business entity according to the first service request information;

The application receiving the confirmation information returned by the target general business entity according to the specific time within the specific time includes: the application receiving the target general business entity from the local general business entity within the specific time. The confirmation message returned.

10. A general business entity of an M2M network, characterized by including:

A receiving module, configured to receive service request information, where the service request information includes a specific time; a sending module, in communication with the receiving module, used to send confirmation information to the application within the specific time.

11. The general business entity of the M2M network according to claim 10, characterized in that, claims

The receiving module is also configured to receive the first service request information from the application.

12. The universal service entity of the M2M network according to claim 10, wherein the receiving module is further configured to receive the second service request generated by the local universal service entity according to the first service request information received from the application. Business request information;

The sending module is also configured to send confirmation information to the application through the local general business entity within the specific time.

13. The general service entity of the M2M network according to claim 12, wherein the first service request information also includes a request type RCAT and a tolerable request processing delay time TRPDT, and the receiving module is used to When the communication link corresponding to the RCAT has been established, receive the second service request information immediately sent by the local universal service entity, and the receiving module is also configured to receive the second service request information sent by the local universal service entity according to the request from the local universal service entity. The second service request information generated using the received first service request information; or

The receiving module is also configured to receive all delayed transmissions of the local general service entity if the local processing time of the local general service entity does not exceed the TRPDT when the communication link corresponding to the RCAT is not established. The second service request information.

14. The universal service entity of the M2M network according to claim 10, wherein the receiving module is configured to receive the aggregation of a plurality of first service request information received by the local universal service entity from the application. Second business request information;

The sending module is also configured to aggregate each confirmation information into aggregated information within the remaining time, and then send the aggregated information to the local universal business entity, and the local universal business entity separates the aggregated information. Corresponding confirmation information is sent to each of the applications respectively, and the remaining time is determined by the local general business entity according to the specific time included in the plurality of first service request information and the local processing time of the local general business entity. , the aggregate information includes the respective confirmation information.

15. The general business entity of the M2M network according to claim 14, characterized in that, claims

The first service request information also includes RCAT and TRPDT. When the communication link corresponding to the RCAT is not established, if the local processing time of the local universal service entity does not exceed the TRPDT, the local universal service entity The business entity determines a delay time. The local universal business entity aggregates a plurality of first service request information received from the application within the delay time. The receiving module is also configured to collect the first service request information from the local universal business entity. The service entity receives the aggregated second service request information, and the local processing time is the time when the local general service entity establishes the communication link.

16. An application of M2M network, characterized by including:

A receiving module, configured to receive confirmation information returned by the general business entity according to a specific time within the specific time.

17. The application of the M2M network according to claim 16, characterized in that: the sending module is also used to send the first service request information to the general service entity; the receiving module is also used to: Receive the confirmation information from the general business entity within the specified time.

18. The application of the M2M network according to claim 16, characterized in that the M2M network further includes a local universal service entity, and the sending module is further configured to send the first service request information to the universal service entity. , so that the local general service entity sends second service request information to the general service entity according to the first service request information;

The receiving module is also configured to receive the confirmation information returned by the general business entity from the local general business entity within the specific time.

19. An M2M network, characterized by including: a target general business entity and at least one application;

The target universal service entity adopts the universal service entity of the M2M network as described in any one of claims 10 to 15; claims

The application adopts the application of the M2M network as described in any one of claims 16 to 18.

20. The M2M network according to claim 19, further comprising: a local universal service entity, configured to receive the first service request information sent by the application; and send a second service request to the target universal service entity. information.