Examensarbetet genomfördes tillsammans med företaget Rol Ergo. Syftet med studien var att analysera Zigbee 3.0 och Bluetooth Low Energy 5.2 och deras lämplighet i tidskritiska system genom att studera latensen och förhållandet mellan signalstyrkan och avståndet mellan de två kommunikationsprodukter. Datainsamlingen genomfördes med en experimentell studie och utifrån kunskap som framskaffats har ett visst antal bestämda experiment utförts för att svara på frågeställningarna som ställs.  Datainsamlingen visar att både maxlatensen och typiska latensen hos Zigbee är lägre än maxlatens och typiska latens för Bluetooth Low Energy. Datainsamlingen för signalstyrkan visar att Bluetooth Low Energys signalstyrka blir mer påverkad av avståndet mellan kommunikationsprodukterna än vad Zigbees blir. Det visar även att den optimala förhållande mellan signalstyrkan och avståndet hos Zigbee är bättre än hos Bluetooth Low Energy.  Slutsatsen av arbetet är att Zigbee är mer lämpad för tidkritiska system än Bluetooth Low Energy då låg latensen prioriteras. Zigbee är även mer lämpad då lång distansen prioriteras men då bör signalstyrkan ligga runt -50dBm. Bluetooth Low Energy är dock mer lämpad då lång distans inte prioriteras och signalstyrkan inte behöver vara utmärkt för att kunna kommunicera.  Begränsningarna för arbetet är att Bluetooth Low Energy och Zigbee endast har prövats på utvecklingskortet nRF5340 DK.  På grund av den begränsade tiden så har endast ett antal bestämda experiment som har föreslagits av rådgivare på Rol Ergo utförts. / The thesis has been conducted together with  Rol Ergo company. The purpose of this study is to analyse Zigbee 3.0 and Bluetooth Low Energy 5.2 and their suitability for time-critical systems, by studying latency and the relations between signal strength and distance between two communication products. The data collection was completed by an experimental study. By using knowledge that has been collected for the study, sets of experiments will be performed to answer the research questions.  Results of the collected data indicate that both the maximum latency and the typical latency for Zigbee is significantly lower than for Bluetooth Low Energy. The collected data for signal strength shows that the signal strength for Bluetooth Low Energy is more affected by distance between the communication product, than Zigbee’s is. It also shows that the optimal ratio between signal strength and distance for Zigbee is better than for Bluetooth Low Energy. The conclusion of the study shows Zigbee to be a more suitable for time-critical systems compared to Bluetooth Low Energy when low latency is being prioritized. Zigbee is also more suitable for time-critical systems when long distance is being prioritized, however the signal strength must then be around -50 dBm. Bluetooth Low Energy is more suitable when long distance is not the priority, and the signal strength does not have to be excellent to be able to communicate.  The limitations for this thesis are that Bluetooth Low Energy and Zigbee will only be tested on the nRF5349 Development Kit. given limited time, only a certain of experiments, whereas some have been suggested by advisors from Rol Ergo, has been carried out.

Message-oriented middleware (MOM) is a middleware used for communication between applications. There are many different MOM technologies available today, each offering different performance (throughput and latency). The performance of MOMs depends on both message size and message guarantee settings used. The problem is that it can be difficult for users to know which MOM they should choose given their requirements. The goal was to create a performance (latency and throughput) comparison of three popular MOMs; Apache Kafka, RabbitMQ and Nats Streaming. The result shows that Kafka is the best performing MOM for smaller message sizes (under 512 bytes). RabbitMQ has the best performance for larger message sizes (over 32768 bytes). Nats Streaming only outperformed the other message system for a few combinations of message guarantee settings with the message size 4096 bytes. / Meddelandeorienterad mellanprogramvara (MOM) är mellanprogramvara som används för kommunikation mellan applikationer. Det finns många MOM system som erbjuder olika prestanda (genomströmning och latens). Prestandan är beroende av vilka meddelandegarantier som används samt meddelande storlek. Detta gör det svårt för användare att välja MOM utifrån sina krav. Målet är därför att jämföra tre populära MOMs; Apache Kafka, RabbitMQ och Nats Streaming. Resultaten visar att Kafka presterar bäst med små meddelandestorlekar (Under 512 bytes). RabbitMQ presterar bäst för större meddelanden (Över 32768 bytes) medans Nats Streaming enbart presterar bäst med ett begränsat antal meddelandegarantier och med en meddelandestorlek på 4096 bytes.

