This paper describes a hierarchical queuing mechanism designed to monitor and control radio buffers while delivering web services in tactical networks. Our solution was motivated by the restrictions imposed by VHF radios, which have large coverage (∼20 km) but very low data rate (e.g. up to 9.6 kbps). Therefore we implemented two queues, one for messages (Qm) and another for IP packets (Qp), shaping the user-generated data traffic to avoid buffer overflow. The queues complement each other, behaving like control points in a feedback loop. Both control points use the current radio buffer occupancy to decide when to dequeue messages and IP packets. We studied the performance of a prototype in a testbed using real military radios with focus on two variations of our control mechanism (reactive/proactive). The quantitative analysis shows our queuing mechanism successfully avoiding buffer overflow under challenging network conditions.

1. A Queuing Mechanism for Delivering
QoS-constrained Web Services in Tactical Networks
Roberto Rigolin F. Lopes, Antti Viidanoja, Maximilien Lhotellier, Anne Diefenbach,
Norman Jansen and Tobias Ginzler
roberto.lopes@fkie.fraunhofer.de
23th May 2018, Warsaw - Poland
Research supported by BAAINBw and WTD-81
#ICMCIS 2018
2014-2017

2. In Short
Deploying Web Services over Tactical Networks
a) Web Services
• User services: Obstacle Alert, FFT and MEDVAC
b) Middleware
• Tactical Service-oriented Infra (TSI)
c) Tactical Networks
• Heterogeneous ad hoc networks <UHF><VHF> <SatCom>
TSI
<Core Services>
OAS FFT MEDVAC
2014-2017
A
B
C
Changing
ChangingNetwork conditions:
User behavior:

3. Overview
1) The problem: buffer overflow
2) A solution (reactive)
3) A better solution (proactive)
• Two analogies for messages:
• Water (humans)
• Container (machines)
<MESSAGE> <MESSAGE>2014-2017
<human> <machine>
What if the user-generated dataflow exceeds
the network capacity?

4. The problem : BUFFER OVERFLOW
• Creating a control loop for the data pipe-lines:
Sender
Receiver
Radio – PR4G
<radio>
<sender>
<receiver>
<brain>
<eyes>
<hand>
<sending>
?
?
?
<control plane>
<data plane>
<data plane> <data plane>

5. The problem: BUFFER OVERFLOW
• Formulation:
∆𝐵𝑟=
𝑖=0
𝑇
𝛼 𝑟 𝑖𝑛 𝑟 − 𝛽𝑟 𝑜𝑢𝑡 𝑟
0.6 kbps
1.2 kbps
2.4 kbps
4.8 kbps
9.6 kbps
zUkWcE7uWxvXgkH5Z
hGpJ/Ehr8CDohpY/AVy
1QkCDuA0eszi/LzhYf1B
K+23OasWSTHjaMhGN
AOfwdDoYy0ewxOngwI
gcAbYWigkZw/qvP7n6i1
EiAKYpqDKg+VDKTCVyn
ToO80qdYeskgd7ZHv2lv
500 kB
<message>
87% loss
26% loss
45% loss
63% loss
80% loss
87 % loss
26 % loss

6. Network topology
VHF
9.6 kbps – 20km
3 of 32 nodes
UHF
240 kbps – 2km
3 of 14 nodes
Deployed
Mobile
Dismounted
SatCom
D1 D2,...,Dw
M2,...,Mx
HQ
Node types and radios:
VHF - PR4G
UHF - St@rMille
Platoon: up to 60 radios
Squads: up to 14 radios
Up to 32 radios
M1
Sender:
Receiver:
<overflow>
1
2
3
32 x 14 = 448
Worst case network setup:

