WO2025198500A1

WO2025198500A1 - Publish-subscribe systems

Info

Publication number: WO2025198500A1
Application number: PCT/SE2024/050257
Authority: WO
Inventors: Oscar Novo Diaz; Lorenzo CORNEO; Hans-Christer Holmberg
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2024-03-21
Filing date: 2024-03-21
Publication date: 2025-09-25
Anticipated expiration: 2026-09-21

Abstract

Aspects of the disclosure provide methods performed by a publisher node, a broker node and a subscriber node in a publish-subscribe system The method in the publisher node comprises sending (601) a first message for a first topic to a broker node, the first message comprising a distribution value for the first message. The method in the broker node comprises: receiving (701) a first message for the first topic from a publisher node, the first message comprising a distribution value for the first message; determining (702) which of the subscriber nodes the first message is to be sent to based on the distribution value for the first message and respective distribution values of the subscriber nodes; and sending (703) the first message to the determined subscriber nodes. The method in the subscriber node comprises sending (801) a subscription message for a first topic to a broker node, the subscription message comprising a suggested distribution value for the subscriber node.

Description

Publish-subscribe systems

Technical Field

This disclosure relates to publish-subscribe systems, and in particular to improvements in distribution of messages to subscribers.

A publish-subscribe model serves as a foundation for asynchronous communication between various components or systems. In this model, information dissemination occurs without direct interactions between the source of the information (referred to herein as the “publisher” or “publisher node”) and the recipient(s) of the information (referred to herein as the “subscriber(s)” or “subscriber nodes”). In addition to the publishers and subscribers, the publish-subscribe model involves a message broker (referred to herein as a “broker” or “broker node”) that facilitates the exchange of messages.

The publish-subscribe model usually operates at the application layer of the Open Systems Interconnection (OSI) model. An important concept in publish-subscribe is the “topic”, which serves as a virtual channel to which clients can publish or subscribe, and topics are the main organisational unit for messages. Subscribers can express interest (‘subscribe’) in specific topics, allowing them to receive relevant messages. Topics are strings that serve as labels or addresses for messages.

A high-level view of a publish-subscribe system 100 is shown in Fig. 1. The system 100 includes a broker node 102 that orchestrates message exchange and a number of clients 104. For a particular topic to which messages are published, clients 104 can be either a publisher node or a subscriber node. In Fig. 1 client 104a is a subscriber node, and client 104c is a publisher node. The other clients 104b, 104d, 104e in Fig. 1 are publisher nodes for certain topics, and subscriber nodes for one or more other topics.

Topics may be structured hierarchically, resembling a file path or directory structure, with levels separated by forward slashes ("/"). For instance, the exemplary topic “home/living- room/lights” has three hierarchical levels: “home”, “living-room” and “lights”.

In home automation, they can represent devices and their states (e.g. “smart-light/living- room/status”). In Internet of Things (loT) deployments, topics can convey sensor data from various devices (e.g. “sensor/temperature/room-1”). In messaging systems, topics can categorise messages by subject matter (e.g. “news/sports” or “alerts/security”).

Security considerations in publish-subscribe implementations are paramount to safeguarding sensitive information and ensuring data confidentiality, integrity, and authenticity. For example, in publish-subscribe systems, various security features can be applied:

• Authentication: Secure publish-subscribe systems typically employ authentication mechanisms such as username-password pairs or client certificates to verify the identity of clients.

• Authorisation: Authorisation mechanisms control access to specific topics or restrict certain operations ensuring that only authorised clients can perform specific actions within the publish-subscribe system. The broker node may contain access control lists, roles and groups that specify which topics a given subscriber is authorised to subscribe to.

• Encryption: Some publish-subscribe systems support encryption of the published data. Encryption may be realised e.g. using Transport Layer Security (TLS), or using some application layer encryption mechanism. Encryption provides confidentiality of the published data. These security considerations are vital components of publish-subscribe models and are instrumental in preserving the integrity and security of data exchanges in such systems.

Standardisation efforts have resulted in detailed specifications for various publish-subscribe models. There are several publish-subscribe models available, and parts of this disclosure relate to Message Queuing Telemetry Transport (MQTT), one of the most popular and widely used models, and the integration of publish-subscribe into Constrained Application Protocol (CoAP). Both MQTT and CoAP are fundamental protocols for loT.

MQTT is defined in “MQTT Version 3.1.1” and “MQTT Version 5.0”, and the document “A publish-subscribe architecture for the Constrained Application Protocol (CoAP)” adapts the CoAP protocol to use a publish-subscribe architecture.

Summary

When dealing with sensitive data, confidentiality is an important concern for existing publish- subscribe systems. Currently, publish-subscribe architectures enforce confidentiality by using private topics and/or roles. Roles give subscribers access to different topics. However, these approaches come with their own sets of challenges and considerations.

Private topics can be used to create a distinction between public and classified/confidential information by using private topics. This entails creating related topics with different names to share data of varying confidentiality levels. For instance, in a smart home system sensor data from different rooms needs to be transmitted via a publish-subscribe channel. To maintain confidentiality, users might create two types of topics: public and private. Public topics, like “home/living-room/temperature” may be meant for data that can be openly accessed by anyone interested. In contrast, private topics, such as “home/bedroom/temperature” may be restricted to authorised users, ensuring that only those with proper access credentials can subscribe to and receive data from these topics. While using private topics is a practical way to differentiate between public and classified/confidential data, it does present some challenges:

• Topic Proliferation: As the number of devices, subscribers, and/or confidentiality levels increases, the creation of numerous private topics can become overwhelming, and can lead to a complex topic hierarchy that is challenging to manage effectively.

• Scalability Issues: In large-scale publish-subscribe deployments, managing an everexpanding list of private topics can strain system resources and make administration more complicated.

• Configuration Complexity: Maintaining a multitude of topics requires careful configuration, which, if not done accurately, can result in misconfigurations that compromise confidentiality.