End-to-end delay measurement is deemed crucial for network models at all times as it acts as a pivotal metric of the model’s effectiveness, assists in delineating its performance ceiling, and stimulates further refinement and enhancement. This premise holds true for 5G Core Network (5GC) models as well. Commercial 5G models, with their intricate topological structures and requirement for reduced latencies, necessitate an effective model to anticipate each server’s current latency and load levels. Consequently, the introduction of a model for estimating the present latency and load levels of each network element server would be advantageous. The central content of this article is to record and analyze the packet data and CPU load data of network functions running at different user counts as operational data, with the data from each successful operation of a service used as model data for analyzing the relationship between latency and CPU load. Particular emphasis is placed on the end-to-end latency of the PDU session establishment scenario on two core functions - the Access and Mobility Management Function (AMF) and the Session Management Function (SMF). Through this methodology, a more accurate model has been developed to review the latency of servers and nodes when used by up to 650, 000 end users. This approach has provided new insights for network level testing, paving the way for a comprehensive understanding of network performance under various conditions. These conditions include strategies such as "sluggish start" and "delayed TCP confirmation" for flow control, or overload situations where the load of network functions exceeds 80%. It also identifies the optimal performance range. / Latensmätningar för slutanvändare anses vara viktiga för nätverksmodeller eftersom de fungerar som en måttstock för modellens effektivitet, hjälper till att definiera dess prestandatak samt bidrar till vidare förfining och förbättring. Detta antagande gäller även för 5G kärnnätverk (5GC). Kommersiella 5G-nätverk med sin komplexa topologi och krav på låg latens, kräver en effektiv modell för att prediktera varje servers aktuella last och latensbidrag. Följdaktligen behövs en modell som beskriver den aktuella latensen och dess beroende till lastnivå hos respektive nätverkselement. Arbetet består i att samla in och analysera paketdata och CPU-last för nätverksfunktioner i drift med olika antal slutanvändare. Fokus ligger på tjänster som används som modelldata för att analysera förhållandet mellan latens och CPU-last. Särskilt fokus läggs på latensen för slutanvändarna vid PDU session-etablering för två kärnfunktioner – Åtkomst- och mobilitetshanteringsfunktionen (AMF) samt Sessionshanteringsfunktionen (SMF). Genom denna metodik har en mer exakt modell tagits fram för att granska latensen för servrar och noder vid användning av upp till 650 000 slutanvändare. Detta tillvägagångssätt har givit nya insikter för nätverksnivåtestningen, vilket banar väg för en omfattande förståelse för nätverprestanda under olika förhållanden. Dessa förhållanden inkluderar strategier som ”trög start” och ”fördröjd TCP bekräftelse” för flödeskontroll, eller överlastsituationer där lasten hos nätverksfunktionerna överstiger 80%. Det identifierar också det optimala prestandaområdet.

BBR is a congestion control recently proposed by Google, unlike the traditional congestion control which uses packet loss as the signal of congestion, BBR uses the estimation of bottleneck bandwidth to control the sending rate. However, recent work shows that BBR suffers from a variety of problems such as large queuing delays with multiple flows in the network. Most of the existing work in this area has so far focused on the performance analysis of BBR. Despite these efforts, there exists still a lack of understanding on how to improve the performance of BBR in different scenarios. In this paper, we first present the behaviour of the original BBR in the Network Simulator 3 (ns-3), then, we provide an improvement that carefully adjusts the pacing rate based on the RTT of the flow, finally, to validate our method, we run simulations varying different bottlenecks, latency, and numbers of flows in both small and large buffer size scenarios on ns-3 network simulator. The results show that our improvement can significantly reduce the queuing delay on the bottleneck at a very small cost of throughput in large buffer scenarios, and also achieve less than 0.1% retransmission rate in small buffer scenarios. / BBR är en typ av stockningskontroll som nyligen föreslagits av Google. Till skillnad från traditionell stockningskontroll som använder paketförlust som stockningssignal använder BBR en uppskattning av bandbredden i flaskhalsen mellan sändare och mottagare för att styra sändningshastigheten. Senare arbete visar dock att BBR lider av olika problem, såsom långa förseningar i paketköer med flera flöden i nätverket. Det mesta av det befintliga arbetet inom detta område har hittills fokuserat på att analysera BBR-prestanda. Trots dessa ansträngningar saknas det fortfarande förståelse för hur man kan förbättra BBR:s prestanda i olika scenarier. I den här rapporten presenterar vi först beteendet hos den ursprungliga BBR i nätverkssimulatorn ns-3. Därefter föreslår vi en förbättring som noggrant justerar sändningstakten enligt RTT (Round Trip Time) för flödet. Slutligen, för att validera vår metod, utför vi simuleringar som varierar olika flaskhalsar, fördröjningar och antal paketströmmar i små och stora buffertstorlekar i ns-3. Resultaten visar att vår förbättring avsevärt kan minska köfördröjningar i flaskhalsar för stora buffertstorlekar till en mycket låg kostnad i genomströmning, samt uppnå mindre än 0.1% omsändningshastighet i scenarier med små buffertstorlekar.

