QoS Implementation with Triple-Metric-Based Active Queue Management for Military Networks

Abstract

For supporting Quality of Service (QoS) in a military network, applications of the triple-metric priority of performance, importance, and urgency as well as autonomous and lightweight implementation are required. In a previous study, we analyzed a Korean military network’s QoS implementation in the perspective of the triple-metric and presented some improvements in the simplification of the service classes of Differentiated Services (DiffServ). To extend the simplified DiffServ from the previous research, this paper proposes Active Queue Management (AQM) algorithms to process the traffic of each service class differently based on importance and urgency and shows the feasibility through some experiments.

1. Introduction

As military networks are operated in very harsh and dynamic environments, the risk of failures or malfunction is high while rapid recovery and repair are limited [1]. Therefore, it is essential to apply Quality of Service (QoS) that differentiates according to priorities in a congestion situation in a military network. In addition, QoS implementation can be replaced with an optimization problem that selects or develops as well as combines and tunes the appropriate priority criterion and processing methods.

In the QoS field for military networks, called the triple-metric priority criterion of performance, importance and urgency is most widely cited and applied. Each priority is associated with a traffic type, a user or mission, and a timeliness. However, it is not easy to implement efficiently and effectively by applying all three priorities.

In the previous study [2], we analyzed the QoS implementations of the US military’s DoDIN (DoDIN: Department of Defense Information Networks) [3,4] and the Korean military’s TICN (TICN: Tactical Information Communication Networks) [5] focusing on the triple-metric and proposed several improvements for QoS of Korean tactical communication networks. We simplified the service class classification of Differentiated Services (DiffServ) [6] to four, which is suitable for performance-based differentiated processing of traffic, suggested additional required criteria such as importance classification, and presented a prioritized traffic-processing mechanism for each service class according to importance and urgency. In the performance analysis, we have demonstrated that the experimental results showed almost the same or better performance with no difference in performance under the same conditions. Furthermore, we also emphasized that autonomy and lightweight solutions are essential for the military network, especially for tactical services because its Disconnected, Intermittent, Limited (DIL) characteristic increases the risk of disconnection with remote services, and its Size, Weight and Power (SWaP) sensitivity limits the complicated and sophisticated processing.

This paper focuses on the extended capability of the simplified DiffServ using Active Queue Management (AQM) [7,8]. AQM enables the addition of special processing to each service class or queue of DiffServ. Therefore, in addition to performance-based differentiated traffic processing through DiffServ, it is necessary to implement importance-based and urgency-based differentiated traffic processing through AQM while meeting the demands for weight reduction in and autonomy of the military network.

Considering the above requirements, this paper proposes the implementation of QoS for military networks based on the simplified DiffServ and the basic idea of AQM. In addition, this paper develops and presents differentiated traffic-processing algorithms based on performance and urgency for each service class that can be implemented through the proposed AQM. It also shows their feasibility through some experiments.

The rest of this paper is organized as follows. In Section 2, we briefly explain related works. In Section 3, we explain the proposed AQM algorithms for the four service classes. Then, Section 4 presents experiments and their performance results. Finally, a conclusion is drawn in Section 5.

2. Related Works

QoS implementation approaches can be divided into a flow-based approach and a class-based approach, and each is represented by Integrated Services (IntServ) [9] and Differentiated Services (DiffServ) [6]. Although IntServ and DiffServ are very old standards, they are still widely used due to their high degree of maturity. Most commercial equipment adopts DiffServ, which is more advantageous in terms of scalability, but the absolute guarantee of important flow-required performance of IntServ or flow-based QoS is an advantage that is difficult to give up. Therefore, a flow-based QoS approach is evolving into a standard named Time Sensitive Networking (TSN) [10,11,12,13] or Deterministic Networking (DetNet) [14,15,16]. In addition, there are studies that try to combine the two approaches [17].

It is a very popular research approach to further improve QoS by applying the latest trendy techniques to the good traditional techniques. Recently, big data or machine learning technology has been attempted in various fields. There are also efforts to support QoS more intelligently, especially in DiffServ [18].

The authors in [19] proposed a machine learning framework to dynamically further segment existing traffic classification mechanisms. Additionally, the authors in [20] proposed a machine learning-based service class classification for encrypted traffic.

The authors in [21] proposed an IOTA-based QoS guaranteed Flow system (IQF), a system that improves QoS by utilizing a blockchain or cryptocurrency technology. IOTA is a cryptocurrency designed specifically for the Internet of Things (IoT).