• Resource Intensiveness: Handling a large number of private topics can be resource intensive for message brokers and client devices, impacting overall system performance.

• Lack of dynamicity: The current approaches are too static which prevents the creation of more dynamic use cases where subscriber’s roles can change over time.

Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges. As publish-subscribe systems continue to evolve, there is a growing need to strike a balance between granularity in managing data confidentiality and simplicity in administration.

This disclosure enables a publisher node to provide a granular distribution value for each published message in a topic. The distribution value can relate to the confidentiality of the message or message content, or any other relevant consideration that would lead to certain subscribers to a topic receiving more or less information than other subscribers to the same topic. Based on the distribution value, the broker node will distribute the message to subscribers that have an appropriate distribution value (e.g. those subscriber nodes whose own distribution value matches or exceeds that of the message). The message will not be sent to subscribers to the topic that do not have an appropriate distribution value.

In some embodiments, a subscriber node can suggest their own distribution value to the broker node when registering to a topic. Then, the policy management can become more dynamic, and it is not centred in the broker node. In some embodiments, the broker node may set a distribution value for the subscriber node, and this may or may not take into account a distribution value suggested by the subscriber node.

This technique allows the publishing of data with different confidentiality levels (or other type of distribution value) for a single topic, rather than defining a separate topic for each confidentiality level. This solution is more dynamic since each publisher node can decide the level of confidentiality of each message by itself without involving the broker node, which the conventional solutions currently do.

Thus, the disclosed techniques enable robust and granular data confidentiality within publish-subscribe systems while avoiding the need for an excessive proliferation of topic definitions. This allows the safeguarding of sensitive information from unauthorised access, while streamlining the topic structure to maintain a balance between data specificity and efficiency.

According to a first aspect, there is provided a method performed by a publisher node in a publish-subscribe system. The method comprises sending a first message for a first topic to a broker node, the first message comprising a distribution value for the first message.

According to a second aspect, there is provided a method performed by a broker node in a publish-subscribe system. A plurality of subscriber nodes are subscribed to a first topic, and the subscriber nodes have respective distribution values. The method comprises receiving a first message for the first topic from a publisher node, the first message comprising a distribution value for the first message; determining which of the subscriber nodes the first message is to be sent to based on the distribution value for the first message and the respective distribution values of the subscriber nodes; and sending the first message to the determined subscriber nodes.

According to a third aspect, there is provided a performed by a subscriber node in a publish- subscribe system. The method comprises sending a subscription message for a first topic to a broker node, the subscription message comprising a suggested distribution value for the subscriber node.

According to a fourth aspect, there is provided a computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method according to the first aspect, the second aspect, the third aspect, or any embodiments thereof.

According to a fifth aspect, there is provided a publisher node configured to perform the method according to the first aspect or any embodiments thereof.

According to a sixth aspect, there is provided a publisher node comprising a processor and a memory, said memory containing instructions executable by said processor whereby said publisher node is operative to perform the method according to the first aspect or any embodiments thereof.

According to a seventh aspect, there is provided a broker node configured to perform the method according to the second aspect or any embodiments thereof. According to an eighth aspect, there is provided a broker node comprising a processor and a memory, said memory containing instructions executable by said processor whereby said broker node is operative to perform the method according to the second aspect or any embodiments thereof.

According to a ninth aspect, there is provided a subscriber node configured to perform the method according to the third aspect, or any embodiments thereof.

According to a tenth aspect, there is provided a subscriber node comprising a processor and a memory, said memory containing instructions executable by said processor whereby said subscriber node is operative to perform the method according to the third aspect, or any embodiments thereof.

Certain embodiments may provide one or more of the following technical advantage(s). These advantages can be realised in systems involving or using Internet of Things (loT) devices and servers, in messaging systems, and in communication applications.

One advantage is enhanced data privacy. By using confidentiality granularity in the topics, sensitive information is protected from unauthorised access or disclosure. This is important in loT deployments where specific data must be kept confidential from certain parties, for example in energy consumption data collected by smart meters or healthcare data transmitted by loT devices (e.g. heart rate, blood glucose levels, or medication schedules).

Another advantage is that the techniques provide granular control over which clients can access specific data. Access control mechanisms enable the publishers to define precisely who can read the information in each published message associated with a topic, ensuring that only authorised entities have access.

Another advantage is scalability as the solutions are scalable to accommodate growing networks and deployments. Whether applied to a small-scale loT project or a large-scale industrial application, the access control and message management can adapt to changing needs.

The techniques provide efficient resource utilisation, making it particularly suitable for resource-constrained devices. This means that even in environments with limited computing power, the proposed solution can be implemented effectively and with minimal effort.

The proposed techniques provide compatibility and interoperability with publish-subscribe systems that use open standards, ensuring compatibility and interoperability with a wide range of publish-subscribe clients and brokers. This enables seamless integration into existing publish- subscribe-based systems.

The techniques allow for fine-grained messaging access control and data management that can be administered efficiently, minimising the risk of misconfiguration, and reducing administrative overhead. This is particularly important in complex networks with numerous clients and topics.

The techniques can be easily adapted to various use cases, such as a smart home, a connected vehicle, or an industrial automation system.

Finally, the techniques reduce the risk of a ‘topics explosion’, since messages with different semantics on the same data, and from the same topic, do not need to be sent via different topics, e.g. temperature value and potential fire hazard. This keeps the number of topics low, saving storage, improving their management, and making it easier for the subscribers to find relevant topics for their applications.

Brief Description of the Drawings

Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings, in which:

Fig. 1 is a high-level view of a publish-subscribe system;

Fig. 2 is a signalling diagram showing exemplary signalling between a subscriber and a broker when the subscriber is subscribing to a topic;

Fig. 3 illustrates exemplary signalling between a publisher and broker when a message is published;

