Estructura y Metodología

Themessage-transport service (MTS)is a core element of theFIPAinfrastructure and it handles letters, i.e., FIPA messages which are wrapped into an envelope. A set of MTSestablishes a high-level communication bus, which can transport arbitrary content. The envelope provides only the information to theMTSwhich is needed to take the correct routing decision for this letter, so that is can be transmitted to a given recipient. The use of an envelope allows to avoid a potentially costly processing of large messages or transport of encrypted messages. Since message as well as envelopes have different representations which are listed in Table5.3, this can have a significant influence on the performance of the communication. This is shown in Section5.3.

Table 5.3:FIPA representations.

Element Representation types message bit-efficient, XML, string envelope bit-efficient, XML

TheMTSeither delivers a letter to its locally attached client agents, or redirects a letter to an- otherMTS, which serves as communication endpoint for the recipient agents. The information about the communication endpoint is extracted from theDSD, which maintains a mapping be- tween agents and communication endpoints. The protocol for the transport of letters between two agents is exchangeable, such that the communication endpoint represents a transport pro- tocol specific access to an MTS. The DSD contains all active communication endpoints for a singleMTS. To deliver a sender agent’s message to another client, the client agent firstly wraps a message into an envelope and forwards the resulting letter to the localMTS. TheMTS re- quires at least one given recipient. This recipient can also be specified by a regular expression which is matched against the entries in theDSD. Thereby, a simple mechanism for broadcast- ing and multicasting is introduced which is not defined in any standard. This feature can be exploited for a topic-based communication in a multi-agent network.

The implementation supports two types of transport protocols: the connection orientedTrans- mission Control Protocol (TCP)and theUser Datagram Protocol (UDP)-based high-bandwidth protocol UDT (Gu and Grossman 2007). The standardUDP protocol is connection less and packets are limited to a maximum size of 65535 bytes.UDPis used for communication of data which has to be rather most recent, than complete. Although UDT usesUDPit still allows for a reliable transport of messages and these message can exceed the maximumUDPpacket size.

Interaction Protocols & Error Reporting

Standard communication approaches in robotic frameworks use a simple forwarding of data. Stateful communication can only be achieved with a custom solution or add-ons to these frame- works. The use of interaction protocols as suggested by FIPA adds a general way to struc- ture communication using the performative field of FIPA messages. An interaction proto- col therefore describes a message flow using a state transition system ∑ = (S, P , R, γ), where

S = {s0, s1, . . .} is the set of state in a conversation , P = {accept-proposal, agree, . . . } is the set of performatives, and R = {r1, r2, . . .} is the set of conversation roles. When the protocol is matched with a real conversation, each role maps to an agent and the minimal protocol definition re- quires at least a sender and receiver label. Appendix Hshows some details on the represen- tation of interaction protocols. The use of interaction protocols allows to verify distributed communication online, e.g., such as agreement procedures. It can thereby increase the ro- bustness of distributed control approaches. For that purpose a conversation monitor has been added (cf. (Roehr and Herfert2016)) which validates the conformance to a requested interac- tion protocol. Each protocol’s flow can be interpreted according the current agent’s role in this conversation.

Errors in the communication path can be reported back to a sender, so that the framework establishes a non-nominal feedback channel for high-level communication similar to theFRM. Figure5.3shows the nominal message flow, which involves the following steps at the sender’s

side: encoding of the message in one of the representation formats (XML, String or bit-efficient), wrapping of the encoded message into an envelope, encoding of the resulting letter in one of the representation formats (XML or bit-efficient) and handover to aMTS. The MTS decodes only the envelope to extract receiver information and to add its stamp, before trying to deliver it to theMTSwhich has been registered for the receiver. The transport between twoMTSre- quires letter serialisation according to the representation format. At the receiver site, the letter is decoded, so that the encoded message can be extracted and decoded.

Figure 5.3: The nominal message flow. Note that for each agent there might be multiple com- ponents which act as sender or receiver.

Figure 5.4 illustrates the reporting of a failed delivery, i.e., when the intended receiver of a message is not available. Since the number available agents in a distributed system might change ad-hoc, an error reporting infrastructure is mandatory for a robust control approach. Corresponding interaction protocols can account for the dynamic removal of agents.

Since letters could start looping between two MTS, theFIPA standard prevents a looping of letters by marking each outgoing letter with anMTSspecific stamp. Already stamped letters can be safely discarded by anMTS. Before a sender is notified about a failed delivery, all active transport protocols are tried. Only if all transports protocols have failed an error is reported back to the original sender of the message. When the originator has also become unavailable in the meantime, the error report is discarded by theMTSwhich detects the originator to be missing.

Figure 5.4: Error reporting back to a message’s sender is automatically triggered by anMTS, when the message delivery fails.

TheMTSimplementation ideally connects allMTSsto a peer-2-peer communication network, but the communication range of individual agents might be limited so that a direct connec- tion between some agents cannot be established. The implementation of a routing mecha- nism across multiple MTS is one feasible approach to create a mesh-based communication. The selected solution, however, does not enable mesh based communication at the applica- tion layer (layer 7), but on the data link layer (layer 2) by using the protocol B.A.T.M.A.N. Advanced (Open-mesh2012). Since this protocol operates at layer 2 of the ISO/OSI network model it can be transparently added to any IP-based communication.

Channel-based Communication

The standardFIPAACL accounts for topic-related discussions between multiple agents, and a particular topic can be identified via the message fieldconversation id. This approach allows

agents to filter communication, and facilitates to correctly redirect or process communication. This conversation-based filtering is part of an internal processing chain, but theMTSimple- mentation allows an additionally separation of communication into communication channel. EachMTSallows the registration of so-called local receivers. A local receiver typically resides on the same physical machine as theMTS. Each receiver can be viewed as particular communi- cation processors within a single agent. One agent can have multiple communication proces- sors which are all identifiable by name. The communication endpoint for each communication processor is defined by a named output port of theMTS. This output port is dynamically cre- ated upon association with anMTS. A corresponding service entry is be added to theDSD. The naming of the output ports of the MTSshould follow a policy: <agent-name><suffix>. This policy is suggested since the MTS allows for multicasting based on receiver name patterns, e.g., all messages to ’.*-processor-0’ are forwarded to all agents which have anMTSport with a matching name. Hence, the communication system can be used to define an arbitrary number of communication channels and topic groups.

Figure 5.5:Channel-based communication withMTS.