The development of networks goes hand in hand with the development of applications. This is because an emerging network meets the needs of new applications and enables the emergence of new applications. Recently, with the advent of 5G, Software Defined Networking (SDN) is attracting attention, and SDN-based QoS control is one of the popular research topics [22].

Next-generation communication systems such as 5G must support new applications that require finer QoS. The authors in [23] proposed a flow-based QoS control and Context-oriented Transport (CoT) that understands application behavior and adapts to the dynamic state of the network. CoT is an end-to-end software solution that improves the underlying network capabilities.

A study to test and evaluate the performance of existing QoS algorithms for a specific network also has practical value. The authors in [24] tested three QoS algorithms for Multiprotocol Label Switching-Traffic Engineering (MPLS-TE) networks: Priority Queuing (PQ), First In First Out (FIFO), and Weighted Fair Queuing (WFQ). As another practical approach, there is also a study to apply QoS to an existing network that did not apply QoS. The authors in [25] proposed the QoS application extension for Information Centric Networking (ICN) [26].

Apart from QoS factors for DiffServ, additional factors such as energy consumption and resource utilization are also important for improving overall network performance and supporting specific tactical applications with computing intensive features in military networks [27,28,29,30].

Most of the latest studies related to QoS are being carried out as improvements by applying the latest technology to the traditional QoS technology. This paper also pursues QoS improvement based on the proven existing technology, i.e., DiffServ. However, other studies assume a very stable commercial communication network and incorporate trendy technologies. In this regard, this paper aims to differentiate QoS with the triple-metric (i.e., performance, importance, and urgency) as an improvement in reliable and proven methods, focusing on lightweight and autonomous QoS technologies for military networks that can be very poor. The enhancement of the proposed solution needs to be continuously discussed in order to support additional requirements according to specific tactical applications in military networks.

3. Triple-Metric-Based Active Queue Management Algorithms

Since the requirements for importance and urgency are different for each service class, the corresponding processing algorithm must also be implemented differently for each. In this regard, this paper develops all algorithms to operate simply when enqueuing and dequeuing considering performance, because processing in the queue is usually computationally expensive.

3.1. Service Class Classification

This paper cites and uses the service class classification result of the previous study [2]. In

Table 1. Service classes.

Service Class	Examples	Note
Control	Network Control	-
Real-Time Multimedia	Telephony, Conferencing	Inelastic
Low-Latency Data	Chatting, Messenger, Web Application	Elastic
Best Effort	Others	Elastic

, the “Control” service class illustrates the network control traffic, the “Real-Time Multimedia” service class showcases voice or video traffic for real-time communication between users, the “Low-Latency Data” service class includes data traffic for real-time information sharing or interaction between users and applications, and others are the “Best Effort” service class.

This service class classification integrated twelve service classes of the DiffServ standard into four. Based on the simplified service class classification, this paper proposes the highest QoS requirements of the integrated service classes, reflecting the QoS characteristics applicable to different types of traffic in each service class (see

Table 2. Service class characteristics.

Service Class	Tolerance to
	Loss	Latency	Jitter
Control	Low	Low	Very Low
Real-Time Multimedia	Very Low	Very Low	Very Low
Low-Latency Data	Low	Low	-
Best Effort	-	-	-

).

3.2. Control Service Class Processing

All traffic of the control service class has high importance and urgency. Therefore, most DiffServ implementations allocate the control service class to the Expedited Forwarding (EF) queue and allocate sufficient bandwidth to the queue to prevent congestion. Therefore, this paper follows the same condition.

In case of network disconnection and degradation, it may not be possible to guarantee QoS even for the control service class. Therefore, resource waste can be reduced by applying AQM to drop the control service class that is not valid due to elapsed delivery time. However, because this can be implemented simply, and the result can also be expected, we do not include it in the scope of this paper.

3.3. Real-Time Multimedia Service Class Processing

In critical and emergency situations, the real-time multimedia service class may increase rapidly for reporting, sharing, and command and control (C&C). In this case, additional priorities rather than performance are required for further differentiated processing. Since all real-time multimedia traffic have almost same urgency, importance-based differentiated processing is appropriate. For this, this paper allocates the real-time multimedia service class to the Assured Forwarding 4 (AF4) queue, and applies the following AQM algorithm (Algorithm 1).

Algorithm 1: Real-time multimedia service class processing

line becomes idle if queue is not empty then  dequeue;  if length of queue <= min_threshold then   send;  else if importance of the packet == highest then   send;  else if importance of the packet >     importance of last packet in queue then   send;  else   drop;