Fig. 4 illustrates further exemplary signalling between a publisher and broker when a message is published;

Fig. 5 is a signalling/flow chart showing an exemplary message exchange using some extended protocol features for MQTT;

Fig. 6 is a flow chart illustrating a method performed by a publisher node in accordance with some embodiments;

Fig. 7 is a flow chart illustrating a method performed by a broker node in accordance with some embodiments;

Fig. 8 is a flow chart illustrating a method performed by a subscriber node in accordance with some embodiments;

Fig. 9 is a block diagram of an apparatus according to various embodiments; and

Fig. 10 is a block diagram illustrating a virtualization environment in which functions implemented by some embodiments may be virtualized.

Detailed Description

Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

As noted above, the techniques disclosed herein enable a publisher node to provide a granular distribution value for each published message in a topic. The distribution level can relate to the confidentiality of the message or message content, or any other relevant consideration that would lead to certain subscribers to a topic receiving more or less information than other subscribers to the same topic. Embodiments provide that a subscriber can provide and/or negotiate their distribution value with the broker. Based on the distribution value, the broker node will distribute the message to subscribers that have an appropriate distribution value (e.g. those subscriber nodes whose own distribution value matches or exceeds that of the message). The message will not be sent to subscribers to the topic that do not have an appropriate distribution value.

The techniques are described in more detail below with respect to specific implementations in MQTT and CoAP. While the techniques are described with reference to a distribution value in the form of a confidentiality value or confidentiality level, it will be appreciated that the following teachings can be ready applied to a distribution value for which considerations other than confidentiality are used to determine which subscribers to a particular topic are to receive information published to that topic.

Implementation in MQTT

MQTT operates on the principle of topics, where publishers send messages to topics registered in the broker, and subscribers receive messages by subscribing to those topics. In the current core MQTT specification, subscribers that are authorised to subscribe to a topic will get all the information published to the topic by a publisher. However, there are use cases where some of the published information for the topic might be confidential to certain subscribers. In those cases, the publisher or broker would need to create different topics according to the granularity of the published information.

The techniques described herein provide that within a single topic, the publisher(s) can indicate levels of data confidentiality for each published message associated with that topic. The level of data confidentiality for a particular message is indicated by a confidentiality value in, or associated with, the message. Even if a subscriber has been authorised to subscribe to data published for the topic, a subscriber will only receive a given published message if the message is within the security/confidentiality clearance of the subscriber.

The mechanism for assigning a confidentiality value to a subscriber can be a dynamic feature that can be suggested by subscribers or system administrators, or be assigned by the broker. This introduces an additional layer of control over the message’s delivery privacy. The following description relates to the confidentiality value being defined or set by the publishers on individual messages.

Subscriber-Initiated Subscription with Confidentiality Value: As noted above, subscribers can dynamically suggest, or define, their own confidentiality value for one or more topics. In particular, subscribers can express their desired confidentiality value when they subscribe to a topic. The signalling diagram in Fig. 2 illustrates the signalling between a subscriber 200 and broker 202 during the subscription establishment phase. The subscriber 200 sends a subscription request message (SUBSCRIBE message) 210 to the broker 202. The SUBSCRIBE message 210 indicate the topic(s) of interest ([TOPIC]), and also a confidentiality value ([CV]) for the subscriber. This confidentiality value may be the subscriber’s preferred or desired confidentiality value.

On receipt of subscription request message 210, the broker 202 determines the confidentiality value to be used for the subscriber 200. The broker 202 may use predefined policies or administrative rules to determine the confidentiality value to be used, or may negotiate and assign a final confidentiality value to the subscriber 200. The determined confidentiality value may be the same as the value requested in the subscription request message 210, higher or lower.

The broker 202 acknowledges the subscription request 210 with an acknowledgement message (SUBACK message) 212. The acknowledgement message 212 can indicate the determined confidentiality value. The acknowledgement message 212 may indicate that the suggested or requested confidentiality value has been agreed or approved, or may indicate the (different) confidentiality value that has been assigned. If the subscription request relates to multiple topics, the acknowledgement 212 may indicate different confidentiality values for different topics.

Publisher-Defined Confidentiality Value for Messages: When a publisher publishes a message for a topic to the broker, the publisher can specify the confidentiality value for the message. The signalling diagram in Fig. 3 illustrates the signalling between a publisher 300 and broker 302 when a message is published. The publisher 300 sends a publish message (PUBLISH message) 310 to the broker 302. The publish message 310 includes the message content for one or more messages ([MESSAGE]), the topic that the message(s) relate(s) to ([TOPIC]), and the confidentiality value ([CV]) for that/those message(s).

In step 312, the broker 302 forwards/publishes the message content ([MESSAGE]) to the subscribers that have an appropriate confidentiality value. For example, where higher confidentiality values for a message indicate a higher level of confidentiality for the message content, and higher confidentiality values for a subscriber indicate a higher clearance to view or receive confidential content, the broker 302 can forward/publish the message content to any subscriber that has a confidentiality level that matches or is higher than the confidentiality value of the message.

In this way, the publisher 300 can suggest a confidentiality value for each message in the PUBLISH message 310, but the actual delivery to each subscriber is up to the broker 302. This approach implies that the broker 302 needs to store and manage the agreed confidentiality values for each subscriber, and perform updates if that value changes over time.

In some cases, the publisher may not indicate a confidentiality value for the message in the publish message. In this case, the broker can use a default confidentiality value for the relevant topic instead to determine which subscribers the message is to be sent to.

Publisher-Defined Confidentiality Value for Topics: In a more general context, the confidentiality value may be dynamically specified for a topic. This could be achieved by specifying the confidentiality value when a topic is created (e.g. when a first PUBLISH message for the topic is sent). This way, when the broker receives a topic creation message that specifies a confidentiality value, the broker can store the information. After topic creation, the broker can use this information to forward the messages from that topic to subscribers that are eligible to receive them, based on the confidentiality value. This is illustrated in Fig. 4. Fig. 4 shows the signalling between a publisher 400 and broker 402 where a first message for a topic is published that includes a confidentiality value, and a subsequent message does not indicate the confidentiality value.

