# Developing Algorithms for the Internet of Flying Things Through Environments
With Varying Degrees of Realism - Extended Version

Thiago de Souza Lamenza
Department of Informatics
Pontifícia Universidade Católica do Rio de Janeiro
Rio de Janeiro, Brazil
<EMAIL_ADDRESS>
Josef Kamysek
Department of Informatics
Pontifícia Universidade Católica do Rio de Janeiro
Rio de Janeiro, Brazil
<EMAIL_ADDRESS>
Bruno José Olivieri de Souza
Department of Informatics
Pontifícia Universidade Católica do Rio de Janeiro
Rio de Janeiro, Brazil
<EMAIL_ADDRESS>
Markus Endler
Department of Informatics
Pontifícia Universidade Católica do Rio de Janeiro
Rio de Janeiro, Brazil
<EMAIL_ADDRESS>

###### Abstract

This work discusses the benefits of having multiple simulated environments
with different degrees of realism for the development of algorithms in
scenarios populated by autonomous nodes capable of communication and mobility.
This approach aids the development experience and generates robust algorithms.
It also proposes GrADyS-SIM NextGen as a solution that enables development on
a single programming language and toolset over multiple environments with
varying levels of realism. Finally, we illustrate the usefulness of this
approach with a toy problem that makes use of the simulation framework, taking
advantage of the proposed environments to iteratively develop a robust
solution.

##  1 Introduction

When working with the development of distributed systems populated by
autonomous nodes capable of movement, you end up dealing with networking and
mobility, which highly affect the algorithm’s performance and behavior [1].
Algorithms running in these environments require specialized features to
achieve a desired level of robustness. The importance of these features
doesn’t become apparent until the algorithm is exposed to the conditions that
motivate them. The process necessary to create and validate these systems very
time-consuming and monetarily draining when reliant on field tests. For these
reasons, using a simulated environment to aid the research and creation
processes is essential. Simulation is a common approach to implementing
solutions to problems in these scenarios [2] [3] [4].

Representing the real world in a simulated environment is very important as it
exposes the algorithms to scenarios and challenges it will encounter in a
final deployment without incurring the costs of field tests. Fidelity is key
here, the robustness of an algorithm in development inside a simulation is
directly proportional to the amount of real world conditions that can be
thrown at it, motivating the addition of features that bypass issues that
arise from the conditions it was exposed to.

One of the ways to tackle the development of these algorithms is through an
empirical and iterative process of development and evaluation. The concept of
incremental and iterative development is not new and is popular in software
engineering in general. Representing and simulating too many specific aspects
of the real world at the same time hinders the development process, which
should start simple in an environment with most of it abstracted away and
gradually introduce realism until the desired requirement of robustness is
achieved. The increment in realism comes at a cost because with the increase
in complexity of the simulation software, the development experience tends to
deteriorate. A realistic simulation has a heavy computational cost that adds a
bigger overhead to the execution of simulation scenarios, slowing down the
development process. The complexity of the software also comes with other
disadvantages as they tend to be harder to set up, have a steeper learning
curve and be very specialized, making it hard to write code that translates
well to other environment and the real world.

This work presents _GrADyS-SIM NextGen_ , a framework for simulating
distributed algorithms in a simulated network environment populated by nodes
capable of communication and mobility. A short video showcase of the simulator
is available 111https://youtu.be/vixp_CicbJk.There are ample use cases for a
simulator like this. Examples are simulating systems where unmanned aerial
vehicles communicate with stationary sensors, the simulation of UAV formations
that rely on communication to maintain a desired configuration, predator and
prey scenarios and many more. The simulator presented in this work is not
unique in the area of simulating networks of UAVs [5] and work has been done
in compiling comprehensive lists of existing options [6] [7]. GrADyS-SIM
NextGen distinguishes itself from the rest for its philosophy of encouraging
the iterative and empirical approach proposed in this work.

That main distinguishing factor manifests itself with the proposal of a
general and environment agnostic way of implementing distributed algorithms
that can run in different simulated environments and, in principle, in the
real world. This has several benefits, the main of which are the lowering of
the learning curve for the framework since only one interface has to be
learned for algorithm development and the removal of the effort required to
translate code between different environments with different requirements.
Having a common interface also enables the creation of tooling that improves
the experience of creating distributed algorithms.

The framework enables you to create artifacts called _protocols_ which, using
Python, implement the logic that powers individual nodes. These Python
protocols can be used in a simple Python simulation environment, which we call
_prototype-mode_. Users can also run them in _integrated-mode_ which will
integrate with OMNeT++, an event-based network simulator, to simulate
realistic network interactions and even integrate it with SITL through the use
of MAVSIMNET 222https://github.com/Thlamz/MAVSIMNET which provides a realistic
mobility models representing several vehicle types. Finally, these protocols
can be used to control real-world vehicles in what we call _experiment-mode_ ,
although this last execution mode is currently not implemented yet. The main
appeal of the framework is that no code changes need to be made to the
protocol itself when switching between these modes, making the knowledge
obtained in a simulation environment easily transferable to another or to the
real world.

This is a continuation of _GrADyS-SIM_ [8] with which it shares its main
objectives. The creation of this new simulation framework based on GrADyS-SIM
was motivated by our experience in previous works, feedback from both within
the team and from external users, and the realization that our current
framework at the time made translating our simulated implementations to real-
life for experiments very hard.

The software was created as part of the GrADyS [9] (Ground-and-Air Dynamic
sensor networkS) project. One of the project’s main interests is investigating
the use of autonomous aerial vehicles in data collection scenarios, such as
remote or dangerous areas not easily accessible by people. GrADyS-SIM was
developed as a simulation tool for the project first and foremost, its general
usage was limited. A more general and user-focused approach is being taken
with GrADyS-SIM NextGen without losing its utility to the project.

This paper is organized as follows. In section 2 we will discuss the concepts
that guided the framework’s implementation. Section 3 the framework’s
components will be presented in a lower level. In section 4 a demonstration of
the usage of GrADyS-SIM NextGen is presented as empirical evidence that the
proposed development approach has tangible benefits for algorithm development.

##  2 Motivation

The GrADyS-SIM simulator was used in several projects internal to the GrADyS
team and by some external users. A common pain point observed by both of these
groups was the difficulty of setting up and using OMNeT++
333https://omnetpp.org/ and its component library INET
444https://inet.omnetpp.org/. OMNeT++ is absolutely essential to the project
for its network simulation capabilities but using it comes with a couple of
downsides. It is a very large piece of software, even the IDE it comes
packaged with is slow even on modern machines, build times and even simple
tasks like checking a function’s usages in code take a while making
development inconvenient. Its complex structure and ample set of features
means that it has a steep learning curve and many possible points of failure.
These failures are not always easy to debug, in fact a significant portion of
the simulator user’s effort is spent doing exactly that. To top it off, it is
not trivial to set up on modern machines, often leading to users ending up
with broken or incomplete installations. These factors combined discourage
potential users, even ones internal to the team.

Dropping support for OMNeT++ was not an option. As stated, its features are
essential to running realistic simulations in the project. Having it as a
requirement was also undesired because as long as people have to use it, the
bar of entry for our simulation framework will always be high. A solution was
devised that satisfies both requirements adequately. OMNeT++ would no longer
be a requirement to run this new version of the simulation framework. Instead,
it would be an optional dependency if the user desired a realistic network
simulation. How this would be achieved is related to another one of this
work’s guiding concepts.

GrADyS-SIM is based on OMNeT++ which uses C++ as its implementation language.
The project’s real world testbed uses Python to implement node behavior. This
means that anything developed inside the simulation would then need to be
translated into Python, potentially introducing errors and requiring more
development time. This led to the choice of Python as the language in which
protocol logic would be written in. It is a convenient language with a low
learning curve, which is both attractive to newcomers and compatible with our
testbed. It’s also easy to integrate in C/C++ code, making interoperability
with OMNeT++ achievable.

Having a single language to define the algorithms doesn’t come close to
solving all problems. First, there is no guarantee that the same code will
work on all the required environments, with their own set of requirements.
Also, having protocols written in Python doesn’t make the simulation framework
much easier to use, as users will still need to deal with OMNeT++ as the
simulation software. Two more decisions were made to guarantee the framework
would meet its requirements, an environment agnostic interface for defining
protocols was needed and a simpler simulation environment for cases where
OMNeT++ wasn’t necessary.