Most services today are developed with a microservice architecture where each component is deployed with multiple replicas on servers all over the world. When requests go between service components, the role of a load balancer is to route each request to the least loaded instance of the target component. There are many algorithms that evaluate different parameters and select an instance from those. One approach is to optimize for latency, i.e., choose the instance that will result in the lowest latency. However, this approach does not take into consideration the geographical distribution of servers, or when requests have to cross networking boundaries, i.e., go from one physical data center to another. Crossing networking boundaries comes with an increased cost as connecting two data centers far apart is an expensive task. Therefore, the cloud computing provider will charge this traffic more than when just sending traffic within a single data center. This study set out to use Google Traffic Director, a service mesh that has information about the whole system and can, therefore, offer locality-aware load-balancing that tries to minimize the amount of traffic that crosses networking boundaries. This is compared to a latency-based algorithm without a service mesh architecture, namely Expected Latency Selector. The study was set up to evaluate how the different approaches performed in terms of cost, latency, and resilience. This evaluation was performed by setting up two testing environments where both load-balancing algorithms could run and relevant metrics were collected. This was then tested in three different scenarios: no disturbance, random delay in a zone, and the final being a zone failing all requests. Results show that in a perfect environment, a locality-aware approach with Traffic Director can reduce the networking cost to an optimal level by only sending a negligible amount of requests cross-zone, while still performing equally well as the latency-based approach in terms of latency. However, when a delay or failure is introduced, Traffic Director, in our setup, keeps the same behavior of prioritizing the locality instead of distributing requests to other zones to even out the latency and circumvent the faulty servers. / De flesta online tjänsterna idag är utvecklade med en mikrotjänst arkitektur där varje komponent är distribuerad med många kopior på servrar över hela världen. När en förfrågan går mellan en tjänsts komponenter, är en lastbalanserares roll att dirigera en förfrågan till den minst belastade instansen av målkomonenten. Det existerar många algoritmer som evaluerar olika parametrar och väljer en instanser på det sättet. Ett tillvägagångssätt är att optimera för latens d.v.s. välja den instansen som kommer att ge lägst latens. Detta tillvägagångssätt kommer däremot inte ta den geografiska distributionen av servrar eller när en förfrågan behöver korsa nätverksgränser i åtanke. Att korsa nätverksgränser kommer med en öka kostnad eftersom att förbinda två datacenter är omständigt och dyrt. Därav kommer molntjänstleverantören att ta mer betalt för denna typ av nätverkstrafik än trafik som håller sig inom ett datacenter. Denna studie använde sig därav av Googles Traffic Director, en service mesh som erbjuder lokalitets-medveten lastbalansering som försöker minimera mängden trafik som korsar nätverksgränser, och jämför det med en latens-baserad algorithm kallad Expected Latency Selector. Studie evaluerar hur de två olika tillvägagångsätten presterar sett till kostnad, latens och resiliens. Evalueringen genomfördes genom att sätta upp två testmiljöer där båda algoritmerna kunde köras och relevant data samlades. Detta kördes sedan under tre olika scenarion: ingen störning, slumpmässig fördröjning och en zon där varje förfrågan misslyckas. Resultaten indikerar att in en perfekt miljö kan ett lokalitets-medvetet tillvägagångssätt med Traffic Director reducera nätverkskostnaden till en optimal nivå genom att endast skicka en försumbar mängd förfrågan till andra zoner, och samtidigt prestera ekvivalent med latens-baserade tillvägagångssättet sett till latens. Däremot, när en fördröjning eller misslyckande av förfrågan introduceras kommer Traffic Director att behålla samma beteende av att prioritera lokalitet istället för att distribuera förfrågningar till andra zoner för att jämna ut latensen och kringgå felaktiga servrar.

