Media delivery harmonization over Digital Terrestrial Television (DTT) and 5G networks

Curso: 2022 - 2023 Director/Directora: Angueira Buceta, Pablo Codirector/Codirectora: Montalbán Sanchez, Jon Estudiante : Jiménez Acedo, Erick MEDIA DELIVERY HARMONIZATION OVER DIGITAL TERRESTRIAL TELEVISION (DTT) AND 5G NETWORKS MÁSTER UNIVERSITARIO EN INGENIERÍA DE TELECOMUNICACIÓN TRABAJO FIN DE MASTER Fecha: Bilbao, 18, septiembre, 2023 Contents 1 Introduction 10 1.1 Technical Advances on Mobile Networks . . . . . . . . . . . . . . . . . . . 11 1.2 Technical Advances on Broadcast Networks . . . . . . . . . . . . . . . . . . 12 1.3 Motivation.................................... 12 2 Objectives 14 3 Contribution to SDG 15 4 State of the Art 16 4.1 Mobilenetworks................................. 16 4.1.1 5GArchitecture............................. 17 4.1.2 Key features of every 5G Release . . . . . . . . . . . . . . . . . . . 33 4.2 BroadcastNetworks............................... 36 4.2.1 ATSC3.0 ................................ 36 4.3 Convergence between Broadcast and Broadband systems . . . . . . . . . . 40 5 Methodology 44 5.1 Phase 1: Project definition and State of the Art study . . . . . . . . . . . 44 5.2 Phase 2: Specifications study and implementation of selected 5G equipment 44 5.3 Phase 3: Adaptation of an ATSC network simulation model . . . . . . . . 46 5.4 Phase 4: Design and Implementation of a Convergent Architecture between ATSCand5G.................................. 49 5.5 Phase 5: Simulation and analysis of convergent use cases . . . . . . . . . . 49 6 Architectures for 5GS and Evaluation Procedure 51 6.1 AApproach................................... 51 6.1.1 Troubleshooting............................. 51 6.2 BApproach................................... 54 6.2.1 Troubleshooting............................. 55 7 Architecture for ATSC 3.0 and Evaluation Procedure 57 7.1 Originalprototype ............................... 57 7.2 Adaptedsolution ................................ 59 8 Architectures for a Convergent System and Evaluation Procedure 63 8.1 KPIprocessing ................................. 64 9 Results and Discussions 66 9.1 UE Mobility and QoE degradation . . . . . . . . . . . . . . . . . . . . . . 67 9.2 Delay and QoE Degradation . . . . . . . . . . . . . . . . . . . . . . . . . . 71 10 Project Planning 73 10.1 Work Packages and Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 10.2GanttChart................................... 74 11 Conclusions 76 12 Bibliography 77 List of Figures 1 Original 3GPP 5G development roadmap. . . . . . . . . . . . . . . . . . . 11 2 ATSC 3.0 protocol stack [4]. . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3 Non stand-alone architecture [6]. . . . . . . . . . . . . . . . . . . . . . . . 18 4 5GC visualized with Service-Based interfaces [6]. . . . . . . . . . . . . . . . 21 5 5GC visualized with point-to-point interfaces [6] . . . . . . . . . . . . . . . 22 6 PCF Service Registration. . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7 AMFServiceDiscovery. ............................ 23 8 AMF Service Request and previous stages. . . . . . . . . . . . . . . . . . . 23 9 Simple 5GC version with obligatory components. . . . . . . . . . . . . . . 24 10 UE served by a pair of SMF/UPF. . . . . . . . . . . . . . . . . . . . . . . 26 11 IPmobility. ................................... 27 12 Entities involved in user plane connection to radio networks and external networks. .................................... 27 13 Connections between the device and the CN for non-3GPP access. . . . . . 28 14 5G radio network architecture. . . . . . . . . . . . . . . . . . . . . . . . . . 29 15 5G radio protocol stack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 16 Network-internal signaling protocol stack. . . . . . . . . . . . . . . . . . . 30 17 Air interface protocol stack. . . . . . . . . . . . . . . . . . . . . . . . . . . 31 18 Resource allocation for three different devices. . . . . . . . . . . . . . . . . 31 19 SDAP protocol structure [13]. . . . . . . . . . . . . . . . . . . . . . . . . . 34 20 5G Multicast traffic example. . . . . . . . . . . . . . . . . . . . . . . . . . 35 21 5G Broadcast traffic example. . . . . . . . . . . . . . . . . . . . . . . . . . 35 22 ATSC 3.0 layered structure. . . . . . . . . . . . . . . . . . . . . . . . . . . 36 23 ATSC 3.0 documents structure. . . . . . . . . . . . . . . . . . . . . . . . . 37 24 ATSC 3.0 receiver protocol stack. . . . . . . . . . . . . . . . . . . . . . . . 38 25 UMLDiagram. ................................. 39 26 Example of separate ROUTE sessions/PLPs to differentiate QoS for video andaudio..................................... 40 27 IP-based cooperative services using ATSC 3.0 and Broadband [17]. . . . . . 42 28 ATSSS functionality included in the 5GS [18]. . . . . . . . . . . . . . . . . 43 29 AmariCallboxClassic.............................. 45 30 DekTec DTU-315 Modulator. . . . . . . . . . . . . . . . . . . . . . . . . . 47 31 DekTec DTA-2131 Receiver. . . . . . . . . . . . . . . . . . . . . . . . . . . 47 32 Triveni GuideBuilder MPD Injest. . . . . . . . . . . . . . . . . . . . . . . . 48 33 Triveni GuideBuilder ROUTE Transmit. . . . . . . . . . . . . . . . . . . . 48 34 Initial 5G architecture design. . . . . . . . . . . . . . . . . . . . . . . . . . 51 35 5G SA Successful Registration Process. . . . . . . . . . . . . . . . . . . . . 52 36 PDU Session Establishment Accept message and allocated IP addresses. . . 53 37 Final 5G architecture design. . . . . . . . . . . . . . . . . . . . . . . . . . . 54 38 APNConfiguration................................ 55 39 Quectel 5G-M2 EVB Kit. . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 40 DTT and mobile legacy architectures to propose BCN for future DTT. . . 57 41 Envisioned architecture for a DTT network containing a BCN. . . . . . . . 59 42 Guidebuilder Service Network Map. . . . . . . . . . . . . . . . . . . . . . 60 43 Logical Networks configuration. . . . . . . . . . . . . . . . . . . . . . . . . 61 44 Physical Transport configuration. . . . . . . . . . . . . . . . . . . . . . . . 61 45 Outputconfiguration............................... 62 46 Adapted DTT architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . 62 47 Final convergent architecture design. . . . . . . . . . . . . . . . . . . . . . 63 48 Amarisoftlogexample. ............................ 64 49 Processed Amarisoft log example. . . . . . . . . . . . . . . . . . . . . . . . 64 50 DL bitrate values for the sample video. . . . . . . . . . . . . . . . . . . . . 67 51 Bitrate downgrade Test I. . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 52 Bitrate downgrade Test II. . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 53 VLCStalling. .................................. 69 54 Use Case Analysis - Bitrate Downgrade (Kbps), Test I. . . . . . . . . . . . 70 55 Use Case Analysis - Bitrate Downgrade (Kbps), Test II. . . . . . . . . . . . 70 56 Use Case Analysis - Delay/Jitter Introduction. . . . . . . . . . . . . . . . . 72 57 GanttChart. .................................. 75 List of tables 1 Evolution of the average smartphone user’s data consumption [1]. . . . . . 10 2 Possible combinations of 5G radio and core networks. . . . . . . . . . . . . 18 3 Advantages of using a smartphone or a 5G router. . . . . . . . . . . . . . . 56 Acronyms 3GPP 3rd Generation Partnership Project IETF Internet Engineering Task Force ITU International Telecommunication Union QoS Quality of Service QoE Quality of Experience OTT Over-the-top CDN Content Delivery Networks IP Internet Protocol NR New Radio SBA Service Based Architecture MBS Multicast and Broadcast Services ATSC Advanced Television Systems Committee DTT Digital Terrestrial Television RAN Radio Access Network RAT Radio Access Technology NF Network Function CN Core Network 5GC 5G Core 5GS 5G System 5G SA 5G Standalone 5G NSA 5G Non-Standalone PTP Point-to-point PTM Point-to-multipoint DASH Dynamic Adaptative Streaming over HTTP ROUTE Real-Time Object Delivery over Unidirectional Transport Resumen La popularidad del streaming de contenidos multimedia ha crecido considerablemente en los ´ultimos a˜nos, convriti´endose en un componente importante del tr´afico diario en Internet. Incluso se prev´e que para el a˜no 2024 el tr´afico de v´ıdeo sea el responsable del 74% del tr´afico diario de un smartphone. Este incremento es debido a razones como mayores tiempo de visionado, un cat´alogo mas extenso y mayores resoluciones. Adem´as, el desarrollo de nuevas aplicaciones con un gran requisito computacional, como puede ser la Realidad Aumentada (RA), Realidad Virtual (VR) o la Telepresencia Hologr´afica est´a contribuyendo a´un m´as a dicho incremento. Es por esta raz´on que es necesario mejorar las arquitecturas cl´asicas de telefon´ıa para conseguir m´etodos de distribuci´on m´as eficientes y poder cumplir con los requisitos de calidad de los usuarios. Teniendo esto como objetivo, este proyecto pretende explorar la convergencia de las redes de TDT y de telefon´ıa 5G para conseguir un esquema que trabaje de forma cooperativa. El trabajo tiene como base la utilizaci´on de los ´ultimos avances en las redes punto a multipunto de TDT, es decir, la transici´on hacia un paradigma IP, para la harmonizaci´on con las arquitecturas de banda ancha 5G. Como resultado final, este trabajo no solo ha permitido la creaci´on de un banco de pruebas convergente sobre el que trabajar en el laboratorio, sino que ha demostrado comportamientos y patrones muy interesantes en los casos de uso estudiados. 7 Laburpena Multimedia edukien streaming-aren ospea nabarmen hazi da azken urteotan, eta Interneteko eguneroko trafikoaren osagai garrantzitsu bat bihurtu da. 2024rako smartphone baten eguneroko trafikoaren % 74aren arduraduna bideo-trafikoa izatea ere aurreikusten da. Hazkunde hori ikusteko denbora gehiago, katalogo zabalagoa eta bereizmen handiagoak direla-eta gertatu da. Gainera, konputazio-betekizun handia duten aplikazio berrien garapenak, hala nola Errealitate Areagotua (RA), Errealitate Birtuala (EB) edo Telepresentzia Holografikoa, are gehiago laguntzen du gehikuntza horretan. Horregatik, beharrezkoa da telefoniako arkitektura klasikoak hobetzea, banaketa-metodo eraginkorragoak lortzeko eta erabiltzaileen kalitate-baldintzak bete ahal izateko. Helburu hori izanik, proiektu honek LTDko eta 5G telefoniako sareen konbergentzia aztertu nahi du, modu kooperatiboan lan egingo duen eskema bat lortzeko. Lanaren oinarria da LTDko puntu-puntu anitzeko sareetako azken aurrerapenak erabiltzea, hau da, IP paradigma bateranzko trantsizioa, 5G banda zabaleko arkitekturekin harmonizatzeko. Azken emaitza gisa, lan honek laborategian lan egiteko proba-banku konbergente bat sortzea ahalbidetzeaz gain, aztertutako erabilera-kasuetan oso portaera eta eredu interesgarriak erakutsi ditu. 8 3 Contribution to SDG Apart from the clear economic and technical benefits that this project provides, it also contributes positively to the Sustainable Development Goals (SDG) in various aspects. Additionally, this project targets the growth of the ICT industry, which is significant for the European GDP. Harmonization or convergence between 5G and DTT enhances community streaming services aligning with several SDGs: • SDG 4: Quality Education. Improved access to streaming services can contribute to online educational resources, promoting quality education. • SDG 9: Industry, Innovation and Infrastructure. This project aims to bridge 5G and DTT networks, achieving innovation and contributing to the development of inclusive and sustainable infrastructure. • SDG 10: Reduced Inequalities. Providing better access to streaming services can help reduce inequalities in access to content and information. • SDG 11: Sustainable Cities and Communities. This endeavor, along with network collaboration, has the potential to result in communities that are better informed and interconnected. This aligns with the goal’s emphasis on promoting sustainable urban development. • SDG 17: Partnership for the Goals. Collaborating between different network sectors showcases partnerships for technological advancements that can benefit society. 15 4 State of the Art A thorough examination of the project precedents is essential for three main reasons: • To understand the context of the problem and establish the contributor’s knowledge about the subject. In what scope does the issue fall? Do I possess the appropriate knowledge for its resolution? • To explore potential solutions to the problem. Are there existing solutions to the posed issue? What advancements are being made in the field of study? What benefits could the proposed solution offer? • To identify the appropriate tools. Once a general idea of the problem’s resolution is formed, what tools are available to address the problem? Is a solution feasible with the resources at hand? All these subjects must be resolved in the initial phases of the work plan in order to ensure a satisfactory outcome for the project. Nonetheless, it is also possible to change some of the initial hypotheses during the project’s advancement. In this section, firstly, a study has been conducted in the field of mobile communications. As previously mentioned, 3GPP has evolved through several versions and aims to enhance the overall performance of 5G with future developments. In this study, the focus is placed on examining their impact on multimedia streaming. Furthermore, it is also important to comprehend the 5G architecture, the NR concept, and the promising SBA of 5G. Having knowledge of the different Network Functions (NFs) is crucial to understanding how the CN operates. Secondly, after research on this field has been performed, the main concern was the transition of DTT systems to a full IP stack. More precisely, in this work attention is given to ATSC 3.0 due to the familiarization and collaboration of the research group with this standard, as well as the possibility of testing the results with laboratory hardware. ATSC’s remarkable strides in innovation are already widely acknowledged, marked by its promising architecture. As a result, the last part of this section is dedicated to exploring the convergence of both ATSC 3.0 and 5G, facilitated by their connection in the lower layers of broadband and broadcast systems [5]. Finally, after studying both systems, we make a final effort to understand the initiatives taken to achieve harmonization and convergence between the two architectures. 4.1 Mobile networks To begin with, it is worth noting that the primary reference for this portion of the study has been the book ’5G CORE NETWORKS Powering Digitalization’ [6] by Stefan Rommmer, et al. This book was written based on different technical documents such as Technical Reports, Technical Specifications, Recommendations, or RFCs from different organizations like 3GPP, IETF, ITU, or ITU-R. It thoroughly explains the main components of the 5GS and is highly detailed in key features like for example, NR, SBA, connectivity procedures, or NF-related concepts. Additionally, it provides comparisons 16 with the previous generation (LTE) in order to understand new ideas more easily. In conclusion, this book serves as a valuable reference and guide for understanding 5G on its own. While the design of the 5GC remains a central feature, the driving forces behind 5G extend beyond the creation of a new CN. Instead, they emerge from the intersection of various requirements and demands: • Demands from a wider range of economic actors, including industrial companies, are propelling the emergence of new use cases. •New technologies for delivering CN components creating more efficient operations. • Changes in the equilibrium between business, societal, and environmental requirements to provide services in a new way. A fundamental principle guiding the design of the 3GPP 5GC was not providing backward compatibility with legacy versions of radio access networks (RAN), i.e., GMS, WCDMA, and LTE. This paradigm shift, which was intended to be as future-proof as possible, was aimed at making the 5GC agnostic to access technologies, enabling the connection with any relevant access technology as well as those not specified by 3GPP. It instead was designed with its own set of interfaces defined for the interaction between radio networks and the CN. These interfaces are known as N2 and N3 for the signaling and user data parts respectively. The N2/N3 were defined based on the S1 protocols defined by 3GPP for 4G LTE, but with the intention to make them as generic as possible, [6]. 4.1.1 5G Architecture 4.1.1.1 Comparison between 5G SA and 5G NSA 5G Non-Standalone (5G NSA) and Standalone (5G SA) were defined as the two 5G tracks that communication service providers could opt for building their 5G architecture when transitioning from 4G. Understanding the different architectures was an important part of this project, as elaborated in the following section. Firstly, let us examine the initial option. In order not to disruptively launch early 5G services and rely on a new 5G architecture for radio and core networks, a solution that maximizes the reuse of 4G equipment was developed. In practice, it relies on LTE radio access for all signaling between devices and the network, and on an Evolved Packet Core (EPC) network improved to support selected 5G features. In this case, NR is only used for user data, and only when the device is in coverage. 17 Figure 3: Non stand-alone architecture [6]. An evident drawback of this option is that NR can only be deployed inside an LTE coverage area. Additionally, the potential innovation that 5G offers is constrained by the capabilities supported by LTE/EPC. The primary distinctions in capabilities lie within Network Slicing, QoS, the flexibility of Edge Computing, and the general adaptability of the CN for smooth integration with applications in an IT-like setting. In summary, there are four ways (8 combinations) in which LTE and/or NR can be deployed. They are consolidated in the table below: Access Network LTE NR LTE with NR NR with LTE EPC CN Opt 1(=4G) Opt 6 Opt 3 (NSA) Opt 8 5GC Opt 5 Opt 2 Opt 7 Opt 4 Table 2: Possible combinations of 5G radio and core networks. Options 6 and 8 were excluded from development due to the direct connection of NR to EPC, which would impose numerous limitations on NR. A comprehensive description of these options can be found in the technical document 3GPP SP-160455, 2016 [7]. However, even if the remaining options were considered, only options 3 and 2 were commercially valid due to having the largest market value. On a different note, it is worth mentioning that options 2,4,5, and 7 represent genuine efforts and the first attempt to create an access-independent interface between the CN and the RAN. Option 3 is known for NSA, which was previously described, and was the first 5G network architecture to enter the market. Nonetheless, the formal name for this option is E-UTRAN-NR Dual Connectivity, EN-DC. 18 Shifting focus back to 5G SA, this version is an implementation of 5G that solely uses a 5GC, meaning it has no dependency on LTE network control functions, for signaling and data transfer. This infrastructure is built across both the RAN and the CN, coupled with cloud-native principles, such as virtualization, containers, container orchestration, and microservices. For this reason, its use of network resources is more efficient and scalable, resulting in an enhanced user experience. In 5G SA, the CN provides control plane signaling, while the RAN handles the transfer of data traffic between the final user and the network. The article published by Dhanashree Shukla and Dr. Sudhir D. Sawarkar [8] outlines some of the differences between the SA and NSA architectures: • Coverage: In terms of coverage, both architectures seem to be similar as they both utilize NR coverage enhancing features like Massive MIMO or beam sweeping MIMO to overcome high-frequency related issues. • Network Capability: Network slicing, flexible QoS management, etc. are not available in the NSA version. • Terminal Performance: Interference occurrences are higher in NSA terminals due to their support for two radio links (LTE and NR). Furthermore, their performance may be affected by this dual link. • 4G/5G inter-working: In the case of NSA, inter-working is easier as the handover occurs intrasystem, as opposed to intersystem in the case of SA, which introduces higher latency. 4.1.1.2 Concept of SBA A significant departure from previous traditional architectures, where nodes were connected by interfaces, is the utilization of services for facilitating interaction between NFs. Essentially, this means that NFs interact making accessible supported functionalities to other NFs in the network over an API (Application Programming Interface). Hence, for each interaction between NFs, one of these acts as a ”Service Consumer”, and the other as the ”Service Producer”. It should be emphasized that this communication applies only to crucial signaling services, not to the transfer of user data. There are strong requirements on reliability and availability with lots of software inter-dependencies that can potentially make the system brittle and fragile. In complex systems, there will always be cases where harmless failures may seem trivial and isolated. However, the possibility of interaction with each other may lead to a chaotic cascade of disasters taking the whole system down. Additionally, considering that the SBA is a complex and tight entity and that many countries plan to use the 5GS for emergency services communications the possibility for a catastrophe arises [9]. Therefore, the design of the SBA is crucial and must be carefully carried out. Figure 4 shows a first look at the 5GC with Service-Based interfaces is shown. While the picture might suggest a comprehensive connectivity mesh among all the NFs, in practice, each NF consumes specific services from other NFs. This idea is represented in Figure 5 by using point-to-point interfaces instead of Service-Based ones. It is worth 19 mentioning that the purpose of this part of the work is not an exhaustive study of the interfaces and many different NFs, but to understand how the SBA and the main NFs work. As it was previously stated, functionalities offered by NFs are accessible over an API. The communication method defined for 5GC is based on the well-known HTTP REST paradigm, which is a set of rules or guidelines that define how web communication technologies access services from distributed applications using APIs. These design rules explain how to implement the communication between different nodes in a networked architecture. Data exchange within the SBA relies on JSON-encoded data. Most contemporary programming languages offer a JSON module that facilitates the conversion from the internal representation to the textual JSON format. In [9] some of the drawbacks and security issues of using this format are discussed, but it is out of the scope of this work. Service-Based interfaces and APIs are a logical choice by 3GPP, given that the software applications responsible for implementing the NFS in the 5GC are expected to operate within an environment resembling IT or shared IT systems. Figure 4shows the utilization of the aforementioned HTTP REST paradigm for service-based communication. This is based on the defined message syntax from the HTTP web protocol and relies on the concept of Resource Modeling. In practice, this means that a distributed software application can be addressed through Uniform Resource Indicators (URIs). In addition, a set of commands or standard HTTP ”methods” are being used [6]. A significant facet of this paradigm is that REST is stateless and does not rely on previous messages. This allows for excellent scalability and distribution capabilities. Next, the most important ones are listed: •GET: used for fetching data from a server. It shall not change any data. •POST: used to send data to a server. •PUT: also used to send data to a server, but replacing existing data. •DELETE: used to remove data from a server In the introduction of this subsection, it was stated that NFs that send the request have the role of a Service Consumer, while the NFs that offer their service act as Service Producer. But a question arises, how do Service Consumers keep track of the functionalities of the Service Producers?. The answer to this matter relies on the concept of Service Discovery. A crucial NF, called Network Repository Function (NRF), is responsible for this task. Each Service Producer registers that its services are available interacting with the NRF, which implies that each NF needs to be configured with at least one NRF, but does not need connection to every NF in the architecture. To understand this concept, a flow example is described in the following paragraphs. For now, the details related to the NFs involved in the example do not matter as they are explained later in the document. 20 Figure 4: 5GC visualized with Service-Based interfaces [6]. 21 Figure 5: 5GC visualized with point-to-point interfaces [6] 22 In the next figure, another NF like the AMF is interested in the services the PCF offers. Hence, it queries the NRF for a list of PCFs that offer the desired service. Before this occurs, the PCF should have put its information in the NRF database. Highlighting once more, this procedure is carried out using HTTP commands. Figure 6: PCF Service Registration. Figure 7: AMF Service Discovery. At this point, the AMF has just received a list of PCFs that fulfill its query requirements, so it needs to contact the selected PCF with a Service Request. When the PCF receives the HTTP POST message from the AMF, it answers back with an HTTP RESPONSE containing the applicable policy requested by the AMF. This Service Request and the previous stages are gathered in the next figure 2. Figure 8: AMF Service Request and previous stages. 2 These procedures do not usually happen one after the other, but when certain circumstances are met. 23 4.1.1.3 Principal 5GC NFs The main functionality of the network is related to the following tasks: establishing secure sessions and forwarding user data to provide data connectivity. This responsibility must be in every 5G deployment and therefore, is related to the following NFs. Figure 9 illustrates the core of the 5GC. Figure 9: Simple 5GC version with obligatory components. Let us examine each NF one by one. Firstly, the AMF is the ”Access and Mobility Management Function”. This NF interacts with both the radio network and devices and with all other NFs. It communicates with the radio network and devices through signaling over the N2 and N1 interfaces, while the communication between NFs is based on Service-Based interfaces. This NF is involved in a major part of the network signaling and allows device registration, authentication and movement between radio cells. However, this function does not perform the authentication of the device by itself, but rather consumes this service from the AUSF. The SMF is the ”Session Management Function” and is in charge of managing enduser sessions. This includes the establishment, modification, and release of user sessions and allocation of IP addresses. On the one hand, the AMF forwards session-related messages between the devices and the SMFs. On the other hand, it also interacts with other NFs by producing and consuming services. Additionally, it selects and controls different UPFs over the N4 interface for the configuration of traffic steering in the UPF for each individual session. If that was not enough, the SMF is also in charge of all charging-related functionalities in the network and Policy Control of user sessions 3. 3 For this matter it interacts with the Policy Control Function (PCF), a key NF responsible for policy rules related to QoS, network access and user data flow. 24 4.1.1.7 NR air interface The next figure shows the protocol stack used for the NR air interface between the devices and the base stations. Figure 17: Air interface protocol stack. Let us examine each layer one by one. Firstly, PHY is the Physical Layer, this is the lowest layer in the protocol stack. This layer is in charge of transporting of data bits between devices and radio base stations. The radio transmission is realized over the radio channels using OFDM modulation and FDD/TDD multiplexing schemes. OFDM is a modulation technology that is convenient to meet 5G requirements and incredibly robust against multipath fading. Basically, OFDM divides the total available radio spectrum into several subchannels, each carrying a subcarrier. The capacities of each device varies based on their needs; therefore resources must be flexibly allocated and can be controlled in both time and frequency. The frequency allocation changes for every time slot considering that the number of assigned subcarriers might change depending on the device. A simple version, with a reduced number of subcarriers, of this resource allocation concept is shown in the next figure. Figure 18: Resource allocation for three different devices. 31 On the one hand, TDD is short for Time-Division Duplex and allows the device and base station to share the same frequency. In order to avoid interference, they transmit data at different time slots in a synchronized way. On the other hand, FDD stands for Frequency Division Duplex and means that the device and the base station use different frequencies for their transmissions. As a consequence of the regulatory situation, FDD is only supported on Mid/Low bands, not on High bands. Following the protocol stack, MAC is the Medium Access Control Layer and is used for the transport of signaling information and user data. This layer is divided into various logical channels, each with a different purpose, e.g. access requests, information broadcasting, and data transfers. It also provides support for multiplexing data from these logical channels into a single PHY transport service. RLC is the Radio Link Control protocol layer. It provides a reliable transport service and supports the transmission of signaling information or user data using three different modes: • Transparent Mode (TM). Only provides buffering of packets and does not support reception feedback. • Unacknowledged Mode (UM). Works in a similar way to TM, but also supports packet segmentation before transmission. • Acknowledged Mode (AM). Fully supports reception feedback and retransmission if needed. On top of RLC, PDCP (Packet Data Convergence Protocol) is used. Encrypts user data and signaling, and provides optional header compression of user data to improve channel performance. Additionally, it also reorders packets that might have arrived in the wrong order. At this point, the stack is different for user data and for signaling. Radio Resource Control (RRC) is the highest protocol in the stack for carrying signaling data. Some of the high-level signaling features between the network and devices include broadcasting of system information, delivery of encryption keys, mobility signaling, or management of radio bearers. It is also in charge of transparently carrying the aforementioned NAS messages between the CN and the devices over the N1 interface. Regarding the user data, Service Data Adaptation Protocol (SDAP) is used. This protocol is able to ensure proper QoS by mapping downlink QoS marked packets towards the correct radio bearer. Additionally, SDAP checks the correct QoS class marking of packets received from the devices, before sending them to the UPF. Before delving into the study of broadcast networks, this work will provide a concise overview of the key features present in each iteration of the 5G standard. 32 4.1.2 Key features of every 5G Release In the introduction of this document, a brief explanation was presented to elaborate on certain features introduced in each 5G Release. The aim of this section is to further elaborate those concepts and provide a more comprehensive understanding of the fundamental principles. 4.1.2.1 Release 15 As it was previously mentioned, Phase 1, or Rel’ 15, was the first version of the new generation that was designed to cover three classes of use cases: enhanced Mobile BroadBand (eMBB), massive Machine-Type Communications (mMTC), and Ultra-Reliable and Low-Latency Communication (URLLC). However, the initial focus in Rel’ 15 was mainly on eMBB. eMBB traffic can be considered to be a direct extension of the 4G broadband service. It is characterized by large payloads and by a device activation pattern that remains stable over an extended time. This pattern allows the radio scheduler to allocate resources for just one eMBB device, in order not to have two eMBB devices sharing resources at the same time. eMBB service has to maximize data rate while guaranteeing a certain reliability degree and a minimum packet error rate (PER) [11]. eMBB targets large-scale events and tight metropolitan areas that have high data rate requirements but restricted bandwidth. Some examples of these applications include 4K video streaming, cloud applications or enhanced navigation [12]. 4.1.2.2 Release 16 Rel’16, which commenced in early 2018, mainly incorporated enhancements for the remaining two use cases within the 5G family: mMTC and URLLC. URLLC provides real-time services for mission-critical scenarios requiring a response time of less than 1ms. Some of the use cases covered by URLLC are robotic control-based industrial automation, autonomous driving or remote surgery [12]. mMTC refers to the capability of 5G networks to efficiently handle a massive number of devices. Some key points of this use case are massive device connectivity, low power and data rates, efficient signaling, and massive coverage. In summary, mMTC is a critical enabler for an Internet of Things (IoT) system, where the number of devices and communications is incredibly large. However, related to the multimedia streaming field the greatest addition was the deployment of the new SDAP protocol. This framework aligned the current media distribution practices with 5G Systems (5GS), exposing the 5G infrastructure for Mobile Network Operators (MNOs) streaming services and third-party services. The goal was to address the challenges related to media streaming, including the quality of experience of UEs, coping with increasing quality demands, new formats petitions, and immersive aspects of the experience. 33 As it was previously mentioned, the main function of this user plane protocol is to establish a mapping between a QoS flow and a DRB. Data is transmitted on a per-DRB basis over the air interface, while a more sophisticated QoS flow structure is implemented within the NR CN [13]. Figure 19 illustrates the SDAP structure. Figure 19: SDAP protocol structure [13]. As it can be seen in the previous figure, the UE can be configured with multiple SDAP entities, and each SDAP corresponds to a PDU session. At the same time, a PDU corresponds to the data of one or more QoS flows. In uplink, when the UE receives the SDAP SDU from the upper layer, it follows a mapping rule to map each QoS flow to the corresponding DRB. Then, the UE generates an SDAP PDU based on the network configuration and sends it to the lower layer. For downlink data, the UE undertakes a sequence of actions on the SDAP PDU received from the lower layer, following the configuration provided by the SDAP header before removing it. If the data is configured without a header, it can be directly sent to the upper layer. 4.1.2.3 Release 17 Rel’ 17 brings Multicast-Broadcast Services (MBS) to the 5GS [14]. Regarding the requirements set by either the service provider or network operators, MBS allows to selection of the most suitable among point-to-multipoint (PTM) or point-to-point (PTP) delivery methods. The content is delivered from a single origin server to terminals that have previously subscribed to the MBS service. Multicast traffic is characterized by being efficiently and reliably transported over the 5GC to the compatible gNBs. Additionally, these base stations are capable of deciding whether to use PTM or PTP methods at the RAN based on the number of subscriptions. If the gNB in question did not support MBS, the individual traffic would be delivered using unicast. 34 Figure 20: 5G Multicast traffic example. Broadcast traffic is only delivered using the PTM method to transport traffic from a single source to multiple devices registered to the service within a broadcast area. In this case, a single copy of the MBS traffic is transported over the 5GC to each compatible base station. Figure 21: 5G Broadcast traffic example. In conclusion, MBS User Services allow popular online television and radio services to be delivered efficiently to compatible equipment like smartphones, smart TVs, or car entertainment systems. While broadcast is more suitable for localized services in individual cells, multicast allows a scalable delivery of services while ensuring a similar QoS and reliability when compared to unicast transmissions. 35 4.2 Broadcast Networks Over the last decade, the broadcast networks, which have traditionally been the primary delivery mechanism for PTM services, have faced significant challenges. Firstly, these challenges arise from regulatory and spectrum issues; secondly, as a result of the rising competition from other actors within the media industry. Not only that, but nowadays viewers demand higher quality and more personalized services, including the likes of OTT services. For this reason, the industry has transitioned into an IP-based IT infrastructure. Significant endeavors have transpired to shift from traditional DTT systems. In this context, ATSC 3.0 emerged as the first IP-based DTT standard, offering a robust pathway for the development of a convergent architecture with other broadband IP networks, such as 5G. These reasons and the fact that the research group had already developed ATSC 3.0 solutions for different projects were the motivations for selecting this standard. Therefore, the focus for this part of the study is set on understanding the ATSC 3.0 standard and the technical concepts behind those projects, in order to incorporate them into this work. 4.2.1 ATSC 3.0 ATSC 3.0 is a set of technical Standards and Recommended Practices that are fundamentally different from predecessor systems. This differentiation from previous designs and the fact that backward compatibility was not considered allows for significant improvements in performance, functionality, and efficiency. While IP transport remains a central feature, the standard has also proved to be able to cope with higher capacity to deliver Ultra-High-Definition (UHD) services, robust reception on a wide range of devices, and advanced emergency messaging. Additionally, the use of an IP stack allows the implementation of hybrid services (broadcast and broadband) that are based on different protocols like ROUTE, MMT, HTTP, or DASH. The ATSC 3.0 standard is designed following a layered architecture. As shown in the following picture, three layers are defined: Physical,Management and Protocols, and Application and Presentation. In order to facilitate flexibility, the different elements that encompass this system are specified in separate standards. Figure 22: ATSC 3.0 layered structure. Each ATSC 3.0 standard is designed in a flexible way so it can accommodate future adaptations. In some cases, parallel options are specified for certain operations, from which broadcasters can choose which method is more suitable for each project. Figure 23 36 is an illustration gathering the various documents that together comprise the standard and the topics to which they belong. Figure 23: ATSC 3.0 documents structure. 4.2.1.1 Service Delivery Following the A/331 ”Signaling, Delivery, Synchronization and Error Protection” standard [15], two methods of Broadcast Service delivery are specified in the standard. The method on the left side of Figure 2, is based on MPEG Media Transport (MMT) and uses MMT Protocol (MMTP) to deliver Media Processing Units (MPUs). This project centers its attention on the method depicted in the center of Figure 2, which is rooted in the DASH-IF profile—a framework built upon the foundation of MPEG DASH. It uses Real-Time Object Delivery over Unidirectional Transport (ROUTE) protocol to deliver DASH segments. For the delivery of hybrid service on the broadband side, DASH-IF utilizes the HTTP/TCP/IP stack. ATSC 3.0 services are delivered using three functional layers: The physical Layer, the Delivery Layer, and the Service Management Layer. The Physical Layer facilitates the transportation of signaling, service announcement and IP packet streams over the Broadcast Physical Layer and/or Broadband Physical Layer. The Delivery Layer is responsible for the transportation functionality of objects and object flows. This layer is enabled by the ROUTE protocol, operating on top of a UDP/IP multicast stack over 37 the Broadcast Physical Layer, and enabled by the HTTP protocol on a TCP/IP unicast over the Broadband Physical Layer. The main role of the Service Management layer is to facilitate the discovery and acquisition of various types of services, like linear TV or HTML5 applications. These services are carried by the underlying Delivery and Physical layers. Figure 24 shows the ATSC 3.0 receiver protocol stack 4. Figure 24: ATSC 3.0 receiver protocol stack. Let us delve deeper into the underlying concepts of this architecture. Service Signaling provides service discovery and description information, and consists of two functional elements: Bootstrap Signaling via the Service List Table (SLT) and Service Layer Signaling (SLS). For a receiver that is encountering the broadcast for the first time, the SLT is the place to start. The SLT facilitates a quick channel scan, enabling the receiver to compile a list of all available services, with their name, channel number and more. Additionally, the SLT offers bootstrap information that aids the receiver in identifying the SLS for each service. In the case of ROUTE/DASH services, the bootstrap information provides a source IP address, destination IP address, and the destination port of the LCT channel that carries the ROUTE-specific SLS. In the context of service delivery via ROUTE, the SLS for each service describes characteristics of the service, such as a list of its components and how to access them, as well as the receiver capabilities necessary for a meaningful presentation of the service. Using distinct service signaling for each service allows a receiver to obtain the desired SLS for a particular service without analyzing the entire SLS carried within a Broadcast Stream. Regarding ROUTE/DASH broadcast services, the SLS is conveyed either using a Signaling Server or through ROUTE/UDP/IP within one of the LCT (Layered Coding Transport) transport channels forming a ROUTE session. The next figure shows the relationship of these logical entities in a UML diagram. Every ROUTE session consists of one or more LCT channels that collectively or partially transport the components forming the ATSC 3.0 service. For streaming service 4 Note that the MMTP part of this stack is illustrated with reduced transparency as it is not utilized in this project. 38 Figure 25: UML Diagram. delivery, an LCT channel might carry an individual component of a user service, such as audio, video, or closed caption. Streaming media is organized into DASH Segments. A Broadcast Stream is a conceptual representation of an RF channel, characterized by a carrier frequency situated within a designated bandwidth. It is uniquely identified by its [geographic area, frequency] pair. A Physical Layer Pipe (PLP) corresponds to a segment of the RF channel. Each PLP is associated with specific modulation and coding parameters. In a Broadcast Stream, there are a certain number of ”groups”. It refers to an abstraction of ”broadcaster” or station and each service in a Broadcast Stream is associated with a single group value (LLS group id). This concept allows multiple stations to operate on a single RF channel with a certain degree of independence. Signaling information carried in the payload of IP packets with a well-known address/port dedicated to this endeavor is referred to as Low Level Signaling (LLS). The SLT itself, which has been discussed earlier, serves as an example of LLS information, in the form of an LLS Table. These packets shall be transmitted using the 224.0.23.60 IP address and the 4937 UDP port. All IP packets, except for LLS IP packets, shall carry a unique and reserved Destination IP address allocated by a mechanism or in the range of 239.255.0.0 - 239.255.255.255. SLTs must be transmitted within their LLS every 5 seconds but can be repeated more frequently, ideally every second, to speed up receiver channel scanning. In conclusion of the service delivery section, it is noteworthy to mention that SLS signaling supports the delivery of service components in multiple PLPs. For example, a service could be configured to carry video in one PLP and audio in a different, more robust, PLP. Regarding some limitations in certain receivers, components of any given service should be conveyed through a maximum of four ALP packet streams, which includes the ALP stream carrying the LLS tables that describe that particular service. The figure below 5 demonstrates how a robust audio service is structured using one PLP/ALP stream for each ROUTE session. This service employs two different Quality of Service (QoS) levels. The first, which is more resilient, handles both signaling and audio 5 Each LCT channel is distinguished by a Transport Session Identifier (TSI), and this identifier is unique within the context of the parent ROUTE session. 39 within a single ROUTE session. The second QoS, which is less robust, is responsible for delivering video and text, like closed-captioning, in a separate ROUTE session. Figure 26: Example of separate ROUTE sessions/PLPs to differentiate QoS for video and audio. 4.3 Convergence between Broadcast and Broadband systems After studying both systems and their respective standards, the final endeavor is to comprehend the initiatives aimed at achieving harmonization and convergence between these two architectures. The references compiled in [16] provide a great starting point to highlight the benefits of convergence and to list the contributions in this field. As previously mentioned, the fully-IP-compliant design of ATSC 3.0 facilitates convergence between Broadcast and Broadband in various system layers, not limited to just the application/presentation layer. This implies that traffic offloading and tower sharing are feasible through the convergence at the transportation and physical layers, respectively. One of the key features of the media and entertainment industries is user interactivity. The most outstanding example of interactivity in Broadband media services is a customized content distribution model, referred to as narrowcasting. Nonetheless, in the era of convergence, media broadcasting will thrive through interactions between different platforms and systems, placing greater emphasis on this kind of interactivity rather than user-interactivity. Additional convergence benefits can be discussed as follows: • Enhanced Quality. Delivering 4K/8K UHD video, high-dynamic range (HDR), or wide color gamut (WCG) is possible with a multi-connectivity scheme that 40 Sets and other parameters like the availability start time or maximum segment duration. This information is used to create the SLS within the Transmit section. Additionally, it can be seen some ROUTE session-related parameters like the multicast address:port pair, or the LCT channel, are all encapsulated within the S-TSID. For the transmitter component, the DekTec DTU-315 modulator is employed. This USB modulator is a portable device capable of operating from VHF to L band (36 MHz - 2150 MHz). It supports all constellations and modulation modes for each supported standard while delivering excellent signal quality for the RF output signal. In conclusion, it aligns perfectly with the project’s requirements as it is compatible with ATSC 3.0, in addition to its outstanding RF characteristics. Figure 30: DekTec DTU-315 Modulator. For the receiver component, the DekTec DTA-2131 is employed. Unlike the DTU-315 modulator, this receiver utilizes a PCIe interface instead of USB 3.0. It is also compliant with ATSC 3.0 standards and optimized for integration with Software Defined Radio (SDR) technology. Consequently, it has the capability to forward ATSC 3.0 packets to IP. Furthermore, this product is bundled with the Atsc3Xpert software, offering advanced RF measurements, decoding of all signaling information, and features such as the recording of PLP data in PCAP files, as well as real-time ALP and ROUTE/MMT output over IP. Figure 31: DekTec DTA-2131 Receiver. 47 Figure 32: Triveni GuideBuilder MPD Injest. Figure 33: Triveni GuideBuilder ROUTE Transmit. 48 5.4 Phase 4: Design and Implementation of a Convergent Architecture between ATSC and 5G Once the performance of both prototypes has been separately tested, the design and implementation of a convergent architecture shall begin. However, an important question has to be addressed first: where in the protocol stack should the project focus on implementing convergence? Retrospectively reviewing the State of the Art, it is evident that the most interesting type of convergence that suits the project resides at IP level. Therefore, the efforts of this phase should be focused on developing this concept. The convergence case explored in this project is related to providing video streaming service to the end user in such a way that even in the presence of failures in the broadband network, the same service continues to be delivered through the DTT network. Once again, as mentioned in the previous phase, the technical details of the final prototype’s operation will be elucidated in the corresponding section. However, let us take a closer look at what needs to be developed in this phase. The 5GC shall conduct a bitrate analysis of the end user device and, based on the results, prepare the DTT transmitter to broadcast the video when the necessities for that particular service are not met. The end user should remain unaware of this process. However, given the project’s scope, it is not feasible to develop a top-layer application that handles these procedures and plays the video regardless of the network to which it is connected, as that would require a very precise synchronization scheme between both networks. For this reason, this project aims at offering the service under the aforementioned conditions but being fully aware that a separate application is required to play the video (e.g., VLC, StreamXpert, or an ATSC 3.0 compliant receiver connected to a TV). Regarding the analysis performed by the 5GC, an interactive Python web application has been deployed on the CN to monitor the activity of the broadband network. Furthermore, its interactivity enables various actions to be performed directly on the network, such as introducing delay, changing the maximum available link bitrate, or adjusting the packet loss percentage. It also enables remote interaction with the ATSC 3.0 network, achieving a certain level of cooperation between both networks. This harmonization allows the remote control of the DTT transmitter directly from the 5GC. The software represents the pinnacle of this work and will assist in future research projects as it sets a precedent in the context of interaction between 5G and DTT networks. 5.5 Phase 5: Simulation and analysis of convergent use cases The convergent architecture is employed in the final phase to test and analyze convergent use cases. One of the primary objectives of these simulations is to empirically determine, based on network conditions, the optimal trigger point for switching to the ATSC network. During stress tests related to these use cases, the network exhibits patterns that could eventually facilitate automated detection of suboptimal service delivery in the broadband network. However, at this time, this determination, which directly impacts end-user QoE, remains non-automated and requires a series of manual tests. 49 For this phase, the following use cases have been analyzed: • Effect of mobility in the cell on multimedia streaming. Increasing the distance between the base station and the end user results in a bitrate reduction, subsequently impacting the streaming service. As a user progressively moves away from the base station, several factors that affect the connection quality and data transfer speed may come into play, such as signal attenuation, modulation scheme changes, or resource reallocation. Ultimately, the distance between the user and the base station can significantly influence the bitrate due to these effects. For the simulation in this section, the maximum bitrate of the mobile network is gradually reduced to analyze the bitrate pattern and the application (VLC) behavior under these conditions. This allows for the determination of when to switch to the DTT network. • Effect of delay on multimedia streaming. Increasing delay and its variation, also known as jitter, results in a series of effects and impacts on the streaming service. Delay refers to the time it takes for information to travel from the streaming server to the smartphone. It can occur at different points in the network and may be influenced by factors such as propagation time through a physical medium or the processing time required to transmit bits over a link. On the other hand, jitter refers to the variation in delay experienced by data packets. They may encounter different delays even when sent at different time intervals. Additionally, traffic fluctuations contribute to these variations. In essence, both delay and jitter impact the network and, consequently, the streaming service. In simulation tests, the bitrate has been progressively increased until reaching a fixed point. Once that fixed point was reached, the jitter was modified, resulting in a different network behavior. 50 6 Architectures for 5GS and Evaluation Procedure This section aims to explain the architecture for studying the DASH data delivery over a 5G system, focusing on some key aspects of the solution, such as the designed architectures or the logging tool. 6.1 A Approach This prototype represents a significant contribution to the hosting research group as it enables the deployment of a private 5G network in the laboratory for testing and developing different research projects, not limited to this streaming service. The availability of a 5G testbed for conducting diverse experiments paves the way for various research projects of interest. This being said, let us begin with the explanation. The primary objective is to ensure the correct operation of the system, ensuring that end users receive the video streaming service as intended. Therefore, the first step is to design the architecture, keeping in mind that the DASH multimedia server should be accessible from the 5GC and, thus, for the users within the 5G network. As was previously mentioned in 5.2, in the first approach, this prototype was meant to work with just a smartphone connected to the 5G network. Fig. 34 illustrates the initial architecture design7. Figure 34: Initial 5G architecture design. However, this design was limited by the hardware available at that stage. The main problem was that the smartphone intended to receive the streaming service could not connect to the 5G network. To address this issue, different alternatives were considered. 6.1.1 Troubleshooting First, it was contemplated that some incompatibilities between radio technology and the smartphone could exist. Therefore, parameters like the frequency band or the power/gain were evaluated and modified accordingly. Nonetheless, the user terminal and the 5GS operated in the n78 NR band at 3489 MHz. Additionally, considering the Amari Callbox user manual, the signal power level indicated that the power and gain were appropriate for correct signal reception. 7The IP address of the UE is allocated by the AMF in the 5GC. 51 The next step was to consider the possibility of issues within the 5GC. In this context, the logging tool Amarisoft provided was helpful. Its web user interface allows for examining message exchanges within the NR air interface and the NAS message interactions among the 5GC entities. While Figure 35 illustrates a part of a successful example of a 5G SA network connection from the UE, Figure 36 shows the IP address allocation in the PDU Session Establishment Accept message. This message, which is typically sent by the AMF to the UE, is part of the 5G session management procedures and is used to confirm the establishment of a PDU session for data communication between the UE and the 5GC. It contains important information like the allocated IP address and IPv4 (IPv6 if supported) DNS Server address. Figure 35: 5G SA Successful Registration Process. 52 Figure 36: PDU Session Establishment Accept message and allocated IP addresses. So, using this tool makes it possible to check the process behind the network connection attempt from the UE. 1. RACH Process. RACH stands for Random Access Channel and is essential to wireless communication systems, not limited to 5G. It plays a significant role in establishing an initial connection between the UE and the network. In this context, it is utilized by a UE to acquire uplink synchronization and to obtain the specified ID for the radio access communication. 2. RRC Setup Request. When the RACH process is complete, the UE generates an RRC Setup Request message, which includes essential information such as its identity, capabilities, and requested services. It is transmitted to the gNB, which then processes the request to authenticate the user and determine the appropriate radio resources. 3. [NAS] UL 5GMM: Authentication Response. If the authentication process was successful on the UE side, this message should be on the message interchange graph. A usual failure in this process implies that there is a SIM parameter mismatch between the USIM and gNB parameters. 4. After this security control, the following messages should appear: 53 •[NAS] UL 5GMM: Security mode complete. NAS Security is complete. • UL DCCH-NR: Security mode complete. This shows that RRC Security is complete. • UL DCCH-NR: RRC Reconfiguration complete. This message implies that RRC Reconfiguration is complete and the physical pipe for communication is setup. • [NAS] UL 5GMM: Registration complete. This shows that the initial attach process is complete. 5. Finally, the PDU Session establishment Request/Response message. As mentioned earlier, this message is used, among other things, to allocate an IP address to the UE and provide it with a list of DNS servers. However, at this point, the device fails to connect with the Internet or the UPV/EHU network as it is not assigned any IP address. While it successfully accessed IMS services, it could not access any other IP network, rendering it practically unusable for this project. Hence, another design was proposed as a solution. . 6.2 B Approach The second design proposal shifted the end-user component of the architecture from a smartphone to a 5G router with known compatibility and performance on 5G SA networks. This paradigm shift opened up new possibilities for the project, enabling the use of computers as end devices. As a result, it allowed for the deployment of more ambitious programs, as the hardware limitations of smartphones were no longer a concern. The 5G router expands the 5G service to both WiFi and Ethernet connections, making it possible to connect a wide range of devices to the 5G network. The following picture illustrates the final fully functional architecture design. With this final setup, users of the WiFi/Ethernet network are able to receive the streaming content via 5G seamlessly. Figure 37: Final 5G architecture design. 54 6.2.1 Troubleshooting Unfortunately, just days prior to the scheduled lab tests, a malfunction was encountered with the 5G router. This necessitated the prompt resolution of the issue and the exploration of alternative solutions. Given the time constraints, creating an entirely new network architecture was deemed impractical, leading to the decision to revert to the initial design. Thorough consideration had previously been given to various factors pertaining to radio issues, and an exhaustive evaluation confirmed the correctness of the 5GC configuration, as evidenced by the successful connection of the router to the network. Consequently, attention was directed towards the network configuration of the smartphone. Upon investigation, it was determined that the issue stemmed from an erroneous auto-configuration of the Access Point Name (APN) on the smartphone. A manual adjustment of the APN settings was undertaken to rectify the problem. The following figure depicts the correct APN configuration, highlighting the important information (Name, APN, and APN Type). Figure 38: APN Configuration. 55 The default configuration successfully connected to one of the available APNs in the 5GC, assigning the user the IP address 192.168.3.2 from the available range. This enabled seamless access to multimedia streaming services within the 5G network. Both architectural designs have their own advantages and drawbacks, as depicted in the table below. To address the issue of requiring two end-user devices or a router in between, the Quectel 5G-M2 EVB Kit was suggested as an ideal solution. This development kit allows for the management of a broader range of 5G-related parameters compared to a commercial device like a smartphone. Furthermore, it is controlled from a computer, eliminating the need for two end-user devices. However, this option has been reserved for future work due to the project’s scope. Table 3: Advantages of using a smartphone or a 5G router. Figure 39: Quectel 5G-M2 EVB Kit. 56 8 Architectures for a Convergent System and Evaluation Procedure This final technical section of the document aims to provide a comprehensive explanation of the convergent prototype. After studying the two preceding prototypes independently, it is easier to understand the idea behind the final architecture. The primary objective of this design is the integration of both systems, with the 5GC assuming the role of the central entity responsible for both Radio Access Networks (RAN). Thus, granting access to streaming services to the users within the 5G network and establishing connections with the ATSC network. In this context, the transmitter can be managed to align content with metrics provided by the 5GC. Furthermore, the configuration of the receiver enables the selection of the RANs from which content will be received. The following figure illustrates the final design. Figure 47: Final convergent architecture design. Two DASH servers are depicted in the upper-left section of the figure above. One of these servers is linked to the EHU/UPV network to facilitate communication with the 5GC. In contrast, the other device is connected to a private LAN. This arrangement is due to the fact that the Triveni Guidebuilder is hosted on a Virtual Machine that is interconnected with this specific private LAN and can not have direct access to the public internet. The 5G system is illustrated in the figure’s upper-right section. In this version, three orange bars have been added to signify the analysis and monitoring of the bitrate in both the mobile broadband and the broadcast networks. Some purple lines have also been added to visualize the convergent communication between the 5GC and the transmitter and receiver modules of the DTT network. The DTT transmitter also uses this communication line to send the measured bitrate values to the 5GC. 63 8.1 KPI processing Let us delve deeper into the analysis and monitoring part of the architecture. Firstly, the bitrate analysis in the 5G network entails a series of actions. The Amarisoft software provides logs containing specific information about the communication between the base station and the user terminal, such as bitrate, MCS (Modulation and Coding Scheme), and SNR (signal-to-noise ratio), among others. This set of parameters proves highly valuable when conducting a mobile communication analysis. However, only the uplink and downlink bitrates are utilized for this initial convergent prototype developed within the project. The following figure provides an example of the logs mentioned. Figure 48: Amarisoft log example. Regrettably, direct plotting of this log information is not feasible, necessitating the implementation of additional processing steps. This procedure is an integral part of the software developed for this project and encompasses the following aspects: • Processing the log files to generate pairs of timestamps and bitrates. The inclusion of a time axis enhances the clarity of the result presentation. The following script utilizes the awk command to manipulate the screenlog output and then flush the result into a final file. #!/bin/sh tail −f screenlog.1 |awk '{print strftime("%H:%M:%S"),$0; ... fflush();}'|tee SCREEN.txt Figure 49: Processed Amarisoft log example. 64 • Once the log file is processed, it is possible to remove all headers and extraneous information that are irrelevant to this project, such as UE-ID, CL, RNTI, or —-DL—- headers. The following Python code reads the processed file and appends the desired lines to an array processed in the next step. def get lines(): ## Process the file and returns array of lines with just numbers. ## Skips lines containing "DL" or "UE−ID". try: with open("SCREEN.txt",'r')asfile: array = [] lines = file.readlines() for line in lines: if not "DL" in line: if not "UE ID" in line: if not "PRACH" in line: if not "[stopped]" in line: array.append(line) return array except FileNotFoundError: print("File not found.") except IOError: print("Error reading the file.") • At this point, the array contains only the essential information. Among all the parameters in the log, this project focuses solely on bitrate values. Therefore, the following functions return those values and perform a type casting into numerical values for their representation. def get bitrate(lines,ch=None): ## Gets the processed lines as an input and returns just the ... bitrate value. ## It it possible to select DL or UL for bitrate values. split = [] date = [] bitrate = [] for iin lines: split.append(str.split(i)) if ch == "DL": for iin split: date.append(i[0]) bitrate.append(i[10]) if ch == "UL": for iin split: date.append(i[0]) bitrate.append(i[18]) return bitrate,date 65 def proc numeric(bitrate): ## Processes the values so it changes kilo into base unit, mega ... into base unit... processed = [] for value in bitrate: if value[−1] == 'k': num = round(float(value[:−1]),2) elif value[−1] == 'M': num = round(float(value[:−1]) *1000,2) else: num = float(value) / 1000 processed.append(num) return processed • Finally, after the preceding steps, the values can be represented in a chart. To achieve this, the following code has been utilized. def load chart(width, height, processed, user colour, timeStrings, ... slider): # Create a DataFrame with the index as datetime objects time objects = pd.to datetime(timeStrings, format="%H:%M:%S") data = pd.DataFrame({'Bitrate (kbps)': processed},... index=time objects) line chart = alt.Chart(data.reset index()).mark line( color=user colour, strokeWidth=slider, ).encode( x=alt.X('index:T', title='Time',... axis=alt.Axis(format="%M:%S",grid=True)), y=alt.Y('Bitrate (kbps):Q', title='Bitrate (kbps)'), ).properties( width=width, height=height ) return line chart 9 Results and Discussions The previous procedure enables analyzing and monitoring 5G uplink and downlink bitrates. This process identifies when the streaming service is affected by network-related problems. It is conceivable that these issues may lead to a bitrate reduction, directly impacting the service and QoE. The developed software analyzes the cell’s bitrate and acts accordingly when specific conditions are met. However, these conditions vary depending on the video requested by the user. In this project, the user requested a video sample with a mean bitrate value of approximately 2.8 Mbps. This test was conducted utilizing the second architecture model for 5G (Fig. 37), and the measured values served as a threshold to determine 66 when the service may encounter issues. The figure below illustrates the bitrate values obtained during a 1.5-minute analysis for this video, establishing the threshold. Actually, considering that this is the mean value of that list, it would be a better choice to employ a slightly lower threshold. Consequently, if bitrate values remain below that threshold for a certain period (this allows to ignore network spikes), it would be possible to determine that the service is being directly affected. Figure 50: DL bitrate values for the sample video. However, as previously mentioned, the 5G router started malfunctioning, and the smartphone had to be used instead. While the obtained results proved to be helpful, in order to determine the ATSC Switching Point more accurately, additional tests were carried out to analyze the behavior of the network under specific conditions. These conditions are directly related to the use cases explained in the Methodology (see 5.5). 9.1 UE Mobility and QoE degradation Mobility, and more precisely, an increasing distance between the base station and the end-user, directly impacts the bitrate. As a user moves further away from the base station, various factors that influence the quality of the connection and the speed of data transfer may arise. These factors affect the QoE for the requested streaming service and are a typical problem in the edges of the coverage areas. In this test, this behavior is modeled by analyzing the impact of gradually limiting the maximum bitrate that the 5G link can offer. We are trying to emulate a CQI degradation. The following script is executed at regular intervals, approximately every 30 seconds, to evaluate the application’s performance on the user terminal to accomplish this objective. During the initial execution of the script, the add option must be utilized, followed by the desired maximum bitrate. Subsequent tests will employ the change option, again followed by the desired bitrate. 67 #!/bin/bash if [[ "$1" == 'add' ]] then tc qdisc add dev tun1 root handle 1:0 htb default 1 tc class add dev tun1 parent 1:0 classid 1:1 htb rate "$2"kbit elif [[ "$1" == 'change' ]] then echo You changed the bitrate to "$2" kbits tc class change dev tun1 parent 1:0 classid 1:1 htb rate ... "$2"kbit fi The first tests aimed to determine the ATSC Switching Point, so these results do not show any ATSC 3.0 bitrate yet. The starting point was set at 3000 Kbps and gradually reduced until 2400 Kbps were reached. It is worth mentioning that the stopping point for the bitrate reduction is produced because the application starts malfunctioning and some video artifacts start to appear, around 2500 - 2400 Kbps. These artifacts are visual errors that affect the video. In some cases, they are related to video stalling, which is the case study of this project, and in other cases, they are related to blurry frames. The following results are promising and will pave the way for precisely determining the switching point, besides acknowledging different network and application behaviors. Figure 51: Bitrate downgrade Test I. 68 Figure 52: Bitrate downgrade Test II. From the preceding figures, a substantial amount of information can be derived. Regarding the first test (Fig 51), two completely different approaches can be seen. During the ”no bitrate limitation” period, the device had no limitation in requesting video segments. Hence, without limitations, the application operated at high performance, filling the buffer and requesting large quantities of bits. This is why great variation in bitrate can be observed during this period. On the contrary, the behavior is totally different when the available bitrate is limited. Under these conditions, the application could no longer request such high bitrates and tried to efficiently manage the buffer and play the content seamlessly. Thus, the bitrate variation is directly limited to the bitrate limit. Aside from the bitrate behavior, this test provided a first concept of the relationship between the buffer management and the artifacts. It is possible to see that when the bitrate remained under certain values (around 2500 Kbps) for a period of time, the artifacts started to happen. Therefore, it can be determined that when the bitrate falls below the threshold value for a certain duration, various behaviors of the application lead to a common outcome: artifacts. In this case, the application tried to play the content while buffering, resulting in two stalling moments which are depicted above. VLC shows a rotating cone in the application during these moments. Figure 53: VLC Stalling. 69 Fig 52 shows a very similar behavior, resulting in three artifacts during this test. Both results allow the determination of a threshold of approximately 2500 Kbps for the ATSC Switching Point for this use case. Understanding the switching point enables the execution of the final convergence tests, as it becomes feasible to perform network transitions when the 5G network meets these conditions. The results obtained during these convergence tests are depicted below. Figure 54: Use Case Analysis - Bitrate Downgrade (Kbps), Test I. Figure 55: Use Case Analysis - Bitrate Downgrade (Kbps), Test II. Both figures exhibit highly similar outcomes concerning their relationship with the switching point. In both instances, remaining below the threshold value for a specific duration without possessing sufficient buffer capacity for content playback yields specific artifacts and triggers the subsequent switch to the DTT network. However, an important conclusion drawn from the comparison between both sets of results is that artifacts are not 70 solely associated with steep bitrate drops, as the initial results had indicated. Therefore, it is possible for artifacts to manifest even in the absence of such drops, highlighting a direct correlation with the buffer’s capacity. It is also worth mentioning the behavior of the application in Fig 54. In this instance, despite no prior bitrate drops, the application, due to inadequate buffering, opts to cease streaming entirely. This leads to the device entering an atypical state associated with the valley until the next data peak. Furthermore, the network transition must be executed swiftly to minimize the impact on Quality of Experience (QoE). To illustrate this transition, the times when the 5G service is lost and the shift to DTT occurs have been marked. 9.2 Delay and QoE Degradation Increasing delay and its fluctuation, often referred to as ”jitter”, result in many consequences and repercussions that substantially affect the performance of the streaming service. These significantly impact the QoE and may lead to a frustrated viewer, as prolonged buffering, interruptions, and poor quality may result in a decline in user satisfaction and engagement. Comprehending these consequences is crucial for enhancing the performance of streaming services. Granting a smooth user experience is mandatory, especially in scenarios where low latency and high quality are paramount. This delay increase is expected to be the outcome of an overloaded network, where multiple users are requesting high throughput video delivery simultaneously. This test aims to analyze the impact of artificially and gradually increasing the network delay on multimedia streaming services. First, the delay is increased gradually until a reasonable maximum value. Second, once this point is reached, the test moves to a second phase where the jitter impact is analyzed while keeping the delay constant. It is crucial to understand that modifying these parameters results in different behaviors and, consequently, diverse artifacts that affect the perceived quality by the user. The same temporal pattern as in the previous tests is followed for the simulations, increasing the delay every 30 seconds. That is to say, the delay is progressively increased up to a value of 100 ms. Subsequently, the jitter is adjusted up to a value of 50 ms. This combination (100 ms delay and 50 ms jitter) represents a critical point, forcing the tests to stop as the application’s behavior became exceedingly unstable. In a similar way to the previous test, the following commands are executed at the aforementioned time intervals: # The first value in ms is related to the delay, while the second # is related to the deviation (jitter) # The following is executed the first time to create the configuration tc qdisc add dev tun1 root hadle 1: netem delay 0ms 0ms # Execute this every 30 seconds with the desired values tc qdisc repalce dev tun1 root netem delay 20ms 10ms The obtained results, depicted in Fig 56, are of significant interest. It is important to note that there was no bitrate limitation in these tests, and the observed trends and patterns are directly linked to the application’s buffer management once again. 71 A downward trend in bitrate as network delay increases is shown during the early phase. In addition to the reduction in bitrate, there is also a noticeable decrease in its variation range. Similar to the previous case study, this behavior prevents the application from filling the buffer, resulting in artifacts. However, due to the absence of a bitrate limitation, the device can manage it and request resources, represented by the prominent peak of 8 Mbps in the center of the graph. Subsequently, the bitrate stabilizes at values close to the video’s mean bitrate (15:31:06, 2.8 Mbps). However, as jitter increases, the behavior becomes remarkably unstable and significantly deviates from what was observed in the initial phase. In this scenario, the increase in jitter is directly linked to an increase in bitrate variation, eventually becoming so unstable that very low values are reached. The buffer cannot load sufficient data, resulting in continuous artifacts that severely impact service quality. Given the application’s inability to recover, this juncture presents an ideal moment to trigger the transition to the ATSC network. Figure 56: Use Case Analysis - Delay/Jitter Introduction. 72