Since multiple GA server instances are required – one per player, a centralized log server is required to collect delay data in real-time from each GA server, perform QoE analysis, and then transmit required up and downlink lag compensation delays back to each corresponding GA server. The data sent from each server to the centralized log server includes synchronization source SSRC, server to client (s2c) delay, client to server (c2s) delay, IP address, and port number. Figure 8 illustrates the data generated and gathered by each GA server into a char array, and sent to a centralized log server in real-time.

#### Fig. 8. Data structure in GA server

Figure 9 illustrates the centralized log server within the whole architecture. Once it receives data, it will compare s2c delay and c2s delay between different GA servers, and determine what compensating delay to add on upstream (player control actions) and downstream (video/audio) in real-time for each player.

UDP sockets are used instead of TCP sockets to minimize delay and maximize responsiveness of system – it does not need any connection setup such as

Fig. 9. Centralized log server

three-way-handshake, and ignores lost packets which would otherwise incur more delay when sending data. UDP sockets are thus an appealing choice for non-critical delay-sensitive applications.

Since data contains characters and integers, we use an object array to store data together. Figure 10 illustrates the data structure in centralized log server. Once the centralized log server receives data from more than 1 player, it starts to do the analysis and generates the table of data above. Firstly, from incoming data packets the centralized log server determines the player with the largest s2c delay for audio and video respectively. Based on upstream delays for RTCP RR traffic, it calculates an average (of video/audio) c2s delay also. As outlined earlier, the threshold of roundtrip delay for FPS games is 100 ms. For this reason, we implement a threshold such that whenever the round-trip delay is greater than 100 ms, the data for that player is not considered as

Fig. 10. Data structure in centralized log server

it makes no sense to penalise every player with more than 100 ms round-trip time after lag compensation.

As shown in Fig. 11, Client1 and Client2 have 30 ms and 50 ms round-trip time respectively while client3 has 120 ms. Since the threshold is 100 ms, the centralized log server will just do comparison of data for Client 1 and 2.

Fig. 11. Threshold network latency for FPS games

116 Z. Li et al.

Once determined, the centralized log server sends recommended compensation delay data back to each GA server based on IP address. The respective GA servers then introduce these additional delays on upstream control traffic (player actions) and downstream data (audio/video).

Figure 12 shows the full structure of testbed in this experiment and also outlines the data flows as well as role of network emulator and lag compensation.

Fig. 12. Full system architecture and data flows

As shown above, we introduce emulated delays of 20 (10/10) and 40 (20/20) ms to Client1 and Client2 respectively. This results in lag compensation of 10 ms on both up and down link traffic for Client2 – shown in grey above so that c2s and s2c are equal for both clients. Note that the delays shown here are symmetric, which is rarely the case in reality. Further details on setting up the testbed and background work can be found in [22].

## 5 Results

In this section, we outline results that address both research objectives from Sect. 3.1. We firstly present a range of results for the 2-player scenario in order to validate the performance of the lag compensation mechanism. We present baseline delays with no emulated delays to get a sense for delays as measured across the university LAN network and the possible need for lag compensation to cope with inherent delay asymmetries. We then outline a range of tests whereby we introduce both up and downlink delays for different players using the network emulator and see how the lag compensation mechanism performs. Moving to objective 2, we then present results of preliminary subjective tests that exposed players to a range of delays with and without lag compensation and captured the resulting QoE scores. The section concludes with a discussion of ongoing and future work.

## 5.1 Baseline Results

Figure 13 shows the analysed data processed by the log server from the two servers/players deployed across the LAN network environment with no artificial delays added by the network emulator. Player 1 data is shown in the first 2 data rows, Data 1 for video and Data 2 for audio. Player 2 data is shown in the next 2 rows, Data 3 for video and Data 4 for audio. As outlined above, the columns (left to right) show SSRC (v for video and a for audio), s2c delay, delay added to downstream (s2c) traffic, c2s delay, average c2s delay (of video and audio stream), delay added to upstream traffic (c2s), IP address and 2 ports. The average c2s is calculated (from audio and video RTCP traffic) and used to delay the uplink control traffic.

Fig. 13. Analysed data with no emulated delays

The output shows how the lag compensating mechanism is achieving the goal of equalising the delays for both players. For example, Player 1 measured s2c delays are 7/5 ms for v/a respectively whereas Player 2 has 6/1 ms for v/a respectively. Therefore, in order to equalise this, compensating delays for Player 2 s2c of 1/4 ms are added for v/a so that totals for Player 2 are 7 (1 + 6) and 5 (4 +1) i.e. same as Player 1.

Moving to c2s delays, Player 1 has measured c2s delays of 4/4 ms for v/a respectively whereas Player 2 has 6/6 ms for v/a respectively. Therefore, in order to equalise this, Player 1 c2s added delays are 2 for v/a so that total for Player 1 is 6 (4 + 2) i.e. same as Player 2.

#### 5.2 Emulated Delays

In order to fully test the lag compensation mechanism, we then added delays using the NEWT emulator and monitored both how quickly these delays were picked up by the mechanism and then how compensating delays were added to equalise delays for both players. We firstly added 10 ms to both up and downlink delay for Player1/Client1 and 20 ms delay for up and downlink delay for Player2/Client2. As shown in Figs. 14 and 15, we use "ping" to validate performance of network emulator which returned averages of 19 and 39 ms.

Fig. 15. Validating network emulator in client2

Figure 16 shows the analysed data for two players under these emulated network environments. It can be seen that the actual delays as measured by modified RTCP code are not 10/10 and 20/20 as implemented by the emulator. The delays are closer to those seen above under zero emulated delays plus the emulated delays plus additional noise caused by non-determinism in various application software and OS stack etc. This results for example in s2c delays for Player 1 of 15/19 ms v/a, c2s delays of Player 1 15/12 v/a, and for Player 2, s2c v/a delays of 26/30 ms and c2s delays of 24/26 ms v/a.

Fig. 16. Analysed data with different network environments

Based on these results, GA server1 requires:

We then changed network latency to 30 ms (15 ms up/downstream) and 60 ms (30 ms up/down stream) for Player 1 and 2 respectively. The results are shown in Fig. 17.

Fig. 17. Analyzed data after changed network latency

As above, the log server detects the changed network conditions and communicates the appropriate changes to respective streams back to GA servers in order to equalise delays.

Figure 18 shows the full set of emulated delays implemented for 6 different tests and Fig. 19 illustrates the resulting analysed data.

Fig. 18. Emulated delays: Test Index 0–5

Fig. 19. Analysed data for tests (Index 0–5) with different network latency

The data (left to right) has two additional columns outlining total s2c and c2s delays (measured + compensation delays). The columns are:

In each case, the mechanism is seen to work correctly by firstly detecting the impact of the emulated delays (including noise) typically within one second and then implementing lag compensation so that total c2s and s2c delays for player 1 and 2 are equal.

#### 5.3 Preliminary Subjective Testing

Although the initial plan was to setup all GA servers in virtual machines for subjective testing, some technical problems and limitations arose, and thus the tests were carried out using separate servers. Since Assault Cube can supports a maximum of 5 players in a LAN, we thus used 10 computers (5 as GA servers and 5 as GA clients) to run the game. As shown in Fig. 20, a multiplayer game was created in Server1 and others joined the game created by Server1. The GA connection between GA servers and GA clients was then established. NTP was also configured in both GA servers and clients to synchronise system time. Finally, the network emulator was used to introduce artificial delay to implement different network environment.

Fig. 20. Testbed

## Test Scenarios

10 people were divided into two groups (5/5) to perform the test. All of the participants were postgraduate students and were familiar to varying degrees with gaming. As shown in Fig. 21, each group (Player 1 - Player 5) firstly played the game without any emulated network delay, thus providing a baseline for the tests. A series of delay scenarios (10 in total - uplink/downlink in ms) were then introduced for each player both with and without lag compensation with each scenario lasting 3 min. After each scenario, players were given a small amount of time to fill out a questionnaire and report the overall QoE and game fairness on a scale of 1–5. Both groups underwent the same series of scenarios.

Fig. 21. Test scenarios

#### Test Results

The overall QoE in absence of lag equalization reported by participants is shown in Fig. 22. Whilst the sample size is small, the bar chart clearly shows that the overall QoE decreased with increasing delay which is in line with other studies on FPS games. Figure 23 illustrates the perceived game fairness for different emulated delay scenarios with and without lag compensation. Again, whilst preliminary and based on a small sample size, the results clearly show that in absence of lag compensation, higher relative network latency results in lower game fairness. However, the game fairness remains high once lag compensation is introduced. It is very interesting to note that there was no decrease in QoE as emulated delays increased, presumably as all participants were experiencing the same delays and values were less than the 100 ms threshold that is reported as being the threshold for acceptability in FPS games.

Fig. 22. Average overall QoE reported for different test scenarios. Delays portrayed on the x axis indicate RTTs.

Fig. 23. Perceived game fairness

More comprehensive and rigorous tests are planned to fully evaluate the effectiveness of our approach. More detailed results from the above preliminary tests are available in [22].

## 5.4 Next Step – Virtualization

The above tests were carried out using dedicated servers for each player GA instance. In order to scale up the testbed, we plan to run all GA server instances using Virtual Machines (VM). This will also help to eliminate some of the non-determinism seen above in the results. This architecture is shown in Fig. 24, whereby each GA server runs in a dedicated VM and sets up connections with each client.

Fig. 24. Run GA server instances in a VM

## 6 Conclusions

In this chapter, we examine cloud gaming from the delay (lag) perspective, and in particular the impact of lag on QoE of gamers. Cloud gaming is an emerging service, which combines cloud computing and online gaming. It opens a promising direction for the computer games industry but several challenges still remain to provide good QoE for every player. We review the literature and then analyze certain QoS-related key factors and characteristics, which influence the QoE for cloud gaming, especially for so-called FPS games. The conclusion is that for FPS games, network latency presents one of the most important QoE factors. In this context, we propose a lag equalization strategy to level the playing field in the context of QoE and outline two research objectives. The first objective is to examine the feasibility of implementing a real-time lag compensation mechanism for cloud gaming. To meet this objective, we implemented a cloud gaming system with both up and downlink lag compensation based on the Gaming Anywhere platform, an open platform for researchers. The FPS game Assault Cube was used to showcase the implementation. The mechanism uses a modified version of the RTCP protocol along with NTP to ensure adequate time synchronization to yield accurate each way delays. These are communicated to a centralized monitoring service that then determines and communicates back to each server the necessary up and downlink compensation delays. The lag compensation approach was evaluated in an emulated environment whereby a series of tests were carried out with differing uplink and downlink emulated delays to emulate differing network conditions. The results validate the mechanism by successfully implementing real-time delay equalization. To meet objective 2, we then carried out preliminary subjective tests with a small group of participants. Results firstly confirmed the impact of lag on QoE as detailed in the literature review and then validated our lag compensation approach whereby the reported QoE remained high for high delay values once equalization was implemented. Our future research will firstly optimize the experimental cloud gaming environment by introducing virtual machines for scalability. More comprehensive subjective QoE tests using the proposed lag compensation approach will then be undertaken to more rigorously evaluate its effectiveness.

Acknowledgments. This work has been partially supported by the ICT COST Action IC1304 - Autonomous Control for a Reliable Internet of Services (ACROSS), November 14, 2013– November 13, 2017, funded by European Union.

Andrej Zgank's work was partially funded by the Slovenian Research Agency (research core funding No. P2-0069).

We would also like to acknowledge the technical support received by the core GA developer Chun-Ying Huang.

## References

Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

# **The Value of Context-Awareness in Bandwidth-Challenging HTTP Adaptive Streaming Scenarios**

Eirini Liotou1(B) , Tobias Hoßfeld2, Christian Moldovan2, Florian Metzger2, Dimitris Tsolkas1, and Nikos Passas1

1 National and Kapodistrian University of Athens, Athens, Greece<EMAIL_ADDRESS>2 University of Duisburg-Essen, Essen, Germany<EMAIL_ADDRESS>
**Abstract.** Video streaming has become an indispensable technology in people's lives, while its usage keeps constantly increasing. The variability, instability and unpredictability of network conditions pose one of the biggest challenges to video streaming. In this chapter, we analyze HTTP Adaptive Streaming, a technology that relieves these issues by adapting the video reproduction to the current network conditions. Particularly, we study how context awareness can be combined with the adaptive streaming logic to design a proactive client-based video streaming strategy. Our results show that such a context-aware strategy manages to successfully mitigate stallings in light of network connectivity problems, such as an outage. Moreover, we analyze the performance of this strategy by comparing it to the optimal case, as well as by considering situations where the awareness of the context lacks reliability.

**Keywords:** HTTP Adaptive Streaming · Video streaming Context awareness · Quality of Experience · Stalling probability

## **1 Introduction**

## **1.1 Motivation**

The rising number of smart phone subscriptions, which are expected to reach 9.2 billion by 2020, combined with the explosive demand for mobile video, which is expected to grow around 13 times by 2019, accounting for 50% of all global mobile data traffic, will result in a ten-fold increase of mobile data traffic by 2020 [1]. This explosive demand for mobile video is fueled by the ever-increasing number of video-capable devices and the integration of multimedia content in popular mobile applications, e.g. Facebook and Instagram. Furthermore, the use of video-capable devices, which range from devices with high resolution screens to interactive head mounted displays, requires a further increase of the bandwidth, so that on-demand video playback can be supported and differentiated expectations raised by the end video consumers can be satisfied.

Following this trend for video streaming, mobile network operators, and service providers focus on the Quality of Experience (QoE) of their customers, controlling network or application-level parameters, respectively. In parallel, from the user's side, a better QoE enhancement can be achieved if both networkand application-level information are utilized (cross-layer approaches). On top of that, greatest gains can be possible if also "context information" is used by any of these parties, complementary to the usually available Key Performance and Key Quality Indicators (KPIs and KQIs), to which the service/network providers already have access. As a general conclusion, (ideally) cross-party, cross-layer, and multi-context information is required towards devising mechanisms that will have the greatest impact on the overall user QoE.

In parallel, since most of the consumed video of a mobile data network is delivered through server-controlled traditional HTTP video streaming, the ability of such monolithic HTTP video streaming to support a fully personalized video playback experience at the end-user is questioned. To this end, this traditional technique is gradually being replaced by client-controlled video streaming exploiting HTTP Adaptive Streaming (HAS). HAS can split a video file into short segments of a few seconds each, with different quality levels and multiple encoding rates, allowing a better handling of the video streaming process, e.g. by adapting the quality level of future video segments. HAS is a key enabler towards a fully personalized video playback experience to the user, as it enables the terminal to adapt the video quality based on the end device capabilities, the expected video quality level, the current network status, the content server load, and the device remaining battery, among others.