Network data rates are growing rapidly. The data rates provided to the customers by their network providers vary from Mbps to Gbps. However, rarely do users get the promised peak throughput. In cellular networks, network conditions change based on obstacles, weather conditions between the client and the base stations, and even the movement of objects and people. As a result of the changes in the radio link, the data transfer rate can change rapidly, hence devices needs to adjust their communications based on the currently available data rate. The Transmission Control Protocol (TCP) is widely used for reliable data transfer over networks. However, TCP was initially designed when link data rates were much lower than the link data rates commonly available today. As a result, TCP does not perform well at high data rates, despite some of the changes that have been made to the protocol to support high data rate links. Moreover, TCP has problems adapting to large changes in link bandwidth (not caused by congestion), resulting in a lower average throughput than the link could potentially deliver. This thesis evaluates two different versions of the TCP protocol (e.g., TCP Reno and Cubic TCP) and proposes a network coding scheme to enhance users’ experience when communicating over unstable radio links. The performance of the two TCP protocols and Random Linear Network Coding (RLNC) scheme were measured in an emulated network environment. The results of these measurements were analyzed and evaluated. The analysis shows that RLNC can provide a higher throughput than TCP over a network with high packet loss. However, RLNC is a UDP based solution and does not implement congestion control algorithms or reliability. A new solution is proposed that increases reliability and implements network adaptation in RLNC solutions. The results obtained in this thesis can be used to develop a new protocol to increases the quality of users’ experience in high loss networks. / Datahastigheter över nätverk ökar drastiskt. Datahastigheterna som ges tillgängliga till användare av deras respektive dataleverantör kan variera från Mbit/s till Gbit/s. Det är dock inte ofta användare får ut vad som har lovats. I mobila nätverk kan nätverkets tillstånd ändras baserat på hinder, väderleksförhållanden mellan en klient och basstationerna, till och med beroende på förflyttning av objekt eller människor. På grund av detta så behöver användares utrustning anpassa dess kommunikation, baserat på den för närvarande tillgängliga datahastigheten. Transmission Control Protocol (TCP) används i stor utsträckning vid behovet av tillförlitlig dataöverföring över nätverk. Däremot så designades TCP när länkdatahastigheterna var mycket lägre än vad som är vanligen tillgängligt idag. På grund av detta så presterar inte TCP över höga datahastigheter, trots ändringar som har gjorts i protokollet för att stödja höghastighets datalänkar. Utöver det så har TCP svårt att anpassa sig efter stora ändringar i länkens bandbredd (som inte är orsakat av stockning), som resulterar i en mindre genomsnitts-dataström än vad länken potentiellt hade kunnat ge. Detta examensarbete utvärderar två olika versioner av TCP (e.g., TCP Reno och Cubic TCP) och föreslår ett sätt att använda network coding för att öka användares upplevelse vid dataöverföring över instabila radio länkar. Prestationerna av de två TCP versionerna och Random Linear Network Coding (RLNC) metoden har blivit mätt i en emulerad nätverksmiljö. Resultaten från dessa mätningar blev analyserade och utvärderade. Analysen visar att RLNC kan ge en högre dataström än TCP över ett nätverk med hög risk för paketförluster. Däremot så är RLNC en User Datagram Protocol (UDP) baserad lösning, och därav inte implementerar trängselkontrolls-algoritmer eller tillförlitlighet. Ett förslag till en ny lösning som ökar tillförlitlighet och implementerar nätverksanpassning till RLNC lösningar har presenterats. Resultaten från detta examensarbete kan användas till att utveckla nya protokoll för att öka kvalitén av användares upplevelse i nätverk med risk för hög paketförlust.

