WO2018112327A1 - Methods of concurrency control for block transfer in coap publish-subscribe architecture - Google Patents

Abstract

Improvements are made to the CoAP pub/sub architecture to minimize waste associated with excess data exchanging. In one aspect, a publish control policy (PCP) is introduced to define how data should be published to a given topic. In another aspect, three new parameters are introduced to the PUBLISH operation to control the initiation of a new block transfer process when attempting to publish data and terminate ongoing block transfers attempting to publish data. In yet another aspect, two new parameters and a new notification scheme are introduced to the block transfer process of a SUBSCRIBE operation to control the notification preference of a subscriber for a block transfer process and terminate ongoing block transfers attempting to notify a subscriber of old published data. In another aspect, two new pairs of parameters are introduced to allow clients to query the number of publishers and subscribers associated with a given topic.

Description

METHODS OF CONCURRENCY CONTROL FOR BLOCK TRANSFER

IN COAP PUBLISH-SUBSCRIBE ARCHITECTURE

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims benefit of U.S. Provisional Patent Application Serial No. 62/434,633, filed December 15, 2016 and claims benefit of U.S. Provisional Patent Application Serial No. 62/440,829, filed December 30, 2016, the disclosures of which are hereby

incorporated by reference as if set forth in their entireties.

BACKGROUND

[0002] The Internet Engineering Task Force (IETF) Constrained RESTful

Environments (CoRE) Working Group (IETF CoRE) has developed Constrained Application Protocol (CoAP) (RFC7252). CoAP is an application protocol for use with constrained nodes or apparatuses and constrained networks, such as wireless-sensor networks and other Internet of Things (IoT) systems.

[0003] The interaction model of CoAP is similar to the client/server model of

Hypertext Transfer Protocol (HTTP). CoAP is a single protocol that uses a two-layer approach, as shown in FIG. 1 : a CoAP Messages Layer for handling UDP, though with different reliability requirements than typical UDP; and a Request/Response Layer that uses Methods - GET, PUT, POST, DELETE - and Request/Response codes for handling the asynchronous nature of the network interactions. In implementation, both the messages layer and the request/response layer are features of the CoAP header.

[0004] CoAP defines four types of messages: CON, NON, ACK, and RST. A

Confirmable message (CON) may be retransmitted using a default timeout and exponential backoff between retransmissions until the recipient sends back an Acknowledgement message (ACK) with the same Message ID. FIG. 2 shows an example of a CON with ACK of the same Message ID 0x7d34. A Non-confirmable message (NON) does not require reliable transmission. For example, each single measurement out of a stream of sensor data can be sent as a NON. NONs are not acknowledged, but still have a Message ID for duplicate detection. An example of a NON with Message ID 0x0 laO is shown in FIG. 3. An ACK may be used to acknowledge receipt of a CON. A Reset message (RST) may be used when a recipient is not able to process a NON.

[0005] CoAP defines four methods: GET, POST, PUT, and DELETE.

[0006] The GET method retrieves a representation for the information that currently corresponds to the resource identified by the request Uniform Resource Identifier (URI). Upon success, a 2.05 (Content) or 2.03 (Valid) response code should be present in the response.

[0007] The POST method requests that the representation enclosed in the request be processed. The actual function performed by the POST method may be determined by the origin server and dependent on the target resource. POST usually results in a new resource being created or the target resource being updated.

[0008] The PUT method requests that the resource identified by the request URI be updated or created with the enclosed representation. If a resource exists at the request URI, the enclosed representation should be considered a modified version of that resource, and a 2.04 (Changed) response code should be returned. If no resource exists, then the server may create a new resource with that URI, resulting in a 2.01 (Created) response code.

[0009] The DELETE method requests that the resource identified by the request URI be deleted.

[0010] Regarding the CoAP Request/Response Layer shown in FIG. 1, CoAP request and response semantics are carried in CoAP messages. A Token is used to match responses to requests independently from the underlying messages. Typically, there are two cases: a synchronous case, and an asynchronous case.

[0011] FIG. 4 shows an example of the synchronous case. In the synchronous case, when a request is carried in a CON, the response to this request will be directly carried in the resulting ACK. This is called a "piggy-backed response." If the CoAP Client that issued the request in a CON does not receive an ACK within an ACK timer, it will retransmit the request using an exponential back-off algorithm and double the ACK timer to wait for the CoAP Server's Response. If a request is sent in a NON, then the response is sent using a new NON.

[0012] FIG. 5 shows an example of the asynchronous case. In the asynchronous case, when a request is carried in a CON, the client will receive an ACK without a payload. Later, when the requested content becomes available, the server will issue a new CON that includes the response to the client's initial CON request. [0013] CoAP defines a number of options that may be included in a message. Each Option instance in a message specifies the Option Number of the defined CoAP Option, the length of the Option Value, and the Option Value itself. Option Value can be empty, opaque, an unsigned integer, or a string. Both requests and responses may include a list of one or more Options. CoAP defines a single set of Options that are used in both requests and responses.

[0014] Options are either "critical" or "elective". An Option is identified by an Option Number, which also provides some additional semantics information. For example, odd numbers indicate a critical Option, while even numbers indicate an elective Option. The difference between these is how an Option unrecognized by an endpoint is handled. Upon reception, unrecognized Options of class "elective" must be silently ignored. Unrecognized Options of class "critical" that occur in a CON request must cause the return of a 4.02 (Bad Option) response. Unrecognized Options of class "critical" that occur in a CON response, or piggy -backed in an ACK, must cause the response to be rejected. Unrecognized Options of class "critical" that occur in a NON must cause the message to be rejected.

[0015] Table 1 displays the properties of CoAP Options using two examples defined in the current CoAP block-transfer specification: Blockl and Block2.

Table 1. Example—Block Option Numbers

[0016] The CoAP Options are maintained by an Internet Assigned Numbers Authority (IANA) registry. The IANA policy for future additions to this sub-registry is split into three tiers: range [0-255] is reserved for Options defined by the IETF; range [256-2047] is reserved for commonly used Options with public specifications; and range [2048-64999] is for all other Options, including private or vendor-specific Options.

[0017] CoAP is a Representational State Transfer (RESTful) transfer protocol for use with constrained nodes or apparatuses and networks. Basic CoAP messages work well for small data transfers, such as temperature sensors, light switches, and similar building-automation devices. Occasionally, however, applications need to transfer larger payloads. For example, in an e-health application, it may be desirable to update the firmware of a watch from time to time so that the watch can work properly with newly added features.

[0018] Whereas protocols like HTTP may rely on transport protocols like TCP to perform the low-level work, CoAP is based on simpler datagram transports like UDP. HTTP relies on TCP to divide large payloads into multiple packets and ensure that all packets arrive and are handled in the correct order. In contrast, UDP limits the maximum size of resource representations that can be transferred without too much fragmentation.

[0019] To avoid problems with IP fragmentation, existing CoAP defines "Block" Options for transferring multiple blocks of information from a resource representation, and the transferring occurs using multiple request-response pairs. For example, if a CON from a client to a server includes a GET request, the server will immediately send back an ACK with the requested payload piggy-backed in the message. In such a manner, this existing block transfer mechanism may be thought of as part of the Messages Layer of CoAP where the Messages Layer is exactly aligned with the Request/Response Layer.

[0020] Accordingly, the concept of "request-response" pairs as defined in block transfers refers to the messaging paradigm of the CoAP Messages Layer: a "request message" typically refers to a CON with an included GET, PUT, or POST request; and a "response message" typically refers to a response piggy -backed in the corresponding ACK. Further, the term "payload" refers to the actual content of a single CoAP message, while the term "body" refers to the entire resource representation being transferred in block-wise fashion.

[0021] As described above, CoAP has two Block Options defined to enable block-wise transfers: "Blockl" and "Block2". Generally both Blockl and Block2 Options may be present in both request and response messages, and their usages may vary depending on context. The Blockl Option pertains to the request payload, and the Block2 Option pertains to the response payload. For example, if a Block2 is included in the response of a GET request, it describes the current payload in this response and is referred to as "descriptive usage." However, when a Block2 is included in a GET request, it provides additional control over how the payload will be formed in the response to the GET request and is referred to as "control usage."

[0022] Each Block Option may need to include three items of information: block size ("SZX"); whether more blocks will follow the current message's block ("M"); and the relative number of the block within a sequence of blocks with the given size ("NUM"). The structure of a Block Option is shown in FIG. 6.

[0023] The block size, SZX, is represented as a three-bit unsigned integer, and the allowed values of SZX are [0-6]. The block size is found by calculating 2^{(SZX + 4)}, making the minimum block size 2⁽⁰⁺⁴⁾ = 16 and the maximum block size 2⁽⁶⁺⁴⁾ = 1024.

[0024] The "more blocks" flag, M, is represented as a single bit, meaning it may only have a value of 0 or 1. For "descriptive usage," when unset (M = 0), M indicates that the payload of this message is the last block in the body; when set (M=l), M indicates that there are one or more additional blocks of the body available for transfer. When a Blockl or Block2 is used for "control usage," then M has different usage rules as defined by the CoAP specification.

[0025] The block number, NUM, indicates the block number being requested or provided. A message having NUM = 0 indicates the first block of a resource body.

[0026] FIG. 7 shows an example illustrating how to use Block2 in GET requests and responses. In this example, the whole resource body has been retrieved from Server by using three request-response pairs in a block transfer process. FIG. 7 shows Block2 usage in both the descriptive usage context and the control usage context.

[0027] In the descriptive usage context with Block2 Option in a response message, NUM = 0 indicates that the ACK payload contains the first block, M = 1 indicates that more blocks need to be transferred, and SZX = 128 indicates that the block size is 128 bytes. In implementation, SZX = 3 because 2⁽³⁺⁴⁾ = 128, but this has been simplified for illustration in FIG. 7. Further, because M is set, SZX must be equal to the size of the payload for compilation by the Client.

[0028] In the control usage context with Block2 Option in a request message, NUM = 1 indicates that Client is requesting the second block of the body, M has no function and is set to 0, and SZX = 128 indicates that the Client expects the block size of the next block to be 128. In this context generally, SZX will likely be the size of the previous block, or SZX will be a suggested block size if the Client has not yet received any blocks. As shown in FIG. 7, the Server first proposed a block size of 128 in Message (MID) 1234; the Client then followed the suggestion by setting SZX = 128 in the subsequent GET requests. Similarly, FIG. 8 shows an example illustrating how to use the Blockl Option in PUT requests and responses. [0029] CoAP uses a request/response model where clients make requests to servers in order to request actions on resources. Depending on the situation, the same device may act either as a server or a client. A class of constrained devices includes devices that are intended to run for years from a small battery and those devices that run by scavenging energy from their environments. These devices have limited reachability because they spend most of their time in a sleeping state with no network connectivity.

