# Effects of Transport Network Slicing on 5G Applications
## 6 Impact of Network Slicing on 5G Applications  
This section elaborates on the applications' traffic patterns and the experiments conducted to investigate the impact of transport network slicing. The input parameters we use for SimTalk to generate the emulated traffic of the same type include the packet size, the sending period, and the number of devices. The packet size and sending period we choose to generate the traffic for an application are those we observed from the real-world counterpart application running on our testbed. However, the number of devices we apply for the same application type is the maximum number of devices the server hardware can support. We define a CIR ratio as the CIR setting for a P4 meter in physical switch hardware divided by the aggregated data rate of applications of the same type, representing the relative ratio of the committed rate to the application traffic input rate. By varying the CIR ratios, we can study the effects of transport network slicing on an application under different bandwidth guarantees. Note that we focus on the effectiveness of bandwidth guarantee instead of rate-limiting and set the PIR parameter for a P4 meter to a constant value of line capacity in all experiments. The details of exemplar CIoT, MIoT, and MBB applications used in the experiments are elaborated below. For the CIoT applications, we investigated the behavior of smart switches in the NCTU smart norms. The raw sensor data of an IoT packet sent from the smart switch to the IoTalk server is 1 byte. Encapsulated by the JSON format, this raw data gains 14 additional bytes, which comprises the payload of the IoTtalk HTTP message. The HTTP header includes variable-length fields, such as the device ID in URL, and the content-length field, taking up about 275 to 277 bytes in total. Consequently, the size of the whole IoTtalk HTTP packet ranges from 290 bytes to 292 bytes. Our experiments include 300 smart switches (called MorSocket; see Appendix A.4). According to our observation of the traffic patterns of the NCTU campus applications, SimTalk emulates various types of traffic that mix and form a Poisson process; the expected inter-arrival time can range from 0.01 s to 10 s. Each smart switch emulated by SimTalk has a packet-sending period of 0.2 s in the mean value. For the MIoT applications, we use MapTalk to produce sensor data (e.g., temperature, humidity, and CO2), indoor positioning data for sensor fusion, and map coordinates; the raw data size in total is 104 bytes. The IoTtalk HTTP message size amounts to 394 to 396 bytes. 10,000 MapTalk sensors are involved in our experiment, each producing a sample every 10 s.  
The two MBB applications, namely sensor fusion and PigTalk, are elephant flows in our testbed. For sensor fusion, we use Yolo to analyze video frames from a set of cameras and output the image bounding box data, combined with other sensory data to perform sensor fusion. The sensor fusion client collects and packs a batch of image bounding boxes into a payload formatted by 520 KB-long JSON, and the IoTtalk HTTP header adds an extra 293 to 294 bytes. Our experiments include 104 sensor fusion clients, and the sending period for each client is a fixed rate of 0.1 s. For PigTalk, the piglet crush video monitor receives and displays live streaming of narrowing pens and uses 1.4 KB-long Real-time Transport Protocol (RTP) packets over UDP for video streaming. In the uplink traffic experiments, the IoTtalk HTTP messages are delivered along the path (9)-(6)-(4)-(2) in Figure 2. The link capacity of (6) and (4) is 10 Gb/s. There are three sources for application traffic, the first being 300 smart switches that send traffic at a rate of 11.312 Mb/s. Additionally, 104 sensor fusion clients generate traffic with a sending rate of 4609.896 Mb/s, while 10,000 MapTalk sensors generate traffic at an average load of 8.296 Mb/s. We also include the background UDP traffic generated from the iPerf [24] with a data rate of up to 10 Gb/s.