I takt med den exponentiella tillväxten av Internet of Things (IoT) har utmaningen att hantera den enorma mängden genererade data blivit allt större. Denna studie undersöker paradigmen med distribuerade dimdatorer, där kostnadseffektiva IoT-enheter används som dimnoder, som en potentiell lösning på de utmaningarna som det centraliserade molnet står inför. Skalbarheten och prestandan hos ett dimdatorsystem utvärderades under en rad olika arbetsbelastningar genererade av beräkningsintensiva uppgifter. Resultaten visade att en ökning av antal dimnoder förbättrade systemets skalbarhet och minskade den totala latensen. Dock visade det sig att konfigurationer med färre dimnoder presterade bättre vid lägre arbetsbelastningar, vilket understryker vikten av balansen mellan beräkningsuppgifter och kommunikationskostnaden. Sammantaget framhäver denna studie dimdatorkonceptets genomförbarhet som en effektiv och skalbar lösning för beräkningsintensiva databearbetning inom IoT. Trots att studiens fokus låg på latens, kan de insikter som vunnits vägleda framtida design och implementering av dimdatorsystem och bidra till de pågående diskussionerna om strategier för datahantering inom IoT. / With the exponential growth of the Internet of Things (IoT), managing the enormous amount of data generated has become a significant challenge. This study investigates the distributed paradigm of fog computing, using cost-effective IoT devices as fog nodes, as a potential solution for the centralized cloud. The scalability and performance of a fog computing system were evaluated under a range of workloads, using computationally intensive tasks reflective of real-world scenarios. Results indicated that with an increase in the number of fog nodes, system scalability improved, and the overall latency decreased. However, at lower workloads, configurations with fewer fog nodes outperformed those with more, highlighting the importance of the balance between computation and communication overheads. Overall, this study emphasizes the viability of fog computing as an efficient and scalable solution for data processing in IoT systems. Although the study primarily focused on latency, the insights gained could guide future design and implementation of fog computing systems and contribute to the ongoing discussions on IoT data processing strategies.

Virtual Environments have transformed over the years the way software is built and distributed. The recent growth of services such as Amazon EC2 or Google Cloud is representative of this trend and encourages developers to build software intended for virtual environments like virtual machines or containers. Despite all the benefits that virtualization brings (isolation, security, energy efficiency, stability, portability, etc.), the extra layer of software between the virtual environment and the hardware, called the hypervisor, increases the complexity of a system and the interpretation of its metrics. In this paper, we explore the situation of software performing latency measurements from a virtual environment. This is an example of a use-case where latency from the hypervisor could lead to measurable noise on the virtual environment if the hypervisor makes our environment wait for resources for milliseconds. To solve this problem, we propose an algorithm that will filter out this noise from computed metrics from the virtual environment. This algorithm was developed studying correlation between those metrics and hypervisor-induced latency spikes. We also try to be hypervisor agnostic which means that this work stays relevant whether a virtual environment is deployed locally or on a Cloud Service with different (and constantly evolving) hypervisor technologies. This research gives an overview of hypervisor technologies and how latency can appear when executing processes on virtual environments. As we will see, computing the metric and running the algorithm make network quality measurements from virtual environments more reliable and can explain unexpected latencies. / Virtuella miljöer(virtual environments) har under åren förändrat hur mjukvara(software) byggs och distribueras. Den senaste tidens tillväxt av tjänster som Amazon EC2 eller Google Cloud är representativ för denna trend och uppmuntrar utvecklare att bygga programvara avsedd för virtuella miljöer som virtuella maskiner eller behållare. Trots alla fördelar som virtualisering ger (isolering, säkerhet, energieffektivitet, stabilitet, portabilitet, etc.), ökar det extra lagret av mjukvara mellan den virtuella miljön och hårdvaran, kallad hypervisor, komplexiteten hos ett system och tolkning av dessa måtvärden. I denna artikel utforskar vi situationen för programvara som utför latensmätningar från en virtuell miljö. Detta är ett exempel på ett användningsfall där latens från hypervisorn kan leda till mätbart brus i den virtuella miljön om hypervisorn får vår miljö att vänta på resurser i millisekunder. För att lösa detta problem föreslår vi en algoritm som kommer att filtrera bort detta brus från beräknade mätvärden från den virtuella miljön. Denna algoritm utvecklades för att studera korrelationen mellan dessa mätvärden och hypervisor-inducerade latensspikar. Vi försöker också vara hypervisoragnostiska vilket innebär att detta arbete förblir relevant oavsett om en virtuell miljö distribueras lokalt eller på en molntjänst med olika (och ständigt utvecklande) hypervisorteknologier. Denna forskning ger en översikt över hypervisorteknologier och hur latens kan uppstå när processer körs i virtuella miljöer. Som vi kommer att se gör beräkning av måtten och körning av algoritmen mätningar av nätverkskvalitet från virtuella miljöer mer tillförlitliga och kan förklara oväntade latenser. / Les environments virtuels transforment depuis des années la manière de développer et distribuer du logiciel. La récente croissance de services comme Amazon EC2 ou Google Cloud reflète bien cette tendance et encourage les développeurs à construire du logiciel déployable sur des environnements virtuels comme des machines virtuels ou des conteneurs. Malgré tous les bénéfices que la virtualisation apporte (isolation, sécurité, efficacité énergétique, stabilité, portabilité, etc.), la couche logiciel supplémentaire entre l’environnement virtuel et le hardware, appelée hyperviseur, augmente la complexité d’un système et l’interprétation de ces métriques. Dans ce mémoire de projet de fin d’études, nous explorons la situation où un logiciel effectue des tests de latence depuis un envirronnement virtuel. Cette situation est un exemple d’un cas d’utilisation où la latence introduite par un hyperviseur peut mener à un bruit mesurable si l’hyperviseur fait attendre notre environnement dans l’ordre de grandeur de la milliseconde. Pour résoudre ce problème, nous proposons un algorithme qui filtre ce bruit à partir de métriques calculées directement depuis l’environnement virtuel. Cet algorithme est dévelopé en étudiant la corrélation entre nos métriques et une latence dite "hypervisor-induced". Cette approche permet donc une grande flexibilité dans la technologie sous-jacente de l’hôte puisque celui-ci peut utiliser des hyperviseurs différents ou même faire partie d’un service Cloud sans que notre solution en soit impactée. Ce mémoire donne aussi un aperçu de la technologie derrière un hyperviseur et comment de la latence peut s’introduire dans l’exécution d’un processus dans un environnement virtuel.