The protocol interface was created to serve as an environment-agnostic
interface to implement algorithms. Code that uses it should be able to run in
any environment supported by the framework, be it simulated or real. It
establishes a well-defined set of rules a protocol should follow in order to
be compliant with the interface and enjoy the benefits of being decoupled from
their environment. The main benefit is reducing or even removing the effort
required to adapt them to new environments. This reduces the overhead required
when moving tests between simulated environments and the real world.

Reduced overhead is not the only benefit of following the protocol interface.
Having a generalized API that protocols adhere to enable the creation of a
toolset dedicated to aiding the creation of new protocols. Repetitive
boilerplate work is required when creating new protocols and has to be re-
implemented every time a new protocol needs to use it. Without a standard
interface, protocol code is not easily reusable. It’s not that creating tools
to reduce this repetitive work isn’t possible, but the incentive to do so
isn’t big because any code would need to be adapted when the simulation’s
characteristics changed. With a generic interface established, tools no longer
need to be adapted to new situations because they use the same features
available to the protocols themselves through the protocol interface. A set of
tools is provided with the simulator for common tasks like implementing
leader-follower mobility, random mobility and a mobility that follows a
mission. The fact that most of the plugins are related to mobility are merely
coincidental, the possible use cases are far wider.

The last of the requirements to be fulfilled is reducing the barrier of entry
by making the simulation framework easier to install, understand and
experiment with. This was achieved by creating a new environment, protocols
running in this mode are said to be running in _prototype-mode_. This
environment consists of a Python event-based simulator created specifically
for the simulation framework. It is trivial to install, light on dependencies
and works on Python version 3.8 or higher.

Python’s simple syntax combined with the simplicity of the simulator provides
a good starting point for people unfamiliar not only with the project but with
how an event-based simulator works and how it can assist you in implementing
network simulations. This comes at the cost of fidelity. The prototype-mode
simulator lacks almost all the features that OMNeT++ has, providing only the
absolute basics. The intention of prototype-mode is being an accessible and
simple environment where simulations are quick to set up and run. Development
is an iterative process, and having an environment that reduces the overhead
of running experiments is a great luxury. Also, when users are in the early
stages of developing a new algorithm, having access to a realistic network and
mobility simulation is not very important, testing the functionality of a
protocol on a simpler environment is more than adequate.

When users are done with their prototypes, they can still use OMNeT++ to
perform realistic simulations, just like the last version of the framework.
The same exact protocol code can be used on both environments, prototype-mode
and integrated-mode. Work was also employed into making the setup of OMNeT++
easier. It is still the harder of the two simulation environments to set up,
specially as the python integration adds some complexity to the setup. The
docker container provided in the repository’s documentation should at least
alleviate the pain of setting it up.

##  3 Architecture

Figure 1: Framework’s architecture

GrADyS-SIM NextGen is a simulation framework with several components. All
components are publicly available and open-source. The framework is
distributed in three GitHub repositories, _gradys-sim-nextgen_
555https://github.com/Project-GrADyS/gradys-sim-nextgen contains the python
components of the framework including the protocol library and the python
simulator, _gradys-sim-visualization_ 666https://github.com/Project-
GrADyS/gradys-sim-nextgen-visualization hosts the visualization website for
python simulations and _gradys-simulations_ 777https://github.com/Project-
GrADyS/gradys-simulations hosts the OMNeT++ components of the framework and
the integration with Ardupilot’s SITL 888https://ardupilot.org/. The
documentation for each of these components is also hosted in their own
repositories.

There are three main ways of running simulations in the framework. The first
one is implementing your algorithms using the protocol library and running
them in the python simulator. Using this scheme, you will have access to all
protocol features while running in a simplified environment with low
implementation overhead and fast execution times. It is ideal for prototyping
and quick development. Optionally, you can use the web visualizer when running
simulations like this. When looking for more serious results using the same
code base, one can try integrating with OMNeT++ and running your code built on
the protocol library in the OMNeT++ simulated environment. Lastly, building
simulations completely in OMNeT++ is still supported, you will be creating all
your code in C++ and won’t be able to use it elsewhere. Both options that use
OMNeT++ can optionally integrate with the Ardupilot SITL Simulator for a
better mobility model.

In the rest of this section, we will talk about each of the individual
components seen in figure 1, detailing their purpose in the framework and how
they are distributed.

###  3.1 Protocol library

Figure 2: Diagram showcasing how protocols work

To allow distributed algorithm logic, implemented as protocol code, to run in
supported environments, be it simulated or real, a common and general
interface needed to be established defining how information from the
environment would be available to the protocol and how it interacts with it.
The environment’s influence in the protocol was modeled as an interface called
protocol interface. The protocol’s interactions with the environment are
defined through an interface called a _provider interface_. This library
contains the code necessary to allow users to create their own protocols. A
protocol must strictly follow the template provided by the protocol interface
in order to properly function in the supported environments. In concrete terms
this means implementing all the required methods and only using functions
provided by the provider interface to interact with the environment.

Protocols are implemented in an event-oriented way. The events available to
the protocol were chosen carefully as to give them the necessary information
to implement their behavior, but not couple them to a specific environment.
Since protocols power nodes capable of communication and mobility, they were
two of the main focuses of the interface. Protocols are able to react to
messages received, being able to read their contents. They are also constantly
updated about their mobility status, mainly about their position. The other
methods are related to more basic needs. Initialization and finalization
events are provided as starting and ending point for protocol logic.
Distributed algorithms often depend on performing actions at certain times or
intervals, so protocols are made aware of when their self-defined timers fire.

It’s also essential that the protocol can act upon the environment. These
actions are performed with the provider interface, named this way because it
_provides_ the protocol with the means to act in its environment. The tools
available to the protocol are highly dependent on the environment, if we want
to build an environment agnostic piece of code we can’t deal with details like
the physical means of locomotion of the node or the hardware that makes it
capable of communication. For this reason, a generic set of messages were
created to hide these details from the protocol through a layer of
abstraction.

Mobility commands are messages that define the primitives through which the
protocol will control its mobility. This simple set of primitives allows the
protocol to go to a coordinate, geographical or Euclidean, and set its speed.
Much more complex behavior can be built on top of this simple set of commands.
Communication commands define the actions the protocol is capable of
performing to impact its communication. It is also a very simple set of
primitives that allow it to send targeted or broadcast messages. The
complexities of the real or simulated environment where the node is in are
thus hidden from it behind these abstractions.

Commands are sent by the protocol through the provider interface. The actual
implementation of the provider interface is environment-dependent, it is
injected into the protocols at run-time and the protocol does not rely on its
design, only that it follows the specification defined in the interface.
Communication commands may result into calls to transmission hardware to send
a message, or send a message through a simulated network stack inside OMNeT++.
The protocol is not concerned with how its commands are handled.

The common interfaces that define a protocol allow us to run the same code in
any environment, provided that some glue code called an _encapsulator_ is
written to adapt the protocol and provider interfaces to the environment. This
glue code is written on a per-environment basis, not a per-protocol basis, so
the effort to maintain it is not excessive and a normal user shouldn’t need to
write any unless he is intending to support some new environment.

Another feature available in the protocol library is a set of tools named
plugins. They come with varying objectives, but mainly focused on making
implementing new protocols easier. They range from abstracting common
behaviors in distributed algorithms from facilitating the implementation of
movement patterns. These tools are only exposed to the protocol interface, and
thus protocols that use them are still completely compatible with it.

This work proposes that the defined library is adequately capable of
representing a wide array of use cases in the creation of distributed
algorithms, in section LABEL:demonstration we will demonstrate this premise by
giving a concrete use case.

Figure 2 illustrates how all of these ideas fit together. In the figure, the
protocol interface and provider methods are shown to be separated from the
environment by the encapsulator. The environment is represented in high
abstraction by three components, mobility, communication, and system.
_Mobility_ is an abstraction for whatever empowers nodes with mobility, be
that hardware or simulated code. Likewise, _communication_ represents what
gives the node the power to communicate. Lastly, _system_ represents a
component that provides computation context and tasks, this could be the
operating system in a real scenario or the simulator itself in a simulated
scenario.

Everything described in this section is available in the _gradys-sim-nextgen_
repository and can be installed directly from PyPI, Python’s package
repository under the name _gradysim_.

###  3.2 Python simulator

