+

WO2018132557A1 - Commutation de protocole dynamique - Google Patents

Commutation de protocole dynamique Download PDF

Info

Publication number
WO2018132557A1
WO2018132557A1 PCT/US2018/013299 US2018013299W WO2018132557A1 WO 2018132557 A1 WO2018132557 A1 WO 2018132557A1 US 2018013299 W US2018013299 W US 2018013299W WO 2018132557 A1 WO2018132557 A1 WO 2018132557A1
Authority
WO
WIPO (PCT)
Prior art keywords
resource
coap
broker
protocol
network
Prior art date
Application number
PCT/US2018/013299
Other languages
English (en)
Inventor
Xiang Sun
Chonggang Wang
Quang Ly
Xu Li
Original Assignee
Convida Wirewless, Llc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Convida Wirewless, Llc filed Critical Convida Wirewless, Llc
Publication of WO2018132557A1 publication Critical patent/WO2018132557A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks

Definitions

  • CoRE Constrained Application Protocol
  • IoT Internet of Things
  • CoAP Hypertext Transfer Protocol
  • FIG. 1 a CoAP Messages Layer for handling UDP packets, 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.
  • both the messages layer and the request/response layer are implemented via features of the CoAP header.
  • the CoAP messaging model may be based on the exchange of messages over UDP between clients and servers; optionally, CoAP may also run on top of other transport protocols, such as Datagram Transport Layer Security (DTLS), Short Message Service (SMS), Transmission Control Protocol (TCP), or Stream Control Transmission Protocol (SCTP) based on different requirements.
  • DTLS Datagram Transport Layer Security
  • SMS Short Message Service
  • TCP Transmission Control Protocol
  • SCTP Stream Control Transmission Protocol
  • the CoAP message format follows a short fixed-length binary header (4 bytes) associated with compact binary options and a payload. Each message contains a message ID used to detect duplicates.
  • CoAP defines four types of messages: CON, NON, ACK, and RST.
  • Confirmable message is retransmitted using a default timeout and exponential back-off 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 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 is used to acknowledge receipt of a CON.
  • a Reset message may be used when a recipient is not able to process a CON or NON.
  • CoAP defines four methods: GET, POST, PUT, and DELETE.
  • 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.
  • URI Uniform Resource Identifier
  • the POST method requests that the representation enclosed in the request be processed.
  • the actual function performed by the POST method is 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.
  • 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.
  • the DELETE method requests that the resource identified by the request URI be deleted.
  • CoAP request and response semantics are carried in CoAP messages.
  • a Token is used to match responses to requests independently from the underlying messages and is a concept different from the Message ID.
  • FIGs. 4A and 4B show examples of the synchronous case. Such a case may be applied to a scenario where the content of a resource that is requested by a client is immediately available on the server side.
  • 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 shown in FIG. 4A and is called a "piggy-backed response."
  • the client requests a
  • the server responds with an ACK message piggybacked with the temperature value, which is "22.5 C”. If the server does not find the requested resource, as shown in FIG. 4B, the server responds with an ACK message piggybacked with the error code "4.04" (Not Found). 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 CoAP Server's Response. If a request is sent in a NON, then the response is sent using a new NON.
  • FIG. 5 shows an example of the asynchronous case. Such a case may be applied to a scenario where the content of a resource that is requested by a client is not immediately available on the server side.
  • the client when a request is carried in a CON, the client will receive an empty ACK to avoid having the client continuously retransmit the request for the resource. Later, when the requested content becomes available, the server will issue a new CON that includes the piggybacked response to the client's initial CON request. The client may then send an ACK to confirm the content was successfully received.
  • the token "0x73" is used to associate the response with the previous request.
  • 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.
  • FIG. 6 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 or function set, 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.
  • clients acting as publishers that are willing to utilize the broker to publish their topics may discover the broker, create topics in the broker, and send publications of the topics to the broker.
  • 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
  • a CoAP Pub/Sub broker is a CoAP server that exposes 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.
  • the broker should additionally have sufficient resources to also store buffer messages on behalf of the clients.
  • a CoAP Pub/Sub client interacts with a CoAP Pub/Sub broker using the aforementioned CoAP Pub/Sub interface. Clients initiate interactions with the CoAP Pub/Sub broker, which reacts to the interactions.
  • a client acting as a data provider e.g., sensor clients
  • a client acting as a data consumer or "Subscriber” e.g., a user app
  • Data is typically categorized by topic.
  • Clients and brokers use CoAP Pub/Sub topics to identify a particular resource or object in a Pub/Sub system.
  • 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.
  • CoAP Pub/Sub function set A CoAP Pub/Sub function set may be separated into two subsets, a publisher-to-broker function set and a subscriber-to-broker function set.
  • the publisher-to-broker function set defines four types of operations between a publisher and a broker: DISCOVER, CREATE, PUBLISH, and REMOVE. All four of these operations may be initiated by the publisher.
  • a publisher may discover a CoAP Pub/Sub broker by applying CoAP Simple Discovery.
  • FIG. 7 shows an example of a publisher applying the Simple Discovery method to find a broker.
  • a broker may advertise its supported content formats and other attributes in the link to its Pub/Sub function set.
  • a publisher may also discover a broker through a Resource Directory (RD).
  • RD Resource Directory
  • a publisher may create a topic on the broker by applying the CREATE operation.
  • a publisher 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. 8 shows an example of a topic called "topic 1" being successfully created at the broker.
  • the broker should return a response code of "2.01 Created” and the created URI path if the topic is successfully created. If the broker fails to create the topic, it should return the appropriate 4.xx response code indicating the reason for the failure.
  • the publisher may apply the PUBLISH operation to update the topic on the broker by transmitting the up-to-date publication of the topic to the broker.
  • the publisher should use the PUT method to transmit its topic publications.
  • FIG. 9 shows an example of a publisher sending a publication of topicl to the broker. After successfully receiving a publication, the broker should return a response code of "2.04 Changed" to acknowledge the publication to the publisher.
  • a publisher wishing to remove a topic may use a "REMOVE" operation, a CoAP DELETE operation on the URI of the topic.
  • FIG. 10 shows an example of a publisher attempting to delete topicl, which was published by the publisher. After successfully removing topicl, the broker should return a response code of "2.02 Deleted". If the broker fails to remove the topic, the broker should return the appropriate 4.xx response code indicating the reason for the failure.
  • the subscriber-to-broker function set defines four types of interfaces between a subscriber and a broker: DISCOVER, SUBSCRIBE, UNSUBSCRIBE, and READ. All four of these operations may be initiated by the subscriber.
  • the DISCOVER interface may be used by subscribers to find topics of interest.
  • a subscriber may search for a topic by a topic name or by link attributes, which may be registered at the broker when the topic is created.
  • FIG. 11 shows an example of a subscriber searching for a topic with a resource type (rt) of "temperature" at a broker using the DISCOVER interface.
  • the broker should return the URI of the topic and its content format (ct) if the requested topic has been found by the broker.
  • Subscribers may also use the RD to discover topics if the topics have been registered in the RD.
  • a subscriber may subscribe to a topic on the broker using the CoAP Observe interface, as defined by the CoAP Observe specification.
  • a subscriber wishing to observe a topic on a broker should use a "SUBSCRIBE" operation, a CoAP GET with Observe
  • FIG. 12 shows an example of a subscriber attempting to observe "topicl ", which was created by the shown Publisher in FIG. 12, by transmitting an observe request to the broker.
  • the broker should return a response code of "2.05 Content” along with the most recent publication of topicl if topicl contains a valid publication and the broker is able to supply the requested content format.
  • the subscriber may receive a notification from the broker along with the up-to-date publication of topicl . In FIG. 12, this is shown by Publisher updating topicl with a PUBLISH operation and the broker notifying Subscriber of the update using a subsequent notification.
  • the broker should notify the clients subscribed on a particular topic each time the broker receives a PUBLISH on that topic.
  • Subscribers that previously observed a topic at the broker may unsubscribe, i.e., de-register, from the topic by utilizing the CoAP UNSUBSCRIBE interface.
  • a subscriber wishing to de-register from a topic in a broker should use the "UNSUBSCRIBE" operation, either a CoAP GET operation sent with an Observe option set to ⁇ ' or a CoAP Reset message sent in response to a publication.
  • FIG. 13 shows an example of a subscriber de-registering from topicl by applying the CoAP GET operation with the Observe parameter of ⁇ ' .
  • the broker should return a response code of "2.05 Content" to indicate topicl is successfully de-registered by the subscriber.
  • a subscriber wishing to obtain only the most recent publication to a topic at a broker may use the "READ" operation, a GET method targeting the URI of the desired topic. This allows a subscriber to receive information about the topic without formally subscribing to the topic.
  • the broker Upon receiving a READ request, the broker should return a response code of "2.05 Content" along with the most recent topic publication if the topic at the broker contains a valid publication and the broker is able to supply the requested content format.
  • FIG. 14 shows an example of a subscriber successfully reading the publication from topicl at the broker, followed by a reading of the updated publication from topicl at a later time.
  • M2M/IoT devices are equipped with limited battery capacity and are required to run for a long period of time. In order to achieve this longevity, those devices may need to sleep when they are in idle status to reduce energy consumption.
  • the CoAP Pub/Sub architecture enables subscribers to be able to retrieve publications of topics even if the publishers that publish those topics are sleeping.
  • the CoAP Pub/Sub architecture does this by introducing a new entity, i.e., a broker, which is to be always- on to respond to topic retrieval requests from subscribers while publishers are sleeping.
  • FIG. 15 shows an example illustrating this benefit by enabling CoAP Pub/Sub communications for sleep- enabled publishers that send topic publications to topic subscribers.
  • a sleep- enabled publisher Publisher
  • Publisher may first create a topic, topicl, at a broker, Broker, and proceed to sleep.
  • Publisher may send an up-to-date publication to topicl at Broker.
  • a subscriber that is interested in topicl, Subscriber may attempt to read the publication of topicl .
  • Subscriber may read the publication even if Publisher is sleeping because Broker is hosting the publication and not sleeping.
  • CoAP endpoints such as clients or servers, may register in an RD.
  • An endpoint may register itself and a hosting resource to an RD that has been previously discovered by the endpoint. After registration, other endpoints may discover the resource using the RD Lookup Function Set, as defined by the CoAP Resource Directory specification. Similarly, an endpoint may update CoRE links of its hosting resources in the RD.
  • an endpoint may register itself and its hosting resources using the registration interface.
  • the registration interface may accept a POST from an endpoint containing the list of resources to be added to the directory as the message payload in the CoRE Link Format, as defined by the CoRE Link Format specification, JSON CoRE Link Format (application/linkformat+ json), or CBOR CoRE Link Format
  • the RD may then create a new resource or may update an existing resource in the RD and return the location of the resource. An endpoint must use that location when refreshing registrations using the registration interface. Endpoint resources in an RD may be kept active for the period indicated by the lifetime parameter.
  • the registration request interface may be specified as follows:
  • RD Function Set path (mandatory). This is the path of the RD Function Set, as obtained from discovery. An RD should use the value "rd" for this variable whenever possible.
  • Endpoint name (mandatory).
  • the endpoint name is an identifier that must be unique within a domain.
  • the maximum length of this parameter is 63 bytes.
  • the RD may associate the endpoint with a configured default domain.
  • Endpoint Type (optional). The semantic type of the endpoint. This
  • Lifetime (optional). This is the lifetime of the registration in seconds. The range of this parameter may be 60-4294967295. If no lifetime parameter is included, a default value of 86400 (24 hours) should be assumed.
  • Context (optional). This parameter sets the scheme, address, and port at which this server is available in the form "scheme://host:port”. In the absence of this parameter, the scheme of the protocol, source IP address, and source port of the register request are assumed to be known. This parameter is mandatory when the directory is filled by a third party such as a
  • FIG. 16 shows an example of an endpoint registering itself and the endpoint' s hosting resources.
  • the endpoint in this example is named "nodel”, and nodel 's hosting resources are temperature and light data.
  • Endpoint nodel registers itself and the temperature and light resources to the RD using the registration interface, as described above, and the RD returns the location of the endpoint's resources in the RD, "/rd/3210", after registration is successful.
  • the endpoint may modify and update its hosting resources' CoRE link attributes in the RD by applying the Update Endpoint Links function.
  • the Update Endpoint Links function may use the PATCH method to add, remove, or change links for the endpoint by including link update information in the payload of the update.
  • One or more links may be selected for update by using query filtering.
  • the query filter may select the links to be modified or deleted by matching the query parameter values to the values of the link attributes.
  • Location (mandatory). This is the Location path returned by the RD as a result of an earlier, successful registration.
  • FIG. 17 shows an example of an endpoint adding a resource, modifying a resource, and removing a resource, in that order, using the Update Endpoint Links function.
  • the endpoint has already registered with the RD, and the endpoints resources are stored at "/rd/3120" in the RD.
  • the endpoint is requesting to add the "/sensors/humid" resource to the RD.
  • the request is successful, and the RD returns a "2.04 Changed" status to the endpoint to indicate the successful update.
  • the endpoint is requesting to modify the CoRE link attributes of the "/sensors/temp" resource in the RD.
  • the request is successful, and the RD returns a "2.04 Changed" status to the endpoint.
  • the endpoint is requesting to remove the "/sensors/light” resource from the RD.
  • the request includes a "null" payload as no attributes are being added or changed to the "/sensors/light” resource.
  • the RD successfully removes the "/sensors/light” resource and returns a "2.04 Changed" status to the endpoint.
  • a CoAP Pub/Sub broker and an RD may interact in various ways, as defined by the CoAP Pub/Sub specification.
  • a CoAP Pub/Sub broker may register its Pub/Sub function set with an RD, which may then be discovered by a CoAP Pub/Sub client via the RD to inform the client how to interact with the broker.
  • a CoAP Pub/Sub broker may also register Pub/Sub topics to an RD, and Pub/Sub clients may then be able to discover those topics via the RD.
  • a CoAP Pub/Sub broker may register links of its topics to an RD. For example, an RD may be triggered to retrieve links from ".well-known/core".
  • W3C World-Wide Web Consortium proposes the concept of Web of Things (WoT). According to their description, "The Web of Things needs to be able to model the real world at different levels of abstraction, and to enable open markets with free competition of services across these levels. The things in the Web of Things can be considered as virtual representations of objects.” W3C has created a WoT interest group, which currently has two work items: WoT Architecture and WoT Current Practices. According to the latest WoT interest group charter: "Things stand for physical or abstract entities such as sensor nodes and services encompassing multiple devices, respectively. Each thing is identified with a URL This URI can be followed to access the thing's description, which can include its relationship to other things, analogous to links in HTML.
  • the Web of Things also allows for on-device data processing and direct thing-to-thing interaction.
  • things can provide a standardized vendor neutral runtime environment for portable apps, similar to Web apps running in every browser. Due to the variations in requirements across application domains, there are many protocols. Things can be interacted with on many kinds of platforms and devices ranging from resource-constrained IoT devices and less constrained gateways to cloud-based server farms.
  • Web browsers may be used for the human-machine interface for services based around the Web of Things.”
  • W3C has defined a WoT Current Practices specification that defines "things.”
  • a thing may be described by a parameter labeled a Thing Description (TD).
  • TD Thing Description
  • a TD may include the following four categories of metadata about a thing: (1) semantic metadata such as generic thing information and context enrichment; (2) the thing's interaction resources such as property, action, and event; (3) communication metadata such as protocols supported by the thing, data exchange formats with the thing, and bindings to an interaction resource; and (4) security metadata such as prerequisites to access the thing and its resources, and security
  • FIG. 18 shows an example of a W3C WoT TD.
  • This example TD includes the following metadata about a thing:
  • the value of the property has an estimated stability of 10ms (i.e., the value will not change within 10ms).
  • CoAP communications provide direct interactions between endpoints, such as a client-server interaction.
  • CoAP Pub/Sub communications introduce indirect interactions between endpoints, such as those between publishers and subscribers, in which sleep-enabled endpoints may be able to deliver updated content, or publications, to interested endpoints, such as subscribers of the content.
  • CoAP Pub/Sub architecture is useful when M2M/IoT nodes intend to sleep for a period of time yet wish to allow other nodes to access resource information.
  • the existing CoAP Pub/Sub architecture does not consider the waste associated with the broker node being always-on. When few or zero subscribers will be accessing published data, the conventional CoAP protocol may waste less energy and require fewer data
  • CoAP Pub/Sub transmissions than CoAP Pub/Sub. Therefore, it may be desirable to switch between the two communication modes in order to limit waste and/or account for other performance
  • Embodiments disclosed herein provide modifications to the existing CoRE Link attributes/formats and the existing CoAP protocol to minimize waste associated with excess data exchanging and excess power consumption by enabling dynamic switching between CoAP and CoAP Pub/Sub.
  • a new procedure for switching from CoAP to CoAP Pub/Sub is described.
  • a new procedure for switching from CoAP Pub/Sub to CoAP is described.
  • Several new CoRE link attributes are introduced to enable the dynamic switching between CoAP and CoAP Pub/Sub and vice versa.
  • a new CoAP response code is also introduced to notify resource consumers that the communication mode used to access the resource has changed.
  • new WoT TD metadata attributes modeled after the proposed new CoRE Link attributes, are introduced to enable dynamic protocol switching in the W3C WoT framework.
  • FIG. 1 illustrates the interaction model of the CoAP protocol
  • FIG. 2 shows an example message flow in accordance with the CoAP protocol
  • FIG. 3 shows another example message flow in accordance with the CoAP protocol
  • FIGs. 4A-B show another example message flow in accordance with the CoAP protocol
  • FIG. 5 shows another example message flow in accordance with the CoAP protocol
  • FIG. 6 illustrates the basic interaction model of the CoAP Pub/Sub architecture
  • FIG. 7 shows an example message flow of a client using the CoAP Pub/Sub DISCOVER operation
  • FIG. 8 shows an example message flow of a CoAP Pub/Sub CREATE operation
  • FIG. 9 shows an example message flow of a CoAP Pub/Sub PUBLISH operation
  • FIG. 10 shows an example message flow of a CoAP Pub/Sub REMOVE operation
  • FIG. 11 shows an example message flow of a subscriber using the CoAP Pub/Sub DISCOVER operation
  • FIG. 12 shows an example message flow of a subscriber using the CoAP Pub/Sub SUBSCRIBE operation
  • FIG. 13 shows an example message flow of a subscriber using the CoAP Pub/Sub UNSUBSCRIBE operation
  • FIG. 14 shows an example message flow of a CoAP Pub/Sub READ operation
  • FIG. 15 illustrates an example use case and call flow of CoAP Pub/Sub communications
  • FIG. 16 shows an example message flow of endpoint registration in an RD
  • FIG. 17 shows an example message flow of endpoint CoRE link updating in an
  • FIG. 18 shows an example embodiment of a W3C WoT TD
  • FIGs. 19A-B show an example use case illustrating one or more benefits of using CoAP Pub/Sub over conventional CoAP;
  • FIGs. 20A-B show an example use case illustrating one or more benefits of using conventional CoAP over CoAP Pub/Sub;
  • FIG. 21 shows a diagram illustrating functional differences between CoAP Pub/Sub and conventional CoAP architectures and potential communication mode switching between them;
  • FIG. 22 shows an example sequence diagram for switching from conventional CoAP to CoAP Pub/Sub
  • FIG. 23 shows an example message flow for creating a resource at a broker
  • FIG. 24 shows an example message flow for notifying resource consumers that a resource URI has changed using new CoRE link attributes
  • FIG. 25 shows another example message flow for notifying resource consumers that a resource URI has changed using new CoRE link attributes
  • FIG. 26 illustrates an example of a duplicate Token IDs problem at the broker
  • FIG. 27 shows an example message flow for notifying existing read resource consumers that a resource URI has changed using a new CoAP response code
  • FIG. 28 shows an example message flor for updating resource entries in an RD after switching from conventional CoAP to CoAP Pub/Sub;
  • FIG. 29 shows an example sequence diagram for switching from CoAP Pub/Sub to conventional CoAP
  • FIG. 30 shows an example message flow for deleting a resource at a broker during switching initiated by a resource provider
  • FIG. 31 shows an example message flow for deleting a resource at a broker during switching initiated by the broker
  • FIG. 32 shows an example message flow for notifying resource consumers that a resource URI has changed using new CoRE link attributes
  • FIG. 33 shows another example message flow for notifying resource consumers that a resource URI has changed using new CoRE link attributes
  • FIG. 34 shows an example message flow for notifying existing read resource consumers that a resource URI has changed using a new CoAP response code
  • FIG. 35 shows an example message flor for updating resource entries in an RD after switching from CoAP Pub/Sub to conventional CoAP;
  • FIG. 36 illustrates an example method of measuring the load of a resource;
  • FIG. 37 shows an example embodiment of a W3C WoT TD using new metadata attributes to enable dynamic switching between conventional CoAP and CoAP Pub/Sub;
  • FIG. 38 shows an example graphical user interface (GUI) in accordance with an example embodiment
  • FIG. 39A 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;
  • M2M machine-to-machine
  • IoT Internet of Things
  • WoT Web of Things
  • FIG. 39B is a system diagram of an example architecture that may be used within the M2M/IoT/WoT communications system illustrated in FIG. 39A;
  • FIG. 39C 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
  • FIG. 39D is a block diagram of an example computing system in which a node or apparatus of the communication system of FIGs. 39A and 39B may be embodied.
  • Conventional messaging protocols and publish-subscribe messaging protocols may perform optimally in different scenarios. As such, it may be beneficial to allow switching between a conventional messaging protocol and a publish-subscribe messaging protocol. Two examples of such messaging protocols include conventional CoAP and CoAP Pub/Sub, respectively.
  • CoAP communications and CoAP Pub/Sub communications have various pros and cons associated with their respective communication modes.
  • Conventional CoAP communications provide direct interactions between CoAP endpoints.
  • CoAP Pub/Sub communications introduce indirect interactions between CoAP endpoints by enabling a third, always-on endpoint called a "broker" that enables store-and-forward messaging between two or more nodes, allowing sleep-enabled publishers to deliver their publications to subscribers.
  • Each mode could be useful over the lifetime of an M2M/IoT/WoT system.
  • an entity such as an M2M/IoT/WoT device, to dynamically switch its communication mode from conventional CoAP to CoAP Pub/Sub or vice versa, creating excess power and data usage in such devices and systems.
  • the term “resource provider” may represent “CoAP server” and “CoAP Pub/Sub publisher”
  • the term “resource consumer” may represent “CoAP client” and “CoAP Pub/Sub subscriber”
  • the term “resource” may represent "CoAP resource” and "CoAP Pub/Sub topic”.
  • CoAP communication implies that a resource is located at the resource provider side, and the resource consumers that are interested in the resource may retrieve the content of the resource directly from the resource provider.
  • CoAP Pub/Sub communication implies that a resource may be created in a broker, and the resource consumers that are interested in the resource may retrieve the content of the resource from the broker rather than directly from the resource provider; further, the resource provider may publish the contents of the resource to the broker when the state of the resource changes.
  • switching between CoAP and CoAP Pub/Sub may involve the following.
  • Switching from CoAP to CoAP Pub/Sub indicates that a resource, which previously existed in the resource provider, is now created in the broker, and the broker should now respond to resource retrieval requests from resource consumers on behalf of the resource provider.
  • switching from CoAP Pub/Sub to CoAP indicates that a resource may be deleted from the broker, and the resource provider now takes the responsibility of responding to resource retrieval requests from the resource consumers.
  • a resource provider or broker may contain multiple resources, and different resources may apply different communications modes. Enabling a resource to be dynamically switched between CoAP and CoAP Pub/Sub may substantially benefit the resource provider, resource consumer, and broker in various aspects, described below. Note that a resource itself is not able to conduct the switching between CoAP and CoAP Pub/Sub. Instead, the entity that hosts the resource, such as the resource provider or the broker, may conduct the switching. [0094] To illustrate the deficiencies of existing systems, which do not allow the switching of communication modes, consider the following use cases, shown in FIGs. 19A-B and 20A-B.
  • a stadium parking lot contains a number of parking meters.
  • Each street parking meter located near the stadium contains a parking spot status resource over time and sends the status to the meter's resource consumers, which are entities such as smart cars that are interested in the parking spot status resource.
  • the parking spot status resource may indicate how long before the parking spot becomes available based on the expiration time shown on the parking meter. It may be more beneficial for resource consumers to obtain information regarding expiration time rather than an emptiness flag because a resource consumer may select the shortest waiting time and proactively drive there before the parking spot becomes empty instead of many resource consumers racing towards a single empty parking spot.
  • tens of thousands of smart cars may try to search for available parking spots near the stadium before the game. Those smart cars become the resource consumers, which try to retrieve the content of the "parking spot status" resources in those parking meters.
  • Resource provider 1 needs to process five requests from the smart cars and accordingly send five responses. If CoAP Pub/Sub is used, as shown in FIG. 19B, Resource provider 1 would only need to create the resource in a broker, send the content of the resource to the broker, and let the broker forward the content of the resource to the five smart cars that are interested in this resource.
  • CoAP Pub/Sub mode may reduce the energy consumption of the resource provider in this scenario because the resource provider sends a fewer number of packets to deliver the resource content to the resource consumers when compared to conventional CoAP communications.
  • CoAP Pub/Sub communications may reduce the response time of resource consumers successfully receiving the content of the resource when compared to the conventional CoAP communications. The response time may be reduced because the broker may have more powerful hardware than the resource provider (i.e., the parking meter), and so the transmission rate of the broker may be higher than that of the resource provider.
  • Resource provider 1 may continuously send the content of the resource, which indicates after how long time the parking spot will be empty, to the broker even if there is no existing resource consumer that is interested in the resource.
  • the use of conventional CoAP communications may require less energy consumption from the resource provider as compared to the use of CoAP Pub/Sub communications.
  • statically applying one communication mode i.e., applying only conventional CoAP communications or only CoAP Pub/Sub communications, for delivering the content of a resource may not be the optimal solution to support different scenarios.
  • Table 1 describes some pros and cons of CoAP and CoAP Pub/Sub.
  • One issue is that switching from CoAP to CoAP Pub/Sub may not provide the broker with enough information to successfully host a resource and later switch back to using CoAP. For example, if a resource provider determines to switch one of its resources from CoAP to CoAP Pub/Sub, the resource provider may send a switching request (i.e., a resource creation request message) to the broker.
  • a switching request i.e., a resource creation request message
  • the resource creation request message may not contain additional information about the resource, such as the UR.I of the resource in the resource provider, the resource load information, and other information describing the resource.
  • the broker may be unable to switch the resource back to CoAP if CoAP becomes more suitable for delivering the content of the topic. For example, if a resource is currently utilizing CoAP Pub/Sub, the resource provider hosting the resource may transmit the up-to-date content of the resource to the broker, and the broker may deliver the content to resource consumers that request the content. If the broker attempts to switch the communication mode of the resource from CoAP Pub/Sub to CoAP, the broker may send the switching request to the resource provider to inform the resource provider about the switching.
  • the broker may not be able to inform the resource provider about the switching, which may result in the broker being unable to switch to CoAP.
  • the broker lacking information about the resource such as the resource's load information, may result in the broker being unable to perform congestion control when a resource provider attempts to apply CoAP Pub/Sub to deliver the content of a resource by creating the resource in the broker.
  • Resource load information may be defined in various ways, as described later in the specification. Information such as the load information and other information used for determining possible congestion may allow the broker to determine whether the resource will be cached or not. Caching may be important for keeping the broker from congesting.
  • each resource creation request message should provide the resource load information to the broker, which may allow the broker to perform access control and determine whether to accept the resource creation request or not.
  • a second issue is that after the resource has been switched from CoAP to CoAP Pub/Sub, the existing resource consumers, which have issued an observation to the resource or previously read the resource, should retrieve the content of the resource from the broker rather than from the resource provider.
  • the existing resource consumers which have issued an observation to the resource or previously read the resource, should retrieve the content of the resource from the broker rather than from the resource provider.
  • a third issue is that after the resource has been switched from CoAP to CoAP Pub/Sub, the RD should respond to new resource consumers, which are attempting to discover the resource via the RD, with the URI of the resource in the broker so those new resource consumers may directly send resource retrieval requests to the broker.
  • the resource entries of the RD are currently not updated after the switching, and so the new resource consumers may only discover the resource in the resource provider, rather than the resource in the broker, via the RD.
  • a second issue is that after the content of the resource has been deleted from the broker, the existing resource consumers, which have issued an observation to the resource or previously read the resource, should retrieve the content of the resource from the resource provider rather than the broker.
  • the existing resource consumers which have issued an observation to the resource or previously read the resource, should retrieve the content of the resource from the resource provider rather than the broker.
  • a third issue is that after the content of the resource has been deleted from the broker, the RD should respond to the new resource consumers, which are attempting to discover the resource via the RD, with the URI of the resource in the resource provider so these new resource consumers may directly send resource retrieval requests to the resource provider.
  • the resource entries of the RD are currently not updated after the switching, and so the new resource consumers may only discover the resource in the broker, rather than the resource in the resource provider, via the RD.
  • this disclosure introduces new interactions among relevant entities, such as new interactions between the RD and the broker and new interactions between resource providers and the RD.
  • a procedure for switching from CoAP to CoAP Pub/Sub is introduced.
  • a procedure for switching from CoAP Pub/Sub to CoAP is introduced.
  • Several new CoRE link attributes and a new CoAP response code are introduced to enable the dynamic switching between protocols.
  • New WoT TD metadata attributes are also introduced to enable dynamic protocol switching in the W3C WoT framework.
  • a procedure for switching from CoAP to CoAP Pub/Sub is introduced.
  • a resource switched from CoAP to CoAP Pub/Sub may be created in a broker, and the resource consumers that are interested in the resource should retrieve (i.e., read or observe) the resource from the broker; the resource consumers should access the resource via the broker rather than the resource provider.
  • This aspect may involve at least three main tasks: (1) resource creation in the broker; (2) resource URI change notification to the existing resource consumers; and (3) resource entry updating in the RD.
  • Describing the switching from CoAP to CoAP Pub/Sub assumes a number of prerequisite conditions. It is assumed that a resource in the resource provider has existing resource consumers, which subscribed to or observed the resource or previously read the resource. Additionally, the resource provider has already discovered the broker as well as the RD in the network, and the resource provider and the broker have already registered their hosting resources in the RD.
  • a resource switched from CoAP to CoAP Pub/Sub may involve a resource being created in the broker and the resource consumers being notified and able to retrieve (i.e., read or observe) the content of the resource from the broker.
  • the resource provider may transfer to the broker the service of transmitting the content of the resource.
  • the resource provider may initialize the switching from CoAP to CoAP Pub/Sub by sending a switching request, such as a resource creation request, to the broker.
  • the resource provider may trigger the switching because the switching may be advantageous to the entities involved in communications. For example, such a switch may be energy saving because the resource provider may offload the processing of a large number of requests.
  • the resource provider may be configured for sleep-enabled mode and wish to provide a resource during sleep.
  • the switching process from CoAP to CoAP Pub/Sub may comprise three main tasks, described in further detail below: (1) resource load measurement and resource creation in the broker; (2) URI change notification to existing resource consumers; and (3) resource entry update in the RD.
  • the resource provider may measure the load of each resource when the resource is applied to CoAP communications prior to switching to CoAP Pub/Sub.
  • the resource provider may then inform the broker about the load of the resource after the resource provider determines to switch from CoAP to CoAP Pub/Sub for a resource.
  • the broker may apply this information to determine if the broker has sufficient capacity to handle the resource.
  • the load of the resource may be defined in various ways. For example, the load may be defined as the number of resource consumers interested in the resource. In another example, the load may be defined as the number of successful packets transmitting to a resource consumer for a specific resource.
  • One possible solution to measure the load of a resource is described later in the specification.
  • a trigger event may occur that causes the resource provider to switch communication modes or protocols (i.e., CoAP to CoAP Pub/Sub or vice versa).
  • a trigger event may be that the load of the resource may be larger than the threshold of the resource provider.
  • a trigger event may be that the resource provider has determined to enter sleep mode.
  • the resource provider may initialize the switching from CoAP to CoAP Pub/Sub by applying the following steps, as shown in FIG. 23.
  • the resource provider may send a switching request (i.e., a resource creation request) to the broker.
  • the resource creation request message may contain the following new CoRE link attributes of a resource:
  • the purpose of containing the 'cm' attribute in the resource creation request is to inform the broker that the resource is being requested to switch to CoAP Pub/Sub. Note that it is optional to include the 'cm' attribute in the resource creation request message.
  • attribute in the resource creation request is to enable the broker to establish a priority for each resource. For example, a resource whose switching purpose is
  • the broker may first delete the resource with lower priority as indicated or derived from 'sp' attributes. Note that the broker determining to delete the resource may trigger the broker enabling the switching from CoAP Pub/Sub back to CoAP for that resource, which is described later in the specification.
  • • 'tli' : 'tli' indicates the resource load measurement.
  • the purpose of containing the 'tli' attribute in the resource creating request is to enable the broker to check if the broker still has the capacity to handle the resource.
  • 'pURT indicates the full URI of the resource in the resource provider.
  • a resource's full URI (e.g., "coap://192.168.1.28:5683/pub/rscl") comprises the IP address (e.g., 192.168.1.28) and the port number of the endpoint hosting the resource (e.g., 5683) as well as the URI path of the resource (e.g., ./pub/rscl).
  • the purpose of containing the 'pURI' attribute in the resource creation request is to enable the broker to have the capability of switching back to CoAP.
  • the broker may use the information of the 'pURF attribute to inform the resource provider which resource is requested to use CoAP.
  • the attributes in the resource creation request indicate the resource provider is attempting to create resource "rscl” in the broker, the resource type of rscl is "temperature”, the communications mode of rscl will be switched to CoAP Pub/Sub, the switching purpose is "energy saving”, the load resulting from access of rscl is "5", and the full URI of rscl in the resource provider is "coap://local-areal/pub/rscl".
  • the broker may process the request and determine if the resource may be created. If the resource is successfully created at the broker, the broker should respond to the creation request with a 2.01 Created response and the URI of the resource created in the broker. The broker may also store the values of 'cm', 'sp', and 'pURF, as shown in FIG. 23. If the resource was not created, the broker should send a 4.00 Bad Request to indicate that it was not feasible to create the resource in the broker.
  • the resource provider may store the URI of the resource in the broker (i.e., "coap://local-broker/ps/rscl").
  • the URI of the resource in the broker may be stored by the resource provider in a new CoRE link attribute, 'bURF, associated with the resource.
  • the resource provider may send a content update of the resource to that URI. Now, the resource with its latest content update is stored at the broker, and the broker will handle requests for content moving forward.
  • the resource provider may stop sending the content of the resource to the resource consumers associated with that resource.
  • the resource provider may take the responsibility of notifying the existing resource consumers, which previously retrieved the resource directly from the resource provider, about the new full URI of the resource (i.e., the value of the 'bURF attribute).
  • the new full URI may indicate the broker's Context, e.g., the broker's IP address and port number, and the URI path of the resource in the broker.
  • the resource provider may notify existing resource consumers differently based on classification or previous interactions. One such classification scheme may separate the consumers into two groups: the existing observe resource consumers and the existing read resource consumers.
  • the existing observe resource consumers may refer to the resource consumers that have issued an observation to the resource at the resource provider.
  • the broker may select its preferred method, or there may be a default method of notification.
  • the resource provider may notify the existing observe resource consumers about the new full URI of the resource at the broker.
  • the steps of such a notification scheme enable the resource provider to send a notification message to each of the existing observe resource consumers informing these existing observe resource consumers that they need to send requests to the broker in order to continue observing the resource.
  • the steps are illustrated in FIG. 24 and may be performed as follows.
  • the resource provider may send a URI change notification message to the existing observe resource consumers.
  • the URI change notification message should have the same Token ID as the previous notification message sent by the resource provider before the switching.
  • the Token ID may be used to identify a resource in the resource provider/broker being observed by a resource consumer. Thus, if the resource consumer observes different resources in the same resource provider/broker, then these resources' corresponding Token IDs should be different; if the resource consumer observes different resources from different resource providers/brokers, then their corresponding Token IDs may be the same.
  • the URI change notification message should contain a payload with the new 'nURI' attribute.
  • the 'nURI' attribute may be used to indicate the full URI of the resource in the broker. Further description of the 'nURI' attribute is discussed later in the specification.
  • the URI change message should be a CON to let the resource consumer confirm successful reception of the message.
  • the resource consumer may update its URI of the resource with the value in the 'nURF attribute and send a 2.04 (Changed) response to the resource provider to acknowledge receipt. If the resource provider does not receive the response from the resource consumer after
  • the resource consumer may send a request to the broker to initiate the resource observation process directly from the broker.
  • step 4 after the broker receives the observe request, it may act in accordance with CoAP Pub/Sub and send a notification to the resource consumer when the state of the resource changes.
  • the resource provider initially receives a request from an observe resource consumer to observe resource "rscl".
  • the request includes Token ID 0x2a.
  • the resource provider responds with a message containing the content of rscl and having the Token ID 0x2a.
  • the resource provider determines to switch communications protocols/modes for resource rscl and performs the resource creation processes at the broker, described above with respect to FIG. 23. Now, the resource provider should notify the existing observe resource consumer that the URI of the resource has changed.
  • the resource provider sends a URI change notification message to the existing observe resource consumer.
  • the URI change notification message is a CON and has the same Token ID, 0x2a, as the previous messages sent between the resource provider and the existing observer resource consumer before the switching.
  • the URI change notification message contains a payload with the new 'nURF attribute set to the new location of the resource, "coap://l ocal-broker.com/ps/rscl".
  • the existing observe resource consumer updates its URI of the resource to "coap://local- broker.com/ps/rscl". It then sends a 2.04 (Changed) response to the resource provider to acknowledge receipt.
  • the resource consumer has the resource's URI at the broker and sends a request to the broker to initiate the resource observation process from the broker.
  • the observe request message in this example has Token ID 0x2b.
  • the broker receives a resource update from the resource provider, setting the value of the rscl to "89.6".
  • the broker updates rscl with this value and sends a notification with Token ID 0x2b to the existing observe resource consumer.
  • This step may repeat when the resource provider updates rscl at the broker.
  • the resource provider may offload the list of observers of the resource to the broker.
  • the resource provider may send information about the existing observe resource consumers to the broker, and the broker may continue to send the content of the resource to the existing observe resource consumers without notifying these resource consumers that the URI of the resource has been changed.
  • This method allows the existing observe resource consumers to continue to receive updates without actively subscribing to a new URI.
  • the steps are illustrated in FIG. 25 and may be performed as follows.
  • the resource provider may send an observe list creation message to the broker.
  • the observe list creation message may contain the URI of the resource at the broker (i.e., "/ps/rscl"), and the existing observe resource consumers' information, which may be contained in the new Observer list', 'token id list', and 'seq num list' attributes.
  • the Observer list' attribute may contain the ID of each existing observe resource consumer; the 'token id list' attribute may contain the Token IDs that were used by the existing observe resource consumers to observe the resource in the resource provider; the "seq num list” attribute may contain the sequence number for each token in the 'token id list' .
  • the 'observer list', 'token id list', and 'seq num list' attributes are more fully described later in the specification.
  • the broker may successfully receive the observe list creation message and check for duplicated Token IDs already existing among the observe lists hosted by the broker.
  • a duplicated Token ID may indicate that the same Token ID is being used by the same resource consumer in different observer lists on the resource provider/broker (i.e., the resource consumer is using the same Token ID to observe different resources hosted by the same resource provider/broker), and the duplicated Token ID may result in the resource consumer losing the content of a specific resource.
  • FIG. 26 shows an example illustrating how a duplicated Token ID occurs and the effect of the duplicated Token ID.
  • resource consumer-1 attempts to observe resources rscl and rsc2 simultaneously; rscl is applying CoAP and hosted by resource provider- 1, and rsc2 is applying CoAP Pub/Sub and delivered via the broker.
  • resource consumer-1 sends one observe request each to resource provider-1 and the broker. It is possible for resource consumer-1 to assign the same Token ID, "0x4a" in this example, to observe rscl from resource provider-1 and observe rsc2 from the broker.
  • rscl is switched from CoAP to CoAP Pub/Sub.
  • rscl is created in the broker at step 2, and resource provider-1 sends the information of the existing observe resource consumers for rscl to the broker at step 3. Consequently, the broker contains the two observations from resource consumer-1 with the same Token ID, which creates confusion for resource consumer-1. Because resource consumer-1 now receives both content updates from the broker, resource consumer-1 considers all the content of rscl as the content of rsc2, and so resource consumer-1 loses all the updates from rscl . Thus, it is necessary for the broker to check for any duplicate Token IDs once it receives the observe list creation message.
  • the broker may perform different actions depending on if a duplicate Token ID is found. This is illustrated in FIG. 25 by Steps 3(a) and 3(b). If a duplicate Token ID is not found, then the broker goes to Step 3(a); if a duplicated Token ID is found, then the broker goes to Step 3(b).
  • the broker may create the observe list for the resource and send a 2.05 (Created) response to the resource provider to indicate that the broker is prepared to send content of the resource to the existing observe resource consumers.
  • a duplicated Token ID has been found.
  • Token ID: 0x4a ⁇ is identified by the broker to be a duplicate Token ID.
  • the broker may delete the information related to the duplicate Token ID (i.e., ⁇ Observe ID: 192.168.1.45, Token ID: 0x4a, Sequence Num: 11 ⁇ ) from the observe list and may send a message to the resource provider indicating the Observe ID of the duplicate Token ID,
  • step 4 after receiving the message about the duplicate Token ID information, the resource provider may be aware that the resource consumer having the duplicate Token ID, "192.168.1.45" in FIG. 25, failed to be created in rscl 's observe list in the broker. Consequently, the resource provider may send a notification message about the new full URI of rscl to the resource consumer with Observe ID "192.168.1.45" by applying Steps 1-3 of FIG. 24 in order to enable the resource consumer to re-observe rscl from the broker.
  • This step 4 procedure may be optional; specifically, step 4 is not necessary when a duplicate Token ID is not found in step 2.
  • the resource provider may send the up-to-date content of the resource to the broker when the state of the resource changes.
  • the broker may send the content of the resource to the existing observe resource consumers in the observe list.
  • the process is now complete, and the broker may now notify resource consumer-1 about resource updates.
  • Existing read resource consumers are those resource consumers that previously discovered and read a resource (i.e., retrieved the resource) from the resource provider before the switching of communication modes and may attempt to make subsequent reads after the switching.
  • the read resource consumers are trying to retrieve a resource that is no longer being served by the resource provider after the switching.
  • the resource provider may notify those read resource consumers about the new full URI of the resource (i.e., the full URI of the resource in the broker) so that the read resource consumers may retrieve the content of the resource from the broker.
  • the resource provider may notify those resource consumers about the new full URI of the resource by applying the following steps, seen in FIG. 27.
  • the resource provider may send a URI change response after it receives a resource read request from the read resource consumer.
  • the URI change notification may contain a new CoAP response code, 5.06 Communications Mode Switched, described later in the specification, with the content indicating the new full URI of the resource (i.e., "coap://local-broker.com/ps/rscl").
  • the resource provider may also include the content of the requested resource in the URI change notification message.
  • the read resource consumer may send an acknowledgement back to the resource provider, acknowledging the change. Then, the read resource consumer may update the URI of the resource based on the content in the response message and send a resource read request to the new URI, which points to the resource in the broker.
  • the broker may send the content of the resource to respond to the resource read request on behalf of the resource provider, completing the process.
  • FIG. 28 illustrates this process. Assume that before the resource provider switches the resource from CoAP to CoAP Pub/Sub, both the broker and the resource provider have discovered the RD and registered their respective resources in the RD, as described in the CoRE Resource Directory specification. As shown in FIG. 28, after the registration, the RD has created two resource entries (i.e., "/rd/1001" and "/rd/1002") for the broker and the resource provider, where
  • “/rd/1001” is for the broker and "/rd/1002" is for the resource provider.
  • This resource and path information indicates that rscl is the hosting resource of the resource provider.
  • the broker and the RD may be two logical entities co-located within the same physical entity. In such a case, the communications between the broker and the RD may be internal communications.
  • the broker may send the content of rscl in response to resource retrieval requests from resource consumers that are interested in rscl .
  • the RD may respond with the URI of rscl in the broker, "./ps/rscl", rather than the URI of rscl in the resource provider, "./pub/rscl", to new resource consumers attempting to discover rscl via the RD.
  • the resource entries in the RD may be updated to reflect the change in communication modes. As shown in FIG. 28, updating resource entries of an RD may be performed as follows.
  • the broker may send a resource entry updating message to the RD by creating a new CoRE link related to the resource in the broker.
  • the resource entry updating message may apply the PATCH operation and contain the broker's resource entry location of resource rscl (i.e., /rd/1001) as well as the payload.
  • the payload may contain the CoRE links attributes of rscl in the broker.
  • the RD may update the resource entry of the broker with the new CoRE link attributes received in the message.
  • the code block after Step 1 such an update is illustrated by the code block after Step 1, where both resources in the RD now have identical attributes, excluding the URL
  • the RD may send a 2.04 (Changed) response to the broker.
  • the resource provider may send a resource entry updating message to the RD.
  • the resource entry updating message may apply the PATCH operation and contain the resource provider's resource entry location (i.e., "/rd/1002") as well as the URI path of rscl in the resource provider.
  • the RD may update the resource entry of the resource provider by deleting the existing CoRE link, which was associated with the resource in the resource provider, resource rscl in FIG. 28. After successfully updating the resource entry, the RD may send a 2.04 (Changed) response to the resource provider.
  • the changes made to the CoRE link are illustrated in the code block under Step 3. After this step, the resource entry of the resource provider, " ⁇ rd ⁇ 1002", no longer has any associated CoRE links or resources.
  • step 5 new resource consumers attempting to discover the resource may send their query requests to the RD.
  • the RD may respond with the new full URI of the resource to the new resource consumers.
  • this new full URI is "coap://local -broker.com/ps/rscl”.
  • the new resource consumers may retrieve (i.e., read or observe) the content of the resource from the broker.
  • the switching from CoAP to CoAP Pub/Sub is complete.
  • a procedure for switching from CoAP Pub/Sub to CoAP is introduced.
  • a resource switched from CoAP Pub/Sub to CoAP may be deleted from a broker, and the resource consumers that are interested in the resource should access (i.e., read or observe) the resource from the original resource provider; the resource consumers should access the resource via the resource provider rather than the broker.
  • This aspect may also involve at least three main tasks: (1) resource deletion from the broker; (2) resource URI change notification to the existing resource consumers; and (3) resource entry updating in the RD.
  • the resource provider has already discovered the broker as well as the RD in the network, and the resource provider and the broker have already registered their hosting resources in the RD.
  • a resource switched from CoAP Pub/Sub to CoAP may involve a resource being deleted from a broker and the resource consumers that are interested in the resource being notified to access the resource from the original resource provider rather than from the broker.
  • the resource provider should respond to resource retrieval requests from the resource consumers while the broker should not send content of the resource in response to resource retrieval requests.
  • the broker and the resource provider may both initialize the switching from CoAP Pub/Sub to CoAP depending on the trigger event.
  • the switching process may comprise three major tasks: (1) resource deletion from the broker; (2) URI change notification to the existing resource consumers; and (3) resource entry updating in the RD.
  • the resource provider may initiate the switching from CoAP Pub/Sub to CoAP when a trigger event occurs, such as the resource provider no longer trusting the broker, the resource provider disabling a sleep mode, or any other such trigger event.
  • the resource provider may initiate the deleting of the resource from the broker by applying the following steps, as shown in FIG. 30.
  • the resource provider may send a switching request (i.e., a resource deletion request) to the broker.
  • the resource deletion request may contain the URI of the resource in the broker to indicate which resource the resource provider requests to delete.
  • the URI of the resource in the broker may be contained in a 'bURI' attribute in the request message.
  • the resource deletion request may not need to contain the 'cm' attribute to indicate the communications mode because deleting the resource from the broker results in the resource provider applying CoAP to deliver the content of the resource.
  • the broker may no longer send the content of the resource to any resource consumer.
  • the broker may delete the cached content related to the resource and send a 2.02 (Deleted) response to the resource provider to indicate that the resource has been deleted.
  • the broker may need to continue to store the value of 'pURI' for a certain period of time in order to notify the existing resource consumers, which have previously issued an observation to the resource or previously read the resource in the broker, about the new full URI of the resource at the resource provider (i.e., the value of 'pURI').
  • the resource provider may empty the 'bURI' attribute because the broker URI is no longer valid.
  • the broker may also initiate the switching when a trigger event occurs, such as the resource no longer being suitably cached in the broker, the broker being congested, or the broker being temporarily unavailable due to maintenance. If the resource is cached in the broker, the broker may take charge of measuring the load of the resource. If the load of the resource becomes too light, it may be more optimal for the resource provider to respond to resource retrieval requests on its own. The broker may initiate the deletion of the resource by applying the following steps, illustrated in FIG. 31.
  • the broker may transmit a switching request (i.e., a resource deletion notification) to the resource provider.
  • the resource deletion notification may use a CoAP PUT operation and include the URI of the resource in the resource provider (i.e., the value of 'pURI') as well as the 'sp' attribute, which may indicate the switching purpose.
  • the resource deletion request may optionally contain the 'cm' attribute to indicate the communications mode.
  • the resource provider may send the switching request directly to the broker if the resource provider attempts to apply CoAP Pub/Sub again.
  • the resource provider may modify the attributes of the resource according to the notification. After modifying the attributes of the resource, the resource provider may send a 2.04 (Changed) response to the broker and prepare to respond to resource retrieval requests from the resource consumers.
  • a 2.04 Changed
  • the broker may delete the cached content of the resource.
  • the broker may store the value of 'pURI' for a certain period of time in order to notify existing resource consumers, which have issued an observation to the resource the resource or previously read the resource in the broker, about the new full URI of the resource if they attempt to access the resource from the broker.
  • the broker may not send the content of the resource to any resource consumer.
  • the broker may take the responsibility of notifying the existing resource consumers, which have issued an observation to the resource or previously read the resource in the broker, about the new full URI of the resource at the resource provider.
  • the existing resource consumers may be separated into two groups, the existing observe resource consumers and the existing read resource consumers.
  • the resource provider may notify the two groups of resource consumers about the new full URI of the resource in differing ways.
  • the resource provider may continue delivering the content of the resource to the existing observe resource consumers when the switching from CoAP Pub/Sub to CoAP is conducted.
  • Two such ways may include (a) the broker notifying the existing observe resource consumers about the new full URI of the resource, and (b) the broker offloading the observe list of the resource to the resource provider.
  • the broker may notify the existing observe resource consumers about the new full URI of the resource.
  • the steps of such a notification scheme may enable the broker to send a notification message to each of the existing observe resource consumers to inform them that they may send a new request to the resource provider in order to continue observing the resource.
  • FIG. 32 illustrates the steps of this notification scheme, which are as follows.
  • the broker may send a URI change notification message to each of the existing observe resource consumers.
  • the URI change notification message may contain the same Token ID as the previous resource notification message sent by the broker before the switching.
  • the URI change notification message may also contain a payload with the 'nURF attribute.
  • the 'nURF attribute may be used to indicate the new full URI of the resource after the switching, i.e., the full URI of the resource in the resource provider.
  • the URI change message may be sent as a CON so that the receiving resource consumer may confirm successful reception of the message.
  • step 2 after the existing observe resource consumer successfully receives the URI change notification message, it may update the full URI attribute of the resource with the value in the 'nURF attribute. After successfully updating the resource's full URI, the resource consumer may send a 2.04 (Changed) response to the broker to inform the broker of the successful modification.
  • a 2.04 Changed
  • step 3 after the existing observe resource consumer updates the resource's full URI, it may send a resource observation request to the resource provider to initiate the resource observation process from the resource provider.
  • the resource provider may send a notification to the resource consumer whenever the state of the resource is changed.
  • the broker may also offload the observe list of the resource to the resource provider.
  • This method may enable the broker to transfer the information of the existing observe resource consumers to the resource provider, and the resource provider may continue to send the content of the resource to the existing observe resource consumers without notifying these resource consumers that the URI of the resource has been changed after the switching.
  • This method is illustrated in FIG. 33 and may include the following steps.
  • the broker may send an observe list creation message to the resource provider.
  • the observe list creation message may contain the URI of the resource in the resource provider (i.e., "/pub/rscl" in the example) as well as the existing observe resource consumers'
  • the existing observe resource consumer information may be contained in the Observer list', 'token id list', and 'seq num list' attributes.
  • the Observer list' attribute may contain the ID of each existing observe resource consumer
  • the 'token id list' attribute may contain the token IDs that were previously applied by the existing observe resource consumers to observe the resource in the resource provider
  • the "seq num list" attribute may contain the sequence number for each token currently in use.
  • the resourced provider may check whether a duplicate Token ID existed among the observe lists hosted by the resource provider. If a duplicate Token ID is not found, then go to Step 3(a); if a duplicate Token ID is found, then go to Step 3(b).
  • the resource provider may create an observe list for the resource and send a 2.05 (Created) response to the broker to indicate that the resource provider is prepared to send content of the resource to the existing observe resource consumers.
  • a duplicate Token ID was found.
  • ⁇ Observe ID: 192.168.1.45, Token ID: 0x4a ⁇ is determined by the resource provider to be a duplicate Token ID.
  • the resource provider should delete the information related to the duplicate Token ID (i.e., ⁇ Observe ID: 192.168.1.45, Token ID: 0x4a, Sequence Num: 11 ⁇ ) from the observe list and may send a message to the broker indicating the Observe ID using the duplicate Token ID, "192.168.1.45" in FIG. 33.
  • the broker may determine that the resource consumer using the duplicate Token ID, "192.168.1.45" in FIG. 33, failed to be created in rscl 's observe list at the resource provider. Consequently, the broker may send a notification message about the new full URI of rscl to the resource consumer having Observe ID "192.168.1.45" by applying the procedure of Steps 1-3 of FIG. 32 in order to enable the resource consumer to re-observe rscl from the resource provider.
  • the process of step 4 may be optional; specifically, step 4 may not be necessary when a duplicate Token ID is not found in Step 2.
  • the resource provider may issue resource notifications and send the up-to-date content of the resource to the existing observe resource consumers in the observe list whenever the state of the resource is changed.
  • existing read resource consumers are those resource consumers that previously discovered and read the resource in the broker before the switching and continue to make subsequent reads after the switching.
  • the broker may notify the existing read resource consumers about the new full URI by applying the following steps.
  • the broker may send a URI change response to an existing read resource consumer after receiving a resource read request from that resource consumer.
  • the URI change response may contain the new CoAP response, 5.06 Communications Mode Switched, with the content indicating the new full URI of the resource at the resource provider.
  • the read resource consumer may update the full URI of the resource with the content in the response message and send the resource read request to the updated URI.
  • the resource provider may respond to the resource read request with the content of the resource.
  • resource entries may need to be updated in the RD when switching from CoAP Pub/Sub to CoAP. Assume that before the resource provider or broker switches the resource from CoAP Pub/Sub to CoAP, both the broker and the resource provider have discovered the RD and registered their resources in the RD. As shown in FIG. 35, the RD has created two resource entries after registration, "/rd/1001" and "/rd/1002", where "/rd/1001" is associated with the broker and "/rd/1002" is associated with the resource provider. Because CoAP Pub/Sub is being used before the switching, there is one resource (i.e.,
  • the resource entries of the resource provider and the broker should be updated such that the RD may respond with the URI of the resource in the resource provider (i.e., "./pub/rscl" in FIG. 35) rather than the URI of the resource in the broker (i.e., "./ps/rscl") to new resource consumers that attempt to discover the resource via the RD.
  • the resource entries in the RD may be updated to reflect the change in communication mode. Updating resource entries of an RD is illustrated in FIG. 35 and may comprise the following steps.
  • the resource provider may send a resource entry updating message to the RD by adding a new CoRE link associated with rscl in the resource provider.
  • the resource entry updating message may use the PATCH operation and contain the resource provider's resource entry location (i.e., "/rd/1002") as well as the payload.
  • the payload may contain the CoRE links attributes of rscl in the resource provider.
  • the RD may update the resource entry of the resource provider with the new CoRE link attributes received in the message. After successfully updating the resource entry, the RD may send a 2.04 (Changed) response to the resource provider.
  • the broker may update its resource entry at the RD by deleting the existing CoRE link related to the resource entry.
  • the resource entry updating message may apply the PATCH operation and contain the broker's resource entry location (i.e., "/rd/1001") as well as the URI path of rscl in the broker.
  • the RD may update the resource entry of the broker by deleting the existing CoRE link attributes, which were associated with the resource in the broker. After successfully updating the resource entry, the RD may send a 2.04 (Changed) response to the broker.
  • the changes made to the CoRE link attributes are illustrated in the code block under Step 3. After this step, the resource entry of the resource provider, " ⁇ rd ⁇ 1001", no longer has any associated CoRE link attributes.
  • new resource consumers that attempt to discover the resource may send their query requests to the RD.
  • the RD may respond to the new resource consumers with the new URI of the resource, "coap://local-areal .com/pub/rscl" in FIG. 35.
  • the new resource consumers retrieve (read or observe) the content of the resource directly from the resource provider.
  • Resource providers and brokers may measure resource load management, which may be defined in any suitable manner.
  • the load of a resource may be defined as the number of successful packets transmitting the content of the resource to a resource consumer.
  • a resource provider may contain a resource (i.e., rscl) that has two resource consumers, i.e., Resource consumer- 1 and Resource consumer-2.
  • Each resource may have a counter to indicate the load of the resource, i.e., Resource Load Counter (RLC).
  • RLC Resource Load Counter
  • a time interval may represent a complete resource load monitoring period. At the beginning of the time interval, RLC may be initialized to be zero.
  • the resource provider After the resource provider transmits a packet having a different message ID than a previous packet to deliver the content of the resource to the resource consumers, the value of the corresponding RLC may increase by one.
  • the resource provider receives two resource read requests from Resource consumer-2 and accordingly responds with the content.
  • Resource consumer- 2 does not receive the 2nd response because of delivery failure, which may be due to a temporary network disconnection, network congestion, or other malfunction; after ACK TIMEOUT seconds, Resource consumer-2 may send the resource read request again, which may contain the same message ID as the previous request.
  • load may also be based on the number of observers to a resource, which may be determined by the number of entries on an Observe list, the number of the resource retrieval requests, and/or any other feasible manner of indicating load.
  • CoRE Link attributes may be utilized to provide information about hosted resources. As described above, several new attributes may be used to support a resource switching back-and-forth between CoAP and CoAP Pub/Sub. Additionally, a new CoAP response code may be used in conjunction with these new attributes to support the dynamic switching.
  • the new 'cm' attribute may be used to indicate the communications mode of a resource after a switching occurs.
  • the value of the 'cm' attribute may be 'CoAP' or 'CoAP Pub/Sub', the value of which indicates the communications mode the resource will use after the switching occurs.
  • the request message may contain the 'cm' attribute.
  • the new 'sp' attribute may be used to identify the purpose for performing a switching of communications mode.
  • the possible values of the 'sp' attribute are listed with accompanying descriptions in Table 2.
  • the new 'tli' attribute may be used to indicate the load of a resource when the resource switches from CoAP to CoAP Pub/Sub.
  • the broker may utilize the value of 'tli' to determine if the broker has sufficient capacity to cache the resource.
  • the resource provider may send the switching request to the broker.
  • the new 'pURI' attribute may be used to provide the full URI of a resource in the resource provider to the broker so that the broker may later initialize the switching from CoAP Pub/Sub to CoAP.
  • the broker may also use the value of the 'pURI' attribute to notify a resource consumer about the new full URI of the resource in the resource provider when the resource is switched from CoAP Pub/Sub to CoAP.
  • Some or all of the existing observe resource consumers that have issued an observation to the resource may be notified that the URI of the resource has changed after the resource has been switched between CoAP and CoAP Pub/Sub.
  • the new 'nURF attribute may be used to provide the new full URI of the resource to those resource consumers. For example, if the resource is switched from CoAP to CoAP Pub/Sub, the resource provider may inform the existing observe resource consumers about the full URI of the resource in the broker by sending URI change notification messages to the existing observe resource consumers.
  • Each URI change notification message may contain the 'nURF attribute to indicate the new URI of the resource.
  • information about the existing observe resource consumers should be transmitted between the resource provider and the broker. This information may be specified by the new Observe list', 'token id list', and 'seq num list' attributes, where Observe list' indicates the IP address of each observe resource consumers, 'token id list' indicates the Token ID applied by each observe resource consumer to observe the resource, and 'seq num list' indicates the observe sequence number that was used to send the last packet to each of the corresponding observe resource consumers.
  • Table 3 illustrates one example of how the 'observe list', 'token id list', and 'seq num list' attributes may represent the information of two observe resource consumers.
  • a new CoAP response code 5.06 (Communications Mode Switched) may be applied when the existing read resource consumers send resource retrieval requests to the resource provider/broker that no longer sends the content of the resource to the resource consumers due to the communications mode being switched. Consequently, the resource provider/broker may respond to resource retrieval requests from the read resource consumers with the new 5.06 code as well as the content of the new full URI of the resource
  • a TD is used to describe metadata about a thing under the W3C WoT framework.
  • Some of the newly introduced CoRE link attributes may be added to a TD to describe richer metadata about whether and how a thing supports dynamic protocol switching between CoAP and CoAP Pub/Sub or between other messaging protocols.
  • the following new metadata is introduced for WoT TD.
  • protocolSet This attribute may stand for the set of protocols that may be used to access the resource described in this property.
  • brokerURI This attribute may stand for the URI of the broker used in the CoAP Pub/Sub protocol.
  • initialProtocol This attribute may stand for the initial protocol to use to access the resource described in this property when the present TD is generated.
  • switchPeriod This attribute may stand for the time interval in ms to switch between protocols, as described in protocolSet
  • WoT servicing A host a number of resources locally.
  • a WoT Client B may access those resources.
  • WoT servicing A hosts resources and acts as a resource provider, while WoT Client B is a resource consumer.
  • a TD may be generated to describe what the WoT Servient A's resources are and how they should be accessed. Specifically, this TD may include the new TD properties and metadata, as described above. The generated TD may be maintained locally in the WoT Servient A, or it may alternatively be stored in a remote Repository.
  • WoT Client B may discover and retrieve this TD locally or from the remote Repository. From the discovered TD, WoT Client B may determine which protocol (e.g. CoAP or CoAP Pub/Sub) should be used to access a specific resource hosted by WoT Servient A at a specific time. In the TD example illustrated in FIG. 37, the value of "protocol Set" indicates to WoT Client B that it may use either CoAP or CoAP Pub/Sub to access WoT Servient A. Note that more and other protocols may be added to protocolSet.
  • protocol e.g. CoAP or CoAP Pub/Sub
  • WoT Client B may use the correct protocol to access the resources at WoT Servient A. According to the new properties and metadata contained in the TD, WoT Client B may switch to use another protocol to access the resources at WoT Servient A as time goes forward.
  • the "tdGenTime” metadata indicates that this TD was generated at 2016-7-30-10-10-10 (Year-Month-Day-Hour-Minute-Second).
  • the "switchPeriod" property indicates that the protocol to access WoT Servient A should be switched every 10000 seconds among the protocols denoted by "protocolSet".
  • the first protocol to be used is CoAP Pub/Sub, as denoted by "initialProtocol".
  • WoT Client B If WoT Client B discovers this TD at time 1000 seconds, it will use CoAP Pub/Sub (i.e. the initialProtocol); if WoT Client B discovers this TD between 10000 and 20000, it will switch to use the next protocol listed in protocolSet (i.e.
  • WoT Servient A may change the method of protocol switching. If it does so, it may generate a new TD or update the above new properties and metadata that are used for protocol switching in the current TD. When a new TD is generated or the current TD is updated, the TD should be discovered by WoT Client B (and/or other WoT Clients) again so that WoT Client B may use the appropriate protocol to access the resources at WoT Client A.
  • FIG. 37 shows an example of how these newly-introduced properties and metadata may be represented.
  • the properties and metadata may be represented as subject-predicate-object triples based on the W3C Resource Representation Framework (RDF).
  • RDF Resource Representation Framework
  • Embodiments contemplated herein include the following: 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:
  • a resource provider apparatus on the network, a first message indicating a request to create a resource and including attributes set to indicate a switch in communication protocol from a first protocol to a second protocol, wherein the second protocol is a publish-subscribe protocol and wherein the resource is accessible via the second protocol;
  • 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:
  • 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:
  • switch in communication protocol is from CoAP protocol to CoAP Pub/Sub protocol.
  • switch in communication protocol is from CoAP Pub/Sub protocol to CoAP protocol.
  • 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:
  • the switch comprising: sending, via the communication network to the resource provider apparatus on the network, a first message indicating a request to delete the first resource and including attributes set to indicate a switch in communication protocol from the first protocol to the second protocol; receiving, via the communication network from the resource provider apparatus on the network, a first response message acknowledging the switch in communication protocol; and deleting the content of the first resource.
  • 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:
  • a broker apparatus on the network receives, via the communication network from a broker apparatus on the network, a first message including attributes set to indicate a switch in communication protocol of a resource from a first protocol to a second protocol, wherein the first protocol is a publish-subscribe protocol;
  • an embodiment includes a user control panel.
  • 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.
  • GUI graphical user interface
  • FIG. 38 For accessing the properties of various resources on a resource provider and broker.
  • input boxes or dropdown boxes may be used to enter or change the parameters of the resources.
  • the interface may contain each resource in the resource provider/broker as well as each resource's status, which may include the communications mode, switching purpose, load, and policy for each resource.
  • the resource provider/broker can monitor the status of its hosting resource.
  • FIG. 39A 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.
  • M2M technologies provide building blocks for the IoT/WoT, and any M2M device, M2M gateway, M2M server, or M2M service platform or other network apparatus 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-17 or 19-36 may comprise a node (i.e., network apparatus) of a communication system such as the one illustrated in FIGs. 39A-D.
  • 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.
  • 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.
  • the communication network 12 may employ one or more channel access methods, such as code division multiple access
  • 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.
  • 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
  • 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 apparatuses (e.g., servers, gateways, devices, and the like) of the network.
  • 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
  • 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.
  • 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.
  • WPAN e.g., Zigbee, 6L0WPAN, Bluetooth
  • 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.
  • 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 comprises servers, computers, devices, or like apparatuses.
  • 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.
  • M2M service layer 22' 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 comprises servers, computers, devices, virtual machines (e.g., cloud computing/storage farms, etc.) or like apparatuses.
  • nodes of the network which may comprises servers, computers, devices, virtual machines (e.g., cloud computing/storage farms, etc.) or like apparatuses.
  • the M2M service layers 22 and 22' provide a core set of service delivery capabilities that diverse applications and verticals can 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 12 and 12' in connection with the services that the service layers 22 and 22' provide.
  • 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.
  • the M2M service layer running across the devices, gateways, servers and other apparatuses 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'.
  • a service layer such as the service layers 22 and 22' illustrated in FIGs. 39A and 39B, 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.
  • M2M 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
  • 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 Common Services Entity (CSE) or Service Capability Layer (SCL).
  • CSE Common Services Entity
  • SCL Service Capability Layer
  • 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
  • the CSE or SCL is a functional entity that may be implemented by hardware and/or software and that provides (service) capabilities or
  • the Third Generation Partnership Project (3GPP) has also defined an architecture for machine-type communications (MTC).
  • MTC machine-type communications
  • SCS Service Capability Server
  • 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 apparatuses in the network, including servers, computers, and other computing devices or apparatuses, or as part of one or more existing apparatuses.
  • a service layer or component thereof may be implemented in the form of software running on a network apparatus (e.g., server, computer, gateway, device or the like) having the general architecture illustrated in FIG. 39C or FIG. 39D described below.
  • SO A Service Oriented Architecture
  • ROA Resource- Oriented Architecture
  • FIG. 39C is a block diagram of an example hardware/software architecture of an apparatus of a network, such as one of the clients or servers illustrated in FIGs. 2-17 or 19-36 which may operate as an M2M server, gateway, device, or other apparatus in an M2M network such as that illustrated in FIGs. 39A and 39B.
  • the apparatus 30 may include a processor 32, non-removable memory 44, removable memory 46, a
  • the apparatus 30 may also include communication circuitry, such as a transceiver 34 and a transmit/receive element 36. It will be appreciated that the apparatus 30 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.
  • This apparatus may be a node that implements the Pub/Sub functionality described herein.
  • the processor 32 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of
  • the processor 32 may execute computer-executable instructions stored in the memory (e.g., memory 44 and/or memory 46) of the apparatus in order to perform the various required functions of the apparatus.
  • the processor 32 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the apparatus 30 to operate in a wireless or wired environment.
  • the computer-executable instructions stored in the memory of the apparatus, and executed by the processor, may further cause the apparatus to perform the operations illustrated in FIGs. 10-26 described above.
  • 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.
  • the processor 32 is coupled to its communication circuitry (e.g., transceiver 34 and transmit/receive element 36).
  • the processor 32 may control the communication circuitry in order to cause the apparatus 30 to communicate with other apparatuses via the network to which it is connected.
  • the processor 32 may control the communication circuitry in order to perform the transmitting and receiving steps described and illustrated herein (e.g., in FIGs. 2-17 or 19-36) and in the claims. While FIG. 39C 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.
  • the transmit/receive element 36 may be configured to transmit signals to, or receive signals from, other apparatuses, including M2M servers, gateways, device, and the like.
  • 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.
  • the transmit/receive element 36 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example.
  • 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.
  • the apparatus 30 may include any number of transmit/receive elements 36. More specifically, the apparatus 30 may employ MIMO technology. Thus, in an embodiment, the apparatus 30 may include two or more transmit/receive elements 36 (e.g., multiple antennas) for transmitting and receiving wireless signals.
  • 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.
  • the apparatus 30 may have multi-mode capabilities.
  • the transceiver 34 may include multiple transceivers for enabling the apparatus 30 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.
  • 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.
  • 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.
  • SIM subscriber identity module
  • SD secure digital
  • the processor 32 may access information from, and store data in, memory that is not physically located on the apparatus 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 communications.
  • the display/indicators 42 may present the graphical user interface illustrated in FIG. 38 and described herein.
  • 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 apparatus 30.
  • the power source 48 may be any suitable device for powering the apparatus 30.
  • 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.
  • 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 apparatus 30. It will be appreciated that the apparatus 30 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.
  • 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.
  • the peripherals 52 may include various sensors such as an accelerometer, biometrics (e.g., fingerprint) sensors, an e-compass, a satellite transceiver, 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.
  • biometrics e.g., fingerprint
  • a satellite transceiver for photographs or video
  • USB universal serial bus
  • the apparatus 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 apparatus 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.
  • FIG. 39D is a block diagram of an exemplary computing system 90 which may also be used to implement one or more apparatuses of a network, such as the clients or servers illustrated in FIGs. 2-17 and 19-36 and described herein, which may operate as an M2M server, gateway, device, or other apparatus in an M2M network such as that illustrated in FIGs. 39A and 39B.
  • 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, such as, for example, performing the operations illustrated and described in FIGs. 10-26 and the accompanying description.
  • CPU central processing unit
  • central processing unit 91 is implemented by a single-chip CPU called a microprocessor.
  • 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 fetches, decodes, and executes instructions, and transfers information to and from other resources via the computer's main data-transfer path, system bus 80.
  • 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.
  • RAM random access memory
  • ROM read only memory
  • 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 can 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 can 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.
  • 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.
  • peripherals controller 83 responsible for communicating instructions from CPU 91 to peripherals, such as printer 94, keyboard 84, mouse 95, and disk drive 85.
  • 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. 38 and its accompanying description.
  • 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. 39A and FIG. 39B, to enable the computing system 90 to communicate with other apparatuses of the network.
  • a network adaptor 97 may be used to connect computing system 90 to an external communications network, such as network 12 of FIG. 39A and FIG. 39B, to enable the computing system 90 to communicate with other apparatuses of the network.
  • 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.
  • 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.
  • any of the steps, operations or functions described above may be
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention concerne des systèmes et des procédés permettant la commutation entre un protocole de messagerie classique et un protocole de messagerie de type publish-subscribe (publier-s'abonner). Deux exemples de tels protocoles de messagerie comprennent les classiques CoAP et CoAP Pub/Sub. Par exemple, des améliorations peuvent être apportées aux attributs/formats de CoRE Link existants, au protocole CoAP existant, et au cadriciel IdO W3C pour réduire au minimum les déchets associés à l'échange de données excessif et à la consommation d'énergie excessive et pour prendre en compte des considérations de performance supplémentaires en permettant une commutation dynamique entre CoAP et CoAP Pub/Sub. Dans un aspect, une nouvelle procédure de commutation de CoAP vers CoAP Pub/Sub est décrite. Selon un autre aspect, l'invention concerne une nouvelle procédure de commutation de CoAP Pub/Sub vers CoAP. Plusieurs nouveaux attributs de CoRE Link sont introduits pour permettre la commutation dynamique entre CoAP et CoAP Pub/Sub et vice versa. Un nouveau code de réponse CoAP est également introduit pour notifier aux consommateurs de ressources que le mode de communication utilisé pour accéder à la ressource a changé. De plus, de nouveaux attributs de métadonnées TD IdO sont introduits pour permettre une commutation de protocole dynamique dans le cadriciel IdO W3C.
PCT/US2018/013299 2017-01-11 2018-01-11 Commutation de protocole dynamique WO2018132557A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201762445098P 2017-01-11 2017-01-11
US62/445,098 2017-01-11

Publications (1)

Publication Number Publication Date
WO2018132557A1 true WO2018132557A1 (fr) 2018-07-19

Family

ID=61148486

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2018/013299 WO2018132557A1 (fr) 2017-01-11 2018-01-11 Commutation de protocole dynamique

Country Status (1)

Country Link
WO (1) WO2018132557A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114244914A (zh) * 2021-11-30 2022-03-25 深圳市晨北科技有限公司 物联网协议切换方法装置、电子设备及存储介质
CN114666177A (zh) * 2022-02-22 2022-06-24 中国建设银行股份有限公司 智能家居预警方法、系统、计算机设备、存储介质
EP4145792A4 (fr) * 2020-06-16 2023-06-07 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Procédé et appareil de publication de ressources, passerelle, plateforme en nuage et support de stockage informatique

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016111914A1 (fr) * 2015-01-05 2016-07-14 Convida Wireless, Llc Indication et négociation de protocole machine-machine

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016111914A1 (fr) * 2015-01-05 2016-07-14 Convida Wireless, Llc Indication et négociation de protocole machine-machine

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
KOSTER ARM LIMITED A KERANEN J JIMENEZ ERICSSON M: "Message Queueing in the Constrained Application Protocol (CoAP); draft-koster-core-coapmq-00.txt", MESSAGE QUEUEING IN THE CONSTRAINED APPLICATION PROTOCOL (COAP); DRAFT-KOSTER-CORE-COAPMQ-00.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, 5 July 2014 (2014-07-05), pages 1 - 16, XP015100517 *
KOSTER ARM LIMITED A KERANEN J JIMENEZ ERICSSON M: "Publish-Subscribe Broker for the Constrained Application Protocol (CoAP); draft-koster-core-coap-pubsub-04.txt", PUBLISH-SUBSCRIBE BROKER FOR THE CONSTRAINED APPLICATION PROTOCOL (COAP); DRAFT-KOSTER-CORE-COAP-PUBSUB-04.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, 5 November 2015 (2015-11-05), pages 1 - 21, XP015109697 *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4145792A4 (fr) * 2020-06-16 2023-06-07 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Procédé et appareil de publication de ressources, passerelle, plateforme en nuage et support de stockage informatique
US11750716B2 (en) 2020-06-16 2023-09-05 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Methods for publishing resource, and gateway
CN114244914A (zh) * 2021-11-30 2022-03-25 深圳市晨北科技有限公司 物联网协议切换方法装置、电子设备及存储介质
CN114244914B (zh) * 2021-11-30 2024-05-17 深圳市晨北科技有限公司 物联网协议切换方法装置、电子设备及存储介质
CN114666177A (zh) * 2022-02-22 2022-06-24 中国建设银行股份有限公司 智能家居预警方法、系统、计算机设备、存储介质
CN114666177B (zh) * 2022-02-22 2024-05-28 中国建设银行股份有限公司 智能家居预警方法、系统、计算机设备、存储介质

Similar Documents

Publication Publication Date Title
KR101973298B1 (ko) M2m-iot 서비스의 발행 및 발견
EP3243317B1 (fr) Indication et négociation de protocole machine-machine
KR102046700B1 (ko) 메시지 버스 서비스 디렉토리
EP3745675B1 (fr) Propagation de ressources de couches de service entre domaines
EP3117587B1 (fr) Répertoire de ressources réparti amélioré
US10708885B2 (en) Methods and nodes for enabling context-awareness in CoAP
US20160088049A1 (en) Internet of things (iot) adaptation services
US11032132B2 (en) Resource link binding management
US11831736B2 (en) System and methods for service layer cache management
EP3011724A1 (fr) Gestion de contexte
US12278874B2 (en) Cross-domain discovery between service layer systems and web of things systems
WO2018112327A1 (fr) Procédés de commande de simultanéité pour transfert de bloc dans une architecture de publication-abonnement coap
US20220141309A1 (en) Efficient resource representation exchange between service layers
WO2018132557A1 (fr) Commutation de protocole dynamique
US20220050726A1 (en) Advanced resource link binding management
WO2017044772A1 (fr) Procédés pour l'activation de messagerie coap sensible au contexte
WO2019067892A1 (fr) Enregistrement de service sur la base de préférences et d'exigences de capacités de service
WO2017008004A1 (fr) Couche de service anycast et somecast
WO2017040948A1 (fr) Activation de la flexibilité temporelle pour le transfert de blocs dans le protocole coap
WO2020149963A1 (fr) Gestion automatisée de flux de messages de couche de service dans un réseau de communication

Legal Events

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

Ref document number: 18702840

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18702840

Country of ref document: EP

Kind code of ref document: A1

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载