In this session, we’ll examine how discrete-event simulation can be used to evaluate the performance of digital communication systems. With electronics becoming more interconnected, engineers are increasingly concerned with data transfer across networks. And whether you’re a cable service provider or avionics designer, you want answers to similar questions…things like, “Do I have the bandwidth required to support my network traffic?,” “Is my software protocol the best for my system architecture” or, “What will happen to communication performance if I add, remove, or replace components in my system?”
Discrete-event simulation is a great way to answer such questions without having to build and test a real network, because the standard elements of a model can be readily mapped to a communication system. You can model data packets as entities that are created by a device, transmitted through the communication medium, and received by a device on the other end. The channel for data transmission can be modeled as a server that the packet resides within for a prescribed amount time dependent on the size of the packet, distance between devices, and communication protocol.
Now, if you’re modeling bidirectional communication in which parties can both send and receive information, then a second pathway would be necessary. This schematic captures the behavior of full duplex communication, meaning that parties can simultaneously send and receive data packets. In this setup, there’s no interference between signals, sort of like a two way street.
Bandwidth constraints tend to be greater with communication systems that are half-duplex, meaning that communication can only go one direction at any given time. This scheme is more like a one lane bridge that supports traffic going both directions. And just as cars could back up on each side of the bridge, so too can traffic pile up on the network. Because of this, communication systems almost always include data buffers that protect against packets crashing into one another by holding the information until it’s safe to transmit. This behavior can be modeled with queues in the discrete-event simulation.
But the system needs to identify that the channel is in use so that parties know when to send versus when to buffer. This challenge is referred to as Media Access Control, and every communication protocol’s MAC strategy is a little different. Regardless of the specific logic employed, a discrete-event simulation will capture this kind of packet routing through a series of loops and dead ends managed by switches.
Elaborating further, we can capture the behavior of an early Ethernet system. In it, every station is connected through a shared cable that supports half-duplex communication. Stations rely on CSMA, Carrier Sense Multiple Access, to detect channel availability. If a station wants to send data, and it looks like the channel is free, the transmission will commence. And so long as no data collisions are detected, more bits will be sent until the entire message is transmitted. In the event of a collision though, Ethernet protocol dictates that the sender wait for the channel to free up and try again. The wait or backoff time is randomized to avoid two stations conflicting over and over.
Hopefully transmission will work after this, but if the station continues to encounter problems, it will eventually give up and declare a failure. And this is exactly the kind of thing you’d like to discover as part of a discrete-event simulation of a communication network. Rather than purchasing all the hardware and hoping for the best, you model the network to identify problems ahead of time. You then reengineer the model to mitigate problems, trying things like reducing traffic, altering the network’s structure, or changing the communication protocol. Fixing the problem in the model can be orders of magnitude faster and cheaper than doing so on hardware. And by iterating our design in simulation, we can work towards optimizing performance against any benchmark we choose.