[0030] Accordingly, an extension to CoAP enables publish-subscribe ("pub/sub") communication using a "broker node" that enables store-and-forward messaging between two or more nodes or apparatuses. FIG. 9 shows the architecture of a CoAP pub/sub service. CoAP pub/sub clients interact with a CoAP pub/sub broker through the CoAP pub/sub interface, which is hosted by the broker. The CoAP pub/sub broker performs a store-and-forward function for data transferring between CoAP pub/sub clients. One or more clients may subscribe to an interested topic. Other clients may publish related data to that topic, and the broker will forward the published data to the subscribing clients.

[0031] The CoAP pub/sub architecture may involve several entities, including a CoAP pub/sub broker, a CoAP pub/sub client, a CoAP pub/sub topic, and a CoAP pub/sub function set.

[0032] A CoAP pub/sub broker is a CoAP server that may expose a CoAP pub/sub interface for clients to use to initiate publish-subscribe interactions. The broker should be network-accessible by clients and should also have sufficient resources (e.g., storage, bandwidth, etc.) to host CoAP resources on behalf of the clients. In some CoAP pub/sub architectures, the broker should additionally have sufficient resources to also store buffer messages on behalf of the clients.

[0033] A CoAP pub/sub client may interact with a CoAP pub/sub broker using the aforementioned CoAP pub/sub interface. Clients may initiate interactions with the CoAP pub/sub broker, which reacts to the interactions. A client acting as a data provider (e.g., sensor clients) may publish data to the broker as a "Publisher," and a client acting as a data consumer or "Subscriber" (e.g., a user app) may read from or subscribe to categorized data from the broker. Data is typically categorized by topic.

[0034] Clients and brokers may use CoAP pub/sub topics to identify a particular resource or object in a pub/sub system. For example, a topic hosted at a broker may be used to describe "temperature" such that temperature sensors may publish their measurements to this topic. A CoAP pub/sub topic may have a reference path using URI path construction, link attributes, and a representation of a value with specified content-formats.

[0035] In order to utilize the CoAP pub/sub architecture, interfaces between a CoAP pub/sub broker and CoAP pub/sub clients have been defined. These interfaces may be referred to as a "CoAP pub/sub function set." In particular, a CoAP pub/sub broker should support the DISCOVER, CREATE, PUBLISH, SUBSCRIBE, UNSUBSCRIBE, READ, and REMOVE operations.

[0036] CoAP pub/sub clients may discover CoAP pub/sub brokers by using CoAP Simple Discovery or through a Resource Directory (RD). FIG. 10 shows an example of a client discovering a local pub/sub function set using CoAP Simple Discovery. A broker wishing to advertise the CoAP pub/sub function set for Simple Discovery or through a Resource Directory must use the link relation rt="core.ps". A broker may advertise its supported content formats and other attributes in the link to its pub/sub function set.

[0037] A CoAP pub/sub broker may offer the DISCOVER interface to enable Clients to find topics of interest, either by topic name or by link attributes which may be registered when the topic is created. FIG. 11 shows an example of a client looking for a topic with a resource type (rt) of "temperature" in the pub/sub function set "/ps" using the DISCOVER interface. The client then receives the URI of the resource and its content-format.

[0038] Clients may create topics on the broker using the CREATE interface. A client wishing to create a topic should use a CoAP POST to the pub/sub function set location with a payload indicating the desired topic. FIG. 12 shows an example of a topic called "topicl " being successfully created. The broker should return a response code of "2.01 Created" if the topic is created and return the created relative URI path via CoAP Location-Path options.

[0039] A CoAP pub/sub client may use the PUBLISH interface for updating topics on the broker. The client should use the PUT method to publish state updates (i.e., new data) to the CoAP pub/sub broker. An example of a CoAP pub/sub client updating the temperature topic of FIGs. 11-12 is shown in FIG. 13. The broker should notify the clients subscribed on a particular topic each time the broker receives a PUBLISH on that topic. A broker should use a CoAP notification to notify subscribed clients. A CoAP block transfer may be used when a client is publishing a large size of data. Therefore, the PUBLISH operation may need to rely on a CoAP block transfer mechanism for data publishing. [0040] CoAP pub/sub clients may subscribe to topics on the broker using CoAP

Observe, as defined by the CoAP Observe specification. A CoAP pub/sub client wishing to subscribe to a topic on a broker should use a "SUBSCRIBE" operation, a CoAP GET with Observe registration. The broker may then add the client to a list of observers. FIG. 14 shows an example of Client-2 subscribing to "topicl " and receiving a response from the broker. The response from the broker includes the last stored value associated with the topicl . After Client- 1 updates topicl with a PUBLISH operation, the broker notifies Client-2 of the update with a subsequent notification. Similarly to the PUBLISH operation, when subscribers get notifications for a large data update after performing a SUBSCRIBE, the subscribers may also need to rely on a CoAP block transfer mechanism to retrieve the large data update.

[0041] The UNSUBSCRIBE operation allows a CoAP pub/sub client that is subscribed to a topic to unsubscribe and stop receiving update notifications. The READ operation allows a CoAP pub/sub client to receive information about a topic without formally subscribing to the topic. The READ operation may be useful for applications where a CoAP client may not be capable of receiving continual updates to a topic. The REMOVE operation removes a topic from the CoAP pub/sub broker.

[0042] There are currently other pub/sub protocols, such as MQTT, RabbitMQ, and the like. For example, in MQTT, an MQTT Client A can subscribe to a topic (i.e., resource) maintained at an MQTT Server, which acts as a broker. When other MQTT clients publish their topics, including resource values, to the M2M Server that matches the subscribed topic from MQTT Client A, the MQTT Server will send notifications (i.e., resource values) to the MQTT Client A. However, MQTT and other similar pub/sub protocols do not include a block transfer mechanism.

[0043] In a 3GPP system, "non-IP" data is data that is unstructured to the 3GPP system. The data may in fact be IP -based; however, the 3GPP system is not aware of the data's structure and protocol(s). The existing 3GPP specification describes how non-IP data packets may be sent to and from a Service Capability Server (SCS) or Application Server (AS) (i.e., M2M Server, Infrastructure Common Services Entity (IN-CSE)) and a user equipment (UE) via the Service Capability Exposure Function (SCEF) and Mobility Management Entity (MME). The 3 GPP specification also describes how non-IP data packets can be sent to/from an SCS/AS and a UE via the Packet Data Network (PDN) Gateway (P-GW). The "non-IP" data may be tunneled from the P-GW to the SCEF.

[0044] A mobile network operator may wish to limit the packet size of "non-IP" packets that are passed through the network. One reason for limiting the packet size is to avoid packet fragmentation when IP -based protocols are used to transport the "non-IP" packets through their network. The existing 3GPP specification describes how the network can use 3GPP session management signaling to inform a UE of the maximum packet size. Session management signaling is used to provide the UE with Protocol Configuration Options (PCO) that contain a Link Maximum Transmission Unit (MTU) size. When the session management signaling is associated with a non-IP PDN connection, the UE treats the Link MTU size as the maximum non-IP packet size. PCO is defined in the 3GPP specification. The PCO may be transferred from the SCEF to the UE. The PCO information may be provided by the network to the SCEF, or the SCEF could choose how some PCO values are set.

SUMMARY

[0045] CoAP' s block transfer mechanism is needed when M2M/IoT applications intend to transfer large payloads using the CoAP pub/sub architecture. However, the existing solution may not operate in an optimal way. In particular, the existing pub/sub architecture does not consider the waste associated with continuing block transfers of data when newer or better data has been published and the waste associated with publishing data to a topic for which there are no subscribers. Disclosed herein is a new solution to concurrency-control and usefulness metrics in the CoAP pub/sub architecture. The disclosed solution considers the time and energy costs associated with the transfer of data that is no longer useful.

[0046] Embodiments disclosed herein provide modifications to the existing pub/sub architecture to minimize waste associated with excess data exchanging. In one aspect, a publish control policy (PCP) is introduced to define how data should be published to a given topic. In another aspect, three new parameters are introduced to the PUBLISH operation to control the initiation of a new block transfer process when attempting to publish data and terminate ongoing block transfers attempting to publish data. In yet another aspect, two new parameters and a new notification scheme are introduced to the block transfer process of a SUBSCRIBE operation to control the notification preference of a subscriber for a block transfer process and terminate ongoing block transfers attempting to notify a subscriber of old published data. In another aspect, two new pairs of parameters are introduced to allow clients to query the number of publishers and subscribers associated with a given topic.

[0047] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to limitations that solve any or all disadvantages noted in any part of this disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

[0048] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:

[0049] FIG. 1 illustrates the interaction model of the CoAP protocol;

[0050] FIG. 2 shows an example message flow in accordance with the CoAP protocol;

[0051] FIG. 3 shows another example message flow in accordance with the CoAP protocol;

[0052] FIG. 4 shows another example message flow in accordance with the CoAP protocol;

[0053] FIG. 5 shows another example message flow in accordance with the CoAP protocol;

[0054] FIG. 6 illustrates the format of CoAP Block Options, Blockl and Block2;

[0055] FIG. 7 shows an example message flow in accordance with using the CoAP Block2 Option;

[0056] FIG. 8 shows an example message flow in accordance with using the CoAP Blockl Option;

[0057] FIG. 9 illustrates the basic interaction model of the CoAP pub/sub architecture;

[0058] FIG. 10 shows an example message flow of a client discovering a local pub/sub function set;

[0059] FIG. 11 shows an example message flow of a client using the CoAP pub/sub DISCOVER interface; [0060] FIG. 12 shows an example message flow of a CoAP pub/sub CREATE operation;

[0061] FIG. 13 shows an example message flow of a CoAP pub/sub PUBLISH operation;

[0062] FIG. 14 shows an example message flow of a CoAP pub/sub client subscribing to "topicl " at a broker and receiving a response from the broker, with a subsequent notification of a data update;

[0063] FIGs. 15A and 15B illustrate an example use case and call flow of two clients publishing to a broker;

[0064] FIG. 16 shows an example message flow of a CoAP pub/sub CREATE operation with PCP parameters;

[0065] FIG. 17 shows an example message flow of a PCP update procedure for a CoAP pub/sub topic using the DELETE and CREATE operations;

