# Artificial Intelligence Control Logic in Next-Generation Programmable Networks
## 3 Generating Network Traffic  
To test our AI solution, we use Networked Application Emulation System (NAPES), a traffic generator we developed within the FlexNet project. The motivation behind the development ofNAPES is to enable rapid deployment of setups that exhibit complex, time varying traffic patterns, which closely resembles those of actual applications. The main innovative idea behind NAPES is that it allows distributed, traffic-generating \"applications\" to be defined with elements of application logic. Specifically, a NAPES application consists of communicating application components, each of which can have several state machines representing the component's logic. State machines are meant to approximate the logic of an actual application. Interacting state machines of an application's components jointly give rise to complex traffic patterns. A NAPES developer specifies the state machines (i.e., states and state transitions) for each of an application's components.  
State transitions occur in response to events, which may originate locally (timer events) or may arrive from other components of the application. Thus, the events serve the purpose of intra- and inter-component coordination.  
Besides lightweight event-based coordination, components communicate via flows, which form the traffic stress-testing the network under investigation. A component may generate a flow addressed to another component. A flow is a sequence of packets described with some parameters, e.g., ones that describe a distribution of inter-packet times and a distribution of packet sizes. Flows are sent and received by means of components' ports. A client port generates the packets of a flow, while a server port receives the packets.  
The generation of flows is governed by the states of the states machines inside the components comprising a NAPES application. Specifically, for each client port, a NAPES user specifies a flow to be generated in each state of a state machine assigned to control the client port (in some states there may be no flow at all). Thus, when an event (a local one or received from another component) causes a state transition, flows generated by the component's client ports controlled by the state machine in question may change. As a result of state changes of components' state machines, a NAPES application may generate traffic of different patterns. Overall, the above mechanisms allow a NAPES to approximate some actual IoT application, whose components are also likely \"to be in different states\" reflecting the state of the environment.  
In terms of implementation, a component is specified in a data structure to be interpreted by the so-called NAPES Runtime. A NAPES Runtime should be installed on a computing device to make it a NAPES node. We intend to implement a NAPES Runtime on different platforms, from resource-constrained IoT nodes to cloud servers. We currently have a Linux implementation; runtimes for Android and Arduino are being developed. As the accepted component data structure is the same, no matter what the underlying platform, NAPES components are portable and can be run on different nodes. Inter-component events are exchanged as short Message Queuing Telemetry Transport (MQTT) messages.  
A general approach to stress-test a network with NAPES is to (a) develop a multi-component NAPES application with an application logic close to that of an actual application, (b) connect to the network under test a number of NAPES nodes (computing devices with NAPES Runtimes), (c) distribute the data structure representations of the application's components to the NAPES nodes, (d) run the application and collect logs. Notably, NAPES applications are agnostic as to an underlying stress-tested network. There is no application-to-network signaling, which calls for some network intelligence and adaptivity.