Med dagens snabba utveckling av informationsteknologin och med ökningen av antalet människor som är uppkopplade mot Internet, blir utvecklingen av webbtjänster allt viktigare. Eftersom webbtjänster har en betydande roll för utvecklingen av Internet, uppstår frågan om vilka verktyg som bör användas för att uppnå den prestanda som dagens användare kräver. Ett vanligt tillvägagångssätt för implementering av webbtjänster är med arkitekturen REST. Dock har REST prestandasvagheter som overfetching, underfetching och hantering av slutpunkter som uppstår i fall där flera slutpunkter nås. Ett alternativ till REST är frågespråket GraphQL som utvecklades för att utesluta de svagheter som REST har och således förbättra prestanda vid datahämtning. I detta arbete utfördes prestandamätningar där latens och datavolym mättes vid olika typer av frågor för respektive GraphQL, REST utan cache och REST med cache. Latens är tidsintervallet från att en klient skickar en förfrågan till att klienten mottar svaret, och datavolym avser storleken på data i ett svarspaket som överförs från en server till en klient. REST med cache togs med i prestandamätningarna då det inte har undersökts i tidigare arbeten som jämfört prestanda mellan GraphQL och REST. Resultaten visade att GraphQL presterar bättre med avseende på både latens och datavolym, i jämförelse med de övriga systemen i fall där förfrågningar ställs mot två eller flera slutpunkter i REST. GraphQL presterade sämre än övriga system, med avseende på latens, när endast en slutpunkt i REST kontaktades. Däremot presterade GraphQL bättre än de övriga systemen, med avseende på datavolym, i samtliga fall. Vid jämförelse av REST med och utan cache visade det sig att ju fler slutpunkter som kontaktades, desto bättre presterade REST utan cache med avseende på datavolym medan REST med cache presterade bättre med avseende på latens. / With today’s rapid development of information technology and with the increase in the number of people connected to the Internet, the development of web services is becoming more important. As web services play a significant role in the development of the Internet, the question arises as to which tools should be used to achieve the performance required by today’s users. A common approach for implementing web services is with the architecture REST. However, REST has performance weaknesses such as overfetching, underfetching, and maintenance of endpoints, that arise in cases where multiple endpoints are accessed. An alternative to REST is the GraphQL query language, which was developed to exclude the weaknesses that REST has and thus improve performance in data retrieval. In this work, performance measurements were conducted where latency and data volume were measured for different types of queries for GraphQL, REST without cache and, REST with cache. Latency is the time interval between a client sending a request and the client receiving the response, and data volume refers to the size of data in a response packet that is transmitted from a server to a client. REST with cache was included in the experiment as it has not been investigated in previous work comparing performance between GraphQL and REST. The results showed that GraphQL performs better, in terms of both latency and data volume, compared to the other systems in cases where requests are made to two or more endpoints in REST. GraphQL performed worse than the other systems, in terms of latency, when only one endpoint in REST was contacted. However, GraphQL performed better than the other systems in terms of data volume in all cases. When comparing REST with and without cache, it turned out that the more endpoints that were contacted, the better REST without cache performed in terms of data volume, while REST with cache performed better in terms of latency.