new packet is arrived if queue is empty && line is idle then  send; else if queue is full then  drop; else if length of queue <= max_threshold then  enqueue; else if importance of the packet == highest ||     importance of the packet >     importance of last packet in queue then  enqueue; else  drop;

Algorithm 1 aims to support importance by mission priority while differentiating the performance by service class. The packet importance used in this algorithm follows the importance classification criterion of the previous study as shown in

Table 3. Importance level.

Level	Telephony/Conferencing	Data
FO (Flash Override)	Commander	Commander/Emergency
F (Flash)	Survival related	Operation Supporting
I (Immediate)	Security related	Mission Supporting
R (Routine)	Official	Administrative

. This classification is applicable to all types of traffic such as voice, video, and data.

This algorithm uses two different queue length thresholds for dequeuing and enqueuing. The threshold (i.e., the min_threshold) used in the dequeue process is set as follows. This value can be a criterion for determining the congestion of real-time multimedia traffic.

min_threshold = TS × BR_AF4 × TD_RT/N_hops

(1)

where TS is the transmission speed, BR_AF4 is the bandwidth allocation ratio for AF4 queue in a switch node, TD_RT is the tolerable delay of real-time multimedia, and N_hops is the number of hops in the route. TS depends on the size of the packet, how long the packet is. Apart from relatively static information under the given network condition, the tolerable delay (TD_RT) is considered to reflect the dynamic traffic characteristics (e.g., jitter, etc.) of the real-time multimedia service class.

If the queue length is shorter than the min_threshold, all packets in the queue can be delivered within the tolerable delay, so there is no need to apply special processing. However, when the queue length becomes longer than the min_threshold, this algorithm performs importance-based differentiated traffic processing. In this case, this algorithm sends the highest importance packet and more important packets than the previous one and drops others. In this way, this algorithm tries to guarantee the QoS of more packets of higher importance and considers the relative importance between packets. The other threshold used in dequeuing process, the max_threshold, is set as follows.

max_threshold = TS × BR_AF4 × TD_RT/HIPR/N_hops

(2)

where HIPR is the highest importance packet ratio in the queue.

If the queue length becomes longer than the max_threshold, even the packet of highest importance cannot meet its QoS requirements. In this case, this algorithm drops all packets except the most and more important packets than previous packets in the queue to strongly suppress the queue length increase.

If many packets of a real-time voice or video traffic are dropped, the voice call or video conference will be disconnected naturally. This can have a positive effect to decrease the congestion of the real-time multimedia service class.

3.4. Low-Latency Data Serivce Class Processing

The low-latency data service class includes traffic for fast and accurate information sharing and real-time interaction between users and applications. In case of critical situation low-latency data traffic can also be overwhelmed. In addition, the low-latency data service class also requires quite a high level of performance. Therefore, differentiated processing based on urgency is not appropriate for the low-latency data service class, and importance-based differentiating is required.

The many delays of low-latency are caused by human beings. Therefore, most users are quite generous to occasional short delays by communication networks. However, the failure of critical information delivery can be a significant problem. Therefore, this paper allocates the low-latency data service class to the Assured Forwarding 2 (AF2) queue and applies the following AQM algorithm (Algorithm 2) considering the reliability of the important traffic further.

Algorithm 2: Low-latency data service class processing

new packet is arrived if queue is empty && line is idle then  send; else if queue is full then  drop; else if length of queue < t1  enqueue; else if length of queue >= tn &&    importance of the packet >= n then  enqueue; else  drop;

line becomes idle if queue is not empty then  dequeue; send;

Instead of two different queue length thresholds (i.e., max_threshold and min_threshold) in Algorithm 1, Algorithm 2 uses different thresholds according to the importance of the packets. Therefore, the first threshold is set as follows.

1_st_threshold = TS × BR_AF2 × TD_lld/N_hops

(3)

where BR_AF2 is the bandwidth allocation ratio for the AF2 queue, and TD_lld is the tolerable delay of the low-latency data.

If the queue length is shorter than the 1_st_threshold, all packets in the queue can be delivered within the tolerable delay. Therefore, there is no need to apply special processing. However, when the queue length becomes longer than the 1_st_threshold, this algorithm drops the least important packets without enqueuing them. This paper sets the subsequent i_th_threshold as follows. Moreover, the i_{th_}threshold should always be greater than the (i-1)_th threshold.

I_th_threshold = TS × BR_AF2 × C × I × TD_lld/N_hops