The publisher 400 sends a publish message (PUBLISH message) 410 to the broker 402. The publish message 410 includes the message content for one or more messages ([MESSAGE]), the topic that the message(s) relate(s) to ([TOPIC]), and the confidentiality value ([CV]) for that/those message(s).

The broker 402 responds with an acknowledgement (PUBACK) 412 to confirm receipt of the publish message 410.

In step 414, the broker stores the confidentiality value received in publish message 410, with the confidentiality value being associated with that topic.

The publisher 400 subsequently publishes another message for the topic via publish message 416, which includes new message content ([MESSAGE]). The publish message 416 does not include or indicate a confidentiality value for the message content.

The broker 402 responds with an acknowledgement (PUBACK) 418 to confirm receipt of the publish message 416. In step 420, the broker 402 uses the confidentiality value for the topic that was stored in step 414 to determine which subscribers the message content is to be sent to.

It will be appreciated that the confidentiality value of a topic may be changed even after the topic is created. It may be that the confidentiality value can only be changed by a predefined set of users, such as the system administrator or the creator of the topic. Such functionality may be enabled, for example, by the publisher sending an empty PUBLISH message with a different (new) confidentiality value. Subsequently, a Confidentiality POLICY UPDATE message could inform connected clients (subscribers) of any changes that might affect their confidentiality values.

MQTT Protocol Extensions for Dynamic Confidentiality: To implement the proposed techniques in MQTT, the existing MQTT protocol needs to be extended to allow for confidentiality negotiation between the broker and the clients (subscribers and publishers). Some exemplary additional protocol functions specifications that can be defined include:

Confidentiality Negotiation Request - An extension to the SUBSCRIBE message could include a new field for the negotiation request. The existing payload, which already includes the topic filter and the requested confidentiality, can be augmented with a “Negotiation Request” field, indicating if the client wishes to negotiate the confidentiality rather than simply accept the broker’s default.

Confidentiality Publication Request - An extension to the PUBLISH message could include a new field called “confidentiality value” that assigns the level of confidentiality for each message.

Confidentiality Negotiation Response - The SUBACK message can be extended to include a “Negotiation Response” field. This field can confirm the confidentiality value granted by the broker and might also include a reason code indicating why a particular confidentiality value was assigned (e.g. policy restrictions, resource limitations).

Confidentiality Level Discovery - A new control message could be introduced to allow clients to query the broker for the confidentiality values available to them before subscribing to a topic. This could enable clients to make informed decisions based on the broker’s current policies and system load.

Confidentiality Policy Update - An administrative client or the broker itself might change confidentiality policies or confidentiality values dynamically. A new control message, such as a Confidentiality POLICY UPDATE message, could inform connected clients of any changes that might affect their confidentiality values.

Error Handling and Status Codes - Additional error/status codes could be provided for scenarios where negotiation fails, or a client’s request cannot be granted or honoured due to system constraints.

Example of Extended Message Exchange: The signalling/flow chart in Fig. 5 shows an exemplary message exchange using the above extended protocol features for MQTT. In particular, Fig. 5 shows signalling between a subscriber 500, a broker 502 and a publisher 504.

In step 510, the system administrator sets the confidentiality value for the subscriber 500 to a value “1”, which is the lowest/loosest confidentiality value, meaning that the subscriber 500 is only permitted to access messages with the lowest confidentiality value.

Confidentiality Negotiation Request - The subscriber 500 sends a SUBSCRIBE message 512 with the requested confidentiality value of “1” and sets the “Negotiation Request” field to indicate a desire to negotiate to the topic “/livingroom/temp”, which relates to temperature measurements in a living room of a house.

Broker Assessment - The broker 502 receives the SUBSCRIBE message 512, evaluates the subscriber’s request against its policies (step 514), and prepares a response.

Confidentiality Negotiation Response - The broker 502 responds to the subscriber 500 with a SUBACK message 516 containing the “Negotiation Response” field. If the negotiation is successful, the field can indicate the assigned confidentiality value, which in this case is “1”. If the negotiation is not successful, the “Negotiation Response” field can provide a reason code.

Publication Message with Confidentiality - The publisher 504 sends a PUBLISH message 518 with a confidentiality value for the message. The publish message 518 indicates that the message relates to the topic “/livingroom/temp”, the confidentiality value is “1”, and the message content is “20.7” (a temperature measurement).

Broker Confidentiality Message Delivery - The broker 502 performs a check in step 520 to determine whether the content of the message 518 can be delivered to the subscriber 500. In particular, the broker 502 checks the confidentiality value of the subscriber 500 against the confidentiality value of the message 518, and then delivers the message to each subscriber 500 that has a required confidentiality level. The delivery of the message to the subscriber 500 is shown by message 522, with message 522 indicating the topic “/livingroom/temp”, and the payload of “20.7”.

Confidentiality Negotiation Fail - Subsequently the same subscriber client 500 sends a SUBSCRIBE message 524 with the requested confidentiality value and sets the "Negotiation Request" field to indicate a desire to negotiate to the topic “/bedroom/light”, which relates to light levels in a bedroom.

Broker Assessment - The broker 502 receives the SUBSCRIBE message 524, evaluates the subscriber’s request against its policies (step 526), and prepares a response. In this case, the broker 502 determines that the subscriber 500 is not allowed to subscribe to this particular topic.

Broker Error Message - Therefore the broker 502 sends an error message 528 to the subscriber 500 since the client cannot subscribe to this particular topic.

Publication Message with Confidentiality -The publisher 504 subsequently sends a PUBLISH message 530 with a confidentiality value for the message. The publish message 530 indicates that the message relates to the topic “/bedroom/light”, the confidentiality value is “1”, and the message content is “19.8” (a light measurement).