In this chapter, our objective is to investigate how context awareness in mobile networks can help not only understand but also enhance the user experienced quality during HAS sessions. We study a scenario where users travelling with a vehicle experience bad or no service at all (i.e. a service outage). In this or similar type of scenarios, the opportunity emerges to propose novel, preemptive strategies to overcome such imminent problems, for instance by proposing proactive adaptive streaming or buffering techniques for video streaming services. This scenario has been modelled, optimized and investigated by means of simulation. Before presenting the problem under study, we first identify the need and the changes needed to move from a QoE-oriented to a context-aware network/application management.

#### **1.2 From QoE-Awareness to Context-Awareness**

QoE is defined as "*the degree of delight or annoyance of the user of an application or service*" [2], and as such, it is an inherently subjective indication of quality. Consequently, a significant amount of research efforts has been devoted to the measurement of this subjective QoE. The goal of these efforts is to find objective models that can reliably estimate the quality perceived/experienced by the end-user. To this end, subjective experiments that involve human assessors are carefully designed, with the purpose of mapping the various quality influence factors to QoE values. In [2], these influence factors are defined as "*any characteristic of a user, system, service, application, or context whose actual state or setting may have influence on the Quality of Experience for the user*", and they are basically classified into three distinct groups, namely, *Human*, *System*, and *Context* factors. Human influence factors include any psychophysical, cognitive, psychological or demographic factors of the person receiving a service, while system influence factors concern technical parameters related to the network, application and device characteristics and parameters. Finally, context relates to any spatio-temporal, social, economic and task-related factors.

The awareness of QoE in a network is a valuable knowledge not only per se (namely for network monitoring and benchmarking purposes) but also as a useful input for managing a network in an effective and efficient way. The "QoEcentric management" of a network can be performed as a closed loop procedure, which consists of three distinguishable steps:

*QoE Modelling:* For the purposes of QoE modelling, key influence factors that have an impact on the network's quality need to be mapped to QoE values. To this direction, QoE models have to be used that try to accurately reflect/predict a subjective QoE estimation.

*QoE Monitoring:* This step provides answers on how, where and when QoErelated input can be collected. It includes the description of realistic architectures in terms of building blocks, mechanisms, protocols and end-to-end signalling in the network. Also, this procedure relates to the way in which feedback concerning QoE measurements can be provided from end-user devices and any network nodes to the responsible QoE-decision making entities in the network.

*QoE Management and Control:* This step includes all the possible QoEdriven mechanisms that can help the network operate in a more efficient and qualitative way. These mechanisms may include for instance power control, mobility management, resource management and scheduling, routing, network configuration, etc. All these procedures can be managed based on QoE instead of traditional Quality of Service (QoS) criteria and their impact can be assessed based on the QoE they achieve. Multiple variants of the three previous steps or building blocks can be found in the literature, such as [3,4].

"Context" may refer to "*any information that can be used to characterize the situation of an entity*" [5]. In this way, context awareness can facilitate a transition from packet-level decisions to "scenario-level" decisions: Indeed, deciding on a per-scenario rather than on a per-packet level may ensure not only a higher user QoE but also the avoidance of over-provisioning in the network. This huge potential has been recently identified in academia and as a result, research works on context awareness and context-aware network control mechanisms are constantly emerging in the literature. In [6], a context aware handover management scheme for proper load distribution in an IEEE 802.11 network is proposed. In [7], the impact of social context on compressed video QoE is investigated, while in [8] a novel decision-theoretic approach for QoE modelling, measurement, and prediction is presented, to name a few characteristic examples.

If we now revisit the three-step QoE control loop described earlier by also considering context awareness, then this is enriched as follows:

*Context Modelling:* Based on the earlier discussion about the QoE modelling procedure, we may observe that the *System* as well as the *Human* influence factors are directly or indirectly taken into account in the subjective experiments' methodologies, e.g. [9]. Consequently, the impact of technical- and human-level characteristics is tightly integrated into the derived QoE models. Nevertheless, the *Context* influence factors are mostly missing in these methodologies, or are not clearly captured. This happens due to the fact that the QoE evaluations are usually performed in controlled environments, not allowing for diversity in the context of use. Besides, context factors are challenging to control, especially in a lab setting, and new subjective experiment types would have to be designed. As a consequence, the mapping of context influence factors to QoE is absent from most QoE models that appear both in the literature and in standardization bodies. Therefore, novel context-aware QoE models need to be devised that are able to accurately measure and predict QoE under a specific context of use, as these context factors are (often) neglected. These context factors could either be integrated inside a QoE model directly, or, be used as a tuning factor of an otherwise stand-alone QoE model.

*Context Monitoring:* On top of QoE monitoring, context monitoring procedures could (and should) be implemented in the network. These procedures will require different input information from the ones used by traditional QoS/QoE monitoring techniques. The acquired context information may be used for enhancing the QoE of the users or for the prediction of imminent problems, such as bottlenecks, and may range from spatio-temporal to social, economic and task-related factors. Some of the possible context information that may be monitored in a network is the following (to give a few examples): the current infrastructure, which is more or less static (access points, base stations, neighbouring cells, etc.), the specific user's surrounding environment (location awareness, outdoors/indoors environment, terrain characteristics, presence of blind spots such as areas of low coverage or limited capacity, proximity to other devices, etc.), the time of day, the current and predicted/expected future network load, the current mobility level or even the predicted mobility pattern of users in a cell (e.g. a repeated pattern), the device capabilities or state (e.g. processing power, battery level, storage level, etc.), the user task (e.g. urgent or leisure activity), as well as application awareness (e.g. foreground or background processes), and social awareness of the end-users, among others. Moreover, charging and pricing can also be included in the general context profile of a communication scenario. It needs to be noted here that context awareness does not necessarily rely on predicting the future (e.g. future traffic demand) but also on solid knowledge that is or can be available (e.g. time of day, outage location, etc.).

*Context-Aware Management and Control:* Three possibilities emerge in a context-aware network. First, the network can take more sophisticated control decisions that are also influenced by context-awareness, such as for instance, a decision to relax the handover requirements for a user in a fast-moving vehicle or a decision to connect a device with low battery to a WiFi access point. Second, the network can actualize control decisions exploiting the current context. For instance, it can exploit information about flash crowd formation to drive an effective Content Distribution Network (CDN) load balancing strategy [10] or, more generally, to take control decisions proactively based on context information about the near future. Finally, context-awareness can help to take decisions with the objective to increase the network efficiency as measured in spectrum, energy, processing resources, etc., and consequently to reduce operational expenses. For instance, context information could allow for a more meaningful distribution of the network resources among competing flows that refer to different communication scenarios.

This book chapter handles a characteristic use case of context-aware management, to showcase its potential. More specifically, we study a scenario where "context awareness" refers to awareness of the location and duration of a forthcoming outage, namely of a restricted area of very low or zero bandwidth (e.g. limited coverage due to physical obstacles or limited capacity due to high network congestion). Based on this knowledge, we devise a proactive HAS strategy that will enhance the viewing experience of a user travelling inside a vehicle towards this area.

Related work involves HAS strategies that use geo-location information ([11,12]), and evoke users to send measurements regarding their data rate, so that an overall map of bandwidth availability can be created for a certain area. Other HAS techniques rely on prediction, rather than context-awareness. For instance, [13] describes a HAS method where higher quality segment requests are a posteriori replaced with lower ones, as soon as a zero-bandwidth spatiotemporal event is identified. Moreover, similarly to our approach, [14] proposes an anticipatory HAS strategy, which requires prediction of the channel state in terms of Received Signal Strength (RSS) and proactively adjusts the user's buffer. An optimization problem is formulated that minimizes the required number of spectrum resources, while it ensures the user buffer is better prepared for an imminent coverage loss. The authors even conducted a demo of this approach in [15] that serves as a proof of concept. Our difference with this approach, is that we rely on longer-term context-awareness rather than imminent channel prediction, and that instead of manipulating the user buffer size, we proactively adapt the video quality selection. Finally, [16] combines RSS information with localization sensors from the smart phones that reveal the user's coverage state and help achieve a smoother and stabler HAS policy, called Indoors-Outdoors aware Buffer Based Adaptation (IOBBA).

## **2 System Analysis**

## **2.1 System Model**

The environment under study is a mobile cellular network. We consider a cell, where one base station is offering connectivity to multiple users, residing inside the cell. Here we focus on TCP-based video streaming service users (e.g. YouTube videos) and therefore, we focus only on the Downlink (DL).

Due to the challenges introduced by the access part of the network, namely due to pathloss, shadowing, fading and penetration losses, as well as due to the mobility of the users within this cell, the channel strength and quality may fluctuate significantly from user to user, from location to location, and from time to time. The existence of an outage inside a cell poses a high risk for the viewing experience of mobile video streaming users, since it might lead to a stalling event.

In the context of this scenario and with the assistance of Fig. 1, we can mathematically represent the system model and problem statement. Assume that a video streaming user is inside a vehicle (such as a bus or train), which is travelling with a particular direction and with a specific speed. We assume, that the positioning and the length of an upcoming outage are known in advance (due to context awareness). As a result, the remaining distance between the vehicle and the outage's starting point is also available at the client side. This distance corresponds to a travelling time of t*dist*, namely the time required until the user enters the outage region. Let b be the current buffer status of this user's HAS application; Then, during t*dist*, this buffer level will be boosted by b+ but also reduced by b−. Similarly, throughout the outage duration, the buffer will be boosted by b*outage*+ but also reduced by b*outage*−. When the user enters (exits) the outage region, the application's buffer level will be b*outage*−*in* (b*outage*−*out*), respectively, and it will hold that:

$$b\_{outage-in} = b + b\_{+} - b\_{-} \tag{1}$$

$$b\_{outage-out} = b\_{outage-in} - b\_{outage-} \tag{2}$$

because b*outage*+ is assumed equal to zero, namely there is negligible or no connection to the base station inside the outage region. Then, we can express the objective of the proposed HAS strategy as the following:

$$b\_{outage-out} \ge b\_{thres} \tag{3}$$

which means that when the vehicle is exiting the outage region, the buffer status of the HAS application should be at least equal to the minimum buffer threshold, b*thres*, which ensures that the video playout continues uninterrupted. Note that, a stalling always occurs when b<b*thresh*. The last condition can be re-written as:

$$b\_{+} \ge b\_{thres} + b\_{-} + b\_{outage-} - b \tag{4}$$

This condition answers the question about how much should the buffer of the HAS application be pro-actively filled during t*dist* (namely from the time of reference up to the outage starting point), so that no stallings will occur. This should be achieved despite the imminent connection disruption. Note that all the parameters on the right hand side are known to the client or can be easily estimated (b*thres* is fixed, b is directly known to the client application, while b−, b*outage*− can be estimated). It needs to be stressed out that all previous bufferrelated variables may be expressed either in seconds, i.e. buffer playtime, or in bytes, i.e. buffer size.

Based on the previous system model we can estimate the b+, namely the required buffer boost (in bytes or in seconds) to avoid any stalling during the outage duration. This measurement can be then further translated to a required "advance time", t*adv*, until which the travelling user needs to be notified about the existence of the outage (namely, its starting position and duration), in order to run the proactive HAS strategy proposed here. We assume that the users switch from a standard HAS strategy to the adapted one exactly at t*adv*. We can express b+ as a function of t*adv* as follows:

$$b\_{+} = r \ast t\_{adv} \tag{5}$$

where r (bytes per second) is the estimated data rate by the client's application. Namely, r is the user's prediction of the available network bandwidth, as estimated by the HAS strategy. Therefore, the minimum required advance time in order to avoid any stalling would be:

$$t\_{adv} \ge \frac{b\_{thres} + b\_- + b\_{outage} - b}{r} \tag{6}$$

To avoid a stalling, t*adv* should be less than the remaining t*dist*, namely the user should be notified early enough to react.

**Fig. 1.** Problem description using buffer status information.

#### **2.2 Optimization Problem**

The goal of this section is to formulate a problem that achieves optimal segment selection with respect to three different optimization objectives, described next. The optimization problem is formulated using the following notation1:

1 [17] is used as a reference.

Then:

$$D\_i = T\_0 + i\tau, \quad \forall i = 1, \ldots, n. \tag{7}$$

Also:

QoE studies on HAS (e.g. [18,19]) have revealed that major quality influence factors are in order of significance: *a*) the layers selected and especially the time spent on highest layer and *b*) the altitude, i.e. the difference between subsequent quality levels (the smaller the better). Other factors with less significance are: the number of quality switches, the recency time and the last quality level. Taking these findings into account, we focus on three different types of optimization objectives, which aim to maximize the positive impact of higher level selection, deducing the negative impact of quality switches and altitude. Three different versions of optimization objectives are thus formulated, as follows:

This leads us to the three different formulations of the optimization problem for one user:

– W: Maximize the quality layer values:

$$\text{maximize} \sum\_{i=1}^{n} \sum\_{j=1}^{r\_{max}} \alpha w\_{ij} x\_{ij} \tag{8}$$

– W+S: Maximize the quality layer values minus the number of switches:

$$\text{maximize } \sum\_{i=1}^{n} \sum\_{j=1}^{r\_{max}} \alpha w\_{ij} x\_{ij} - \frac{1}{2} \sum\_{i=1}^{n-1} \sum\_{j=1}^{r\_{max}} \beta (x\_{ij} - x\_{i+1,j})^2 \tag{9}$$

– W+S+A: Maximize the quality layer values minus the number of switches and the altitude difference:

$$\text{maximize} \sum\_{i=1}^{n} \sum\_{j=1}^{r\_{\max}} \alpha w\_{ij} x\_{ij} - \frac{1}{2} \beta \sum\_{i=1}^{n-1} \sum\_{j=1}^{r\_{\max}} \left[ \left( x\_{ij} - x\_{i+1,j} \right)^2 + \frac{\left( x\_{ij} - x\_{i+1,p} \right)^2}{|p-j|} \right] \tag{10}$$

where

$$p = \{1..r\_{max}\} - \{j\}$$

Despite its complication, the terms in the last parenthesis of Eq. (10) represent the preference over switches between "neighbor" layers (i.e. after a layer 1 selection, layer p = 2 switches will be preferred/after a layer 2 selection, either layer p = 1 or p = 3 switches will be preferred/while after a layer 3 selection, layer p = 2 switches will be preferred).