The simulator module is a Python package that implements an event-based
network simulator. It was designed to be of similar usage as OMNeT++ but with
a much simpler interface, gentle learning curve, trivial installation process
and a limited set of features. The main objective of this simulator is serving
as a platform for prototyping and developing protocols. Its low overhead and
streamlined usage allow users to quickly iterate through versions of their
protocols, improving developer experience.

Although simple in terms of functionality, it is still capable of emulating a
lot of circumstances a real node will be exposed to. It simulates
communication, allowing users to specify communication range and introducing
common network failures such as network delay or dropped messages. It also
simulates mobility, which is essential since this entire framework has been
created to allow for the simulation of networks populated by mobile nodes.

This component fits in to the framework as a first step for protocol
development. The simpler simulator also serves as a great entry-point for new
users who can learn how to create and implement distributed algorithms. The
Python simulator is also part of the _gradysim_ Python package, and its source
code is available in the _gradys-sim-nexgen_ repository.

###  3.3 Web visualization

This component integrates with the python simulator to provide a visual
representation of a running simulation. Nodes are displayed as spheres
positioned in a 3D visual environment, where the ground is marked as a black
mesh. Information about the running simulation like the simulation time and
the value of some variables marked for tracking inside protocols can be seen
in the user interface. Users can also color specific nodes to distinguish them
from the rest, this is very important to visually interpret some simulations.
The component is available as a website 999https://project-
gradys.github.io/gradys-sim-nextgen-visualization/.

The visualization works by consuming information from a Web Socket. When the
simulation starts, the visualization component of the python simulator, which
is optional, opens a Web Socket server locally. On detecting that this server
is online, the visualization website connects to it and starts receiving live
information from the simulator.

This strategy was chosen because the Python libraries capable of 3D rendering
that were sampled were not fitting with the project’s requirement of
simplicity, ease of setup and minimal dependencies. Although complicated at a
first glance, the visualization was implemented in less than 300 lines of
Typescript code and has only one dependency for the 3D rendering, _Three.JS_
101010https://threejs.org/. Also, the choice of implementing it on the web
means there are zero installation steps if the user already has a web browser
installed.

###  3.4 OMNeT++

The next big component is the OMNeT++ simulator. This whole component was
already available in the previous version of the simulation framework. It has
been modified slightly to account for interacting with the encapsulator
module. The previous version of the simulator was already built on the idea of
a central protocol module implementing the node’s behavior, so adapting was
easy. To bridge the communication gap between Python and OMNeT++, a proxy
protocol sits in the C++ code acting as a protocol but redirecting all calls
to the Python protocol. It acts as a middleman, ensuring that commands and
information flow between the two environments.

Users can select the Python implemented protocol they want through OMNeT++’s
configuration system. In execution time, this protocol will be imported and
wrapped with an _encapsulator_. The proxy protocol will redirect commands to
this wrapped protocol and execute any actions it commands. Protocols running
in this way are said to be running in _integrated-mode_. All interactions with
python are managed through pybind11 111111https://github.com/pybind/pybind11.

###  3.5 Ardupilot SITL Simulator

The final component in the architecture is entirely optional. The OMNeT++
simulation can integrate with Ardupilot’s SITL Simulator. The SITL simulator
allows users to simulate real vehicles running Ardupilot with a convincing
mobility model that takes into account the physics of the vehicle and the
environment. Through work developed in MAVSIMNET, integrating SITL into
OMNeT++ is possible. This provides a much more realistic mobility model to the
simulated node’s movement. The integration replaces the mobility model
implemented as part of the framework’s OMNeT++ simulator with this more
realistic one. This component is only available in _integrated-mode_.

##  4 Results and Discussions

This section presents a demonstration of the benefits of an iterative and
empirical approach to algorithm development in the context of the Internet of
Flying Things. It is aided by GrADyS-SIM NextGen which serves here as a tool
for creating simulated environments and easily translating code between them.
The demonstration presents a hypothetical scenario which is solved by a
distributed algorithm implemented as a protocol in the framework. This
protocol will then be tested and iterated as more realistic conditions are
added. It is not meant as a revolutionary solution to a real world problem,
but as a toy problem where the development of the algorithm itself is more
important than the solution it proposes. The scenario will be better explained
below.

It is a data-collection scenario set in some remote location deprived of any
network infrastructure. A set of stationary sensors has been distributed in
arbitrary known locations in the location of interest. These sensors are
constantly collecting data from their immediate environment, and that
information needs to be collected and processed. The sensors have limited
communication range. The remote nature of the location and lack of
infrastructure makes remote collection impossible, and the frequency with
which data is generated makes manual collection impractical. Some quad-copter
UAVs are available. These vehicles are capable of communication with the
sensors and each other, and of autonomous flight. A ground station (GS) has
been set up with short-range communication equipment capable of talking to the
UAVs.

As for the solution, the UAVs serving as mobile nodes will be employed in
collecting data from the sensors and bringing it to the GS. They will fly
above the sensors, communicating with them to retrieve the data collected and
then return to the GS, delivering the data. The real challenge in this
scenario is coordinating UAV movement efficiently to maximize their
usefulness. This coordination will happen through communication and will
follow some protocol.

The protocol chosen for the solution puts UAVs in a common waypoint mission.
This mission starts at the ground station and travels above every sensor in
the field. When reaching the end of the mission, the UAV will be on top of a
sensor and will need to turn around and complete the mission in reverse in
order to come back to the start. While performing this mission, the mobile
node will constantly advertise its presence with a heartbeat message. Sensors
can receive this messages and will respond with a message containing data
collected from its proximity. The mobile node will listen for these messages
and absorb the data when received. UAVs also interact with each other, when
two meet they will exchange the data they have stored and end their
interaction by flying in opposite directions on the mission, with the UAV that
ends up traveling towards the GS carrying all the data from the pair. This
interaction is managed through a three-step sequence composed of the
heartbeat, which is responded with a pair request that is acknowledged with a
pair confirmation. The same UAV to UAV interaction also happens between UAV
and the GS. With the GS being stationary it of course can’t move away from the
UAV so it always gets all the data from it and the UAV will end up travelling
away from it. This protocol is called ZigZag, and its objective is
collaboratively relaying sensor data to the GS.

It is also necessary to describe how the scenario will be represented in the
simulations. The sensors are represented by stationary nodes, as is the GS.
The UAVs are represented as mobile nodes. Three different protocols were
developed, one for each of these node types. The message interactions
described in the protocol’s specification were implemented, and a simulation
scenario was constructed. The GS was placed, and all mobile nodes were
initialized in that same position. Sensors were placed in a line in 300 meter
intervals away from the ground station. A line was chosen as the sensor’s
dispersal pattern in the field was deemed irrelevant for this simple
experiment. Three configurations of this scenario were built, one with 5
sensors and two UAVs, another with 15 sensors and 7 UAVs and a last one with
25 sensors and 12 UAVs. The number of UAVs was intentionally kept lower than
the number of sensors, as having an excessive number of UAVs changes the
nature of the problem to something akin to a drone swarm. The information the
sensors record from their proximity is being abstracted away as it is not
relevant to the scenario, which focuses on the transportation of this
information and not on its nature. Every time a UAV receives data from a
sensor, it will simply increment a counter, representing the information
collected. This information will be exchanged with other UAVs and the ground
station.

The scenario was constructed in prototype-mode using the python simulator, and
this was the environment used for the initial creation of the protocol. A
network communication range of 50 meters was used in this test. An iterative
and empirical approach was taken, as pieces of the protocol were slowly added
and tested with the aid of the simulation. Initial simulations showed the
mobile nodes getting stuck in interaction loops where a new interaction starts
after the end of a previous one, before the nodes could fly out of
communication range from each other. A timeout strategy was introduced, mobile
nodes will ignore communication from others for a couple of seconds after
finishing an interaction. Another observation was that with all UAVs starting
their mission at the same time, they would stay very close to each other
during the simulation’s course. A change was made to start them in a staggered
manner, with UAVs being released one by one.

After the initial set of changes, a version deemed stable enough was then set
up to be tested in integrated-mode using the integration between the protocol
interface and OMNeT++ and its component library INET. An IEEE 802.11 compliant
radio was used in all nodes, and their transmission power was tuned to
approximate the 50-meter range chosen in python. Additionally, background
noise was added to the network to simulate the noise and interference one
would expect in a real world scenario. The same scenario and three
configurations were set up in this new environment.