Broker Confidentiality Message Delivery - The broker 502 performs a check in step 532 to determine whether the content of the message 530 can be delivered to the subscriber 500. As the subscriber was not allowed to subscribe to the topic “/bedroom/light”, the broker 502 determines that the message 530 is not to be delivered to subscriber 500. The broker 502 therefore does not send the message 530 (shown by block 534).

Implementation in CoAP

The Constrained Application Protocol (CoAP) is an Internet protocol designed for resource constrained devices. CoAP defines two roles: CoAP Client and CoAP Server. A CoAP Client sends a request to a CoAP Server, and the CoAP Server sends a response back to the CoAP Client. An entity can act as either a CoAP Client, a CoAP Server, or both. In a typical scenario, constrained devices act as CoAP Clients and communicate with servers acting as a CoAP Server. A single CoAP Server typically serves multiple CoAP Clients.

The CoAP publish-subscribe mechanism, which is defined in the ietf draft: draft-ietf-core- coap-pubsub “A publish-subscribe architecture for the Constrained Application Protocol (CoAP)”, is implemented using existing CoAP methods and mechanisms. Publish-subscribe Topics will be realised by CoAP Resources. Publishers and Subscribers will be realised as CoAP Clients, and brokers as CoAP Servers.

Topics are implemented using CoAP Resources. Each Topic is associated with two CoAP Resources: a topic resource and a topic-data resource. The topic resource is used to create and administrate a Topic, while the topic-data resource is used to publish and subscribe data on the Topic.

A Publisher (CoAP Client) publishes to a topic by including the published data in a CoAP PUT request to the CoAP topic-data resource associated with the Topic. The published data will modify the state of the CoAP topic-data resource.

Subscriptions are implemented using the CoAP Resource Observation mechanism (as described in IETF RFC 7641). A Subscriber (CoAP Client) subscribes to a topic by sending a CoAP GET request with the Observe option set to 0 to the CoAP topic-data resource associated with the topic. When the topic-data resource state changes (when a Publisher publishes data to the topic-data resource), the Subscriber will receive a CoAP notification (CoAP GET response), that contains the published data.

CoAP Protocol Extensions for Dynamic Confidentiality: To implement the techniques described herein, the CoAP protocol can be extended to allow for confidentiality negotiation between the brokers (CoAP Servers) and the Publishers/Subscribers (CoAP Clients). The following description provides options for extending the CoAP protocol in order to support the mechanism:

Confidentiality Negotiation Request - A new CoAP message header Option (e g. “conflevel”) can be defined. The Option is included in a CoAP GET request to indicate the requested confidentiality level of the Subscriber for the topic that the Subscriber is subscribing to. Based on local policy, the broker might accept the requested confidentiality level, or assign a different confidentiality level for the Topic to the Subscriber. If the Subscriber does not request a confidentiality level, the broker might still assign a confidentiality level for the Subscriber.

Confidentiality Negotiation Response -A new CoAP message header Option (e g. “conflevel”) can be defined. The Option is included in a CoAP GET response to indicate the confidentiality level that has been assigned to the Subscriber by the broker, for the Topic that the Subscriber has subscribed to.

Publisher Published Data Confidentiality Level - A new CoAP message header Option (e.g. “conf-level”) can be defined. The Option is included in a CoAP PUT request to indicate the confidentiality level for the published data included in the request. The broker will only forward the published data to Subscribers that have been assigned an equal or higher confidentiality value for the associated Topic.

Topic Configuration - New CoAP publish-subscribe parameters (e.g. conf-level-min, conf- level-max) can be defined. When a Topic is created, the Topic creator can use these parameters to configure confidentiality level parameters for the Topic, e.g. the minimum and maximum confidentiality values that can be used by data published to the Topic, or the minimum or maximum confidentiality values that can be assigned to Subscribers subscribing to the Topic. The same parameters can be used to provide the information when a user is querying the metadata for a Topic.

Error Handling and Status Codes - Additional error/status codes would be necessary for scenarios, e.g. where a confidentiality value requested by a Subscriber is not accepted by the broker, or where the confidentiality value selected by a Publisher when publishing data is not accepted by the broker. Confidentiality Value for data published to a Topic - Confidentiality Value Assigned by the Publisher: In this case, when a Publisher publishes data to a Topic, it can assign the Confidentiality Value for the published data. Therefore, a CoAP PUT message, that contains the published data and the Confidentiality Value assigned to the data, is sent by the Publisher. The Publisher can assign a different Confidentiality Value in each CoAP PUT message, even if the data is published to the same Topic as previously. The broker forwards the published data to each Subscriber that has subscribed to the Topic to which the data is published, and that has been assigned a confidentiality value equal to or higher than the confidentiality value of the published data.

Confidentiality Value for data published to a Topic - Confidentiality Value assigned by the Broker: Similar to the MQTT use case, the Confidentiality Value for data published to a Topic can be assigned by the broker, even if the Publisher has assigned a Confidentiality Value to the published data. Based on configuration or local policy, the broker can assign the same Confidentiality Value to all data published to a Topic, or it can assign different Confidentiality Values.

Confidentiality Value for data published to a Topic - Confidentiality Value reguested by the Subscriber: In this case, when a Subscriber subscribes to a Topic, it can request the Confidentiality Value for data published to the Topic. Therefore, the Subscriber can send a CoAP GET message that indicates the Topic the Subscriber wants to subscribe to, and the requested Confidentiality Value for the Topic. The broker can, based on local policy, accept or reject the requested Confidentiality Value. If the broker rejects the requested Confidentiality Value, it can assign another Confidentiality Value to the Subscriber. When a Publisher publishes data for the Topic to which the Subscriber has subscribed, the broker will forward the published data to the Subscriber if the Confidentiality Value of the published data is equal to or higher than the Confidentiality Value that has been assigned to the Subscriber for the Topic.