[0066] FIG. 18 shows an example message flow of a PCP update procedure for a CoAP pub/sub topic using the UPDATE operation;

[0067] FIG. 19 shows an example message flow of the new public control process using two new parameters associated with the PUBLISH operation;

[0068] FIG. 20 shows a flow diagram of a broker's decision making process to publish or not publish data in accordance with an example embodiment;

[0069] FIGs. 21 A and 21B show an example message flow for using a new parameter to terminate a block transfer during a PUBLISH operation;

[0070] FIG. 22 shows an example message flow for using a new parameter to select a notification scheme during a SUBSCRIBE operation;

[0071] FIGs. 23 A and 23B show an example message flow using a new notification scheme to update subscribing clients and a new parameter for terminating a notification update;

[0072] FIGs. 24A, 24B, and 24C show an example message flow for using a new parameter to terminate a block transfer during a subscribing client's notification update;

[0073] FIG. 25 shows an example message flow for using new parameters to query the number of publishing clients and subscribing clients for a given topic;

[0074] FIG. 26 illustrates an example use case and message flow using the new parameters shown in FIG. 19 and FIG. 25; [0075] FIG. 27 shows an example graphical user interface (GUI) in accordance with an example embodiment;

[0076] FIG. 28A is a system diagram of an example machine-to-machine (M2M), Internet of Things (IoT), or Web of Things (WoT) communication system in which one or more disclosed embodiments may be implemented;

[0077] FIG. 28B is a system diagram of an example architecture that may be used within the M2M/IoT/WoT communications system illustrated in FIG. 28 A;

[0078] FIG. 28C is a system diagram of an example communication network apparatus, such as an M2M/IoT/WoT device, gateway, or server that may be used within the

communications system illustrated in FIGs. 28 A and 28B; and

[0079] FIG. 28D is a block diagram of an example computing system in which a node or apparatus of the communication system of FIGs. 28 A and 28B may be embodied.

DETAILED DESCRIPTION

[0080] An extension to CoAP enables publish-subscribe communication using a "broker node" that enables store-and-forward messaging between two or more nodes. In the CoAP pub/sub architecture, the data from publishers will be published to different topics at a broker. Subscribers may then subscribe to topics based on their interests. In the existing CoAP pub/sub architecture, multiple publishers may publish their data to the same topic. For example, temperature sensors in a given area may each publish their data to the same topic storing temperature readings for that area. A publisher may generate data having a large size, which may require the publisher to use a CoAP block transfer process to complete the PUBLISH operation. Subscribers may then need to use a CoAP block transfer process when receiving updates after performing the SUBSCRIBE operation. However, the existing CoAP block transfer mechanism may not work in an optimal way with the CoAP pub/sub architecture because the existing CoAP pub/sub architecture lacks concurrency-control.

[0081] To illustrate the deficiencies of the existing CoAP block transfer mechanism with the CoAP pub/sub architecture, consider the following use case, shown in FIGs. 15A and 15B. Organizations or various parties may deploy outdoor cameras (as IoT devices) for various purposes, such as traffic control and anti-theft monitoring, among other uses. As shown in FIGs. 15A and 15B, assume a CoAP pub/sub architecture has been deployed and Topic-A holds data regarding "security monitoring for Region-1" and is hosted by the broker, which may be a network gateway. Accordingly, cameras deployed in Region-1 are potential publishers to Topic- A and they could publish their image data to this topic. For example, there are two cameras in FIGs. 15A and 15B, Publisher-1 and Publisher-2. In particular, Publisher-1 is a low-resolution camera while Publisher-2 is a high-resolution camera.

[0082] Initially, Publisher-1 first publishes an image, Image- 1, to Topic-A through a PUBLISH operation in which a CoAP block transfer is utilized and Image- 1 has been split into five blocks for the transfer. At a later time, after the first two blocks of Image- 1, Block-0 and Block- 1, have been transferred to the broker by Publisher-1, Publisher-2 attempts to publish Image-2 to Topic-A. The broker is aware that images from Publisher-2 are high-resolution images. Such awareness may be based on historical publishing records or additional data sent to the broker during initial setup. Both Image- 1 and Image-2 may describe the most-current view of Region-1 within a short time interval, meaning both images have the same usefulness. As a result, the broker may decide to replace the partially-delivered Image- 1 with Image-2 if current network conditions are amenable to transferring large-size data because Image-2 has better quality and resolution than Image-1. Thus, Image-1 will become useless once Image-2 is published to the broker, and Publisher-1 should not continue to transfer the remaining blocks of Image-1 to the broker in order to save unnecessary communication cost. However, there are currently no mechanisms for addressing concurrency control -related issues for the CoAP block transfer process when it is used with the CoAP pub/sub architecture.

[0083] The above use-case illustrates a concurrency-control problem in the CoAP pub/sub architecture, and solutions to that concurrency-control problem may include several technical aspects relating to the CREATE, PUBLISH, and SUBSCRIBE operations.

[0084] The existing CoAP pub/sub architecture does not include a publish control policy governing how data should be published into a given topic. For example, when creating a topic using a CREATE operation, it is not possible for a broker to stop or decline a publisher from publishing to a topic.

[0085] Further, PUBLISH and SUBSCRIBE operations that utilize CoAP block transfers take more time than non-block transfers, which may result in inefficiency in the form of wasted request/response exchanges if a newer or better-suited published result becomes available at the broker. [0086] The existing CoAP pub/sub architecture does not include a mechanism for controlling the initiation of a new block transfer process for a PUBLISH operation, and when a publisher uses a block transfer process to send blocks through multiple PUT requests to the broker, the broker does not currently have an available mechanism to explicitly terminate the ongoing block transfer. Similarly, when a broker is sending a notification update to a subscriber, there is no available mechanism for the broker to terminate an ongoing block transfer process used via the SUBSCRIBE operation.

[0087] When a broker sends a notification update to a subscriber using a block transfer, two different approaches may be used based on the scenario and application requirements, data- by-data or block-by-block. However, the existing CoAP pub/sub architecture does not include a method for allowing a subscriber to choose its delivery preference for a given topic.

[0088] In the existing CoAP pub/sub architecture, publishers and subscribers know little information about each other. There is not currently a mechanism for a client to query useful information about the publishers and subscribers for a given topic. As a result, clients are not aware of the status of the broker, which may lead to inefficiencies such as the publisher publishing too often.

[0089] There are at least four aspects to the solution disclosed herein. In a first aspect, a "publish control policy" (PCP) is introduced to define how data should be published to a given topic. Typically, a PCP may be defined based on specific application requirements or business logics. In a second aspect, three new parameters are introduced to the PUBLISH operation to control the initiation of a new block transfer process when attempting to publish data and terminate ongoing block transfers attempting to publish data. In a third aspect, two new parameters are introduced to the block transfer process of a SUBSCRIBE operation to control the notification preference of a subscriber for a block transfer process and terminate ongoing block transfers attempting to notify a subscriber of published data. A new procedure is introduced for the block-by-block notification scheme of a subscriber. In a fourth aspect, two new pairs of parameters are introduced to allow clients to query the number of publishers and subscribers associated with a given topic. Each of these aspects is described more fully below.

Publish Control Policy

[0090] In a first aspect, a PCP is introduced to enable concurrency control in the CoAP pub/sub architecture. Concurrency control attempts to eliminate problems associated with multiple participants intending to operate on a shared entity or resource at the same time. In the example shown in FIGs. 15A and 15B, the concurrency problem exists when multiple cameras are attempting to publish their respective images through a block transfer to the same topic at the same time. Concurrency problems are common in the CoAP pub/sub architecture because block transfers are needed when publishers intend to publish their large-size data to the same topic, and each block transfer process includes a number of time-consuming request-response messages, which increases the probability that two block transfers may happen during an overlapping time interval.

[0091] As described above, different publishers may publish similar data to the same topic. Because the multiple pieces of data have similar usefulness, subscribers need only receive one of them. Accordingly, there should be certain publish control policies in the system so that publishers may contribute and publish their data in a more efficient way. In particular, from a data-value standpoint, each topic should have a way to evaluate the potential value of the data published to itself, the value of which will become the major criteria when enforcing a publish control policy. For example, in the example shown in FIGs. 15A and 15B both cameras, Publisher- 1 and Publisher-2, may publish their image data to Topic- A, but if the two images from the different cameras have the same usefulness, only one should be published to the topic. However, there is currently no mechanism in the existing CoAP pub/sub architecture to define a PCP or other constraints regarding how data should be published to a given topic.

[0092] A new concept is proposed to enable a topic to have a PCP. Typically, a PCP may be defined based on specific application requirements or business logics. For example, using the example shown in FIGs. 15A and 15B, the PCP of Topic-A may be "if two images from different cameras have the same usefulness and intend to be published to Topic-A around the same time, only the one having high-resolution should be allowed." For a given topic, the PCP can be dynamically changed based on various needs. For example, if the network condition of the broker becomes congested, meaning only limited bandwidth is available for

communicating with the broker's clients, the PCP of Topic-A could be changed to "if two images from different cameras have the same usefulness and intend to be published to Topic-A around the same time, only the one having low-resolution should be published (in order to save network bandwidth)." [0093] Table 2 shows an example specification of a PCP for a given topic, in which a number of items have been defined to describe what kind of data should be published to the topic and how to manage publishing priority, among other things. Note that, a PCP can be easily extended based on needs.

Table 2. An Example Specification of a PCP

typically use the information in this image has higher priority

metadata when deciding whether to allow

new data to publish. This field enables

the CoAP protocol to allow upper-layer

applications to specify any policy.

Last Update Time

This metadata is used to describe the last

for Publishing 03-26-2016 18:55

time that this PCP was updated.

Policy

This metadata is used to describe the

Latest Data latest data that is already completely

Completely Stored stored in this topic. It is not describing Data-0

in Topic Now data that is currently being published

through an ongoing block transfer.

Generation Time: 04-16-2016

Metadata for Latest This metadata is used to describe related 18:55

Data Completely information about the latest data that is

Resolution: High

Stored in Topic Now already completely stored in this topic.

Published by : Publisher-2

[0094] Typically, for a given topic, its PCP may be defined by the client who created the topic. Accordingly, several new parameters may be carried in the request message of a CREATE operation in order to describe the PCP. Those new parameters are included in Table 2 and include Topic Description (t_d), Allowed Data Type (a d t), Maximum Data Size (m_d_s), and Publishing Policy Description (p_p_d). Upon receiving a CREATE request at the broker, the broker will generate a topic with a topic ID/name and also generate a PCP for that topic by using the information carried in the above parameters. The detailed procedure for this process is shown in FIG. 16.