Initial results were confusing as no data was being collected in the ground
station. Further analysis pointed out that the cause was a flaw in the
protocol’s behavior that could not be captured by the simpler python
simulator. The UAV and ground station heartbeats were sent in regular
intervals, which were the same for every UAV. This meant heartbeats were being
sent at the exact same time for all nodes. In prototype-mode this wasn’t an
issue as network conditions are not taken into account when evaluating if a
transmission was successfully, only the distance between the recipient and
sender. The OMNeT++/INET simulation stack take into account several factors
when handling message transmission, including interference. The fact that all
the UAVs and the ground station always sent messages at the same time meant
that messages always collided and interfered with each other, not being
delivered. A short random offset was added to each mobile node and the ground
station to prevent further collisions. This fixed the issue, as demonstrated
by later simulation runs.

This serves as an example of how a more realistic simulation scenario can help
with the development of more robust protocols. A more realistic simulation can
introduce problems like unexpected message timings arising from transmission
delays, loss of packets, interference, transmission failures due to obstacles
and many more. These problems are not limited to networking, if we were to use
a more complex mobility model we would observe problems from node reaction
time, imprecision in positioning and others. When exposing an algorithm to
these problems, the effects on its logic can be understood and accounted for.

After a robust enough version of the protocol was finished, massive
simulations were run to collect metrics and evaluate its performance. These
simulations were run both in prototype-mode and in integrated-mode, although
integrated-mode is much more appropriate for this use case. The integration
with the more realistic and proven simulator means the results produced are
more reliable. Prototype-mode is more useful for iterative development,
running shorter simulations and validating a protocol visually and through
code assertions. Either way, the evaluation simulations were run in prototype-
mode to serve as a point of comparison for this work.

Figure 3: Simulated Time vs. Collected Packages – Average Ground Station data
with 10 Runs

The comparison between simulated time and data load for mobile nodes is of
significant interest as it helps to understand the protocols’ performance
under different conditions as well as sheds light on potential trade-offs
between simulation realism and simplicity. In Figure 3, the plot illustrates
the comparison between the three different configurations for both the
prototyping and integrated execution of the ZigZag protocol. In the X Axis the
figure shows the simulation time and on the Y axis the data count in the
ground station at that simulation time. This metric measures the algorithm’s
effectiveness in transporting data to the ground station. The three
configurations for the two simulators are shown as different colored curves.
Each configuration was run 10 times and an average of the runs was taken.

The figure shows a big difference in data collected when comparing the same
configuration in integrated and prototype modes, with prototype-mode
collecting more data. This makes sense as the network simulation of the python
simulator is primitive compared to OMNeT++ and INET’s modules. They more
accurately simulate the loss of packets based on the relative distance between
the communicating nodes and take into account the effects of background noise.
This observed difference again illustrates the importance of using a more
realistic environment. In this particular case, the loss of packets didn’t
drastically affect the functionality of the protocol, but it is easy to
imagine algorithms that are more sensitive to these types of failures.

Figure 4: Simulated Time vs. World Time – Average Ground station data with 10
Runs

Another metric collected was the simulated time and world time ratio, as seen
in figure 4. This effectively shows how fast the simulator is when running
unregulated, as fast as it can go. The X axis shows simulation time and the Y
axis shows the real world time it took to get to that simulation time. The
steepness of the curve measures how fast the scenario ran, with steeper curves
meaning slower times. Each configuration was run 10 times and an average is
shown.

The results show that in this metric, integrated mode is dominant. The
shortcomings of the python simulator in this can be attributed to a lack of
focus on optimization and the usage of Python, which is an interpreted
language that is known to pale in comparison to C++ in terms of performance.
This doesn’t detract from the python simulator’s usefulness because, as
mentioned previously, running big simulation campaigns is not its focus. Fast
iterative development relies on short simulations, not on longer ones. Not
pictured in figure 4 are other time wastes that make using OMNeT++ for this
kind of development cumbersome.

First, it relies on a modified Eclipse IDE made for the project. This removes
user agency in choosing their own development software and limits them to this
IDE, which is very feature rich but slow. Features like syntax highlighting
and auto-completing variable names are slow, sometimes temporarily freezing
the IDE. Another disadvantage is that there is an additional compilation step
before running a simulation. Compilation times ranges from several seconds to
a couple of minutes, depending on the amount of files changed relative to
previous compilations.

Using an analogy, the speed comparison is akin to a race between a man on foot
and a biker, with the biker starting lying on the ground. The racer will get
the early advantage, but of course the biker will later pass him. The winner
depends on the size of the race, and for iterative development the race
doesn’t need to be long. Integrated-mode is still the de facto standard for
collecting performance metrics, as those depend on longer simulations and
benefit from a higher level of realism.

##  5 Conclusion

In conclusion, the proposed approach of iteratively developing distributed
algorithms by abstracting away complexity and gradually introducing it,
switching simulation environments as that happens, has been empirically
validated through the creation and demonstration of the GrADyS-SIM NextGen
framework. It aims to address key challenges in the development and testing of
distributed algorithms for autonomous vehicles in dynamic, networked
environments. It streamlines the intricate processes of creating and
evaluating distributed algorithms by offering an environment-agnostic
interface for protocol implementation and support for multiple execution
environments.

The framework’s architecture, as illustrated in Figure 1, is designed with a
focus on modularity and flexibility. The protocol module establishes a
standardized interface for protocol implementation, ensuring that the same
code can run seamlessly across different simulated environments.

The introduction of _prototype-mode_ provides users with a lightweight and
accessible simulation environment. With a simplified setup and a focus on
rapid prototyping. The _integrated-mode_ leverages the power of OMNeT++, a
widely used event-based network simulator, to provide a more detailed and
accurate representation of network behaviors. The seamless transition between
_prototype-mode_ and _integrated-mode_ ensures that the developed protocols in
the initial stages of development can very easily be used in a realistic
network simulation.

The experiments presented in section 4 shows the tangible benefits of the
proposed approach. During the development of the algorithm, the gradual
introduction of complexity made many inadequacies in the logic apparent,
without sacrificing the developer experience by introducing every complexity
at once.

The next natural step in the development of the framework is supporting real-
world scenarios. The foundational for this to be possible has already been
laid. All that is left is selecting a hardware testbed and implementing the
first integration between it and the framework. This would close the
development cycle from inception, to prototyping, to validation and finally to
experimentation and deployment.

## Acknowledgments

This study was financed in part by AFOSR grant FA9550-23-1-0136.

## References

  * [1] Bruno José Olivieri Olivieri De Souza, Thiago Lamenza, Marcelo Paulon, Victor Bastos Rodrigues, Vítor Gouvêa Andrezo Carneiro, and Markus Endler.  Collecting sensor data from wsns on the ground by uavs: Assessing mismatches from real-world experiments and their corresponding simulations.  In 2023 IEEE Symposium on Computers and Communications (ISCC), pages 284–290, 2023.
  * [2] Francisco Fabra, Willian Zamora, Pablo Reyes, Julio A. Sanguesa, Carlos T. Calafate, Juan-Carlos Cano, and Pietro Manzoni.  Muscop: Mission-based uav swarm coordination protocol.  IEEE Access, 8:72498–72511, 2020.
  * [3] Antonio Guillen-Perez and Maria-Dolores Cano.  Flying ad hoc networks: A new domain for network communications.  Sensors, 18(10), 2018.
  * [4] Jesús Sánchez-García, J.M. García-Campos, Mario Arzamendia Lopez, Daniel Gutiérrez, S.L. Toral, and Derlis Gregor.  A survey on unmanned aerial and aquatic vehicle multi-hop networks: Wireless communications, evaluation tools and applications.  Computer Communications, 119, 02 2018.
  * [5] Sabur Baidya, Zoheb Shaikh, and Marco Levorato.  Flynetsim: An open source synchronized uav network simulator based on ns-3 and ardupilot.  In Proceedings of the 21st ACM International Conference on Modeling, Analysis and Simulation of Wireless and Mobile Systems, pages 37–45. ACM, 2018.
  * [6] SeokYoon Kang, Monther Aldwairi, and Ki-Il Kim.  A survey on network simulators in three-dimensional wireless ad hoc and sensor networks.  International Journal of Distributed Sensor Networks, 12(9):1550147716664740, 2016.
  * [7] Abhishek Phadke, F. Antonio Medrano, Chandra N. Sekharan, and Tianxing Chu.  Designing uav swarm experiments: A simulator selection and experiment design process.  Sensors, 23(17), 2023.
  * [8] Thiago Lamenza, Marcelo Paulon, Breno Perricone, Bruno Olivieri, and Markus Endler.  Gradys-sim – a omnet++/inet simulation framework for internet of flying things, 2022.
  * [9] Bruno José Olivieri De Souza, Marcelo Paulon, Jucá Vasconcelos, and Markus Endler.  GrADyS: Exploring movement awareness for efficient routing in Ground-and-Air Dynamic Sensor Networks.  dec 2020.