7. Sketching a solution
<queue>
…CIS Capabilities
Technical Services
Communication Services
Transmission Services
Transport Services
Communication Access Services
Core Enterprise Services
SOA Platform Services
Enterprise Support Services
COI Services
COI-Enabling Services
COI-Specific Services
User-Facing Capabilities
User Applications
Infrastructure Services
Cross-layerdataexchange
COI-Specific Services
Radio plug-in
Qm1
Qp0,1
B1In
Out
λx
TSI
<middleware>
IP Packet(s)
Message(s)
Proxy
Service(s)
QoS
Context
1
2
3
4
1
2
3
4
Hierarchy of queues complementing each other
to avoid buffer overflow.

8. The solution <messages>
<message>
<IP packets>
<radio buffer>
Priority
0 FLASH
1 Immediate
2 Priority
3 Routine
Sleep x: queue 0: dequeue
No: queue Yes: dequeue
How long to admission?
Buffer below b%?
Sender
User service(s)
3
ε4
ε3
ε1
Invoke:
λx
QoS Handler
Receiver(s)
out
αin
i
ii How much to b%?
Cross-layerContextualMonitoring
4Proxy
Message Queue
1
UDP Transport
Packet Handler
2
Routing ε2

9. How TSI is doing this?
Packet Handler
Buffer: 100%
1
<=10%
>10%
<radio>

10. The solution in action
• Meanwhile, what the Message Queue is doing?
• Sleeping and asking the QoS Handler: How long to admission?
Message Queue
𝑄𝑝0 + 𝑄𝑝 𝑛 + ∆𝐵
∆out
1
3
~8 min
~3 min2
0 min

11. QoS-constrained Web Services
• Message Queue tasks:
• Sort by priority, replace, drop expired messages
Service Priority Reliability ToE(sec)
MEDEVAC 0 FLASH Yes 300
Obstacle Alert 1 Immediate Yes 150
Picture 2 Priority Yes 3600
FFT 3 Routine No 120
0
1
2
3
OAS FFTMEDVAC
0
1
2
3
3
3
3
Sort, replace
and drop
<newest>
Continuous
hygiene

12. Different configurations
• Why a 10% threshold?
• Studying the effects of different b% threshold in the queue of packets and
buffer occupancy as a function of time
Radio buffer occupancyQueue of packets

13. Queue of packets (Qp)
70% 60% 50%
10% 5% 1%
40% 30% 20%

14. Radio buffer (ΔB)
<overflow> <overflow>
<underflow>
70% 60% 50%
40% 30% 20%
10% 5% 1%

15. Proactive solution
• How much to b%?
𝛼 = 𝜔/
(𝐵 ∗ 𝑏) − ∆𝐵
𝑀𝑇𝑈
𝛼
Time window (𝜔)
𝛼 𝛼 ∆𝐵
Potential delay at queue of packets
𝑀𝑇𝑈 𝑀𝑇𝑈 𝑀𝑇𝑈 𝑀𝑇𝑈
Inter-packet delay:

16. Conclusion
• The system relies only on the local awareness
of the current network conditions
• Hierarchical layers complementing each other
in a control loop seems to be a good idea:
• Reactive control equals to less control
• Proactive control means more control
• The model:
𝑁𝑜𝑑𝑒 𝑛
𝑟
𝑀𝑒𝑠𝑠𝑎𝑔𝑒 𝑥 λ, 𝑃, 𝑅, 𝑇, 𝐸
𝑄𝑢𝑒𝑢𝑒 𝑟 𝑄𝑚, 𝑄𝑝0,𝑟, 𝐵
𝐶𝑜𝑛𝑡𝑒𝑥𝑡 𝑟(∆𝑖𝑛, ∆𝑜𝑢𝑡, ∆𝐵, ∆𝑛𝑒𝑡)
Communications
Core Services
COI Services
Cross-layer

17. A Queuing Mechanism for Delivering
QoS-constrained Web Services in Tactical Networks
Roberto Rigolin F. Lopes, Antti Viidanoja, Maximilien Lhotellier, Anne Diefenbach,
Norman Jansen and Tobias Ginzler
roberto.lopes@fkie.fraunhofer.de
23th May 2018, Warsaw - Poland
Research supported by BAAINBw and WTD-81
#ICMCIS 2018 – The end
2014-2017
<message delivered>