(4)

where C is the correction factor which is assigned to the queue. The correction factor can be adjusted by the traffic ratio of the queue.

If the queue length is longer than the i_th_threshold, this algorithm drops all packets below the i_th importance without enqueuing them. Additionally, this paper does not apply a special algorithm for dequeuing. This algorithm tolerates some delays to ensure the reliability of important traffic.

3.5. Best Effort Service Class Processing

Some traffic has delivery deadline flags and it becomes worthless when it exceeds the deadline. Therefore, a packet with short remaining time to the delivery deadline has high urgency. In addition, forwarding packets that have already exceeded or will exceed the delivery deadline waste network resources.

As all control, real-time multimedia, and low-latency data service classes have a very short delivery deadline, differentiated processing based on urgency may be impossible and meaningless. However, the best effort service class requires relatively low performance and can have a different delivery deadline depending on the application. Therefore, it is possible to apply urgency-based differentiated processing to the best effort service class. Accordingly, this paper allocates the best effort service class to the Default Forwarding (DF) queue and applies the following AQM algorithm (Algorithm 3).

Algorithm 3: Best effort service class processing

new packet arrived if new packet with delivery_deadline flag &&  remain time of new packet  < expected latency then  drop; else if queue is empty && line is idle then  send; else if queue is full then  drop; else  enqueue;

line becomes idle if queue is not empty then  dequeue;  if remain time of the packet <    expected latency then   drop;  else   send;

Apart from the differentiated performance by service classes and the importance by mission priority, Algorithm 3 supports the urgency by delivery time, especially any urgency that is associated to time constraints. This algorithm avoids wasting network resources by dropping packets that exceeded or will exceed the delivery deadline.

On the other hand, not all traffic has a delivery deadline. Therefore, we need a way to tell whether a packet has a delivery deadline or not. For this, this paper uses two unused bits of Differentiated Services Code Point (DSCP) [31] in the packet header (see

Table 4. Time-limit codes.

Delivery Deadline	Code
Yes	00
No	01

).

Finally, this paper proposes a method of giving the remaining time of delivery in seconds by utilizing the Time to Live (TTL) field of the packet header. Currently, the TTL field is used to prevent packets falling into an infinite loop by setting the maximum number of hops. However, as the name “Time To Live” suggests, its original use was to impose a remaining time of delivery by Nagle in 1987 [32]. This paper proposes to utilize the TTL field for both purposes.

4. Experiments

4.1. Simulation Environment

Figure 1 shows the switch node configuration of a military network for setting up the simulation environment of our entire study. This paper uses a part of that environment. We implemented our proposed simulation model (see Figure 2 for details) in each switch node of the military network supporting each military device with the traffic generator.

For the configuration of the simulation model as shown in Figure 2, this paper considered the following conditions.

• Bandwidth: 2048 Kbps, 256 byte packet;
• Service Class Traffic Combination: EFRate 12%, AF4Rate 38%, AF2Rate 25%, DFRate 25%;
• Queue Size: EFQueueSize 1000, AF4QueueSize 1000, AF2QueueSize 1000, DFQueueSize 1000;
• Threshold: 1_st_threshold 0.25, 2_nd_threshold 0.51 and 3_rd_threshold 0.76 of Queue size.

To implement the proposed triple-metric-based AQM, packets with four different service classes are simultaneously generated with different ratios. They have different priorities, importance levels and time-limit flags. As shown in Figure 3, the importance of all EF traffic is 0 (high priority). The importance is randomly allocated between 0 and 3 to the AF4 and AF2 traffic. In case of the DF traffic, time sensitive information is randomly allocated. Then, each switch node processes individual packets according to the proposed algorithms.

In this experiment, importance is applied to the EF, AF4, and AF2 traffic, requiring real-time or near real-time delivery, and a delivery deadline is applied to the DF traffic, requiring efficient delivery. The followings show the details of importance and delivery deadline assignment policy.

• The highest importance (FO) is assigned to the EF traffic;
• Four importance values (FO, F, I, R) are randomly assigned to the AF4 and AF2 traffic;
• Delivery time-limit flags (true, false) are randomly assigned to the DF traffic. A false delivery time-limit flag is fixedly assigned to the EF, AF4, and AF2 traffic.