All above optimization objectives are subject to the following constraints:

$$x\_{ij} \in \{0, 1\} \tag{11}$$

$$\sum\_{j=1}^{r\_{\max}} x\_{ij} = 1, \quad \forall i = 1, \ldots, n \tag{12}$$

$$\sum\_{i=1}^{k} \sum\_{j=1}^{r\_{max}} S\_{ij} x\_{ij} \le b(D\_k), \quad \forall k = 1, \ldots, n \tag{13}$$

The three constraints in this problem are interpreted as follows: x*ij* is a binary value (Eq. (11)) meaning that a segment is either downloaded or not, each segment has to be downloaded in exactly one layer (Eq. (12)), and all segments need to have been downloaded before their deadline, so that no stalling occurs (Eq. (13)).

#### **2.3 HAS-Based Strategy**

The proposed strategy needs to avoid stallings during the outage, something which is extremely high likely to occur due to the very low network coverage. The main idea to ensure that is to pro-actively lower the requested quality level of the next segments a priori, i.e. before entering the outage area. As a consequence, the buffer at the user side when entering the outage region will be fuller than it would have been without such a scheme (see Fig. 2)2.

As a result of this strategy, the user viewing experience will be less affected, not only because the video will continue to play without a stalling for a longer

2 This figure is adapted from [20].

**Fig. 2.** Adaptive video streaming scenario with and without context awareness.

period of time, or hopefully will never stall depending on the outage duration, but also because the quality level will be *gradually* decreased and thus the user will be better acquainted with lower quality levels. Such progressive quality degradations would be preferred in comparison to sudden and unexpected quality degradations, especially if the quality level is already very high (cf. the IQX hypothesis [21]). Consequently, the objective of the proposed strategy is to compute the optimal context-based quality level selection to ensure the best QoE while avoiding any stallings.

The HAS strategy is based on the estimation of the required buffer boost b+ as this was described in Sect. 2.1. As for the estimation of the expected downlink rate (network bandwidth prediction), this is assumed equal to the segment rate. The segment rate estimation (in bytes per second) is done over a sliding window of the past k downloaded segments as follows:

$$r = (1 - w) \* \frac{Size\ of\ last\ (k-1)\ segments}{Time\ to\ download\ (k-1)\ segments} + w \* \frac{Size\ of\ segment\ k}{Time\ to\ download\ segment\ k} \tag{14}$$

where w is the weight (importance) given to the latest downloaded segment. Based on this rate estimation, the expected bytes that can be downloaded until the user enters the outage region is:

$$b\_{+expected} = r \ast t\_{adv}, \quad \text{(in } bytes\text{)}\tag{15}$$

while the minimum required buffer playtime to exit the outage region and avoid a stalling is:

$$b\_{+} = b\_{thres} + b\_{-} + b\_{outage-} - b, \quad (in \, seconds) \tag{16}$$

Therefore, the required bytes per segment are:

$$required\,vide\,or\,rate = \frac{b\_{+}expoted}{b\_{+}}, \quad (in\,bytes\,\,per\,\,second) \tag{17}$$

Note that the higher the outage duration, the larger the b+ and thus the lower the required video rate (lower layer selection). Based on the required video rate estimation, the HAS strategy will request the highest possible representation j that fulfills this condition:

$$\frac{S\_{ij}}{\tau} \le required \, video\, rate \tag{18}$$

Namely, the layer j that will be requested will be the highest one that yields a video bit rate less or equal to this estimation. The "required video rate" estimation may be updated each time in order to account for the most recently achieved data rate r. Alternatively, an average value may be calculated in the beginning (on t*adv*) and assumed valid until entering the outage region. In the case that the actual available data rate for this user is less than his subjective rate estimation, r, there is, however, a higher risk of stalling. We assume that the player requests the lowest layer when initialized.

#### **2.4 QoE Models**

The QoE models that are used in this work are the following:

– A QoE model for HAS, where no stallings are assumed. This model can be found in [17] and it can be described by the following formula:

$$QoE = 0.003 \ast e^{0.064 \ast t} + 2.498 \tag{19}$$

where t is the percentage of the time that the video was being played out at the highest layer (here layer 3).

– A QoE model for TCP-based video streaming, if stallings occur. This model can be found in [22] and it is described as follows:

$$QoE = 3.5 \ast \exp(-(0.15 \ast L + 0.19) \ast N) + 1.5\tag{20}$$

where N is number of stalling events and L is the stalling length.

For the purposes of this scenario we combine the two aforementioned models, so that in case that no stalling has occurred, the former QoE model is used, while during and after a stalling event, we use the latter.

## **2.5 Realization in the Network**

In this section, we provide some insights regarding the realization of the proposed scheme in a real network. Specifically, the information required so that this framework can work already is or can become easily available, namely:

As far as the need for "Big Data" mentioned before is concerned, this may take two forms: Either they could be data collected at the device itself because the user has the same travel profile every day and, therefore, learns about any coverage problems on his way, or, the data are collected at a central network point (e.g. at a base station or a server) through measurements collected by any devices passing from there. Actually, in Long Term Evolution (LTE) networks, such measurements are already available via "Channel Quality indicators - CQI". CQIs report to the LTE base station (eNB - evolved NodeB) about the quality of the received signals (SINR - Signal to Interference plus Noise Ratio) using values between 1 (worst) and 15 (best). Currently, CQIs are used only for realtime decisions such as scheduling; however, we may envision that CQIs may be collected by an eNB on a longer-term time scale (days or weeks), and be used in order to create a "coverage profile" of the cell. Following such past information, proactive measures could be taken at a cell for users travelling towards problematic areas (e.g. a physical tunnel ahead).

## **3 Evaluation Results**

For the purposes of evaluation we use Matlab simulation. The client's buffer is simulated as a queuing model, where the "DOWNLOADED" segments are arrivals and the "PLAYED" segments are departures. To simulate the network traffic, we use real traces recorded from a network [23]. Moreover, to simulate congestion we use the parameter "bandwidth factor3", which is a metric of the network congestion/traffic and takes values between 0 and 1 (the higher this factor the lower the congestion).

3 The bandwidth factor concept is extracted from [17].

The parameters used in our simulation are presented at Table 1:

**Table 1.** Simulation parameters.

#### **3.1 Proof of Concept**

The first evaluation study mainly serves as a proof of concept of the enhanced HAS logic. The goal is to demonstrate how a context-aware HAS policy can help overcome an otherwise inevitable buffer depletion and thus, an imminent stalling event. To demonstrate that, we plot four different metrics: (*a*) the client buffer size in bytes, (*b*) the client buffer size in seconds (i.e. buffer playtime), (*c*) the HAS layers selected for each played out segment, and finally (*d*) the QoE evolution in time for the travelling user. For the latter, we make the assumption that the QoE models presented in Sect. 2.4 hold also in a real-time scale, and that the QoE model for HAS holds for the tested scenario where three different layers are available per segment. Real-time estimation of the QoE for a particular user means that QoE is estimated at every time instant t using as input accumulated information about the percentage of time that this user has already spent watching the video at layer 3 up to instant t, as long as no stalling has occurred yet, or information about the number N and duration L of stalling events since t = 0 up to instant t, as long as at least one stalling has occurred.

As shown in Fig. 3, three different cases are considered, namely (*a*) the conventional case, where no context awareness about the outage event is available, and consequently, the standard HAS strategy is implemented, (*b*) the case where context awareness about the starting point and duration of the outage event is available, which leads to the selection of the adapted, proactive HAS strategy, and finally (*c*) the optimal case (W) described in Sect. 2.2. Examining Figs. 3a and b we can see that a stalling of around 80 s is completely avoided when context awareness is deployed, or when optimal knowledge is assumed. The explanation behind the prevention of the stalling lies in Fig. 3c. In the "without context" case higher HAS layers are selected as compared to the "with context" case

**Fig. 3.** Client behavior with context awareness, without context awareness, and optimal behavior (W).

(mainly with layer = 2), especially around the outage occurrence, which here starts and ends at 200 s and 400 s, respectively. Having downloaded lower HAS layers in the "with context" case, the buffer of the client is fuller in terms of playtime than it would have been if higher HAS layers had been downloaded instead. The impact on QoE for all cases is also presented in Fig. 3d, where we can see that even a single stalling event of a few seconds' duration has a significantly deteriorating impact on the perceived QoE, as compared to the selection of lower HAS layers. QoE values per strategy follow the trend of layer selection: this is why the "context case" at some periods reveals higher QoE than the "optimal" case (the former requests more layer 3 segments before the outage).

Comparing now the enhanced HAS strategy with the optimal strategy, we observe that the latter does a better job in selecting higher quality layers (especially layer 2 segments) up to the point of the outage start. The reason is that the optimal strategy has full awareness of the future network conditions and thus, can take more informed decisions that lead to the highest layer selection with zero stalling risk.

#### **3.2 Required Advance Time Estimation ("Context Time")**

Next, we study how the outage duration influences the required advance time, t*adv* and present the results in Fig. 4 (mean and standard deviation). We observe an intuitively expected trend, i.e. that the user needs to initiate the proactive HAS strategy earlier for longer outage durations (i.e. a higher t*adv* is required). In this way, the user has more time to buffer sufficient playtime. Moreover, the standard deviation follows the same trend, indicating higher uncertainty for longer outages. The required advance time strongly depends on the achieved data rate per user, which for the purposes of simulation is a result of the network traces and bandwidth factor.

**Fig. 4.** The minimum required advance time (t*adv*) to avoid a stalling event during an outage.

#### **3.3 Comparison of Different Strategies**

Next we perform a study with respect to the availability of bandwidth, in order to evaluate how HAS performs in bandwidth-challenging scenarios. Since we use real traces as input information about the data rates in the network, we can indirectly enforce a network congestion by multiplying the measured bandwidth with the aforementioned bandwidth factor.

(a) With context awareness: Minimum required advance time (*tadv*) to avoid a stalling event in light of an outage event of 150sec for various bandwidth factors.

(b) Without context awareness: Stalling probability for various bandwidth factors.

**Fig. 5.** Simulation results for various bandwidth factors with and without context awareness.

The purpose of the first study with regard to the bandwidth factor is to investigate how it influences the minimum advance time t*adv* in the case of context awareness, and how it influences the stalling probability in the conventional context unaware case. The results are presented in Fig. 5. As demonstrated in Fig. 5a, for very low data rates (e.g. a bandwidth factor of 0.2), the minimum required advance time gets higher, as the user would need a much greater timemargin to proactively fill the buffer in light of the outage, because the network is heavily congested. Moreover, the uncertainty in this case is also very high, a conclusion that we have seen at the previous section as well. On the contrary, the more relaxed the network conditions, the higher the margin for an early notification about the outage, while this practically gets zero seconds (i.e., no notification is needed) when the network conditions are very relaxed (bandwidth factor = 1). Similar conclusions are drawn for the context-unaware case with regard to the stalling probabilities for different bandwidth factors, namely the less this factor, the higher the stalling probability, as expected (Fig. 5b).

Next, we compare the behaviour of the three different types of the optimal strategy (i.e. cases W/W+S/W+S+A, as described in Sect. 2.2) both among them, but also with the context-aware strategy. In Figs. 6a–d, the percentage of time spent on each of the three layers as well as the resulting number of switches are presented per strategy. All four strategies follow a similar trend as bandwidth availability increases, that is higher and higher layer 3 segments are selected, while lower and lower layer 1 segments are selected. With respect to layer 2 segments, the behaviour is different when the bandwidth factor changes from 0.25 to 0.5 (increasing layer 2 selection) from when it changes from 0.5 to 1 (decreasing layer 2 selection). Note that a bandwidth factor of 0.25 represents very high congestion and a bandwidth factor of 1 represents very low congestion.

Another interesting observation is that strategy W+S+A "avoids" layer 2 segments almost completely. The reason behind that is that layer 2 in W+S+A is mostly used as a "transition step" to switch to layer 1 or layer 3, respecting the objective to keep the altitude of two sequential layers as low as possible. Equation (10) gives the same priority to staying at the same layer and to switching to a +1 or −1 layer. Perhaps, this is not necessarily the best action in terms of QoE, but there is no complete HAS QoE model to be able to build the perfect optimization function. However, the optimization goal of low altitude between successive layers holds. On the contrary, strategy W+S has a tendency to select many layer 2 segments, which is explained by its goal to minimize the switches and thus operate at a stable but safe level. We have also tested a "W+A" optimal strategy (not mentioned in Sect. 2.2), but this has been found to cause too many quality switches; therefore it was not considered for further investigation.

It is important to note that no optimal strategy is considered "better" than the other; They all represent how different optimization objectives behave under varying bandwidth conditions. However, once a validated multi-parameter QoE model for HAS becomes available in the future, the optimization problem could be revisited.

In terms of quality switches caused, which is another important QoE impairment factor, the context aware strategy and the optimal W strategy cause the highest number of switches, since they do not take measures to prevent them (see Fig. 6d). On the contrary, the optimal W+S and optimal W+S+A strategies cause the least number of switches. Between the last two, W+S+A causes more switches, as it puts equal priority to mitigating switches and keeping the altitude of any switches at a low level.

(a) Percentage of time spent on layer 1.

(b) Percentage of time spent on layer 2.

(c) Percentage of time spent on layer 3.

**Fig. 6.** Simulation results for various bandwidth factors for the three optimal cases W/W+S/W+S+A as well as the context-aware strategy.

#### **3.4 The Impact of Unreliability of Context Information**

In this section we study how unreliability in the context information influences the probability of having a stalling event. In other words, we study how risky the proactive HAS strategy is to lead to a stalling, when accurate information about the outage starting point is missing or when it is impossible to have this information on time.

For the purposes of this experiment, we assume that the buffer of the user is not limited, and therefore the user will continue to download as many bits as its connectivity to the base station allows. As a consequence, the starting point of the outage plays an important role, since the further away it is from the vehicle's current location, the fuller the buffer of the client will be under normal circumstances up to that point. Thus, also the stalling probability will be lower. Overall, this study evaluates to what extent an unexpected outage is mapped to a stalling probability.

The results under this perspective are presented in Fig. 7. As expected, the further away the outage, the less the stalling probability. However, it might be more meaningful to conduct the same study assuming a limited buffer size of the client's application, which is a more realistic assumption. In that case, we would expect that the starting point of the outage would not play such a crucial role, but the maximum size of the buffer would. Note that a normal value for an upper threshold in the number of buffered segments would be 50 segments. However, this study still provides some insights about the impact of unexpectancy regarding the outage starting point.