It will be appreciated that the techniques described herein can be implemented in a distributed manner across several nodes in a network, such as in cloud-based systems or loT (Internet of Things) environments. That is, part or all of the techniques described herein can be implemented on one or multiple nodes, with any one or more of those nodes being virtualised.

For example, the core of MQTT communication is the MQTT broker, which is responsible for message routing and security enforcement. In a distributed implementation, MQTT brokers can be organised into a cluster. This cluster can consist of multiple broker nodes distributed across different servers or cloud instances. These nodes work together to ensure the reliability and scalability of MQTT communication.

As another example, managing the confidentiality value of the subscribers, especially in cases where there are many subscribers and topics, or complex topic hierarchies, can be resource intensive. A dedicated node can handle/manage the confidentiality value of each subscriber and the topics, ensuring that they are appropriately configured and organised. The management node can also dynamically adjust topic and subscriptions based on changing confidentiality requirements.

Fig. 6 is a flow chart illustrating a method according to various embodiments performed by a publisher node. The publisher node is part of a publish-subscribe system. The publisher node may perform the method in response to executing suitably formulated computer readable code. The computer readable code may be embodied or stored on a computer readable medium, such as a memory chip, optical disc, or other storage medium. The computer readable medium may be part of a computer program product.

In step 601 , the publisher node sends a first message for a first topic to a broker node. The first message comprises a distribution value for the first message. The first message can be a publish message. The distribution value indicates a level of confidentiality or security for the first message. The first message may be a message according to the MQTT protocol or CoAP.

In some cases, prior to step 601 , the publisher node can determine the distribution value for the first message.

In some cases, prior to step 601 , the publisher node can send a topic configuration message to the broker node to establish or update the first topic at the broker node. The topic configuration message indicates a distribution value for the first topic. The distribution value indicated for the first message sent in step 601 can correspond to the distribution value indicated for the first topic. The distribution value for the first topic may be used as a default distribution value for messages for the first topic from the publisher node to the broker node.

In some cases, the publisher node may send a further message for the first topic to the broker node. This further message can comprise a respective distribution value for the further message, and in some cases the distribution value for the further message is different to the distribution value for the first message.

Fig. 7 is a flow chart illustrating a method according to various embodiments performed by a broker node. The broker node is part of a publish-subscribe system. The broker node may perform the method in response to executing suitably formulated computer readable code. The computer readable code may be embodied or stored on a computer readable medium, such as a memory chip, optical disc, or other storage medium. The computer readable medium may be part of a computer program product.

In step 701 , the broker node receives a first message for a first topic from a publisher node. The first message comprises a distribution value for the first message. A plurality of subscriber nodes are subscribed to the first topic, and the subscriber nodes have respective distribution values. The first message can be a publish message. The distribution value indicates a level of confidentiality or security for the first message. The first message may be a message according to the MQTT protocol or CoAP.

In step 702, the broker node determines which of the subscriber nodes the first message is to be sent to based on the distribution value for the first message and the respective distribution values of the subscriber nodes.

In step 703, the broker node sends the first message to the determined subscriber nodes. It will be appreciated that steps 702 and 703 may result in the first message being sent to all, some, one or none of the subscriber nodes, depending on their respective distribution values.

Step 702 can comprise comparing the distribution value for the first message to the respective distribution values of the plurality of subscriber nodes. The subscriber nodes to send the first message to are determined based on the result of the comparison. The first message is not sent to the other ones of the subscriber nodes. That is, the first message is not sent to any subscriber nodes other than the subscriber nodes determined in step 702.

In some embodiments, the broker node can receive a topic configuration message from the publisher node to establish or update the first topic. The topic configuration message indicates a distribution value for the first topic. The broker node can then establish or update the first topic. The distribution value for the first topic can be used as a default distribution value for one or more messages from the publisher node for the first topic. In particular, the broker node may receive a second message for the first topic from the publisher node, where the second message does not comprise a distribution value for the second message. The broker node can then determine which of the subscriber nodes the second message is to be sent to based on the default distribution value for the first topic and the respective distribution values of the subscriber nodes. The second message is then sent those subscriber nodes.

In some cases, the broker node may receive a further message for the first topic from the publisher node. This further message can comprise a respective distribution value for the further message, and in some cases the distribution value for the further message is different to the distribution value for the first message. The broker node can determine which of the subscriber nodes the further message is to be sent to based on the distribution value for the further message and the respective distribution values of the subscriber nodes. The further message is then sent to that or those subscriber nodes. In some embodiments, the broker node can receive a subscription message for the first topic from a first subscriber node. The subscription message can comprise a suggested distribution value for the first subscriber node. The broker node can determine a distribution value for the first subscriber node based on the suggested distribution value. The broker node can send the determined distribution value to the first subscriber node.

Fig. 8 is a flow chart illustrating a method according to various embodiments performed by a subscriber node. The subscriber node is part of a publish-subscribe system. The subscriber node may perform the method in response to executing suitably formulated computer readable code. The computer readable code may be embodied or stored on a computer readable medium, such as a memory chip, optical disc, or other storage medium. The computer readable medium may be part of a computer program product.

In step 801 the subscriber node sends a subscription message for a first topic to a broker node. The subscription message comprises a suggested distribution value for the subscriber node. The subscription message requests the broker node to send one or more messages for the first topic to the subscriber node. The suggested distribution value can indicate a level of confidentiality or security that the subscriber node considers it has, or should have. The subscription message can be a message according to the MQTT protocol, or CoAP.

The subscriber node may subsequently receive a determined distribution value from the broker node. The determined distribution value indicates a determined level of confidentiality or security for the subscriber node.

After sending the subscription message in step 801 , the subscriber node may receive a first message for the first topic from the broker node.