For the experimental analysis of the proposed triple-metric-based AQM algorithms to support performance by service class, importance by mission priority, and urgency by delivery time simultaneously, we aim to focus on the performance of the AF4, AF2 and DF traffic according to importance and urgency while guaranteeing high performance of the EF traffic. In this regard, we applied importance-based differentiated processing (Algorithm 1 in Section 3.3) for the AF4 traffic and different loss thresholds considering the reliability (Algorithm 2 in Section 3.4) for the AF2 traffic while satisfying the delay characteristics. In addition, we applied urgency-based differentiated processing (Algorithm 3 in Section 3.5) for the DF traffic. The aim of the experimental analysis was to demonstrate the outstanding characteristics of the optimized algorithms (Algorithms 1, 2 and 3) to the simplified DiffServ.

4.2. Performance of Non Real-Time Traffic (DF)

By allocating importance and delivery deadlines to the DSCP, traffic with an imminent delivery deadline can be delivered firstly. In the case of traffic within the delivery time limit of 1 (true), the traffic is dropped when the delay exceeds the specified time.

Figure 4a shows the latency characteristics according to the delivery time-limit value by changing the DF traffic load to 80–200% with only the DF traffic as input. As the input load increases, so does the traffic propagation delay. Traffic for which the delivery time-limit flag is true is dropped when the delay exceeds the specified time. Therefore, the delay of the transmitted traffic without being dropped can be maintained within the specified time.

Figure 4b shows the difference between when the delivery time-limit flag is set (1, the traffic that has passed the specified time is dropped) and when there is the false delivery time-limit flag (0). When the input load exceeds 100%, it is dropped by the amount of excess traffic. As shown in Figure 4b, traffic within the delivery time-limit flag of 1 is dropped. The proposed method shows that the maximum propagation delay can be limited within a certain value even for traffic of the best effort service class.

Through this experiment, it was confirmed that the suggested algorithm works well. By dropping invalid packets that have passed the delivery deadline, we were able to avoid wasting resources and deliver more valid packets.

4.3. Performance of Real-Time Traffic (AF4)

For the F4 traffic, the processing method is determined according to the queue length and importance. Figure 5a confirms the result while changing the load to 80–200% with only the AF4 traffic as input, and randomly assigns four levels of importance (FO, F, I, R). In this result, when the load exceeds 100%, transmission delay occurs; however, when the queue length exceeds the threshold, a drop is made so that the delay does not increase excessively. A typical maximum tolerable latency for multimedia traffic is around 150 ms [33], and it can be seen that all traffic latencies in the experiment are less than 150 ms.

Figure 5b shows the AF4 traffic loss characteristics with the four levels of importance randomly assigned. Since the FO traffic with the highest importance does not drop regardless of the queue length, the loss value is maintained at 0, and it can be seen that the loss rate of the F, I, R traffic having the remaining three importance values (i.e., 1, 2 and 3) varies according to the loss threshold.

As the load exceeds 100%, the R traffic-oriented loss occurs, and the F, I traffic loss rapidly increases to around 160%.

From this result, in the case of the AF4 traffic, delay differentiation by importance hardly appears and affects the loss differentiation. Therefore, it can be seen that it is effective for the bounded latency of traffic of the real-time multimedia service class and loss-free delivery of high-importance traffic in case of overload by considering both the queue length threshold and the importance within the same service class.

4.4. Performance of Low-Latency Traffic (AF2)

Figure 6a confirms the result while changing the load to 80–200% with only the AF2 traffic as input, and randomly assigns four levels of importance (FO, F, I, R). When the load exceeds 100%, the delay increases rapidly. Even with the different loss rates for each importance value, the delay is up to 140%. At an input load above 133%, the traffic with the R importance is mostly dropped, so latency appears to be reduced. The traffic with the I importance is also lowering the average delay due to excessive loss at 180% or higher.

The AF2 traffic randomly assigns four importance values (i.e., 0, 1, 2 and 3), so the following results are expected:

• 0~100%: there should be no loss of traffic;
• 100~133.3%: only part of the R traffic is lost;
• 133~200%: 100% of the R traffic is lost and some of the I traffic is lost;
• 200% or more: some of the F traffic is lost.

Consistent with the above expectation, from Figure 6b, it can be seen that as the load increases, low-importance traffic loses firstly, and the F traffic starts to lose at 1800% load. It is earlier than our expectation. The cause is that there are packets with various importance values in the queue already, and our algorithm gives more priorities to the packets in the queue than the new arriving packets.

Therefore, for the AF2 traffic, it affects the delay and loss differentiation by importance. It has a clear effect on the loss-free delivery of high-priority traffic when overloaded within the same service class.

4.5. Performance of Latency and Loss by Service Class