**Fig. 7.** The impact of the outage starting point on the stalling probability.

Next, we would like to investigate what happens if the context information is not communicated to the client as 100% accurate or, similarly, if it is not communicated early enough in advance (so it is accurately communicated but with some delay). Specifically, we assume that the information about the t*adv* deviates from its mean value, as this was estimated in Sect. 3.2. This mean value is considered to represent a "0% deviation" in the following figures. From Figs. 8a and b, which represent the stalling probability and stalling duration respectively, we draw two main conclusions. Firstly, we confirm that the mean values of t*adv* are not enough to prevent a stalling, due to the fact that standard deviations have not been taken into account. In fact, as presented in Sect. 3.2, the standard deviations are higher for larger outage lengths and thus we observe higher stalling probabilities for the 0% values (compare the three plots per figure).

A second important conclusion, which is the emphasis of this simulation study, is that a potential uncertainty in this context information can lead to inevitable stallings. This is interpreted both in terms of stalling probabilities and stalling lengths. This emphasizes the need for accurate and timely context information, which also takes into account statistical metrics such as the standard deviation.

**Fig. 8.** Stalling effects when t*adv* deviates from its mean value.

## **4 Conclusions**

In this chapter, a novel proactive HAS strategy has been proposed and evaluated, demonstrating significant benefits as compared to the current approaches in terms of QoE and meaningful KPIs such as stalling probability. The proposed strategy can successfully help prevent stallings at the client's HAS application during network coverage problems. The "cost to pay" is the collection and signalling of context information, which could however be realistically implemented; therefore its adoption in a real network should not be difficult.

Even though this work focused on outage conditions of zero bandwidth, we could easily extend this solution to a more general problem where bandwidth may be insufficient (but not zero). Similarly, the same problem could be adjusted for cases of an imminent service disruption such as a handover, where the aforementioned HAS strategy can help prevent stallings during the disruption period (i.e. the handover period). This may become possible by exploiting handoverhinting information, a priori. In this way, the user will be better prepared for a potential interruption in his viewing experience.

It would be also interesting as future work to study a scenario of more than one mobile video streaming users using HAS, and investigate how the decisions of one user potentially affect the others. Stability and fairness issues, together with QoE analysis would be of great interest in this case.

Finally, as a general comment, we would like to point out that this work could be revisited once a standard QoE model for HAS becomes available. In that case, we could have the opportunity not only to produce a more accurate optimization problem, but also to enhance the proposed HAS strategy, focusing on the key factors that mostly influence the end-users' QoE.

## **References**

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

# **Conceptual and Analytical Models for Predicting the Quality of Service of Overall Telecommunication Systems**

Stoyan Poryazov1(✉) , Emiliya Saranova1,2 , and Ivan Ganchev1,3,4

1 Institute of Mathematics and Informatics, Bulgarian Academy of Sciences, Sofia, Bulgaria<EMAIL_ADDRESS><EMAIL_ADDRESS>2 University of Telecommunications and Post, Sofia, Bulgaria 3 University of Limerick, Limerick, Ireland<EMAIL_ADDRESS>4 University of Plovdiv "Paisii Hilendarski", Plovdiv, Bulgaria

**Abstract.** This chapter presents scalable conceptual and analytical performance models of overall telecommunication systems, allowing the prediction of multiple Quality of Service (QoS) indicators as functions of the user- and network behavior. Two structures of the conceptual presentation are considered and an analytical method for converting the presentations, along with corresponding additive and multiplicative metrics, is proposed. A corresponding analytical model is elaborated, which allows the prediction of flow-, time-, and traffic char‐ acteristics of terminals and users, as well as the overall network performance. In accordance with recommendations of the International Telecommunications Union's Telecommunication Standardization Sector (ITU-T), analytical expres‐ sions are proposed for predicting four QoS indicators. Differentiated QoS indi‐ cators for each subservice, as well as analytical expressions for their prediction, are proposed. Overall pie characteristics and their causal aggregations are proposed as causal-oriented QoS indicators. The results demonstrate the ability of the model to facilitate a more precise dynamic QoS management as well as to serve as a source for predicting some Quality of Experience (QoE) indicators.

**Keywords:** Overall telecommunication system · Performance model Overall causal QoS indicator · Dynamic QoS management Telecommunication subservices · Differentiated QoS subservice indicator QoS prediction · Human factors of QoS

## **1 Introduction**

The telecommunication service is the basis for the Information Service Networks. From the very beginning the Internet began its existence as a packet-based communication system without guarantees for the quality of the services, which are provided on a besteffort basis. At the same time, with the evolution of hardware technologies, and services and applications becoming more and more complex, the quality of service (QoS) has become a hot topic and the term "Internet QoS" has widely spread. The question of providing QoS guarantees in the Internet is still open (c.f., for instance, the history of the Internet Engineering Task Force (IETF) standards for Integrated Services (IntServ) and Differentiated Services (DiffServ) as well as the Third Generation Partnership Project (3GPP)/European Telecommunications Standards Institute (ETSI) Internet Protocol (IP) Multimedia Subsystem (IMS) initiative).

The QoS has many aspects – QoS offered by the provider, QoS delivered (QoSD), QoS achieved by the provider, QoS experienced by the user/customer (QoSE or QoSP – QoS perceived) and others. "The understanding of QoSE is of basic importance for the opti‐ mization of the income and the resources of the service provider" [1]. A new attitude towards the QoS has become dominant – QoS and Quality of Experience (QoE) are considered as goods. The agreement is made according to the perceived quality – Expe‐ rience Level Agreement (ELA) [2]. This approach considerably increased interest in the perceived quality among researchers, providers, and users of telecommunication services.

As a result of the intensive research, the definition of QoE evolved and at the moment the QoE is perceived as a degree of satisfaction or irritation of the users of some appli‐ cation or service which is a result of the fulfillment of their expectations about the utility or/and the satisfaction from the application or service in the context of the user's person‐ ality and the current state [3, 4]. The QoS perceived by users depends not only on the quality offered by the provider but also on the context of the services, including the techno-socio-economic environment, user's context, and other factors. The importance of the teletraffic models, particularly of the overall QoS indicators, for QoE assessment is emphasized by Fiedler [5].

From among the many services provided by a telecommunication system, this chapter deals with flow-, time-, and traffic characteristics of the connection and commu‐ nication services. The other QoS characteristics of information transmission service are reflected partially and indirectly as a probability of the call attempt abandoning by users.

The main objective of the authors of this chapter is the development of scalable performance models of overall telecommunication systems, as a part of Information Service Networks, including many of the observable system-dependent factors deter‐ mining the values of QoS indicators.

These models may be used for multiple purposes but the aim of this chapter is to develop prediction models for some key QoS indicators' values, as functions of the user behavior and technical characteristics of the overall telecommunication system. Such values may be useful for the network design, for the management of telecommunication systems' QoS, and as a source for predicting some QoE indicators.

The work presented in this chapter continues the development of the approach for the conceptual and analytical modeling of overall telecommunication systems (with QoS guarantees), presented in [6].

Firstly, in Sect. 2, a scalable conceptual model of an overall telecommunication system with QoS guarantees is presented. Two structures of the conceptual presentation are compared – the normalized structure and the pie structure. An analytical method for converting the presentations, along with corresponding additive and multiplicative metrics, is proposed. A qualitative extension of the conceptual model, in comparison with [7], is proposed. This includes two new service branches corresponding to the cases of 'called party being busy with another call' and 'mailing a message'. This allows analyzing telecommunication systems' QoS indicators as a composition of QoS indi‐ cators of consecutive and parallel subservices.

The developed model is based on: a Bernoulli–Poisson–Pascal (BPP) input flow; repeated calls; limited number of homogeneous terminals; 11 cases of losses of call attempts (due to abandoning, interrupting, blocking, and unavailable service); and three successful cases (normal interactive communication, communication after call holding, and mailing). The calling (A) and called (B) terminals (and users) are considered sepa‐ rately, but in interaction to each other. This allows formulation of QoS indicators sepa‐ rately for A-, B-, and AB-terminals.

In Sect. 3, on the basis of the developed conceptual model, a corresponding analytical model is elaborated. User behavior parameters and technical characteristics of the tele‐ communication network serve as an input for the model. The model itself is intended for systems remaining in a stationary state. It is insensitive to the distributions of random variables and provides results in the form of mean values of the output parameters. The model is verified for the entire theoretical interval of network load. It allows the predic‐ tion of flow-, time-, and traffic characteristics of A-, B-, and AB-terminals (and users), as well as of the overall network performance.

In accordance with recommendations of the International Telecommunications Union's Telecommunication Standardization Sector (ITU-T), analytical expressions for the prediction of three QoS indicators are proposed:

Four differentiated QoS indicators for each subservice are proposed along with analytical expressions for their prediction:

The four QoS specific indicators are independent. They are components (in multipli‐ cative metrics) of the ITU-T concordant Overall Call Attempt Efficiency indicator (*Ec*):

$$Ec = Ecs\ Qb\ Q\ \mu\ Qc.$$

The usage of the proposed QoS indicators of telecommunication subservices allows conducting a more specific QoS analysis and more adequate QoS management.

In Sect. 4, in accordance with the ITU-T recommendations, analytical expressions for the prediction of the Overall Traffic Efficiency Indicator and other overall pie parameters and their causal aggregations are proposed and illustrated numerically. The overall pie characteristics and their causal aggregations could be considered as causaloriented QoS indicators. The results allow a more precise estimation of the dynamic importance of each reason of call attempts finishing and thus a more precise dynamic effort targeting of the QoS management.

In the Conclusion, possible directions for future research are discussed.

## **2 Conceptual Model**

## **2.1 Background**

At the telecommunication system level, Ericson has proposed a reference model consisting of five parts – terminals, access-, transport-, network management-, and network intelligence part [8]. We have extended this reference model by making differ‐ ence between the telecommunication system and the telecommunication network, and by applying the present ITU-T terminology (Fig. 1). It contains seven parts (subsystems): (1) Network Environment (natural-, technological-, and socio-economic environment); (2) Users; (3) Subscribers/Customers1; (4) Terminals; (5) Telecommunication Network; (6) Network's Information Servers (network intelligence); and (7) Telecommunication Administration (network service provider). The interaction between subsystems (if any) is presented by a common border between their representing rectangles in Fig. 1. Each subsystem is part of the environment (context) of the other subsystems.

1 According to [1], the user is "A person or entity external to the network, which utilizes connec‐ tions through the network for communication", whereas the customer is "A user who is responsible for payment for the services".

For designing and managing telecommunication systems one needs scalable models in all aspects of the term 'scalability': "*scale down*: make smaller in proportion; reduce in size"; "*scale up*: make larger in proportion; increase in size"; "*to scale*: with a uniform reduction or enlargement" [10]. Models' scalability includes: temporal-, spatial-, struc‐ tural-, parametric-, conceptual-, functional-, and etc. scalabilities.

*Basic Virtual Devices:* At the bottom of the structural model presentation, we consider 'basic virtual devices' that do not contain any other virtual devices. A basic virtual device has the graphic representation as shown in Fig. 2.

**Fig. 2.** A graphical representation of a basic virtual device *x*.

Parameters of the basic virtual device *x* are the following (c.f. [11] for terms definition):

*Fx* – Intensity or incoming rate (frequency) of the flow of requests (i.e. the number of requests per time unit) to device *x*;

*Nx* – Number of lines (service resources, positions, capacity) of device *x*.

**Functional Normalization:** In our models, we consider monofunctional idealized basic virtual devices of the following types (Fig. 3):

**Fig. 3.** A graphical block representation of the main basic virtual mono-functional devices used.

**Structural Normalization:** Following the theorem of Böhm and Jacopini [12], we use basic virtual devices mainly with one entrance and one exit. Exceptions are: the transi‐ tion device, which in our structural normalization has one entrance and two exits (for splitting the requests' flows) or two entrances and one exit (for merging the requests' flows); and the copier with its one entrance and two exits.

**Causal Structure Presentation:** Any service may end due to many reasons. In a tele‐ communication network, all reasons are classified into four types: network failures, user failures (ineffective calls associated with the callers and callees), network service provider failures, and successful ending (completed seizures) [13, 14]. The 'cause value' field in [14] contents 99 items. In [13], there are 127 'cause value' numbers. Cisco lists 131 'call termination cause codes' and 44 'Cisco-specific call termination cause codes' [15].