# Cooperation and the social brain hypothesis in primate social networks

Neil G. MacLaren1 Lingqi Meng1,† Melissa Collier2 Naoki Masuda1,3
<EMAIL_ADDRESS>1Department of Mathematics, State University of New York
at Buffalo, NY 14260-2900, USA  2Department of Biology, Georgetown University,
DC 20057, USA  3Computational and Data-Enabled Science and Engineering
Program, State University of New York at Buffalo, Buffalo, NY 14260-5030, USA
†Present address: Science for Life Laboratory, KTH – Royal Institute of
Technology, Stockholm, SE-17121 Sweden

###### Abstract

The social brain hypothesis states that the relative size of the neocortex is
larger for species with higher social complexity as a result of evolution.
Various lines of empirical evidence have supported the social brain
hypothesis, including evidence from the structure of social networks. Social
complexity may itself positively impact cooperation among individuals, which
occurs across different animal taxa and is a key behavior for successful group
living. Theoretical research has shown that particular structures of social
networks foster cooperation more easily than others. Therefore, we
hypothesized that species with a relatively large neocortex tend to form
social networks that better enable cooperation. In the present study, we
combine data on brain and body mass, data on social networks, and theory on
the evolution of cooperation on networks to test this hypothesis in primates.
We have found a positive effect of brain size on cooperation in social
networks even after controlling for the effect of other structural properties
of networks that are known to promote cooperation.

##  I Introduction

The social brain hypothesis posits that the relative size of the neocortex in
the brain is positively correlated with social complexity [1]. The hypothesis
has obtained quantitative support in terms of various indices of social
complexity for primates and other taxa [2]. Social networks are a key aspect
of social complexity [3, 4, 5]. In fact, various social network measures have
been related to the social brain hypothesis. The original study in this area
showed that group size is correlated with neocortex size in primates [6].
Further work demonstrated that the number of contacts an individual has, which
is called the degree of the node in network analysis, is positively correlated
with relative neocortex size in primate species [7] and the size of the
amygdala and some other brain regions in human individuals [8, 9, 10]. Other
network indices such as the so-called complexity of the network [8], edge
connectivity and two-clans [11], and global efficiency [4] have also been
shown to be correlated with the size of the neocortex [11, 4] or amygdala [8]
of primates including humans.

Social networks have functions. Focusing on the animal kingdom, the structure
of social networks affects, for example, the speed of diffusion of information
and diseases, mating behavior, predator avoidance, communication efficiency,
and group movement [12, 4, 13, 14]. However, social networks also have costs.
For example, network structure determines disease transmission potential and
epidemic outcomes in populations, because a pathogen can only spread if the
relevant form of contact exists between two individuals. Networks with high
degree heterogeneity (i.e. high variation in the number of contacts among
individuals) have increased transmission potential due to the presence of
superspreaders which cause rapid, explosive outbreaks of disease in a
population [15]. Animal social networks that we observe today may therefore be
a result of evolutionary processes in which more advantageous network
structures have proliferated at the expense of less advantageous structures
under restrictions imposed by the environment and trade-offs between different
objectives.

One function for which social networks are particularly relevant is
cooperation. Individuals of various animal species cooperate with each other,
even cooperating with non-kin and in social dilemma situations in which non-
cooperation is more lucrative than cooperation [16, 17, 18, 19] (but see
[20]). Although cooperation under social dilemmas is an evolutionary puzzle,
theoretical research has suggested various mechanisms enabling cooperation
[21, 22]. Network reciprocity, or the effect of the network structure, is one
mechanism to promote cooperation [22, 23, 24, 25, 26]. Specifically, a
relatively small node degree (i.e., the number of neighboring individuals per
individual) [27, 28] and heterogeneity among individuals in the network in
terms of the degree [29, 30] can both promote cooperation compared to well-
mixed populations depending on the assumptions underlying the evolutionary
process models.

In the present study, we extend the social brain hypothesis to the domain of
cooperation. We ask whether species with a large neocortex size form social
networks that foster cooperation to a greater extent than networks for other
species. While cooperation occurs in various animal taxa [17, 19], here we
focus on primates because neocortex data are available for many primate
species and various indices that correlate with neocortex size have been
documented for primates, as we reviewed above. Recently developed mathematical
theory enables us to quantify the ease of cooperation for networks with
arbitrary structure [28]. We use this theory and look for significant
determinants of cooperation as a function of the neocortex size and other key
properties of the network structure including those which are known to affect
cooperation.

##  II Methods

###  II.1 Threshold benefit-to-cost ratio for cooperation

We assume a network with $N$ nodes that is connected, undirected, and
weighted. On the given network, we consider the gift-giving game, which is a
simple variant of the prisoner’s dilemma game. In the gift-giving game, one
player, called the donor, decides whether or not to pay a cost $c$ $(>0)$ to
benefit another player, called the recipient. If the donor pays $c$, which we
refer to as cooperation, then the recipient gains $b$ $(>c)$. If the donor
does not, which we refer to as defection, then the recipient gains nothing.
The donor receives a higher payoff by defecting than cooperating. However, the
average payoff over the players in the network is larger when the donor
cooperates rather than defects. We assume that the gift-giving game occurs
twice on each edge of the network by swapping the roles of the donor and
recipient in a single round of the evolutionary dynamics. The payoff of each
player $i$ in each round is given as the weighted average of the payoff that
$i$ obtains over all $i$’s neighbors, where the weight for averaging is
proportional to the edge weight. For updating the strategy of the players in
each round of evolutionary dynamics, we assume the death-birth process with
selection on birth, which is known to foster cooperation under certain
conditions [27, 28]. In the death-birth process with selection on birth, one
first selects a node $i$ to be replaced uniformly at random. Then, one selects
a parent to reproduce with the probability proportional to its fitness among
the neighbors of $i$. The fitness of each player is assumed to be linearly but
only weakly depending on the payoff, which is the regime called the weak
selection.

Under this setting, without mutation, all players will eventually become
either cooperators (i.e., fixation of cooperation) or defectors (i.e.,
fixation of defection). We use the recently developed random-walk-based theory
that enables one to calculate the fixation probability for cooperation for
arbitrary network structure [28]. We assume that just one node, selected
uniformly at random, is initially a cooperator and the other $N-1$ nodes are
defectors. If the fixation probability for cooperator exceeds the baseline
value $1/N$, we say that natural selection favors cooperation [31, 27, 28].
Under the weak selection limit, Allen et al. showed the expression for the
threshold benefit-to-cost ratio, denoted by $(b/c)^{*}$, such that the
fixation probability for cooperation is larger than $1/N$ when
$b/c>(b/c)^{*}$, i.e., Eq. (2) in Ref. [28]. If $(b/c)^{*}$ is smaller, the
network supports cooperation more strongly because natural selection favors
cooperation for relatively small values of $b/c$.

We calculated $(b/c)^{*}$ for each network using our in-house code in Python
3.10, which implements the procedures described in [28].

###  II.2 Data

The data for this study come from the Animal Social Network Repository (ASNR)
[32, 33]. The ASNR contains 770 non-human social networks from eight animal
classes and 69 species. For each network in this data set, nodes represent an
individual animal. Edges represent a specific type of contact between two
animals, such as grooming in primates and trophallaxis in ants, as well as
more general contact such as group membership and spatial proximity.

There are 114 primate social networks in the ASNR, including 60 grooming
networks, 31 spatial proximity networks, 10 mating networks, and 13 networks
with other contact types. Most sampled populations are free-ranging (84), with
some captive (18) and some semi-ranging (7) populations, as well as five
populations for which the type was not recorded. There are 99 catarrhine
primate networks, 13 platyrrhine networks, and 2 strepsirrhine networks.
Sampling of the different contrasts represented in the ASNR is thus somewhat
unbalanced but reflects the sampling effort present in the literature.

