IR Colonies represent a theoretical concept derived from membrane and reaction systems, and their purpose is to model communication between Internet of Things (IoT) devices. In this paper, we analyze the possibilities of turning this concept into a real-world application, and determine the possibility of implementing the system as a real communication simulator in an IoT network. IoT devices use a variety of protocols to communicate with each other, which can be classified into one of two communication models. In this paper, we analyze the specifics of these two communication models and consequently, of the individual protocols, and consider appropriate approaches and possible modifications of the concept into a form compatible with the respective protocols.
Membrane computing (introduced by Gheorghe Paˇun in 1998) is a framework for modeling parallel
distributed processing. Mathematical models of membrane systems have been called P Systems.
Information about this paradigm is available in [
The development continued and a number of systems based on P Systems were created. The P
Colony (introduced in [
P Colonies with transferable programs were introduced in [
Reaction systems were introduced in [
IR Colonies were introduced in [
The purpose of this paper is to examine the compatibility and identify any diferences between IR Colonies and common IoT application protocols. The goal is to prepare for the use of IR Colonies for the purpose of simulating communication in IoT device networks and to transform the IR Colony structure into real-world IoT (Internet of Things) device networks.
This section is followed by the preliminaries section with a brief introduction to IR Colonies, IoT protocols and basic IoT communication models.
Section 3 consists of three subsections: in the first one, we discuss diferent aspects of the functionality of IR Colonies and identify the possibilities of their implementation. In the second and third subsections, we focus on the possibilities of implementing communication between agents with each other and between agents and the environment, analyzing the correlation of this communication to the two basic communication models for IoT networks (Request-Response and Publish-Subscribe).
Section 4 is devoted to individual application protocols used in the world of IoT devices, focusing in particular on the two most common protocols. We consider their communication model (typically one of the two previously discussed), but also other features that need to be considered when implementing the IR Colony concept.
We assume the reader to be familiar with the basics of the formal language theory [
We denote the length of a word by ||, and also the number of elements in a set by ||. The empty word is represented by the symbol , so || = 0.
For details and definitions of graph theory, we can refer e.g. to https://www.britannica.com/topic/ graph-theory [2024-07-08]. We denote the set of all nodes from which an edge leads to a node by in().
An IR Colony is a system of agents in a shared environment, connections between agents are defined using a graph. Each agent has its own state in the form of a set of objects, and objects can also occur in the shared environment.
In order to make our IR Colony concept applicable to IoT network simulation, we need objects with properties (values). The properties of objects are numbers (e.g. for an object of type temperature, the property is the temperature value, an object specifying the version of a device will have the version number directly as a property). In the basic concept of IR Colony, each object has at most one property and the value of this property is a number, but in principle it is not a problem to modify this concept and use objects with more than one property, moreover of diferent types (numbers, strings).
The agent state is determined by the set of objects. Because our objects can have properties, set operations on these sets must be defined a little diferently than usual.
Definition 1 (According to [
The intersection operation is commutative.
All membership operators (e.g. ⊆) work with properties in the same way.
The union operation applied on a set of objects with properties is not commutative. If the same object is in both sets, but with diferent properties, the object from the set on the right side of the union operator will be the member of the resulting set. There are the following cases: • ∈ or () ∈ : () ∈ {()} ∪ and () ∈ ∪ {()}, • () ∈ , ̸= : () ∈ ∪ {()}, but () ̸∈ {(} ∪ and () ∈ {()} ∪ . For the union operation, the second case listed: This corresponds to updating properties in the right-toleft direction, e.g. {(), ()} ∪ {(), ()} = {(), (), ()}.
If the same object has a property in only one of the sets, then the result of the union will contain the object with the property. E.g. {()} ∪ {, } = {(), }.
If objects could have more than one property, the definition would need to be slightly modified. We
would assume that two objects of the same type are diferent if they difer in at least one property.
Definition 2 (IR Colony, [
If the graph is undirected, then it is connected. If is directed, then it is weakly connected.
An agent , 1 ≤ ≤ , is a pair = ( , ) where • ⊂ Σ, ̸= ∅ is the initial state of the agent, • is the initial set of programs of the given agent, is finite, and can be empty.
The symbols (objects) in rules may or may not have properties specified. Listing a property on the left side of a rule indicates a conditional application of that rule. The properties are numbers from R. The rules can be in one of the following forms: • evolution rule: → or () → (), , ∈ Σ , an agent evolves its state, , ∈ R are properties of the given objects, • deletion rule: → , ∈ Σ, • multicast rule: →−out, , ∈ Σ to send the object to all outgoing edges, remains inside the sending agent; if = , it is not necessary to specify the properties of the objects, the current property of is used, • backup rule: →, ∈ Σ , to put the object down into the environment (including its current property), the object remains in the agent’s state, • restoration rule: ← , ∈ Σ , to pick an object up from the environment (including its current property), the object remains in the environment; if has been present in the state of the given agent, the parameter will be rewritten (updated), • programming rule: ◁, the format is explained below at the end of the definition.
The backup and restoration rule types apply the union operation, including the processing of parameters. Denote the set of all possible rules for Π . A program in Π is a construct lab = (lab, , , ) where • each program has the own unique label lab, • ⊆ is a finite nonempty set of rules, • ⊆ Σ ∪ is a finite set of reactants, reactants can be: • ⊆ Σ ∪ for .
– an object with or without a property (a relational expression can be added to the object for its property), – a relation between properties of diferent objects, – a program,
is a finite set of inhibitors, ∩ = ∅, the syntax of elements of the set is the same as The set must be deterministic in the sense that the same object must not appear on the left-hand side of any two rules.
A programming rule is a construct (label, , , ) ◁ with the parts of this sequence of the same meaning as in the definition of a program. The programming rule creates a new program with the given parameters and stores it in the rule repository in the environment.
Definition 3 (Application of rules and programs, [
A state of a given agent , 1 ≤ ≤ is a set of objects, the objects have or have not properties.
A rule ∈ with an object ∈ Σ on the left side is applicable to a state of a given agent , if the object is present in including potential parameters. The restoration rule ← is applicable if the object on the right side is present in the environment. The programming rule is always applicable.
A program lab in an agent = ( , ) is applicable if • all rules in are applicable to , • ( ∩ Σ) ⊆ , ( ∩ ) ⊆ , • ∩ = ∅, ∩ = ∅.
During a single step, the following happens (for a ℎ agent): 1. the agent checks the program repository and updates its own programs: if there is a program with a label belonging to one of the agent’s programs, the agent’s original program is overwritten by a new program with the same label located in the repository, 2. the agent nondeterministically chooses one of its applicable programs, 3. all rules in the program are processed with influencing the own state and computation of the result and context sets for the given agent and step, 4. the result sets are used to calculate the new state of agents.
Example 1. The paper [
J ?
light bulb 4 Updater
2 J^J
control 5 6 J 6 3 J^J
]JJ 7
J ? CO2 sensor
For example, the agent 5 (Window control) is defined as follows: 5 = ({(1), (0), (0)}, {wopent, wopens, wclose}) Thus, its initial state contains three symbols, the first of which is the version of its software (to see if it an update is necessary), the next one indicates the current state of the window opening (value 0 means “closed”), the third one is to indicate the manual mode of window control (value 0 means “manual mode is of”, i.e. the window is controlled by this component. There are three programs in the set of programs: the first one for opening the window if the temperature in the room is too high (info from the thermometer), the second one after the information about high CO2 level, the third one for closing the window. The first program: (wopent, {(0) → (1)}, {(> 22)}, {(1)}) The set of rules contains a single rule that changes the state of the window to “open”, the set of reactants contains a single reactant specifying that the rule is to be executed if an object with a property value greater than 22 is received from the thermometer (the object then remains in the agent state and is overwritten by any other incoming objects of the same type). The inhibitor of the rule is a manual window control object in the state “manual mode is on”.
In the paper [
Other possible reactants and inhibitors could be related to outdoor temperature, and weather in Example 2. The following diagram shows a simple centralized network of several IoT devices.
2
3 sensor
4 sensor
Hub - Light at entrance 5 we only want to turn on the light if someone appears at the door.
The IR Colony: Π = (Σ, , , , and the structure shown in Figure 2 using the location function .
There are currently no objects in the shared environment (i.e., 0 = ∅); it is a simple closed system. The set 0 is also empty; the program repository would be used e.g. if we added an update mechanism or if the hub were user-programmable and allowed changes to the functionality of the connected devices.
0, 0) where = {1, . . . , 5}, = (, ) is a graph corresponding to the set The agent 1 is defined as follows:
{ day(0), move(1)}, {lightState(1)}) 1 = ({day(1), sun(1), move(0), lightState(0)}, {lightOn1, lightOn2, lightOf}) with three programs: (lightOn1, { lightState(0) → lightState(1), lightState →−outlightState}, (lightOn2, { lightState(0) → lightState(1), lightState →−out lightState}, { day(1), sun(0), move(1)}, {lightState(1)})
The set of inhibitors could be empty if we placed lightState(0) in the set of reactants. (lightOf, { lightState(1) → lightState(0), lightState →− lightState}, { day(1), sun(1), move(0)}, {lightState(0)}) out The multicast rules contain objects without property, they only transmit the current values.
This agent acts as a hub and is the central element of the entire network. It can be equipped with a display showing the current status of connected devices, i.e., the properties of objects in the agent’s state.
The next three agents are simple: 2 = ({day(1)}, {transportDay}) with one program: (transportDay, {day →−outday}, {day}, ∅) 3 = ({sun(1)}, {transportSun}) with one program: (transportSun, {sun →−outsun}, {sun}, ∅) 4 = ({move(0)}, {transportMove}) with one program: (transportMove, move →−outmove, {move}, ∅)
The agents 2, 3, 4 operate asynchronously at regular intervals because the status of the sensors does not change very often and it is necessary to preserve the battery life of these devices. The light should also remain switched on for a certain period of time even when no movement is detected.
The properties of the enclosed objects day, sun and move changes independently of the IR colony according to the current status of the (physical) sensors. The role of the agents is to be transmitting the current values to the agent 1.
The last agent is very simple, it has no programs: 5 = ({lightState(0)}, ∅)
The enclosed object is being updated by the hub in regular intervals, the current value is passed to the device.
IoT (Internet of Things) devices are usually small devices with simple functionality, where the main importance is their interconnection in the network and automation of their communication with each other. Some IoT devices are equipped with sensors and send data from these sensors to the network (e.g. a thermometer or more complex weather station, smoke detector, light detector, etc.). Other devices can be used to interact with a user (screen, controller), or act as a central controller (broker) or router.
Networks of IoT devices are a typical example of synergy: very simple devices can, when properly connected, form a relatively smart system. For example, a change in the state of a thermometer can have the efect of switching the heating on or of and opening the windows to ensure the room is at the right temperature. Smart bulbs can also have the intensity and colour of light adapted to the phase of day and the amount of sunlight according to the current weather.
In [
Most IoT devices are battery powered, so their operation must not be energy intensive, including communication. Some devices use Wi-Fi, but there are other options. Figure 3 outlines the communication architecture typical of IoT devices.
The bottom layer contains transmission technologies that determine how data is transformed into a signal, how the signal is handled (frequency, bandwidth, etc.), how the connection is established, etc. As we can see, some IoT devices handle Wi-Fi, Ethernet or LTE just like laptops or cell phones, but there are other possibilities.
RFID/NFC is designed for communication over very short distances (about 10 cm) between a pair of devices. Bluetooth and its optimized form BLE (Bluetooth Low Energy) are used to connect two devices over longer distances (tens of meters), especially the BLE variant is much more energy-eficient than Wi-Fi.
IEEE 802.15.4 (Low-Rate Wireless Personal Area Networks) is a communication standard optimized for wireless sensor networks, and is the basis for various higher-layer technologies designed especially for M2M (Machine-to-Machine) communication. This can be seen in the figure: the 6LoWPAN and
P T T T T Q H M
TLS TCP
PPXM SDD oPAC .SN. N.TMP,P,
UDP e e B g i Z
ii-FW ttreenh I/FFCDN
E R
LET ,LETBB (LR8-0IW2E.E1PE5A.4Ns)
N
A
W
a
R
o
L
ZigBee technologies are typical examples. Besides other features, 6LoWPAN (IPv6 over Low-power
Wireless Personal Area Networks) adds a very compact header (metadata) format to avoid having to
transfer too much extra data.[
IPv4, IPv6, ICMP, IPSec, TCP, UDP, NTP, and SNMP are common network protocols that provide addressing, connectivity, higher-layer protocol identification, time synchronization, network management, and other functions; their description is beyond the scope of this paper. The TLS and DTLS protocols are used to encrypt connections. Details can be found e.g. on http://tcpipguide.com/free/t_ NetworkingFundamentals.htm [2025-07-09].
ZigBee [
Nowadays, Thread and Matter protocols are very popular in the IoT world. The Thread protocol is based on (heaps) some of the protocols mentioned above: it works on top of IEEE 802.15.4 and includes IPv6, 6LoWPAN, UDP, DTL and CoAP, among others.1 Therefore, we do not need to deal with the Thread protocol separately.
Matter is one of the application layer protocols. Matter is often combined with the Thread protocol in devices, although it can also work with other protocols such as Wi-Fi or BLE. This protocol assumes a centralized network and has a relatively complex communication architecture. The interaction between devices is called a transaction and can be of type Read, Write, Subscribe, Report or Invoke.2
There are several basic communication models [
Request-Response communication model. This communication model is based on how common computer networks work: the client sends a request for data, the server processes it and sends a response with the data. 1Details can be found at https://www.silabs.com/documents/public/user-guides/ug103-11-fundamentals-thread.pdf [2025-0818]. 2Details can be found at https://csa-iot.org/wp-content/uploads/2024/11/24-27349-006_Matter-1.4-Core-Specification.pdf [2025-08-18], especially Chapter 8.
This model does not require the existence of a special device as an intermediary. A device on the network can play both client and server roles as needed in relation to other devices inside the network, but the roles within a single communication are strictly defined.
Some protocols using this model require establishing a connection at the beginning (negotiating connection parameters, etc.) and terminating the connection at the end of the communication, while others simply allow a request to be sent and a response to be returned without establishing a connection. Publish-Subscribe communication model. When using this communication model, there is usually a central device (broker, dispatcher, controller) in the network that mediates the communication and manages the queues with the forwarded data.
Publisher
Broker
Subscriber
Publishers are nodes in the network serving as data sources, subscribers are nodes serving as data destinations.
The data always belongs to a category (called a topic), which is usually related to the type and origin of the data. E.g. there may be a topic for the temperature from a thermometer outside on the north side of the house.
Publishers send the pairs (topic,data) to the broker (whether once or on a regular basis). Any device can subscribe to a topic from the broker, and the broker then forwards everything it receives on that topic to that device.
The broker therefore performs several roles: it maintains queues for individual topics containing published data, receives publish messages, processes subscription orders for topics (subscribe messages) and sends published data according to these subscriptions.
A simplified version of this model (the Publish model, [ 17]) does not require the existence of a broker. The role of the broker is then partially taken over by publishers themselves, subscribers order subscriptions directly from publishers.
Our goal is to determine the relationship between the concept of IR Colonies and the protocols used in the IoT world and to analyze the possibilities of implementing IR Colonies in IoT device networks. In this section, we identify areas that need to be considered for this purpose.
There are two levels in the use of IR Colonies: the first level is the use of IR Colonies in simulating a network of IoT devices, for example, to plan such a network and to verify the connectivity and communication possibilities between devices. This plan is almost implementation independent of the actual hardware, we just need to take into account certain characteristics and possible limitations of the actual devices we want to simulate. We can develop this system either in a common programming language (C++, Java, Python, C#, . . . ), or in a language designed for membrane systems (but IR Colonies are probably too specific for such languages). Or we can use IR Colonies only for the theoretical design of the IoT system; programming is not necessary in this case.
The second level is the transfer of the design created in this way to the real world. Here we have to take into account the specifics of both the IoT devices themselves and the protocols that will be used to ensure communication between them.
The problem of implementation can be divided into several parts: 1. Linking to sensors inside the device, i.e. getting an object (or a property of an existing object) into the agent state (e.g. for a thermometer, pressure sensor, light detector, etc.) or, conversely, transferring an object (or its property) from the agent state to an actuator, a visualizer or other component (e.g. a motor for opening/closing a window, a smart bulb, a display). 2. Working with states containing objects inside the agents, implementing programs/rules including working with reactants and inhibitors. 3. Identification of individual agents, communication between agents within the IR Colony. 4. Communication with the outside world (cloud, Internet services).
We will discuss in detail each of the items listed above.
Item 1: Each type of device has a specific way of accessing sensors and various other components; there is no space for the implementation details in this paper.
Item 2: The agents themselves can be developed quite easily in any programming language supported by the given IoT devices. And if the chosen programming language allows it, we can use e.g. the object paradigm (we use objects in IR Colonies) and event-driven code. Working with reactants and inhibitors in programs is very easy to program, they are simple conditions. We can use state-driven programming (i.e. the software design pattern “state”) as in the implementation of finite automata, which can be easily combined with the event-driven programming mentioned above.
Also, programming both the evolution and deletion rules that are related only to the agent’s state, and operations on that state in general, will not be a problem. Other rules already require communication with other agents, so their application depends on the communication protocol used (see item 3 below). Item 3: This implementation step depends on the chosen IoT application protocol (or protocols— nothing hinders us from making IR Colony compatible with multiple protocols at the same time). We are not forced to code the protocols themselves (there are ready-made libraries for that), but we need the communication model in IR Colony to match the communication model of the given protocol: • possible roles of devices, identifying the devices in communication, • identifying the device state, data format for data exchange, • establishing and terminating connection and acknowledging (if it is applied at all), • requesting and sending data, sending unsolicited data, • subscribing data to be sent periodically, etc.
The implementation of most rules in programs depends on this item because this is the communication between agents or between an agent and the environment.
Item 4: For this item, predefined APIs (Application Programming Interfaces) of individual services are usually used, including the IFTTT service3 communicating with devices from diferent vendors. We will not address this issue here.
It follows from this list that we will deal in particular with item 3 subsequently. Let us focus on the two communication models mentioned above. For each model we will be interested in the following: • requirements for the structure of both the IR Colony and the IoT network, • identification of communicating devices if needed in messages, addressing, other IDs, • implementation of rules in agents’ programs, • the possibility of implementing an IR Colony environment.
Currently, almost any IoT network can only be accessed by a device that is equipped with an identifier and login credentials, which is handled by the IoT protocol itself (especially when connecting the device to the network) and we don’t need to deal with that here. Except when the device ID, address, etc. are part of the messages being sent—in that case, we can use objects with the appropriate data.
There is no central device in the Request-Response model and anyone can request data or service from anyone else, which corresponds to the unrestricted graph structure used in IR Colonies. Thus, the structure of an IR Colony can be easily converted to the structure of devices using this communication model and vice versa; we only need to have a device in the network acting as an IR Colony environment, as will be explained later.
The use of the Request-Response communication model assumes that the client is capable of identifying the server before the communication begins. Conversely, the server can determine the client’s identification after receiving the request and then use it to send an addressed response. Communication in an IR Colony is between agents that are connected by an edge. Identification needs to be addressed first of all when creating an edge, which in a real network will be handled by the IoT protocols themselves: creating an edge corresponds to establishing a connection between devices, resolving identification, permissions, etc. Something else is addressing in messages in a previously established connection, which is implementation dependent and will be handled according to a specific protocol. The client can be informed of the servers’ addresses via objects and their properties.
But the problem is something else: IR Colonies are built mainly on unaddressed multicast communication (the multicast rule for sending data to connected agents) and other unaddressed rules (the backup and restoration rules for transferring data between agent and environment, the programming rule for sending programs to agents via repository in the environment). Most Request-Response protocols, such as HTTP REST, do not support multicast (one-to-many) communication; they use only unicast (one-to-one) type. Thus, we will need to simulate multicast communication using a sequence of unicast connections.
The Request-Response model strictly adheres to the roles of the client and server, with the server being the source of the data or service and the client starting the communication, we relate • the start of the (multicast) communication to the process of creating a sequence of oriented edges leading from the agent containing the multicast rule to the agents that are supposed to obtain the data in this way, • the creation of such edge will correspond to the pair of operations establishing connection plus
Request (or Bulk Request), with respect to real functions of the specific protocol, • the Response operation, and • the removal of the edge to the operation terminating the connection.
The role of the environment will probably be fulfilled by some equipment, because the environment objects and the program repository for the products of program rules must also be stored somewhere. Therefore, the above will also apply to rules for communicating with the environment (backup, restoration and programming rules).
In IR colonies, each agent should periodically check the environment’s rule repository for a rule intended for them ( e.g. an update to one of their existing rules). This step can be implemented by requesting the device acting as the environment. The new rule will then be sent in response to this request.
The use of the Publish-Subscribe model assumes a centralized network: there is a central equipment (broker) to which all publishers send data. This data is sorted and stored in queues for individual topics, then subscribers subscribe to a specific topic and then data from the corresponding queue is sent to the given subscriber.
Thus, the graph of the IR Colony must be in the form of a star: the main node of the graph will be the device acting as a broker, while the other devices are connected to it and have the role of publishers and subscribers as needed. If we have an IR colony in the form of a generic graph, transforming it into star form will not be a problem, we just need to add more objects with information about the original connection.
A single device can act in the both roles, but for diferent topics. If the device is only acting as a publisher, it will be connected to the broker by a directed edge pointing towards the broker. Subscribers will be connected by a directed edge pointing away from the broker. If a device performs both roles, the edge will be traversable in both directions. Alternatively, we can use an undirected graph and in the IR Colony we would use the mechanism of reactants and inhibitors to sort messages. We have to use this mechanism anyway, because every device/agent will certainly not want to get all messages, but only those belonging to specific topics.
Protocols implementing this communication model also use IDs, addresses and login credentials, but we can leave that up to the protocol. There are usually special message types for establishing and terminating connections, and we can also use these to dynamically create and destroy edges in the graph.
Compared to the previous model, there is a mandatory identification of the message type, called topics. Topics are part of diferent message types (especially publish and subscribe). In IR Colonies we use objects (topics) and their properties (values sent within the topic) for this purpose.
The basic rule for communication between agents is the multicast rule. Since we will require a star graph structure for the IR Colony, the publisher will only send a message to the broker when using this rule. The broker will then send a multicast to all subscribers registered to the topic, according to its subscriber database (which can be object-based, which is more equivalent to an IR Colony). When switching from an IR colony to the real world, some of the functionality of the programs will be transferred from the agent/publisher to the agent/broker.
The role of the IR Colony environment will be played by the broker. This will make it easy to implement rules for data transfer between an agent and the environment (backup and restoration rule). The broker will also maintain the rule repository, so the implementation of the programming rule will consist of passing a new rule to the broker, which will store the rule in the repository. All agents will contact the broker periodically to ask for new applicable rules (updates).
From Figure 3 it is clear that there are many IoT protocols in the application layer (although we have selected only the most common protocols). For each of the listed protocols we will specify the possibilities of its cooperation with the IR Colony concept.
Some IoT devices communicate with their environment using the HTTP protocol, which is commonly known from WWW communication, or rather its modified variant HTTP REST (Representational State Transfer Protocol) standardized by IETF. The advantage is especially the possibility of direct interaction with common web services and servers.
HTTP REST [
In particular, the Put method is very practical for our purposes (for all rules intended for communication between agents, or an agent and the environment), because it is idempotent4, i.e. if the agent/client is sending a message using this method repeatedly with the same object and identical property, there is no change (it corresponds to one message), whereas if the Put method is sent sequentially with diferent objects and/or properties, the object and the property in the destination are updated. Or the object is created if it does not exist in the destination yet.
HTTP REST can, among other things, send data in JSON text format, which is suitable for representation of objects used in IR Colonies.
Suppose an agent containing a temperature sensor executes a program containing the following rule: out →− Among other objects, the agent also has a object with the property 22.4 in its state. The purpose of the rule is to send the current state of the temperature sensor to all the nodes in the IR Colony graph that are destinations of edges leading from this agent.
Because HTTP REST must always establish a unicast connection, the original multicast message has to be decomposed into a series of unicast messages (each with a diferent receiver) and each message specifies the destination device. For the first listed example, one of the destinations could be a display device.
The IoT device, which is a real-world representation of this agent, sends the PUT Requests to all devices with an edge leading from it, including the display device (assuming that the connection between the devices has already been established): PUT /agent/display HTTP 2.0 Accept: application/json Content-type: application/json ... { } "name": "temp"; "property": "22.4"; ... and in the body of the message is the following message in the JSON format:
This Request is followed by a Reply acknowledging acceptance of the message.
4.2. MQTT
MQTT (Message Queuing Telemetry Transport, [
MQTT has several other specific features that are very practical especially for IoT devices. One of them is “Last Will and Testament Message”: a special type of message stored at the broker that is sent to all subscribers of a particular publisher when the network loses connection to that publisher.
The objects that we send between agents within IR Colony will be represented in MQTT by topics. For example, the object used in the first listed example will be represented by a topic with the same name, and the agent publishing this topic will send a Publish message to the broker with the current temperature value belonging to the topic named . The broker will forward this message to all nodes that have subscribed the given topic.
Message data are in plain text format, structured formats such as JSON or XML are not supported. However, in our case it doesn’t matter, because in MQTT messages there are fields for topic and value, we don’t actually need fields for the message data itself.
The format of the MQTT message header5 is quite complicated. Besides determining the message type (such as “PUT” in HTTP REST), there are, among others, several control bits that specify how some of the more advanced MQTT properties are set. In the Publish message, the topic name, property value, and accompanying plain text message data are present.
CoAP (Constrained Application Protocol, [20]), standardized by the IETF, does not require a connection to be established; messages are simply sent to the destination. As a result, there is no problem with sending multicast messages. CoAP uses a Request-Response architecture, and there are even implementations with a REST architecture (CoAP REST). Most of what was said above about HTTP REST applies to this protocol, except that multicast messages do not need to be serialized and creating an edge does not need to be bound to connection establishment.
AMQP (Advanced Message Queueing Protocol, [17, 20]) is quite similar to MQTT. It is also standardized by OASIS and uses a Publish-Subscribe communication architecture, but the use of a central component (broker) is optional. If a broker exists in the network, it maintains a message queue separately for each subscriber, and subscribers take messages from their queues themselves (unlike MQTT, which forwards messages from publishers directly to subscribers). Thus, AMQP allows several types of connections to be established: client-broker (the same type as MQTT), client-client and broker-broker.
XMPP (eXtensible Message and Presence Protocol, [
DDS (Data Distribution Service, [20]) defined by OMG uses the Publish-Subscribe communication model and is decentralized. This means that the individual devices in the network are much more autonomous than in other Publish-Subscribe protocols, there is no broker in DDS. Instead, a GDS (Global Data Space) is defined: GDS is a kind of virtual space to which all publishers and subscribers connect and where messages are passed. In relation to IR Colonies, the GDS principle resembles a shared system environment in which all agents are located. 5https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901100 [2025-07-17]
There are many application protocols designed for use in IoT networks (more than listed here, we’ve only covered the most common ones), but there are some similarities between them, which makes it easier to access them a bit more uniformly.
The individual protocols use either the Publish-Subscribe (MQTT, AMQP, XMPP, DDS) and/or Request-Response (HTTP REST, CoAP, XMPP) communication model with some specifics. There are diferences, for example, in whether a connection needs to be established to send a message or the message can be sent directly without an “introduction”, there are also diferences in the types of supported messages.
We have only discussed the HTTP REST and MQTT protocols in detail, but the other protocols mentioned in the previous subsection are quite similar in handling.
It has turned out that IR Colony rules used to communicate with other agents or the environment can be implemented using both HTTP REST and MQTT protocols, although it is advisable to take this relationship into account when designing the IR Colony structure: either by creating specific objects to identify the communicating parties or, in the case of the Publish-Subscribe model, by modifying the structure of the IR Colony graph into a star shape with a central device, if any central device is to be used (the central device, the broker, is required for the MQTT protocol, other Publish-Subscribe protocols do not require or even assume any broker).
In terms of these protocols, the IR Colony environment can be implemented as a separate device or as part of the functionality of a central device.
The purpose of this paper was to analyze the relevance of the IR Colony concept with respect to real-world applications in the IoT device world and to identify potential limits to its applicability. IR Colonies were directly designed to model the events in a network of IoT devices, thus no major problems were expected. However, it should be taken into account that there are a number of IoT protocols with specific communication architectures, supported messages and other features.
At the beginning of Section 3, we outlined the individual steps in implementing the IR Colony concept into real-world IoT device networks. There are a total of four areas to consider: the first area concerns communication with the hardware inside device, the second one concerns operations inside the IoT device (or agent in the IR Colony), the third one involves communication between IoT devices (agents) with each other, and the fourth area relates to communication with the rest of the world (e.g. web services or other networks). Of these items, we have focused on the third one, i.e., communication between IoT devices, because this is where compatibility with IoT-designed communication protocols will need to be considered.
Section 4 explores these protocols specifically, focusing on two of them in particular, and for the others we have only taken their similarities with the first two protocols. The IoT world originally started in chaos, with each vendor going its own way, and it was only later that interoperability between devices from diferent vendors started to be considered, hence the existence of a number of IoT application protocols.
It turns out that for the purpose of implementation it will not be necessary to make significant changes to the IR Colonies, only future implementation will need to be taken into account when proposing a specific IR Colony (existence of objects for device identification purposes, modification of the IR Colony graph). The role of the environment also needs to be ensured. Each of the protocols requires a slightly diferent approach, but on the whole these approaches are quite compatible with each other. The concept of a shared virtual space GDS used by the DDS protocol is interesting as well, resembling the IR Colonies environment.
It would be advisable not to restrict ourselves to a single IoT application protocol and instead consider the possibility of cooperating with several diferent protocols, because, despite their diferences, we can ifnd common features.
In subsequent research, we intend to use the results presented above to work on implementing the IR Colonies concept into the real world of IoT devices.
During the preparation of this work, the author used Grammar Checker (https://www.grammarcheck. net/editor/) in order to: Grammar and spelling check. After using this service, the author reviewed and edited the content as needed and takes full responsibility for the publication’s content. [17] T. Domínguez-Bolaño, O. Campos, V. Barral, C. J. Escudero, J. A. García-Naya, An overview of IoT architectures, technologies, and existing open-source projects, Internet of Things 20 (2022). URL: https://www.sciencedirect.com/science/article/pii/S254266052200107X. doi:https: //doi.org/10.1016/j.iot.2022.100626. [18] IEEE Standard for Low-Rate Wireless Networks, IEEE Std 802.15.4-2024 (Revision of IEEE Std 802.15.4-2020) (2024) 1–967. doi:10.1109/IEEESTD.2024.10794632. [19] J. P. Dias, A. Restivo, H. S. Ferreira, Designing and constructing internet-of-things systems: An overview of the ecosystem, Internet of Things 19 (2022) 100529. URL: https://www. sciencedirect.com/science/article/pii/S2542660522000312. doi:https://doi.org/10.1016/j. iot.2022.100529. [20] J. Dizdarević, F. Carpio, A. Jukan, X. Masip-Bruin, A Survey of Communication Protocols for Internet of Things and Related Challenges of Fog and Cloud Computing Integration, Association for Computing Machinery 51 (2019). URL: https://doi.org/10.1145/3292674. doi:10.1145/3292674.