*Complex Virtual Devices:* Each reason for service ending has its own probability to occur and mean service time (duration). In our conceptual model, the service execution goes through different stages (e.g. dialing, switching, ringing, etc.), each consisting of different phases. Each stage of a modeled service corresponds to one (or more) complex virtual device and contains 'service branches' (service phases). Typically, a service phase includes a service device and all necessary auxiliary devices such as queues, entry and exit devices, as well as virtual devices reflecting the user behavior, associated with this phase, e.g. the waiting time before initiating a repeated call attempt. Each service branch corresponds to a different reason of service ending. The service branches form the 'causal structure' of the modeled service. The causal structure of a complex virtual device *x* (with input requests' flow frequency *Fx*, mean service time *Tx*, and traffic inten‐ sity *Yx*) could be presented in two ways – by using a normalized structure or a pie structure (Fig. 4).

**Fig. 4.** (a) A complex virtual device *x*, representing a service with *k* reasons for ending; (b) the normalized causal structure of device *x*; (c) the pie causal structure of device *x*.

Both structures include *k* virtual 'causal devices', each with its own mean input requests' flow frequency *Fi* , mean service time *Ti* , and traffic intensity *Yi* . Obviously:

$$Y\_x = \sum\_{i=1}^k Y\_i; \quad F\_x = \sum\_{i=1}^k F\_i. \tag{1}$$

The difference between the two presentations is in the internal flow structures only. In the pie causal structure (Fig. 4c), all causal service branches have common beginning. The probability *Pp*,*i* shows what part (pie) of the service incoming flow is directed to the causal device *i*. All probabilities *Pp*,*i* are dependent:

$$\sum\_{i=1}^{k} P\_{p,i} = 1.\tag{2}$$

In the normalized causal structure (Fig. 4b), all service branches are ordered consec‐ utively as derivations of one 'successful completed service branch'. The probability *Pn*,*i* shows what part of the flow, already passed through the previous causal branches, is derived to the considered service case (causal device) *i*. The probabilities *Pn*,*i* are inde‐ pendent (orthogonal, normal). The order of causal branches does not matter (has no mathematical meaning) but usually the branch of successful completion of the service (*Pn*,*k*) is the last one.

Both structures lead to different presentations of the same QoS indicators. For example, the probability (resp. efficiency *Ec*) for successful completion of the service in the normalized (3) and pie presentation (4) is respectively:

$$E\_c = \prod\_{i=1}^{k-1} (1 - P\_{n,i}).\tag{3}$$

$$E\_c = 1 - \sum\_{i=1}^{k-1} P\_{p,i} \,\tag{4}$$

The normalized- and pie structures are used by many authors but usually without these associated names, and without discussions about the nature of parameters and how one structure could be converted to the other. For example, in [16] expressions like (2), (3) and (4) are classified as 'aggregation functions', whereas (2) is additive, (3) is multi‐ plicative, and (4) is not specified.

The conversion between the values of the normalized and pie probabilities (and vice versa) could be done by means of the following system of *k* equations with *k* variables (*Pn*,*i* or *Pp*,*j* , *j* = 1, 2, 3, …, *k*):

$$\begin{cases} P\_{p,j} = P\_{n,j}, & \text{if } j = 1\\ P\_{p,j} = P\_{n,j} \prod\_{i=1}^{j-1} (1 - P\_{n,i}), & \text{if } j = 2, \dots, k \end{cases} \tag{5}$$

Each structure has advantages over the other. The normalized structure allows clearer conceptual presentation and simpler inference of the analytical models, but normalized probabilities depend on the causal branch positions. The pie structure is more natural and impressive in business presentations (pie charts, pie graphs). Each structure is a mathematical equivalent of the other. Both allow for model scalability.

#### **2.2 Conceptual Model**

We consider a virtual overall telecommunication system including users, terminals and possibly several telecommunication networks, operated by different operators. We consider VNET carrying Class 0 traffic (real-time, jitter-sensitive, with high interaction (Voice over IP (VoIP), video teleconference) [17]. The VNET utilizes virtual channel switching principles, following the main method for traffic QoS guaranties – resource reservation [18]: "Bandwidth reservation is recommended and is critical to the stable and efficient performance of Traffic Engineering methods in a network, and to ensure the proper operation of multiservice bandwidth allocation, protection, and priority treat‐ ment."

In our approach, the overall network QoS parameters are aggregation of all end-toend QoS parameters of all terminals and connections in the network, within the consid‐ ered time interval (Fig. 5).

The VNET in Fig. 5 includes also users, not just the terminals, and generalizes call intensity, time- and traffic parameters of the calling (A), called (B) and all active (AB) terminals, as well as of the overall network equivalent switching lines, reflecting resources of all comprised telecommunication networks.

In this chapter, we propose a considerable extension of the conceptual and analytical performance models of the overall telecommunication system with QoS guarantees, described in [6]. This includes two new service branches corresponding to the cases of 'called party being busy with another call' and 'mailing a message'.

**Fig. 5.** A generalized VNET, including users and terminals, with overall QoS guaranties (a modification of [19]).

**Basic Virtual Devices' Name Notation.** In the normalized conceptual model, each virtual device has a unique name, depending on its position and the role it plays in the model (Figs. 6, 7, 8, 9 and 10).

**Fig. 6.** The basic virtual devices' name notation.

The model is partitioned into service stages (**d**ialing, **s**witching, **r**inging, **h**olding, **c**ommunication, and **m**ailing).

Each service stage has different branches (**e**ntered, **a**bandoned, **b**locked, **i**nterrupted, **n**ot **a**vailable, **c**arried), corresponding to the modeled possible cases of ending the service.

Each branch has two exits (**r**epeated, **t**erminated) that show what happens with the service request after it enters the telecommunication system. Users may make a new bid (repeated service request) or may stop attempting (terminated service request).

In the virtual devices' name notation, the corresponding first letters of the name of the branch exit, the branch, and the service stage are used (in this order) to form the name of the virtual device:

## = *<*  *>< >< >*

**Complex Virtual Devices' Names.** We use the following complex virtual devices (i.e. devices, consisting of several basic virtual devices):

*a* – a virtual device that comprises all A-terminals (i.e. the calling terminals) in the system. The *a* device is represented as a 'dotted line' box, named *a*0 in Fig. 7, *a* 1 in Fig. 8, *a* 2 in Fig. 9, and *a* 3 in Fig. 10;

*b* – a virtual device that comprises all B-terminals (i.e. the called terminals) in the system. The *b* device is represented as a 'dashed line' box, corresponding to the Bterminal load, in Figs. 8, 9, and 10;

*ab* – this device comprises all the active (i.e. calling and called) terminals in the system; *s* – a virtual device corresponding to the equivalent connection lines in the switching system. It is represented as a 'dotted and dashed line' box, named *s*, inside the *a*0 box in Fig. 7, and other *a* boxes (*a* 1 in Fig. 8, *a* 2 in Fig. 9, and *a* 3 in Fig. 10).

The network environment includes also basic virtual devices outside the *a* and *b* complex devices. Service requests in the environment do not occupy network devices, but rather form incoming flows out of demand and repeated call attempts.

**Fig. 7.** Service stages 'Dialing', 'Switching', and the beginning of stage 'Ringing'.

In Fig. 7, *Fo* is the intent intensity of calls2, with a Poisson distribution, generated by a terminal; *dem.Fa*3 is the intensity of demand (first, primary calls), generated by all A-terminals, according the BPP-traffic model (c.f. the modifier block in Fig. 7); *M* is a constant. In our approach, every value of *M* within the interval [−1, +1] is allowed. If *M* = −1, the intensity of the demand flow corresponds to the Bernoulli (Engset) distri‐ bution; if *M* = 0 – to the Poisson (Erlang) distribution; and if *M* = +1 – to the Pascal (Negative Binomial) distribution.

2 In this chapter, the term 'call' means 'service request', 'call attempt' or 'bid' according to the

terminology in [11]. 3 In the expressions, formulas and figures, the sign (.) is used only as a separator and NOT as a sign of multiplication. The multiplication operation is indicated by a gap between multiplied variables, e.g. *X Y*.

*rep*.*Fa* stands for repeated attempts, generated by A-users and A-terminals, in the case of unsuccessful call attempts; *Fa* is the flow generated by and occupying the Aterminals (it is a sum of the intensities of primary (demand) call attempts (*dem*.*Fa*) and repeated attempts *rep*.*Fa*).

Devices 'entered dialing' (*ed*), 'carried dialing' (*cd*), and 'carried switching' (*cs*), belong to the successful service branch.

Devices 'abandoned dialing' (*ad*), 'interrupted dialing' (*id*), 'blocked switching' (*bs*), 'interrupted switching' (*is*), 'not available switching (service, number)' (*ns*), and 'blocked ringing' (*br*) belong to the unsuccessful (due to different reasons) service branches. They reflect durations of the correspondent signaling, e.g. the 'busy tone' duration.

Devices 'repeated abandoned dialing' (*rad*), 'repeated interrupted dialing' (*rid*), 'repeated blocked switching' (*rbs*), 'repeated interrupted switching' (*ris*), 'repeated not available switching (service, number)' (*rns*), and 'repeated blocked ringing' (*rbr*) corre‐ spond to the duration of users' requests waiting, outside the network equipment, before the next repeated call attempt.

The device of type 'Enter Switch' (just before the 'blocked switching' (*bs* device) in Fig. 7) deflects calls if there is no free line in the switching system, with probability of blocked switching (*Pbs*). The second 'Enter Switch' device (after the block 'carried switching' (*cs*) in Fig. 7) deflects calls, with probability of blocked ringing (*Pbr*), if the called B-terminal is busy.

Note that there is no B-terminal traffic in the part of the conceptual model, presented in Fig. 7.

**Fig. 8.** Service stages 'Ringing' (end), 'Communication', and 'B-terminal Load' (Case 1).

Figure 8 presents the call flows, in Case 1, when the B-terminal is found free (c.f. Connector 1 in Figs. 7 and 8). In this case, the flow intensity, occupying the B-terminal, is generated by the Copy device (c.f. Connector B1), because at the beginning of the ringing stage, the B-terminal becomes busy. In Case 1, the traffic load on the A-terminal equals the traffic load on the B-terminal.

**Fig. 9.** Service stages 'Holding', 'Communication', and 'B-terminal Load' (Case 2).

Figure 9 presents the call flows, in Case 2, when the B-terminal is found busy (c.f. Connector 2 in Figs. 7 and 9). This is the case of call holding – the A-user is put to wait (virtual devices 'carried holding' (*ch*) and 'abandoned holding' (*ah*)). In pure voice communication systems, in this case, a pre-recorded music/message is usually played to the caller while waiting. The connection is not terminated but no verbal communi‐ cation is possible. At the same time the B-user is notified (by a sound and/or light indi‐ cation on his/her terminal/phone) that another call is trying to reach him/her, with the options of answering (virtual devices 'carried holding' (*ch*)) or not answering it (virtual device 'abandoned holding' (*ah*)). During the hold time, the B-user is able to continue with or answer another call, retrieve a waiting call, etc. Note that in this case, traffic loads on the A- and B-terminals are considerably different.

**Fig. 10.** Service stages 'Mailing', 'Communication', and 'B-terminal Load' (Case 3).

Figure 10 presents the call flows, in Case 3, when the B-terminal is found busy (c.f. Connector 3 in Figs. 7 and 10). This is the case when the A-user is redirected to a mail service to leave an audio message. In some systems, there is also a possibility to leave a video message, e.g. a visual voicemail. The A-user receives an invitation to leave a mail message (virtual device 'enter mailing' (*em*)) and may decide to use this service (virtual device 'carried mailing' (*cm*)) or to abandon the service (virtual device 'aban‐ doned mailing' (*am*)). The message is retrieved (later) by the B-user either as audio directly from his/her terminal/phone or from another device via a web link supplied by an email message, or as a text by utilizing a voicemail-to-text functionality. This message retrieval is reflected by the case of using the B-terminal by the B-user in our conceptual model.

**Parameters' Qualification.** In Fig. 7, one may see notations '*Fa*', '*dem*.*Fa*', and '*rep*.*Fa*', using qualifiers *dem* and *rep*. Traffic qualification is necessary and it is used in [11], but without any attempt for including the qualifiers in the parameters' names. The problem is more complex: (1) one would like to have the same, or very similar, param‐ eters' names in the conceptual-, analytic-, and computer models; (2) one would like to meet the Name Design Criteria: "Names with which human beings deal directly should be user-friendly. A user-friendly name is one that takes the human user's point of view, not the computer's. It is one that is easy for people to deduce, remember and understand, rather than one that is easy for computers to interpret." [20], Annex J: "Name Design Criteria".

Since 2006 [6] we use up to two qualifiers as a part of the parameter's name. The first is for the parameter value's origin, e.g. *emp* for 'empirical', *dsn* for 'designed', *trg* for 'target', etc. The second qualifier characterizes the traffic. Most of the traffic qualifiers are described in [11]. In this paper we use *dem* for 'demand', *rep* for 'repeated', *ofr* for 'offered', and *crr* for 'carried'. We expand the meaning of the traffic qualifiers to the other parameters determining the traffic, e.g. in our notations, *ofr*.*Ys* = *ofr*.*Fssrv*.*Ts* means: 'the offered traffic intensity to the switching system is a product of the offered requests' frequency (rate) and the service time in the switching system.

The definition of the offered traffic needs more explanations. There are two offered traffic definitions in the ITU-T recommendations: (1) Equivalent Traffic Offered [21]; and (2) Traffic Offered [11]. In the other standardization documents, there is only one offered traffic definition, close to the Equivalent Traffic Offered [21]. In the overall network performance models, both definitions give considerably different values [22]. In this chapter, we use only the definition of the Equivalent Traffic Offered [21].

#### **2.3 QoS Prediction Task Formulation**

We consider the conceptual model presented in Figs. 6, 7, 8, 9, 10 and described in Sect. 2.2. In this chapter, we consider that the overall telecommunication system provides four services: (1) finding B-terminal; (2) connection to B-terminal; (3) finding B-user (with sound, vibration, message, etc.); and (4) transmission and/or record of messages. The quality of this services depends on many subsystems (c.f. Fig. 1), including the user- and network behavior.

*Types of Parameters.* There are two types of parameters – static and dynamic. The 10 basic dynamic parameters (with values dependent of the system state) are: *Fo*, *Yab*, *Fa*, *dem*.*Fa*, *rep*.*Fa*, *Pbs*, *Pbr*, *ofr*.*Fs*, *Ts*, and *ofr*.*Ys*. All others dynamic parameters can be obtained from these.

Note that the traffic *Yab* from all terminals is accepted as a system macro-state parameter.

*Input Parameters.* These are mostly static, i.e. related to the network technical char‐ acteristics or the user behavior. We choose one dynamic parameter - *Fo* (the intent intensity of calls of one idle terminal) as an independent input variable. The proposed analytical model allows to find all dynamic values, if *Fo* and all static parameters are known.

The probability of finding the B-user is considered static (i.e. independent of the system state).

The basic *QoS output parameters* are:

These two parameters allow determination of many other QoS indicators, related to traffic-, time-, and flow characteristics of users and terminals.

The goal of this section is to find analytically all unknown basic dynamic parameters, including the basic QoS output parameters.

## **2.4 Main Assumptions**

For a clear analytical modeling of a telecommunication system with QoS guarantees, the following assumptions were made:

**Assumption 1.** A closed service system, presented in Figs. 6, 7, 8, 9 and 10, is considered;

**Assumption 2** (Capacity of Devices). The switching system (*s*) has capacity of *Ns* connections (every virtual internal switching line may carry only one call attempt). Complex devices have limited capacity: the capacity of the *ab* device is *Nab* ∈ [2, ∞) terminals; the capacity of every terminal is engaging in one call (incoming or outgoing); all basic virtual devices have unlimited capacity;

**Assumption 3** (Occupation of A-terminals). Every incoming call attempt (*Fa*), from the environment, falls only on a free A-terminal. This terminal becomes a busy one;

**Assumption 4** (Steady State). Every device is in a stationary state. Hence the Little's theorem [23] is applicable to each device: *Y* = *F T*;

**Assumption 5** (Capacity of Call Attempts). Every call attempt may occupy no more than one place, if any, in each basic virtual device;

**Assumption 6** (Network Environment). The calls and devices in the environment (outside blocks *a* and *b* in Figs. 7, 8, 9 and 10) form the intent- and repeated calls flows). They don't create telecommunication network's load;

**Assumption 7** (Device Independence). Excluding the dependences described in the mathematical model, all parameters of a virtual device are independent from the param‐ eters' values of any other virtual device in the model;

**Assumption 8** (Randomness of the Processes). All variables in the analytical model are considered random with a fixed distribution; the Little's theorem is used for working with their mean values.

**Assumption 9** (A and B Simultaneity). If a call attempt is served in corresponding virtual devices belonging to A- and B-terminal's load (e.g. *ar*, *cr*, *ac*, *c1*, *cc2*, *cm* in Figs. 7, 8, 9 and 10), it seizes and releases them simultaneously, with the same service load and duration.

**Assumption 10** (Virtual Channel Switching). Every call attempt occupies simulta‐ neously places in all the basic virtual devices of the complex device *a* or *b* it is passing through, including the basic device where it is at the moment of observation. Every call attempt releases all occupied places at the very moment it leaves the complex device *a* or *b*.

**Assumption 11** (Homogeneity4). All terminals and users are homogeneous.

**Assumption 12** (Self-Excluding). Every A-terminal directs, with uniform distribution, all its call attempts to other terminals, not to itself;

**Assumption 13** (B-flow). The flow of call attempts, occupying B-terminals (*Fb*), is ordinary. (The case when two or more call attempts reach simultaneously a free Bterminal is not considered, due to its statistical unimportance);

**Assumption 14** (B-terminal Busy Probability). The stationary probability of a call to find the intended B-terminal busy ('blocked ringing' (*Pbr*)) during the first (primary, demand) attempt and all subsequent (repeated) attempts is one and the same.

## **3 Analytical Model**

## **3.1 Overall Input Flow Intensity**

The input (incoming) flow to the telecommunication network, with intensity *Fa*, is the flow generated by (and occupying) A-terminals. From the ITU E.600 definitions and Fig. 7 it is obvious that the intensity of incoming flow is a sum of the intensities of primary (demand) call attempts (*dem*.*Fa*) and repeated attempts (*rep*.*Fa*):

$$Fa = dem.Fa + rep.\\ Fa. \tag{6}$$

From the definition of the BBP-flow and Fig. 7 we have:

$$=dem.Fa = Fo(Nbb + M\text{ }Yab) \tag{7}$$

4 *Homogeneity* means that all relevant characteristics and their considered mean values are the same.

#### **3.2 QoS Indicator 1: Carried Switching Efficiency**

According to Definition 2.11 in [11]: "fully routed call attempt; successful call attempt" is "A successful call attempt that receives an answer signal". We define the Carried Switching Efficiency of the 'Finding B-Terminal' service as a ratio of the flow intensity of the calls reaching the intended B-terminal (*Fcs*) and receiving an answer signal 'busy tone' or 'ringing tone', to the incoming call attempts intensity (*Fa*).

The Carried Switching Efficiency corresponds to the concept of "answer bid ratio (ABR)" in [11]: "On a route or a destination code basis and during a specified time interval, the ratio of the number of bids that result in an answer signal, to the total number of bids."

In the conceptual model considered (c.f. Fig. 7), the calls served in the device 'carried switching' (*Fcs*) are those, reaching the B-terminals. The intensity *Fcs* may be calculated by taking into account *Fa* and losses on the way to the *cs* device (c.f. Fig. 7). This, expressed in two ways – by using the lost call flows and probabilities of successful moving of requests along the successful branch, results in the following: *a*

$$Fcs = Fa\left(1 - Rad\right)\left(1 - Pid\right)\left(1 - Pbs\right)\left(1 - Pis\right)\left(1 - Pns\right). \tag{8}$$

So, the Carried Switching Efficiency (*Ecs*) of the 'Finding B-Terminal' service is:

$$Ecs = \frac{Fcs}{Fa} = (1 - Rad)(1 - Pid)(1 - Pbs)(1 - Pis)(1 - Pns). \tag{9}$$

#### **3.3 Repeated Calls Flow**

Based on the repeated calls definition [21] and the proposed conceptual model (Figs. 7, 8, 9 and 10), the intensity of the repeated attempts (*rep*.*Fa*) is:

$$\text{Prop.}Fa = Frad + Fid + Frbs + Frs + Frss + Frbr + Fr1 + Fr2 + Fr3,\tag{10}$$

where *Fr*1 = *Frar* + *Frac* + *Frcc*1 is the intensity of repeated attempts in Case 1, directed to Connector 4 (c.f. Fig. 8); *Fr*2 = *Frah* + *Frac* + *Frcc*2 is the intensity of repeated attempts in Case 2, directed to Connector 4 (c.f. Fig. 9.); *Fr*3 = *Fram* + *Frcm* is the intensity of repeated attempts in Case 3, directed to Connector 4 (c.f. Fig. 10).

**Proposition 1.** The intensity of the repeated attempts *rep*.*Fa* may be obtained as:

$$\begin{split}prep.Fa &= Fa(Pud \ Prad + (1 - Pud)(Pid \ Prid + (1 - Pid)(Pbs \ Prbs \\ &+ (1 - Pbs)(Pis \ Pris + (1 - Pis)(Pns \ Prms + (1 - Pns)Pbr(Ph \ Pr2 \\ &+ (1 - Ph)(Pm \ Pr3 + (1 - Pm)(Pbr)) + (1 - Pbr)Pr1)))), \\ \end{split} \tag{11}$$

where *Ph* ('holding') is the probability of calls going to Case 2 (c.f. Connector 2 in Fig. 7), *Pm* ('mailing') is the probability of calls going to Case 3 (c.f. Connector 3 in Fig. 7), and:

$$Pr1 = Ecs \left( Pah \, Prah + (1 - Pah) \left( Pac \, Prac + (1 - Pac) \, Prcc \, 1 \right) \right);\tag{12}$$

$$Pr2 = Ecs\ Pbr\ Ph\ (1 - Par)\ (Pah\ Prah + (1 - Pah)(Pac\ Prac + (1 - Pac)Prcc2));\tag{13}$$

$$Pr\mathfrak{F} = Ecs\ Pbr\ (1 - Ph)\ P m\ (Pam\ Pram\ + (1 - Pam)Prcm). \tag{14}$$

**Proof:** As can be seen from Figs. 7, 8, 9 and 10, Assumption 1, and (10), *rep*.*Fa* is a sum of intensities of repeated attempt flows, in all branches. The intensities of repeated attempt flows, in all branches, may be easily expressed as functions of *Fa*, following the conceptual model structure depicted in Figs. 7, 8, 9 and 10:

$$Frad = Fa\ Pad\ Prad;\tag{15}$$

$$Frid = Fa\,\,(1 - Rad)\,\,Pid\,\,Prid;\,\tag{16}$$

$$Frbs = Fa\,(1 - pad)(1 - Pid)\, Pbs\, Prbs;\tag{17}$$

$$F \text{ris} = Fa \ (1 - pad)(1 - Pid)(1 - Pbs) \\ P \text{is} \ Pr \text{is}; \tag{18}$$

$$Fms = Fa\,\,(1 - pad)(1 - Pid)(1 - Pbs)(1 - Pis)Pns\,Pms;\tag{19}$$

$$Fbrr = Fa\,(1 - Rad)(1 - Pid)(1 - Pbs)(1 - Pis)(1 - Pns)Pbr\,Prbr;\tag{20}$$

$$\begin{split} Fr1 &= Fa \left( 1 - pad \right) (1 - Pid) (1 - Pbs) (1 - Pis) (1 - Pns) (1 - Pbr) \left( Pah \Pr{hh} \\ &+ (1 - Pah) (Pac \Pr{cac} + (1 - Pac) Prcc 1) \right) = Fa \Pr{1}; \end{split} \tag{21}$$

$$\begin{aligned} Fr2 &= Fa \left(1 - Rad(1 - Pid)(1 - Pbs)(1 - Ps)(1 - Pns)Pbr \; Ph \; (1 - Par) \\ &\quad (Pah \; Pah + (1 - Pah)(Pac \; Paac + (1 - Pac)Prcc 2)) = Fa \; Pr2; \end{aligned} \tag{22}$$

$$\begin{aligned} Fr3 &= Fa \ (1 - pad)(1 - Pid)(1 - Pbs)(1 - Pis)(1 - Pns)Pbr(1 - Ph)Pm \\ &\quad (Pam \ Pam) + (1 - Pam)Prmm) = Fa \ Pr3. \end{aligned} \tag{23}$$

By adding Eqs. (15) to (23) and taking into account (10), we obtain (11).

**Proposition 2.** By distinguishing static and dynamic parameters in (11), and after some algebraic operations, we obtain *rep*.*Fa* as a simple function of *Fa*, *Pbr*, and *Pbs*:

$$\text{Lrep.}Fa = Fa \ (R1 + R2 \ Pbr \ (1 - Pbs) + R3 \ Pbs), \tag{24}$$

where:

$$\begin{aligned} R1 &= Rad \, Prad + (1 - pad)(Pid \, Prid + (1 - Pid) \, Pis \, Pris \\ &+ (1 - Pis)(Pns \, Pns + (1 - Pns) \, Pr1); \end{aligned} \tag{25}$$

$$\begin{split} R2 &= (1 - Pad)(1 - Pid)(1 - Pis)(1 - Pns)(PhPr2 + (1 - Ph)(PmPr3 \\ &+ \ (1 - Pm)Prbr) - Pr1); \end{split} \tag{26}$$

$$R3 = (1 - pad)(1 - Pid)(Prbs - (Pis \ Pris + (1 - Pis)(Pns \ Prns + (1 - Pns)Pr1))).\tag{27}$$

#### **3.4 QoS Indicator 2: B-Terminal Connection Efficiency**

Definition 2.10. in [11] describes "completed call attempt; effective call attempt" as "A call attempt that receives intelligible information about the state of the called user".

Based on this, we define the B-Terminal Connection Efficiency as a ratio of the flow intensity of the calls occupying the intended B-terminal (*Fb*) to the incoming call attempts' intensity (*Fa*).

In the considered conceptual model, the calls occupying the B-terminal receive infor‐ mation about the state of the called B-user such as signals 'ringing tone' (Case 1 in Fig. 8), 'holding signal' (Case 2 in Fig. 9), or 'invitation to mailing' signal (Case 3 in Fig. 10). The A-user may accept (devices *cr*, *ch*, *cm*) or reject (devices *ar*, *ah*, *am*) the offers.

#### **3.5 B-Terminals' Characteristics**

The intensity of the input flow occupying all B-terminals (*Fb*) is a sum of the following intensities of input flows (to B-terminals): *Fb*1, in Case 1 - Ringing stage (generated in the copy device in Fig. 8); *Fb*2, in Case 2 - Communication stage (generated in the copy device in Fig. 9); and *Fb*3, in Case 3 - Communication stage (generated in the copy device in Fig. 10), or:

$$Fb = Fb1 + Fb2 + Fb3. \tag{28}$$

The flow intensities *Fb*1, *Fb*2 and *Fb*3 can be calculated by considering the intensity of the carried switching flow *Fcs*. From Figs. 7, 8, 9 and 10, we obtain directly:

$$Fb1 = Fcs\,(1 - Pbr)\tag{29}$$

$$Fb2 = Fcs \, Pbr \, Ph \, (1 - Pah) \tag{30}$$

$$Fb\Im = Fcs\Pr\left(1 - Ph\right)\Pr\left(1 - Am\right)\tag{31}$$

After summation, we obtain *Fb* as:

$$\begin{aligned} Fb &= Ecs\,Fa\left((1 - Pbr) + Pbr\left(Ph\left(1 - Pah\right)\right) \\ &+ \left(1 - Ph\right)Pm\left(1 - Pam\right)\right) = Eb\,Fa \end{aligned} \tag{32}$$

where *Fb* is the B-Terminal Connection Efficiency, or shortly 'B-Efficiency'. B-Efficiency (*Eb*) is expressed as a ratio of flow intensity, occupying B-terminals (*Fb*), to the intensity of the incoming flow (*Fa*). It is considerably different from the Carried Switching Efficiency (*Ecs*):

$$Eb = \frac{Fb}{Fa} = Ecs((1 - Pbr) + Pbr(Ph(1 - Pah) + (1 - Ph)Pm(1 - Pam))).\tag{33}$$

#### **Flow of Call Attempts, Occupying all B-Terminals**

Traffic intensity to B-terminals (*Yb*) is a sum of traffic intensities (to them) in cases 1, 2, and 3. From Figs. 8, 9 and 10 and the Little's theorem, we can obtain directly the following:

$$Yb = Yb1 + Yb2 + Yb3,\tag{34}$$

where

$$Yb1 = Yar + Ycr + Yac + Ycc1 = Fb1 \quad Tb1. \tag{35}$$

$$Yb2 = Yac + Ycc2 = Fb2 \text{ } Tb2. \tag{36}$$

$$Yb3 = Ycm = Fb\ \Im \, Tb3.\tag{37}$$

and

$$Tb1 = Par\ Tar + (1 - Par)(Tcr + Pack\ Tac + (1 - Par)Tcc1) \tag{38}$$

$$Tb2 = \text{Pac } \text{Tac} + (1 - \text{Pac}) \, \text{Tcc} \, \mathcal{D} \tag{39}$$

$$Tb\,\mathfrak{J} = Cm\,\tag{40}$$

**Proposition 3.** Traffic intensity to B-terminals (*Yb*) may be calculated from the equa‐ tion:

$$\begin{aligned} \label{eq:SDL-1} &Ib = Ecs\,Fa\left((1-Pbr)\,Tb1 + Pbr\left(Ph\left(1-Pah\right)\,Tb2\right)\right) \\ &+ \ (1-Ph)\,Pm\,\left(1-Pam\right)\,Tb3\right), \end{aligned} \tag{41}$$

where *Tb* is the mean holding time of calls in B-terminals and *Fb* is the intensity of call attempts that occupy B-terminals.

**Proof:** After summation of *Yb*1, *Yb*2 and *Yb*3, and taking into account expressions (2.8)– (2.10), we obtain:

$$Yb = Fcs\left(\left(1 - Pbr\right)Tb1 + Pbr\left(Ph\left(1 - Pah\right)Tb2 + \left(1 - Ph\right)Pm\left[Pb\,\,\mathrm{Tb}\right)\right)\right)$$

and after replacing *Fcs* with *Ecs Fa* from (9) we get (41).

**Proposition 4.** The mean holding time of all B-terminals (*Tb*), in accordance with cases 1, 2, 3, is:

$$Tb = \frac{Yb}{Fb} = \frac{(1 - Pbr)Tb1 + Pbr(Ph(1 - Pah)Tb2 + (1 - Ph)Pm(1 - Pam)Tb3)}{(1 - Pbr) + Pbr(Ph(1 - Pah) + (1 - Ph)Pm(1 - Pam))}.\tag{42}$$

**Proof:** This follows directly from the formulas for *Yb* and *Fb*, and by directly applying the Littlle's theorem.

**Consequence:** Traffic intensity of B-terminals (*Yb*) is:

$$\mathbf{Yb} = \mathbf{Fb} \ \mathbf{Tb} = \mathbf{Fa} \ \mathbf{Eb} \ \mathbf{Tb}. \tag{43}$$

#### **3.6 A-Terminals' Characteristics**

In this subsection, analytical expressions characterizing all A-terminals (traffic intensity (*Ya*), intensity of occupation flow (*Fa*), holding time (*Ta*)) are obtained, as functions of known variables.

**Proposition 5.** A-terminals' traffic intensity (*Ya*) is:

$$Ya = Ya0 + Ya1 + Ya2 + Ya3 = Fa\,Ta,\tag{44}$$

where

$$Ya0 = Ycd + Yad + Yid + Ycd + Ybs + Yis + Yns + Ycs \tag{45}$$

$$Ya1 \,\,=\,\,Yb1,\,\,\tag{46}$$

$$Ya2 = Yah + Ych + Yb2,\tag{47}$$

$$Ya\mathfrak{Z} = Yem + Yam + Yb\mathfrak{Z}.\tag{48}$$

**Proof:** Based on the proposed conceptual model and Figs. 7, 8, 9 and 10, and by applying the Little's theorem, we can obtain the traffic intensity for each virtual device, in *a*0 (*Ya*0), *a* 1 (*Ya*1), *a* 2 (*Ya*2), and *a*3 (*Ya*3) blocks, of stages Dialing (*Yed*, *Yad*, *Yid*, *Ycd*), Switching (*Ybs*, *Yis*, *Yns*, *Ycs*), Holding (*Yah*, *Ych*), and Mailing (*Yem*, *Yam*), and by using the found traffic intensities of B-terminals (*Yb*1, *Yb*2, *Yb*3).

After summation, we obtain the following:

$$\begin{aligned} \text{Ya} &= \text{FaTa} = \text{Fa} \left( \text{Ted} + \text{Pad} \, \text{Tad} + (1 - \text{Pad}) (\text{Pid} \, \text{Tid} + (1 - \text{Pid}) (\text{Tcd} + \text{Pbs} \, \text{Tbs} \\ &+ (1 - \text{Pbs}) (\text{Pas} \, \text{Tis} + (1 - \text{Pis}) (\text{Pas} \, \text{Tas} + (1 - \text{Pas}) (\text{Tcs} + (1 - \text{Pbr}) \, \text{Tb} \, 1 + \text{Pbr} \, \text{Tb} \, \text{T} + \text{Pbr} \, \text{Tbr} \\ &+ \text{Ph} \, (\text{Pah} \, \text{Tal} + (1 - \text{Pah}) (\text{Tcb} + \text{Tb} \, \text{2}) \\ &+ (1 - \text{Ph}) \, \text{Pm} \, (\text{Tcm} + \text{Pam} \, \text{Tam} + (1 - \text{Pam}) (\text{Tb} \, \text{3}))))))))))))))))))) \end{} \end{aligned} \end{aligned} \tag{49}$$