In Section 4.2, Section 4.3 and Section 4.4, we have demonstrated the performance behaviors of the individual service classes, i.e., the DF, AF4 and AF2 traffic, respectively. This section shows the performance analysis results for the delay and loss for each service class when the four classes of traffic are mixed, as we have explained with the Figures in Section 4.1.

Figure 7a shows that when the load exceeds 100% in traffic environments with the four service classes, the delay increases sequentially from the low priority traffic. For the DF and AF2 traffic, the delay increases when the input load exceeds 100% and 180%, respectively, and the highest priority EF and AF4 traffic maintains a low delay up to a 200% load.

As mentioned earlier in the simulation environment, the following behavior is expected because the ratio of the input traffic is EF (12%), AF4 (38%), AF2 (25%), and DF (25%).

• Loss of the DF traffic occurs when input exceeds 100%;
• Loss of the AF2 traffic occurs when input exceeds 133.3%;
• Loss of the AF4 traffic occurs when input exceeds 200%.

Figure 7b shows that, consistent with the above prediction, the loss of the DF traffic increases when the load exceeds 100%, and the loss of the AF2 traffic occurs when the load exceeds 140%. When the total load reaches 200%, the sum of the EF and AF4 traffic, which are the highest priorities, becomes 100%, so it is the point at which the loss begins (some loss occurs).

Next, we look at the delay and loss characteristics according to the importance of each service class. In Figure 8a, the delay increases as the traffic load increases, but the delay of the FO traffic with high importance increases slowly.

Figure 8b shows that when the load exceeds 100%, the loss of traffic for all the importance values occurs. Moreover, for the traffic with the higher importance value, the drop rate decreases.

Finally, the results of the performance analysis on traffic differentiation according to the delivery time are reviewed.

At 100% load, the DF traffic starts to lose, and at 133% load, 100% of the DF traffic will be dropped. Therefore, the meaningful period in Figure 9a is the 100~133% load as highlighted with the rectangular box in Figure 9b. Since the delivery time limit is 0 (false) for all EF, AF4, and AF2 traffic and 50% of the DF traffic, a delay at a load of 133% or more represents the average of the traffic delays of the four service classes. Traffic within the delivery time limit of 1 (true) is 50% of the DF traffic, and the delay is maintained within a certain level in the meaningful range from 100 to 133%, and it seems to converge to 0 because the amount of delivery is too small in the period where the loss is excessive.

That is, since only half of the DF traffic has the delivery time of 1 (true), it is responsible for maintaining the delay within a certain range only in the 100–133% load period, and the delay appears as “0” at a load of 133% or more because all traffic has been dropped.

As mentioned earlier, the traffic within the delivery time limit of 0 (false) is the traffic that includes all EF, AF4, and AF2 traffic and 50% of the DF traffic (occupies 75% of the total traffic), and only the DF traffic in the 100–133% load range. If a drop occurs and the delivery delay exceeds the time limit, traffic within the delivery time limit of 1 (true) is dropped first. At a load of 133% or more, the AF2 traffic starts to drop, so the drop of traffic within the delivery time limit of 0 (false) gradually increases. Traffic within the delivery time limit of 1 (true) occupies 12.5% of the total traffic, so if the total load is 200%, a 25% drop occurs.

The last result shown in Figure 9c is a case where the traffic with the four service classes are mixed, and differentiation according to time limit appears in the 100–133% load period. It can be seen that the drop according to the delivery time limit is controlled in the DF traffic, which is the lowest priority, so that it is effective in delivering the traffic within a time limit even when overloaded.

5. Conclusions

The simplified DiffServ and triple-metric-based AQM-based QoS implementation proposed in this paper improves the delivery characteristics required in the military network by the importance and delivery time-limit flags.

Among the four service classes, four levels of importance were assigned to the AF4 and AF2 service classes. In case of overload, by assigning different loss thresholds for each importance, high-importance traffic could be delivered first. It was verified that it is possible to guarantee the delivery of the most important traffic without degrading the delay characteristics.

For the DF traffic, a method of dropping traffic exceeding the delivery time limit was applied in case of overload. It was verified that the waste of network resources can be reduced and as a result, the delay of transmitted traffic can be maintained within a certain value.

This can be applied as a method to ensure the delivery of important traffic even when it is overloaded in the military network. Apart from the triple-metric, we believe that other factors such as energy consumption and resource utilization are also important. For future research, we will further focus on the enhancement of the proposed solution considering other QoS factors for some specific tactical applications with different requirements while improving overall network performance.