Applications today are generally deployed in public cloud environments such as Azure, AWS etc. Mobile edge computing (MEC) enables these applications to be relocated to edge nodes which are located in close proximity to the end user, thereby allowing the application to serve the user at lower latency. However, these edge nodes have limited capacity and hence a problem arises of when to relocate an application to an edge. This thesis project attempts to tackle the problem of detecting when an application’s quality of experience is degraded, and how to use this information in order to generate candidates for relocation to edge nodes. The assumption for this thesis project is there is no insight to the application itself, meaning the applications are treated as blackboxes. To detect quality of experience degradation we chose to capture network packets and inspect protocol-level information. We chose WebRTC and HTTP as communication protocols because they were the most common protocols used by the target environment. We developed two application prototypes. The first prototype was a rudimentary server based on HTTP and the second prototype was a video streaming application based on WebRTC. The prototypes were used to study the possibility of breaking down latency components and obtaining quality of service parameters. We then developed a recommendation engine to use this information in order to generate relocation candidates. The recommendation engine was evaluated by placing the WebRTC prototype under quality of experience affecting scenarios and measuring the time taken to generate a relocation candidate of the application. The result of this project show it is possible in some cases to break down latency components for HTTP based applications. However, for WebRTC based applications our approach was not sufficient enough to break down latency components. Instead, we had to rely on quality of service parameters to generate relocation candidates. Based on the outcomes of the project, we conclude detecting quality of experience degradation for blackbox applications have three generalizations. Firstly, the underlying transport and communication protocol has an impact on available approaches and obtainable information. Secondly, the implementation of the communication protocol also has an impact on obtainable information. Lastly, the underlying infrastructure can matter for the approaches used in this project. / Applikationer idag produktionssätts allmänhet i offentliga molntjänster som Azure, AWS etc. Mobile edge computing (MEC) gör att dessa applikationer kan flyttas till gränsnoder som är placerade i närheten av slutanvändaren, vilket gör att applikationen kan erbjuda användaren lägre latens. Dessa gränsnoder har emellertid begränsad kapacitet och därför uppstår ett problem om när en applikation ska flyttas till en gränsnod. Detta examensarbete försöker ta itu med problemet med att upptäcka när en applikations upplevelsekvalitet försämras, och hur man använder denna information för att generera kandidater för omlokalisering till gränsnoder. Antagandet för detta examensarbete är att det inte finns någon insikt i själva applikationen, vilket innebär att applikationer behandlas som svarta lådor. För att upptäcka försämring av upplevelsekvalitet valde vi att fånga nätverkspaket och inspektera information på protokollnivå. Vi valde WebRTC och HTTP som kommunikationsprotokoll eftersom de var de vanligaste protokollen som användes i målmiljön. Vi utvecklade två applikationsprototyper. Den första prototypen var en rudimentär server baserad på HTTPoch den andra prototypen var en videoströmningsapplikation baserad på WebRTC. Prototyperna användes för att studera möjligheten att bryta ned latenskomponenter och erhålla tjänstekvalitetsparametrar. Vi utvecklade sedan en rekommendationsmotor för att använda denna information till att generera omplaceringskandidater. Rekommendationsmotorn utvärderades genom att placera WebRTC-prototypen under scenarion som påverkar upplevelsekvaliten, och sedan mäta tiden det tog att generera en omlokaliseringskandidat av applikationen. Resultatet av detta projekt visar att det i vissa fall är möjligt att bryta ned latenskomponenter för HTTP-baserade applikationer. Dock för WebRTCbaserade applikationer var vårt tillvägagångssätt inte tillräckligt för att bryta ned latenskomponenter. Istället var vi tvungna att förlita oss på kvalitetsparametrar för tjänsten för att generera omlokaliseringskandidater. Baserat på resultaten av projektet drar vi slutsatsen att upptäcka kvalitetsförsämring av erfarenheter för blackbox-applikationer har tre generaliseringar. För det första har det underliggande transport- och kommunikationsprotokollet en inverkan på tillgängliga tillvägagångssätt och tillgänglig information. För det andra har implementeringen av kommunikationsprotokollet också en inverkan på tillgänglig information. Slutligen kan den underliggande infrastrukturen ha betydelse för de tillvägagångssätt som används i detta projekt.