[0095] The process for updating the PCP for a given topic is slightly more difficult. Because an "update" operation does not exist in the current CoAP pub/sub architecture, the PCP update operation will be implemented in a "first-delete-then-create-again" manner. Accordingly, the broker needs to support the PCP update operation as an "atomic" operation; during this process, certain lock mechanisms need to be applied on this topic to avoid losing data. The parameters to be updated in a PCP may be carried in the request message of the CREATE operation after the current topic first gets deleted, shown in FIG. 17.

[0096] Alternatively, a new primitive may be introduced, UPDATE, for the CoAP pub/sub architecture, which could be used for updating a topic. Accordingly, the parameters to be updated in a PCP may also be carried in the request message of the new UPDATE operation, shown in FIG. 18.

[0097] Finally, to make it generally applicable, the PCP concept for the CoAP pub/sub architecture may also be used in circumstances where block transfer is not involved.

PUBLISH Operation

[0098] In a second aspect, three new parameters are introduced to the PUBLISH operation to control the initiation of a new block transfer process when attempting to publish data and terminate ongoing block transfers attempting to publish data.

[0099] Once a PCP has been defined for a given topic, it can be used to control whether a publisher should publish its new data to the topic and further control whether a new block transfer should be initiated for a PUBLISH operation by a publisher. However, no mechanism has been defined in the existing CoAP pub/sub architecture regarding how to utilize a PCP to control the initiation of a new block transfer process for a PUBLISH operation.

[00100] The new publishing procedure may work as follows. Once a publisher has a new piece of data, instead of starting a PUBLISH operation by initiating a block transfer process, the publisher first asks the broker whether the publisher is allowed to publish by sending metadata information about its new piece of data. Alternatively, the publisher may directly send the first block along with the metadata information. On the broker side, the broker may evaluate the metadata information sent from the publisher and decide whether the new data should be published to the topic based on the PCP for this topic. If the publisher receives a positive ACK from the broker, a block transfer will be initiated to complete a PUBLISH operation. Otherwise, the publisher will abandon its attempt to publish this new piece of data. In this aspect, the broker is a dominant entity and publishers do not need to have information regarding the detailed PCP, alleviating the burden on the publisher side. Not having information regarding the PCP is especially efficient for resource-constrained IoT devices. [0100] To use the new publishing procedure, a publisher needs a method for asking a broker whether new data should be published. A new parameter, publishRequest, is introduced to be included in the request message from the publisher that includes metadata information regarding the new data to be published. A second new parameter, publishDecision, is also introduced to be included in the response message from the broker, from which the publisher will receive information regarding whether or not the publisher should proceed with a new block transfer process. The publishRequest and publishDecision parameters may also be applied to a scenario where a large-size piece of data needs to be published to a topic, but a different mechanism other than CoAP block transfer is adopted for use in the CoAP pub/sub architecture. An example publishing procedure utilizing the new parameters is illustrated in FIG. 19, which makes reference to the use case of FIGs. 15A and 15B.

[0101] Initially, Publisher-2 has a new piece of data, Data-2, ready to be published to Topic-A at Broker. Data-2 is split into five blocks for transmission via a CoAP block transfer process.

[0102] At step 1, Publisher-2 sends a CoAP GET request with the publishRequest parameter to ask Broker for permission to publish Data-2. The publishRequest parameter contains metadata about Data-2, such as image generation time, image resolution, image size, and other relevant information.

[0103] At step 2, upon receiving the request from Publisher-2, Broker decides whether to allow Publisher-2 to publish Data-2 to Topic-A based on the PCP and current working status of other publishers also currently publishing data to Topic-A. The details of the broker's decision-making process are shown in the flow diagram of FIG. 20, described more fully below.

[0104] At step 3, Broker sends back a response message to Publisher-2, which includes the publishDecision parameter to indicate Broker's decision to allow Publisher-2 to publish or not publish Data-2 to Topic-A.

[0105] At step 4, upon receiving the response message from Broker, Publisher-2 will interpret the publishDecision parameter and decide whether Publisher-2 should initiate a new block transfer to publish Data-2 to Topic-A. If Publisher-2 received a negative decision, or negative ACK, from Broker, Publisher-2 will abandon its efforts to publish Data-2 to Topic-A and will contact Broker at a later time when Publisher-2 has updated data beyond Data-2.

Otherwise, Publisher-2 will initiate a block transfer process to publish Data-2 to Topic-A. [0106] Table 3 defines a working status log table hosted by a broker for a given topic. A working status log table records the current working status about a topic. For example the working status log table for Topic-A, as shown in Table 3, shows that another publisher, Publisher-1, is currently publishing its data, Data-1, through an on-going block transfer process. Data-l ' s generation time and resolution are also described in this table.

Table 3. An Example Working Status Log Table for a Topic

[0107] FIG. 20 illustrates a flow diagram of an example decision-making process for a broker node receiving a request to publish data to a topic. The following description of the broker's decision-making process references the example use case of FIGs. 15A and 15B.

[0108] After the broker receives a request to publish new data, Data-2, to a topic, Topic-A, the broker investigates the metadata information sent from the publisher, Publisher-2, regarding Data-2 and compares it with the information in the PCP, shown in Table 2. In particular, the broker compares the metadata of Data-2 and the latest data that has already been completely stored in Topic-A, Data-0 as shown in Table 2, and then evaluates whether Data-2 should replace Data-0 based on the publishing policy of the PCP of Topic-A.

[0109] If the broker decides that Data-2 should not replace Data-0, the broker will reject Publisher-2' s request to publish. If the broker decides that Data-2 should replace Data-0, the broker checks the working status log table for Topic- A, as shown in Table 3, to see whether there is an ongoing block transfer by another publisher.

[0110] If there is not an ongoing block transfer by another publisher, the broker will allow Publisher-2 to publish Data-2. However, in this example, Publisher- 1 is currently using a block transfer to publish Data-1. Because there is an ongoing block transfer, the broker compares the metadata of the in-transfer data, Data-1, to the metadata of Data-2 and uses the PCP to decide which data should be published.

[0111] If, after comparing the metadata, the broker decides that Data-2 should replace Data-1, which now may be only partially delivered to the broker, the broker will allow Publisher- 2 to start a new block transfer for publishing Data-2 while also terminating the current ongoing block transfer for publishing Data-1 by Publisher-1. Otherwise, the broker will reject Publisher- 2's request to publish.

[0112] As discussed above, it is possible that the broker may allow Publisher-2 to start a new block transfer for publishing Data-2 even if there is an ongoing block transfer by

Publisher-1 to publish Data-1. Therefore, the broker needs an explicit way to indicate to

Publisher-1 that its current ongoing block transfer should be terminated. However, currently no mechanism has been defined in the existing block transfer mechanism to terminate an ongoing block transfer by a publisher.

[0113] A new parameter is introduced to allow a broker to terminate an ongoing block transfer by a publisher: stopBlockTransfer. Because a block transfer includes a number of request-response message pairs between a publisher and a broker, a broker may include the stopBlockTransfer parameter in the next immediate response message of the ongoing block transfer process once the broker decides to terminate the current block transfer process. The new stopBlockTransfer parameter may be used in multiple ways. For example, it may be only a signal to the publisher to end the block transfer. Alternatively, it may include additional information. For example, the stopBlockTransfer parameter may be used to convey information to the publisher concerning which publisher and what data made the broker decide to terminate the current ongoing block transfer. At minimum, the stopBlockTransfer parameter includes explicit semantics to indicate to the publisher that the broker is doing concurrency-control.

Otherwise, if the broker only returned a 4.xx or 5.xx error response code to end the existing block transfer, the publisher would have no information regarding why the block transfer process was terminated and may try to initiate a new block transfer to still publish its data at a later time.

[0114] The proposed procedure for using the stopBlockTransfer parameter is illustrated in FIGs. 21 A and 21B, in which the stopBlockTransfer parameter is used in the context of the topic and entities of FIGs. 15A and 15B. In particular, stopBlockTransfer is included in a response message from Broker after Publisher-1 attempts to transfer the third block of Data-1. By receiving this parameter, Publisher-1 determines that Broker requires it to stop the current block transfer. Publisher-1 is able to determine that the block transfer was not stopped due to any other reason, such as network congestion, broker overloading, etc. More than that,

Publisher-1 will stop attempting to publish the current data, Data-1, will not re-initiate a new block transfer for this data, and will contact the broker again only when it has newer data to be published to this topic, Topic-A. Similarly, at the broker side, the partially delivered blocks of Data-1 will be deleted by Broker. Generally, the newly-introduced stopBlockTransfer parameter for use in the CoAP pub/sub architecture may also be applied in a traditional client-server architecture in order to terminate an on-going block transfer.

SUBSCRIBE Operation

[0115] In a third aspect, two new parameters are introduced to the block transfer process of a SUBSCRIBE operation to control the notification preference of a subscriber for a block transfer process and terminate ongoing block transfers attempting to notify a subscriber of published data. A new procedure is also introduced to allow a block-by-block notification scheme for a subscriber, and an accompanying parameter is introduced to indicate that a block- by-block update has been terminated.

[0116] As mentioned above, CoAP pub/sub clients subscribe to topics on a broker using CoAP Observe, and a CoAP pub/sub client wishing to subscribe to a topic on a broker should use a CoAP GET with Observe registration. When a piece of data from a topic is of large size, a block transfer process will likely be involved in the Observe operation. For example, as defined in the existing block transfer mechanism, a broker will send a notification to a subscriber, which may include the first block of data. Subsequently, the subscriber will retrieve the remaining blocks via a normal CoAP block transfer, beginning with the second block if the first block was properly received from the broker's notification. Because the broker is an intermediate node between publishers and subscribers, there could be two different approaches for the broker to notify subscribers of a given topic: data-by-data and block-by-block.

[0117] In the "data-by-data" approach, the broker will begin to send a notification to a related subscriber only when a complete data body is fully published to the broker by a publisher. If a publisher is involved in an ongoing block transferring process to publish its data to a topic, the broker will not inform related subscribers of the update until the block transfer process is completed, even if some of the blocks have already been delivered to the broker.

[0118] In the "block-by-block" approach, the broker may choose to send notifications to a subscriber when a new block is delivered to the topic. As opposed to the data-by-data approach where the broker will only send a notification to a subscriber after the entire data update, in this approach the broker will send a notification for each newly delivered block.