The techniques described herein are applicable to a wide range of different use cases, that are not currently feasible with state-of-the-art solutions, or that are too complex to implement.

Temperature reporting and potential fire hazards - A fire alarm monitoring system may be implemented leveraging a temperature monitoring system that uses a single topic, such as “room/temperature”, per sensor. Here, the temperature sensor reports regular temperature, e.g. 20 degrees, through messages with low confidentiality values. Conversely, when the temperature is too high, hence suggesting there could be a potential fire hazards, the sensor sends the temperature reading with higher confidentiality value. This way, the relevant recipients, for example the fire department, can receive the information and act upon its reception. In this use case, the confidentiality value avoids the need to have multiple topics for different purposes, as well as avoiding the need for additional software to handle/relay the information depending on the temperature value, thus reducing the software complexity.

Reporting frequency - A temperature monitoring system can report temperature values via a topic, for example “room/temperature”, to different subscribers with different frequencies depending on the confidentiality value. That is, for example, subscribers with low confidentiality values can receive sensor readings once per hour, while subscribers with high confidentiality values can receive sensor readings once per second. Using current techniques, this operation could only be achieved by creating multiple topics, one for the ‘1 hour’ frequency and one for the ‘1 second’ frequency, and additionally this implementation leverages roles that will put more strain on the broker.

Semantics-enhanced messages - A luminosity monitoring system may report light values to all the subscribers with a low confidentiality value. As such, light values are not so insightful and are suitable for subscribers with low confidentiality values. However, light values may be used to infer whether one or more people are currently present within a room. In this case, the same topic used for light values could be used to deliver the information regarding the presence of people within a room to subscribers with a high confidentiality value. To implement something similar using conventional techniques, it would be necessary to have multiple topics or add complexity at the broker.

Fig. 9 is a simplified block diagram of an apparatus 900 that can be used to implement, or implement part of, one or more of the nodes described herein. In particular, the apparatus 900 may be, or be a part of, a publisher node, a broker node, or a subscriber node. More generally, the apparatus 900 can be any of a client, a MQTT client, a CoAP client, a MQTT Broker, a UE, an loT device, a server, a CoAP server, a computer, etc. In particular embodiments, the apparatus 900 can be configured or adapted to perform the method in any of Figs. 6, 7 or 8.

The apparatus 900 comprises processing circuitry (or logic) 901 . It will be appreciated that the apparatus 900 may comprise one or more virtual machines running different software and/or processes. The apparatus 900 may therefore comprise, or be implemented in or as one or more servers, switches and/or storage devices and/or may comprise cloud computing infrastructure that runs the software and/or processes.

The processing circuitry 901 controls the operation of the apparatus 900 to implement any of the methods described herein. The processing circuitry 901 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the apparatus 900 in the manner described herein. In particular implementations, the processing circuitry 901 can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the apparatus 900.

The apparatus 900 also comprises a communications interface 902. The communications interface 902 is for use in enabling communications with other apparatus, nodes, computers, servers, etc. For example, the communications interface 902 can be configured to transmit to and/or receive from other nodes, requests, acknowledgements, information, data, signals, or similar. The communications interface 902 can use any suitable communication technology.

The processing circuitry 901 may be configured to control the communications interface 902 to transmit to and/or receive from other nodes, etc. requests, acknowledgements, information, data, signals, or similar, according to the methods described herein.

The apparatus 900 may comprise a memory 903. In some embodiments, the memory 903 can be configured to store program code that can be executed by the processing circuitry 901 to perform the methods described herein in relation to the apparatus 900. Alternatively or in addition, the memory 903 can be configured to store any requests, acknowledgements, information, data, signals, or similar that are described herein. The processing circuitry 901 may be configured to control the memory 903 to store such information therein.

Fig. 10 is a block diagram illustrating a virtualization environment 1000 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 1000 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a client node, a server node, a publisher node, a broker node, or a subscriber node.

Applications 1002 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment 1000 to implement some of the features, functions, and/or benefits of some of the embodiments disclosed herein.

Hardware 1004 includes processing circuitry, memory that stores software and/or instructions executable by hardware processing circuitry, and/or other hardware devices as described herein, such as a network interface, input/output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 1006 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1008a and 1008b (one or more of which may be generally referred to as VMs 1008), and/or perform any of the functions, features and/or benefits described in relation with some embodiments described herein. The virtualization layer 1006 may present a virtual operating platform that appears like networking hardware to the VMs 1008. The VMs 1008 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 1006. Different embodiments of the instance of a virtual appliance 1002 may be implemented on one or more of VMs 1008, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

In the context of NFV, a VM 1008 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 1008, and that part of hardware 1004 that executes that VM, be it hardware dedicated to that VM and/or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 1008 on top of the hardware 1004 and corresponds to the application 1002.

Hardware 1004 may be implemented in a standalone network node with generic or specific components. Hardware 1004 may implement some functions via virtualization. Alternatively, hardware 1004 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 1010, which, among others, oversees lifecycle management of applications 1002. In some embodiments, hardware 1004 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signalling can be provided with the use of a control system 1012 which may alternatively be used for communication between hardware nodes and radio units.

Although the computing devices described herein (e.g., apparatus, clients, servers, nodes, etc.) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and/or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and/or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and/or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionalities may be provided by the processing circuitry without executing instructions stored on a separate or discrete device- readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and/or by end users and a wireless network generally.

The foregoing merely illustrates the principles of the disclosure. Various modifications and alterations to the described embodiments will be apparent to those skilled in the art in view of the teachings herein. It will thus be appreciated that those skilled in the art will be able to devise numerous systems, arrangements, and procedures that, although not explicitly shown or described herein, embody the principles of the disclosure and can be thus within the scope of the disclosure. Various exemplary embodiments can be used together with one another, as well as interchangeably therewith, as should be understood by those having ordinary skill in the art.

Claims