**Proposition 6.** By distinguishing static and dynamic parameters, the mean holding time *Ta* of A-terminals is:

$$\begin{split} Ta &= S1 - S2(1 - Pbs)Pbr - S3 \; Pbs - Ecs \; (Tb1 + Pbr \; (-Tb1 \\ &+ \; Ph \; (1 - Pah) \; Tb2 + (1 - Ph) \; Pm \; (1 - Pam) \; Tb3)), \\ \end{split} \tag{50}$$

where *S*1, *S*2, and *S*3 are generalized static parameters:

$$\begin{aligned} S1 &= Tcd + Pad \, Tad + (1 - Pad)(Pid \, Tid + (1 - Pid)(Tcd + Pis \, Tis \\ &+ (1 - Pis)(Pns \, Tns + (1 - Pns)(Tcs + 2Tb1)))). \end{aligned} \tag{51}$$

$$\begin{split} S2 &= (1 - P a d)(1 - P d)(1 - P i)(1 - P n)(2Tb1 - T b r - P h (P a h \,\mathrm{T a h} \,\mathrm{T} \,\mathrm{T} \,\mathrm{T} \,\mathrm{T} \,\mathrm{T} \,\mathrm{T} \,\mathrm{T} \,\mathrm{T})) \\ &+ (1 - P a h)(T c h + 2Tb2)) - (1 - P h) P m (T e m + P a m \,\mathrm{T} \,\mathrm{m} + (1 - P a m) 2Tb3)) \end{split} \tag{52}$$