To test our hypothesis we require that, to the best extent possible, the edges
represent prosocial contacts between individuals. Other contact types, such as
dominance or mating, may reflect motives that are not relevant to the spread
of cooperative behaviors, and proximity-based networks may reflect individuals
who are co-located by chance or interest in a common resource rather than for
social interaction. We therefore used the ASNR networks with the interaction
types labeled “grooming”, “physical contact”, and “overall mix”; the “overall
mix” category captures one additional network that recorded grooming behavior.
We thus obtained 67 possible networks, which we regarded as undirected
weighted networks.

Thirteen out of the 67 networks yielded negative $(b/c)^{*}$ values, which
imply that spiteful behavior evolves instead of cooperation [28, 34]. We
discarded these networks because we are interested in cooperation under social
dilemma situations. Additionally, we discarded one network that was composed
of two disconnected dyads and used the remaining 53 connected networks for our
analysis. Most species had a single network in the repository. The exceptions
were P. cynocephalus (which had 23 networks), M. fascicularis (2), M. fuscata
(4), M. mulatta (9), and M. radiata (2). For these species we took the median
for $(b/c)^{*}$ and for the network-based explanatory variables explained in
Section II.3 to prevent a few species, such as P. cynocephalus and M. mulatta,
from dominating the set of networks to be analyzed. In this manner, we reduced
the 53 networks to observations on 17 species for further analysis.

We used the species-level neocortex ratio (NCR) estimate from [7] for all but
one species, Colobus guereza; a species-level NCR estimate was not available
in [7], so we used the genus-level NCR estimate from [6]. Additionally, we
used the total brain mass and body mass data from [35] for all species except
Papio papio, for which the data is not present. For Papio papio, we used the
data of the closely related species P. cynocephalus [36]. We included brain
and body size as simpler measures of species’ anatomical and physiological
complexity that may also correlate with sociality [37]. These three measures
(i.e., brain mass, body mass, and NCR) are highly correlated with each other
(see Section III).

###  II.3 Analysis

Data analysis was conducted in R 4.2 [38]. We used the “MuMIn” package [39] to
implement the model selection procedure described below. Code in R and Python
to reproduce these analyses is available at
https://github.com/ngmaclaren/cooperation-threshold.

We used generalized linear models (GLMs) to test whether NCR and other
variables were associated with the ease of cooperation, $(b/c)^{*}$. We
considered eight explanatory variables: NCR, brain mass in grams, body mass in
grams, and five network indices some of which are known to influence
$(b/c)^{*}$. The five network indices are the number of nodes in the network
(denoted by $N$), the average degree over the $N$ nodes (denoted by $\langle
k\rangle$), the average node strength (i.e., the average of the weighted
degree over the $N$ nodes), denoted by $\langle s\rangle$, the average
clustering coefficient (denoted by $C$), i.e., the average over all nodes of
the number of complete triangles divided by the number of possible triangles
involving each node [40, 41], and the average weighted clustering coefficient
(denoted by $\tilde{C}_{\text{w}}$), which is calculated similarly to the
unweighted version except that it uses the geometric mean of the edge weights
instead of a count of edges [42]. Because brain mass, body mass, $\langle
s\rangle$, and $\tilde{C}_{\text{w}}$ are positive and obey right-skewed
distributions, we used the natural logarithm transform of each of these
variables.

We began our modeling process from a position of relative ignorance, including
these eight explanatory variables as predictors. By design, our outcome
variable, $(b/c)^{*}$, is positive and continuous, suggesting a model with
gamma-distributed errors. To test our choice, we built five different models,
each with all eight explanatory variables, with different error models and
link functions (i.e., gamma and Gaussian distributions with both inverse and
log links, and a quasi-Poisson model) and calculated the deviances of each
[43]. As expected, the gamma models fit well ($\chi^{2}$ test with $d.f.=8$;
$p$ = 0.942 and 0.986 for the inverse and log links, respectively), whereas
the other models did not ($p<0.001$ for each). The residual deviances
associated with both gamma-based models are small (inverse link: 2.87, log
link: 1.81), further suggesting good fit [43]. We chose the inverse link
because it is the canonical link function for the gamma distribution [43] and
because it improves interpretability in this analysis.

The number of explanatory variables (i.e., eight) is relatively large given
the number of observations (i.e., 17). Therefore, we evaluated all possible
models with only up to five explanatory variables and calculated the AICc for
each model. AICc is a modification of the Akaike Information Criterion (AIC)
that is preferred for model selection when data sets are relatively small
[44].

Because we use the inverse link function, a positive coefficient implies that
the inverse of the outcome variable, $(b/c)^{*}$, increases as the explanatory
variable increases. In other words, positive coefficients suggest that an
increase in the explanatory variable decreases $(b/c)^{*}$ on average,
promoting cooperation in the network.

##  III Results

There were 206 models, or combinations of the explanatory variables, with five
or fewer explanatory variables for predicting $(b/c)^{*}$. We show the sorted
AICc values for these models in Fig. 1. The three best models in terms of the
AICc have similar AICc values compared to the other models, with $\Delta$AICc
$<1$, where $\Delta$AICc is the difference between the AICc for a model and
that for the model minimizing the AICc. The fourth and fifth best models have
$\Delta$AICc $\approx 2$. All the other models have $\Delta$AICc $>3$, forming
a series of models with few obvious cut-points until the poorest models.
Therefore, we focus on the five models with $\Delta$AICc $<3$; we show these
five models in Table 1.

Figure 1: AICc for all possible GLMs with between zero and five explanatory variables. Model 1 | Coef. | SE | $p$
---|---|---|---
Intercept | $-0.344$ | 0.176 | 0.072
$\langle k\rangle$ | $-0.009$ | 0.003 | 0.020
$\ln(\tilde{C}_{\text{w}})$ | $-0.057$ | 0.025 | 0.043
$\ln(\text{Body mass})$ | 0.039 | 0.020 | 0.075
$\Delta$AICc | 0.00 |  |
Model 2 | Coef. | SE | $p$
Intercept | $-0.295$ | 0.163 | 0.093
$\langle k\rangle$ | $-0.008$ | 0.003 | 0.020
$\ln(\tilde{C}_{\text{w}})$ | $-0.059$ | 0.025 | 0.036
$\ln(\text{Brain mass})$ | 0.064 | 0.036 | 0.095
$\Delta$AICc | 0.13 |  |
Model 3 | Coef. | SE | $p$
Intercept | $-0.201$ | 0.127 | 0.137
$\langle k\rangle$ | $-0.010$ | 0.004 | 0.019
$\ln(\tilde{C}_{\text{w}})$ | $-0.047$ | 0.028 | 0.115
NCR | 0.097 | 0.059 | 0.121
$\Delta$AICc | 0.69 |  |
Model 4 | Coef. | SE | $p$
(Intercept) | $-0.021$ | 0.105 | 0.845
$\langle k\rangle$ | $-0.009$ | 0.004 | 0.055
$\ln(\tilde{C}_{\text{w}})$ | $-0.067$ | 0.040 | 0.114
$\Delta$AICc | 1.83 |  |
Model 5 | Coef. | SE | $p$
(Intercept) | $-0.182$ | 0.124 | 0.165
$\langle k\rangle$ | $-0.009$ | 0.003 | 0.015
NCR | 0.138 | 0.054 | 0.024
$\Delta$AICc | 1.95 |  |
Table 1: The best five models, i.e., the models with $\Delta$AICc $<3$. A
positive coefficient suggests that variable is associated with a smaller
$(b/c)^{*}$, i.e., easier evolution of cooperation. SE stands for the standard
error. We remind that $\langle k\rangle$ and $\tilde{C}_{\text{w}}$ represent
average degree and the weighted clustering coefficient, respectively.

Table 1 indicates that no model among the best five models has more than three
explanatory variables. Therefore, adding more explanatory variables would not
be useful in better explaining $(b/c)^{*}$ across the different networks. The
two network features, i.e., average degree and the weighted clustering
coefficient, have consistently negative coefficients, with average degree
appearing in each of the best five models and the weighted clustering
coefficient appearing in all but one model. The present result that a smaller
average degree promotes cooperation is consistent with the previous findings
[27, 28]. Body mass and brain mass, which are highly correlated with each
other (with Pearson correlation coefficient $r=0.953$), are each the third
predictor in the best two models, which are nearly indistinguishable in terms
of the AICc; $\Delta$AICc for Model 2 = 0.13. Compared to these best two
models, the third best model uses NCR in place of body or brain mass as the
third explanatory variable. Note that NCR is also highly correlated with body
mass ($r=0.81$) and brain mass ($r=0.84$), partly because we are only
analyzing primates. The fourth best model only contains the average degree and
the weighted clustering coefficient. We note that the number of nodes $N$,
average weighted degree $\langle s\rangle$, and the unweighted clustering
coefficient $C$ did not appear among the best five models.