[0119] Each approach has pros and cons. For example, the data-by-data approach has better Quality-of-Service (QoS) because the broker will inform the related subscribers to retrieve data only after the entire data body is published or delivered to the broker, thus allowing subscribers to retrieve the entire data body instead of having to wait for more blocks to be delivered or needing to discard data blocks if a transfer is interrupted or terminated by the broker. However, this approach may have large notification delays because subscribers may not able to access the data at the earliest time available. By comparison, the block-by-block approach gives subscribers the opportunity to retrieve and access blocks as soon as they become available at the broker, which may be very important for some time-critical applications. For example, in video or image transmission-related applications, users may already be able to process a digital image or a video frame even if it is not delivered completely, akin to understanding a digital image even if some of parts in the image are destroyed. However, this approach may not have as good QoS as the data-by-data approach because it is possible that the block transfer process on the publisher side may not be finally completed if it is interrupted or terminated such that the subscribers may never receive a completed data body. In addition, because notifications are sent in a block-by-block manner, this approach will consume more communication bandwidth.

[0120] Both the data-by-data and block-by-block approaches need to be supported. However, there is currently no solution that enables a subscriber to indicate its preference regarding how it should receive notifications from the broker for a given topic. In order to support the above two approaches, a new parameter, notificationGranularity, is introduced, which enables a subscriber to indicate how it should receive notifications. The

notificationGranularity parameter may be carried in a SUBSCRIBE request message when a subscriber is making a subscription to a given topic. Setting "notificationGranularity=0" may indicate a data-by-data notification approach, while setting "notificationGranularity=l" may indicate a block-by-block notification approach. Upon receiving this parameter, the broker will record how the subscriber should receive notifications. The proposed procedure for using notificationGranularity is illustrated in FIG. 22. The value of the notificationGranularity parameter may be set larger than 1 to add more specificity. For example, setting

"notificationGranularity=2" may mean that the subscriber should receive a notification once every two blocks become available at the broker.

[0121] When a subscriber chooses to use the block-by-block approach to receive notifications, it will not be able to use the defined CoAP Observe notification methods.

Accordingly, a new procedure for implementing block-by-block notifications is illustrated in FIGs. 23 A and 23B and described below with reference to the broker of Topic- A and accompanying entities, used in previous figures. A new parameter, Terminated, is also introduced to the block-by-block notification approach to enable a subscriber to determine that an ongoing block transfer by the publisher was terminated and no further blocks of that publisher's data will be sent to the subscriber.

[0122] At step 1, Subscriber- 1 makes a subscription to Topic-A using CoAP observe, and sets "notificationGranularity=l" to indicate a block-by-block notification approach.

[0123] At step 2, Publisher-1 intends to publish Data-1 to Topic-A and is approved by Broker to do so, based on the PCP of Topic-A. Accordingly, Publisher-1 will initiate a new block transfer process to transfer Data-1.

[0124] At step 3, Publisher-1 sends the first block, Block 0, of Data-1 to Topic-A using the existing CoAP Blockl option. Broker then ACKs the reception of this block.

[0125] At step 4, upon receiving the Block 0 of Data-1, Broker determines to send a notification to Subscriber-1 for Block 0.

[0126] At step 5, the notification of Block 0 is sent to Subscriber-1 through a normal CoAP Observe notification, in which the existing CoAP Block2 option is used. [0127] At step 6, similar to step 3, Publisher-1 sends the second block of Data-1, Block 1, to Topic-A. Steps 4-6 will be repeated until all blocks of Data-1 are published to Broker and Subscriber-1 retrieves all of these blocks. However, the following additional steps consider the case in which another publisher, Publisher-2, receives approval to publish its data, Data-2, to Topic-A during the ongoing block transfer of Data-1.

[0128] At step 7, Publisher-2 has new data, Data-2, for Topic-A and receives permission from Broker to initialize a new block transfer to publish Data-2. As a result, Broker terminates the current block transfer between Publisher-1 and Broker being used to publish Data- 1.

[0129] At step 8, because Data-l's publishing block transfer is terminated, no further blocks of Data-1 will arrive from Publisher-1. Broker needs to inform Subscriber-1 that the transmission of Data-1 has been terminated. Accordingly, a new parameter, Terminated, is introduced to notify subscribers of a terminated block transfer.

[0130] At step 9, Broker sends a notification including the Terminated parameter to Subscriber-1 through an existing CoAP Observe notification.

[0131] At step 10, upon receiving a notification in which the Terminated parameter is included, Subscriber-1 will not expect more blocks of Data-1. Once Subscriber-1 receives the Terminated signal, it will be able to determine that from that point in time, later notifications will include new data: the blocks from Publisher-2 in this example. Accordingly, Broker will begin to send notifications carrying blocks of Data-2 to Subscriber-1 after sending the Terminated parameter to Subscriber-1, and Subscriber-1 should delete the retrieved blocks of Data-1.

[0132] In the above procedure, for simple presentation, it is assumed that the block transfer between Publisher-1 and Broker use the same block size as used in the block transfer between Subscriber-1 and Broker. However, these two block transfers may use different block sizes. If SI denotes the block size used in the block transfer between Publisher-1 and Broker and S2 denotes the block size used in the block transfer between Broker and Subscriber-1, the following situations may occur:

1. If S1>S2, Publisher-1 uses a larger block size. In this case, the block published by Publisher-1 will need to be re-sized or further split to the size of S2 by Broker before sending it to Subscriber-1. 2. If S1<S2, Publisher-1 uses a smaller block size. In this case, several blocks published by Publisher-1 will need to be combined together by Broker to reach the size of S2 before sending it to Subscriber-1.

[0133] Similarly to the PUBLISH operation, when a subscriber uses a data-by-data notification scheme, it will use a block transfer for retrieving a data body after receiving a notification from the broker. However, during the block transfer process for retrieving all the blocks of data, another publisher may receive approval by the broker to publish better or newer data than the current data being retrieved by the subscriber. To avoid a race condition for data updating, certain policy data could be defined in a PCP for the topic. For example, the PCP may dictate that data may be considered to be "newer" only if its data generation time is at least five minutes later than that of data already hosted by the broker and being retrieved by the subscriber. Because data currently being retrieved is not as useful as the newer data from another publisher, the broker needs an explicit way to indicate to the subscriber that the current ongoing block transfer should be terminated. However, no mechanism currently exists to enable the broker to stop an on-going block transfer used in a SUBSCRIBE operation.

[0134] The previously-introduced parameter, stopBlockTransfer, for use with the PUBLISH operation may be reintroduced and used for the SUBSCRIBE operation. In particular, for a given topic, once the broker allows a publisher to publish a new data body and identifies that there are ongoing block transfers by subscribers retrieving data already published at the broker, the broker may include the stopBlockTransfer parameter in the next immediate response message of the ongoing block transfer processes to stop the subscribers from fully retrieving the old data.

[0135] The proposed procedure for using the stopBlockTransfer parameter with a SUBSCRIBE operation is illustrated in FIGs. 24A, 24B, and 24C, in which the

stopBlockTransfer parameter is included in a response message from the broker during the transfer of the third block of Data-1 to Subscriber-1. The description of the procedure is as follows.

[0136] At step 1, Subscriber-1 makes a subscription to Topic-A through CoAP Observe and indicates to Broker that it wants to receive notifications in a data-by-data manner.

[0137] At step 2, Publisher-1 publishes Data-1 to Topic-A. [0138] At step 3, Broker sends a notification to Subscriber-1 for it to retrieve Data-1. At this step, Subscriber-1 may decide to either continue to retrieve the remaining blocks of Data- 1 in a traditional way or simply ignore this notification. Because the same topic may receive data in different qualities and sizes, e.g., a high-resolution image or a low-resolution image, a resource-constrained subscriber may choose to only receive low-resolution image updates, which are smaller in size, thereby reducing potential processing cost. As a result, the publishing control policy defined in the PCP for the topic, which is relatively a global policy, should be carefully designed by considering the characteristics of both the publishers and subscribers. For purposes of example, assume Subscriber-1 will continue to retrieve the remaining blocks of Data-1.

[0139] At step 4, Subscriber-1 begins to retrieve the remaining blocks for Data-1 through a block transfer process.

[0140] At step 5, Publisher-2 intends to publish new data, Data-2, to Topic-A and receives approval from Broker to publish Data-2 based on the PCP of Topic-A.

[0141] At step 6, because Data-2 is better or newer than Data-1, Data-1 is not as useful to Subscriber-1. Therefore, Broker needs to terminate the ongoing block transfer process to Subscriber-1 being used to retrieve the remaining blocks of Data-1.

[0142] As a result, at step 7, Broker includes the stopBlockTransfer parameter in the response message for transferring the third block of Data-1.

[0143] At step 8, Subscriber-1 will now stop the current block transfer process for retrieving the remaining blocks of Data-1.

[0144] The introduced stopBlockTransfer parameter for use in the CoAP pub/sub architecture may also be applied in the traditional CoAP Observe methodology to terminate an on-going block transfer.

Information Query

[0145] In a fourth aspect, two new pairs of parameters are introduced to allow clients to query the number of publishers and subscribers associated with a given topic.

[0146] The CoAP pub/sub architecture emphasizes the decoupling between a sender and a receiver. In this way, publishers do not need to know what entities are consuming their data and, similarly, subscribers need only to consume data from a broker and do not have to know what entities are producing that data. However, when maintaining such a loosely-coupled system, it is beneficial to allow publishers and subscribers to determine information about each other for them to conduct more-intelligent actions. For example, a publisher may want to determine how many peer publishers are currently contributing data to a certain topic. By having this information, the publisher may reduce its publishing frequency and conserve energy.

Similarly, a subscriber may want to determine how many subscribers have the same interest in a certain topic and how many publishers are contributing data to a topic to which it is currently subscribing in order to make sure the subscriber is able to receive enough data notifications from that topic. Because both publishers and subscribers may want to determine such information, publishers and subscribers are referred to generally as "clients." Currently, no mechanism exists for a client to query such information regarding the publishers and subscribers for a given topic.

[0147] Accordingly, two new pairs of parameters are proposed in order to enable a client to ask a broker about the useful information related to publishers and subscribers for a given topic: num_of_pub and ans_of_pub; and num of sub and ans of sub.

[0148] The num_of_pub parameter is sent from a client, either a publisher or a subscriber, to a broker and indicates that the client is requesting the number of publishers currently publishing data to the topic.

[0149] The ans of pub parameter is carried in the corresponding response message from the broker to the client and indicates the number of publishers currently publishing data to the topic.