$$\text{S.S.} = (1 - P\text{ad})(1 - P\text{id})(\text{Pis}\,T\text{is} - T\text{bs} + (1 - P\text{is})(\text{Pns}\,T\text{ns} + (1 - P\text{ns})(\text{Tcs} + 2T\text{b1})))\tag{53}$$

**Proof:** Based on (49) in Proposition 5, obviously:

$$\begin{aligned} Ta &= \textit{Ted} + \textit{Pad} \, \textit{Tad} + (1 - \textit{Pad}) (\textit{Pid} \, \textit{Tid} + (1 - \textit{Pid}) (\textit{Tcd} + \textit{Pbs} \, \textit{Tbs} + (1 - \textit{Pbs}) (\textit{Pis} \, \textit{Tids} + \textit{Pas} \, \textit{Tals})) \\ &+ (1 - \textit{Pis}) (\textit{Pas} \, \textit{Tas} + (1 - \textit{Pas}) (\textit{Tcs} + (1 - \textit{Pbr}) \, \textit{Tbl} + \textit{Pbr} \, (\textit{Tbr} + \textit{Pbr} \, (\textit{Pah} \, \textit{Tah} \\ &+ (1 - \textit{Pah}) (\textit{Tcb} + \textit{Tb} \, \boldsymbol{2}) + (1 - \textit{Pb}) \textit{Pan} \, (\textit{Tam} + \textit{Pam} \, \textit{Tam} + (1 - \textit{Pam}) \, \textit{Tb} \, \boldsymbol{3}))))))))))) \end{)} \end{aligned} \tag{54}$$

After simple mathematical transformations we obtain (50).

#### **3.7 QoS Indicator 3: Overall Call Attempt Efficiency**

Definition 2.12 in [11] describes "successful call" as "A call that has reached the wanted number and allows the conversation to proceed". Note that 'call' is "A generic term related to the establishment, utilization and release of a connection. Normally a qualifier is necessary to make clear the aspect being considered, e.g. call attempt." [11]. A 'call attempt' is "An attempt to achieve a connection to one or more devices attached to a telecommunications network." Therefore, a call may content several call attempts.

Based on this, we define the Overall Call Attempt Efficiency (*Ec*), of a communica‐ tion service, as a ratio of the flow intensity (*Fc*) of the calls attempts with a fully and successfully finished communication, to the incoming call attempts' intensity (*Fa*).

In the considered conceptual model, *Fc* is a sum of flow intensities of virtual devices *cc*1 (Case 1 in Fig. 8), *cc*2 (Case 2 in Fig. 9), and *cm* (Case 3 in Fig. 10):

$$Fc = Fc1 + Fc2 + Fcn.\tag{55}$$

Then the Overall Call Attempt Efficiency (*Ec*) is:

$$\begin{split} Ec = \frac{Fc}{Fa} = Ecs\left( (1 - Pbr)\left(1 - Par\right)\left(1 - Par\right) + Pbr\left(Ph\left(1 - Pah\right)\left(1 - Par\right) \right) \right. \\ &+ \left. \left(1 - Ph\right)Pm\left(1 - Par\right) \right) \end{split} \tag{56}$$

#### **3.8 Network Generalized Subservice Indicators**

The Overall Call Attempt Efficiency (*Ec*) obviously includes the described indicators Carried Switching Efficiency (*Ecs*) and B-Terminal Connection Efficiency (*Eb*). From users' and service providers' point of view, it is important to distinguish the efficiency of the subservices of the telecommunication system. Such subservices include: switching (finding B-terminal), connection to B-terminal, finding B-user, transmission of messages (communication). Here we introduce specific QoS indicators for each of these subservices, as parts of the Overall Call Attempt Efficiency (*Ec*).

As a QoS-specific indicator of the switching subservice (finding B-terminal), the Carried Switching Efficiency (*Ecs*), proposed in (9), could be used, i.e. as the ratio of the flow intensity of the calls reaching the intended B-terminal (*Fcs*) and receiving either a 'busy tone' or a 'ringing tone' signal, to the incoming call attempt intensity (*Fa*):

$$Ecs = \frac{Fcs}{Fa}.\tag{57}$$

**Definition 1.** A QoS-specific indicator (*Qb*) of the subservice 'Connection to Bterminal' is the ratio of the intensity of the flow seizing B-terminals (*Fb*) to the flow intensity of all calls reaching the intended B-terminal (*Fcs*):

$$Qb = \frac{Fb}{Fcs}.\tag{58}$$

**Definition 2.** A QoS-specific indicator (*Qu*) of the subservice 'Finding B-user' is the ratio of the intensity of the flow seizing B-users (*Fu*) to the intensity of the flow seizing B-terminals (*Fb*):

$$
\mathcal{Q}u = \frac{Fu}{Fb}.\tag{59}
$$

The intensity of the flow seizing B-users (*Fu*) is a sum of intensities of the flows: after ringing *Fb*1 − (*Far* + *Fcr*) in Case 1 (c.f. Fig. 8); after holding *Fb*2 in Case 2 (c.f. Fig. 9.); and of the carried mailing *Fb*3:

$$F\mu = Fb1 - Far - Fcr + Fb2 + Fb3. \tag{60}$$

**Definition 3.** A QoS-specific indicator (*Qc*) of the communication subservice is the ratio of the flow intensity of call attempts with fully successfully finished communication (*Fc*) to the intensity of the flow seizing B-users (*Fu*):

$$Qc = \frac{Fc}{Fu}.\tag{61}$$

The proposed specific QoS indicators of telecommunication subservices are aggre‐ gated because: they aggregate many call attempts from many users and terminals (they are stochastic); some of them comprise several parallel services, e.g. *Qc* includes three successful cases – normal interactive communication, communication after call holding, and mailing.

Considering the Overall Call Attempt Efficiency (*Ec*) as a composition of the four considered subservices, one may find that the quality metric is multiplicative:

$$Ec = \frac{Fc}{Fa} = \frac{Fcs}{Fa} \left. \frac{Fb}{Fcs} \right. \frac{Fu}{Fb} \left. \frac{Fc}{Fu} \right. = Ecs \left. Qb \right. \mathcal{Q}u \left. \mathcal{Q}c. \tag{62}$$

This result allows more specific QoS analysis and more adequate QoS management.

#### **3.9 AB-Terminals' Characteristics**

In this subsection, analytical expressions of characteristics of AB-terminals (all occupied calling terminals (A) and called terminals (B)) – i.e. traffic intensity (*Yab*), intensity of occupation flow (*Fab*), and holding time (*Tab*) – are obtained as functions of known variables.

From the assumptions made and the conceptual model proposed in Subsect. 2.2, it is clear that the intensity of the call flows occupying all terminals (*Fab*) is a sum of intensities of the call flows occupying A-terminals (*Fa*) and the call flows occupying Bterminals (*Fb*):

$$Fab = Fa + Fb.\tag{63}$$

The traffic intensity of all terminals (*Yab*) is a sum of traffic intensity of the A- (*Ya*) and B-terminals (*Yb*):

$$Yab = Ya + Yb.\tag{64}$$

**Proposition 7.** The call flows intensity occupying all terminals (*Fab*) can be obtained by the following equation:

$$\begin{split} Fab &= Fa\,\,(1 + Ecs((1 - Pbr) + Pbr)Ph\,\,(1 - Pah) \\ &\quad + \,(1 - Ph)Pm\,\,(1 - Pam)))) = Fa\,\,(1 + Eb), \end{split} \tag{65}$$

where *Ecs* is the Carried Switching Efficiency (9) and *Eb* is the B-efficiency (33).

**Proof:** It can be easily seen that (65) follows directly from (33) and (63).

**Proposition 8.** The traffic intensity of all terminals (*Yab*) can be presented by the following expression:

$$Yab = Fa\ (Ta + Eb\ Tb). \tag{66}$$

**Proof:** (66) follows directly from (43), i.e.:

$$Yab = Ya + Yb = FaTa + Fb \\ Tb = FaTa + FaEb \; Tb = Fa(Ta + Eb \; Tb). \tag{67}$$

**Terminal Traffic Limitations.** Since the number of terminals is limited to *Nab* (Assumption 2), and there is no negative occupancy, the following terminal traffic limi‐ tations obviously apply in the studied system:

$$0 \le Yab \le Nb.\tag{68}$$

**Proposition 9.** Traffic of all simultaneously busy terminals (*Yab*), after separation of static parameters from dynamic parameters, may be expressed from Eqs. (50) and (66) as:

$$Yab = Fa\left(S1 - S2\left(1 - Pbs\right)Pbr - S3\left(Pbs\right),\tag{69}\right)$$

where *S*1, *S*2, and *S*3 are generalized static parameters as per (51), (52), and (53).

**Proof:** Based on (64), (49) and (41) we obtain:

$$\begin{aligned} \text{Yab} &= \text{Fa} \left( \text{Ted} + \text{Pad} \, \text{Tad} + (1 - \text{Pad}) (\text{Pid} \, \text{Tid} + (1 - \text{Pid}) (\text{Tcd} + \text{Pbs} \, \text{Tbs} \\ &+ (1 - \text{Pbs}) (\text{Pis} \, \text{Tis} + (1 - \text{Pis}) (\text{Pas} \, \text{Tas} + (1 - \text{Pas}) (\text{Tcs} + (1 - \text{Pbr}) \, 2 \, \text{Tb} \, 1 + \text{Pbr} (\text{Tbr} \, \text{Tbr} \\ &+ \text{Pb} \, (\text{Pah} \, \text{Tal} + (1 - \text{Pah}) (\text{Tcb} + 2 \, \text{Tb} \, 2) \\ &+ (1 - \text{Pb}) \, \text{Pm} \, (\text{Pam} \, \text{Tam} + (1 - \text{Pam}) (2 \, \text{Tb} \, 3)))))))))))))))))))) \end{} \end{b} \, \text{T} \, \text{T} \, \text{B} \, \text{T} \, \text{B} \end{aligned} \tag{70}$$