In each of best five models in which a brain size variable (i.e., brain mass
or NCR) appears (i.e., Models 2, 3, and 5), the coefficient for the brain size
variable is positive. This result suggests that social networks for primates
with a larger brain size tend to better accommodate cooperative behavior if
the average degree and the clustering coefficient (i.e., abundance of
triangles) are the same. We visualize this relationship in Fig. 2. However,
formally, either brain mass or NCR only satisfies $p<0.05$ for Model 5
($p=0.024$); brain mass and NCR yield $p=0.095$ in Model 2 and $p=0.121$ in
Model 3, respectively. We visualize in Fig. 3 the coefficient values and
associated 95% confidence intervals for each explanatory variable for each of
the best five models. In Fig. 3, a circle’s position and the span of the line
segment in the horizontal direction indicate the value of the estimated
coefficient and its 95% confidence interval, respectively. The figure shows
that, although some 95% confidence intervals for the brain size variables
include zero, the value and sign of the coefficient estimates are consistent,
and the confidence intervals only marginally cross zero. As expected, the
coefficients for the average degree and weighted clustering coefficient are
consistently negative. We thus conclude that our data analysis provides
evidence in favor of our hypothesis: brain size, measured in two different
ways, is positively associated with the ease with which cooperation spreads in
primate social networks, albeit not strongly.

Figure 2: Threshold for cooperation, $(b/c)^{*}$, as a function of the NCR for
Model 3. Each circle represents a primate species. The solid line represents
the predicted $(b/c)^{*}$. The dotted lines indicate twice the standard error
of prediction. Figure 3: Coefficient estimates for the best five models. The
circles represent the coefficient values. The lines represent the 95%
confidence intervals. NCR: neocortex ratio, $\langle k\rangle$: average
degree, $\tilde{C}_{\text{w}}$: average weighted clustering coefficient.

##  IV Discussion

Consistent with network reciprocity, animal social networks foster cooperation
in terms of fixation probability [45]. Advancing this finding one step
further, we found positive support for the social brain hypothesis in terms of
network reciprocity in primates. In reaching our conclusion, we controlled for
major network properties that affect cooperation, such as the average degree
and the clustering coefficient, as well as the size of the entire group. We
point out that the average degree, i.e., average number of others one
individual contacts, is also a major outcome variable that the social brain
hypothesis aims to explain in terms of brain size. Therefore, the present
results are orthogonal to these previous ones. Exploration of network
properties that covary with both brain size and $(b/c)^{*}$ and finding
generative mechanisms of such network properties warrant future work.

We found that the weighted clustering coefficient negatively contributes to
evolution of cooperation and that the unweighted clustering coefficient does
not have effect, at least for the best five models. This result is apparently
inconsistent with spatial reciprocity, which dictates that high clustering in
networks promotes cooperation [46, 47, 22]. In fact, these results have been
derived for the fraction of cooperators in the quasi-stationary state of
evolutionary dynamics in relatively large networks rather than the fixation
probability for the cooperator strategy; we examined the latter quantity in
this study. The effect of clustering on the fixation probability for
cooperation is not systematically known. For example, some numerical
simulations suggest that clustering, which is present in most empirical
networks, does not facilitate the fixation of cooperation [27, 48]. Therefore,
our results are in fact not contradictory to the known results for spatial
reciprocity, and fixation of cooperation in clustered networks remains to be
investigated.

Cooperative group living is often advantageous in the animal kingdom because
it can provide protection from predators and increase the efficiency of
foraging tactics [49, 18]. However, one of the most commonly cited
disadvantages to cooperative group living is the increase in disease
transmission potential [49, 50]. In fact, previous work suggests that the
average degree is the most important aspect of network structure in
determining the transmission potential for pathogens on a network [51]. Our
results show that average degree is negatively associated with the evolution
of cooperation, a finding supported by previous theoretical work [27]. Given
that small average degrees are beneficial for both enhancing cooperation and
reducing pathogen transmission opportunity, cooperation and protection against
disease transmission potential might have coevolved through a decrease in the
average degree of social networks. Maintaining contacts is also costly for
individuals. However, a large average degree helps robustness of networks
against node and edge failures [52, 14]. We may be able to further discussion
of the evolution of network structure and social brain hypotheses by
simultaneously taking into account multiple functions of animal society such
as cooperation, protection against infection, robustness, and communication
efficiency.

The present work also opens avenues for further work to explore intersection
between social brain hypothesis, networks, and cooperation. Investigation of
social networks of species other than primates is worthwhile. Additional study
of important contrasts within the primates—such as between catarrhine and
platyrrhine primates, or between captive and wild groups—can also be
informative. We are also aware that most of the social networks we used are
grooming networks. Network structure may vary according to the type of
prosocial contact even for the same group of animals [51], which is worthy of
investigation. Although further comparative work along these lines is
currently limited by available data [32], various technological and
algorithmic developments of automatic data collection [14, 53] are expected to
allow us to access more data and explore these topics in a near future.

## Acknowledgments

N. Masuda acknowledges support from AFOSR European Office (under Grant No.
FA9550-19-1-7024), the Japan Science and Technology Agency (JST) Moonshot R&D
(under Grant No. JPMJMS2021), and the National Science Foundation (under Grant
No. 2052720). M. Collier acknowledges funding from the Morris Animal
Foundation (under Grant No. D22ZO-059). We thank Shweta Bansal for her
thoughtful comments on this work. We thank Pratha Sah, Jose Mendez, Grant
Rosensteel, Elly Meng, and Sania Ali for their contributions to the
development and growth of the Animal Social Network Repository.

