MASTER’S DEGREE PROJECT, ICT INNOVATION STOCKHOLM, SWEDEN 2018
Service Aware Traffic
Distribution in Heterogeneous
A2G Networks
DAVID TOMIĆ
Abstract
Airplanes have different ways to connect to the ground, including satellite air-to-ground communication (SA2GC) and direct air-air-to-ground communication (DA2GC). Each connection/link offers a different varying amount of transmission capacity over flight time. The traffic generated in the airplane must be forwarded/sent to ground over the available links. It is however not clear how the traffic should be forwarded so that traffic quality of service (QoS) requirements are met. The thesis at hand considers this question, and implements an algorithm handling the forwarding decision with three different forwarding schemes. Those consider traffic parameters in calculating a value assigned to each traffic flow, over a combination of priority, delay requirement and the number of times a traffic flow is dropped. The forwarding algorithm relies on proposed in-flight broadband connectivity (IFBC) network traffic and air-to-ground (A2G) link models, which aim at approximating the network environment of future IFBC networks. It is shown that QoS requirements of traffic flows in terms of packet loss and delay cannot be satisfied with capacities offered by current DA2GC and SA2GC technology. For a future scenario, with higher assumed link capacities, the QoS requirements are met to a higher extent. This is shown in lower packet loss and delay experienced by the respective traffic flows. Further, it is shown that the performance can be improved with specific forwarding schemes used by the forwarding algorithm. It is also investigated how a web cache can be used as a fallback technology. For this a required web cache hit rate is found, which should be high enough to offload the network with content served from the cache. Overall, the thesis aims at proposing an efficient traffic forwarding technique, and at giving insight into an alternative if this technique fails. Keywords
Sammanfattning
Flygplan har olika sätt att ansluta till marken, inklusive satellit-mark-kommunikation (SA2GC) och direkt luft till marksatellit-mark-kommunikation (DA2GC). Varje anslutning/länk erbjuder en annan varierande mängd överföringskapacitet under flygtid. Den trafik som genereras i flygplanet måste vidarebefordras/skickas till marken över de tillgängliga länkarna. Det är emellertid inte klart hur trafiken ska vidarebefordras så att trafiksäkerhetskvaliteten (QoS) uppfylls. Avhandlingen handlar om denna fråga och implementerar en algoritm som hanterar vidarebefordringsbeslutet med tre olika vidarebefordringssystem. De betraktar trafikparametrar vid beräkning av ett värde som tilldelas varje trafikflöde, över en kombination av prioritet, fördröjningskrav och antalet gånger ett trafikflöde tappas. Vidarebefordringsalgoritmen är beroende av föreslagna bredbandsförbindelser (IFBC) i nätverk och A2G-länkmodeller, som syftar till att approximera nätverksmiljön för framtida IFBC-nätverk. Det visas att QoS-krav på trafikflöden när det gäller paketförlust och fördröjning inte kan tillgodoses med kapacitet som erbjuds av nuvarande DA2GC- och SA2GC-teknik. För ett framtida scenario, med högre antagna länkkapacitet, uppfylls QoS-kraven i högre utsträckning. Detta visas med lägre paketförlust och fördröjning som upplevs av respektive trafikflöden. Vidare är det visat att prestanda kan förbättras med specifika vidarekopplingsscheman som används av vidarebefordringsalgoritmen. Det undersöks också hur en webbcache kan användas som en återgångsteknik. För detta hittas en obligatorisk webbcache-träfffrekvens, som bör vara tillräckligt hög för att ladda upp nätverket med innehåll som serveras från cacheminnet. Sammanfattningsvis syftar uppsatsen till att föreslå en effektiv trafiköverföringsteknik och att ge insikt om ett alternativ om denna teknik misslyckas.
Nyckelord
Bredbandskommunikation i flygning, direkt marknadskommunikation, satellit-till-jord-kommunikation, vidarebefordringsalgoritm,
List of Acronyms
IFBC In-Flight Broadband Connectivity A2G Air-to-Ground
SA2GC Satellite Air-to-Ground Communication DA2GC Direct Air-to-Ground Communication GEO Geostationary
QoS Quality of Service
KPI Key Performance Indicator
3G Third Generation Mobile Network HSPDA High-Speed Downlink Packet Access 4G Fourth Generation Mobile Network LTE Long-Term Evolution
5G Fifth Generation Mobile Network SDN Software Defined Network
ACD Aircraft Control Domain
AISD Airline Information Service Domain PODD Passenger Owned Devices Domain MTC Machine Type Communication FR Flight Recorder
HM Health Monitor
CDN Content Delivery Network EAN European Aviation Network VoIP Voice over IP
ns-3 Network Simulator 3 UDP User Datagram Protocol
TCP Transmission Control Protocol IP Internet Protocol
List of Figures
Figure 1: IFBC use case - devices generating traffic flows, available links and forwarding algorithm
Figure 2: SDN architecture and the OpenFlow protocol [3]
Figure 3: SDN with communication domains, output links and network application allocating resources running on top
Figure 4: Airplane traversing cells with different activity levels Figure 5: Map of Europe, sectored into spots of 80km
Figure 6: Example of varying link conditions (scenario 1) Figure 7: Forwarding algorithm – pseudocode
Figure 8: Input traffic variation over simulation time
Figure 9: Percentage of dropped packets for traffic flows from the PODD domain (forwarding scheme 1, scenario 1 and scenario 2)
Figure 10: Percentage of total simulation time spent on the SA2GC link for VoIP flows from each travel class (forwarding scheme 1, scenario 1 and scenario 2)
Figure 11: Remaining capacity on the DA2GC and SA2GC links during a simulation lasting 1 hour (forwarding scheme 1, scenario 1)
Figure 12: Percentage of dropped packets for traffic flows from the MTC and mission critical domains (forwarding scheme 1, scenario 1 and scenario 2) Figure 13: Percentage of dropped packets for traffic flows from the PODD domain (forwarding scheme 2, scenario 1 and scenario 2)
Figure 14: Percentage of total simulation time spent on the SA2GC link for VoIP flows from each travel class (forwarding scheme 2, scenario 1 and scenario 2)
Figure 15: Percentage of dropped packets for traffic flows from the PODD domain (forwarding scheme 3, scenario 1 and scenario 2)
Figure 16: Percentage of total simulation time spent on the SA2GC link for VoIP flows from each travel class (forwarding scheme 3, scenario 1 and scenario 2)
Figure 18: Monte Carlo simulation, percentage distribution of required cache hit rates for each forwarding scheme (scenario 2)
Figure 19: Percentage of dropped packets for traffic flows from the PODD domain (scenario 1, all forwarding schemes) – showing the simulation run at which QoS thresholds were met
List of Tables
Table 1: LTE traffic mix, with the usage ratio per application [26] Table 2: IFBC PODD traffic mix, with the usage ratio per application Table 3: IFBC traffic generating devices
Table 4: Number of traffic generating devices per application and class
Table 5: Communication domains with the respective priority and delay requirement
Table 6: Traffic flow behaviour and data rate for each application
Table 7: Distribution of the numbers of airplanes occurring for each spot size Table 8: Numbers of airplanes in inactive, normal and active spots – for each spot size
i
Table of Contents
List of Acronyms ... List of Figures ... List of Tables ... 1 Introduction... 1 1.1 Motivation ... 1 1.2 Background ... 1 1.3 Related Work... 6 1.4 Problem Statement ... 8 1.5 Methodology ... 9 1.5.1 Traffic Model ... 9 1.5.2 Link Model ... 9 1.5.3 Forwarding Algorithm ... 10 1.5.4 QoS Requirements ... 10 1.5.5 Network Topology ... 10 1.5.6 Simulations ... 101.5.7 Monte Carlo Simulations ... 11
2 Conception... 12
2.1 Traffic Model ... 12
2.1.1 Priorities and Delay Requirements ... 14
2.1.2 Data Rates and Traffic Characteristics ... 15
2.2 Link Model ... 16
2.2.1 Capacity Scenarios ... 17
2.2.2 Air Traffic Analysis ... 17
2.3 QoS Requirements ... 21
2.3.1 Packet Loss... 21
2.3.2 Delay ... 22
2.4 Forwarding Algorithm ... 23
2.4.1 Forwarding Schemes ... 23
2.4.2 Forwarding Algorithm Description ... 24
2.4.2.1 Limitations ... 27
2.5 Web Cache ... 28
3 Implementation ... 29
3.1 Simulation Environment ... 29
3.1.1 Network Topology with ns-3 ... 29
3.1.2 Queue Management ... 31 3.2 Web Cache ... 32 4 Results ... 33 4.1 Forwarding Schemes ... 34 4.1.1 Forwarding Scheme 1 ... 34 4.1.2 Forwarding Scheme 2 ... 40 4.1.3 Forwarding Scheme 3 ... 41 4.2 Performance Comparison... 43
4.3 Monte Carlo Simulation ... 44
1
1 Introduction
With a growing interest in in-flight broadband connectivity (IFBC), various parties from the industry are posed with the task of researching new solutions to meet the demand thereof. In the advent of 5G, connectivity will be required at high travel speeds and altitudes, while delivering unprecedented levels of reliability and data rates [1].
Connectivity for airplanes can be provided, amongst other options, over satellite air-to-ground communication (SA2GC) and direct air-to-ground communication (DA2GC). With traffic flows coming from/going to the devices in the airplane, it is important to find which should be forwarded over SA2GC, and which over DA2GC. Traffic flows originate from a set of applications, each with different quality of service (QoS) requirements. They also vary in intensity, as passenger activity is changing over flight time. Link conditions are on the other hand changing due to airplane movement, and handovers to base station and satellite cells with varying activity levels – sharing the transmission capacity offered in a cell with other airplanes.
The decision as to which flow should be forwarded over which link (forwarding decision; link allocation), as well as which shall be dropped in an overload situation (low link capacity periods), depends on the traffic and link conditions outlined above. It needs to be done so to keep traffic QoS parameters below predefined threshold values.
1.1 Motivation
The thesis is motivated by the need for a traffic forwarding decision algorithm which can ensure that QoS and throughput requirements of the forwarded traffic are met. It is also motivated by the lack of appropriate traffic and link models which can be used in the forwarding decision. Further, since today’s networks will hardly handle the amounts of traffic expected with future IFBC [1], and it is not ensured that future link capacities will suffice either, part of the motivation is to investigate a fall-back technology if traffic QoS requirements are not met with a found forwarding algorithm.
Overall, the thesis is driven to offer a solution to the link allocation problem at hand. It shall yield a traffic forwarding algorithm which considers the outlined requirements and constraints, and test it over different configurations on fitting technology.
1.2 Background
To aid overall understanding of the thesis, some general terms and technologies used are outlined below. Those concern the type of traffic flows and where they are generated, links used and what they are based on, and the overall network topology used in the solution implementation.
2 flows. Those flows are destined for other devices on ground, and each have different characteristics in terms of traffic shape and QoS requirements. The flows are assumed to be forwarded over the links based on decisions of an algorithm developed for this purpose. The overall picture of this scenario can be seen in Figure 1.
Figure 1: IFBC use case - devices generating traffic flows, available links and forwarding algorithm
The traffic flows under consideration originate from:
• Aircraft Control Domain (ACD) – safety essential systems managing the airplane and the flight
• Airline Information Service Domain (AISD) – safety non-essential systems, destined for maintenance and crew communication
• Passenger Owned Devices Domain (PODD) – passengers’ personal communication devices (e.g. smartphones, tablets, laptops…)
• Machine Type Communication (MTC) – inter-connected devices (e.g. temperature sensors, cargo tracking sensors), generating and transmitting information to ground
• Flight Recorder (FR) – devices capturing flight data and cockpit voice • Health Monitor (HM) – devices capturing thousands of airplane health
3 QoS refers to the performance of traffic flows in terms of a set of parameters [2]. Those are for this thesis chosen to be packet loss and delay. For it to be met, threshold values defined for these parameters shall not be exceeded. The links under consideration, over which traffic can be forwarded are:
• Direct Air-to-Ground Communication (DA2GC) – a ground network of base stations, of varying cell sizes and activity levels. The airplane is connected to a base station over an antenna mounted to the body of the airplane. As it moves, it is handed over from one base station to another, receiving a share of the total base station capacity. With DA2GC traffic flows can experience less delay, however the coverage offered with such a network is limited mostly to land masses (continental).
• Satellite Air-to-Ground Communication (SA2GC) – geostationary satellites providing access to the ground core network. Handover and capacity sharing apply here too, with the difference that satellite cells are much larger – hence less handovers and a smaller share of capacity can be expected. Although with SA2GC there is a higher delay to be expected for traffic flows, its coverage is worldwide.
The network topology over which traffic flows are forwarded is chosen to be based on SDN, which is a networking paradigm separating the control and data plane of the network [3]. An SDN switch is hence only handling the forwarding task, while the logic behind forwarding is moved to the control plane. This plane does not have to be collocated with the switch.
4 Figure 2: SDN architecture and the OpenFlow protocol [3]
5 Figure 3: SDN with communication domains, output links and network application allocating resources running on top
6 The cache hit rate would need to be high enough, so that QoS thresholds of the flows are not exceeded. Web caches found in e.g. content delivery networks (CDN) are often advertised to have cache hit rates of up to 99% [4]. Those are however not comparable to web caches which could be used in airplanes. CDN caches are organized in hierarchies, with a high number of cache instances before the origin. In contrast, an airplane would not be able to carry such infrastructure on board. For the IFBC use case then, those hit rates cannot per se be taken as a measure. This work will calculate them based on the performance of traffic flows, and give insight into the hit rate requirements for IFBC web caches.
1.3 Related Work
Research on IFBC is in a relatively early stage – the few works found on this topic do not offer solutions for the link allocation problem at hand. However, other aspects of such connectivity in airplanes get elaborated on. In [5] an extensive survey on SA2GC and DA2GC is given, explaining the concept behind each link (e.g. radio bands used, achievable data rates), and defining the business ecosystem required for provisioning them. The respective link data (capacity, delay) given can aid the link modelling done in this thesis. In [6] more details for each of the two technologies are given, along with a comparative analysis of 4G and 5G DA2GC, as well as SA2GC. The signal quality and capacity achieved over each link get compared and evaluated, while considering airplane movement. Although 5G DA2GC shows to perform best, no suggestions as to under which circumstances a link should be chosen are given.
In [7], information about the European Aviation Network (EAN), the first 4G DA2GC and SA2GC network in Europe is given. A heterogeneous network is utilized in providing in-flight connectivity. Extensive infrastructure investments have been made, and the true performance of the system is yet to be displayed (proof of concept has only been done on small scale – i.e. small airplane and low number of devices accessing internet). [8] contains information on this project written by Nokia. In that work a good overview of the technical requirements for LTE DA2GC, and a comprehensive comparison to those of SA2GC is given. The projected 75Mbit/s connection speed have been achieved with the trials to date. Since their solution is proprietary, no technical details on the implementation of IFBC is given.
7 400 cells monitored over the course of three days, researchers in [11] create traffic models. Those are interesting because they come from analysis of a real trace. Their results can be used while creating traffic models needed for this thesis. In [12] a large-scale comparison of proposed traffic models from different papers is given, pointing out how different researchers arrive at differing distributions describing the same traffic types. The research points out the ambiguity which is seen when assumptions on traffic flows need to be made. In [13], Cisco is giving a good overview of VoIP data rates. These can be used while setting up traffic generators for this research. In [14], Cisco gives a “handbook” of QoS requirements which must be met for traffic traversing a network. Those can be used as inspiration in constructing a set of requirements more applicable to traffic originating from an airplane network. In [15] and [16], estimations on capacity requirements and costs of in-flight connectivity are given, based on tariffing of ground networks, and user segmentation per travel class and purpose. The research however uses only user/usage statistics from Germany, and it is very outdated – their results are hence not a relevant input to current research. [17] gives a comprehensive summary of usage statistics for mobile networks (mostly LTE). It is useful for tariffing information, and calculating throughput and capacity requirements from the given numbers (global and regional).
An offloading algorithm between LTE and WiFi is proposed in [18]. The link allocation decision is based on a utility maximization problem, where users are first allocated LTE connections, and gradually offloaded to WiFi if higher throughput and overall network utility can be achieved. Their work serves as a good example of the decision logic to be implemented in a forwarding algorithm, and the events it should react to. In [19] an SDN network with multiple virtual network slices was used as basis for a network controller, which distributes physical network resources amongst the virtual tenants. Given different requirements of each virtual slice, it is the controller’s responsibility to fairly distribute limited physical resources. The work serves well as an example of how a controller can be implemented, and in bringing forward criteria upon which a resource allocation decision can be made. [20] demonstrates how a global view over the network using an SDN controller can enable more efficient routing decisions, leading to less data loss and a better link utilization. The thesis at hand also assumes a global view over link conditions. A global view is assumed in [21] too, where an LTE to WiFi offloading scheme is investigated. The work demonstrates how feedback from the network can make users offload to WiFi more efficiently. Although concerned with link allocation, the work is scoped only to a small number of considered parameters used in the allocation decision.
8 hardly be met in-air without cached content. This serves as motivation to investigate the required properties of an IFBC web cache. In [25], required properties of web caches are analysed over web traffic traces from the Akamai CDN. However, those properties can hardly be applied for IFBC caches, given the considerable difference of the use case. In general, research on IFBC web caches is sparse – steering research into this direction with the thesis is hence reasonable.
This thesis contributes to the research to date by proposing traffic and link models which approximate the environment of IFBC networks. It further uses the proposed models in designing a traffic forwarding algorithm, which considers traffic and link conditions while deciding over which link to direct a traffic flow so that its QoS requirements are met. Furthermore, an implemented network simulator is used in calculating the web cache hit rate needed for caches which may be installed in IFBC networks. Over repeated simulations a general insight into the required hit rates is given, which should aid future planning of the properties IFBC web caches must have.
1.4 Problem Statement
Forwarding traffic to the available links in an IFBC network must be done so that QoS requirements of the applications generating the traffic are met. The high number of traffic and link parameters to be considered in that traffic forwarding decision makes this problem non-trivial. Also, current research lacks insight into the potentials and properties of web caches which can be employed in IFBC networks.
The traffic forwarding decision problem can be formulated as follows: Given:
1) traffic flows (TF) originating from applications used in-flight;
2) varying traffic intensity (TI) caused by the respective traffic generation patterns and a varying user activity level;
3) packet loss QoS requirements of the applications expressed in terms of threshold packet loss (Tresh-PL) values;
4) delay QoS requirements of delay sensitive applications expressed in terms of threshold values of the time spent being forwarded over SA2GC (Tresh-D);
5) three different forwarding schemes (FM) used to distinguish between traffic flows in terms of
a. priority (P),
b. delay requirement (DR),
c. the number of times a traffic flow was dropped (DC) due to lacking transmission capacity;
6) a DA2GC and SA2GC link;
7) total transmission capacities (TC) offered by the links;
8) varying available transmission capacities (AC) on those links;
9 Objectives:
1) Minimize PL and D of TFs;
2) Minimize the required WCH-HR. Constraints:
1) For each TF, the measured packet loss (PL) should be less than or equal to Tresh-PL;
2) For delay sensitive TFs the time spent being forwarded over the SA2GC link (D) should be less than or equal to Tresh-D.
Output:
1) Forwarding scheme(s) (FM) where QoS requirements of most or all TFs are satisfied;
2) web cache hit rates (WCH-HR) required so that QoS requirements of all TFs are satisfied.
1.5 Methodology
The forwarding algorithm to be developed needs input to make forwarding decisions. That input should be network traffic originating from an airplane, and link characteristics occurring during flight time. Since this information is not readily available – no holistic representation of network traffic/conditions in airplanes was found – it was at task to model these as close as possible. Therefore, a crucial part of the thesis was the development of a traffic and link model.
1.5.1 Traffic Model
For this model, the first parameters considered were priority and delay requirements of the traffic flows. A numbered scale was defined for each parameter (i.e. low to high priority/delay requirements), from which values are assigned to traffic flows based on the relevance of the communication domain they are originating from, and the application generating the traffic. It was then at task to define the type, shape and respective amount of generated traffic. The PODD traffic was modelled based on LTE usage statistics [26], and characteristics of traffic originating from VoIP, Video and WWW applications [9], [13], [14]. The amount of traffic generated in this domain depends on the number of passengers – which is inherent from the assumed airplane type used in the thesis – and their activity – which is by default varied from low activity to peak, and back. ACD, AISD, FR and HM domain traffic was modelled based on the real applications employed in airplanes, approximating the characteristics of traffic originating from the respective devices. The MTC traffic is modelled based on research found in [27], [28], which approximates the data volumes expected from this domain, and the type of information to be transmitted. However, since exact traffic volumes and types are still open research, the model used in this thesis is heavily based on assumptions.
1.5.2 Link Model
10 share of capacity is obtained from it (i.e. while the airplane under consideration is within the cell). The distributions of the numbers of airplanes for each cell size were used to obtain representative numbers of airplanes for each cell size and activity level considered (i.e. inactive, normal, active). The numbers of airplanes per cell are thus assumed to share the total capacity available in the cell. The total capacities for 5G base stations (400Mbit/s), as well as future GEO satellites (500Mbit/s) were taken from [30], [31]. The total capacities for currently available base stations and GEO satellites were assumed to amount to 100Mbit/s, respectively.
1.5.3 Forwarding Algorithm
With the required models in place, a concept for the link allocation/forwarding algorithm was developed. It assumes that incoming traffic will be distinguished by a forwarding scheme, calculated for each flow based on several parameters. Depending on the configuration used, the parameters and respective weights included in the forwarding scheme calculation differ. Different configurations are used to see how the performance of traffic flows changes. Given a configuration then, the algorithm sorts flows based on the forwarding scheme, and allocates them to links such that the ones with a higher forwarding scheme value have less packet loss and delay.
1.5.4 QoS Requirements
The levels of packet loss and delay below which QoS requirements are considered satisfied (henceforth QoS thresholds), were for PODD defined based on parameters found in [14], and adjusted to fit priority assumptions on passenger traffic taken in the thesis. The MTC domain is assumed to have no QoS requirements, since it is assumed that data from this domain can be saved for post-flight processing. Other traffic domains are assumed to have no tolerance for packet loss and delay, since they are considered mission critical. 1.5.5 Network Topology
The models created, and algorithm concept developed were then used to aid a network implementation in Network Simulator 3 (ns-3). The network developed spans up nodes connected to a switch, with each node belonging to one of the communication domains. Depending on the communication domain and type of application assumed, the node generates traffic corresponding to the developed model. The implementation is also generating an environment of changing DA2GC and SA2GC link conditions. Those are represented by the available capacity on each link, which is changing based on a random pattern, as it is assumed that the airplane is traversing base station and satellite cells of different sizes and activity levels, as per the link model. The traffic is intercepted by an SDN controller, and reported to an application which implements the forwarding algorithm described above. The application bases its forwarding decision on the incoming traffic, and the generated link conditions, per rules defined in the algorithm.
1.5.6 Simulations
11 considered to be parameters representative of performance. This information is used to see if QoS thresholds are exceeded – and consequently if a web cache is required. If so, the amount of traffic generating nodes is decreased (i.e. PODD domain, Video and WWW nodes) – implying that those traffic flows do not have to be sent/fetched from ground due to cached content. The extent of the decrease depends on the assumed cache hit rate, which is varied from 0% to 100% (by 10%), until the performance parameters remain below the QoS thresholds. To get more insight into the results, passenger activity is varied in another set of simulations – also from 0% to 100% (by 10%), to see at which activity level QoS thresholds are exceeded. The measurements are done for all forwarding scheme calculations, to see how the performance parameters are changing.
1.5.7 Monte Carlo Simulations
12
2 Conception
To form a foundation for implementing the network environment expected with IFBC, and generating output for analysis, all theoretical concepts under consideration had to be worked on and defined. This chapter hence gives an in-depth review of how each of these definitions was carried out, and which assumptions have been taken, respectively.
2.1 Traffic Model
As a crucial input of the link allocation decision, traffic originating from the airplane network had to be modelled to gain insight into the amounts and types of traffic that are to be generated. This modelling started out by considering the communication domains from which traffic is expected. The characteristics of traffic originating from domains which are already present in today’s airplane networks are available in [32]. Those comprise ACD, AISD, HM and FR. The shape and type of airplane MTC traffic are still an open research question. Overall however, these communication domains are assumed to be represented by one device respectively, which is generating the expected traffic volumes. The respective device, application running on it
and the communication domain name the device is from, may for these domains for brevity be used as synonyms from here on.
For the PODD domain, it is not obvious which types of traffic can be expected, and at which volumes they will arrive. This depends on the applications used by passengers, the percentage of passengers using an application, and the total number of active passengers (i.e. actively using an application; henceforth user activity). These dependencies are assumed to be similar to today’s LTE network, given that it is the latest widely deployed mobile network. In [26], the following list of applications for LTE, and respective percentages of users using them (henceforth usage ratio) is given:
Table 1: LTE traffic mix, with the usage ratio per application [26] Application Usage ratio
VoIP 30%
Video 20%
WWW 20%
Gaming 20%
FTP 10%
13 assumptions with other research. The list of applications from the passenger domain, and usage ratios are summarized in Table 2.
Table 2: IFBC PODD traffic mix, with the usage ratio per application Application Usage ratio
VoIP 20%
Video 60%
WWW 20%
For the simulations done in this thesis, it is further assumed that user activity increments over flight time from low at the beginning of the flight to peak at mid-flight (i.e. where all users are active; 100% user activity), and decrements back to low towards the end of flight. The value for low activity is approximately 20%, which is noted as the expected activity level in [1]. The variation is done to test the developed algorithm against the worst-case user activity scenario. However, as will be explained later in this document, the implementation offers a possibility to set a custom user activity level which will remain constant during a simulation.
The number of passengers is inherent from the airplane type – i.e. from how many passengers can be seated. The airplane assumed in this thesis is the Airbus A318, which has a typical seating capacity for 107 passengers. This airplane was chosen due to the low number of passengers, which decreases the computational overhead for the conducted simulations. All seats are assumed to be occupied by passengers using one of the applications from Table 2. Each passenger is hence represented by a single device.
Since the affiliation of seats to a travel class is dependent on the airline, the number of seats per class was chosen intuitively. It is also assumed that there are three travel classes in the airplane to show how this impacts the traffic originating from them – although this does not have to be the case for this airplane type. Travel classes are considered because it is assumed that passengers who pay a higher price for a ticket are expecting better service – in terms of e.g. flight comfort and internet connectivity. A travel class may from
here on for brevity also be called a communication domain – it is however part of PODD.
Table 3: IFBC traffic generating devices
Communication domain Number of devices
14 The total number of traffic generating devices is summarized in Table 3. To get the numbers of devices per application from the PODD domain, the numbers from first, business and economy class need to be multiplied with the usage ratios of applications from Table 2. The number of VoIP devices in economy class would for example be calculated as follows:
# 𝑉𝑜𝐼𝑃 𝑑𝑒𝑣𝑖𝑐𝑒𝑠 𝑖𝑛 𝐸𝑐𝑜𝑛𝑜𝑚𝑦 = 𝑇𝑜𝑡𝑎𝑙 # 𝑑𝑒𝑣𝑖𝑐𝑒𝑠 𝑖𝑛 𝐸𝑐𝑜𝑛𝑜𝑚𝑦 ∗ 𝑉𝑜𝐼𝑃 𝑢𝑠𝑎𝑔𝑒 𝑟𝑎𝑡𝑖𝑜 = 95 ∗ 20%
= 19
Decimal results are truncated to the closest integral value.
Table 4: Number of traffic generating devices per application and class
Class VoIP Video WWW
First 1 3 1
Business 1 3 1
Economy 19 57 19
Total 21 63 21
Truncation can cause the total number of devices to be less than the passenger count per travel class, as seen in Table 4. This effect however has no considerable impact on the results.
2.1.1 Priorities and Delay Requirements
The generated traffic is assumed to be differentiated based on its priority and delay requirements. A scale was hence defined for each parameter. Priority was defined to scale from one to five (lowest to highest), and delay requirement from one to three (lowest to highest).
Priorities were assigned to each communication domain. Delay requirements were assigned on a per application basis.
Table 5: Communication domains with the respective priority and delay requirement
Communication domain
Application Priority Delay
15 Economy class 2 1 - 3 VoIP 2 3 Video 2 2 WWW 2 1 MTC 1 1
As summarized in Table 5, the highest priority was assigned to communication domains considered to be mission critical – those generating traffic which is concerned with the flight, airplane parameters and health. The next priority levels range from first to economy class – due to higher assumed expectations of passengers paying a correspondingly high price. MTC is assigned the lowest priority, due to the assumption that data from this domain can be saved and analyzed post-flight. The same assumptions were taken while assigning delay requirement values to applications. The delay requirements of applications used by passengers were inspired by [14]. There the pattern of assignment is the same, with VoIP having the highest delay requirement, followed by Video and WWW. Depending on which configuration is used for the simulation, these parameters may have a direct effect on the performance of the respective flow.
2.1.2 Data Rates and Traffic Characteristics
Each of the generated traffic flows has a “behaviour” and associated data rate. The behaviour is characterized by the pattern of traffic generation. As found in [9], VoIP flows follow an ON/OFF traffic generation pattern, with exponentially distributed ON and OFF phases. The traffic generated in the ON phases has a constant bit rate (CBR). The same applies for WWW flows. Video flows on the other hand are shown to have a continuous traffic generation, with a varying bit rate depending on the content represented in each video frame [34]. The rest of the traffic flows (ACD, AISD, HM, FR, MTC) is assumed to have a continuous traffic generation with a constant bit rate. The references found for each traffic type thus served to construct an overall picture of the traffic generation and data rate for each traffic flow. This information is summarized in Table 6.
Table 6: Traffic flow behaviour and data rate for each application Application Traffic generation pattern Mean duration and distribution of ON phase Mean duration and distribution of OFF phase Data rate and type
VoIP ON/OFF 3sec,
exponential
3sec,
exponential
15kbit/s, CBR
Video Continuous - - 4Mbit/s,
varying
WWW ON/OFF 5sec,
exponential 30sec, exponential 3Mbit/s, CBR
16 , CBR
AISD Continuous - - 100kbit/s,
CBR HM Continuous - - 0.6kbit/s, CBR FR Continuous - - 136kbit/s, CBR MTC Continuous - - 3Mbit/s, CBR
Data rates taken for VoIP, WWW and Video are based on values given in [13], [14] and [35]. Given that MTC is still under research, there were no resources to be found on its traffic shape and data rate. However, Inmarsat states that 500GB data volume per flight could be produced by MTC [28], which on an average long haul flight of about 10 hours amounts to approximately 111Mbit/s. It also states that in the future around 8000GB could be expected, which would amount to approx. 1,78Gbit/s. Since it is hard to imagine that any of the two data rates could be supported, an assumed reduced data volume (i.e. filtered, fused and compressed sensor information, as in [27]) of 3Mbit/s is taken. Since it is still not clear how this data reduction and transmission will be done, the traffic characteristics (i.e. frequency of transmission, type of transmission, protocol…) are not known – hence constant bit rate traffic is assumed. Data rates for the other traffic (ACD, AISD, HM, FR) correspond to those found on the respective devices in airplanes today.
2.2 Link Model
The other part of the input required for the forwarding algorithm are the network/link conditions to be expected with IFBC. These were modelled based on up to date research and, where applicable, assumptions.
17 Figure 4: Airplane traversing cells with different activity levels
The following shall outline all the parameters and values considered for the ground and satellite network. It shall also explain the total capacities assumed for the two links, and the ways these are shared with other airplanes.
2.2.1 Capacity Scenarios
The total capacity of a base station and GEO satellite was assumed to correspond to research from [30], [31], and assumptions taken in this thesis.
The total capacity is assumed to be equally shared by airplanes within range of a base station, or within a satellite cell.
The values taken for the capacities in parts of the simulations are different in two scenarios considered.
• Scenario 1: the projected capacity of a 5G base station is around 400Mbit/s, while a GEO satellite should provide a capacity of 500Mbit/s. These capacities may be available in the future.
• Scenario 2: capacities of 100Mbit/s respectively are assumed. This is for another set of simulations where it is aimed to have more overload situations. These capacities are available today.
The two scenarios should enable a comparison of results in terms of packet loss and delay – where scenario 2 is expected to generate higher values for these parameters. It should further enable a more extensive comparison of the three different forwarding scheme calculations, as well as the proposed cache hit rates.
2.2.2 Air Traffic Analysis
18 were obtained from [29], and the scripts parsing them were written in MATLAB.
To parse the traces, information about base station and satellite cell size had to be found. As stated in [36], the deployed LTE base station cells for EAN have a radius of 80 to 150km – these were assumed for the network under consideration too. The satellite cells vary greatly due to the geographic position as seen in [37], so a default radius of 1000km was assumed. With this information, the map of Europe was sectored into spots of 80 to 150km (by 5km), and 1000km radius. Europe was chosen because it has very dense air traffic in general, but also areas where little to no air traffic activity is occurring. This aids the desired effect of changing network conditions – places where enough capacity is available, and those where little to no capacity is available. For the trace analysis, the spots are rectangular, so that within a rectangle’s area a circle of the respective cell radius can be inscribed. Rectangular spots approximate a scenario where circular spots would be used, since those would have to overlap to ensure no places without connectivity.
Spot size will henceforth for brevity refer to the radius of the cell inscribed into the rectangle.
Figure 5 shows how the map was sectored into spots of size 80km. The spots are shown in red, and all the airplanes from the capture are shown in yellow. The lengths of the sides of the rectangles are based on degrees of longitude and latitude in the position the rectangle is placed on the map. Due to this, rectangles in the bottom part of the image appear to be smaller than the ones on top. They are however all the same size. The same consideration was taken for the total number of rectangles placed horizontally and vertically. The aim was to place as many full rectangles in each row and column as possible. The remaining space was split evenly on both sides horizontally and vertically.
19 The same approach was taken for each spot size considered – that is repeating all the calculations done, for sectored maps with rectangles of size 85km, 90km, 95km … up to 150km.
For each sectored map, the 7 day trace was analyzed to see how many airplanes were in each of the spots at the times samples were taken. The numbers of airplanes in each sample were saved for each spot. Rerunning the calculation for each spot size yields distributions of the numbers seen in Table 7. It shows that for different spot sizes there is no significant change in values in the dataset (between minimum and maximum values). This is likely to be due to a high number of samples with no airplanes traversing the spots (especially after midnight) which are pulling the percentile values down. Nevertheless, an increase in the number of airplanes with increasing spot size is observed. From Table 7, this is best noticed in the outlier values, attributed to areas with very dense air traffic (e.g. big cities, airports…), and when comparing the smallest and biggest ground network spot size. Since the spot size for the ground network almost doubles, the numbers of airplanes approximately double.
Table 7: Distribution of the numbers of airplanes occurring for each spot size
Spot size Minimum Median Maximum Maximum
outlier 80 0 2 17 93 85 0 3 17 98 90 0 3 20 98 95 0 3 18 96 100 0 3 18 104 105 0 3 21 119 110 0 4 21 132 115 0 4 23 128 120 0 4 23 136 125 0 4 23 132 130 0 4 23 142 135 0 4 23 152 140 0 4 26 166 145 0 4 26 156 150 0 5 26 180 1000 0 8 48 85
The distribution of the numbers of (coming/leaving) airplanes for the satellite spots are much higher, due to the coverage of the spot. Since sharing the available satellite capacity with a high number of airplanes would give a very small share of the capacity, it is assumed that not all airplanes in the satellite spot belong to the same satellite operator. The obtained numbers of airplanes with which capacity needs to be shared were thus divided with 10, with the assumption that this will be the number of satellite operators in 2020+.
20 numbers within the dataset range from -4 to 4. Hence, a negligible difference between data sets of the respective spot sizes is seen, for the same assumed reasons as above. However, there are outliers which have much higher values. The numbers of airplanes coming/leaving while the airplane is within a cell are thus for every cell size assumed to be up to 4. This is because the number of leaving airplanes could, due to the outlier values, be much higher than the number of airplanes present in a cell – for example there are 10 airplanes, and then there is the possibility that 45 leave.
To abstract the obtained results with the 7 day trace, it is assumed that there are three different activity levels of spots – inactive, normal and active. For each spot size then, a representative number of airplanes for each activity level is calculated.
The calculation is based on the following assumptions:
• Inactive spot – number of airplanes lies at the midpoint between dataset minimum and median
• Normal spot – number of airplanes lies at the midpoint between dataset median and maximum
• Active spot – number of airplanes lies at the midpoint between dataset maximum and outlier maximum
Table 8: Numbers of airplanes in inactive, normal and active spots – for each spot size
Spot size Inactive Normal Active
80 1 10 55 85 2 10 58 90 2 12 59 95 2 11 57 100 2 11 61 105 2 12 70 110 2 13 77 115 2 14 76 120 2 14 80 125 2 14 55 130 2 14 55 135 2 14 88 140 2 15 96 145 2 15 91 150 3 16 103 1000 4 28 67
21 The cell sizes and activity levels traversed would in a real-life scenario depend on the airplane route. Since the base station and satellite cells under consideration are however not in place yet, it is assumed that a random set of cells is traversed (with a correspondingly random set of cell sizes and activity levels observed). The time spent in each cell is determined by its size and the airplane speed – which is assumed to be an average of 0.25km/s, as noted in [38]. To get the time over a cell, the distance covered over a cell (assumed to be double the spot size; e.g. 160km for a cell radius of 80km) is divided by the airplane speed. This calculation is done in the implementation for each cell entered, so to know when to make the next corresponding link condition change. The generated link conditions will for a given route follow a pattern as in Figure 6.
Figure 6: Example of varying link conditions (scenario 1)
As seen there, there are periods where there is enough capacity available on both links, and those when there is not. Overall, the link conditions will change based on the capacity share that is obtained from a given link.
2.3 QoS Requirements
To measure the performance of traffic flows, it was at task to define their QoS requirements (thresholds) which were not to be exceeded by parameters measured in the implementation. Those are, as in [14], described by packet loss and delay a flow endures. Initial values which are to be respected for a flow of a certain type are already available, but those had to be adjusted so to conform with other traffic flow priority requirements assumed in this thesis. The below shall outline how these adjustments were done.
2.3.1 Packet Loss
22 network device forwarding them to the output links, a number of them will be dropped if the capacity on the output links is not sufficient to support all incoming flows. The decision on which flow to drop is defined in the forwarding algorithm. The amount of dropped traffic is for each flow measured in terms of packet loss.
Each application considered has associated packet loss values which shall not be exceeded (henceforth referred to as packet loss QoS threshold). The mission critical domains are assumed to have no tolerance for packet loss. MTC is, as for the reasons outlined before, considered to have tolerance for packet loss. The applications from the PODD domain however each have a different tolerance, as defined in [14] for VoIP and Video traffic. There a 1% tolerance for VoIP, and 2% tolerance for Video is given. An assumed 10% tolerance level is taken for WWW traffic.
To take the priority of PODD subdomains (i.e. first, business and economy class) into consideration, the way packet loss is measured is different respectively. Therefore, the overall packet loss per subdomain and application is summarized in percentiles, as seen in Table 9. The percentile of packet loss from traffic flows of a certain application type taken, shall per travel class correspond to its priority – for example, the 99th percentile is taken over
packet loss of all the traffic flows from first class per application type, implying that almost all the flows from this class should have their packet loss QoS requirement satisfied. For business and economy, the percentile taken is lower, with 95th and 75th percentile respectively. This implies that a greater
number of flows whose packet loss QoS thresholds are exceeded is tolerated for these classes.
Table 9: Packet loss QoS threshold per application and travel class Application First class
packet loss (99th percentile) Business class packet loss (95th percentile) Economy class packet loss (75th percentile) VoIP 1% 1% 1% Video 2% 2% 2% WWW 10% 10% 10%
From the measured packet loss values of all flows per application type, the corresponding percentile taken per traffic class should be below the application packet loss QoS threshold.
2.3.2 Delay
23 and speed - only certain flows can be transmitted over it without a drop in QoS. This depends on the QoS requirements a flow has in terms of delay (henceforth referred to as delay QoS threshold).
Mission critical flows are again assumed to have no tolerance for delay, i.e. only tolerating the minimum delay possible – which is in this case only when transmitted over DA2GC. MTC is assumed to tolerate delay, as for the reasons explained before. The only application from the PODD domain which does not tolerate the delay levels experienced over SA2GC, is as defined in [14], VoIP. To be able to quantize the delay QoS threshold then, it is assumed that the amount of time VoIP flows spend on SA2GC shall not exceed some predefined values. These were chosen intuitively, since no comparable research on these parameters was found. The assumed values are summarized in Table 10. Table 10: Delay QoS threshold for VoIP per travel class
Application First class amount of time forwarded over SA2GC (99th percentile) Business class amount of time forwarded over SA2GC (95th percentile) Economy class amount of time forwarded over SA2GC (75th percentile) VoIP 1% 1% 1%
To be able to account for the priority levels of the different travel classes, the same percentiles per travel class as those taken for packet loss are assumed here too. Those are hence taken over the times VoIP flows have been forwarded over SA2GC for each traffic class, and should not exceed 1% respectively.
2.4 Forwarding Algorithm
With the generated input, as described in the traffic and link models, it is at task to satisfy the outlined QoS requirements of the flows, such that flows which are considered more relevant get more forwarding time over DA2GC, and in general get dropped less. This is conditioned by a flow’s forwarding scheme value, which is calculated based on a set of parameters. Depending on which type of calculation is assumed, a different overall configuration of the forwarding algorithm is achieved. The flows are sorted based on the forwarding scheme value, and depending on its value allocated to one of the links or dropped.
2.4.1 Forwarding Schemes
24 • Forwarding scheme 1: 100% priority
• Forwarding scheme 2: 50% priority + 50% delay requirement
• Forwarding scheme 3: 50% priority + 25% delay requirement + 25% number of times the flow was dropped
All parameters are first normalized to range from zero to one. The weights assigned to the parameters are chosen so to show how a change in the considered weight, or consideration of another parameter affects the performance of the flows. With forwarding scheme 1, only the priority of the flows is considered, such that the flows with a higher priority get the advantage of being forwarded more over DA2GC, and getting dropped less in low capacity situations. This implies e.g. that flows from the economy class may have a correspondingly lower performance than those from business class. The same may propagate up the communication domain chain as per the respective priority. Forwarding scheme 2 on the other hand considers an equal weight on priority and delay requirement. The pattern of better performance for flows from a communication domain with higher priority can be expected here too. However, considering the delay requirement of the flow can improve the performance of flows with high delay requirement values assigned even in lower priority communication domains. Forwarding scheme 3 is assumed to split the weight on delay requirement from forwarding scheme 2 amongst delay requirement and the number of times a flow was dropped. This is assumed to improve the performance of flows which are dropped frequently – e.g. those with low delay requirements, or a low priority. Overall, it is expected that the forwarding scheme 3 configuration considers the characteristics and state of traffic flows in the best way amongst the chosen configurations.
Although the configurations do capture some characteristics and state information of the flows, another set of parameters could be considered, and the weights assigned to them could be optimized. Finding the “optimal” forwarding scheme is however out of the scope of this thesis, and will be suggested for future work.
2.4.2 Forwarding Algorithm Description
With all the relevant input at hand, it was at task to define the events the forwarding algorithm will react to. Those shall be defined so that the available link capacity is utilized efficiently, and that the incoming traffic characteristics and amounts are considered. The following list of randomly occurring events has thus been chosen:
• Incoming traffic flow • Change in DA2GC capacity • Change in SA2GC capacity • Change in traffic flow data rate
It is further assumed that the algorithm can take the following actions: • Forward a traffic flow over DA2GC
25 • Offload a traffic flow from DA2GC to SA2GC (and vice versa)
• Drop a traffic flow
Based on the traffic model, traffic flows from the PODD domain arrive in parallel, with the number of incoming flows increasing to flight (i.e. mid-simulation), and then decreasing towards the end as flows depart. Traffic flows from the other domains arrive in parallel once the simulation starts, and remain to the end.
The traffic flows are sorted based on their forwarding scheme value in ascending order. The incoming traffic flow is first attempted to be forwarded over DA2GC if there is remaining capacity. If not, its forwarding scheme value is compared to the ones of flows which are already being forwarded over that link. If a flow with a lower forwarding scheme value than the incoming flow is found, it is offloaded to SA2GC and the new flow is placed on the link. Otherwise, the incoming flow is attempted to be forwarded over SA2GC. The offloading/attempted forwarding over SA2GC also happens based on available capacity and the forwarding scheme value of flows forwarded over it. If there is no available capacity to accommodate the offloaded/incoming flow, again a flow with a lower capacity is sought for. If it is found, it is dropped. If there is still not enough available capacity, the search for flows with a lower forwarding scheme value goes on. Eventually, the offloaded/incoming flow will be forwarded over SA2GC if there is enough capacity freed to accommodate it, or it will get dropped if not. This is summarized in Figure 7.
Forwarding scheme value -> FSV
// loop waiting for events
// each event is handled by respective methods and submethods
while(true) {
if(incoming traffic flow) {
forward over DA2GC(incoming flow F) } else if(change in DA2GC capacity) {
change in capacity over DA2GC(new capacity) } else if(change in SA2GC capacity) {
change in capacity over SA2GC(new capacity) } else if(change in traffic flow data rate) { if(flow is forwarded over DA2GC) {
change in capacity over DA2GC(new capacity) } else {
change in capacity over SA2GC(new capacity) }
} }
forward over DA2GC(incoming flow F) {
if(data rate of F <= available capacity over DA2GC) { forward F over DA2GC
} else {
while(there is a lower FSV flow on the DA2GC link) { offload to SA2GC(lower FSV flow)
if(data rate of F <= available capacity over DA2GC) { forward F over DA2GC
forward = successful break
} }
26
offload to SA2GC(incoming flow F) }
} }
offload to SA2GC(lower FSV/incoming flow F) {
if(data rate of F <= available capacity over SA2GC) { forward F over SA2GC
} else {
while(there is a lower FSV flow on the SA2GC link) { drop(lower FSV flow)
if(data rate of F <= available capacity over SA2GC) { forward F over SA2GC
forward = successful break
} }
if(forward != successful) {
drop(lower FSV/incoming flow F) }
} }
drop(lower FSV/incoming flow F) { if(F is forwarded over DA2GC) { drop F from the DA2GC link
} else if(F is forwarded over SA2GC) { drop F from the SA2GC link
} else { drop F }
}
change in capacity over DA2GC(new capacity) { if(new capacity > old capacity) {
while(data rate of highest FSV flow on SA2GC <= remaining capacity over DA2GC) {
forward highest FSV flow from SA2GC over DA2GC }
} else if(new capacity < old capacity) {
while(remaining capacity over DA2GC !>= 0) { while(remaining capacity over SA2GC !>= data rate of lowest FSV flow on DA2GC) { drop lowest FSV flow from SA2GC }
forward lowest FSV flow from DA2GC over SA2GC }
} }
change in capacity over SA2GC(new capacity) { if(new capacity > old capacity) {
while(data rate of highest FSV dropped flow <= remaining capacity over SA2GC) {
forward highest FSV dropped flow over SA2GC }
} else if(new capacity < old capacity) {
while(remaining capacity over SA2GC !>= 0) { drop lowest FSV flow from SA2GC
} } }
27 Further summarized there is, that if a change in capacity on one of the links occurs, the flows must, based on their forwarding scheme value, get reallocated on the links. The reallocation depends on whether there is an increase or decrease in capacity. If for example the capacity on the DA2GC link increases, it may be possible to accommodate flows from the SA2GC link on it too. So based on the forwarding scheme value, the flows with the highest value from the SA2GC link get loaded to the DA2GC link until there is no more remaining capacity on it. If there is a decrease in capacity on the DA2GC link however, flows from it get offloaded to the SA2GC link. If there is no more remaining capacity on SA2GC though, flows with a lower forwarding scheme value than the next lowest forwarding scheme value flow from the DA2GC link need to be found, and dropped until there is enough capacity to accommodate the offloaded flow. This is done until the remaining capacity on DA2GC reaches a value of zero or more.
On the other hand, an increase in capacity on the SA2GC link will enable dropped flows to be placed on it again. For this the next highest forwarding scheme value flow from the drop set is taken, until the remaining capacity on the SA2GC link reaches zero. If a decrease in capacity on this link occurs, flows with the next lowest forwarding scheme value get dropped until the remaining capacity reaches zero.
The change in capacity on either link could originate from a change in the link conditions or an increase/decrease in data rate of one or more flows being forwarded over the respective links. In any case, flows are reallocated to the sets/links based on their forwarding scheme value.
2.4.2.1 Limitations
With this approach of flow reallocation, it could happen that flows with a high data rate (i.e. one exceeding available capacity) and forwarding scheme value could block flows with a lower data rate and forwarding scheme value from e.g. being loaded from the drop set to the SA2GC link (or from the SA2GC link to DA2GC) – given that only the next highest forwarding scheme value flow is considered for being loaded onto one of the links when more capacity is available – although the available capacity on a link could be sufficient to accommodate some lower forwarding scheme value and lower data rate flows. The same limitation could occur in the attempt of forwarding a high data rate, and high forwarding scheme value flow over one of the links, if the flows which are already being forwarded over the link have a lower forwarding scheme value. The high forwarding scheme value of the flow could cause multiple, or theoretically all flows to be removed from the link, yet with no guarantee that even then the available capacity over the link will be sufficient to accommodate the data rate generated by the incoming flow. This would hence unnecessarily degrade the performance of the lower forwarding scheme value flows.
28 which set. This can lead to performance differences between flows with the same forwarding scheme value, which deviate from what would be observed with real switch queues.
However, the scope of this thesis did not include an optimization of the offloading/on-loading and queuing technique – which leaves potential for future improvements in this sense.
2.5 Web Cache
29
3 Implementation
Having covered the theoretical basis for the thesis at hand, the next step was to implement the models and forwarding algorithm in software, to be able to simulate the whole network environment, and answer the questions set out on the beginning of the thesis. This implementation, amounting to about 2500 lines of code, turned out to include a steep learning curve, and to be the most work intensive part of the thesis. It was done on an Ubuntu 16.04.4 64-bit virtual machine.
Given the relatively young stage of research behind SDN networks, the resources with which the implementation were to be done were limited. Most considered frameworks and programming stacks did not have the possibility to set up a network topology with an SDN switch. Those which did however were Mininet and ns-3. The limitation behind using Mininet for this simulation is that the network traffic cannot be simulated, but generated – so no precise correspondence to the traffic model assumed in this thesis could be achieved. Hence, ns-3 (version 3.28) was the library of choice for the network simulation.
3.1 Simulation Environment
ns-3 is a discrete event network simulator, which offers a wide range of network elements that can be coupled into complex topologies, as per the requirements of a project. The network elements can be traffic generating nodes, or devices connecting multiple nodes into a topology. Each node and networking device can have preset characteristics which concern the networking stack installed on them [35]. The nodes, devices and stacks installed in the network for this thesis, and the topology created are further outlined below.
3.1.1 Network Topology with ns-3
Since ns-3 offers libraries for creating network nodes, and setting the characteristics of traffic to be generated by them, which are per default not automated for creating multiple nodes at once, appropriate code for doing this was written in C++, which does the following:
• Creates the nodes, and sets the traffic characteristics for each node as per the traffic model.
The number of nodes does not map to the one from the traffic model if a cache is considered for the simulation or a custom user activity level is set (as further outlined below).
The traffic generation pattern, data rates and other associated parameters from the traffic are passed to the constructors of nodes created in the network.
• Gives each node an IP and MAC address, and specifies that the transport protocol to be used for the traffic should be UDP for each node.