After algebraic transformation and taking into account (51), (52), and (53), we obtain (69).

**Proposition 10.** The mean occupation time (*Tab*) of all simultaneously busy terminals can be obtained from (70) as a function of *Ta*, *Tb*, and *Eb*.

**Proof:** From the obvious formula *Yab* = *Fab Tab*, after replacing *Yab* with (66), *Fab* with (63), and *Fb* with (32), we have:

$$Tab = \frac{Yab}{Fab} = \frac{Ya + Yb}{Fa + Fb} = \frac{Fa \ Ta + Fb \ Tb}{Fa + Fb} = \frac{Fa \ Ta + Fa \ Eb \ Tb}{Fa + Fa \ Eb} = \frac{Ta + Eb \ Tb}{1 + Eb}.$$

**Proposition 11.** The mean occupation time (*Tab*) of all simultaneously busy terminals can be obtained from (71) as a function of *S*1, *S*2, *S*3, *Pbr*, *Pbs*, and *Eb*.

**Proof:** From the formula *Yab* = *Fab Tab*, and after replacing *Yab* with (69) and *Fab* with (65), we obtain:

$$Tab = \frac{Yab}{Fab} = \frac{S1 - S2\ (1 - Pbs)\ Pbr - S3\ Pbs}{1 + Eb}.\tag{71}$$

#### **3.10 Offered Traffic to the Switching System**

Following the definition of equivalent traffic offered to the switching system, traffic (*ofr*.*Ys*) depends on the offered flow intensity (*ofr*.*Fs*) and the occupation (service) time *Ts* of an equivalent switching line:

$$
\rho\_l \rho r.\mathbf{Ys} = \rho g r.\mathbf{Fs} \text{ Ts.}\tag{72}
$$

The offered flow to the switching system is the flow offered to the first Enter Switch device in Fig. 7. This device deflects calls, if there is no free line in the switching system, with probability of blocked switching (*Pbs*) to the Blocked Switching (*bs*) device, or with probability (1 − *Pbs*) of calls seizing free equivalent switching lines. So the offered flow intensity *ofr*.*Fs* is:

$$
\rho\_l r.Fs = Fa(1 - pad)(1 - Pid). \tag{73}
$$

The occupation (service) time of an equivalent switching line (*Ts*) is determined by the engaged devices of the switching system (c.f. Subsect. 2.2), namely the *s* device, represented by a box with a dotted dashed line inside the *a* 0 box in Fig. 7, and three other *a*-boxes (*a* 1 in Fig. 8, *a* 2 in Fig. 9, and *a* 3 in Fig. 10). So consequently:

$$\text{Ts} = \text{S1}z - \text{S2}z \, Pbr,\tag{74}$$

where:

$$TS1z = PisT\bar{s} + (1 - Pis)(Pns\ Tns + (1 - Pns)(Tcs + Tb1));\tag{7S}$$

$$\text{L.S2} \mathcal{Z} = \text{Tb1} - \text{Tbr} - \text{Ph} \left( \text{Pah} \,\, \text{Tah} + (1 - \text{Pah}) \left( \text{Tch} + \text{Tb2} \right) \right) \tag{7.6}$$

$$- \left( 1 - Ph \right) Pm \left( Tem + Pam \stackrel{\cdot}{\\_} Tem + (1 - Pam) Tb3 \right) \tag{76}$$

#### **Probability of Blocked Switching**

**Proposition 12.** The probability of blocked switching (*Pbs*) could be obtained from (72) as:

$$Pbs = Erl\\_b(Ns, \, ofr.Ps). \tag{77}$$

**Proof:** (77) simply expresses the usage of the Erlang-B formula for determination of the blocking probability in the switching system, on the basis of the number of equivalent internal switching lines (*Ns*) and the offered traffic *ofr*.*Ys*.

**Probability of Blocked Ringing (B-terminal Busy).** Under Assumptions 4, 12, 14, the following expressions, presenting the probability of blocked ringing (*Pbr*) as a function of the network state *Yab* (traffic of all A- and B-terminals) and the number *Nab* of all active terminals in the system, could be obtained:

$$\begin{cases} Pbr = \frac{Yab - 1}{Nbb - 1} \text{ if } 1 \le Yab \le Nbb, \\ Pbr = 0 & \text{if } 0 \le Yab < 1. \end{cases} \tag{78}$$

(78) was first proposed as part of the simple overall network teletraffic model, described in [24], and its proof was given in [25].

## **4 Results**

#### **4.1 QoS Indicator 4: Overall Traffic Efficiency Indicator**

Based on the "effective traffic" definition [11] as "The traffic corresponding only to the conversational portion of effective call attempts", we define the Overall Traffic Effi‐ ciency Indicator (*Ey*) as a ratio of the effective traffic of A-terminals (*Ycc*) to the overall traffic of the A-terminals (*Ya*):

$$E\mathbf{y} = \frac{\mathbf{Y}cc}{\mathbf{Y}a},\tag{79}$$

where

$$Ycc = Ycs + Ycc1 + Ycc2 + Ycm. \tag{80}$$

The Overall Traffic Efficiency Indicator is used for simpler models in [7]. Some authors use the name "Overall Traffic Efficiency" in other meaning, and without any definition, e.g. [26].

#### **4.2 Numerical Results**

The input data considered is typical for voice communications in the Global System for Mobile communication (GSM). For simplicity we set *M* (defined in the explanations of Fig. 7) to 0.

Figure 11 presents results (as functions of the state of the network load – the traffic of all AB-terminals *Yab*, in the theoretical interval [0, 100]) for a network with blocking probability due to insufficient resources. The number of all terminals (*Nab*) in the system is 1000 and the number of equivalent switching lines is *Ns* = 200 (i.e. 20% of *Nab*).

**Fig. 11.** The values of the main output parameters of the model of an overall network with limited capacity.

The probability of finding B-terminal busy (*Pbr*), not shown in Fig. 11, increases linearly with the network traffic load, c.f. (78), to almost 1. The numerical results demonstrate the existence of a local maximum for the probability of blocked switching *Pbs*. This is because the overall blocking probability in the network, including *Pbr* and *Pbs*, has an absolute maximum of 1, c.f. Fig. 12.

**Fig. 12.** The causal aggregated overall pie probabilities

#### **4.3 Overall Pie Parameters**

In the model considered (c.f. Figs. 7, 8, 9 and 10), there are five reasons for call attempt ending: abandoning (6 branches), interruption (1 branch), blocking (2 branches), unavailable service (1 branch), and successful communication (3 branches). By describing the effect caused by each reason, one can construct a 'causal branch' for it. The causal branch comprises all basic virtual devices involved in the call attempt ending due the considered reason, which form the corresponding causal complex virtual device with its flow-, time-, and traffic characteristics. Overall, in the model, there are 13 causal branches considered.

The three branches of successful communication have the following service times *Tp*.*cc*1, *Tp*.*cc*2, and *Tp*.*cm*:

$$T p.cc1 = Tcd + Tcd + Tcs + Tcr + Tcc1;\tag{81}$$

$$T p.cc2 = Tcd + Tcd + Tcs + Tch + Tcc2;\tag{82}$$

$$Tp.cm = Tcd + Tcd + Tcs + Tem + Tcm.\tag{83}$$

The pie flow intensities, of the three subcases of successful communication, coincide with the flow intensity of the last virtual device in the causal branch, respectively: *Fp*.*cc*1 = *Fcc*1; *Fp*.*cc*2 = *Fcc*2 and *Fp*.*cm* = *Fcm*.

The pie flow probabilities of the three branches of successful communication respec‐ tively are:

178 S. Poryazov et al.

$$Pp.cc1 = \frac{Fp.cc1}{Fa}; \; Pp.cc2 = \frac{Fp.cc2}{Fa}; \; Pp.cm = \frac{Fp.cm}{Fa}. \tag{84}$$

The pie traffic intensities of the three branches of successful communication are:

$$\text{Yp.cc1} = \frac{\text{Fp.cc1 Tp.cc1}}{\text{Ya}}; \text{ Yp.cc2} = \frac{\text{Fp.cc2 Tp.cc2}}{\text{Ya}}; \text{ Yp.ccm} = \frac{\text{Fp.cm Tp.ccm}}{\text{Ya}}.\tag{85}$$

By analogy, one may easily obtain all other overall pie probabilities, pie flows, and pie traffic intensities in the model, by using the normalized parameters found in Sect. 3.

#### **4.4 Causal Aggregated Overall Pie Parameters**

The overall causal branches may be aggregated as might be needed for telecommuni‐ cation system monitoring, design, or management. A usable aggregation is the causal aggregation of all the branches corresponding to one type of call attempts ending.

For instance, for the case of successful communication, one can express the aggre‐ gated parameters of the branches of the Aggregated Overall Successful Carried Commu‐ nication Branch, considered as a complex virtual device *p.c*. The metrics are additive because this is a pie presentation of the model.

The causal aggregated overall pie probability of a call attempt ending with successful communication (*Pp*.*c*) is:

$$Pp.c = Pp.cc1 + Pp.cc2 + Pp.cm. \tag{86}$$

By taking into account (56), the overall causal pie flow intensity of successful communication (*Fp*.*c*) respectively is:

$$Fp.c = Fp.cc1 + Fp.cc2 + Fp.cm = \frac{Fcc1 + Fcc2 + Fcm}{Fa} = \frac{Fc}{Fa} = Ec. \tag{87}$$

The overall causal pie traffic intensity of successful communication (*Yp*.*c*) is:

$$\text{Yp.c} = \text{Yp.cc1} + \text{Yp.cc2} + \text{Yp.cm.} \tag{88}$$

Similarly, one may find all other causal aggregated overall pie parameters of the model.

#### **4.5 Numerical Results for Pie Characteristics**

Figures 12 and 13 present numerical results for the causal overall pie probabilities and traffic intensities for each of the five reasons for call attempt ending (i.e. abandoning *p. a*, interrupting *p.i*, blocking *p.b*, service not available *p.n*, and successful communication *p.c*) as functions of the network traffic load.

**Fig. 13.** The causal aggregated overall pie traffic intensities

The overall pie characteristics and their causal aggregations may be considered and used as causal-oriented QoS indicators. They allow more precise estimation of the dynamic importance of each reason for call attempt ending and thus a more precise dynamic effort targeting of the QoS management.

## **5 Conclusion**

The presented modeling approach and corresponding numerical results demonstrate the big potential and importance of the overall teletraffic models of telecommunication systems with QoS guarantees.

Such models allow prediction of many overall QoS indicators as regards the flow-, time-, and traffic characteristics of the A-, B-, and AB-terminals and users, as well as of the overall network performance.

The approach makes easy the separation of an overall telecommunication service into different subservices with specific QoS indicators for each of them.

In this chapter, the newly proposed indicators are network-oriented or terminaloriented. The model, however, is suitable for the development of user-oriented indicators as well. This will be a task for future research.

Applying pie characteristics and their causal aggregations to the subservices results in causal-oriented QoS indicators. This allows a more precise estimation of the dynamic importance of each reason, in every subservice, of call attempt ending, and thus a more precise dynamic effort targeting of the QoS management. Applying a similar approach (with specific QoS indicators) for multimedia and multiservice networks seems very attractive and promising.

Another important goal could be the development of methods for using specific QoS indicators as sources for predicting QoE indicators.

**Acknowledgments.** This work was coordinated under the EU COST Action IC1304 "Autonomous Control for a Reliable Internet of Services (ACROSS)". The work was partially funded by the Bulgarian NSF Projects DCOST 01/9 (the work of S. Poryazov) and DCOST 01/20 (the work of E. Saranova).

## **References**

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

# **QoS-Based Elasticity for Service Chains in Distributed Edge Cloud Environments**

Valeria Cardellini1 , Tihana Galinac Grbac2(B) , Matteo Nardelli1 , Nikola Tankovi´c3 , and Hong-Linh Truong4

> 1 University of Rome Tor Vergata, Rome, Italy<EMAIL_ADDRESS>2 University of Rijeka, Rijeka, Croatia<EMAIL_ADDRESS>3 Juraj Dobrila University of Pula, Pula, Croatia<EMAIL_ADDRESS>4 TU Wien, Vienna, Austria<EMAIL_ADDRESS>
**Abstract.** With the emerging IoT and Cloud-based networked systems that rely heavily on virtualization technologies, elasticity becomes a dominant system engineering attribute for providing QoS-aware services to their users. Although the concept of elasticity can introduce significant QoS and cost benefits, its implementation in real systems is full of challenges. Indeed, nowadays systems are mainly distributed, built upon several layers of abstraction, and with centralized control mechanisms. In such a complex environment, controlling elasticity in a centralized manner might strongly penalize scalability. To overcome this issue, we can conveniently split the system in autonomous subsystems that implement elasticity mechanisms and run control policies in a decentralized manner. To efficiently and effectively cooperate with each other, the subsystems need to communicate among themselves to determine elasticity decisions that collectively improve the overall system performance. This new architecture calls for the development of new mechanisms and efficient policies. In this chapter, we focus on elasticity in IoT and Cloud-based systems, which can be geo-distributed also at the edge of the networks, and discuss its engineering perspectives along with various coordination mechanisms. We focus on the design choices that may affect the elasticity properties and provide an overview of some decentralized design patterns related to the coordination of elasticity decisions.

## **1 Introduction**

Elasticity is a quality attribute that is widely used in virtual environments together with the "as a service" paradigm to deal with on-demand changes. Although elasticity is multi-dimensional [27,72], in most cases, elasticity techniques just focus on offering elastic resources on demand and dynamically provision them to fluctuating workload needs based on the "pay-per-use" concept [23].

I. Ganchev et al. (Eds.): Autonomous Control for a Reliable Internet of Services, LNCS 10768, pp. 182–211, 2018. https://doi.org/10.1007/978-3-319-90415-3\_8

In this sense, elasticity mechanisms automatize the process of reconfiguring virtualized resources, mostly at infrastructural levels, at runtime with the goal of sustaining offered Quality of Service (QoS) levels and optimizing resource cost.