## References

  * [1] R. I. M. Dunbar.  The social brain hypothesis.  Evolutionary Anthropology: Issues, News, and Reviews, 6(5):178–190, 1998.
  * [2] R. I. M. Dunbar and S. Shultz.  Evolution in the social brain.  Science, 317(5843):1344–1347, 2007.
  * [3] T. Wey, D. T. Blumstein, W. Shen, and F. Jordán.  Social network analysis of animal behaviour: a promising tool for the study of sociality.  Animal Behaviour, 75(2):333–344, 2008.
  * [4] C. Pasquaretta, M. Levé, N. Claidiere, E. Van de Waal, A. Whiten, A. J. J. MacIntosh, M. Pelé, M. L. Bergstrom, C. Borgeaud, S. F. Brosnan, M. C. Crofoot, L. M. Fedigan, C. Fichtel, L. M. Hopper, M. C. Mareno, O. Petit, A. V. Schnoell, E. Polizzi di Sorrentino, B. Theirry, B. Tiddi, and C. Sueur.  Social networks in primates: smart and tolerant species have more efficient networks.  Scientific Reports, 4(1):7600, 2014.
  * [5] P. M. Kappeler, T. Clutton-Brock, S. Shultz, and D. Lukas.  Social complexity: patterns, processes, and evolution.  Behavioral Ecology and Sociobiology, 73:5, 2019.
  * [6] R. I. M. Dunbar.  Neocortex size as a constraint on group size in primates.  Journal of Human Evolution, 22(6):469–493, 1992.
  * [7] H. Kudo and R. I. M. Dunbar.  Neocortex size and social network size in primates.  Animal Behaviour, 62(4):711–722, 2001.
  * [8] K. C. Bickart, C. I. Wright, R. J. Dautoff, B. C. Dickerson, and L. F. Barrett.  Amygdala volume and social network size in humans.  Nature Neuroscience, 14(2):163–164, 2011.
  * [9] R. Kanai, B. Bahrami, R. Roylance, and G. Rees.  Online social network size is reflected in human brain structure.  Proceedings of the Royal Society B: Biological Sciences, 279(1732):1327–1334, 2012.
  * [10] P. A. Lewis, R. Rezaie, R. Brown, N. Roberts, and R. I. M. Dunbar.  Ventromedial prefrontal volume predicts understanding of others and social network size.  NeuroImage, 57(4):1624–1629, 2011.
  * [11] J. Lehmann and R. I. M. Dunbar.  Network cohesion, group size and neocortex size in female-bonded old world primates.  Proceedings of the Royal Society B: Biological Sciences, 276(1677):4417–4422, 2009.
  * [12] N. Pinter-Wollman, E. A. Hobson, J. E. Smith, A. J. Edelman, D. Shizuka, S. De Silva, J. S. Waters, S. D. Prager, T. Sasaki, G. Wittemyer, J. Fewell, and D. B. McDonald.  The dynamics of animal social networks: analytical, conceptual, and theoretical advances.  Behavioral Ecology, 25(2):242–255, 2014.
  * [13] J. Kruase, R. James, D. W. Franks, and D. P. Croft, editors.  Animal Social Networks.  Oxford University Press, Oxford, UK, 2015.
  * [14] J. B. Brask, S. Ellis, and D. P. Croft.  Animal social networks: an introduction for complex systems scientists.  Journal of Complex Networks, 9(2):cnab001, 2021.
  * [15] S. Bansal, B. T. Grenfell, and L. A. Meyers.  When individual behaviour matters: homogeneous and network models in epidemiology.  Journal of the Royal Society Interface, 4(16):879–891, 2007.
  * [16] R. L. Trivers.  The evolution of reciprocal altruism.  The Quarterly Review of Biology, 46:35–57, 1971.
  * [17] D. P. Croft, M. Edenbrow, and S. K. Darden.  Assortment in social networks and the evolution of cooperation.  In Animal Social Networks, pages 13–23. Oxford University Press, Oxford, UK, 2015.
  * [18] P. M. Kappeler and C. P. Van Schaik.  Cooperation in Primates and Humans.  Springer, Berlin, Germany, 2006.
  * [19] R. Noë.  Cooperation experiments: coordination through communication versus acting apart together.  Animal Behaviour, 71(1):1–18, 2006.
  * [20] T. Clutton-Brock.  Cooperation between non-kin in animal societies.  Nature, 462(7269):51–57, 2009.
  * [21] D. Fudenberg and D. K. Levine.  The Theory of Learning in Games.  MIT Press, Cambridge, MA, 1998.
  * [22] M. A. Nowak.  Five rules for the evolution of cooperation.  Science, 314:1560–1563, 2006.
  * [23] G. Szabó and G. Fáth.  Evolutionary games on graphs.  Physics Reports, 446:97–216, 2007.
  * [24] M. Perc, J. Gómez-Gardeñes, A. Szolnoki, L. M. Floría, and Y. Moreno.  Evolutionary dynamics of group interactions on structured populations: a review.  Journal of the Royal Society Interface, 10(80):20120997, 2013.
  * [25] M. Perc, J. J. Jordan, D. G. Rand, Z. Wang, S. Boccaletti, and A. Szolnoki.  Statistical physics of human cooperation.  Physics Reports, 687:1–51, 2017.
  * [26] K. Takács, J. Gross, M. Testori, S. Letina, A. R. Kenny, E. A. Power, and R. P. M. Wittek.  Networks of reliable reputations and cooperation: a review.  Philosophical Transactions of the Royal Society B: Biological Sciences, 376(1838):20200297, 2021.
  * [27] H. Ohtsuki, C. Hauert, E. Lieberman, and M. A. Nowak.  A simple rule for the evolution of cooperation on graphs and social networks.  Nature, 441(7092):502–505, 2006.
  * [28] B. Allen, G. Lippner, Y.-T. Chen, B. Fotouhi, N. Momeni, S.-T. Yau, and M. A. Nowak.  Evolutionary dynamics on any population structure.  Nature, 544(7649):227–230, 2017.
  * [29] F. C. Santos and J. M. Pacheco.  Scale-free networks provide a unifying framework for the emergence of cooperation.  Physical Review Letters, 95(9):098104, 2005.
  * [30] F. C. Santos, J. M. Pacheco, and T. Lenaerts.  Evolutionary dynamics of social dilemmas in structured heterogeneous populations.  Proceedings of the National Academy of Sciences of the United States of America, 103(9):3490–3494, 2006.
  * [31] M. A. Nowak, A. Sasaki, C. Taylor, and D. Fudenberg.  Emergence of cooperation and evolutionary stability in finite populations.  Nature, 428(6983):646–650, 2004.
  * [32] P. Sah, J. D. Méndez, and S. Bansal.  A multi-species repository of social networks.  Scientific Data, 6:44, 2019.
  * [33] M. Collier, S. Ali, and S. Bansal.  Animal Social Network Repository.  https://github.com/bansallab/asnr, accessed on 2022-10-31.
  * [34] Q. Su, A. McAvoy, and J. B. Plotkin.  Evolution of cooperation with contextualized behavior.  Science Advances, 8(6):eabm6066, 2022.
  * [35] J. B. Smaers, R. S. Rothman, D. R. Hudson, A. M. Balanoff, B. Beatty, D. K. N. Dechmann, D. de Vries, J. C. Dunn, J. G. Fleagle, C. C. Gilbert, A. Goswami, A. N. Iwaniuk, W. L. Jungers, M. Kerney, D. T. Ksepka, P. R. Manger, C. S. Mongle, F. J. Rohlf, N. A. Smith, C. Soligo, V. Weisbecker, and K. Safi.  The evolution of mammalian brain size.  Science Advances, 7(18):eabe2101, 2021.
  * [36] T. K. Newman, C. J. Jolly, and J. Rogers.  Mitochondrial phylogeny and systematics of baboons (_Papio_).  American Journal of Physical Anthropology, 124(1):17–27, 2004.
  * [37] J. B. Smaers, C. S. Mongle, K. Safi, and D. K. N. Dechmann.  Allometry, evolution and development of neocortex size in mammals.  Progress in Brain Research, 250:83–107, 2019.
  * [38] R Core Team.  R: A Language and Environment for Statistical Computing.  R Foundation for Statistical Computing, Vienna, Austria, 2022.
  * [39] K. Bartoń.  MuMIn: Multi-Model Inference, 2022.  R package version 1.47.1.
  * [40] S. Wasserman and K. Faust.  Social Network Analysis: Methods and Applications.  Cambridge University Press, New York, NY, 1994.
  * [41] M. Newman.  Networks.  Oxford University Press, Oxford, UK, 2nd edition, 2018.
  * [42] G. Fagiolo.  Clustering in complex directed networks.  Physical Review E, 76(2):026107, 2007.
  * [43] J. J. Faraway.  Extending the Linear Model with R: Generalized Linear, Mixed Effects and Nonparametric Regression Models.  Chapman and Hall/CRC, Boca Raton, FL, 2nd edition, 2016.
  * [44] D. Anderson and K. Burnham.  Model Selection and Multi-Model Inference.  Springer-Verlag, New York, NY, 2nd edition, 2002.
  * [45] B. Voelkl and C. Kasper.  Social structure of primate interaction networks facilitates the emergence of cooperation.  Biology Letters, 5(4):462–464, 2009.
  * [46] M. A. Nowak and R. M. May.  Evolutionary games and spatial chaos.  Nature, 359(6398):826–829, 1992.
  * [47] Ch. Hauert.  Fundamental clusters in spatial 2 $\times$ 2 games.  Proceedings of the Royal Society B: Biological Sciences, 268(1468):761–769, 2001.
  * [48] Z.-X. Wu, Z. Rong, and H.-X. Yang.  Community structure benefits the fixation of cooperation under strong selection.  arXiv preprint arXiv:1408.3267, 2014.
  * [49] R. D. Alexander.  The evolution of social behavior.  Annual Review of Ecology and Systematics, 5:325–383, 1974.
  * [50] W. J. Freeland.  Pathogens and the evolution of primate sociality.  Biotropica, 8(1):12–24, 1976.
  * [51] M. Collier, G. F. Albery, G. C. McDonald, and S. Bansal.  Pathogen transmission modes determine contact network structure, altering other pathogen characteristics.  Proceedings of the Royal Society B: Biological Sciences, 289(1989):20221389, 2022.
  * [52] R. Cohen and S. Havlin.  Complex Networks: Structure, Robustness and Function.  Cambridge University Press, Cambridge, UK, 2010.
  * [53] J. Krause, S. Krause, R. Arlinghaus, I. Psorakis, S. Roberts, and C. Rutz.  Reality mining of animal social systems.  Trends in Ecology & Evolution, 28(9):541–551, 2013.