# Reinforcement Learning Based Resource Management for Network Slicing
## 3 System Model
### Service and Traffic Model  
In general, network slices may support different services (e.g., streaming, P2P, and web) consisting of a single type or multiple types of the network traffic. Thus, we assume that slices consist of different types of traffic depending on their services. Internet traffic is mainly categorized into two types of traffic: elastic traffic and inelastic traffic [15]. Since elastic traffic is less sensitive to the delay and bandwidth constraints, it does not instantly require minimum bandwidth requirements but usually prefers high throughput. The file transfer service is an example of the elastic traffic. On the other hand, inelastic traffic usually requires strict bandwidth to support real-time traffic such as streaming services and online gaming. For this reason, it always needs to receive instantaneous bandwidth at every time slot \(t\). We denote \(I=\{1,\ldots,|I|\}\) as the set of inelastic flows, and \(E=\{1,\ldots,|E|\}\) as the set of elastic flows. Each inelastic flow \(i\in I\) always requires an instantaneous bandwidth \(d_{i}\) at every time slot \(t\), whereas each elastic flow \(e\in E\) needs an average bandwidth \(d_{e}\) over a long time scale. In our system model, it is assumed that all slices are characterized by the ratio of elastic traffic to inelastic traffic. Our framework has the flexibility to accommodate various types of service models. For example, if the tenant is a streaming service operator, it may have a slice with almost inelastic flows and others with almost elastic flows. On the other hand, in the case the tenant is a mobile network operator, the flows of a slice can have different service requirements such as an elastic and inelastic traffic mix scenario. To evaluate the QoS directly depending on the resources consumed by end-users, we describe how the respective QoS function of each of the traffic types can be obtained from the general utility function used in [16]. Figure 2 shows that the QoS function reflects the performance according to the bandwidth requirements of each traffic type. Typically, elastic traffic does not need to achieve the minimum rate, i.e., \(d_{e}^{min}=0\). Instead of the minimum rate, elastic traffic requires the average bandwidth, denoted as \(d_{e}^{avg}\), because this traffic does not have strict delay and bandwidth constraints as mentioned above. It also does not require maximum bandwidth because high throughput is usually desirable. Therefore, its QoS gradually increases as the received bandwidth increases. Unlike elastic traffic, inelastic traffic always needs to achieve the minimum rate, i.e., \(d_{i}^{min}>0\). When the received bandwidth of each flow is lower than \(d_{i}^{min}\), the QoS is the minimum value. QoS gradually increases as the received bandwidth increases between \(d_{i}^{min}\) and \(d_{i}^{max}\) similar to elastic traffic, which reflects the sensitivity of variations in QoS (e.g., video quality). Because improving the rate beyond what is required for the highest QoS is not useful, there exists a saturation region, i.e., the maximum QoS denoted as \(q^{max}\). To easily analyze the performance, we assume in this study that QoS of each flow is \(q^{max}\) if the bandwidth is larger than \(d_{i}^{min}\). According to the system model explained above, the bandwidth is provided to inelastic flows at time slot \(t\) first. Thus, sufficient bandwidth is provided to inelastic flows to guarantee the minimum demand, while elastic flows equally receive the share of the remaining bandwidth. Therefore, inelastic flows are first provided with sufficient bandwidth as follows:  
\[r_{t}^{i}=\min(\frac{R_{n,t}}{|I|},d_{i}^{min}), \tag{2}\]  
where \(r_{t}^{i}\) is the data rate consumed by inelastic flow \(i\) at \(t\). If the number of inelastic flows is too large (i.e., \(\sum_{i\in I}d_{i}^{min}/R_{n,t}>1\)), not all inelastic flows can receive enough bandwidth. In this case, we meet the demands of as many inelastic flows as possible and provide the remaining bandwidth to elastic flows.