1. A method performed by a publisher node in a publish-subscribe system, the method comprising: sending (601) a first message for a first topic to a broker node, the first message comprising a distribution value for the first message.

2. The method as claimed in claim 1 , wherein the method further comprises: determining the distribution value for the first message.

3. The method as claimed in claim 1 or 2, wherein the method further comprises: sending a further message for the first topic to the broker node, the further message comprising a respective distribution value for the further message.

4. The method as claimed in claim 3, wherein the distribution value for the further message is different to the distribution value for the first message.

5. The method as claimed in any of claims 1-4, wherein the first message is a publish message.

6. The method as claimed in any of claims 1-5, wherein the method further comprises: sending a topic configuration message to the broker node to establish or update the first topic at the broker node, wherein the topic configuration message indicates a distribution value for the first topic.

7. The method as claimed in claim 6, wherein the distribution value for the first topic is used as a default distribution value for messages for the first topic from the publisher node to the broker node.

8. The method as claimed in any of claims 1-7, wherein the distribution value indicates a level of confidentiality or security for the first message.

9. The method as claimed in any of claims 1-8, wherein the first message is a message according to a Message Queuing Telemetry Transport, MQTT, protocol, or a Constrained Application Protocol, CoAP.

10. A method performed by a broker node in a publish-subscribe system, wherein a plurality of subscriber nodes are subscribed to a first topic, and the subscriber nodes have respective distribution values, the method comprising: receiving (701) a first message for the first topic from a publisher node, the first message comprising a distribution value for the first message; determining (702) which of the subscriber nodes the first message is to be sent to based on the distribution value for the first message and the respective distribution values of the subscriber nodes; and sending (703) the first message to the determined subscriber nodes.

11. The method as claimed in claim 10, wherein the step of determining (702) comprises comparing the distribution value for the first message to the respective distribution values of the plurality of subscriber nodes.

12. The method as claimed in claim 11 , wherein the subscriber nodes to send the first message to are determined based on the result of the comparison.

13. The method as claimed in any of claims 10-12, wherein the distribution value for the first message indicates a level of confidentiality or security for the first message.

14. The method as claimed in any of claims 10-13, wherein a respective distribution value for a subscriber node indicates a level of confidentiality or security for the subscriber node.

15. The method as claimed in any of claims 10-14, wherein the first message is not sent to the other ones of the subscriber nodes.

16. The method as claimed in any of claims 10-15, wherein the first message is a publish message.

17. The method as claimed in any of claims 10-16, wherein the method further comprises: receiving a topic configuration message from the publisher node to establish or update the first topic, wherein the topic configuration message indicates a distribution value for the first topic.

18. The method as claimed in claim 17, wherein the method further comprises: establishing or updating the first topic, wherein the distribution value for the first topic is used as a default distribution value for one or more messages from the publisher node for the first topic.

19. The method as claimed in claim 18, wherein the method further comprises: receiving a second message for the first topic from the publisher node, wherein the second message does not comprise a distribution value for the second message; determining which of the subscriber nodes the second message is to be sent to based on the default distribution value for the first topic and the respective distribution values of the subscriber nodes; and sending the second message to the determined subscriber nodes.

20. The method as claimed in any of claims 10-19, wherein the method further comprises: receiving a further message for the first topic from the publisher node, the further message comprising a respective distribution value for the further message, wherein the distribution value for the further message is different to the distribution value for the first message.

21 . The method as claimed in claim 20, wherein the method further comprises: determining which of the subscriber nodes the further message is to be sent to based on the distribution value for the further message and the respective distribution values of the subscriber nodes; and sending the further message to the determined subscriber nodes.

22. The method as claimed in any of claims 10-21 , wherein the method further comprises: receiving a subscription message for the first topic from a first subscriber node, the subscription message comprising a suggested distribution value for the first subscriber node.

23. The method as claimed in claim 22, wherein the method further comprises: determining a distribution value for the first subscriber node based on the suggested distribution value.

24. The method as claimed in claim 23, wherein the method further comprises: sending the determined distribution value to the first subscriber node.

25. The method as claimed in any of claims 10-23, wherein the first message is a message according to a Message Queuing Telemetry Transport, MQTT, protocol, or a Constrained Application Protocol, CoAP.

26. A method performed by a subscriber node in a publish-subscribe system, the method comprising: sending (801) a subscription message for a first topic to a broker node, the subscription message comprising a suggested distribution value for the subscriber node.

27. The method as claimed in claim 26, wherein the method further comprises: receiving a determined distribution value from the broker node.

28. The method as claimed in claim 27, wherein the determined distribution value indicates a determined level of confidentiality or security for the subscriber node.

29. The method as claimed in any of claims 26-28, wherein the subscription message requests the broker node to send one or more messages for the first topic to the subscriber node.

30. The method as claimed in any of claims 26-29, wherein the method further comprises: receiving a first message for the first topic from the broker node.

31. The method as claimed in any of claims 26-30, wherein the suggested distribution value indicates a suggested level of confidentiality or security for the subscriber node.

32. The method as claimed in any of claims 26-31 , wherein the subscription message is a message according to a Message Queuing Telemetry Transport, MQTT, protocol, or a Constrained Application Protocol, CoAP.

33. A computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method of any of claims 1-32.

34. A publisher node configured to perform the method of any of claims 1-9.

35. A publisher node comprising a processor and a memory, said memory containing instructions executable by said processor whereby said publisher node is operative to perform the method of any of claims 1-9.

36. A broker node configured to perform the method of any of claims 10-25.

37. A broker node comprising a processor and a memory, said memory containing instructions executable by said processor whereby said broker node is operative to perform the method of any of claims 10-25.

38. A subscriber node configured to perform the method of any of claims 26-32.

39. A subscriber node comprising a processor and a memory, said memory containing instructions executable by said processor whereby said subscriber node is operative to perform the method of any of claims 26-32.