[0150] The num of sub parameter is sent from a client to a broker and indicates that the client is requesting the number of subscribers currently subscribing to the topic.

[0151] The ans of sub parameter is carried in the corresponding response message from the broker to the client and indicates the number of subscribers currently subscribing to the topic.

[0152] The new pairs of parameters may be carried in a request/response pair in any stage of a block transfer process. For example, the query could be related to a block transfer process in a PUBLISH operation or in a SUBSCRIBE operation. The query may appear in the first request/response message pair before a block transfer process begins, or it may be in one of the request/response messages, during an ongoing block transfer process. The two pairs of parameters may also be exchanged generally, even when a block transfer is not involved in a PUBLISH or SUBSCRIBE operation. The number of publishers and subscribers may be stored by the broker as status information for this topic for other uses. [0153] FIG. 25 illustrates a client, Client- 1, using the new parameters and a broker, Broker, for Topic-A responding with the appropriately-paired parameter. As shown on the client-side of FIG. 25, the new pairs of parameters may enable clients to take more intelligent actions or decisions based on the number of publishers or subscribers for a given topic, and FIG. 26 shows such a use case.

[0154] FIG. 26 has a procedure similar to that of FIG. 19, where a publisher, Publisher- 1, intends to publish new data, Data-1, to a topic, Topic-A, held at a broker, Broker. Publisher-1 begins a publishing procedure and includes the num of sub parameter in the publish-request message to Broker to query how many subscribers are currently subscribing to Topic-A.

Accordingly, Broker answers this query and returns the answer in the ans of sub parameter along with its publishing decision response message. Upon receiving the answer from Broker, Publisher-1 may learn that there is currently only one subscriber to Topic-A, which leads Publisher-1 to determine that publishing data to Topic-A may not bring much benefit or value to other clients. Thus, because publishing data to Broker at a higher frequency will require higher communication cost and energy of Publisher without leading to significant benefit to subscribers, Publisher-1 may determine to reduce the data generation and publishing rates in order to save a certain amount of energy, an important design consideration for IoT systems.

Example Embodiments

[0155] CoAP defines a number of options which can be included in a CoAP message. Each option instance in a message specifies the Option Number of the defined CoAP option, the length of the Option Value, and the Option Value itself. An option value can be empty, opaque, unit, or string. The new parameters introduced above may be embodied as new CoAP block options.

[0156] A PCP for a topic may be defined by the client who creates the topic.

Accordingly, several new parameters may be carried in the request message of a CREATE operation in order to describe the PCP: Topic Description (t_d); Allowed Data Type (a d t); Maximum Data Size (m_d_s); and Publishing Policy Description (p_p_d).

[0157] Table 4 shows the implementation details of an embodiment of the four new PCP parameters. The parameters may be included in the No. 51, 53, 55, and 57 CoAP block options within the headers of the CREATE requests. Table 4. Implementation Details for New PCP Parameters

[0158] Three new parameters, publishRequest, publishDecision, and

stopBlockTransfer, are introduced above for use with the PUBLISH operation. The stopBlockTransfer may also be used with the SUBSCRIBE operation. Table 5 shows the implementation details of an embodiment of the three new parameters. The parameters may be included in the No. 59, 61, and 63 CoAP block options within the headers of the requests and responses.

Table 5. Implementation Details for New PUBLISH Parameters

[0159] Two new parameters, not including the reused stopBlockTransfer parameter, are introduced above for use with the SUBSCRIBE operation: notificationGranularity and

Terminated. Two new pairs of parameters are also introduced above for use with both publishers and subscribers: num_of_pub and ans_of_pub; and num of sub and ans of sub. Table 6 shows the implementation details of an embodiment of these six new parameters. The parameters may be included in the No. 65, 67, 69, 71, 73, and 75 CoAP block options within the headers of the requests and responses.

Table 6. Implementation Details for New SUBSCRIBE and Query Parameters

Example Graphical User Interface

[0160] From a protocol stack perspective, the above embodiments may run at the application protocol layer below the application layer, and the upper-layer applications and services may not directly interact with the application protocol layer unless cross-layer interaction is implemented. To provide a convenient avenue for configuring or accessing any or all of the aforementioned parameters, an embodiment includes a user control panel. In particular, the interface may have a graphical user interface (GUI) that allows a user to input desired values for the parameters or access values of the parameters during protocol setup and deployment. Such an example GUI can be seen in FIG. 27 for accessing the values of a topic's PCP. For example, depending on the specific context or application scenario, users may use such a GUI to query the details of the PCP for a given topic before making any updates to the topic. As can be seen in FIG. 27, input boxes may be used to enter the parameters, and a submit button may be used to access the values of the entered parameters.

Example 3GPP Embodiment

[0161] The techniques described above may be used to send data over a 3GPP network. For example, a publisher or subscriber may reside in a 3GPP device such as a UE, while the broker is located in core network or Internet. However, when a 3GPP network is used, the publisher and subscriber must coordinate block sizes with the 3GPP network so that the constraints of the 3 GPP core network are not violated.

[0162] If a non-IP PDN connection is used by a publisher, subscriber, or application that is hosted on a UE, then the mobile core network may be used to signal the maximum non-IP block size to the UE. The UE may expose an API to the publisher, subscriber, or application that is hosted on the UE so that the publisher, subscriber, or application can determine the maximum block size. For example, the network may use PCO to provide the UE with a Link MTU for the non-IP PDN connection. The API may allow the publisher, subscriber, or application to provide a PDN Connection, or Bearer, identifier and the API may return the same Link MTU that was provided in the PCO for the PDN Connection. The Link MTU may be treated by the publisher, subscriber, or application as a maximum block size or a required block size. The PCO may further indicate if the Link MTU should be treated as a maximum block size or a required block size. The API may be provided by the UE's operating system or provided by the modem itself.

[0163] The publisher, subscriber, or application that is hosted in the SCS/AS that the UE is in communication with should assume the same maximum or required block size. There are several ways to coordinate this value between the SCS/AS and the UE:

1. The SCEF may set the Link MTU. In this scenario, the SCEF may provide the Link MTU to the UE by providing the PCO to the MME and the MME providing it to the UE in SM signaling. The SCEF may expose an API to the publisher, subscriber, application, or server that is hosted in the SCS/AS that allows it to query for the Link MTU, maximum block size, or required block size. The API may require that the SCS provide a UE External ID or Internal ID, an Application ID, a Port ID, and/or a Bearer ID. The API may return the Link MTU, maximum block size, or required block size.

2. A core network node, such as the Home Subscriber Service Center (HSS) or MME, may be used to set the Link MTU. The value may be provided by the core network node to the SCEF. The SCEF may provide the value to the UE and the publisher, subscriber, application, or server that is hosted in the SCS/AS as described in approach 1.

3. The publisher, subscriber, application, or server that is hosted in the SCS/AS may set the Link MTU. The value may be provided to the SCEF, and the SCEF may provide the value to the UE as described in approach 1.

Example Environment

[0164] FIG. 28A is a diagram of an example machine-to machine (M2M), Internet of Things (IoT), or Web of Things (WoT) communication system 10 in which one or more disclosed embodiments may be implemented. Generally, M2M technologies provide building blocks for the IoT/WoT, and any M2M device, M2M gateway, M2M server, or M2M service platform may be a component or node of the IoT/WoT as well as an IoT/WoT service layer, etc. Any of the client or server devices illustrated in any of FIGs. 2-5, 7-19, or 21A-26 may comprise a node of a communication system such as the ones illustrated in FIGs. 28A-D.

[0100] The service layer may be a functional layer within a network service

architecture. Service layers are typically situated above the application protocol layer such as HTTP, CoAP or MQTT and provide value added services to client applications. The service layer also provides an interface to core networks at a lower resource layer, such as for example, a control layer and transport/access layer. The service layer supports multiple categories of (service) capabilities or functionalities including a service definition, service runtime

enablement, policy management, access control, and service clustering. Recently, several industry standards bodies, e.g., oneM2M, have been developing M2M service layers to address the challenges associated with the integration of M2M types of devices and applications into deployments such as the Internet/Web, cellular, enterprise, and home networks. A M2M service layer can provide applications and/or various devices with access to a collection of or a set of the above mentioned capabilities or functionalities, supported by the service layer, which can be referred to as a CSE or SCL. A few examples include but are not limited to security, charging, data management, device management, discovery, provisioning, and connectivity management which can be commonly used by various applications. These capabilities or functionalities are made available to such various applications via APIs which make use of message formats, resource structures and resource representations defined by the M2M service layer. The CSE or SCL is a functional entity that may be implemented by hardware and/or software and that provides (service) capabilities or functionalities exposed to various applications and/or devices (i.e., functional interfaces between such functional entities) in order for them to use such capabilities or functionalities.

[0101] As shown in FIG. 28 A, the M2M/ IoT/WoT communication system 10 includes a communication network 12. The communication network 12 may be a fixed network (e.g., Ethernet, Fiber, ISDN, PLC, or the like) or a wireless network (e.g., WLAN, cellular, or the like) or a network of heterogeneous networks. For example, the communication network 12 may be comprised of multiple access networks that provide content such as voice, data, video, messaging, broadcast, or the like to multiple users. For example, the communication network 12 may employ one or more channel access methods, such as code division multiple access

(CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and the like. Further, the communication network 12 may comprise other networks such as a core network, the Internet, a sensor network, an industrial control network, a personal area network, a fused personal network, a satellite network, a home network, or an enterprise network for example.

[0102] As shown in FIG. 28 A, the M2M/ IoT/WoT communication system 10 may include the Infrastructure Domain and the Field Domain. The Infrastructure Domain refers to the network side of the end-to-end M2M deployment, and the Field Domain refers to the area networks, usually behind an M2M gateway. The Field Domain and Infrastructure Domain may both comprise a variety of different nodes (e.g., servers, gateways, device, and the like) of the network. For example, the Field Domain may include M2M gateways 14 and devices 18. It will be appreciated that any number of M2M gateway devices 14 and M2M devices 18 may be included in the M2M/ IoT/WoT communication system 10 as desired. Each of the M2M gateway devices 14 and M2M devices 18 are configured to transmit and receive signals, using communications circuitry, via the communication network 12 or direct radio link. A M2M gateway 14 allows wireless M2M devices (e.g., cellular and non-cellular) as well as fixed network M2M devices (e.g., PLC) to communicate either through operator networks, such as the communication network 12 or direct radio link. For example, the M2M devices 18 may collect data and send the data, via the communication network 12 or direct radio link, to an M2M application 20 or other M2M devices 18. The M2M devices 18 may also receive data from the M2M application 20 or an M2M device 18. Further, data and signals may be sent to and received from the M2M application 20 via an M2M Service Layer 22, as described below. M2M devices 18 and gateways 14 may communicate via various networks including, cellular, WLAN, WPAN (e.g., Zigbee, 6L0WPAN, Bluetooth), direct radio link, and wireline for example.

Exemplary M2M devices include, but are not limited to, tablets, smart phones, medical devices, temperature and weather monitors, connected cars, smart meters, game consoles, personal digital assistants, health and fitness monitors, lights, thermostats, appliances, garage doors and other actuator-based devices, security devices, and smart outlets.

[0103] Referring to FIG. 28B, the illustrated M2M Service Layer 22 in the field domain provides services for the M2M application 20, M2M gateways 14, and M2M devices 18 and the communication network 12. It will be understood that the M2M Service Layer 22 may communicate with any number of M2M applications, M2M gateways 14, M2M devices 18, and communication networks 12 as desired. The M2M Service Layer 22 may be implemented by one or more nodes of the network, which may comprise servers, computers, devices, or the like. The M2M Service Layer 22 provides service capabilities that apply to M2M devices 18, M2M gateways 14, and M2M applications 20. The functions of the M2M Service Layer 22 may be implemented in a variety of ways, for example as a web server, in the cellular core network, in the cloud, etc.

[0104] Similar to the illustrated M2M Service Layer 22, there is the M2M Service Layer 22' in the Infrastructure Domain. M2M Service Layer 22' provides services for the M2M application 20' and the underlying communication network 12 in the infrastructure domain. M2M Service Layer 22' also provides services for the M2M gateways 14 and M2M devices 18 in the field domain. It will be understood that the M2M Service Layer 22' may communicate with any number of M2M applications, M2M gateways and M2M devices. The M2M Service Layer 22' may interact with a Service Layer by a different service provider. The M2M Service Layer 22' may be implemented by one or more nodes of the network, which may comprise servers, computers, devices, virtual machines (e.g., cloud computing/storage farms, etc.) or the like. [0105] Referring also to FIG. 28B, the M2M Service Layers 22 and 22' provide a core set of service delivery capabilities that diverse applications and verticals may leverage. These service capabilities enable M2M applications 20 and 20' to interact with devices and perform functions such as data collection, data analysis, device management, security, billing, service/device discovery, etc. Essentially, these service capabilities free the applications of the burden of implementing these functionalities, thus simplifying application development and reducing cost and time to market. The Service Layers 22 and 22' also enable M2M applications 20 and 20' to communicate through various networks such as network 12 in connection with the services that the Service Layers 22 and 22' provide.

[0106] The M2M applications 20 and 20' may include applications in various industries such as, without limitation, transportation, health and wellness, connected home, energy management, asset tracking, and security and surveillance. As mentioned above, the M2M Service Layer, running across the devices, gateways, servers and other nodes of the system, supports functions such as, for example, data collection, device management, security, billing, location tracking/geofencing, device/service discovery, and legacy systems integration, and provides these functions as services to the M2M applications 20 and 20' .

[0107] Generally, a Service Layer, such as the Service Layers 22 and 22' illustrated in FIG. 28B, defines a software middleware layer that supports value-added service capabilities through a set of Application Programming Interfaces (APIs) and underlying networking interfaces. Both the ETSI M2M and oneM2M architectures define a Service Layer. ETSI M2M's Service Layer is referred to as the Service Capability Layer (SCL). The SCL may be implemented in a variety of different nodes of the ETSI M2M architecture. For example, an instance of the Service Layer may be implemented within an M2M device (where it is referred to as a device SCL (DSCL)), a gateway (where it is referred to as a gateway SCL (GSCL)) and/or a network node (where it is referred to as a network SCL (NSCL)). The oneM2M Service Layer supports a set of Common Service Functions (CSFs) (i.e., service capabilities). An instantiation of a set of one or more particular types of CSFs is referred to as a Common Services Entity (CSE) which may be hosted on different types of network nodes (e.g., infrastructure node, middle node, application-specific node). The Third Generation Partnership Project (3 GPP) has also defined an architecture for machine-type communications (MTC). In that architecture, the Service Layer, and the service capabilities it provides, are implemented as part of a Service Capability Server (SCS). Whether embodied in a DSCL, GSCL, or NSCL of the ETSI M2M architecture, in a Service Capability Server (SCS) of the 3GPP MTC architecture, in a CSF or CSE of the oneM2M architecture, or in some other node of a network, an instance of the Service Layer may be implemented as a logical entity (e.g., software, computer-executable instructions, and the like) executing either on one or more standalone nodes in the network, including servers, computers, and other computing devices or nodes, or as part of one or more existing nodes. As an example, an instance of a Service Layer or component thereof may be implemented in the form of software running on a network node (e.g., server, computer, gateway, device or the like) having the general architecture illustrated in FIG. 28C or FIG. 28D described below.

[0108] Further, the methods and functionalities described herein may be implemented as part of an M2M network that uses a Service Oriented Architecture (SO A) and/or a Resource- Oriented Architecture (ROA) to access services.

[0165] FIG. 28C is a block diagram of an example hardware/software architecture of a node of a network, such as one of the clients, servers, or proxies illustrated in FIGs. 2-5, 7-19, or 21 A-26, which may operate as an M2M server, gateway, device, or other node in an M2M network such as that illustrated in FIGs. 28A and 28B. As shown in FIG. 28C, the node 30 may include a processor 32, non-removable memory 44, removable memory 46, a

speaker/microphone 38, a keypad 40, a display, touchpad, and/or indicators 42, a power source 48, a global positioning system (GPS) chipset 50, and other peripherals 52. The node 30 may also include communication circuitry, such as a transceiver 34 and a transmit/receive element 36. It will be appreciated that the node 30 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment. This node may be a node that implements the concurrency control for block transfers in a CoAP pub/sub architecture as described herein, e.g., in relation to the methods described in reference to FIGs. 10-26, or the data structures of FIGs. 1-8, 10-19, 21 A-26, Tables 1-6, or in a claim.

[0109] The processor 32 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of

microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. In general, the processor 32 may execute computer-executable instructions stored in the memory (e.g., memory 44 and/or memory 46) of the node in order to perform the various required functions of the node. For example, the processor 32 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the node 30 to operate in a wireless or wired environment. The processor 32 may run

application-layer programs (e.g., browsers) and/or radio access-layer (RAN) programs and/or other communications programs. The processor 32 may also perform security operations such as authentication, security key agreement, and/or cryptographic operations, such as at the access- layer and/or application layer for example.

[0166] As shown in FIG. 28C, the processor 32 is coupled to its communication circuitry (e.g., transceiver 34 and transmit/receive element 36). The processor 32, through the execution of computer executable instructions, may control the communication circuitry in order to cause the node 30 to communicate with other nodes via the network to which it is connected. In particular, the processor 32 may control the communication circuitry in order to perform the transmitting and receiving steps described herein (e.g., at least those in FIGs. 2-5, 7-19, or 21 A- 26) and in the claims. While FIG. 28C depicts the processor 32 and the transceiver 34 as separate components, it will be appreciated that the processor 32 and the transceiver 34 may be integrated together in an electronic package or chip.

[0110] The transmit/receive element 36 may be configured to transmit signals to, or receive signals from, other nodes, including M2M servers, gateways, device, and the like. For example, in an embodiment, the transmit/receive element 36 may be an antenna configured to transmit and/or receive RF signals. The transmit/receive element 36 may support various networks and air interfaces, such as WLAN, WPAN, cellular, and the like. In an embodiment, the transmit/receive element 36 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 36 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 36 may be configured to transmit and/or receive any combination of wireless or wired signals.

[0111] In addition, although the transmit/receive element 36 is depicted in FIG. 28C as a single element, the node 30 may include any number of transmit/receive elements 36. More specifically, the node 30 may employ MTMO technology. Thus, in an embodiment, the node 30 may include two or more transmit/receive elements 36 (e.g., multiple antennas) for transmitting and receiving wireless signals.

[0112] The transceiver 34 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 36 and to demodulate the signals that are received by the transmit/receive element 36. As noted above, the node 30 may have multi-mode capabilities. Thus, the transceiver 34 may include multiple transceivers for enabling the node 30 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.

[0113] The processor 32 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 44 and/or the removable memory 46. For example, the processor 32 may store session context in its memory, as described above. The non-removable memory 44 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 46 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 32 may access information from, and store data in, memory that is not physically located on the node 30, such as on a server or a home computer. The processor 32 may be configured to control lighting patterns, images, or colors on the display or indicators 42 to reflect the status of a node or configure a node, and in particular underlying networks, applications, or other services in communication with the node. In one embodiment, the display/indicators 42 may present the graphical user interface illustrated in FIG. 27 and described herein.

[0114] The processor 32 may receive power from the power source 48, and may be configured to distribute and/or control the power to the other components in the node 30. The power source 48 may be any suitable device for powering the node 30. For example, the power source 48 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0115] The processor 32 may also be coupled to the GPS chipset 50, which is configured to provide location information (e.g., longitude and latitude) regarding the current location of the node 30. It will be appreciated that the node 30 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment. [0116] The processor 32 may further be coupled to other peripherals 52, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 52 may include various sensors such as an accelerometer, biometrics (e.g., fingerprint) sensors, an e-compass, a satellite transceiver, a sensor, a digital camera (for photographs or video), a universal serial bus (USB) port or other interconnect interfaces, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0117] The node 30 may be embodied in other apparatuses or devices, such as a sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or airplane. The node 30 may connect to other components, modules, or systems of such apparatuses or devices via one or more interconnect interfaces, such as an interconnect interface that may comprise one of the peripherals 52.

[0167] FIG. 28D is a block diagram of an exemplary computing system 90 which may also be used to implement one or more nodes of a network, such as the clients, servers, or proxies illustrated in FIGs. 2-5, 7-19, or 21 A-26 and described herein, which may operate as an M2M server, gateway, device, or other node in an M2M network such as that illustrated in FIGs. 28A and 28B.

[0118] Computing system 90 may comprise a computer or server and may be controlled primarily by computer readable instructions, which may be in the form of software, wherever, or by whatever means such software is stored or accessed. Such computer readable instructions may be executed within a processor, such as central processing unit (CPU) 91, to cause computing system 90 to do work. In many known workstations, servers, and personal computers, central processing unit 91 is implemented by a single-chip CPU called a

microprocessor. In other machines, the central processing unit 91 may comprise multiple processors. Coprocessor 81 is an optional processor, distinct from main CPU 91, that performs additional functions or assists CPU 91. CPU 91 and/or coprocessor 81 may receive, generate, and process data related to the disclosed systems and methods for E2E M2M Service Layer sessions, such as receiving session credentials or authenticating based on session credentials. [0119] In operation, CPU 91 fetches, decodes, and executes instructions, and transfers information to and from other resources via the computer's main data-transfer path, system bus 80. Such a system bus connects the components in computing system 90 and defines the medium for data exchange. System bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the system bus. An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus.

[0120] Memories coupled to system bus 80 include random access memory (RAM) 82 and read only memory (ROM) 93. Such memories include circuitry that allows information to be stored and retrieved. ROMs 93 generally contain stored data that cannot easily be modified. Data stored in RAM 82 may be read or changed by CPU 91 or other hardware devices. Access to RAM 82 and/or ROM 93 may be controlled by memory controller 92. Memory controller 92 may provide an address translation function that translates virtual addresses into physical addresses as instructions are executed. Memory controller 92 may also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Thus, a program running in a first mode may access only memory mapped by its own process virtual address space; it cannot access memory within another process's virtual address space unless memory sharing between the processes has been set up.

[0121] In addition, computing system 90 may contain peripherals controller 83 responsible for communicating instructions from CPU 91 to peripherals, such as printer 94, keyboard 84, mouse 95, and disk drive 85.

[0122] Display 86, which is controlled by display controller 96, is used to display visual output generated by computing system 90. Such visual output may include text, graphics, animated graphics, and video. Display 86 may be implemented with a CRT -based video display, an LCD-based flat-panel display, gas plasma-based flat-panel display, or a touch-panel. Display controller 96 includes electronic components required to generate a video signal that is sent to display 86. Display 86, in combination with the computer-executable instructions executed by CPU 91, may generate and operate the graphical user interface illustrated and described in FIG. 27 and its accompanying description.

[0168] Further, computing system 90 may contain communication circuitry, such as for example a network adaptor 97, that may be used to connect computing system 90 to an external communications network, such as network 12 of FIG. 28A-D, to enable the computing system 90 to communicate with other nodes of the network. The communication circuitry, alone or in combination with the CPU 91, may be used to perform the transmitting and receiving steps described herein (e.g., at least those in FIGs. 2-5, 7-19, or 21 A-26) and in the claims.

[0169] It is understood that any or all of the systems, methods and processes described herein may be embodied in the form of computer executable instructions (i.e., program code) stored on a computer-readable storage medium which instructions, when executed by a machine, such as an apparatus of an M2M network, including for example an M2M server, gateway, device or the like, perform and/or implement the systems, methods and processes described herein. Specifically, any of the steps, operations or functions described above may be

implemented in the form of such computer executable instructions. Computer readable storage media include both volatile and nonvolatile, removable and non-removable media implemented in any non-transitory (i.e., tangible or physical) method or technology for storage of information, but such computer readable storage media do not includes signals. Computer readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible or physical medium which can be used to store the desired information and which can be accessed by a computer.

[0170] This written description uses examples to disclose the invention, including the best mode, and also to enable any person skilled in the art to practice the invention, including making and using any devices or systems and performing any incorporated methods. The patentable scope of the invention is defined by the claims, and may include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims if they have elements that do not differ from the literal language of the claims, or if they include equivalent elements with insubstantial differences from the literal language of the claims.

Claims

What is Claimed:

1. An apparatus comprising a processor, a memory, and communication circuitry, the apparatus being connected to a communications network via its communication circuitry, the apparatus further comprising computer-executable instructions stored in the memory of the apparatus which, when executed by the processor of the apparatus, cause the apparatus to:

receive, via the communication network from an other apparatus on the network, a first CoAP message indicating a request to create a CoAP pub/sub topic and including CoAP Option fields set to indicate a publish control policy for the CoAP pub/sub topic; and

upon creating the CoAP pub/sub topic with the publish control policy:

send, via the communication network to the other apparatus on the network, a first CoAP response message acknowledging the creating.

2. The apparatus recited in claim 1, wherein the computer-executable instructions, when executed by the processor of the apparatus, further cause the apparatus to:

receive, via the communication network from the other apparatus on the network, a request to update the publish control policy of the CoAP pub/sub topic; and

upon updating the publish control policy:

send, via the communication network to the other apparatus on the network, a

CoAP message acknowledging the updating.

3. The apparatus recited in claim 2, wherein the receiving a request to update the publish control policy comprises:

receiving, via the communication network from the other apparatus on the network, a second CoAP message indicating a request to delete the CoAP pub/sub topic;

sending, via the communication network to the other apparatus on the network, a second CoAP response message acknowledging the deleting of the CoAP pub/sub topic;

receiving, via the communication network from the other apparatus on the network, a third CoAP message indicating a request to create the CoAP pub/sub topic and including the CoAP Option fields set to indicate an updated publish control policy for the CoAP pub/sub topic; and

creating the CoAP pub/sub topic with the updated publish control policy.

4. The apparatus recited in claim 2, wherein the request to update the publish control policy of the CoAP pub/sub topic comprises a CoAP pub/sub UPDATE operation including the CoAP Option fields set to indicate an updated publish control policy for the CoAP pub/sub topic.

5. The apparatus recited in claim 1, wherein the computer-executable instructions, when executed by the processor of the apparatus, further cause the apparatus to:

receive, via the communication network from the other apparatus on the network, a second CoAP message including a second CoAP Option field set to indicate a request to publish a first data to the CoAP pub/sub topic;

determine, based on the publish control policy, to allow or deny the request; and send, via the communication network to the other apparatus on the network, a second CoAP response message including a third CoAP Option field set to indicate the determination.

6. The apparatus recited in claim 5, wherein the third CoAP Option field was set to indicate the request to publish data to the CoAP pub/sub topic was allowed, and wherein the computer- executable instructions, when executed by the processor of the apparatus, further cause the apparatus to:

receive, via the communication network from the other apparatus on the network, a first CoAP block transfer to publish the first data at the CoAP pub/sub topic.

7. The apparatus recited in claim 6, wherein computer-executable instructions, when executed by the processor of the apparatus, further cause the apparatus to:

send, via the communication network to the other apparatus on the network, a third CoAP message including a fourth CoAP Option field set to indicate the first CoAP block transfer should be terminated due to a second CoAP block transfer.

8. An apparatus comprising a processor, a memory, and communication circuitry, the apparatus being connected to a communications network via its communication circuitry, the apparatus further comprising computer-executable instructions stored in the memory of the apparatus which, when executed by the processor of the apparatus, cause the apparatus to: receive, via the communication network from a subscriber apparatus on the network, a first CoAP message indicating a request to subscribe to a CoAP pub/sub topic and including a CoAP Option field set to indicate a notification scheme for the subscriber apparatus for the CoAP pub/sub topic;

receive, via the communication network from a publisher apparatus on the network, a first CoAP block transfer including a first data for publishing to the CoAP pub/sub topic; and send, via the communication network to the subscriber apparatus, the first data according to the notification scheme.

9. The apparatus recited in claim 8, wherein the notification scheme is a block-by-block notification scheme and wherein the computer-executable instructions, when executed by the processor of the apparatus, further cause the apparatus to:

for each block of the first data:

receive, via the CoAP block transfer from the publisher apparatus, the block of the first data; and

send, via the communication network to the subscriber apparatus, the block of the first data.

10. The apparatus recited in claim 9, wherein the computer-executable instructions, when executed by the processor of the apparatus, further cause the apparatus to:

receive, via the communication network from a second publisher apparatus on the network, a second CoAP block transfer including a second data for publishing to the certain CoAP pub/sub topic;

terminate the first CoAP block transfer for publishing the first data; and

send, via the communication network to the subscriber apparatus, a second CoAP message including a second CoAP Option field set to indicate that blocks of the first data will no longer be sent and future messages will include blocks of the second data.

11. The apparatus recited in claim 8, wherein the notification scheme is a data-by-data notification scheme and wherein the send, via the communication network to the subscriber apparatus, the first data according to the notification scheme further comprises: initiating, with the subscriber apparatus on the network, a second CoAP block transfer to transmit the first data.

12. The apparatus recited in claim 11, wherein the computer-executable instructions, when executed by the processor of the apparatus, further cause the apparatus to:

receive, via the communication network from a second publisher apparatus on the network, a third CoAP block transfer including a second data for publishing to the certain CoAP pub/sub topic; and

send, via the communication network to the subscriber apparatus, a second CoAP message including a second CoAP Option field set to indicate that the second CoAP block transfer should be terminated.

13. An apparatus comprising a processor, a memory, and communication circuitry, the apparatus being connected to a communications network via its communication circuitry, the apparatus further comprising computer-executable instructions stored in the memory of the apparatus which, when executed by the processor of the apparatus, cause the apparatus to:

send, via the communication network to a broker apparatus on the network, a first CoAP message including a CoAP Option field set to request the number of clients for a CoAP pub/sub topic; and

receive, via the communication network from the broker apparatus on the network, a second CoAP message including a second CoAP Option field set to indicate the number of clients for the CoAP pub/sub topic.

14. The apparatus recited in claim 13, wherein the clients are publishers to the CoAP pub/sub topic.

15. The apparatus recited in claim 14, wherein the computer-executable instructions, when executed by the processor of the apparatus, further cause the apparatus to:

determine, based upon the number of publishers, whether to subscribe to the CoAP pub/sub topic.

16. The apparatus recited in claim 13, wherein the clients are subscribers to the CoAP pub/sub topic.

17. The apparatus recited in claim 16, wherein the computer-executable instructions, when executed by the processor of the apparatus, further cause the apparatus to:

determine, based upon the number of subscribers, whether to publish to the CoAP pub/sub topic.

18. The apparatus recited in claim 1, wherein the computer-executable instructions, when executed by the processor of the apparatus, further cause the apparatus to:

generate a graphical user interface for a user to view characteristics of the publish control policy.

19. The apparatus recited in claim 1, wherein the computer-executable instructions, when executed by the processor of the apparatus, further cause the apparatus to:

receive, via the communication network from the other apparatus on the network, a first maximum block size for block transfers.

20. The apparatus recited in claim 7, wherein computer-executable instructions, when executed by the processor of the apparatus, further cause the apparatus to:

delete the first data of the CoAP pub/sub topic.