5G NR Modelling in MATLAB: Network Architecture, Protocols, and Physical Layer 9781032720753, 9781032736747, 9781003465393

Citation preview

5G NR Modelling in MATLAB® 5G is the fifth generation of wireless technology and NR stands for a new radio interface and radio access technology for cellular networks, i.e., a physical connection method for radio-based communication. It is a powerful platform that supports a wide range of services that includes enhanced mobile broadband, massive machinetype communication and ultra-reliability, and low latency covering several vertical industries such as e-health, transportation, energy, media, and factory automation. This book provides a detailed description of the fundamental aspects of 5G. It gives an in-depth coverage of the network architecture of 5G by considering both the network reference point architecture and the service-based architecture. It also describes all the user and control plane protocols including the standalone and nonstandalone architecture options. The radio access technologies such as the waveforms used in 5G, the multiaccess and duplexing techniques as well as the resource allocation schemes are treated in detail. Additionally, the physical layer signal processing blocks of 5G NR are covered in depth with elaborate numerical examples to illustrate the functioning of each block in the 5G downlink transmitter and receiver chain. The main originality of this book is the detailed illustration of the 5G NR preprocessing steps as well as MATLAB® simulation models with explanations of the codes to allow for a seamless understanding of the principles. In general, this book is meant for anyone with a basic engineering background who would be interested in acquiring a solid foundation in the fundamental concepts of 5G NR.

MATLAB® and Simulink® are trademarks of The MathWorks, Inc. and are used with permission. The MathWorks does not warrant the accuracy of the text or exercises in this book. This book’s use or discussion of MATLAB® or Simulink® software or related products does not constitute endorsement or sponsorship by The MathWorks of a particular pedagogical approach or particular use of the MATLAB® and Simulink® software. [First] edition published [2025] by CRC Press 2385 NW Executive Center Drive, Suite 320, Boca Raton FL 33431 and by CRC Press 4 Park Square, Milton Park, Abingdon, Oxon, OX14 4RN CRC Press is an imprint of Taylor & Francis Group, LLC © 2025 [Tulsi Pawan Fowdur, Madhavsingh Indoonundon, Dragorad A. Milovanovic, and Zoran S. Bojkovic] Reasonable efforts have been made to publish reliable data and information, but the author and publisher cannot assume responsibility for the validity of all materials or the consequences of their use. The authors and publishers have attempted to trace the copyright holders of all material reproduced in this publication and apologize to copyright holders if permission to publish in this form has not been obtained. If any copyright material has not been acknowledged please write and let us know so we may rectify in any future reprint. Except as permitted under U.S. Copyright Law, no part of this book may be reprinted, reproduced, transmitted, or utilized in any form by any electronic, mechanical, or other means, now known or hereafter invented, including photocopying, microfilming, and recording, or in any information storage or retrieval system, without written permission from the publishers. For permission to photocopy or use material electronically from this work, access www.copyright.com or contact the Copyright Clearance Center, Inc. (CCC), 222 Rosewood Drive, Danvers, MA 01923, 978-750-8400. For works that are not available on CCC please contact [email protected] Trademark notice: Product or corporate names may be trademarks or registered trademarks and are used only for identification and explanation without intent to infringe. ISBN: 9781032720753 (hbk) ISBN: 9781032736747 (pbk) ISBN: 9781003465393 (ebk) DOI: 10.1201/9781003465393 Typeset in Times by Deanta Global Publishing Services, Chennai, India

Contents Preface......................................................................................................................vii Authors.......................................................................................................................ix Chapter 1 Introduction........................................................................................... 1 1.1 1.2

5G Overview...............................................................................1 The Roadmap to 5G...................................................................3 1.2.1 A Brief History of the Evolution of Mobile Standards................................................................ 7 1.2.2 5G vs LTE Requirements and Performance Indicators..................................................................... 10 1.3 5G Technology Research and Innovations...............................24 1.3.1 3GPP Standardization Process.................................... 29 1.3.2 Support for Multimedia Applications......................... 42 1.3.3 Concluding Remarks and Further Study..................... 47 References........................................................................................... 48 Chapter 2 5G and LTE Network Architectures................................................... 51 2.1

LTE/4G Network Architecture................................................. 52 2.1.1 Evolved Packet System (EPS)..................................... 53 2.1.2 Evolved Universal Terrestrial Radio Access Network (E-UTRAN)................................................. 53 2.1.3 Evolved Packet Core (EPC)........................................ 59 2.2 LTE/4G Protocol Architecture................................................. 63 2.2.1 LTE Control Plane Protocol Stack..............................64 2.2.2 LTE User Plane Protocol Stack................................... 78 2.3 5G RAN and Network Reference Point Architecture..............80 2.3.1 5G RAN Network Architectures.................................80 2.3.2 5G Network Reference Point Architecture................. 83 References......................................................................................... 168 Chapter 3 5G Service-Based Architecture, Protocol Stack, and Interoperation.................................................................................... 175 3.1

5GC Service-Based Architecture........................................... 175 3.1.1 5G Core Packet Controller Services.......................... 182 3.1.2 5G Core Subscriber Management Services...............202 3.1.3 5G Core Policy Management Services...................... 217 3.1.4 5G Core Shared Environment Services.................... 218 3.1.5 5G Core Application and Network Exposure Services.....................................................................224 v

vi

Contents

3.1.6 5G Core Network Resource Management Services.............................................................. 228 3.1.7 5G Core Location Services....................................... 242 3.1.8 5G Core Signaling Services...................................... 247 3.2 5G Protocol Stack...................................................................248 3.2.1 Control Plane Protocol Stack....................................248 3.3 5G Non-Standalone and Standalone Architecture Options... 291 3.3.1 NR Architecture Options.......................................... 291 3.3.2 Migration Paths to 5G Standalone Architecture....... 298 References.........................................................................................302 Chapter 4 Physical Layer Processing with Numerical and MATLAB® Modeling...........................................................................................307 4.1

Transmitter Modeling.............................................................307 4.1.1 DLSCH Encoding.....................................................309 4.1.2 PDSCH Encoding...................................................... 333 4.1.3 Precoding.................................................................. 351 4.1.4 CP-OFDM................................................................. 353 4.1.5 Channel Model.......................................................... 367 4.2 Receiver Modeling................................................................. 372 4.2.1 Synchronization......................................................... 373 4.2.2 CP-OFDM Demodulation......................................... 375 4.2.3 Channel Estimation................................................... 377 4.2.4 PDSCH Decoding..................................................... 380 4.2.5 DLSCH Decoding..................................................... 387 References.........................................................................................400 Chapter 5 MATLAB® Simulation Model and Performance Analysis of 5G PDSCH..............................................................................................402 5.1 Simulation of 5G Processing Chain on MATLAB................402 5.2 Creation of 5G Model Simulator App on MATLAB............. 429 References......................................................................................... 434 Index....................................................................................................................... 437

Preface 5G is the fifth generation of cellular technology. It is designed to increase speed, reduce latency, and improve the flexibility of wireless services. 5G New Radio (NR) is the enabler of three key service classes: Enhanced Mobile Broadband (eMBB), Ultra-Reliable Low Latency Communications (URLLC), and Massive MachineType Communications (mMTC). The 5G network is expected to deliver a wide range of services that includes eMBB, mMTC, and URLLC. To realize such a diverse set of requirements, the 5G network has evolved as a multilayer network that uses various technological advances to offer an extensive range of wireless services. Several technologies, such as software-defined networking, network function virtualization, edge computing, cloud computing, and small cells, are being integrated into the 5G networks to fulfill the need for diverse requirements. This book provides a detailed description of the fundamental aspects of 5G. It gives an in-depth coverage of the network architecture of 5G by considering both the network reference point architecture and the service-based architecture. It also describes all the user and control plane protocols including the different standalone and non-standalone architecture options of 5G. The radio access technologies such as the waveforms used in 5G, the multiaccess and duplexing techniques as well as the resource allocation schemes are treated in detail. Additionally, the physical layer signal processing blocks of 5G NR are covered in depth with elaborate numerical examples to illustrate the functioning of each block in the 5G downlink transmitter and receiver chain. The MathWorks introduced MATLAB’s® 5G Toolbox which provides standardcompliant functions and examples for the simulation of the 5G environment. In this book, functions from the toolbox were used to build the 5G NR end-to-end physical layer model for Packet Data Shared Channel (PDSCH) processing and to calculate the PDSCH throughput, Bit Error Rate (BER), and Block Error Rate (BLER). Moreover, MATLAB models of each block have been used to simulate a complete 5G downlink system. A user-friendly Graphical User Interface (GUI)-based simulator has also been developed using MATLAB’s 5G Toolbox, so as to facilitate the physical layer simulation of 5G NR and generate performance results based on common metrics such as the bit error rate and throughput. The book is organized into five chapters. Chapter 1 presents a chronological evolution of mobile communications standards from 1G to 5G along with the proposed pathway to 6G by 2030. Chapter 2 gives a detailed analysis of the 5G and LTE network architectures with focus on the 5G core and network reference architecture. Chapter 3 elaborates on the software-based architecture of 5G, the 5G protocol stack, and the 5G non-standalone and standalone architecture options. Chapter 4 presents numerical and MATLAB modeling of both the downlink transmitter and receiver of the 5G NR physical layer blocks. Chapter 5 develops a complete userfriendly GUI-based MATLAB simulation to facilitate the simulation of both the downlink transmitters and receivers. vii

viii

Preface

MATLAB® is a registered trademark of The MathWorks, Inc. For product information, please contact: The MathWorks, Inc. 3 Apple Hill Drive Natick, MA 01760-2098 Tel: 508-647-7000 Fax: 508-647-7001 E-mail: info​@mathworks​.​com Web: http://www​.mathworks​.com

Authors Tulsi Pawan Fowdur received his BEng (Hons) degree in Electronic and Communication Engineering with first class honors from the University of Mauritius in 2004. He was also the recipient of a gold medal for having produced the best degree project at the Faculty of Engineering in 2004. In 2005 he obtained a full-time PhD scholarship from the Tertiary Education Commission of Mauritius and was awarded his PhD degree in Electrical and Electronic Engineering in 2010 by the University of Mauritius. He is also a registered chartered engineer of the Engineering Council of the UK, Fellow of the Institute of Telecommunications Professionals of the UK, and Senior Member of the IEEE. He joined the University of Mauritius as an academic in June 2009 and is presently an associate professor at the Department of Electrical and Electronic Engineering. His research interests include mobile and wireless communications, multimedia communications, networking and security, telecommunications applications development, Internet of Things, and AI. He has published several papers in these areas and is actively involved in research supervision, reviewing of papers, and organizing international conferences. Madhavsingh Indoonundon graduated with first-class honors, earning a BEng (Hons) degree in Electronics and Communications Engineering from the University of Mauritius in 2017. He was honored with a gold medal for presenting the top degree project at the Faculty of Engineering that same year. He is currently pursuing his PhD in Telecommunications Engineering at the University of Mauritius, supported by a scholarship from the Higher Education Commission of Mauritius. His research interests lie in channel coding, mobile communications, and artificial intelligence. He has contributed to the field through publications on channel coding in Wi-Fi and 5G NR wireless technologies in various international journals and conferences. Additionally, he has co-authored books within his research domain. Alongside his academic pursuits, he has been actively engaged as an engineer in the telecommunications industry since 2017, acquiring expertise in both Radio Access Networks and IP-based networks. Dragorad A. Milovanovic received the Dipl. Electr. Eng. and Magistar degree from the University of Belgrade, Serbia. From 1987 to 1991, he was a research assistant and PhD researcher from 1991 to 2001 at the Department of Electrical Engineering, where his interests include simulation and analysis of digital communications systems. He has been working as R&D engineer for DSP software development in the digital television industry. He also serves as an ICT lecturer and consultant in digital television and medicine/sports/arts informatics for implementation standard-based solutions. He participated in research/innovation projects and published more than 300 papers in international journals and conference proceedings. He has also coauthored textbooks/chapters in multimedia communications published by Prentice Hall (2002), Wiley (2005), CRC Press (2009, 2019, 2020), Springer-Verlag, and IGI ix

x

Authors

Global. Is present projects include adaptive coding of 3D video, QoE immersive media, IoMT and big media integration, and 5G/6G wireless technology. Zoran S. Bojkovic is full professor of Electrical Engineering at the University of Belgrade, Serbia, life senior member of IEEE, full member of Engineering Academy of Serbia, and member of the Scientific Society of Serbia. He was and still is a visiting professor worldwide. He is author and coeditor of more than 500 publications: monographs, books (Prentice-Hall, Wiley, McGraw Hill, Springer, CRC Press/Taylor & Francis Group, IGI GLOBAL, WSEAS Press), book chapters, peer-reviewed journals, conference and symposium papers. Some of the books have been translated in China, India, Canada, and Singapore. He has been a consultant to industry, research institutes, and academia worldwide. His research focuses on computer networks, multimedia communications, 3D video coding, smart grid, green communications, 5G, and beyond. He had plenary keynotes and invited talks at international conferences. He is a highly regarded expert in the IEEE, contributing to the growth of the communication industry and society reviewing process in many books and journals as well as organizing special sessions workshops and being general chair and Technical Programme Committee (TPC) member at numerous conferences all over the world.

1

Introduction

1.1 5G OVERVIEW The 5th-generation mobile network (5G) encompasses various requirements, standardized technical specifications, and a range of implementation options, all with a focus on services and users. In comparison to earlier generations, the network’s overall performance and capacity have greatly improved. 5G enables faster and improved access to mobile Internet, reliable and low-latency network response, and significantly enhanced connectivity for a mass of Internet of Things (IoT) devices. While wireless communications technologies evolve continuously, a new mobile generation typically emerges roughly every ten years [1, 2, 3]. In the technological advancement of the 5G 3rd Generation Partnership Project (3GPP) Releases 15, 16, and 17 unified platforms for innovations, the collaborative efforts of industry, and academia currently focus on the evolution of the 5G-Advanced Releases 18, 19, and 20. The work on Release 18 for several study items to enhance network capacity, latency, coverage, power efficiency, and mobility was initiated in 2022 and is projected to be finished by March 2024. While 3GPP’s technical team is working on Release 18, new issues are constantly cropping up. Release 19 is the successor to Release 18 and the stepping-stone to the revolutionary 6G technology that will bring about even greater improvements in speed and functionality. Clarity on tasks and timelines would be provided at the first workshop in June 2023, with the content being fine-tuned until December 2023. Researchers anticipate that the Release 19 specification will be locked and frozen in March 2025. The next-generation innovation platform will have its scope and technological foundation defined during a workshop in July 2024, with finalization expected in September 2026. Official specifications work on 6G standards is expected to begin around 2025. The first 6G standard, Release 21, needs to be finalized and ratified by early 2028 in order to meet the anticipated needs of use cases in 2030 and beyond. The current global implementation of 5G mobile networks is gaining momentum. The coverage and capacity are expanding, enabling the introduction of numerous new 5G devices and services. Each mobile generation builds upon the technological advancements of its predecessor. Global standards for each generation are set by the International Telecommunication Union (ITU) and the 3GPP. The 3GPP is devoted to studying use cases, foundational aspects, architecture evolution, and migration. The deployment of 5G technologies, standardized globally, is occurring at a much faster pace compared to previous generations [4, 5]. The 3GPP system model has progressed and improved over time in terms of how it supports network functions (as shown in Figure 1.1). In order for mobile devices to connect to a network wirelessly, a Radio Access Network (RAN) must be in place. To accomplish this, RAN transceivers take in analog signals, digitize them, and

DOI: 10.1201/9781003465393-1

1

2

5G NR Modeling in MATLAB®

FIGURE 1.1  3GPP system model (5G NR access network + 5GC network).

send them along with electromagnetic radio waves to the core network (5GC). The information can then be transmitted to the Internet. For mobile devices to connect to a network wirelessly, a RAN must be in place. 5G New Radio (NR) performs powerful and complex processing within a fully coordinated, multilayer network that encompasses low-band, mid-band, and high-band frequencies. Its goal is to provide wireless connectivity to devices and optimize network performance. Usually, service delivery occurs through a data forwarding network or User Plane (UP). The core network 5GC sets up and maintains the forwarding path, which necessitates supporting various capabilities. The UP covers a wide variety of responsibilities and restrictions, including but not limited to monitoring, service level guarantees, billing, and many other authorized network capabilities. The mobile communication system’s functions that set up and keep the UP running are supported by the signals of the Control Plane (CP). In this context, “signaling” refers to the interchange of data that facilitates but does not itself provide the end-to-end communication service. Essential services including access control, data packet routing and forwarding, mobility management, radio resource management, and User Equipment (UE) reachability are all supported by the 5GC network. The objective of the upcoming platform is to make significant advancements in performance and effectiveness. 6G technology is anticipated to be the succeeding iteration of wireless communication after 5G. It aims to attain data rates of up to 1 Tbps, extremely low latency of less than 1 ms, and a connection density of 10 million devices per square kilometer. Operating in the sub-THz to THz frequency range (100 GHz to 3 THz), 6G aims to be ten times more energy efficient. 6G is anticipated to incorporate a range of advanced technologies, such as holographic communications, which would allow for the transmission of 3D images and other immersive media. It is also expected to support a wider range of frequencies, including higher and lower bands, which could improve coverage and capacity. Potential applications of 6G include smart cities with improved urban planning, energy management, transportation, and security. Industry 4.0 will benefit from advanced automation, real-time data analysis, and predictive maintenance. Extended Reality (XR) and autonomous vehicles will also see significant advancements, thanks to the capabilities of 6G technology. However, several challenges must be overcome before 6G becomes a reality. Developing and deploying the necessary infrastructure and establishing global standards for new technology and its applications are also critical steps in the realization of 6G networks. For a seamless transition in both fixed and mobile use cases, it is expected that 6G would coexist with, complement, and augment existing 5G deployments.

Introduction

3

This chapter covers the five generations of mobile communications spanning 50 years. From simple analog mobile radios, it has evolved into possibly the most complex human-made system worldwide, with more than two-thirds of the global population being subscribers and the number of devices surpassing the world’s population. In the last 20 years, mobile phones have become pervasive among consumers. These days, it only takes a few clicks to establish contact with someone on the other side of the world. 3GPP has standardized the features and standards of mobile technologies from 3G to 5G. A complete system description for mobile telecommunications is provided by the project’s coverage of radio access, core network, and service capabilities. The 3GPP 2025 roadmap for 5G mobile technology R&D and standardization is described in the following section. The goal is to determine 5G’s requirements and potential areas of innovation. 5G connectivity is a sophisticated, adaptable, and dynamic technological framework with a wide range of potential uses. As a whole, 5G is being refined technically to pave the way for the 6G age of innovation.

1.2 THE ROADMAP TO 5G Mobile communications have made a step up approximately every 10 years, starting from the 1st Generation (1G) enabling mobile voice communications in the 1980s, followed by the 2nd Generation (2G) improving voice communication efficiency and coverage in the 1990s. The focus started to shift to mobile data communications in the 3rd Generation (3G) in the 2000s when wireless Internet became a reality. Mobile broadband took off in the 4th Generation Long Term Evolution (4G LTE), achieving unprecedented wireless communications speeds and expansion into other fields as well as driving the proliferation of smartphones. The recent 5G is a common communication platform driven by continuous research and innovations of unified connectivity for diverse services, radio-spectrum, and deployments (Figure 1.2). All standardization processes have to be done in a phased approach. The standardization work requires extensive evaluations, careful analysis, and meticulous end-to-end system design including handling possible error cases, practical performance characterization and testability, and reconciliation of various views from all participating parties. In addition, standardization work in 3GPP is increasingly witnessing close interaction and cooperation among different standardization

FIGURE 1.2  The continuous research and innovations in mobile communications.

4

5G NR Modeling in MATLAB®

FIGURE 1.3  3GPP 5G timeline for phases R15, R16, R17, and 5G-Advanced R18.

organizations, most notably due to the expansion of wireless communications into other vertical domains, such as the automotive industry, smart factories and satellites, and the usage of unlicensed or shared spectrum. The groundbreaking event for 5G was the first workshop in September 2015 where three emerging high-level use cases were identified: Enhanced Mobile Broadband (eMBB), Massive Machine-Type Communications (mMTC), and Ultra-Reliable and Low Latency Communications (URLLC). Figure 1.3 illustrates the timeline for 5G NR in 3GPP in the period 2015–2023. 3GPP is a collaborative project between seven organizations that work together to produce global technical reports and technical specifications for building and implementing next-generation networks. These Technical Reports (TRs) result from studies conducted by the working groups, which are then consolidated into technical specifications that serve as the standard. 3GPP is a worldwide partnership that brings together stakeholders from various regions to agree on Technical Specifications (TSs) that later become national standards and eventually the hardware and software used in the mobile telecommunications industry. In 3GPP, the phased approach is managed using a terminology called a Release (R). Each release usually lasts one to two years. The releases in 3GPP are indexed contiguously. After GSM Phase 1 and Phase 2 and the first 3GPP release called Release 99 (which was named by the year of the anticipated release), starting from Release 4 in the year 2000, the releases in 3GPP were indexed with a specific number, incremented after each release. For 5G NR, there have been four releases: R15 from 2016Q1 to 2018Q4, R16 from 2018Q3 to 2020Q1, R17 from 2020Q2 to 2022Q2, and R18 from 2022Q1 to 2023Q4. Note that it is typical that a release may consist of a study phase Study Items (SI) and a specification phase Work Items (WI). After the end of each release, the resulting specifications may undergo a series of corrections and fixes. As the first release of 5G, R15 was done in a very short time of one-year study item from 2016Q1 to 2017Q1, followed by a nine-month work item for a first drop of the release focusing on Non-Standalone (NSA) deployments using the Evolved Packet Core (EPC) (Option 3). Then, this was followed by another six months for Standalone (SA) deployments using the new core network (5GC) (Option 2), and

Introduction

5

FIGURE 1.4  3GPP 5G System architecture options and migration strategies.

yet another six months for a late drop delivering additional use cases and additional architecture options including connecting evolved LTE to the new 5G core (Options 5 and 7) as shown in Figure 1.4. For both the second and third 5G releases, while there are continued evolutions for the traditional eMBB, the expansion of 5G into vertical domains is addressed in R16 and is further accelerated in R17. Release 18 is a significant upgrade and the first version to support 5G-Advanced. Forward-looking ideas and technologies that will increase cellular networks’ accessibility and usefulness will be detailed in Release 19 and following revisions. • Release 15 (R15), which was made available in 2018, outlined the first official 5G network architecture. Many mobile operators expected to provide 5G services in 2018; therefore, to hasten its global rollout, 3GPP split R15 into two drops. Rapid deployment of 5G was made feasible by the early deployment of NSA, which allowed for the interconnection of 5G radio networks with 4G core networks. The 5G core network and the accompanying SA were dropped later. The 5G NR (New Radio) air interface requirements are part of R15. Version R15 introduces new features and enhancements for LTE, the air interface utilized by 4G networks, along with other technical modifications and refinements. As the current standard for cellular networks, R15 is the foundation upon which 5G networks will be built. As wireless communications continue to advance, new features and capabilities will be added to subsequent releases of the 3GPP specifications. These releases will build upon and improve upon the groundwork laid in R15.

6

5G NR Modeling in MATLAB®

• Release 16 (R16), which was introduced in 2020, adds new features and capabilities to LTE, the air interface used by 4G networks, and improves upon the 5G NR air interface. The complete capabilities of 5G, including Network-Slicing (NS) and enterprise services, are enabled by the R16 specification. R15 laid the groundwork for consumer and enterprise services, and R16 expanded on its success. R15 requirements were expanded and made more efficient with this new edition, mainly in the enterprise area. Mission-critical communication and the IoT are two examples of the new services and applications it supports. mMTC, URLLC, and improved mobile broadband are some of the main areas of the R16 study. Additional technical improvements and support for new frequency bands are included in Release 16 to help cellular networks continue to evolve. • Release 17 (R17) was published in March 2022 and comprises additional developments and upgrades to the 5G NR air interface. R17 was frozen in March 2022, and R18 was frozen in December 2023. These two releases introduced new features that aim to bring significant value for enterprise applications, along with other organic improvements to the cellular standard. Building on the foundations laid by earlier 3GPP specification releases, R17’s development is guided by the evolving needs and requirements of the mobile industry. 3GPP R17 reached Stage 3 functional freeze (system design completion) in March 2022 (the scope of the release was approved in December 2019). The first stage of the 5G decade’s technological evolution is concluded with R17. • Release 18 (R18) addresses more 5G-Advanced, which is what the industry is calling some of the technologies that come between 5G and 6G. Work for R18 started in the second quarter of 2022. R18 is 5G-Advanced’s first standard release, and we anticipate a few more releases that will be 5G-focused after that. The normative work on 6G is expected to start in the R21 timeframe if the shift from 4G to 5G is a sign of when 6G will start (~10-year cadence). With the introduction of 5G-Advanced technology in 2024, the field of 5G technology will witness a greater emphasis on Artificial Intelligence (AI), Machine Learning (ML), and Extended Reality (XR). Additionally, there will be a greater focus on sustainability initiatives. The initial freeze date for that standard package is December 2023, after which vendors should be able to start integrating those approved changes into commercial equipment. It is anticipated that between 2024 and 2026, 5G-Advanced radios will begin to see market traction. It is anticipated that 5G-Advanced, with its XR applications like gaming, video streaming, and remote working, will create financial opportunities in the consumer and enterprise markets. In order to encourage mass market adoption, 3GPP working groups are focusing on enhancing XR-specific traffic performance and power consumption. Because 5G network utilization is becoming more complex and requires the use of more sophisticated ways than traditional methods to manage, AI/ML is also becoming increasingly important for future networks. Furthermore, operators need to save system-level network

Introduction

7

energy in order to reduce deployment costs and maintain network performance for a range of use cases.

1.2.1 A Brief History of the Evolution of Mobile Standards About a decade of study and development is necessary before launching a new generation of networks. In 1991, the world witnessed the commercial debut of the 2nd Generation (2G) of digital cellular networks. This was followed by the introduction of 3G in 2001, 4G in 2009, and 5G in 2019. Thus, we must now concentrate on forming 6G, with a projected release date of 2028–2030. Around the year 2020, serious international 6G research was initiated as shown in Figure 1.5. 1G, where it all began. Nippon Telegraph and Telephone (NTT) introduced 1G mobile networks in Tokyo in 1979. NTT had 1G up and running over all of Japan by 1984. The Motorola DynaTAC was one of the first extensively used mobile phones in the United States when the first 1G operations were permitted in 1983. The DynaTAC proved the viability of 1G technology by attracting an unprecedented 20 million users around the world by the year 1990. Canada and the United Kingdom were among the

FIGURE 1.5  3GPP timeline 2019–2026 functional freeze data for R15–20.

8

5G NR Modeling in MATLAB®

countries that launched their own 1G networks a few years after the United States. The disadvantages of 1G technology included limited service areas, subpar audio quality, no roaming between operators on various networks, and incompatibility with networks that used different frequency bands. Despite these shortcomings, the widespread adoption of 1G enabled the creation of 2G mobile networks. 2G, cultural revolution. Under the GSM standard, Finland introduced the 2nd Generation (2G) of mobile networks in 1991, ushering in the first encrypted conversations and vastly improved digital audio communications with less static and background crackling. In addition, SMS, MMS, and MMS were all made available for the first time on mobile devices. As a result, there was unprecedented uptake from both customers and companies. Operators hurried to invest in new infrastructure such as mobile cell towers despite 2G’s slow initial transfer speeds of roughly 9.6 kbps. By the time it was over, users could get download speeds of up to 40 kbps over dial-up and up to 500 kbps via EDGE. Despite its slow speeds, 2G completely altered the business world and our daily lives. Table 1.1 provides a summary of the most salient features and specifications of 2G releases. 3G, packet-switching revolution. In 2001, NTT DoCoMo was the first company to launch a 3G network, with the intention of standardizing the network technology that service providers employ. Since the data packets that power an Internet connection are standardized, users could now access data from anywhere in the globe. For the first time, worldwide roaming services were openly made available by this. With 3G’s enhanced data transfer capabilities, new services including Voice over Internet Protocol, video streaming, and video conferencing also became available. The launch of 3G took mobile networks and data usage to a new level. The network expanded to incorporate cell towers that could service 60 to 100 users simultaneously without experiencing service degradation, and speeds were raised to 2 Mbps. Every advancement in these first three levels of networking necessitated new hardware. Smartphone use was growing by the time 3G was introduced, and they had evolved into portable mini computers that could be taken anywhere. An overview of 3G releases and their main characteristics is given in Table 1.2. 4G, streaming era. In 2009, the first commercial 4G service, using the LTE standard, was launched in Stockholm, Sweden, and Oslo, Norway. It was then rolled out worldwide, making high-quality video streaming a reality for millions of people. With 4G, users may access mobile Internet at a speed of up to 1 Gbps when stationary, which makes gaming, HD video, and high-definition video conferencing possible. Mobile devices, which had to be properly engineered to accommodate 4G, helped device manufacturers to drastically raise their revenues. As engineers worked out how to maximize the data packet for transmission over the available bandwidth, cell towers could serve 300–400 individuals. 4G brought mobile phones up to speed with the fastest PC DSL rates available, enabling 3–5 Mbps. An overview of 4G releases and their main characteristics is given in Table 1.3. 5G, Internet of Things era. The next great digital revolution of the Internet of Things (IoT) will allow mass connected devices to communicate data globally. 5G’s intelligent connectivity promises to revolutionize every industry, including healthcare and banking. 5G presents the potential for life-saving innovations like

9

Introduction

TABLE 1.1 2G Releases and Features Release

Features

Generation

R98 Release 1998 (EDGE)

The main enhancements in this release include GSM additional features, GPRS for PCS 1900, AMR, and EDGE. A summary is given below: • Enhanced Data rates for GSM Evolution (EDGE)—BSS and NSS Parts. • Enhanced QoS Support in GPRS. • General Packet Radio Service Phase 2 (GPRS)—part1 network and radio. • GPRS for PCS1900 and GPRS Mobile IP Interworking. • GSM—Cordless Telephony System (CTS). • GSM Mobile Number Portability (EURO) MNP. • GSM-API for SIM-Toolkit. • Mobile Station Execution Environment (MExE) [6].

2.75G

R97 Release 1997 (GPRS)

The main update in this release was the introduction of GPRS and some other features as follows: • A-bus Management of Alarms/faults on the BTS site. • ASCI Phase 2. • Calling Name Presentation—US (CNAP-US). • CAMEL phase 2. • General Packet Radio Service Phase 1 (GPRS)—network part. • General Packet Radio Service Phase 1 (GPRS)—radio part. • Mobile Assisted Frequency Allocation (MAFA). • SIM—Security mechanisms for the SIM Application Toolkit. • SMS enhancements phase 1. • SMS Mobile Busy. • Support of Private Numbering Plan (SPNP). • Support of Shared Interworking Function (SIWF) [7]. The main GSM updates in this release include: • 14.4 kbit/s User Data Rate. • ASCI Phase 1Voice Broadcast Service (VBS) and Voice Group Call Service (VGCS)—phase 1 • CAMEL phase 1. • Compression of User Data. • High-Speed Circuit Switched Data. • Packet Data on Signaling Channels. • Radio Local Loop (RLL) using GSM. • Second SMS broadcast channel. • Service Dialing Numbers. • SMS Interworking Extensions [7].

2.5G

R96 Phase 2+

2G

(Continued )

10

5G NR Modeling in MATLAB®

TABLE 1.1 (CONTINUED) 2G Releases and Features Release Ph2 Phase 2

Ph1-EXT Phase 1 Extension

Ph1-DCS Phase 1 DCS-1800 Ph1 Phase 1

Features

Generation

Phase 2 of GSM brought new capabilities, such as: • Advice of charge. • Calling line identification. • Call waiting. • Call hold. • Conference calling. • Closed user groups. • Enhanced Full Rate (EFR) Codec. The GSM-900 band has been expanded to include higher frequencies in several countries. E-GSM is an “extended” version of the original GSM-900 band, using frequencies from 880 to 915 MHz (uplink) and 925 to 960 MHz (downlink) to accommodate an additional 50 channels (channels 975 to 1023 and 0) [7]. GSM-1800 MHz—GSM-1800 uses 1710–1785 MHz to send information from the Mobile Station to the Base Transceiver Station (uplink) and 1805–1880 MHz for the other direction (downlink), providing 374 channels (channel numbers 512 to 885). Duplex spacing is 95 MHz [7]. Basic GSM-900MHz—The uplink frequency range for GSM-900 is 890–915 MHz, and the downlink frequency range is 935–960 MHz, with 200 kHz between each RF channel (channels 1–124) in both directions. The 45-MHz duplex spacing is employed. The GSM-900 band has been expanded to include higher frequencies in several countries.

telemedicine, remote surgery, and even remote vital signs monitoring. In December 2018, three South Korean mobile providers (KT, LG Uplus, SK Telecom) introduced commercial 5G services. In March 2019, they simultaneously deployed 5G across the country. Another massive, exponential increase in speed and connectivity is offered by 5G. It provides faster download rates of up to 20 Gbps and more capacity to accommodate thousands of IoT devices and hundreds of users concurrently. An overview of 5G releases and their main characteristics is given in Table 1.4. 6G, IMT-2030. IMT-2030 will be a hybrid network that combines many types of networks, such as fixed, mobile cellular, high-altitude platforms, satellites, and others that have not yet been defined and builds on the massive upgrading of network equipment envisaged for 5G. IMT-2030 is designed to provide a revolutionary new user experience with connection speeds in the Terabits/s range per user. Unlike 2G in 1991 or 4G in 2009, IMT-2030 will not replace existing infrastructure but serve as an upgrade rather than a new generation of mobile technology.

1.2.2 5G vs LTE Requirements and Performance Indicators The data rate supported by each generation has increased significantly over time. 2G networks had a throughput of 9.6–236 Kbps, 3G increased this range to 384 Kbps

11

Introduction

TABLE 1.2 3G Releases and Features Release

Features

Rel-9 Release 9

Release 9 essentially deals with LTE enhancements. Aside from introducing novel features like Self-Organizing Networks (SON), eMBMS, LCS, new spectrum bands (such 800 MHz and 1500 MHz) for LTE operation, SAES Enhancements, WiMAX, and LTE/UMTS interoperability, it also fully integrates the Femtocell idea (Home eNodeB). Dual-Cell HSDPA with MIMO, Dual-Cell HSUPA and LTE HeNB [8]

Rel-8 Release 8

Release 8 marked the beginning of the finalization of the LTE specification. Release 8 was introduced in 2008 with the intention of developing cutting-edge communication systems. LTE release 8 included: • Maximum transfer rates of 300 Mbps downlink and 75 Mbps uplink low delay, as low as 10 ms. • Orthogonal Frequency Domain Multiple Access (OFDMA) downlink technology. • Single-Carrier Frequency Domain Multiple Access (SC-FDMA) uplink technology, • Multi-Input Multi-Output (MIMO) antennas targeting to increase bandwidth. • Flat radio architecture with functionality distributed among eNodeBs base stations. • All IP core networks, designed around System Architecture Evolution (SAE). In addition, LTE Cat 1 was defined in this release, providing a low-power, low-bandwidth technology suitable for IoT applications. LTE Cat 1 caps out at 10 Mbps downstream, unlike LTE Cat 4 which might peak at 150 Mbps. As a result, the device can consume less power without sacrificing performance. Release 8 added Dual-Cell HSDPA and UMTS HNB [9], none of which were compatible with earlier CDMA interfaces. HSPA+, the next iteration of High-Speed Packet Access (HSPA), is also known as Release 7. MIMO antenna solutions, introduced in Release 7 [9], allow for an increase in the HSPA+ downlink peak bit rate to 28.8 Mbps, and in the uplink rate to 11.5 Mbps, thanks to higher order modulation. For increased data transmission speeds, GSM has a backwards-compatible upgrade called Enhanced Data rates for GSM Evolution (EDGE), which was specified in Release 7. EDGE is also known as Enhanced GPRS (EGPRS), IMT Single Carrier (IMT-SC), and Enhanced Data rates for Global Evolution. With its inclusion in the ITU’s 3G standard, EDGE can be seen of as a pre-3G radio technology. Quality of Service and Low Latencies as well as Voice over Internet Protocol were enhanced in Release 7 [10].

Rel-7 Release 7

Generation 3.95G

3.75G

(Continued )

12

5G NR Modeling in MATLAB®

TABLE 1.2 (CONTINUED) 3G Releases and Features Release Rel-6 Release 6

Rel-5 Release 5

Rel-4 Release 4

R00 Release 2000 R99 Release 1999

Features One of the most notable additions in this update is support for wireless LAN integration. The HSUPA 3G mobile telephone protocol was recently introduced. This innovation was a significant next step in the development of UMTS. The uplink data rate is increased to 5.76 Mbps, which increases the capacity and decreases the latency. Also included is the ability to efficiently deliver broadcast and multicast services within a cell and throughout the core network via Multimedia Broadcast Multicast Services (MBMS), a point-to-multipoint interface specification for current and future 3GPP cellular networks. To further extend mobile voice, data, and multimedia (IP Multimedia Subsystem/Session Initiation Protocol (IMS/SIP)) services over IP networks, IMS was improved with features such as Push to Talk over Cellular (PoC) and Generic Access Network (GAN) [11]. With this release, IMS and HSDPA were made available for the first time. Delivering IP multimedia services is the primary function of the IP Multimedia Subsystem (IMS), also known as the IP Multimedia Core Network Subsystem. 3G mobile communications protocol High-Speed Downlink Packet Access (HSDPA) is a member of the High-Speed Packet Access (HSPA) family. The 3GPP Release 5 documents the initial rollout of HSDPA. In the first stage, new fundamental capabilities were implemented, and peak data rates of 14.0 Mbps with drastically reduced latency were targeted. Key features of HSDPA include higher-order modulation, short Transmission Time Intervals (TTIs), fast link adaptation and scheduling, and instantaneous Hybrid Automatic Repeat Requests (HARQ); it is based on shared channel transmission. In many cases, WCDMA networks only need a software update to be upgraded to HSDPA. Typically, phone calls are given higher priority than data transfers [12]. Release 4 was also known as 3GPP Release 2000. This release marked the introduction of the UMTS all-IP Core Network. Some of the key features include Multimedia Message Service (MMS), enhancements in QoS, security, location services, UTRAN radio interface and GERAN [13]. Eventually, Release 4 would come to supersede Release 2000 as the preferred nomenclature. The original UMTS/WCDMA standard was published in 3GPP Release 99. The new UTRAN radio access network was created, and the underlying GSM requirements were consolidated. Both circuit-switched and packet-switched high-speed traffic transmission architectures have their origins in this work. It pioneered the 3G UMTS network standard that uses WCDMA for its radio access [14].

Generation 3.5G

3G

13

Introduction

TABLE 1.3 4G Releases and Features Release

Features

Generation

Rel-14 Release 14

This release focused mainly on 5G study items and outlined the elements on the road to 5G which included: • Energy efficiency. • Location services (LCS). • Mission Critical Data over LTE. • Mission Critical Video over LTE. • Flexible Mobile Service Steering (FMSS). • Multimedia Broadcast Supplement for Public (MBSP) Warning System. • Enhancement for TV service. • Massive Internet of Things. • Cell Broadcast Service (CBS) [15]. This release is also termed as LTE Advanced Pro. It has the following main features: • LTE in unlicensed spectrum. The primary cell in Release 13 operates in a licensed spectrum to supply mission-critical data and QoS guarantees, while the secondary cell operates in an unlicensed spectrum to take advantage of spectrum openings and increase data rates. • Carrier Aggregation enhancements. The purpose of this Release 13 is to allow LTE CA to support up to 32 Component Carriers, allowing for a significant improvement in both the maximum data speeds that can be achieved by LTE and the ability to aggregate a large number of carriers across many frequency bands. • LTE enhancements for Machine-Type Communications (MTC). Release 13 focuses on defining a new low complexity UE category type that supports reduced bandwidth, reduced transmit power, reduced support for downlink transmission modes, ultra-long battery life via power consumption reduction techniques, and extended coverage operation, continuing the normative work begun in Release 12 to specify key physical layer and RF enablers to enhance LTE's suitability for the promising IoT market. • Enhancements for D2D. • Elevation Beamforming/Full-Dimension MIMO. In the future, higher frequencies will be more useful for high-order MIMO systems with up to 64 antenna ports at the eNB. • Enhanced multiuser transmission techniques. The project’s overarching objective is to investigate whether or not downlink multiuser broadcasts employing superposition coding can improve the LTE system’s spectral efficiency and enhanced indoor positioning • Single-Cell Point-to-Multipoint (SC-PTM). eMBMS was created to effectively provide multicast services across large, often cross-cell, areas. Multicast services across a single cell, however, may be useful for a variety of applications. Any potential advantages and solutions of SC-PTM operation based on the LTE downstream shared channel will be determined via a 3GPP Study Item for Support of SC-PTM transmission in LTE [16].

4.75G

Rel-13 Release 13

4.5G

(Continued )

14

5G NR Modeling in MATLAB®

TABLE 1.3 (CONTINUED) 4G Releases and Features Release Rel-12 Release 12

Rel-11 Release 11

Rel-10 Release 10

Features Improved small cells (higher order modulation, MIMO (3D channel modeling, elevation beamforming, massive MIMO), dual connectivity, cell discovery, self-configuration), new and enhanced services (cost and range of MTC, D2D communication, eMBMS enhancements), carrier aggregation (two uplink carriers, three downlink carriers, FDD/TDD carrier aggregation), Wi-Fi integration with LTE, and LTE in unlicensed spectrum were all introduced in Release 12. The LTE Advanced capabilities that were standardized in Release 10 have been improved in Release 11. A few of the major updates are listed below: • Carrier Aggregation enhancements. Multiple Timing Advances (TAs) for uplink carrier aggregation, Non-contiguous intra-band carrier aggregation, and physical layer changes for carrier aggregation support in TDD LTE • Coordinated Multipoint Transmission and Reception (CoMP). With CoMP the transmitter can share data load even if they are not collocated. • ePDCCH. In 3GPP Release 11, a new upgraded PDCCH was created to expand the capacity of control channels. Unlike Release 8 PDCCH, which can only use the control section of subframes, ePDCCH makes use of PDSCH resources to send control information. • Network-based Positioning. Uplink positioning is supported in Release 11 through the use of sounding reference signals for time difference measurements from multiple eNBs. • Advanced IP Interconnection of Services. • Service layer interconnection between national operators/carriers as well as third-party application providers. • Heterogeneous networks (HetNet) improvements. • In-device Co-existence (IDC) [17, 18]. Compared to the maximum speeds that a UE may attain using 3GPP Release 8 specifications, the LTE-Advanced specifications in Release 10 offer major new capabilities and improvements to meet the ITU’s IMT-Advanced requirements. Some key requirements laid down by IMT-Advanced are as below: • 1 Gbps DL/500 Mbps UL throughput. • High spectral efficiency. • Worldwide roaming. • The following are some significant improvements in Release 10: • Enhanced Uplink multiple access. Uplink clustered SC-FDMA is included in Release 10. LTE-Advanced in Release 10 supports frequencyselective scheduling in the uplink, whereas Release 8 SC-FDMA only allowed carriers along contiguous blocks of spectrum. • MIMO enhancements. In the downlink, LTE-Advanced supports up to 8 × 8 MIMO, and in the uplink, the UE can support up to 4 × 4.

Generation 4G

(Continued )

15

Introduction

TABLE 1.3 (CONTINUED) 4G Releases and Features Release

Features

Generation

• Relay Nodes. Relay nodes are one of the improvements proposed for Release 10 to help fill in coverage gaps. • Enhanced inter-cell interference coordination (eICIC). 3GPP Release 10 implemented eICIC to address interference conundrums in Heterogeneous Networks (HetNet). • Carrier aggregation (CA). In order to increase end-user throughput as required by IMT-Advanced, CA was introduced in Release 10 as a cost-effective approach for operators to make advantage of their fragmented spectrum spread across separate or same bands. • Support for heterogeneous networks. Heterogeneous networks are produced when large macro cells and small cells interact with one another. Heterogeneous network detail specifications were planned to be laid forth in Release 10. • SON Improvements. Release 10 improves upon previously offered SON features and takes into account self-healing mechanisms. • It is backwards-compatible with Release 8 (LTE) and also provides Multicell HSDPA (four carriers) [19].

to 42 Mbps, and 4G further improved it from 100 Mbps to 1 Gbps. 5G has made a massive leap with a throughput of 10 Gbps to 20 Gbps, while 6G is expected to reach an impressive 100 Gbps to 1 Tbps. The average user experience in terms of speed has also improved with each generation. 2G networks provided speeds of around 20–40 Kbps, 3G increased this range to 500 Kbps to 2 Mbps, and 4G delivered speeds of 10–50 Mbps. With 5G, users can expect speeds between 50 Mbps and 10 Gbps. 6G is projected to offer speeds from 1–100 Gbps. Latency, or the time it takes for a signal to travel from the sender to the receiver, has decreased significantly with each generation. 2G had a latency of 300–1000 ms, 3G reduced this to 100–500 ms, and 4G further decreased it to 30–100 ms. 5G has dramatically lowered latency to 1–10 ms, and 6G is expected to achieve submillisecond latency. The ability to transmit more data using the same spectrum has improved. 2G had low spectrum efficiency, while 3G and 4G made significant improvements. 5G has very high spectrum efficiency thanks to massive Multi-Input Multi-Output (MIMO) and beamforming technologies. 6G is expected to push the limits of spectrum efficiency even further with the use of THz frequencies and advanced network architectures. Some of the key features of 5G networks include: • Data transfer rates on 5G networks are expected to be significantly higher than those of previous mobile network generations (10 Gbps or more).

16

5G NR Modeling in MATLAB®

TABLE 1.4 5G Releases and Features Release

Features

Generation

Rel-18 Release 18

With Release 18, development on 5G Advanced officially began. Data-driven, 5G-Advanced smart network solutions will be at the forefront of Release 18’s focus, owing to the incorporation of AI and ML technology. The most notable changes and studies from Release 18 are as follows [20, 21]: • Network energy saving. To create a network energy consumption model for a Base Station (BS), construct an evaluation methodology, and determine Key Performance Indicators (KPIs), a study on network energy savings for NR in Release 18 will be done). The next step of the research is to look into methods for maximizing network energy efficiency during certain deployments. • Coverage enhancement. Improved PRACH (physical random access channel) coverage is on the agenda for 3GPP, along with research into increasing UE power a limit for CA and DC and decreasing maximum power reduction or peak-average-power ratio. In the uplink, 3GPP will also investigate the possibility of dynamically switching between Cyclic-Prefix Othogonal Frequency-Division Multiplexing (CP-OFDM) and Discrete Fourier Transform (DFT) spread OFDM (DFT-S-OFDM). • Mobility support. Work on mobility in Release 18 also focuses heavily on improving conditional handover support. In conditional handover, UE gets a handover command with a condition from the network and does not apply the command until the condition is satisfied. • MIMO evolution. MIMO evolution continues in 3GPP Release 18. Coherent joint transmission, two-timing advances, and improved uplink power regulation for multiple TRPs are all topics that 3GPP plans to investigate as part of its work to broaden the scope of the Transmission Configuration Indicator (TCI) framework (TRP). Support for eight antenna ports in uplink and simultaneous multipanel uplink transmission will be studied to better support advanced UEs such as Customer Premise Equipment (CPE), Fixed Wireless Access (FWA) devices, and vehicular UEs. • Multicast and broadcast. In Release 18, we will look into techniques to increase resource efficiency in RAN sharing scenarios and extend multicast support to UEs in RRC inactive state; 3GPP will also make enhancements to allow UEs in RRC connected state to receive broadcast service and unicast service simultaneously. • Improved positioning. Improved positioning accuracy, integrity, and power efficiency are all topics that will be studied in 3GPP Release 18 along with sidelink positioning and positioning support for RedCap devices.

Rel-17 Release 17

New capabilities for the three primary use case families—eMBB, URLLC, and MC)—will be introduced as a result of the work items accepted by the 3GPP. The goal is to accommodate the anticipated increase in mobile data traffic while also tailoring NR to specific industries including transportation, logistics, public safety, the media, and production. The new features are as follows [22]:

5G

(Continued )

17

Introduction

TABLE 1.4 (CONTINUED) 5G Releases and Features Release

Rel-16 Release 16

Features eMBB Features: • Supporting PNR from 52.6 GHz to 71 GHz. More spectrum, up to and including the unlicensed 60 GHz band, is now available thanks to the expansion of the NR frequency range. • Multicast and broadcast services. V2X, public safety, IP multicast, software delivery, and the Internet of Things are the primary targets of this technology. • Support for multi-SIM devices. Allows for network notification and the avoidance of paging collisions when a UE changes networks. • Support for non-terrestrial networks. Better coverage in remote places can be achieved through the use of high-altitude platforms, Low Earth Orbit satellites, and geostationary satellites. • Sidelink relaying. Scenarios include single hop, UE to UE and UE to network relaying. • URLLC features: • IIoT and URLLC support. Enhanced physical layer feedback for manufacturing automation, specifically pertaining to time synchronization. • Positioning. Improved horizontal and vertical precision and reduced latency, especially for IoT applications. • Sidelink. V2X, public safety, commercial use cases, resource allocation enhancement and sidelink discontinuous reception. • Service continuity mechanisms for intra-radio access technology handovers to ensure that UE can quickly reach the cell that provides the desired slice. • Anything reality (XR) evaluations. Help for a wide variety of XR applications, including virtual and augmented reality. • mMTC features: • Small data transmission in the inactive state. Keep-alive messages, wearables, and other types of sensors can now benefit from lower connection establishment overhead. • Support of reduced-capability NR devices. Useful for transmitting data between machines, such as industrial sensors, security cameras, and wearables. Coverage, capacity, latency, power, mobility, dependability, and ease of deployment are just a few of the areas that have seen significant improvements due to Release 16. These are described as follows [23]: Massive MIMO enhancements. Increased support for higher ranks in Multiuser MIMO (MU-MIMO), stronger multibeam management to increase connection stability (crucial for millimeter-wave bands), and enhanced reference signals to decrease Peak-to-Average Power Ratio (PAPR) are just a few of Release 16’s technological achievements. To further enhance coverage at the cell edge, Release 16 enables full-power uplink for all MIMO-capable devices.

Generation

5G

(Continued )

18

5G NR Modeling in MATLAB®

TABLE 1.4 (CONTINUED) 5G Releases and Features Release

Features

Generation

Enhanced Ultra-Reliable, Low-Latency Communication (eURLLC). New vertical use cases, such as industrial automation, require higher connection dependability, which Release 16 is providing by improving the 5G URLLC architecture (up to 99.9999%). Increasing the number of retransmissions alone is not sufficient for these scenarios because there is typically also a strict latency restriction. Coordinated Multipoint Transmission (CoMP) is one crucial technology that can help solve this systemic problem. It employs multi-TRP to offer multiple communication pathways with geographical diversity, allowing for continuous communication even if one link is temporarily blocked. New power-saving features. Several enhancements meant to save energy were included in Version 16. A new Wakeup Signal (WUS), for instance, can inform the device that a transmission is imminent, or it can let the device continue operating in low-power mode without performing the next low-power Discontinuous Reception (DRX) monitoring phase. Low-power optimization, overhead reduction, and better power control techniques are a few more features. Integrated Access and Backhaul (IAB). The expense of constructing new mmWave base stations, which typically necessitates new fiber optics backhaul deployments, is a significant barrier to widely expanding 5G NR mmWave network coverage. Release 16 includes combined access and backhaul to reduce the cost of mmWave densification by allowing a single base station to serve as a wireless access point for end devices and a backhaul node. With IAB, operators may add more base stations on the fly without having to deploy extra fibers for more backhaul capacity, providing for a more adaptable densification plan. Unlicensed spectrum (NR-U). In Release 16, 3GPP finished two projects necessary for new vertical deployments, allowing 5G to penetrate beyond typical public mobile networks. 5G NR-U is the first step toward enabling 5G service in unlicensed bands. It defines two operation modes, anchored NR-U requiring an anchor in licensed or shared spectrum and standalone NR-U that employs just unlicensed spectrum, i.e., does not require any licensed spectrum. The 3GPP has now defined a cellular technology that can operate “standalone” in unlicensed spectrum. The greenfield 6 GHz spectrum offers an enormous 1200 MHz of unlicensed capacity to the United States, and Release 16 supports both it and the existing global 5 GHz unlicensed band now used by Wi-Fi and LTE LAA. Non-Public Network (NPN). The second Release 16 project that I want to highlight is the added support in the system architecture for private networks (called “non-public networks” or NPN, in 3GPP parlance). Private networks utilize dedicated resources (e.g., small cell base stations) that are independently managed, provide security and privacy that allow sensitive data to stay on-premises, and deliver optimizations for local applications (e.g., low latency). Private networks can benefit a wide range of new 5G deployments such as industrial IoT use cases. (Continued )

19

Introduction

TABLE 1.4 (CONTINUED) 5G Releases and Features Release

Features

Generation

Time-Sensitive Networking (TSN). Release 16 of 5G NR introduced support for TSN integration, which can guarantee time-deterministic delivery of data packets, as part of the drive for 5G to serve new Industry 4.0 use cases (such as factory automation). Components of the system used in this endeavor include a precise time synchronization mechanism (Generalized Precision Timing Protocol, or gPTP), a mapping of TSN configuration into a 5G QoS framework for deterministic messaging and traffic shaping, and a headercompressed transport mechanism for Ethernet frames. Cellular-Vehicle-to-Everything (C-V2X). Release 16 also prioritizes the use of 5G to improve automotive safety. While Release 14 C-V2X introduced sidelink (V2V, V2I, V2P) to provide basic safety use cases, Release 16 expands on Release 14/15 by delivering an NR-based sidelink that will enable additional advanced safety use cases while also paving the route for autonomous driving. Using distance as a new dimension at the physical layer, Release 16 offers “on-the-fly” multicast groups depending on distance and applications, allowing for reliable and efficient multicast communication based on HARQ data. Rel-15 Release 15

Phase 1 of 5G corresponds to 3GPP Release 15. It covers the most pressing scenarios for commercial rollouts, such as eMBB and some features of URLLC [24]: The main Release-15 LTE enhancements are as follows: • 1024 QAM support. • LAA/eLAA for Communications Commission for the Citizens Broadband Radio Service (CBRS) at 3.5 GHz. • LTE Operation in Unlicensed spectrum with frame structure type 3. • Advance V2X for Enhancements to V2X. • Enhancement to Narrow Band IoT. Key elements of a 5G phase 1 system include support for network slicing, access and mobility management, a QoS framework, a policy framework, network sharing, access to un-trusted non-3GPP network inter-working (WiMAX, Wi-Fi), and integration with Evolved Packet System (EPS). New system architecture and procedures necessary for 5G systems will be described in the specifications included in Release-15 work items. In the initial stage of the 5G network, a radio access technique called New Radio (NR) has been implemented. Using frequencies up to 52.6 GHz, this 5G NR should support eMBB and URLLC use cases. The goal of the New RAT phase 1 is to accommodate both Non-Standalone (NSA) and Standalone (SA) networks. In the first stage of 5G NR deployment, LTE will act as the primary cell to anchor signals, while NR will be deployed as a secondary cell. The Evolved Packet Core (EPC) needed some upgrades, such as widening the range of QoS parameters, handling the UE capabilities, adding 5G NR parameters in the MME, and regulating access to 5G NR, for this tight inter networking of LTE and 5G NR to be possible.

5G

(Continued )

20

5G NR Modeling in MATLAB®

TABLE 1.4 (CONTINUED) 5G Releases and Features Release

Features

Generation

For LTE and 5G NR to work together, the E-UTRA (LTE cell) must be linked to 5G Core Network (CN). In cases where the handover occurs between 5G NR and LTE, both of which are connected to 5G CN, or between distinct LTE cells connected to EPC and 5G CN, LTE will need to undergo some upgrades to accommodate network slicing, a flow-based QoS framework, and mobility support.

• Latency refers to the amount of time it takes for a signal to be transmitted from one device to another. 5G networks are designed to have significantly lower latency than previous generations of mobile networks, potentially reaching levels as low as a few milliseconds. • 5G networks are designed to support a larger number of devices and connections, which is expected to enable new applications and services such as the IoT. • 5G networks are expected to offer improved coverage and reliability compared to previous generations of mobile networks. It is projected that 5G networks will become more widely available over the next few years as they are being rolled out in many countries. From the radio perspective (RAN) there are many similarities between 5G (NR) and 4G (LTE) but there are some key differences to note. 5G, from its inception, has been meant to address three major types of applications: eMBB, URLLC, and mMTC. The first 3GPP release of NR was R15 and the main focus was eMBB. In order to address future applications, NR was designed from day one with forward compatibility in mind. While URLCC support was in the scope of R15, only a limited set of features were introduced motivated by this type of application: low latency (mini-slot scheduling), and high reliability (set of MCS and CQI tables tailored for 10 –5 error rate operation). It is important to note that URLCC is not enabled by one particular feature or functionality in the NR specifications. Rather, different levels of low-latency and reliability are enabled by different functionalities. In addition, there are features introduced to enable the coexistence in a network and within a terminal of services of different latency and reliability requirements. On mMTC, it is important to realize that mMTC has not been explicitly addressed by NR R15, R16, or even R17. 3GPP made the conscious decision to avoid further fragmenting the IoT market by developing yet another Low Power Wide Area (LPWA) solution just a couple of releases after the initial introduction of Enhanced MTC (eMTC) and Narrow-Band IoT (NB-IoT) in R13. Instead, mMTC communications are supported by the LTE-developed features eMTC (or LTE-M) and NB-IoT, which can be fully embedded inside an NR carrier and connected to the 5GC from R16.

21

Introduction

When LTE was designed and standardized, there was a clear intent to keep it simple and try to minimize options. As a result, LTE is a fairly lean and simple design avoiding unnecessary options and configurability. Note that these design principles were not present in the development of 5G NR, which is designed for a variety of use cases requiring substantially different configurations. LTE was introduced in Release 8 of 3GPP and still evolves today with the corresponding R17 work. The amount of work and functionality that 3GPP has added over the releases to the LTE platform is remarkable. Also, there were some revolutionary changes in the migration from 3G networks to 4G networks. The most relevant change from the radio perspective was the change of waveform from Code Division Multiple Access (CDMA) to Orthogonal Frequency Division Multiple Access (OFDMA) in the downlink and Single-Carrier Frequency Domain Multiple Access (SC-FDMA) in the uplink. From the network perspective, 4G removed the concept of macro-diversity and migrated to a flatter architecture model. Note that this fundamental change remains in the 5G architecture. From a core network and system perspective overall, Evolved Packet System (EPS) is the first fully packet-switched system designed by 3GPP. This always-on IP connectivity is one of the major enablers of the Internet-connected Apps that are used on phones every day. The main components in the 4G architecture are the UEs used by the end users, base station Evolved NodeB (eNB) that connects the UE to the core network and core network Evolved Packet Core (EPC). The LTE architecture revolves around the EPC, a framework structured to handle data traffic and the control of mobile devices. Some of its key components include Mobility Management Entity (MME) responsible for session management and mobility, Serving Gateway (SGW) as a local mobility anchor in routing the data packets, PDN Gateway (PGW) manages IP data connections and assigns IP addresses to UEs, Home Subscriber Server (HSS) central database for user information and subscriptions, Policy and Charging Rules Function (PCRF) dictates policy and charging rules (Table 1.5). TABLE 1.5 5G vs 4G Network Architecture Comparison 5G (NR)

4G (LTE)

Core network

5GC (5G Core) with Service-Based Architecture (SBA)

Evolved Packet Core (EPC)

Base station User equipment Key protocols

gNodeB (gNB) UE designed for 5G standard HTTP2/, PFCP … protocols in SBA

Key functions Latency Throughput

AMF, SMF, UDM, UDR, AUSF, NEF … 1 ms up to 20 Gbps

Evolved NodeB (eNB) UE designed for 4G standard Diameter, GTP-C, GTP-U, S1a, S1b … MME, SGW, PGW …

Frequency

up to 100 GHz (mmWave)

30–50 ms up to 1 Gbps (LTE-Advanced) up to 6 GHz

22

5G NR Modeling in MATLAB®

5G is designed to offer faster speeds, lower latency, and support for many devices. The 5G architecture is based on the Service-Based Architecture (SBA) and introduces the concept of Network Functions (NFs). Some of the key components include user UE similar to 4G but enhanced to support 5G speeds and features, base station gNodeB (gNB), and core network 5G Core (5GC) with several NFs. It’s a radical departure from the EPC and is designed to be more modular, scalable, and flexible. Key components of 5GC include: Access and Mobility Management Function (AMF) which manages user access to resources and mobility; Session Management Function (SMF) which handles session management tasks like session establishment, modification, and release; Unified Data Management (UDM) new version of HSS, it manages user data; Authentication Server Function (AUSF) assists in user authentication; Network Repository Function (NRF) maintains information about network functions (aiding in service discovery); Network Exposure Function (NEF) exposes network capabilities and resources to third-party applications; Policy Control Function (PCF) evolved version of PCRF (dictates policy rules); Unified Data Repository (UDR) storage function for structured data; User Place Function (UPF) is a key component in the 5G core network architecture (responsible for packet routing and forwarding, packet inspection, and Quality of Service (QoS) handling for user data); Network Slice Selection Function (NSSF) is responsible for selecting the appropriate network slice instance based on the UE and the service requirements; Application Function (AF) interacts with the core network (primarily for policy and charging purposes and represents external applications that need to communicate with 5G core components). Unlike 4G’s more rigid design, 5G adopts SBA architecture, allowing different NFs to access services from other functions. 5G further decouples the control and user planes, enabling scalability and flexibility in network deployment and management. Network functions in 5GC are designed to be stateless, meaning they don’t store session state. This improves reliability and fault tolerance. 5G introduces Network Slicing (NS), allowing operators to create multiple virtual networks with varied performance characteristics on a single physical infrastructure (Table 1.6). The 4G core EPC primarily uses the S1 Application Protocol (S1AP) responsible for handling signaling related to mobility and session management, diameter primary signaling protocol (utilized for authentication, authorization, and accounting), GPRS Tunneling Protocol (GTP) handles user data transport between the eNodeB gateways, GTP-C manages signaling for session establishment, GTP-U is responsible for user data encapsulation and transport. In the 5G core SBA introduces new protocols and refines existing ones: NG Application Protocol (NGAP) used between the base station gNodeB and the Access and Mobility Management Function (AMF) dealing with signaling related to mobility and session management; HTTP/2 in functions communication using HTTP/2-based services; Packet Forwarding Control Protocol (PFCP) replaces GTP for control signaling related to user plane function (used between the SMF and UPF; GTP-U still remains as the primary protocol for user data encapsulation and transport between the gNodeB and UPF. In 5GC SBA architecture network functions provide services to other functions over a common bus. This contrasts with the more rigid, interface-based approach of

23

Introduction

TABLE 1.6 5G vs 4G Network Core Architecture Comparison 5G (NR)

4G (LTE)

Architecture type

SBA

Monolithic

Mobility management

AMF

Session management User data management

SMF UDM UDR AUSF PCF

Mobility Management Entity (MME) Combined with MME and SGW Home Subscriber Server (HSS)

Authentication Policy control Service discovery Exposure to third parties User Plane function Network flexibility State handling Network Slicing

NRF NEF provides extensive capabilities UPF High-flexibility due to decoupling CP and UP Mostly stateless functions Native support with end-to-end slicing

Integrated with MME Policy and Charging Rules Function (PCRF) not explicitly defined Limited Serving Gateway (SGW) Packet Data Gateway (PGW) Less flexible Stateful components Not native (can be emulated)

the EPC. 5GC uses HTTP/2 for many internal signaling and communication tasks, contrasting with the more traditional telecom protocols used in 4G. 5GC introduces protocols and mechanisms to handle data in a more unified manner, especially with functions like Unified Data Management (UDM). Next, 5G introduces protocols to support network slicing, allowing for multiple logical networks on the same physical infrastructure, catering to different service requirements. 5GC further separates the Control Plane (CP) and User Plane (UP), enabling more flexible deployments and scalability. This is reflected in the protocols and their interactions. The CP protocol stacks of NR and LTE are, fundamentally, the same. Above the Packet Data Convergence Protocol (PDCP) in the NR protocol stack is a new layer called Service Data Adaptation Protocol (SDAP) that marks QoS flow ID (QFI) in DL and UL packets and maps QoS flows to data radio bearers. During the transition from 4G to 5G, the separation between the UP and CP was extended to the RAN to enable flexible accommodation of 5GC services. The SBA architecture was introduced as another attempt to facilitate cloud and virtualized networks; nevertheless, its use was restricted to the core network for 5G (Figure 1.6). In addition, the advantages of the SBA architecture may be brought to the RAN through the 6G network design by allowing a single cloud platform to host services for the application, the core, and the RAN. Scalability, reliability, elasticity, adaptability, reusability, transparency, automation, and failover are all enhanced by the

24

5G NR Modeling in MATLAB®

FIGURE 1.6  Increasing disaggregation of network from 4G to 5G.

cloud-native, end-to-end strategy. Each service in the RAN and core network can be scaled individually using a cloud-native solution by increasing or decreasing the resources provided to each function. 6G, is anticipated to improve upon 5G NR, by providing higher throughput, lower latency, and more sophisticated capabilities.

1.3 5G TECHNOLOGY RESEARCH AND INNOVATIONS The new generations of mobile communication technologies seemingly appear about every 10 years. The first 1G analog cellular, appeared in the early 1980s. The most successful of these analog systems was Advanced Mobile Phone System (AMPS) with the first service launched in the United States in October 1983. It was essentially an FM mobile radio, with a connection to a telephone central office, a bit of control to send dialed digits and to manage the call, and the ability to manage a radio channel and to perform handoff. It was primitive by today’s standards, but it worked. Mobile telephone systems (MTSs) date from 1949 with the commercial introduction of MTSs. However, its capacity was so low, and its cost so high, even for the enhanced Improved Mobile Telephone System (IMTS). AMPS, however, was a major success. A derivative, with essentially different channel spacing, Total Access Communications System (TACS) was deployed in the United Kingdom and many other countries, in both the European Union and the rest of the world. Japan TACS was a variant deployed in Japan. In the European Union, several other analog

Introduction

25

systems were developed including Nordic Mobile Telephone (NMT) operating at 450 and 900 MHz (launched in 1981), Radiocom2000 (400 MHz, 200 MHz, 160 MHz), C450 in Germany, TMA in Spain, and Radio Telefono Mobile Integrato (RTMI) in Italy [4]. With the rapid growth of AMPS, operators in the United States were demanding more capacity. The United States took two directions. The first standard that was developed, IS-54, called Digital AMPS (DAMPS), used Time-Division Multiple Access (TDMA) techniques to get three calls in the same 30 kHz channel bandwidth of AMPS. It became known as TDMA and was deployed by several major operators as AT&T. Qualcomm AMPS using a wideband Code Division Multiple Access (CDMA) system was also standardized in the United States and became known as IS-95 and was deployed by several major operators (Verizon, Sprint). It was also used in South Korea by all the operators, in Japan, and several other countries. The development of CDMA was a particularly important step, as it brought into the cellular industry advanced communications concepts and set the stage for the highperformance cellular systems that we have today. The European Union undertook a standardization program to create a pan-European system, which became known as Global System for Mobile (GSM) communications. The GSM physical layer used TDMA techniques, and the overall system architecture and separation of functions was very logical and clean. Perhaps most important was that the development of GSM brought together many countries and created a single standard for Europe. An often-overlooked aspect was that the standardization was conducted in English and the standard was written in English to speed up the standardization process, and created a single definitive version of the standard, reducing ambiguities. Japan developed Personal Digital Cellular (PDC) which was a derivative of North American TDMA. During this era, there was considerable debate between proponents of cellular systems and proponents of short-range cordless systems. The Japanese-designed Personal Handyphone System (PHS) and the European Digital Enhanced Cordless Telecommunications (DECT) were the most deployed. However, by the end of the 1990s, it had become clear that cellular technology had become the communications mode chosen by the consumer. In 1985, the International Telecommunications Union (ITU) started to study mobile telephony, six years before the first commercial 2G systems. Recommendation M.687, issued in 1990, put forth a vision for Future Public Land Mobile Telecommunication Systems (FPLMTS) which included many of the attributes of modern systems, including support for many services, international operation, and automated roaming. In hindsight, they got two things wrong. The first was that they viewed the mobile operation as an extension of the Public Switched Telephone Network (PSTN) and Integrated Services Digital Network (ISDN), a vision that was to hinder the development of good data communications through the early days of 3GPP. The first was that, in the early days of 3GPP, they perceived mobile operation as an extension of the PSTN and ISDN, a notion that ultimately slowed down the progress of reliable data communications. The second was their estimates of the required spectrum were from 110 to 160 MHz for voice services and 65 MHz for data services for a total of

26

5G NR Modeling in MATLAB®

between 175 MHz and 225 MHz. This is an almost absurd number given the more than 1150 MHz and 700 MHz of sub-6-GHz licensed spectrum available today in China and the United States, respectively. In addition, the United States has now allocated more than 3 GHz of millimeter wave spectrum which is being used for 5G deployments; other countries have made or are making a large amount of millimeter wave spectrum available. By 1992, when the ITU issued Recommendation M.816 Framework for Services Supported on Future Public Land Mobile Telecommunication Systems (FPLMTS), the system was being called the 3rd Generation (3G) with service starting around 2000. In 1994, the ITU began using the term IMT-2000 instead of 3G. The vision was for one air interface (radio interface), though more than one could be acceptable. When issued in 2000, the IMT-2000 specification, M.1457 Detailed Specifications of the Terrestrial Radio Interfaces of International Mobile Telecommunications-2000 (IMT-2000), contained not a single common air interface, but five air interfaces, none of which had been developed by the ITU. The ITU had succeeded in setting the stage for 3G, but the air interfaces were developed by various other groups. An essentially similar stage-setting approach has been used for successive generations: IMT-Advanced (4G) and IMT-2020 (5G). During the late 1990s, there were numerous discussions on creating a common 3G air interface. While the goal of creating a single 3G air interface was not achieved, this era took a huge step forward in bringing together the world’s cellular communications industry. The result was the creation of two partnership projects, 3GPP and 3GPP2, along with two CDMA-based systems: Universal Mobile Telecommunications System (UMTS), often called WCDMA, and cdma2000. One common system was not attainable for both technical and business reasons. From a technical perspective, cdma2000 offered a smooth evolution path from IS-95 CDMA (CDMAone) and significantly higher capacity, which was particularly a concern due to the more limited amount of spectrum that was available at the time. From a business perspective, beginning in the mid-1990s, GSM and cdma2000 had been in a very intense competition trying to secure operators for their technology, particularly in South America, Africa, and Asia. Over time, the larger European Union-based ecosystem of GSM secured more operators, but it took a few more years for that to fully play out. Three of the initial five air interfaces that were part of IMT-2000 came from 3GPP and 3GPP2. They were IMT-2000 CDMA direct spread (WCDMA), IMT-2000 CDMA multicarrier (cdma2000), and IMT-2000 CDMA TDD. IMT2000 CDMA TDD was a combination of a TDD air interface originally developed by 3GPP, and TD-SCDMA, developed by China Wireless Telecommunications Standards (CWTS), which was, eventually, incorporated into the 3GPP specifications. cdma2000 had both what was called a 1× mode which had a single 1.23 MHz bandwidth carrier, and what was called a 3× multicarrier mode which had three carriers spaced by 1.25 MHz, hence the name IMT-2000 CDMA multicarrier. This was the precursor for 3GPP’s carrier aggregation, though the 3× mode was never commercialized. The other two IMT-2000 air interfaces were an evolution of TDMA and DECT. Around this time, AT&T concluded that continuing the TDMA path was not practical and began deployment of GSM.

Introduction

27

Thus, by the early 2000s, the situation had been clarified: 3G would be based upon the two major CDMA-based air interfaces, WCDMA and cdma2000, though there was deployment by China Mobile of TD-SCDMA. Standardization had consolidated into the two partnership projects, 3GPP and 3GPP2. For much of the 2000s 3GPP and 3GPP2 were rivals, each coming up with new technologies, which in some form were adopted by the other partnership project. One of the weaknesses of the initial 3G standards was that they did not fully rethink the handling of packet traffic to support the rapidly expanding Internet. WCDMA could send the downlink about 2 Mbps using its 5 MHz carrier. Nevertheless, this was an enhancement over General Packet Radio Service (GPRS) which supported up to 114 kbps, and its enhancement Enhanced Data Rates for GSM Evolution (EDGE) which supported up to 473.6 kbps. The CDMA community had focused on Internet support from its early days and had incorporated significantly higher data rates in IS-95-B; the cdma2000 specification could support about 628 kbps on a 1.23 MHz bandwidth carrier. A major step forward in providing better Internet traffic came in late 2000, with 3GPP2’s completion of the cdma2000 High-Rate Packet Data (HRPD) specification. The common name for 3GPP2’s HRPD was 1× EVolution Data Only (1×EVDO), which was then changed to 1× Evolution Data Optimized. This air interface addressed downlink transmissions through a single transmission stream, very short transmissions, high rate feedback of the best transmission mode, the recognition that throughput is higher when the best link to a mobile is selected for transmission (proportional fair scheduling), the use of 8PSK and 16QAM modulation when the channel quality is good, and incremental redundancy. While maintaining the 1.23 MHz channel bandwidth of IS-95 and cdma2000 1×, it was able to attain peak transmission rates of 2.4 Mbps, though it used a separate channel. This was the source of considerable controversy at the time, as 1×EV-DO was not able to support circuit voice services and SMS, which were the primary services at the time, though later there were some trials of packet voice services. As a result, by the end of 2000, 3GPP2 started to develop 1× EVolution Data and Voice (1×EV-DV). While 1×EV-DV pioneered many new concepts, it was never commercially deployed, and high-rate operation on 3GPP2 systems was provided by 1×EV-DO. 3GPP soon started to develop its equivalent of 1×EV-DV which appeared as Highspeed Downlink Packet Access (HSDPA) in Release 5 in 2002 with downlink peak data rates of 14.4 Mbps. Two years later High-Speed Uplink Packet Access (HSUPA) appeared in Release 6. Due to the straightforwardness of the upgrade from IS-95 to cdma2000, the first commercial cdma2000 systems appeared in 2000. It wasn’t until early 2004 that WCDMA Release 99 was performing well, resulting in many operators starting commercial service, though NTT Docomo in Japan had launched a simplified variant in 2001, called Freedom Of Mobile Multimedia Access (FOMA). However, it was not until the launch of HSDPA at the end of 2005 with good Internet packet performance that WCDMA showed its real potential. Further enhancements beyond Release 6 added even higher order modulation, dual-carrier, four carriers, simultaneous operation in multiple bands, and MIMO.

28

5G NR Modeling in MATLAB®

In the early 2000s after the completion of the first generation of IMT-2000, the ITU turned its attention to two phases for the development of mobile systems, as outlined in M.1645, Framework and Overall Objectives of the Future Development of IMT-2000 and Systems Beyond IMT-2000, which was published in 2003. The first phase was the evolutionary enhancement of IMT-2000, which had been occurring through the various 3GPP releases and 3GPP2 specification revisions. The second phase held that new wireless access technology, able to support high data rates with great mobility, may be needed around the year 2010, with widespread deployment in some countries possible by 2015. The second phase held that new wireless access technology, able to support high data rates with great mobility, may be needed around 2010, with widespread deployment in some countries possible by 2015. The ITU’s timeline would soon be hidden, with the first specifications of what might be called 4G emerging in 2007. Several important factors contributed to this. First was the rapid increase in the number of users of cellular communications. A second was the rise of data usage, encouraged by several developments. At the end of the 1990s, the camera began to appear in phones and was in almost every highend phone just a few years later. Users wanted access to their email on cell phones. Mobile location using Global Positioning System (GPS) was starting to appear. All this led to increasing demands for higher capacity and higher data rates. A third was the previously described frustration with the performance of WCDMA in the early 2000s. Orthogonal Frequency Division Multiple Access (OFDMA) as a wireless technology was causing a considerable amount of interest, due to its inherent resilience to multipath as compared to CDMA which tried to identify and process multiple paths. This became more difficult as the bandwidth increased due to the greater number of resolvable paths. Orthogonal Frequency Division Multiplexing (OFDM) as a technology goes back many years and has been used in the European Union Digital Audio Broadcasting (DAB) and Digital Video Broadcasting (DVB) systems, and the IEEE 802.11a and 802.11g standards for Wi-Fi. Perhaps the most important incentive came from the development of WiMax using the IEEE 802.16 standard. The early versions of the 802.16 standard were designed for backhaul or point-to-multipoint data distribution, but the 802.16e amendment was meant for mobile operation. This encouraged 3GPP to have a future evolution workshop in November 2004 to study the evolution of 3GPP radio technologies. This led to the development of the 3GPP standard for Long Term Evolution (LTE) based upon OFDMA which was completed as part of Release 8 in December 2008. The workshop also led to further enhancements of WCDMA, notably carrier aggregation. Not to be outdone, 3GPP2 developed Ultra-Mobile Broadband (UMB), a rather advanced OFDMA design, which was completed in mid-2007. In spite of its technical advantages, some key cellular operators which had been major backers of cdma2000, decided that it was time to have a common worldwide cellular standard based upon LTE. As a result, UMB was never commercially deployed. While 802.16e saw commercial deployment by a number of operators, particularly in Korea, it took several years after the completion of the standard to adequately develop the ecosystem sufficiently for deployment. This delay, coupled with some

Introduction

29

design faults which slowed down performance, prevented 802.16e from becoming a success. The design faults were mostly fixed in the later 802.16m amendment, but by then it was too late as operators had focused on LTE. LTE turned out to be a great success. While a few small deployments were beginning in December 2009, the massive 38-market launch in December 2010 in the United States showed that LTE was commercially ready. Since then, almost every operator in the world has deployed LTE. Yet the first release of LTE, Release 8, was not 4G in some countries as it preceded the IMT-Advanced specification of the ITU. In Japan, NTT Docomo called it Super 3G. The ITU IMT-Advanced designation came two releases later with Release 10. M.2012 Detailed Specifications of the Terrestrial Radio Interfaces of International Mobile Telecommunications Advanced (IMT-Advanced) was published at the beginning of 2012 and contained both LTE and 802.16m. By then, it was clear that there was going to be one cellular air-interface technology worldwide and that it was LTE. One of the trends of 4G, but beginning with 3G, was the expansion of the technologies beyond just cell-to-device unicast connectivity. The first came with Multimedia Broadcast Multicast Service (MBMS) in Release 6 which provides 3G broadcast and multicast services for mobile operators. With LTE came other capabilities including Proximity Services (ProSe) communications, which enables direct communications without going through the network for devices that are close to each other. Release 13 specified Mission-Critical Push To Talk (MCPTT), which supports public safety and other users over unicast, MBMS, or ProSe transports. Release 14 introduced Cellular Vehicle-to-Everything (C-V2X) which enables communications between automobiles and roadside units. Of particular note has been all the activity on Machine-Type Communications (MTC) to support the IoT, notably creating enhanced MTC (eMTC), a simplified version of LTE using a 1.4 MHz bandwidth and creating a special air interface named Narrow-Band IoT (NB-IoT), using 200 kHz bandwidth carriers.

1.3.1 3GPP Standardization Process Mobile communications have constantly evolved via the advancement of technology. Increases in latency, spectral efficiency, and dependability are the major areas where 5G networks stand out from their predecessors. The idea abstracts the most fundamental features of the use case, normalizes the requirements, and integrates the technical parts. A new set of technical requirements has been created by the community of standardization organizations led by the 3GPP consortium. The purpose of this part is to examine the 3GPP standardization procedure, paying special attention to the study and working items in the key Technical Specification Groups (TSG) [25, 26, 27]. The technological standards for evolved 5G have been vastly increased, allowing for the provision of multidimensional needs beyond the baseline Key Performance Indicators (KPIs) established by International Mobile Telecommunications-2020 (IMT-2020 standard). Multiple sectors and institutions throughout the world have been working on requirements for 5G services since 2015. The requirements have

30

5G NR Modeling in MATLAB®

TABLE 1.7 5G Technology Vision in ITU-R Vision, Spectrum. and Technology View 2012–2015 • Development plan • Market/services view • Kick off technology and research • Vision IMT for 2020

Technology Definition

2016–2017

2018–2019

• Radio-spectrum arrangements • Technical performance requirements • Evaluation criteria • Call for proposals

• Proposals • Evaluation • Consensus building

2019–2020 • Spectrum arrangements • Decision & radio framework • Detailed IMT-2020 specifications • Future update plan

been used as input for relevant technical study and are summarized in ITU-R report M.2410-0 (2017) as requirements for IMT-2020 networks. The evaluation criteria and submission forms for the production of IMT-2020 recommendations and reports are laid out in detail in Report M.2411. This includes the service needs, spectrum, and technical performance of radio-interface technologies. The process, approach, and criteria for assessing potential technologies are laid forth in detail in Report M.2412. Background information on individual needs and clarification of the selected items and values are included in Report M.2410 [28, 29, 30]. Table 1.7 displays the ITUperspective Rs and definition of 5G technology. The IMT-2020 radio interface has been specified in full by the Working Group WP5D, which issued its recommendation M.2150 in February 2022 [31]. The recommendation gives a consolidated set of specifications for a Radio Interface Technology (RIT) or a collection of RITs after evaluating potential radio technologies. The 3GPP 5G-SRIT, 3GPP 5G-RIT, and 5Gi (Telecommunications Standards Development Society of India) radio interface technologies are included in the standard and serve as the basis for the worldwide development of 5G networks. After 7–8 years of research and development, 193 countries have given their approval to the IMT-2020 standards. The World Radiocommunication Conferences have adopted Radio Regulations (Edition 2020), which details the spectrum and frequency band arrangements of radio interface technologies (WRC-19). The ITU has begun work on a report detailing the technological developments of terrestrial IMT-2030 systems in response to the worldwide success of 5G networks (June 2022). The paper presents a thorough analysis of the forces that are motivating the development of mobile broadband systems with enhanced radio-interface and radio-network performance. To help inform the ITU’s recommendation on the future of IMT beyond 2030, this report provides high-level principles for the design of the next generation of 6G networks [32, 33]. The 3GPP-led community of SDOs (standards development organization) has been hard at work conforming to the ITU’s vision standards. The work of the 3GPP is

31

Introduction

structured in a hierarchical set of parallel operations. Parallel Releases organize the technical specifications. A release consists of a collection of internally consistent set of features. Each release has a set schedule that determines the “freezing date”, or the point in time after which no new features or changes can be implemented. With each subsequent 3GPP release, the 5G development community is provided with a more solid foundation upon which to build the system, and new features can be added as needed [34, 35, 36, 37]. The 3GPP TSGs hold quarterly plenary meetings where the Working Groups (WGs) are updated on TSG business, discuss and approve their work, and make recommendations to the TSGs. Some 15–18 months are typically allotted for Release development, guaranteeing a short period and allowing 3GPP specifications to be developed in response to market needs and ready for use in actual products within a year or two of release freeze (completed). Additionally, the limited period for development guarantees that only the most important tasks are done for the release. As a result, 3GPP released the first set of technical specifications for 5G networks in early 2019 based on an entirely revised system architecture (Table 1.8). An early, less complex, NSA version of the system is specified in R15 edition. The SA version, as described by the R16 standard, will receive the remaining features and performance improvements in Phase 2. Virtualized network functions, support for a large number of concurrently communicating IoT devices, ultra-reliable low-latency communications, network slicing, edge computing, and an optimized service-based architecture model are all part of the project’s latest major release. IMT-2020 mandates globally compatible and uniform 5G mobile communication systems, and Edition R16 satisfies those standards. In

TABLE 1.8 5G Technology Evolution in 3GPP Project 5G Foundational Phase

5G Transformational Phase

3GPP Releases

R14 requirement [3GPP freeze March 2017] R15 5G Phase-1 [freeze June 2019] R16 5G Phase-2 [freeze July 2020]

R17 improvement [freeze June 2022] R18 5G-Advanced [freeze April 2024] R19 new verticals, apps, deployments

Enablement

eMBB, early enterprise, FWA

Milestones

DL/UL up to 10/4 Gbps, low-latency, 5G NSA/SA, mmWave, mMIMO, OpenRAN NSA and SA, FR1 and FR2 mmWave, MIMO enhancements, Multi-RAT Dual connectivity (MR-DC), Integrated Access and Backhaul (IAB)

eMBB, large-scale enterprise apps, non-public networks, new consumer use cases and multimedia services DL/UL up to 50/10 Gbps, ultra-lowlatency, Network Slicing (NS), mIoT

Features

Commercial availability

2019

high-precision positioning, RedCap NR Sidelink evolution, NTN NR, NTN IoT, support XR&enhanced multimedia, support AI/ML services 2025

32

5G NR Modeling in MATLAB®

addition, 3GPP has initiated the next stage of growth towards 5G-Advanced. Beginning in the first quarter of 2022, the R17 edition was completed, and by the second quarter of that year, work had begun on the R18 edition. 3GPP Research Projects 3GPP consortium of national or regional standards bodies has been producing technical specifications and proposing the 5G standard. ARIB, ETSI, ATIS, TTA, and TTC were the original partners to sign the 3GPP Agreement on December 4, 1998. At the time, they were also the only Market Representation Partner (MRP). As of 2015, TSDSI had joined the ranks of the seven SDO Partners that make up 3GPP, and the number of MRPs has grown to 26. The following Technical Standards Groups (TSG) are responsible for carrying out 3GPP’s standardization efforts: • Each of the TSG SA Service & System WG1, WG2, WG3, WG4, WG5, and WG6 groups is in charge of a different component of the system’s architecture and its services, including their definition, development, and maintenance. They also help with group coordination. • Throughout the physical layer, Layer 2, and Layer 3, the TSG RAN Radio Access Network WG1, WG2, WG3, WG4, WG5, and WGAH1 groups establish the functions, requirements, and interface of the access network. Additionally, UEs and base stations that implement the specified solutions must be subjected to conformity testing. • Terminals, interfaces, and capabilities; core network development; interconnection with external networks; and WG1, WG3, WG4, and WG6 of the TSG CT Core network are all under the purview of end-to-end networking. For UE to efficiently and effectively access various wireless networks, services, and verticals, 5G NR has been at the center of RAN standardization. The series of documents labeled 38​.x​xx are of use in NR radio technology. Technical groups within TSG produce deliverables such as reports and specifications that detail their work. • The first step in the specification process is an Initial Study (SI), which yields a Technical Report (TR) (1110 reports over R15–R18). Specification numbers of the type XX.9XX indicate that the report is meant to be issued by the organization partners as their publication. Specification numbers of the type XX.8XX (feasibility study reports) or 30​.x​xx of 50​.x​xx are assigned to reports that are not intended for publication but are instead only 3GPP internal working papers (planning and scheduling). • After preliminary research and consensus, an SI is transformed into a Working Item (WI). The technical specification (TS) then applies to the compatible WIs (R15–R18 releases consist of 3754 specifications). After each of the four quarterly TSG plenary meetings, the specifications are published. In March 2017, after preliminary research, 3GPP accepted a work item for NR standard as part of R15. It was proposed at the same meeting that the 5G development

33

Introduction

schedule be sped up such that the NSA standard would be finished by December 2017 and the SA NR system architecture option would be finished by June 2018. While the SA version is not dependent on LTE, the NSA version is developed in accordance with 4G LTE technical specifications for initial access and mobility management. The final stage of Phase 1, which included many architectural choices, was finished in March 2019. URLLC and mMTC scenarios, as well as the development of new vertical industrial applications, are the primary foci of the more than 70 standardization research projects that 3GPP has initiated in R16 Phase-2 (Table 1.9). Moreover, by the end of 2019, enhancements to the 5G standard have been finalized

TABLE 1.9 3GPP 5G Workplan 3GPP Standards Phase-1 Release 15

Phase-2 Release 16

5G-Advanced Release 17

Phase-3 5G-Advanced Release 18

Release 19

Capacity and Operational Efficiency

Vertical Expansion

• • • • • •

NSA and SA • eMBB Carrier aggregation operation • URLLC Inter-RAT between NR and LTE FR1 [450 MHz–7.125 GHz] MIMO enhancements • Industrial IoT (IIoT) Multi-RAT Dual Connectivity • URLLC (MR-DC) • Random Access Channel • Integrated Access and Backhaul (IAB) (RACH) • Cross Link Interface/Remote • UE positioning Interference Management (CLI/RIM) • Unlicensed Spectrum (US) • UE power saving • Vehicle to Everything (V2X) • FR2: [24.25–52.6 GHz mmWave] • MIMO enhancements • NR up to 71 GHz • Sidelink enhancements • NR up to NTN • DSS enhancements • RedCap (NR-Light) • IIoT/URLLC enhancements • Multicast and Broadcast • Coverage enhancements Services (MBMS) • IAB enhancements eMBB use cases: UL enhancement, FR2 mobility enhancement, DL MIMO enhancement, smart repeaters, Non-eMBB use cases: XR enhancements, sidelink enhancements, positioning enhancements, Cross-functionality use cases: Evolution of duplex operation, network energy savings, AI/ML RAN enhancements, • • • • •

Support frequencies up to THz. Advanced radio interfaces (including full duplex). Joint sensing and communication. Energy harvesting and passive IoT. Cognitive access to wireless technologies (cellular, satellite, Wi-Fi).

34

5G NR Modeling in MATLAB®

in areas including intelligent networks, extreme performance, widened spectrum, and applications. Phase 1 is defined by the technical requirements of version R15, whereas Phase 2 is defined by R16. Performance-wise, R16 satisfies all of the IMT-2020 requirements, and both performance and features will continue to advance in subsequent releases. The R17 revolutionary phase was completed in 2022, marking a radical shift toward the industrial verticals. Future ideas like AI and ML, full duplex operation, and online energy savings are addressed in the R18 version, the foundation of the new 5G-Advanced standard. As the sequel to R18 and the stepping-stone to 6G’s revolutionary new features and efficiencies, 5G-Advanced Release 19 is the second major revision of the 5G standard. Edition R17 establishes the groundwork for 3GPP’s upcoming 5G-Advanced release, which will usher in the next stage of 5G beginning with R18. The 6G system, outlined in Edition R18’s blueprints, will not fully materialize until the decade’s conclusion. The trend is moving towards more specialized applications in the smart grid and network rail industries, as well as in high-precision location, timing-resilient services, the tactile Internet, personal IoT, and even extraterrestrial systems. The optimization of 5G systems, advancements in network slicing, and characteristics like the incorporation of AI/ML models into frameworks, data integrity, and service function chaining are other approaches. Phase 1 is defined by the technical requirements of version R15, whereas Phase 2 is defined by R16. Performance-wise, R16 satisfies all of the IMT-2020 requirements, and both performance and features will continue to advance in subsequent releases. The R17 revolutionary phase will be completed in 2022, marking a radical shift toward the industrial verticals. Future ideas like artificial intelligence and machine learning, full duplex operation, and online energy savings are addressed in the R18 version, the foundation of the new 5G-Advanced standard. As the sequel to R18 and the steppingstone to 6G’s revolutionary new features and efficiencies, 5G-Advanced Release 19 is the second major revision of the 5G standard. The March 2023 3GPP Plenary sessions’ last focus was on R18’s feature development and timeline. On schedule, R18’s remaining Stage 2 architectural work was wrapped up in June 2023, paving the way for Stage 3 protocol development. The ASN.1 functional freeze date is set for June 2024, and the ASN.1 ASN.2 freeze date is set for March 2024. The development of mobile telecommunications system technical requirements begins at Stage 1. At this point in the process, all of the stakeholders in the project have come together to identify and settle on the system’s requirements. This involves determining the most important aspects of the system, such as its features and capabilities, as well as the restrictions that must be taken into account. Stage 1 produces a list of broad criteria that will serve as a roadmap for the rest of the system’s development. • In the second phase, precise technical requirements are defined. In this phase, we take the foundation laid in Stage 1 and determine the precise technical solutions we will employ to put the system into action. System components including radio access, the backbone network, and the services all need to have comprehensive protocols and processes developed for

Introduction

35

them. To guarantee that the system is functional and compatible with other systems, this phase also involves the creation of test cases and procedures (functional freeze June 2023). • Once the functional elements have been mapped into the physical parts, the third stage is the actual implementation of functionality and protocols at physical interfaces between the physical elements (freeze March 2024). In order to make sure the systems are up to par with the standards set in earlier phases, this stage entails developing precise specifications and testing them. As part of this process, the connectivity and performance of the network and its associated devices are examined. • Once the functional elements have been mapped into the physical parts, the third stage is the actual implementation of functionality and protocols at physical interfaces between the physical elements (freeze March 2024). In order to make sure the systems are up to par with the standards set in earlier phases, this stage entails developing precise specifications and testing them. As part of this process, the connectivity and performance of the network and its associated devices are examined. 3GPP R17 Transformational Phase Improvements to the core 5G technology are addressed in 3GPP R17. There are over 40 distinguishing features in this release, and they can be roughly broken down into three categories: new ideas, enhanced features from R16, and refined features from R15. From the perspective of the 5G architecture, R17 includes but is not limited to improved support for Industrial IoT (IIoT) and Non-Public Network (NPN), multicast and broadcast architecture, edge computing, and network automation. The collection of system projects concerning the verticals and technological enablers has been authorized by the technical specification committee SA WG2. Coverage and capacity optimization, load balancing optimization, network slice instance resource allocation optimization, and self-establishment of network function are only some of the tasks that should be made easier with the help of Self-Organizing Networks (SON) (including automated software management and automatic network configuration data handling). The primary RAN topics of interest for inclusion in the R17 version were recognized in June 2019 by the 3GPP community. Stage 3 freeze occurred in September 2021, the ASN.1 specification was made public in December 2021, and the specification phase was completed in the first quarter of 2022. By streamlining the 5G protocol, 5G RedCap (NR-Light) makes it possible to operate 5G networks on devices with less powerful hardware. Work is being done to enhance V2X’s use of IIoT, MIMO, and Sidelinks (SL). The first steps toward expanding 5G NR’s frequency range to include frequencies above 52 GHz, including support for satellite Non-Terrestrial Networks (NTNs) and coverage augmentation techniques, have been taken (Table 1.10). 3GPP R18 5G-Advanced Project in TSGs RAN and SA WG2 The content of the R18 work/study item package was mostly decided at the TSG working meeting #94 in December 2021. The introduction of novel ideas like ML

36

5G NR Modeling in MATLAB®

TABLE 1.10 3GPP R17 Features in TSG SA WG2 Enhancements and Second Phases • • • • • • • • • • • •

• • • • •

Further enhancements on NR MIMO. NR Sidelink. Dynamic spectrum sharing. Industrial IoT/ URLLC. NR positioning. NR coverage. Non-Public Networks (NPN). Multi-radio DCCA mesh. NB-IoT and LTE-MTC. Integrated Access and Backhaul (IAB). SON and minimization of drive tests. User Plane (UP) function enhancements for control and 5G Service-Based Architecture (SBA). Network automation for 5G Phase-2. RAN Slicing. Network Slicing (NS) Phase-2. Edge Computing (EC) in 5GC core network. Vehicle-to-Everything (V2X) enhancements.

Further Developments • • • • • • • • • • • • • • • • •

52.6–71 GHz with existing waveform. NR over Non-Terrestrial Networks (NTN). 5G Multicast-Broadcast Services (MBS). Multi-SIM. NR Sidelink relay. . NR Quality of Experience (QoE). Satellite components in 5G architecture. Proximity-based services in 5GS. Advanced interactive services. Access traffic steering, switch and splitting support in the 5G system architecture. Unmanned aerial systems. Multimedia priority service. 5G wireless and wireline convergence. 5G LAN-type services. NR eXtended Reality. IoT over Non-Terrestrial Networks (NTN).

and AI were confirmed. Standardization groups are now working on a comprehensive plan for developing the requirements that will comprise the R18 standard’s final edition in 2024. Multicast and Broadcast Services (MBS), extension into the FR2 frequency mmWave range, and support for satellite communications NTN for smartphones and IoT devices are all examples of how the standard has evolved since R17. While 3GPP’s technical team is hard at work on R18, ideas for R19 are beginning to take shape. Figure 1.7 shows the time for 3GPP R18. In May of 2021, the project coordination group formally unveiled R18 as 5G-Advanced (PCG). With over 500 proposals from 80 firms and 1200 participants, the 3GPP online Workshop in June 2021 kicked off the standardization process. When first organized, the concepts were roughly grouped into three categories: eMBB, non-eMBB evolution, and cross-functionalities. Following a week of deliberation, the plenary session settled on 17 points of discussion, including 13 broad issues, three sets of RAN-specific subjects (WG1–3), and one set of RAN-specific topics (WG4). Most of the discussions center on new and improved features seen in R16 and R17. These include MIMO, Uplink, Mobility, and Precise Positioning. Many of the proposed research and study topics focus on enhancing systems to help network operators make the most of their spectrum and radio resources, allowing for better service for a wider variety of connected devices (Table 1.11). Improvements are being made to DL/UL links for MIMO radio systems, Integrated

37

Introduction

FIGURE 1.7  3GPP R18 timeline.

TABLE 1.11 3GPP R18 Approved Projects in TSG RAN (SI Initial Study, WI Working Item) • • • • • • • • • • • • • • •

MIMO evolution for Downlink and Uplink (WI). AI/ML for NR Air Interface (SI). Evolution of NR duplex operation (SI). NR Sidelink evolution (WI). Expanded and improved NR positioning (SI/WI). NR RedCap UE complexity reduction (SI/WI). Network energy savings (SI/WI). Further NR coverage enhancements (WI) Enhancement NR dynamic spectrum sharing (WI). Low-power Wake-Up Signal (WUS). Receiver (WUR) for NR (SI). Multicarrier enhancements for NR (WI). Mobile IAB (WI). AI/ML for NG-RAN (SI/WI). Further enhancement of data collection for SON and MDT (minimization drive test) in NR (WI). • Enhancement on NR QoE management and optimizations for various services (WI).

• • • • • • • • •

Further NR mobility enhancements (WI). XR enhancements for NR (SI). NR sidelink relay enhancements (WI). NR NTN enhancements (WI). IoT-NTN enhancements (WI). NR MBS enhancements (WI). NR support for UAV (WI). Dual Tx/Rx Multi-SIM (WI). IDC (in-device co-existence) enhancements for NR and MR-DC dual connectivity (WI). • Mobile Terminated-Small Data Transmission (MT-SDT) for NR (WI). • NR support for dedicated spectrum less than 5 MHz for FR1 (WI).

38

5G NR Modeling in MATLAB®

Access and Backhaul (IAB) nodes are becoming mobile, smart repeaters are becoming situationally aware, mobility has increased, full-duplex transmission is near, UE power consumption and basic bandwidth processing are being optimized, and networks are being designed with the help of AI and ML techniques [38]. • Objectives of working item enhancements NR MBS are to support multicast reception by UE in radio resource control RRC inactive state, Uu interface signaling enhancements for UE to use shared processing for MBS broadcast and unicast reception, as well as enhancements to improve the resource efficiency for MBS reception in RAN sharing scenarios. • Objectives of working item XR enhancements for NR are to support XR-awareness in RAN (QoS metrics, traffic characteristics, and handling), power-saving techniques (periodicity, multiple flows, jitter, latency, reliability), as well as capacity improvements (more efficient resource allocation and dynamic scheduling/grant enhancements). • Objectives of working item AI/ML for NR air interface are to support algorithms for air interface enhanced performance and/or reduced complexity/ overhead. Channel State Information (CSI) feedback enhancement (reduction in overhead, improvement in prediction accuracy), beam management (prediction in time and/or space for overhead and latency reduction, as well as selection accuracy improvement), and positioning accuracy enhancements comprise the initial set of use cases. Lifecycle management for AI/ ML models, datasets, and terminology are all addressed in the working study. Actual AI/ML model and algorithm specifications are deferred until the implementation phase (Table 1.11). Construction on RAN1 began in 2022Q2 and on RAN2/3/4 in 2022Q3. The functional freeze for RAN1 was scheduled for September 2023, while for RAN2/3/4, it was scheduled for December 2023, giving R18 a total period of 18 months. All SA WGs have completed Stage 2, and 3GPP is on track to provide the final, stable R18 ASN.1 specifications by the target date of June 2024. Table 1.12 displays the roster of approved tasks and research topics for R18 SA WG2 capabilities. The 3GPP Stage 2 system architecture and services, comprising user equipment, access network, and core network, are developed based on the services requirements specified by SA WG1. It specifies the primary components of the system and the relationships between them. It also specifies the primary features and the data flow between the entities involved. Proposed areas of study and development included network topology changes, XR (extended reality), satellite connections, broadcast/multicast services, sidelink, and RedCap. The most interesting and exciting topics were XR media services and AI/ML. • Objectives of working item architecture enhancement for XR and media services are better support of advanced High Data Rate Low Latency (HDRLL), AR/VR/XR, and tactile/multimodality communication. Included improvements are those for transmitting QoS and policy upgrades

39

Introduction

TABLE 1.12 3GPP R18 Approved Projects TSG SA WG2 Enhancements and Second Phases • System enabler for service function chaining. • MPS when access to EPC/5GC is WLAN. • Generic group management, exposure, and communication enhancements. • Access traffic steering, switching, and splitting support in the 5G system architecture; Phase-3. • Enhanced support of NPN Phase-2. • Phase-2 for UAS, UAV, and UAM. • Extensions to the TSC framework to support DetNet. • 5G Timing Resiliency and TSC & URLLC enhancements. • RedCap Phase-2. • Vehicle-mounted relays. • 5GC Location services Phase-3. • Edge Computing Phase-2. • 5G system with satellite backhaul. • Support for 5WWC Phase-2.

Further Developments • • • • • • • • • • • • • •

Network Slicing Phase-3. 5G AM policy Phase-2. personal IoT Networks. Evolution of IMS multimedia telephony service. 5G multicast-broadcast services Phase-2. Extended Reality (XR) and media services. Ranging-based services and sidelink positioning. System support for AI/ML-based services. 5G UE policy Phase-2. Enablers for Network Automation for 5G Phase-3. Satellite access Phase-2. UPF enhancement for exposure and SBA. Proximity-based services in 5GS Phase-2. Seamless UE context recovery.

and power management in consideration of the traffic pattern of media services; enabling multimodality service; and exposing the network to support interaction between 5GS and applications. • Working item of architectural enhancements for 5G MBS Phase-2 evaluates further enhancements to expand on the scope for MBS including end-to-end procedures/functionalities and architecture. The specific goals include facilitating the delivery of group messages for RedCap devices and identifying potential performance difficulties for a large number of public safety UEs while also supporting the end-to-end delivery of MBS traffic to a large number of UEs. • Working item of enhanced support of NR RedCap Phase-2 investigates potential enhancements of 5GS system to enable the support of RRC inactive state with Extended Discontinuous Reception (eDRX) cycle as well as MT control messages between network functions in a 5G core network and data handling for UE with eDRX cycle. • Objectives of working item 5G system support for AI/ML-based services are investigating 5GS system assistance in support model distribution, transfer, and training for various applications (video/speech recognition, automotive) in AI/ML operation splitting between endpoints, model/data distribution and sharing over 5G system, as well as distributed/Federated Learning (FL) over 5G system. The detailed objectives include supporting

40

5G NR Modeling in MATLAB®

the application layer AI/ML operations, possible QoS as well as policy enhancements. 3GPP R19 Bridge to 6G The first R19 planning discussions occurred at the March 2023 3GPP Plenary meetings. There would be more fine-tuning of the material up until December 2023, although two planning workshops have already clarified the scope and timeline of R19. June of 2023 saw the beginning of the TSG’s RAN and SA workshops. There have been over 550 proposals submitted for 5G-Advanced features, giving a glimpse into the future of 5G radio and network designs. It is anticipated that the R19 specs will be locked and finished by the end of 2025. To produce product standards, the work in a 3GPP release feature normally goes through two phases: a study phase and a normative phase. Coordinating the research phase with feature-specific Study Item Descriptions (SIDs) and the normative phase with Work Item Descriptions (WIDs). Figure 1.8 shows the time for 3GPP R19. R19 is the successor to R18 and the stepping-stone to 6G, the next generation of 5G-Advanced. The result was a collection of enhancements that expanded upon the structural norms being established in R18. These enhancements to the radio and system performance will also result in enhanced services, such as augmented reality. The R19 standards will continue to build on the significant themes introduced in R18, such as increased energy efficiency, enhanced coverage, and enhanced mobility performance, while also introducing new themes, such as 5G femto BTS or

FIGURE 1.8  3GPP R19 timeline.

41

Introduction

TABLE 1.13 3GPP R19 RAN Topics Category • • • • • • • • • •

AI/ML Air interface. MIMO evolution. Duplex evolution. Ambient IoT. Network energy-saving enhancement. Mobility enhancement. NTN evolution. XR evolution, SON/MDT, Channel modeling for further evolution.

• RAN1 candidate topics (LP-WUS/WUR, multicarrier enhancement, coverage enhancement, positioning enhancement, SL evolution). • RAN2 candidate topics (NCR, SL relay enhancement, UAV/UAM, MU-SIM, broadcast/ multicast, UE aggregation, collaboration, backup). • RAN3 candidate topics (topological enhancements, QoE).

• Lean protocol stack/high-speed packetization/Layer2 UP enhance. • RAN architectural enhancement / AS security enhancement. • Network/outer coding • RedCap enhancement/High reliability and low complexity IoT. • Timing as a Service (TaaS)/High accuracy timing service. • SDT enhancement. • LTE enhancement • Dynamic UE capability update. • Idle/inactive enhancement. • RAN slicing enhancement.

TABLE 1.14 3GPP R19 SA Topics • Satellite architecture enhancements. • XRM enhancements and Metaverse. • AI/ML enhancements • Multiaccess (Dual 3GPP + ATSSS Enh). • Integrated Sensing and Communication.

• Ambient IoT. • Energy efficiency/ Energy saving as a Service. • IMS and NG_RTC enhancements. • Edge Computing enhancements. • Proximity Services enhancements.

• TSC/URLLC/TRS enhancements. • Network sharing. • User identities + identification of device behind RG/ AP. • 5G Femto.

• UAS enhancements. • VMR enhancements. • UPEAS enhancements.

combined communication and sensing. Preparatory work toward 6G has also begun in the workshops. Although the full R19 requirements will not be ready until 2025, this preliminary workshop discussion provides a glimpse into the future. The R19 RAN workshop (Table 1.13) and SA workshop led to the following topic suggestions (Table 1.14). Until December 2023, there was room for more debate and explanation on any issue. Projects headed by RAN1, RAN2, and RAN3 will be TSG RAN’s primary emphasis in December 2023, followed by those led by RAN4 in March 2024. After two days of in-depth discussions, TSG SA identified 17 core and 15 miscellaneous candidate topics for inclusion in R19. SA3 (Security), SA4 (Multimedia Codecs, Systems, and Services), and SA5 (Release 19) are all having conversations

42

5G NR Modeling in MATLAB®

FIGURE 1.9  ITU IMT-2030 and 3GPP 5G R19, 20 and 6G R21 timeline.

on R19 at the same time (Management, Orchestration, and Charging). Topics like AI/ML air interface (mobility improvement), NTN evolution (regenerative payload architecture), duplex evolution, network energy saving enhancement, XR evolution (capacity improvement), AI/ML for NG-RAN (model training, data collection to improve energy saving), and NCR enhancement are all continuations from R18. Work on the use cases and normative service criteria for R19 Stage 1 is ongoing in SA1 (Services) and is scheduled to be finished by December 2023. A forthcoming liaison from ITU-R relating to finishing the IMT2030 framework paper (Figure 1.9) triggered initial discussions on the 6G work plan in SA. ITU-R WP5D shared the draft new recommendation Framework and overall objectives of future development of IMT for 2030 and beyond (IMT-2030) finalized in June 2023 [39]. IMT-2030 technical proposals are due to ITU-R in 2028, followed by self-evaluations in 2029, and finally, adoption as the IMT-2030 standard in 2030, as outlined in the draft recommendations. Many people suggested beginning 6G planning as a result of this. A 6G workshop is planned for the end of Release 19 (mid-2024), Release 20 will include Study Items for 6G, Release 21 will include Work Items, and the first 6G release will be ready in 2029 for submission to IMT-2030 with self-evaluation, although there are some minor differences between the proposals from different members. Release 21 will likely be the first 6G release, with a release date in 2029, while there is some uncertainty about the precise timing of the 6G workshop and schedule (either the beginning or the end of 2029).

1.3.2 Support for Multimedia Applications As part of the R16 and R17 specifications, 3GPP has begun developing features for multimedia services and applications. These include edge processing, analytics, and event exposure as enablers for 5G media streaming; advancements for LTE-based 5G broadcast and hybrid services; 5G Release 17 TS 23.247 MBS and 5G Media Streaming (5GMS); and eXtended Reality (XR) experiences [40, 41].

Introduction

43

The efficiency with which network resources are used can be enhanced by using broadcast/multicast technologies in this age of media streaming and expanding data traffic. The 3GPP standards provide a lot of advantages. In many cases, only minor alterations to the already deployed mobile network are needed for services to be offered over the already existing infrastructure and spectrum. The method can eliminate the need for unicast for many forms of data flow. For instance, the distribution of duplicate or real-time content online. Considering the bandwidth demands of multimedia services, especially video, this addition can help make networks more efficient. A huge number of users or UEs can receive broadcasts thanks to 3GPP broadcast/multicast technology. As well as the broadcast industry, other sectors also benefit from the 3GPP broadcast/multicast, particularly public safety communications. Another possible use case is V2X, where broadcast can deliver messages or warnings over an Intelligent Transportation System (ITS) to infrastructure, vehicles and all the devices within. For dynamic switching of broadcast/multicast service delivery between multicast (PTM) and unicast, the MBS architecture was established in Release 17, along with improvements to the 5GS to handle broadcast and multicast (PTP). To enable media streaming over 5G, the 5G MBS user service architecture was extended to handle both pure broadcast/multicast and hybrid unicast/broadcast usage. Both exploratory and normative work for MBS is being done in the current versions (R18 and 19). The entertainment, education, remote control, communication, and virtual meeting industries are only a few of the ones where XR is expected to boost efficiency and ease. It has broad applicability across a variety of fields, from healthcare and medicine to retail and logistics to production and beyond. The term “Extended Reality” (XR) encompasses a wide variety of immersive technologies, including but not limited to “Virtual Reality” (VR), “Mixed Reality” (MR), and “Augmented Reality” (AR). However, the truly transformative potential of MR and AR lies beyond what VR can deliver. With AR, users are present in reality and can move freely, even when using their Head-Mounted Device (HMD). Because the user’s arm is free, AR technologies drastically change user interaction and efficiency. • XR-Specific Service Requirements XR is an umbrella word that incorporates applications such as AR, VR, or other forms of augmented and immersive reality applications. When compared to standard mobile broadband services, XR as a service stands apart due to its need for low latency and high data rates in sync with XR-codec periodicity. Particularly problematic is the fact that the frame rate of many video codecs is inconsistent, making it a poor fit for the frame structures employed by 5G networks. Incompatible with the 10 ms 5G frame structure and the internal transmission time of 1 or 0.5 ms (depending on the frequency band and the associated subcarrier spacing) is a typical frame rate of 60 frames per second (fps), which would result in a periodicity of about 16.67 ms. In addition to the video data itself, it is important to provide for the transmission of control/pose update signals on a somewhat regular basis while keeping the experienced latency below 10 ms. In addition, the solutions

44

5G NR Modeling in MATLAB®

will need to be flexible enough to accommodate the varying timing requirements of the various XR applications. • Key Considerations for the Support of XR The first step in providing adequate support for XR traffic is identifying it. One way to do this is to add support for identifying the packets that make up an XR service to the 5G QoS flow identifiers. Once XR packets have been identified, the scheduling algorithm must be adjusted to take into consideration the frame rate and maximum jitter for that service. In addition, when dealing with services like VR, there is a compromise to be made between latency and the required maximum data rate. Only content that fills the user’s field of view will be transmitted accurately when the latency of the connection is low enough to react to the user’s shifting attention. Instead, parts of the vision that are not ordinarily in the field of view at that instant but still require high accuracy must be transmitted to compensate for the increased delay. Obviously, the servers providing the service need to be located somewhat close to the mobile user in order to reap the benefits of considering gaze focus. Since portable, lightweight devices are favored for XR services, the UE’s ability to conserve power is particularly vital. While a high data rate is ideal for reduced latency, it drains an excessive amount of power from the UEs. By permitting DRX operation during periods when XR data is not arriving, the UE can save power and improve the usability of XR services by decreasing the amount of processing that must be done at the receiver. In addition, there are positive effects on network power consumption from intentionally interrupting the data stream. A specific level of mobility performance from the XR is required before it can be deemed a genuine mobile service. While the stability of the connection is vital, it is also critical to limit interruption times to a minimum because, in the latter case, the motion-related control feedback slows excessively, or the data flow disruption is evident in the end-user video stream. Additional 5G-Advanced features, including expanded uplink coverage and system capacity, will aid in the distribution of XR services. Since XR application processing in the network must be done close enough to the end user to minimize overall end-to-end latency, the benefits of XR directly correspond to the advantages of Edge Computing (EC). The 3GPP developed a traffic model and assessment assumptions for XR evaluation over NR after researching possible improvements for XR delivery over 5G-Advanced. XR enhancements are already being detailed for R18. This significantly enhances the efficiency of delivering XR services and makes them available to a larger number of concurrent XR users than in the first iteration of 5G networks. Since XR necessitates end-to-end handling in the radio access network and edge computing, most effort is focused on improvements to the core network. In order to adapt to the needs of XR services, we focus on the development of QoS and application awareness. In addition, 3GPP is working to establish standards for appropriate audio and video codecs in relation to XR service delivery, as these will help facilitate XR service delivery for a wider audience.

Introduction

45

• 3GPP R18 Architecture Support for XR and Media Services (XRM) In R18, 3GPP SA2 started the XRM Work Item to find ways to improve 5GS’s features and capabilities. Multimodal transmission, 5G System (5GS) information disclosure, PDU set-based QoS management, uplink/downlink transmission synchronization, packet delay variation monitoring/reporting, and power efficiency advancements are just a few examples. In order to provide a better experience for users, XR services incorporate a wide range of data streams, including audio, video, sensor, pressure, and touch. In the present 5GS, only one data flow is subject to policy control. To guarantee the coordinated transmission of multimodal data, alignment policy control is now being added to 5GS policy control. This can take the form of requiring all multimodal data to have the same 5QI, the same priority, or integrated network resource allocation. An application can profit from the 5GS’s disclosure of network information, which allows it to adjust the media codec or traffic rate in real-time. Two methods have been standardized: marking Low Latency, Low Loss, and Scalable Throughput (L4S) with Explicit Congestion Notification (ECN) and exposing Application Programming Interface (API) data to Application Functions (AF). 5G specifies the estimated bandwidth computed by the Network Analytics Function (NWDAF) computation to the application server in addition to the previously specified parameters. QoS regulation in conventional mobile networks is based on the concepts of flows and packets. However, the interaction between packets is critical for interactive media services like XR, and this was not taken into account in the previous scheduling approaches. In addition, the user experience might be affected differently by various media units, even when they are all part of the same stream. Therefore, these media units do not have special relevance from the media layer's point of view. To aid in the aforementioned integrated and differentiated media unit transmission, the term “PDU Set” is coined to denote the group of Protocol Data Unit (PDU) packets that together convey a media unit (frame or video slice). A latency indicator and real-time latency requirements are provided by the 5G system’s AF to the PCF. This means that the service data flow must control the latency overhead to guarantee that it does not exceed the latency requirement for real-time operations. The PCF needs to break down the actual delay into a UL and DL Packet Delay Budget (PDB). The restriction is that the UL/DL PDB may be unequal, but their aggregate cannot be more than the real-time latency. The PCF sets two Policy and Charging Control (PCC) rules for the UL and DL streams in accordance with PDBs and allocates 5QIs (QoS IDs). In the 5G system, the Packet Delay Variation (PDV) required for a certain QoS flow is supplied by the AF . The PDV can show how reliable the network’s transmission is. Once the PCF approves the PDV requirements, the necessary PCC rules for QoS monitoring can be developed and sent to the SMF. With this, packet delay QoS monitoring will begin. The PCF can determine the PDV using IETF RFC 1889 or RFC 3393 once it has received the packet delay values. In general, XR terminals, which can be glasses or headsets, can handle significant processing requirements with a comparatively small amount of power. There is more

46

5G NR Modeling in MATLAB®

work to be done on the issue of power conservation at these terminals. Most XR and media services have a media stream that repeats at roughly regular intervals. For example, a video with a frame rate of 60 fps will have continuous bursts that repeat every 16.67 ms. The RAN/terminal can account for periodicity by computing the Connected Mode Discontinuous Reception (CDRX) cycle length, allowing for improved timing of media packet arrival and power conservation. Another important piece of data is when the burst will terminate. Because of this, RANs can tell when a broadcast is over and tell UEs to go into power conservation mode immediately. The above study suggests that 5GC can transmit periodicities and the N6 jitter range of media services via control plane signals to the RAN node. It can also signal the end of a burst to the RAN node using UP packets. With this information, the RAN may set up the CDRX in a way that facilitates efficient power conservation without impairing data transmission. • XR for NR High bit rates and low latency are required for XR services, creating new challenges for wireless connectivity. To quantify these issues, 3GPP has conducted in-depth research across multiple working groups on how XR services are provided (RAN1, RAN2, SA2, SA4). The first mechanisms that these investigations have demonstrated to be helpful will be presented in the recently authorized R18 work items. The term “Extended Reality” (XR) is used to characterize the hybrid real-and-virtual settings and human–machine interactions made possible by computers and wearables. Mixed reality (MR) is an advanced form of augmented reality (AR) in which some virtual elements are inserted and can be interacted with; AR refers to a reality in which additional content is superimposed on the user’s environment; and virtual reality (VR) aims to give the user the impression that they are physically and spatially there. For an XR experience without pixelated images, 90 or even 120 fps at resolutions up to 8K per eye are required. An acceptable XR experience demands frame rates of at least 60 fps and 2K resolution per eye. The resulting bit rates are in the tens of Mbps. It takes powerful XR engines to generate content at high bit rates, and these engines typically cannot function on the consumer device due to heat dissipation and battery life limitations. Since this is the case, rendering is typically aided or shared across the network, as seen in Figure 1.10. UE sends uplink sensor data to the cloud, which then develops

FIGURE 1.10  XR split rendering.

Introduction

47

and renders multimedia content and sends it back downlink to UEs for display. Then, tens of Mbps must be transmitted via NR. Even though this reduces the device’s processing needs, it increases its latency needs. In order to prevent nausea and provide a more realistic experience, the time between when anything moves and when the corresponding photon is produced is capped at 20 ms. Split rendering accounts for the time it takes for the UE to transmit sensor data uplink, the time it takes for the core network to transport and process the data, and the time it takes to deliver the multimedia data back to the user device for display. The resulting delays for the RAN in both directions, downlink and uplink, are just about 10–15 ms. In conclusion, for XR services that make use of split rendering, RAN must guarantee tens of Mbps with a latency of around 10 ms assessed at the transport/application layer. The combination of low latency and massive data rates presents a new challenge for NR. XR awareness aids in uplink and downlink radio resource optimization by employing the 3GPP SA WG2-specified concepts of PDU Set and Data Burst. Data Bursts and PDU sets enable the RAN to identify packets that include content (such as a portion of an image or audio frame) that the application treats as a single unit for analysis. The R18 XR study evaluated several strategies for reducing energy use. Aligning UE DRX and XR traffic is shown to be critical for improving capacity performance and reducing power consumption. The most common XR frame rates are 60, 90, and 120 fps, and these rates all correspond to non-integer periodicities (16.66, 11.11, and 8.33 ms, respectively). New processes will be introduced to deal with these reoccurring issues. For XR capacity increases, two PHY-related mechanisms are specified: a Configurable Grant (CG) term with multiple Physical Uplink Control Channel (PUCCH) occasions, and Uplink Control Information (UCI) displaying unused CG PUSCH occasion(s). Primarily, Layer 2 capacity increases inform the gNB of the UE’s transmission requirements. XR services require very low latency and huge data rates, so it is vital to carefully customize the grant to reduce padding and delay. This will be done by reducing quantization mistakes and increasing delay knowledge in the Buffer Status reports. The two requirements of low latency for some applications and high data rates for others are met by NR, but they have not yet been merged. The enhancements to the RAN will change this for XR, allowing NR to meet these new difficulties. Benefits of around 30% in capacity and power savings are anticipated as a result of those new enhancements.

1.3.3 Concluding Remarks and Further Study The introduction of 5G mobile networks is a thrilling development for the tech and telecom sectors. Compared to earlier generations of mobile networks, the 5G system provides expanded capacity and enhanced coverage, as well as quicker data speeds and lower latency. eMBB, URLLC, and mMTC are the service classes that

48

5G NR Modeling in MATLAB®

this infrastructure is built to serve. It is projected that 5G networks will become more widely available over the next few years as they are being rolled out in numerous nations. However, 5G networks are still in the process of being developed and deployed, with ongoing research and development aimed at enhancing the technology and extending its capabilities. In 2015, 3GPP started working together to define the minimal specifications for a 5G system and an evaluation methodology. This was in response to recommendations made by ITU-R. Rapid progress has been made toward the coming R18 standard with the launch of the 5G NR standard in R15. Fully Backward Compatibility, as addressed by 3GPP R18 5G between 5G and 6G, significant technical progress has been made. The year 2021 was spent getting ready for the transformative phase; the R18 standard was started in 2022, and its completion is anticipated for 2023 and 2024. The 3GPP technical specification working group SA WG2 architecture, which is responsible for creating the second stage of the mobile network, is the focus of our discussion. This group determines the network’s primary tasks and entities, their interconnections, and the data they share based on the services requirements developed by SA WG1. The general design of the RAN and the specification of its network interface protocols are under the purview of RAN WG3. 3GPP Release 19 is the second release of 5G-Advanced, it’s a continuation of R18, and also the bridge towards the 6G technology leap to new capabilities and efficiency. Release 20 is the technology foundation for the next-generation innovation platform towards finalization in September 2026. Release 21 will establish the roadmap for 6G by early 2028, including enabling technologies for scalable network architecture and air interface innovations that will initiate future wireless research.

REFERENCES



1. M. Shafi, A. F. Molisch, P. J. Smith, T. Haustein, P. Zhu, P. DeSilva, F. Tufvesson, A. Benjebbour, G. Wunder, “5G: A Tutorial Overview of Standards, Trials, Challenges, Deployment, and Practice”, IEEE Journal on Selected Areas in Communications 35(6), 1201–1221 (June 2017). 2. Y. Kim, Y. Kim, J. Oh, H. Ji, J. Yeo, S-J. Choi, H. Ryu, H. Noh, T. Kim, F. Sun, Y. Wang, Y. Qi, J. Lee, “New Radio (NR) and its Evolution toward 5G-Advanced”, IEEE Wireless Communications 26(3), 2–7 (June 2019). 3. B. Bertenyi, “5G Evolution: What’s Next?”, IEEE Wireless Communications 28(1), 4–8 (Feb. 2021). 4. W. Chen, P. Gaal, J. Montojo and H. Zisimopoulos, Fundamentals of 5G Communications: Connectivity for Enhanced Mobile Broadband and Beyond, McGraw Hill, 2021. 5. X. Lin and N. Lee (Eds), 5G and Beyond: Fundamentals and Standards, Springer, 2021. 6. F. Müller, J. Sorelius and D. Turina, Further Evolution of the GSM/EDGE Radio Access Network, Ericsson Review No. 3, 2001 (available online). 7. ETSI TS 101 356 V6.5.0 (1999-12), “Digital Cellular Telecommunications System (Phase 2+); General Packet Radio Service (GPRS); Mobile Station (MS) Supporting GPRS (GSM 07.60 Version 6.5.0 Release 1997)”, (available online).

Introduction







49

8. White Paper, LTE Release 9 Technology Introduction, Rohde and Schwarz (Available Online), 2011. 9. ETSI TS 136 322 V8.8.0 (2010-07), “LTE; Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Link Control (RLC) Protocol Specification (3GPP TS 36.322 Version 8.8.0 Release 8)”, (available online). 10. H. Holma, A. Toskala, K. Ranta-aho and J. Pirskanen, “High-Speed Packet Access Evolution in 3GPP Release 7 [Topics in Radio Communications]”, IEEE Communications Magazine 45(12), 29–35 (Dec. 2007). 11. ETSI Mobile Competence Centre, “Overview of 3GPP Release 6, Summary of all Release 6 Features, TSG #33”, 2006. 12. ETSI TS 123 228 V5.15.0 (2006-06), “Digital Cellular Telecommunications System (Phase 2+); Universal Mobile Telecommunications System (UMTS); IP Multimedia Subsystem (IMS) (3GPP TS 23.228 Version 5.15.0 Release 5); Stage 2”, (available online). 13. ETSI, “Overview of 3GPP Release 4, Summary of all Release 4 Features, TSG #26”, (available online) 14. 3GPP, “Overview of 3GPP Release 99 Summary of all Release 99 Features v.1.0, SP-030767”. 15. ETSI TS 136 101 V14.5.0 (2017-11), “LTE; Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) Radio Transmission and Reception (3GPP TS 36.101 Version 14.5.0 Release 14)”, (available online). 16. ETSI TS 136 331 V13.5.0 (2017-04), “LTE; Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol Specification (3GPP TS 36.331 Version 13.5.0 Release 13)”, (available online). 17. ETSI TS 136 212 V12.2.0 (2014-10), “LTE; Evolved Universal Terrestrial Radio Access (E-UTRA); Multiplexing and Channel Coding (3GPP TS 36.212 Version 12.2.0 Release 12)”, (available online). 18. ETSI TS 136 521-1 V11.1.0 (2013-07), “LTE; Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) Conformance Specification; Radio Transmission and Reception; Part 1: Conformance Testing (3GPP TS 36.521-1 Version 11.1.0 Release 11)”, (available online). 19. ETSI TS 136 300 V10.2.0 (2011-01), “LTE; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall Description; Stage 2 (3GPP TS 36.300 Version 10.2.0 Release 10)”, (available online). 20. X. Lin, “An Overview of 5G Advanced Evolution in 3GPP Release 18”, IEEE Communications Standards Magazine 6(3), 77–83 (Sept. 2022). 21. J. Jeon, G. Lee, A. A.I. Ibrahim, J. Yuan, G. Xu, J. Cho, E. Onggosanusi, Y. Kim, J. Lee, J. C. Zhang, “MIMO Evolution Toward 6G: Modular Massive MIMO in LowFrequency Bands”, IEEE Communications Magazine 59(11), 52–58 (Nov. 2021). 22. J. Peisa, P. Persson, S. Parkvall, E. Dahlman, A. Grøvlen, C. Hoymann and D. Gerstenberger, 5G Evolution: 3GPP Releases 16 & 17 Overview, Ericsson Technology Review (available online). 2020 23. L. Casaccia, Propelling 5G Forward: A Closer Look at 3GPP Release 16, Qualcomm (available online). 24. ETSI TS 123 501 V15.9.0 (2020-03), “5G; System Architecture for the 5G System (5GS) (3GPP TS 23.501 Version 15.9.0 Release 15)”, (available online). 25. W. Chen, J. Montojo, J. Lee, M. Shafi and Y. Kim, “The Standardization of 5G-Advanced in 3GPP”, IEEE Communications Magazine 60(11), 98–104 (Nov. 2022). 26. X. Lin, “An Overview of 5G Advanced Evolution in 3GPP Release 18”, IEEE Communications Standards Magazine 6(3), 77–83 (Sept. 2022).

50

5G NR Modeling in MATLAB®

27. W. Chen, X. Lin, J. Lee, A. Toskala, S. Sun, C. F. Chiasserini, L. Liu, “5G-Advanced toward 6G: Past, Present, and Future”, IEEE Journal on Selected Areas in Communications 41(6), 1592–1619 (June 2023). 28. ITU-R Report M.2410, “Minimum Requirements Related to Technical Performance for IMT-2020 Radio Interface(s)”, Nov. 2017. 29. ITU-R Report M.2411, “Requirements, Evaluation Criteria and Submission Templates for the Development of IMT-2020”, Nov. 2017. 30. ITU-R Report M.2412, “Guidelines for Evaluation of Radio Interface Technologies for IMT-2020”, Oct. 2017. 31. ITU-R Report M.2150, “Detailed Specifications of the Terrestrial Radio Interfaces of International Mobile Telecommunications-2020 (IMT-2020)”, Feb. 2022. 32. ITU-R Report M.2516, “Future Technology Trends of Terrestrial IMT Systems towards 2030 and Beyond”, Nov. 2022. 33. ITU-R WP5D Draft Recommendation, “Framework and Overall Objectives of the Future Development of IMT for 2030 and Beyond”, June 2023. 34. 3GPP SA TR21.915, “Release 15 Description; Summary of Rel-15 Work Items”, Oct. 2019. 35. 3GPP SA TR21.916, “Release 16 Description; Summary of Rel-16 Work Items”, June 2021. 36. 3GPP SA TR21.917, “Release 17 Description; Summary of Rel-17 Work Items”, Sep. 2022. 37. 3GPP SA TR21.918, “Release 18 Description; Summary of Rel-18 Work Items”, March 2024. 38. 3GPP RAN WG1 TR38.875, “Release 17; Study on Support of Reduced Capability NR Devices”, March 2021. 39. 3GPP RAN WG1 TR38.843, “Release 18; Study on Artificial Intelligence (AI)/Machine Learning (ML) for NR Air Interface”, June 2022. 40. 3GPP SA WG4 TR26.802, “Release 17; Multicast Architecture Enhancement for 5G Media Streaming”, June 2021. 41. 3GPP SA WG4 TR26.998, “Release 17; Support of 5G Glass-Type Augmented Reality/ Mixed Reality (AR/MR) Devices”, March 2022.

2

5G and LTE Network Architectures

4G Long Term Evolution (LTE) is a radio interface technology that uses Orthogonal Frequency Division Multiple Access (OFDMA) on the downlink and Single CarrierFrequency Division Multiple Access (SC-FDMA) on the uplink to achieve antenna diversity through multiple inputs and multiple outputs. Half-Duplex Frequency Division Duplexing (HD-FDD) is one of the duplexing methods supported by LTE [1, 2] to help it work with low-cost User Equipment (UE). HD-FDD operation differs from FDD in that a UE does not have to transmit and receive at the same time, negating the need for an expensive duplexer in the UE [3, 4]. LTE’s main selling point is its ability to handle peak data rates of up to 300 Mbps on the downlink and 150 Mbps on the uplink. The three main components of an LTE network are the Evolved Packet Core (EPC), the Evolved Universal Terrestrial Radio Access Network (E-UTRAN), and the MultimediaBroadcast and Multicast Services (MBMS). With LTE-Advanced, LTE’s capabilities are expanded to either surpass or at least meet the standards set by IMT-Advanced. The goal of LTE-Advanced is to increase data transfer speeds. Providing higher bitrates in a cost-effective manner while also fully satisfying the requirements set by the International Telecommunications Union (ITU) for IMT-Advanced, also known as 4G, was the primary motivation for the development of LTE towards LTEAdvanced—LTE Release 10. • Increased peak throughput (DL at 3 Gbps and UL at 1.5 Gbps). • Enhanced spectral efficiency, to 30 bps/Hz in Release 10 (from a maximum of 16 bps/Hz in Release 8). • Increased number of simultaneous active subscribers. • Enhanced cell edge performance (for example, for DL 2 × 2 Multiple-Input Multiple-Output (MIMO) at least 2.40 bps/Hz/cell is targeted). Carrier Aggregation (CA), improved multiantenna techniques, and support for Relay Nodes (RN) are the primary new features introduced in LTE-Advanced [5]. There are two main architectures for transitioning to 5G from LTE, and both were introduced by the 3rd Generation Partnership Project (3GPP): Non-Standalone (NSA) and Standalone (SA). By utilizing pre-existing LTE infrastructures, NSA allows for the rapid rollout of 5G services at a low cost. Due to the fact that there is only one Radio Access Technology (RAT) in SA, we can offer true 5G improvements optimized for the 5G New Radio (NR) architecture [6]. In this chapter, the architecture of LTE is described in detail, followed by the architecture of 5G, and then the various options for the NSA and SA of 5G are discussed in order to gain a clear understanding of the evolution from LTE to 5G. DOI: 10.1201/9781003465393-2

51

52

5G NR Modeling in MATLAB®

2.1 LTE/4G NETWORK ARCHITECTURE A complete LTE-based cellular network, including cells, UEs, base stations, gateways, relay nodes, and other entities, is depicted in Figure 2.1. The LTE Releases 10 through 13 can all make use of this architecture. Relay nodes and home-Evolved NodeBs (eNBs) were introduced to the LTE architecture beginning with Release 10 (i.e., LTE Advanced) [1, 7, 8, 9, 10]. This is the primary difference between the LTE Release 8 and 9 architectures. The base stations in earlier 3GPP Radio Access Networks (RANs) were managed from a centralized location. This is the base station controller (BSC) in GSM and the Radio Network Controller (RNC) in Universal

FIGURE 2.1  LTE advanced architecture.

5G and LTE Network Architectures

53

Mobile Telecommunications System (UMTS). The central controllers in these systems are in charge of configuring the radio links between the base stations and the wireless devices, monitoring the connections in real time to maintain quality of service, and switching over to a different base station as needed. Since these management tasks necessitate substantial resources if concentrated in a few higher-layer network nodes, LTE abandoned the idea of removing latency from the user path and to distribute them. The different Network Elements depicted in Figure 2.1 are defined as follows.

2.1.1 Evolved Packet System (EPS) LTE and System Architecture Evolution (SAE) are two of the components that make up EPS: E-UTRAN and EPC. The EPS is an IP-only architecture. The IP protocol will serve as the backbone for both synchronous and asynchronous datacom services. When a mobile device is turned on, an IP address is assigned to it, and when it is turned off, the address is made available to other devices [11].

2.1.2 Evolved Universal Terrestrial Radio Access Network (E-UTRAN) The EPS’s access component is the E-UTRAN, which was first announced in 3GPP Release 8. High spectral efficiency, high peak data rates, quick round trip time, and bandwidth and frequency flexibility are the primary needs for this access network. To create its flat design, the E-UTRAN just uses a collection of base stations called Evolved NodeBs (eNBs) (Figure 2.1). The eNBs typically communicate with one another via the X2 interface and with the Core Network (CN) using the S1-U and S1-MME interfaces; however, there is no centralized intelligent controller. The goal of LTE’s base-station information distribution is to shorten the time it takes to establish a connection and perform a handover. The LTE-Uu interface links the eNBs to the UEs, and the eNBs in turn link to the Type II RNs [1, 7, 8, 9, 10, 11]. The E-primary UTRAN’s parts are described as follows: (i) Evolved NodeB (eNB) Th eNB is the system component with the highest degree of complexity. Named after the first UMTS base station (NodeB), the “e” stands for “evolved” in this context. eNBs have three main parts: • Antennas. They are the most visible part of a mobile network. They are responsible for sending and receiving RF signals and determining the coverage’s “Shape”. • Radio modules, also called Radio Resource Units (RRUs). Every signal sent or received over the air interface must first be modulated or demodulated by these devices. In addition to these functions, they also carry out RF signal filtering and amplification and interconversion between digital data and RF signal.

54

5G NR Modeling in MATLAB®

• Signals sent and received via the air interface are processed by digital modules called Base Band Units (BBUs), which also serve as an interface to the CN via a high-speed backhaul connection. There are three main types of base stations [12]: • Figure 2.2 depicts a typical base station’s lumped structure, which includes the BBU and RRU, as well as a connection to the antenna. • Figure 2.3 [12] depicts a distributed base station, where the RRU is located on the tower and data is transferred to the BBU through an optical fiber connection. • Figure 2.4 [12] gives an illustration of an antenna and RRU from a base station that is tailored for massive MIMO integration. The radio module and the digital module are often connected via optical means, as is the case with many manufacturers. This allows the radio module to be placed near the antennas, reducing the required length of expensive coaxial copper wires. Significant cost reductions are possible with this approach, also known as Remote Radio Head (RRH), especially if the antennas and the base station cabinet cannot be positioned near one another. Bearer is a logical link between network entities that provides Quality of Service (QoS) features like latency, maximum throughput, etc. for the data that travels across it. A Radio Access Bearer controls all communications between a mobile device and a Radio Base Station (RAB). In contrast to early iterations of UMTS, where the base station was essentially an intelligent modem, LTE base stations function independently. In this case, it was

FIGURE 2.2  Traditional lumped base stations.

5G and LTE Network Architectures

FIGURE 2.3  Distributed base stations.

FIGURE 2.4  Integrated base stations.

55

56

5G NR Modeling in MATLAB®

decided to incorporate most of the RNC’s former responsibilities into the base station. Consequently, the eNB is in charge of not only the air interface but also: • Management of users and scheduling of air-interface resources. • QoS provisioning, including maximum data rate for background applications based on the user profile, minimum bandwidth requirements for realtime bearers, and latency. • Load balancing of multiple radio bearers serving multiple users simultaneously. • Mobility management. • Interference management or reducing the impact of its downlink transmissions on neighboring base stations. One innovation in 3GPP systems is the eNB’s ability to autonomously decide to move data from one eNB to another. In addition, the handover is performed independently from the network’s higher-layer nodes, which are only made aware of it after the fact [8]. Through the S1 interface, the eNB communicates with the EPC. The S1 interface consists of two distinct halves that share a single physical link. The S1 User Plane (S1U) is the interface portion responsible for carrying user data to and from the Serving Gateway (S-GW). To provide seamless handovers between various base stations, IP packets belonging to a user are tunneled across an IP connection. Users’ IP data packets can be seamlessly transferred to a new base station without affecting their experience thanks to tunneling. The user’s IP address remains unchanged while the destination IP address on layer 3 (the tunneling IP layer) is modified [8]. There are two uses for the S1 Control Plane (S1C) protocol, which is specified in the 3GPP TS 36,413. Firstly the eNB utilizes it to discover other nodes in the network, to communicate status and connection keepalive information, and to receive configuration information from the CN. Secondly, the S1C interface is utilized to transmit user-related signaling messages. For instance, the CN oversees authentication, providing encryption keys for usage over the air interface, and establishing a tunnel for the user’s data between the eNB and the CN whenever a device wishes to communicate over the LTE network. As soon as the user’s data tunnel is established, the S1C protocol is utilized to keep the connection alive and to coordinate a handover to another LTE base station [8]. There are two main reasons for eNBs to communicate with one another over the X2 interface. In the first place, the handovers can be managed locally at each base station. X2 interface allows for direct cell-to-cell communication if the destination cell is known and reachable. The S1 interface and the CN are used to complete the handover in the absence of the former. Interference coordination is the second application of the X2 interface. The X2 interface allows mobile devices to report the noise level and the perceived source to their serving base station, which can then communicate with the neighboring base station to come up with a solution [8]. For the eNB and the UEs to exchange information, the LTE-Uu radio interface is used. The eNB contains all the protocols and functionality necessary to complete this exchange and the other control operations of the LTE-Uu interface.

5G and LTE Network Architectures

57

(ii) User Equipment (UE) It is typically a portable device like a smartphone or a data card used in 2G and 3G networks, but it could also be integrated into a laptop. The user device’s internal architecture is depicted in Figure 2.5 [13]. UMTS and GSM share the same architecture. Instead of UE, the term Mobile Equipment (ME) refers to the actual means of communication. It is important to note that this is a singular unit in the case of a voice mobile or a smartphone. Mobile equipment, on the other hand, can be broken down into two subcomponents: the Mobile Termination (MT), which manages all the communication processes, and the Terminal Equipment (TE), which terminates the data streams. For instance, if the MT were an LTE card that plugs into a laptop, the laptop itself would serve as the terminal device [9]. Commonly referred to as the Subscriber Identification Module (SIM) card, the Universal Integrated Circuit Card (UICC) is a type of smart card. The Universal Subscriber Identity Module (USIM) [14] software that it runs keeps information unique to each user, like their phone number and the name of their home network. In addition, the USIM performs several calculations for security purposes utilizing the smart card’s stored secure keys. Mobiles utilizing a SIM from earlier GSM releases are not compatible with LTE, however, those using a USIM from Release 99 or later are. Moreover, LTE is compatible with mobiles running IP version 4, IP version 6, or a dual stack of IP versions 4 and 6. Each packet data network, such as the Internet or an internal company network, assigns a unique IP address to a mobile device. Another option is for the mobile to obtain both an IPv4 and IPv6 address. This is possible if the mobile and network support both versions of the protocol. There is a vast range of mobiles with respect to their radio capabilities [15], such as their maximum data rate support, the radio access technologies they are compatible with, and the carrier frequencies they support. Through signaling messages, mobiles communicate these capabilities to the RAN, allowing the E-UTRAN to exert proper control. The UE category is a grouping of the most significant skills; further information on the various UE categories may be found in [16, 17].

FIGURE 2.5  Internal architecture of a UE [13].

58

5G NR Modeling in MATLAB®

For the eNB and the UEs to exchange information, the LTE-Uu radio interface is used. The eNB contains all the protocols and functionality necessary to complete this exchange and the other control operations of the LTE-Uu interface. (iii) Type I and Type II Relay Nodes (RN) The high data speeds that can be attained are a major driving force for the deployment of LTE. Although data rates are lower for all technologies towards the cell boundary due to weaker signals and more interference, this is a common trade-off for achieving better coverage. MIMO, OFDM, and state-of-the-art error-correction techniques boost throughput in many scenarios, but they do not solve all the issues at the cell edge. Due to the increasing importance of cell edge performance as current technologies are being pushed to their limitations, it is important to investigate lowcost ways to improve cell edge performance. Unlike a repeater, which simply rebroadcasts the signal, LTE relaying modifies the original signal before retransmitting it. When a relay receives information, it demodulates and decodes it, corrects any errors it finds, and then sends out a fresh signal. Because of this, employing an LTE relay is preferable to using a repeater, which degrades signal quality by lowering the Signal-to-Noise Ratio (SNR). Simply put, relays can offer benefits including higher network densities, larger service areas, and a quicker rollout time. By transmitting their own synchronization channels and reference symbols, type 1 LTE relay nodes exert autonomous control over the cells they serve. To Release 8 UEs, Type 1 relays will appear to be functioning as a Release 8 eNB. By doing so, compatibility with older systems can be guaranteed. The most fundamental Type 1 relay only supports in-band, half-duplex communications. It is said that an LTE relay node is “In-band” when the connection between the base station and the relay node, or BS-RN link, and the connection between the base station and the UE, or RN-link, share the same carrier frequency. Type 2 relay nodes lack their own cell identity and appear identical to the primary cell. Any UE within range is unable to differentiate between a relay and the primary eNB within the cell. Control data can be transmitted through the eNB, while user data can be transmitted from the LTE relay [18]. (iv) Home eNodeBs (HeNBs) One type of femtocell base station is the Home eNB (HeNB), which can be purchased by a user to cover their house. A residential eNB is only accessible by mobile devices with a USIM from the same Closed Subscriber Group (CSG) as the eNB. Home eNBs can communicate directly with the EPC like any other base station, or they can use a centralized hub called a Home eNB gateway (HeNB-GW) to aggregate data from several HeNBs [9, 19]. (v) Home eNodeB Gateway (HeNB-GW) The HeNB-GW provides access to the CNs for HeNBs. The HeNB-GW consolidates connections from a large number of HeNBs via the S1 interface and ends the connection to existing CNs via the standard interface. It supports S1-C and S1-U

5G and LTE Network Architectures

59

network interfaces based on industry standards. It appears as an eNB to the Mobility Management Entity (MME) and as an MME to the HeNB. The HeNB-GW ends S1-C procedures not linked with the UE towards the HeNB and the MME. Optionally, it ends the S1-U link between the HeNB and Serving Gateway (S-GW) [20].

2.1.3 Evolved Packet Core (EPC) The EPC manages functions unrelated to radio access yet required for a comprehensive mobile broadband network. This comprises authentication, billing functionality, and the establishment of end-to-end connections, among others. Handling these services independently, as opposed to incorporating them into the RAN, is advantageous because it enables many radio-access technologies to be supported by the same CN [7]. The EPC represents a major change from the GSM/GPRS CN utilized by GSM and WCDMA/HSPA. EPC only supports access to the packet-switched domain; access to the circuit-switched domain is not supported. It comprises of various distinct sorts of nodes, as outlined below: (i) Mobility Management Entity (MME) The MME is the EPC’s principal control element. The MME is often a server located in a secure place on the operator’s premises. It functions only in the CP and does not participate in the UP data channel. The following interfaces end at the MME in the architecture depicted in Figure 2.1 [10]: • S6a. It allows MME and HSS to send subscription and authentication data for authenticating/authorizing user access to the evolving system (AAA interface) [21]. • S1-C. It serves as the control plane protocol’s reference point between E-UTRAN and MME. • S11. This is the point of reference between the MME and the S-GW. The interface is based on the Gn/GPRS Tunneling Protocol (GTP) GTP-Control (GTP-C) (interface between the Serving GPRS Support Node (SGSN) and Gateway GPRS Support Node (GGSN)) with some additional functions for paging coordination and mobility in comparison to the legacy Gn/GTP-C (SGSN-GGSN) interface. • S10. It connects MMEs and is utilized when the MME serving a user must be changed for one reason or another, such as due to maintenance, a failed node, or most obviously when a terminal transfers between two pools. Additionally, the MME has a logically direct CP link to the UE, which serves as the principal control channel between the UE and the network. The following is a list of the primary MME functions in the fundamental System Architecture Configuration: • Authentication and Security. As soon as a UE first registers with a network, the MME begins the authentication process by doing the following: determining the UE's permanent identity based on the last network it visited or the

60

5G NR Modeling in MATLAB®

UE itself; requesting the authentication vectors from the Home Subscriber Server (HSS) in the UE’s home network, which contain the authentication challenge—response parameter pairs; sending the challenge to the UE; and finally, comparing the UE’s response to the parameters in the authentication vectors for the UE to be trusted, this feature is essential [10]. • Mobility Management. All UEs within the MME’s service area are tracked and recorded. The MME creates a record for a UE and notifies the HSS in the UE’s home network of its location upon the UE’s initial registration to the network. The MME requests that the eNB and the S-GW it chooses for the UE are configured with the necessary resources. The MME will then continue to monitor the UE’s location either at the eNB level if the UE is still connected and communicating, or at the Tracking Area (TA) level if the UE has entered idle mode and a continuous data connection is not required. The MME regulates resource provisioning and release in response to the UE’s activity mode changes. Handover of a UE in active mode between eNBs, S-GWs, or MMEs requires control signaling, in which the MME takes part [10]. • Managing Subscription Profile and Service Connectivity. When a UE connects to a network, the MME is in charge of getting the UE’s subscription profile from the primary network. To continue providing service to the UE, the MME will keep this data for as long as possible. At the time of network attachment, the UE’s packet data network connections are determined by the profile. The MME will configure the UE’s default bearer automatically, providing it with minimal IP connectivity. Control Plane signaling between the eNB and S-GW is a part of this. Later on, when setting up dedicated bearers for priority services, the MME may be required to get involved. Dedicated bearer setup requests can come into the MME from the S-GW if they are coming from the operator service domain, or they can come from the UE themselves if they are setting up a connection for a service that is not known by the operator service domain [10]. (ii) Serving Gateway (S-GW) Data is sent between the eNB and the Packet Data Network (PDN) gateway via the Serving Gateway (S-GW) (P-GW). A typical network may have several gateways, each of which is responsible for the mobile devices in a certain area. Each mobile device is initially connected to a certain serving gateway; however, this connection can be switched if the device travels far enough [9]. Whenever a UE transitions between eNBs, the S-GW acts as the local mobility anchor for the data bearers, ensuring that all IP packets originating from the UE are transported without interruption. When the UE is not actively sending or receiving data, it stores bearer information and temporarily buffers downlink data until the MME pages the UE to restore the bearers. In addition, the S-GW carries out several administrative tasks within the host network, such as gathering data for billing purposes (such as the amount of data transferred and received by the user) and carrying out any necessary interception required by law. It is the

5G and LTE Network Architectures

61

mobility backbone upon which other 3GPP technologies, including GPRS and UMTS, can be built [1]. The main interfaces associated with the S-GW are as follows: S5. It manages tunnels between the S-GW and the Packet Data Network Gateway and facilitates user-plane tunneling (P-GW). It is employed when the UE moves about, and the S-GW needs to connect to a P-GW that is not co-located with it [21]. S8. Inter-Public Land Mobile Network (PLMN) reference point connecting the S-GW of the Visited PLMN (VPLMN) to the P-GW of the home PLMN (HPLMN) for user and control plane. The S8 is the inter-PLMN variation of the S5. (iii) Packet Data Network Gateway (P-GW) In actuality, this node serves as the Internet’s entry point; also, some network operators utilize it to connect to the intranets of large organizations via an encrypted tunnel, allowing the latter’s employees direct access to the former’s private internal networks. The S5 interface is shut down by the P-GW. To reach the S-GW currently handling a user's traffic, their data packets must be encapsulated in an S5 GPRS Tunneling Protocol (GTP) and sent along the user plane. To get to the user’s mobile device, the S-GW sends the data packets over the S1 interface to the eNB that is currently serving the user, and then the eNB sends the packets over the air interface [8]. The P-GW is also in charge of providing IP addresses to mobile devices. The eNB initiates communication with the MME in the manner outlined above when a mobile device attempts to join the network following a power cycle. After the subscriber is verified, the MME will ask the P-GW for an IP address for the endpoint. To do this, the S5 control plane protocol is implemented. In international roaming scenarios, the P-GW also serves an essential function. Roaming interfaces link the LTE, UMTS, and GPRS CNs of several international network operators, allowing the foreign network to authenticate the user by querying the user database of the user’s home network. When a bearer is established, a GTP tunnel is created between the S-GW in the visiting network and a P-GW in the user’s home network. This allows the user to access the Internet from either location. To differentiate the case, the interface is referred to as S8, but the procedure is almost identical to that for setting up a user data tunnel on the S5 interface [8]. When talking about the P-GW and the packet data network, the SGi interface is used as a point of reference. A packet data network, such as the one used to provide IMS services, may be either an external public or private packet data network or an internal intra-operator packet data network. For 3GPP accesses, this metric is synonymous with Gi [21]. (iv) Policy and Charging Rules Function (PCRF) The Policy and Charging Rules Function (PCRF) is an essential component of the Policy and Charging Control (PCC) in the EPC architecture (3GPP packet core architecture in general). One of the key principles of the PCC concept is the use of

62

5G NR Modeling in MATLAB®

online credit control and policy control to aid in the authorization and monitoring of services, as well as the management of their quality, among others [21]. In the context of the 3GPP architecture, a policy can be thought of as a rule that determines how a given IP flow will be handled in the network, including how it will be charged and what QoS it will be granted. To perform either the charging or policy control duties, it is necessary to first classify all IP flows (in the P-GW/S-GW) using distinct packet filters that act on the IP data flows in real time. Policy decisions and flow-based charging regulation features are housed in the PCRF. It terminates an interface called Rx, which is used by third-party application servers to communicate with the PCRF and convey service information including resource needs and IP flow-related characteristics. When using GTP on S5, the PCRF communicates with the P-GW using the Gx interface; when using PMIPv6 instead, the PCRF would interface with the S-GW over the Gxc interface. When a user is traveling, their home network’s Policy Charging Rules Function (PCRF) decides what rules should be enforced. As such, the S9 interface serves as a roaming interface between PCRFs [22] and is used to communicate with a PCRF in the visiting network. (v) Home Subscriber Server (HSS) All permanent user data is stored in Home Subscriber Server (HSS), which is also the subscription data repository. Additionally, it logs the user’s position relative to the visited network control node (MME, for example) on the level of visitation. The HSS communicates with the MME in all signaling pertaining to these roles [10]. Through the S6a interface [21], subscription and authentication data for authenticating and authorizing user access to the evolving system can be transferred between MME and HSS. For the HSS to support roaming for its UEs, it must be able to establish connections with every MME across the whole network. Only one MME will be listed as servicing a given UE in the HSS’s records at any one time. When a different MME announces that it is now providing service to the UE, the HSS will remove the old MME’s location. The HSS is essentially a centralized database server kept at the premises of the home operator. The following details are included in its contents: • The user’s International Mobile Subscriber Identity (IMSI), which can be used to identify a single subscription. When a user is roaming internationally, their home network can be located by using the IMSI, which includes the Mobile Country Code (MCC) and Mobile Network Code (MNC). The IMSI is recorded in the subscriber’s Subscriber Identity Module (SIM) card [10]. • The permanent key, which is kept in the Authentication Center (AuC), which is a part of the HSS, and used to compute authentication vectors delivered to a visited network for user authentication and deriving subsequent keys for encryption and integrity protection. • A master copy of the subscriber profile, which includes details about the user’s applicable services, such as their permitted PDN connections and

5G and LTE Network Architectures

63

whether or not they are permitted to roam to a specific visited network. The HSS additionally keeps track of the Identities of the in-use P-GWs to facilitate mobility across non-3GPP ANs [10]. • Circuit-switched service characteristics include the phone number, also known as the Mobile Subscriber Integrated Services Digital Network (MSISDN) number, and the services that the user has access to, such as text messaging and call forwarding [8]. • Packet‐switched service attributes, including the subscriber’s authorized Access Point Names (APNs), which in turn correspond to the connection attributes of an Internet or other external packet data network, like the maximum throughput [8]. (vi) IP Multimedia Subsystem (IMS) IP Multimedia Subsystem (IMS) is an industry norm that specifies a generic architecture for providing Voice over Internet Protocol (VoIP) and other multimedia services. Operators can make use of the robust multivendor service creation sector in this way, rather than being locked into a single provider for future service expansion. IMS offers its customers bundled services, as well as a hosting infrastructure for third-party applications [23]. There is a variety of viable business models that are not required by the IMS. It instead allows operators to set prices at any level they see fair. With the data provided by the IMS, the operator can choose to charge the user based on the QoS, the call duration, or any other factor [23].

2.2 LTE/4G PROTOCOL ARCHITECTURE The interfaces described in the preceding section are used by the network nodes to communicate with one another via a protocol stack. The underlying framework of these protocol stacks is depicted in Figure 2.6. There are two levels or planes in the protocol stack. Data relevant to the user are processed by protocols in the user plane, while control plane protocols process signals relevant only to the network nodes themselves [9]. There are two primary levels to the protocol stack as well. While the lower layer handles the actual transmission of data, the top layer does the data manipulations

FIGURE 2.6  LTE high-level protocol stack.

64

5G NR Modeling in MATLAB®

FIGURE 2.7  Relationship between the access stratum and the non-access stratum on the air interface.

required by LTE. They are separated into the radio network layer and the transport network layer of the E-UTRAN. After that, we have three distinct protocols. When two devices need to communicate with one another, they need a common language called a “signaling protocol”. The primary function of user plane protocols is to aid in the internal routing of data within the network, but they also perform several other functions. Last but not least, fundamental transport protocols are responsible for relaying information and signals between nodes [9]. Figure 2.7 depicts one layer of complexity added to the air interface [24]. By delivering signals to the mobile device, the MME can regulate its behavior at a high level. The MME and the mobile device are not directly connected, so messages cannot be sent or received. The air interface is separated into the Access Stratum (AS) and the Non-Access Stratum (NAS) to deal with this. Protocols from the access stratum, such as those used by the S1 and Uu interfaces, are used to transmit the higher-level signaling messages.

2.2.1 LTE Control Plane Protocol Stack The CP protocols associated with a UE’s PDN connection are depicted in Figure 2.8 in which the interconnections between two eNBs and the interfaces from a single MME can be seen. The protocols with white backgrounds were created by the 3GPP, while the protocols with a light grey background were created by the IETF and represent the standard Internet technologies used for transport in EPS. The only contribution of 3GPP is to clarify how exactly these protocols are supposed to be utilized. (i) Non-Access Stratum (NAS) The Non-Access Stratum (NAS) is the highest level of the CP. It comprises of two independent protocols that are sent between the UE and the MME via a direct

5G and LTE Network Architectures

65

FIGURE 2.8  Control plane protocols.

signaling route. The eNB is not aware of the inner workings of the NAS layer protocols, and its only function in these exchanges is to transmit the messages and, in some situations, provide extra transport layer indications [25]. The NAS layer protocols are: (a) EPS Mobility Management (EMM). Mobility management for UEs is handled by the EMM protocol. Features such as connecting to and disconnecting from the network, as well as location-based functions, are included. In standby mode, the tracking area is updated, a process known as Tracking Area Updating (TAU). Although the lower layer protocols are responsible for connected mode handovers, the EMM layer does provide features for re-enabling the UE after it has been inactive. Paging represents the network-initiated scenario, while Service Request describes the UE-initiated scenario. (b) EPS Session Management (ESM). Bearer management between the UE and MME, as well as bearer management for E-UTRAN, can be handled with the help of this protocol [25]. (ii) Radio Resource Control (RRC) The Radio Resource Control (RRC) protocol facilitates the flow of both common NAS information (data that is useful for all UEs) and dedicated NAS information (which applies only to a specific UE). In addition, RRC allows notifying UEs in RRC_IDLE of incoming calls [1].

66

5G NR Modeling in MATLAB®

The RRC protocol covers several functionalities: • Information broadcasting is managed by the system, and this includes NASwide information. While UEs in RRC IDLE need access to specific system information, UEs in RRC CONNECTED can benefit from a broader range of system information [1]. • The administration of an RRC connection encompasses all actions taken before, during, and after the establishment, modification, and disconnection of that connection. Paging, initial security activation, establishing Signaling Radio Bearers (SRBs) and user-carrying radio bearers, LTE handover (including UE RRC context information transfer), lower protocol layer configuration, access class barring, and radio link failure are all included. • Mobility between RATs that is orchestrated by the network and requires the establishment of encryption and the exchange of UE RRC context data. • Setting and reporting of measurements for intra- and inter-frequency and inter-RAT mobility; this includes the configuration and activation of measurement gaps. • Miscellaneous tasks, such as sharing information about dedicated NASs and UEs’ radio access capabilities [1]. For the downlink transmission (ENB to UE), Figure 2.9 depicts the radio protocol architecture from layer 1 to layer 4, including the links between layer 3 and the logical channels of layer 2. Figure 2.10 displays the matching uplink transmission layers [1, 7]. Through the PDCP and RLC layers, physical SRBs are transformed into

FIGURE 2.9  Layers and channel mapping for the downlink transmission.

5G and LTE Network Architectures

67

FIGURE 2.10  Layers and channel mapping for the uplink transmission.

logical channels, such as the Common Control Channel (CCCH) during connection establishment and a Dedicated Control Channel (DCCH) in RRC_CONNECTED, where dedicated RRC messages are exchanged. Broadcast Control Channel (BCCH) and Paging Control Channel (PCCH) are the logical channels to which System Information and Paging messages are directly mapped. SRB0 is used for CCCH-based RRC messages, SRB1 is used for DCCH-based RRC messages, and SRB2 is used for the (lower-priority) DCCH-based RRC messages that solely provide NAS-dedicated information. After security is turned on, the PDCP layer encrypts and protects all DCCH messages sent by the RRC, and then the RLC layer uses Automatic Repeat request (ARQ) protocols to ensure that all RRC messages are properly transmitted. It is important to note that CCCH-based RRC messages lack integrity protection and do not employ ARQ at the RLC level. In addition, it is worth noting that the NAS has its own system of integrity protection and ciphering. E-UTRAN chooses the method by which EPS bearer packets are transmitted over the radio interface when setting up a Data Radio Bearer (DRB). One EPS bearer is mapped to one DRB, and one DRB is mapped to one Dedicated Traffic Channel (DTCH), a logical channel. Layer 1 then assigns the logical channels to their appropriate transport channels. The last step is to convert the transport channels into physical channels. Figure 2.9 and Figure 2.10 depict the downlink and uplink radio bearer mappings, respectively [1, 7].

68

5G NR Modeling in MATLAB®

(iii) Packet-Data Convergence Protocol (PDCP) The Packet-Data Convergence Protocol (PDCP) compresses IP headers to reduce the data size on the radio interface. The header compression process is based on the standard header compression algorithm Robust Header Compression (ROHC) [26]. This algorithm is employed in a variety of other mobile communication technologies. Additionally, PDCP encrypts data to prevent eavesdropping, and it provides integrity protection for the control plane to verify that messages coming from the plane's controllers are authentic. The PDCP then decodes the message and decompresses the data at the receiving end [7]. When it comes to intra-eNB handover, the PDCP is crucial, since it ensures that data is sent and received in the correct order and that duplicates are discarded. Undelivered downlink data packets will be sent from the old eNB to the new eNB via the PDCP during the handover process. All uplink packets that have not yet been sent to the eNB will be retransmitted by the device’s PDCP entity as the hybrid-ARQ (HARQ) buffers are flushed during handover [7]. (iv) Radio-Link Control (RLC) The Radio-Link Protocol (RLC) protocol is in charge of partitioning the PDCP’s IP packets, or RLC Service Data Units (SDUs), into smaller, more manageable chunks called RLC Protocol Data Units (RPDUs) (PDUs). It handles the removal of duplicate PDUs from the network and retransmits any PDUs that were received in error. Ultimately, the RLC guarantees that SDUs are sent to higher levels in the correct order. The RLC can be set up in a variety of modes to carry out any or all of these tasks, depending on the nature of the service being provided. One of the primary uses of RLC is segmentation and concatenation, which is depicted in Figure 2.9. From the RLC SDU buffer, a particular amount of data is selected for transmission, and the SDUs are segmented/concatenated to form the RLC PDU based on the scheduler’s decision. As can be seen in Figure 2.11, the RLC PDU size in LTE is dynamic, and a PDU can be generated from a variety of SDU segments (n, n + 1, n + 2, and n + 3). Overhead is reduced when the PDU size is large, which is the case for high data rates, while small PDU sizes are necessary when the data rate is low since the payload would be too large otherwise. In contrast to older mobile communication technologies, which normally employed a set

FIGURE 2.11  RLC segmentation and concatenation.

5G and LTE Network Architectures

69

PDU size, dynamic PDU sizes are motivated for LTE as the LTE data speeds may range from a few kbit/s up to several Gbit/s. In LTE, dynamic PDU sizes are easily accommodated because the RLC, scheduler, and rate-adaptation mechanisms are all housed in the eNB. Each RLC PDU has a header that includes information like a sequence number for handling retransmissions and making sure data arrives in the correct order. The Medium Access Control (MAC) employs HARQ while RLC relies on the more traditional ARQ for error detection. (v) Medium-Access Control When it comes to uplink and downlink data transfers, the MAC layer is in charge of scheduling and multiplexing the logical channels involved. It is also responsible for data multiplexing/demultiplexing across multiple component carriers when carrier aggregation is employed, as well as clear-channel evaluation for license-assisted access [7]. For the convenience of the RLC, the MAC provides the latter with logical channels. When talking about logical channels, there are two primary categories: control channels, which are used to send the control and configuration information needed to run an LTE system, and traffic channels, which are used to communicate the actual user data. LTE defines a number of different kinds of logical channels, including: • The Broadcast Control Channel (BCCH), used to broadcast system data from the network to all devices in a cell. A device must first acquire the system information to learn how the system is configured and, more generally, how to behave properly within a cell [7]. Only the downlink contains this channel. • The Paging Control Channel (PCCH), used to page UEs whose precise position within a cell cannot be determined by the network. Hence, the paging message should be broadcast across more than one cell. Only the downlink contains this channel. • The Common Control Channel (CCCH), used to transmit control information in a random-access setting. Both the downlink and the uplink use this channel. • The Dedicated Control Channel (DCCH), used to send and receive control information between devices. This channel is present in both the downlink and the uplink and is used for device-specific configuration purposes such as different handover messages. SRB1 and SRB2 are associated to DCCH1 and DCCH2 in Figures 2.9 and 2.10. • The Dedicated Traffic Channel (DTCH), used to send and receive information between devices and users. All uplink and non- Multimedia Broadcast Single Frequency Network (MBSFN) downlink user traffic is transmitted via this logical channel type. DTCH1 and DTCH2 are associated to DRB1 and DRB2 in Figures 2.9 and 2.10. • The Multicast Control Channel (MCCH), employed to Broadcast Multicast Traffic Channel Reception Control Data (MTCH). This is strictly for downlink transmissions.

70

5G NR Modeling in MATLAB®

• The Single-Cell Multicast Control Channel (SC-MCCH), utilized for downlink control information transmission for single-cell MTCH reception. • The Multicast Traffic Channel (MTCH), utilized for downlink communication of MBMS across multiple cells. • The Single-Cell Multicast Traffic Channel (SC-MTCH), utilized for downlink communication of MBMS in a single cell. To facilitate communication between gadgets, a sidelink is provided, with two additional channels. For sidelink synchronization, there is the Sidelink Broadcast Control Channel (SBCCH), and for sidelink communication, there is the Sidelink Traffic Control Channel (STCH), (not depicted in Figure 2.9). The MAC layer uses the transport channels to access the physical layer’s services. The transport channel is defined by the mode and features of data transmission through the radio interface. The smallest logical unit of data arrangement on a transport medium is the transport block. Each Transmission Time Interval (TTI) simply uses the radio interface to send or receive a single transport block of varying sizes. Spatial multiplexing permits no more than two transport blocks per TTI (MIMO). During transmission, each transport block must adhere to its own unique transport format (TF), which defines how the block should be transferred via the air interface. The transport format includes information such as the transport block size, modulation and coding technique, and antenna mapping. Changes to the transport format at the MAC layer allow for a variety of data rates to be achieved. It is possible to think of the process of choosing a data transport format as a form of rate control. The following transport-channel types are defined for LTE [7]: • The specifications stipulate a constant transport format for the downlink of the broadcast channel (BCH). The Master Information Block (MIB) of the BCCH system is transmitted using this method. • The Paging Channel (PCH) is a logical channel that is used to send paging data downlink. To conserve power, the PCH allows for Discontinuous Reception (DRX), which means the device need only wake up to receive the PCH at specific times. • The Downlink Shared Channel (DL-SCH) is the main transport channel used for the transmission of downlink data in LTE. It is compatible with essential LTE features like hybrid Automatic Repeat Request (ARQ) with soft combining and spatial multiplexing, as well as dynamic rate adaptation and channel-dependent scheduling in the time and frequency domains. It also works with DRX to lessen the load on a device’s battery life without sacrificing the ability to stay constantly connected. Transmission of BCCH system information that is not mapped to the BCH also makes use of the DL-SCH. In some subframes, there may only be one DL-SCH in a cell carrying system information, while in other subframes, there may be multiple DL-SCHs in a cell, one for each device scheduled in this TTI. • The Multicast Channel (MCH) is used to support MBMS. The scheduling and transport format are both semi-static. Scheduling and transport format

5G and LTE Network Architectures

71

configuration for MBSFN transmissions involving multiple cells are coordinated between the various transmission nodes. • The Uplink Shared Channel (UL-SCH) is the uplink transport channel corresponding to the Downlink Shared Control Channel (DL-SCH) and is used to transmit uplink data. • Communication over a sidelink employs a special kind of transport channel known as the Sidelink Shared Channel (SL-SCH). The sidelink synchronization is done on the Sidelink Broadcast Channel (SL-BCH), and the sidelink discovery is done on the Sidelink Discovery Channel (SL-DCH). These channels have not been shown in Figures 2.9 and 2.10. The Random-Access Channel (RACH) is also considered as a transport channel even though it does not actually move transport blocks. Multiplexing and mapping logical channels to their corresponding transport channels is an integral part of the MAC’s functionality. Figure 2.9 for the downlink, and Figure 2.10 for the uplink, depict the mapping between logical-channel types and transport channel types. As can be seen in the figures, DL-SCH and UL-SCH serve as the primary downlink and uplink transport channels, respectively. Transport channels are depicted alongside their corresponding physical counterparts, and the mapping between the two is shown. The MAC layer can multiplex several logical channels, each with its own RLC entity, into a single transport channel to facilitate priority handling. The MAC layer at the receiver performs the appropriate demultiplexing and sends the RLC PDUs on to the appropriate RLC entity for in-sequence delivery and any other RLC-managed tasks. To facilitate demultiplexing at the receiver, a MAC header is used, as depicted in Figure 2.12. There is a subheader in the MAC header associated with each RLC PDU. The subheader contains the Logical Channel Identity (LCID) from which the RLC PDU originated and the PDU’s bytes length. A flag will appear if this is the last subheading. Each transport block sent to the physical layer is comprised of one or more RLC

FIGURE 2.12  MAC header and SDU multiplexing.

72

5G NR Modeling in MATLAB®

PDUs, the MAC header, and, if required, padding to make up the difference between the actual and desired transport-block size. The MAC layer can insert the MAC control elements into the transport blocks to be transmitted, in addition to multiplexing the various logical channels. In-band control signaling, like timing-advance commands and random-access responses, are all handled by a MAC’s control element. The LCID field is used to uniquely identify control elements, and the value of the LCID field designates the nature of the control data. In addition, for control elements of a constant length, the length field in the subheader is omitted. Scheduling is another crucial function of the MAC layer. LTE radio access relies on the concept of shared-channel transmission, in which users make dynamic use of shared time-frequency resources. The scheduler manages the allocation of uplink and downlink resources in terms of resource block pairs and is technically a part of the MAC layer (although it is often better viewed as a separate entity, as shown in Figure 2.13). Resource-block pairs correspond to a time-frequency unit of 1 ms × 180 kHz. The scheduler works primarily through a process known as dynamic scheduling, in which the eNB makes a scheduling decision and notifies the selected devices of that decision at regular intervals of 1 millisecond. Due to LTE’s split between uplink and downlink scheduling, uplink and downlink scheduling decisions can be made independently (within the constraints of the uplink/downlink split in the case of halfduplex FDD operation). The downlink scheduler decides (dynamically) which devices to send to and, for each of these devices, which blocks of available resources should be used to send the device’s DL-SCH. The eNB selects the transport format (transport-block size, modulation method, and antenna mapping) and executes logical-channel multiplexing during the downlink. The left half of Figure 2.13 depicts this. All three of these factors—data rate, RLC segmentation, and MAC multiplexing—are influenced by the scheduler’s choice. As shown in Figure 2.12, the downlink scheduler’s output can be seen to good effect. Just as the downlink scheduler determines which devices transmit over which UL-SCHs, the uplink scheduler decides which devices transmit over which uplink time-frequency resources (including component carrier). Although the TF is set by the eNB scheduler, it is vital to note that the uplink scheduling decision is made per device and not per radio bearer. Even though the eNB scheduler manages the data that a scheduled device sends, the device itself must decide which radio bearer(s) to use. The eNB can set the parameters for the device to handle logical-channel multiplexing as it sees fit. The right side of Figure 2.14 shows how the eNB scheduler manages the TF while the device handles the logical-channel multiplexing. Resilience against transmission errors is provided via hybrid ARQ with soft combining. Since HARQ retransmissions are quick, many services support them, creating an implicit (closed-loop) rate-control mechanism. Even though soft combining occurs at the physical layer, the HARQ protocol operates at the MAC layer. Unfortunately, not all forms of traffic can use Hybrid ARQ. In the case of broadcast transmissions, where the same data is being sent to different receivers, hybrid ARQ

5G and LTE Network Architectures

73

FIGURE 2.13  LTE downlink transmission.

is normally not used. Since only the DL-SCH and the UL-SCH may make use of hybrid ARQ, this feature is optional. (vi) Physical Layer The signal is coded, modulated, processed by many antennas, and mapped to the appropriate physical time-frequency resources at the physical layer. As can be seen

74

5G NR Modeling in MATLAB®

FIGURE 2.14  TF selection in (A) downlink and (B) uplink.

in Figures 2.9 and 2.10, it also manages the process of mapping transport channels to physical channels. The MAC layer relies on the physical layer’s transport channels for service. The DL-SCH, UL-SCH, and SL-SCH transport channels are used for downlink, uplink, and sidelink data transfer, respectively. On a DL-SCH, UL-SCH, or SL-SCH, there is a maximum of one transport block per TTI, or two in the event of spatial multiplexing. For each component carrier detected by the device, one DL-SCH (or UL-SCH) is present in a carrier aggregation scenario. As can be seen in Figures 2.9 and 2.10 for the downlink and uplink, respectively, each transport channel is mapped to a corresponding physical channel, which is the set of time-frequency resources required for transmission of that transport channel. There are also physical channels that don’t have an equivalent transport channel. For correct reception and decoding of downlink data transfer, the device relies on these channels, referred to as L1/L2 control channels, which are utilized for Downlink Control Information (DCI). The device’s state is relayed to the scheduler and HARQ protocol via Uplink Control Information (UCI), while sidelink transmissions are managed via Sidelink Control Information (SCI). LTE defines the following physical-channel types: • The Physical Downlink Shared Channel (PDSCH) is the primary physical channel utilized for unicast data transfer, as well as paging information transmission.

5G and LTE Network Architectures

75

• The Physical Broadcast Channel (PBCH) carries a portion of the system information required for network connectivity by the device. • The Physical Multicast Channel (PMCH) is used for MBSFN transmission. • The Physical Downlink Control Channel (PDCCH) is utilized for downlink control information, primarily for scheduling decisions required for the reception of PDSCH and for scheduling grants allowing broadcast on PUSCH. • The Enhanced Physical Downlink Control Channel (EPDCCH), which was introduced in Release 11 serves essentially the same role as the PDCCH supports more flexible delivery of control data. • The MTC Physical Downlink Control Channel (MPDCCH) is a variant of the EPDCCH which was introduced in Release 13 as part of the improved support for massive machine-type communication (mMTC). • The Relay Physical Downlink Control Channel (R-PDCCH), which was introduced in Release 10, is used to support L1/L2 control signaling on the donor-eNB-to-relay link. • The Physical HARQ Indicator Channel (PHICH) conveys the HARQ acknowledgement to the device to show whether or not a transport block needs to be retransmitted. • The Physical Control Format Indicator Channel (PCFICH) is a channel that gives the devices the data they need to decode the PDCCHs. Each component carrier can only have a single PCFICH. • The Physical Uplink Shared Channel (PUSCH) is the uplink equivalent of the PDSCH. There is a maximum of one PUSCH per uplink component carrier per device. • The Physical Uplink Control Channel (PUCCH) transmits HARQ acknowledgements to the eNB to indicate whether or not the downlink transport block(s) were received successfully, transmits channel-state reports to aid in downlink channel-dependent scheduling, and requests resources to transmit uplink data. There is a limit of one PUCCH per device. • The Physical Random-Access Channel (PRACH) is used for random access. In addition, there are four sidelink channels not depicted in Figures 2.9 and 2.10 and described as follows: • The Physical Sidelink Shared Channel (PSSCH) which supports sidelink data transfer. • The Physical Sidelink Control Channel (PSCCH), which supports sidelinkrelated control information. • The Physical Sidelink Discovery Channel (PSDCH), which supports sidelink discovery. • The Physical Sidelink Broadcast Channel (PSBCH), which supports the transfer of basic sidelink-related information between devices. Some of the physical channels, such as those utilized for downlink control information (PCFICH, PDCCH, PHICH, EPDCCH, and R-PDCCH), uplink control

76

5G NR Modeling in MATLAB®

information (PUCCH), and sidelink control information (SLCCH), do not have equivalent transport channels (PSCCH). (i) Control Plane Protocols on the S1-C Interface Figure 2.15 shows the control plane protocols between the eNB and MME connected by the S1-C interface. The S1 Application Protocol (S1AP) offers the signaling service between the EPC and E-UTRAN. The S1AP services are separated into two categories: • Non-UE-associated services. They are tied to the entire S1 interface instance between the eNB and MME using a signaling connection independent of the UE. • UE-associated services. They are related to one UE. Signaling link functions associated with S1APs provide these services to the UE. The S1AP is responsible for managing the UP and CP links between the UE and the E-UTRAN and EPC, and it also takes part in the handover [27]. The Internet Protocol (IP) and the Stream Control Transmission Protocol (SCTP) are examples of common IP transport protocols well suited to signaling messages. SCTP’s main purposes are dependable transportation and on-time delivery. There are many different options for the data connection and physical layer technologies (L2 and L1) that IP can operate on [10].

FIGURE 2.15  Control plane protocols between the ENB and MME.

5G and LTE Network Architectures

77

FIGURE 2.16  Control plane protocols between the S11 and S5/S8 interfaces.

(ii) Control Plane Protocols on the S11 and S5/S8 Interfaces Figure 2.16 shows the control plane protocols between the S11 and S5/S8 interfaces. The protocols are defined as follows: • GPRS Tunneling Protocol, Control Plane (GTP-C). It oversees the EPC’s UP connections. This involves communicating QoS and additional characteristics. It manages the GTP-U tunnels as well. GTP-C also conducts mobility management responsibilities within the EPC, such as when a UE’s GTP-U tunnels to be shifted from one node to the next. • IP and its underlying transport protocol, the Unit Data Protocol (UDP), are widely used. When error recovery and retransmission are already provided by higher layers, UDP is used instead of Transmission Control Protocol (TCP). In EPC, IP packets can ride atop a wide range of layer 2 and layer 1 protocols. A couple of examples would be Ethernet and ATM. When S5/S8 is based on PMIP, the following protocols are used: • Proxy Mobile IP (PMIP). PMIP is the alternative protocol for the S5/S8 interface. Mobility management is handled by it, but bearer management services are not included. All traffic associated with a UE's connection to a specific PDN is aggregated. • IP. PMIP runs directly on top of IP, and it is used as the standard IP transport. (iii) Control Plane Protocols on X2 Interface The X2 interface connects two eNBs together and the protocol stack of this interface is shown in Figure 2.17.

78

5G NR Modeling in MATLAB®

FIGURE 2.17  Control plane protocols between the X2 interface.

The X2 interface is utilized for mobility between eNBs, and the X2AP includes capabilities for handover planning and general relationship management between adjacent eNBs. The S1 interface has previously defined the additional protocols [10, 27].

2.2.2 LTE User Plane Protocol Stack Figure 2.18 illustrates the UP protocol structure for a UE connecting to the P-GW. The UP protocol structure closely resembles the CP structure. This demonstrates that the entire system is designed to convey generic packet data and that both CP signaling and UP data are ultimately packet data. Only the volume levels vary. The majority of protocols have already been introduced in Subsection 2.1.2.1, with the exception of the two that follow the protocol suite selection in the S5/S8 interface: • GPRS Tunneling Protocol, User Plane (GTP-U). When S5 or S8 is GTPbased, GTP-U is used. To transmit IP packets from an end user through a single EPS bearer, GTP-U creates a GTP-U tunnel. It is utilized in the S1-U interface and, if the CP employs GTP-C, the S5/S8 one is as well used.

5G and LTE Network Architectures

79

FIGURE 2.18  LTE user plane protocol stack in EPS.

• Generic Routing Encapsulation (GRE). To facilitate communication between S5 and S8, GRE is used with PMIP in the interface. To transmit all of the information associated with a single UE’s connection to a certain PDN, GRE creates an IP-in-IP tunnel. Since GRE is built on top of IP, there is no need for UDP. The user plane protocol structure for the X2 interface is shown in Figure 2.19. For temporary data forwarding during handover, the UP in the X2 interface is used after the radio interface has been disconnected at the source but before it has

FIGURE 2.19  User plane protocols between the X2 interface.

80

5G NR Modeling in MATLAB®

been resumed at the destination. Since the UE may effectively limit the uplink traffic, only the downlink data is forwarded [10, 27].

2.3 5G RAN AND NETWORK REFERENCE POINT ARCHITECTURE In this section, the different architectures of the 5G RAN will be described and a detailed treatment of the 5G network reference point architecture will be given.

2.3.1 5G RAN Network Architectures Due to the base station’s modular design, the 5G RAN can be deployed in a variety of ways. Some fundamental elements in relation to 4G and 5G RAN and base station functions will be discussed before examining the whole 5G Network infrastructure. The Baseband Unit (BBU), depicted in Figure 2.20, is a component of 4G networks that handles all of the necessary baseband processing. The RF operations are handled by a separate component called the Remote Radio Head (RRH). The RRH and BBU capabilities can be deployed using either of two possible architectures. The first, and by far the most common, architecture deploys both the BBU and RRH functions at each cell site; it is called Distributed RAN (D-RAN).

FIGURE 2.20  4G RAN deployment architectures.

5G and LTE Network Architectures

81

In the second configuration, sometimes referred to as a BBU Hotel, the BBU function is located in a more central area. Centralized RAN is a method that has been adopted by a few service providers so that the cell site’s infrastructure can be reduced in complexity, which in turn reduces the need for physical space and electrical power. The BBU elements can also be distributed to other cell locations. Understanding the 5G RAN deployment models requires expressing the baseband processing and RF processing capabilities in the form of the 3GPP Radio Protocol Stack, as shown in Figure 2.21 [28, 29]. As seen in the figure above, the functional parts of the RAN can be divided into three functional units. In other terms, the BBU functions are divided as follows between the CU, DU, and RU: (i) Central Unit (CU): includes L2 PDCP and L3 RRC non-real time operations. (ii) Distributed Unit (DU): hosts the higher-layer PHY function, as well as the L2 RLC and L2 MAC's real-time operations. (iii) Radio Unit (RU): supports RF processing and higher-layer PHY operations.

FIGURE 2.21  5G gNB functional elements.

82

5G NR Modeling in MATLAB®

Fronthaul-Low Layer (Fronthaul-LL) is the name given to the interface between the RU and the DU. Since this interface requires low-latency transfer (150–200 seconds), the physical distance between the RU and the DU is limited. The Common Public Radio Interface (CPRI) is the specific implementation standard for this layer. CPRI is a well-known standard for delivering baseband I/Q signals to the radio unit in conventional BS radio systems (Base Station). CPRI permits an effective and adaptable I/Q data interface for several protocols, such as GSM, WCDMA, LTE, etc. In addition, improved CPRI (eCPRI), which is published after CPRI and describes the standards that connect the RRU to the DU, is also available. It is used for LTEAdvanced and LTE-Advanced Pro systems [30] and 5G systems. Fronthaul-High Layer (Fronthaul-HL), or more particularly the F1 interface, is the name given to the interface between the DU and the CU. This interface is also referred to as the Midhaul interface. This interface is less susceptible to delay than the Fronthaul-LL interface, allowing the CU to further be centralized. The F1 interface is utilized to connect a gNB CU to a gNB DU. This interface is suitable for the architecture of CU-DU Split gNB. Several possible architectures are depicted in Figure 2.22 [28, 31], where the CU, DU, and RU are each a functional block that can be physically separated and placed at different tiers of the transport network. In the 5G D-RAN architecture, all processing occurs at the cell site. In the 5G Cloud D-RAN paradigm, the CU functions are performed in the cloud, and the DU and RRU functions are performed on-site. In the 5G Cloud C-RAN paradigm, only the RRU is present at the cell site, while the DU and CU functions are executed in the cloud. Figure 2.23 [31] depicts an overview of the 5G network architecture using Cloud C-RAN.

FIGURE 2.22  5G RAN functional architectures.

5G and LTE Network Architectures

83

FIGURE 2.23  High-level view of 5G architecture.

With cloud RAN, the baseband is virtualized and hardware and software are uncoupled, making it possible for them to have separate lifecycles. The real-time and non-real-time baseband in a fully cloudified Cloud RAN are each virtualized and divided into their own units, known as the Virtualized Distributed Unit (vDU) and the Virtualized Centralized Unit (vCU), respectively. The conventional, one-size-fits-all approach to designing radio networks is no longer adequate. Virtualizing the RAN edge enables the next generation of consumer and enterprise wireless technologies. Cloud RAN offers the ability to flexibly grow capacity, create and monetize services rapidly, and satisfy the required latency. The fully cloudified Cloud RAN technology is also the foundation for flexible and dynamic end-to-end network slicing [31]. Multiaccess Edge Computing (MEC) plays a significant role in decreasing latency for 5G networks and delivering a latency reduction on the order of 1 ms for the data plane for URLLC applications and services. With MEC, the application server or content storage will be incorporated into local cellular base stations and moved closer to the end user and their smart device to meet latency requirements for mission-critical use cases. Figure 2.23 depicts this in the vDU server and vCU data center. In a 5G network, MEC is installed primarily at the N6 reference point, i.e., in a data network external to the 5G system.

2.3.2 5G Network Reference Point Architecture The 5G system architecture is outlined to provide data connectivity and services, allowing for deployments to make use of technologies like Network Function Virtualization and Software Defined Networking. When applied to the specified use cases, it is essential that the 5G System architecture leverage service-based interactions between Control Plane (CP) Network Functions. Important principles include: • Decouple the CP from the User Plane (UP), allowing for distributed or centralized deployments, as well as independent scalability, evolution, and deployment options. Modularizing the design of functions is also important, for instance to allow for efficient and adaptable network slicing. • Keep the Access Network’s (AN) dependence on the CN to a minimum. The design is characterized by a convergent CN that uses a standard AN-CN interface to connect multiple Access Types, such as 3GPP and non-3GPP.

84

5G NR Modeling in MATLAB®

• Allow for simultaneous access to both local and centralized services, capability exposure, and decoupling of the “compute” and “storage” resources. For low-latency services and local data network access, UP capabilities can be deployed in close proximity to the AN. Additionally, both locally routed traffic from the home PLMN and traffic from the visited PLMN are supported when roaming. The complete network reference point architecture of 5G is shown in Figure 2.24 [32, 33, 34, 35]. This architecture is composed of the 5G Cloud CRAN and the 5G Core. The 5G Cloud CRAN is founded on 5G NR signal processing elements and consists of 5G gNB and UEs. The functions of the baseband unit of the gNB are supposed to be distributed between the gNB-CU, gNB-RU, and gNB-DU in this architecture. The gNB-CU-CP handles the control plane functions, whereas the gNB-CU-UP handles the user plane functions.

FIGURE 2.24  5G network reference point architecture.

5G and LTE Network Architectures

85

2.3.2.1 5G Cloud CRAN Elements The main elements and interfaces of the 5G Cloud RAN are described as follows: (a) User Equipment (UE) The 5G NR UE is a device that can process signals in accordance with 5G NR specifications, such as the NR’s frequency bands, MIMO type, and multiplexing standards. The Uu interface allows for separation into the NG-1U interface for user plane functions and the NG-1C interface for control plane functions, allowing for a direct connection to the 5G RAN. Through the N1 RP, it links up with the 5G Core’s Access and Mobility Management Function (AMF). The N1 interface is an invisible connection between UE and AMF. It is used to send signaling-unrelated data from UEs to AMFs, such as connection, mobility, and session details. Its primary function is in the NAS layer’s signaling, which is non-radio. (b) gNB-Radio Units (gNB-RUs) Figure 2.25 highlights the main architectural difference between a 4G LTE RAN and a 5G RAN. Most commercially available 4G LTE networks use frequencies below 4 GHz. The first generation of 5G networks has prioritized employing a spectrum allocation that includes low (600–900 MHz), mid (2.5–4.5 GHz), and high (24–47 GHz) millimeter wave (mmWave) frequencies. Eventually, all currently available 4G

FIGURE 2.25  Main architectural difference between 4G RAN and 5G RAN.

86

5G NR Modeling in MATLAB®

LTE spectrum will be upgraded to 5G NR. Compared to 5G NR’s single channel bandwidth of 100 MHz, the current upper limit for 4G LTE’s single channel bandwidth is only 20 MHz. While Frequency Division Duplex (FDD) is used by 4G LTE networks, Time Division Duplex (TDD) is the focus of 5G NR networks in the mid-band and high-band spectrums and FDD in the low-band spectrum. The current generation of 4G LTE RRUs employs either a 4 × 4 MIMO 4T4R or an 8 × 8 MIMO 8T8R architecture for FDD and TDD modes, respectively. There are 4 × 4 MIMO 4T4R RUs for the low band, and 8 × 8 MIMO 8T8R and massive MIMO 32T32R/64T64R RUs for the mid-band. Lower order MIMO is used in high band RUs, however normally 128–512 Antenna Elements (AE) are used in these types of setups [36]. The RF circuitry, as well as any analog-to-digital or digital-to-analog converters, and any up/down converters, are all housed in the RU of the base station. Its primary functions are as follows [37]: • Convert signals from optical form to electrical and vice versa using CPRI/ eCPRI. • In the transmitter section of RU, it converts digital signal to RF and amplifies that signal to the desired power level and the Antenna connected to it, radiates the RF signal in air. • In the receiver section of RRH, it receives the desired band of signal from antenna and amplifies it and converts the RF signal back to digital signal in the receiver chain. Signals in the CPRI/eCPRI format travel along the fiber optic line from the RU to the gNB-DU. As CPRI data rates increase from 6 Gbps to 10 Gbps or higher, optical cable is preferred over RF coaxial cable due to its lower price and lower loss. The number of RUs that can be connected to a single gNB-DU is determined by the capabilities of the BBU [37]. For all of the mid-band 5G NR frequencies, the default configuration for 5G NR TDD RRUs is 8T8R. (2500–4500 MHz). 5G NR will operate in FDD mode on lowband frequencies (600–700 MHz) in many countries, however, the corresponding RRU configuration will be 4T4R. There will be between 160 and 320 W of RF power available across the entire 8T8R RRU system, with each RRU using 20 to 40 W of power per RF carrier. Through a series of nine RF coaxial jumper wires [36], the 8T8R RRU is linked to a separate passive sectorized antenna panel. The RRU can be divided into three primary subsystems: 1. CPRI Fronthaul and L1 Baseband Processing. 2. Digital IF/Analog RF Radio Transceiver. 3. Filter. Mid-band (5G NR) networks will use Active Antenna Units (AAUs) of the massive MIMO variety (i.e., Antenna Aadio Systems (ARS)) operating at frequencies

87

5G and LTE Network Architectures

between 2500 and 4500 MHz S. With average RF power levels ranging from 100 to 320 W [36], the most common radio transceiver designs will be 32T32R or 64T64T. The AAU can be divided into three primary subsystems: 1. eCPRI Fronthaul and L1 Baseband Processing. 2. Digital IF/Analog RF Radio Transceiver. 3. Filter/Antenna. (c) gNB-Distributed Unit (gNB-DU) The gNB-CU-UP and gNB-CU-CP are responsible for regulating the gNB-DU, a logical node that houses the RLC, MAC, and PHY layers of the gNB. It is possible for many cells and several RUs to coexist on the same gNB-DU. However, a single gNB-DU can support several cells. The gNB-DU establishes connections to the gNB-CU-CP via the F1-C interface and the gNB-CU-UP over the F1-U interface [38]. The gNB-DU coordinates and disseminates system information. The gNB-DU encodes the NR-Master Information Block (NR-MIB) and System Information Block Type 1 (SIB1) for SI broadcasting, while the gNB-CU encodes the remaining SI messages. Energy savings can be realized by UEs thanks to the F1 interface’s signaling support for on-demand SI delivery [39]. The main functionalities of the F1-C interface can be illustrated in Table 2.1 [40]. The Control Plane Functionalities of the F1-C interface are elaborated as follows [40, 41, 42, 43]:

TABLE 2.1 Control Plane Functions of the F1-C Interface Interface Mgt Procedures

UE Context Mgt Procedures

RRC Msg Transfer Procedures

F1 Setup

UE Context Setup

Initial UL RRC Message Transfer

Reset

UE Context Modification (gNB-CU initiated) UE Context Modification Required (gNB-DU initiated) UE Context Release

DL RRC Message Transfer

Error Indication gNB-DU Configuration Updates gNB-CU Configuration Updates gNB-DU Resource Indication SI & Paging Procedures System Information Delivery Paging

UE Context Release Request UE Inactivity Notification Notify

UL RRC Message Transfer Warning Msg Transfer Procedures Write-Replace Warning PWS Cancel PWS Restart Indication PWS Failure Indication

88

5G NR Modeling in MATLAB®

(i) Interface Management Procedures • F1 Setup. Executing the F1 Setup method allows the CU-CP and DU to create an F1 connection. Creating an SCTP connection between the CU-CP and DU is a prerequisite to starting the F1 Setup process. The DU will initiate communication with the CU-CP by sending an F1 Setup Request, and the CU-CP will reply with an F1 Setup Response. The F1 Setup Request notifies the CU-CP of the DU’s identity and the cell kinds that it may support. The F1 Setup Response is utilized for the purpose of identifying target DU cells for stimulation. • Reset. Either the CU-CP or DU can start the Reset procedure. It can be used to clear the state for all UE contexts in an F1AP, or for a selection of UE contexts in an F1AP. At the moment the CU-CP initiates the reset, the DU frees up any resources it was retaining on the F1 interface and any radio resources it was using. When the DU requests a reset, the CU-CP makes all necessary allocations on the F1 interface. The Reset/Reset Acknowledge handshake is used in this procedure. In other words, it does not force a hard reset of the F1 system. • Error Indication. It is up to either the CU-CP or the DU to start this process. This message is sent when an error has been identified in an incoming F1 Application Protocol (F1AP) message. This occurs when a failure message from the appropriate signaling process cannot be used to indicate the error. Only the Error Indication message is used in the process. • gNB-DU Configuration Update. The DU uses this to relay up-to-date information about the cells it can support to the CU-CP. Using the gNB-DU Configuration Update message, users can add new cells, make changes to existing cells, or remove cells entirely. To confirm the update, the CU-CP sends a gNB-DU Configuration Update Acknowledge message. • -gNB-CU Configuration Update. The CU uses it to communicate new information about the set of cells to be activated or deactivated to the DU. The CU can instruct the PCI to be used during cell activation. The CU will send out a gNB-CU Configuration Update message to kick off the process, and the DU will respond with a gNB-CU Configuration Update Acknowledge message to confirm that it has received the update. • gNB-DU Resource Coordination. This procedure is used in situations where a gNB and a ng-eNB have overlapping coverage areas and share the same spectrum. To transmit XnAP messages between the CU and DU, the F1AP method is implemented as a subset of the related XnAP procedure. It is possible to encapsulate the XnAP: E-UTRA—NR Cell Resource Coordination Request message within the F1AP: GNB-DU Resource Coordination Request message. It is worth noting that the XnAP response is essentially the same as the F1AP response. Since the Packet Scheduler resides in the DU, it is the DU that will be the focus of this procedure rather than the CU. • gNB-DU Status Indication. Through the gNB-DU Status Indication procedure, the DU can inform the CU of its overload status. A simple flag specifies whether or not the DU is overloaded in the gNB-DU Status Indication message.

5G and LTE Network Architectures

(ii) RRC Message Transfer Procedures • Initial UL RRC Message Transfer. It relays the initial uplink RRC message from the DU to the CU-CP. This initial uplink communication, like an RRC Setup Request, is a CCCH responsibility. The procedure also notifies the CU-CP of the C-RNTI allocated by the DU and transfers the CellGroupConfig parameter structure, which details the RLC, MAC, and Physical Layer settings for the new connection, to the CU-CP. Initiating a connection linked with a UE over the F1 interface is another function of the method. After the UE has been linked with a CU-CP, the CU-CP will have access to the UE's unique identifier, or “gNB-DU UE F1AP Identity”, which will be used in all subsequent message exchanges to identify the UE’s connection. Within the initial DL RRC Message Transfer, the CU-CP supplies a matching gNB-CU UE F1AP Identity. • DL RRC Message Transfer. It is the mechanism by which the CU-CP sends RRC messages to the DU over the downlink. As part of the PDCP stack, the CU-CP is responsible for generating and handling RRC messages. As PDCP PDU, they are then sent to the DU. To have the DU use SRB duplication, the DL can include a flag in the RRC Message Transfer message. This is relevant in cases where redundancy across different NR carriers has been set for the connection. By using numerous carriers to send the same RRC message, duplication increases reliability. The DU’s prioritization judgments can be aided by a RAT-Frequency Priority information clement included in the DL RRC Message Transfer message. • UL RRC Message Transfer. With this mechanism, the DU can send uplink RRC messages to the CU. The DU takes in RRC messages sent by UEs and processes them at the Physical, MAC, and RLC levels. After that, they are sent to the CU as PDCP PDU. (iii) UE Context Management Procedures • UE Context Setup. F1AP UE Context Setup procedure includes UE Context Setup Request/UE Context Setup Response handshake. In every case, it is the CU-CP which initiates this process. When setting up a new connection for the first time. Afterwards, the AMF sends the NG-C: initial UE Context Setup Request, which is followed by the F1AP: UE Context Setup Request. A pair of SRB and a pair of DRB with the F1AP: UE Context Setup Request message can be set up. Each DRB assigns the DU an uplink GTP-U TEID to utilize for sending user plane data in the uplink direction to the CU. The downlink GTP-U TEID is specified in the F1AP: UE Context Setup Response packet. Incoming handover processes can also make use of the UE Context Setup procedure to establish a new UE context at the destination DU. As soon as the handover decision is made, i.e., once the CU receives the RRC: Measurement Report from the UE, it requests a new UE context from the target DU. • UE Context Modification. To modify the settings specified in Initial UE Context Setup, CU-CP employs the UE Context Procedure. It can also be

89

90

5G NR Modeling in MATLAB®

used to instruct the DU to start or restart sending data to the UE. To send an RRC message to a UE, the DU can wrap it in a UE Context Modification Request. After the DU receives an RRC Reconfiguration from the CU, it includes it in a UE Context Modification Request and sends it out. The list of downlink GTP-U TEID is updated by the DU using the UE Context Modification Required protocol. It can also mandate the dissemination of a given set of SRB and DRB. Also, when a gNB and a ng-eNB share spectrum with overlapping coverage, the gNB can define a need for the ngeNB to provide updated information about its cells and the gNB can offer updated information about its cells. • UE Context Release. The CU-CP has a function called UE Context Release that it uses to free up an already-in-use UE context. This operation makes use of the handshake between the UE Context Release Command and the UE Context Release Complete. The UE Context Release Request protocol corresponds to the DU sending a message to the CU requesting that the CU begin the process of releasing the UE context. • UE Inactivity Notification. Using this procedure, the DU can notify relevant parties of a UE’s inactive state. For each DRB, DU shows either “Active” or “Not Active”. • Notify. The notify procedure permits the DU to alert the CU-CP whenever a designated DRB is no longer achieving its Guaranteed Flow Bit Rate (GFBR). This is relevant for Notification Control-enabled GBR QoS Flows. When GFBR is again fulfilled, the DU can inform the CU. (iv) SI and Paging Procedures • System Information Delivery. The CU-CP can instruct the DU on which types of “Other System Information” (OSI) it wishes to broadcast within a certain cell by following this procedure. SIB2 through SIB9 are part of OSI. A UE’s request for the dissemination of Other System Information might initiate the System Information Delivery procedure. • Paging. To get the DU to page a certain UE, the CU-CP makes advantage of the Paging procedure. Since the target UE’s Paging Frame is specified by the UE Identity Index, it may be determined from the Paging message. Both the Radio Access Network User Equipment Identity (I-RNTI) and the Core Network User Equipment Identity (I-RNTI) are included in the paging message (S-TMSI). When a UE is in the RRC Inactive state, it is given an I-RNTI. The DU also receives information regarding the number of cycles in which the paging DRX must occur, the paging priority, and the list of cells that must be used to send the paging data. (v) Warning Message Transfer Procedures • Write-Replace Warning. With the use of this procedure, the CU can either start sending out warnings or override existing ones. These alerts are suitable for use in a Public Warning System (PWS). The CU-CP and DU

5G and LTE Network Architectures

91

exchange a Write-Replace Warning Request and a Write-Replace Warning Response to carry out the procedure. The PWS System Information to be broadcast is included in the Write-Replace Warning Request message. Using the PWS Cancel procedure, the CU-CP can instruct a DU to cease transmitting PWS System Information. Using the PWS Restart Indication process, the DU notifies the CU of the cells for which PWS data is available. In the event of a failure in PWS transmission, the DU will notify the CU of the affected cells using the PWS Failure Indication procedure. The main functionalities of the F1-U interface are as follows [40, 43]: The F1-U’s user plane oversees the relay of information about applications between the CU-UP and the DU. The application data is transmitted over GTP-U tunnels. The TEID is used to identify each of these tunnels. Every DRB gets their own individual tunnel. Different ways for managing downlink data transfers are made available by the user plane protocol, which operates on top of the GTP-U layer. Flow control, packet loss detection, and successful delivery reporting are all examples of such processes. As can be seen in Figure 2.26, the CU sends out PDU Type 0 (user plane protocol frames) and the DU sends out PDU Type 1 (control plane frames).

Each downlink data packet is given a unique sequence number by the CU-UP through PDU Type 0. This sequence number is used by the DU for packet loss detection. In addition, the CU-CP can receive a wide range of discard commands from PDU Type 0. A retransmission attempt from the PDCP layer via a second DU may be made by the CU-UP if the DU indicates a radio connection outage. For improving efficiency, the CU-UP instructs the sending DU to discard the packets that have already been transmitted successfully if the receiving DU reports that the PDCP PDU was successfully delivered. The DU employs PDU Type 1 to report any missing packets and to manage the rate at which downlink data is provided by the CU, hence preventing the buffers within the DU from becoming too full. The DU indicates the sequence number of the most recent PDCP PDU that was successfully transmitted, the intended buffer level, and the desired data rate. The desired data rate is defined as the number of bytes the DU wishes to receive in one second. These information aspects are utilized by the

FIGURE 2.26  PDU exchange over the F1-U interface.

92

5G NR Modeling in MATLAB®

CU to decide the quantity of data to convey to the DU. The DU may also utilize PDU Type 1 to indicate “Radio Link Outage” and “Radio Link Resume”. (a) gNB Central Unit (gNB-CU). It is a logical node that hosts RRC, SDAP, and PDCP protocols of the gNB or RRC and PDCP protocols of the en-gNB (en-gNB denotes a gNB that can link with EPC and eNB of a 4G LTE network) and manages the operation of one or more gNB-DUs. [44] The gNB-CU terminates the F1 interface that is connected to the gNB-DU. The gNB-CU can be further subdivided into its CP and UP components to optimize the positioning of various RAN functions based on various scenarios and performance needs (the gNB-CU-CP and gNB-CU-UP, respectively). E1 is the name of the interface between CU-CP and CU-UP, which is solely a control plane interface. Figure 2.27 depicts the overall RAN architecture with CU-CP and CU-UP separation. In the NG-RAN architecture the following connections are observed with regard to the gNB-CU and gNB-DU [44]: • • • • • •

Besides the gNB-CU-CP, a gNB can also have gNB-CU-UPs and gNB-DUs. The F1-C interface links the gNB-CU-CP to the gNB-DU. The F1-U interface links the gNB-CU-UP to the gNB-DU. The E1 interface links the gNB-CU-UP to the gNB-CU-CP. Each gNB-DU is linked to a single gNB-CU-CP. Only a single gNB-CU-UP is linked to a gNB-CU-CP.

Xn is an open interface that allows for the transmission of signaling data between NG-RAN nodes and the delivery of PDUs to their corresponding tunnel endpoints. The Xn can be thought of as a direct connection between two gNBs from a logical perspective. It helps make it possible to link together NG-RAN nodes from various vendors and for NG-RAN services provided over the NG interface to be maintained

FIGURE 2.27  5G RAN architecture with CU-UP and CU-CP separation.

5G and LTE Network Architectures

93

while users move from one node to another. It permits the decoupling of Radio Network functionality from Transport Network functionality via the Xn interface, paving the way for the implementation of new technologies. In addition, it allows for the implementation of processes for intra-NG-RAN mobility and the implementation of procedures to support dual connections between NG-RAN nodes [45]. (b) gNB-CU-Control Plane (gNB-CU-CP). The gNB-CU is a logical node in an en-gNB or gNB that houses the RRC and the control plane of the PDCP protocol. When linked to both the gNB-CU-UP and the gNB-DU, the gNB-CU-CP serves as a terminal for the E1 and F1-C interfaces, respectively [44]. Moreover, it communicates with the 5G Core’s AMF via the N2 interface. The interfaces of the gNB-CU-CP are defined as follows: (i) Xn-C interface The functions of this interface are summarized in Table 2.2. (ii) The E1 interface The E1 interface is a point-to-point, open connection that allows for the logical, but not necessarily physical, transmission of signaling information between a gNB-CUCP and a gNB-CU-UP. It divides the physical layer (Radio Network) from the logical layer (Transport Network). In addition, it facilitates the sharing of data that is not directly related to UEs [46]. The E1 interface management function is summarized in Table 2.3. The gNB-CU-CP initiates the E1 bearer context, and the gNB-CU-UP either approves or rejects it depending on admission control criteria. The E1 bearer context management function is responsible for establishing the E1 bearer context (e.g., resource not available). Initiation of E1 bearer context change can be triggered by either gNB-CU-CP or gNB-CU-UP. It is up to the receiving node to decide whether or not to take in the update. For bearer contexts created via the gNB-CU-UP, the E1 bearer context management feature also allows for their release. Either the gNB-CU-CP initiates the release of the bearer context on its own or in response to a request from the gNB-CU-UP. This function is also used to setup and modify the QoS-flow to DRB mapping configuration. The gNB-CU-CP makes the decision on how flows are mapped to DRBs and gives the gNB-CU-UP the resulting SDAP and PDCP configuration. In turn, the gNB-CU-CP employs this feature to alert the gNB-CU-UP when it has detected the arrival of DL data. By use of this feature, the gNB-CU-UP instructs the gNB-CU-CP to initiate the paging procedure over F1 in order to accommodate the RRC Inactive state [46]. (iii) N2 Interface The gNB-CU-CP is linked to the Access and Mobility Management Function (AMF) through N2. This is crucial due to the R14 implementation of Control and User Plane

94

5G NR Modeling in MATLAB®

TABLE 2.2 Xn-C Interface Functions [45] Xn-C Interface Management and Error Handling Functions General

These capabilities enable error recovery, Xn interface surveying, and management of signaling relationships between NG-RAN nodes.

Setup function

This function enables application-level data exchange during the initial Xn interface setup between two NG-RAN nodes. General application-level errors can be reported using this feature.

Error indication function Reset function

Configuration data update function Removal function

Handover preparation function Retrieve UE context function RAN paging function Data forwarding control function Dual connectivity function Energy saving function

With this capability, a node in an NG-RAN can signal to another that it has recovered from an abnormal failure and that all or some of the contexts associated with it and stored in the other node should be erased (with the exception of application-level data). This function enables real-time data updates at the application level between two NG-RAN nodes. This function makes it possible for two NG-RAN nodes to disconnect from one another via the Xn interface. UE Mobility Management Functions This feature facilitates communication between the source and destination NG-RAN nodes to initiate the handover of a specified UE. The Retrieve UE context function facilitates the acquisition of UE context from a neighboring node in an NG RAN. The RAN paging function enables an inactive NG-RAN node to start paging a UE. The data forwarding control function enables the creation and removal of transport bearers for data forwarding between nodes in the NG- RAN. Other Functions Because of the dual connectivity feature, a secondary node in the NG-RAN can be used to access and utilize supplementary resources. By providing an indicator of cell activation/deactivation across the Xn interface, this feature reduces energy consumption.

Separation (CUPS). In order to facilitate the deployment of edge computing and a more distributed network architecture, it was crucial to separate control signaling from user session traffic. Since the UE needs to be linked to the network in order to use any service, N2 is essential. While the new Session Management Function (SMF) is responsible for managing sessions (following the decomposition started with CUPS), the AMF is in charge of the UE context. Thus, the UE’s context, location, and other factors must be taken into account prior to the start of any transmission or session [47]. In the 5G network design, N2 is a critical point of reference. This is the central node via which all radio network signals are routed to reach the CN (AMFprotected). It is also referred to as the NG-C. The NG-AP protocol is the foundation for the signaling that travels via N2. Several distinct signaling protocols can be carried out over N2 [33, 48]:

95

5G and LTE Network Architectures

TABLE 2.3 E1  Interface Management Functions Function

Description

Error indication function

It is sent from the gNB-CU-CP to the gNB-CU-UP when an error has been detected.

Reset function

After a node has been set up and a failure event has taken place, this is the feature that initiates the peer entity. The gNB-CU-UP and gNB-CU-CP are both able to employ this method. It allows the gNB-CU-UP and gNB-CU-CP to communicate properly via the E1 interface by exchanging application-level data. Both the gNBCU-UP and the gNB-CU-CP initiate the E1 configuration process.

Setup function

gNB-CU-UP and gNB-CU-CP configuration update functions

Over the E1 interface, the gNB-CU-CP and the gNB-CU-UP can exchange the application-level configuration data necessary for seamless operation.

• Procedures supporting the management of N2 like the configuration of the interface itself. To facilitate load balancing, redundancy, and network slicing, a single gNB can be linked to several AMFs. • Procedures related to signaling for a specific UE/device. Except in some instances involving simultaneous roaming in 3GPP and non-3GPP networks, each UE/device is always connected with a single AMF. These signals can be broken down into three distinct processes: • Signaling related to the forwarding of messages between the device and the CN. This is based on the Non-Access Stratum (NAS) protocol. Each NAS message in the 5GC architecture is handled by either the AMF or the SMF, depending on its nature. Given that there is no direct link between the SMF and the radio network, the AMF is used to relay messages between the SMF and the device. The SMF handles NAS messages associated with Session Management. Every other type of NAS communication is handled independently by the AMF, without any input from the SMF. Note that NAS can also be used to transparently convey communications destined for or from other Network Functions. • Signaling related to the modification of the stored data for a specific device, the “UE context”. • Signaling related to the management of events like handovers between radio cells or access networks and paging of devices that are in idle mode. When compared to the EPC architecture, 5GC distinguishes itself by designating a unique name for the reference point between the device and the CN (the AMF). The above-mentioned NAS messages travel along this path, which is referred to as N1. In practice, this means that the NAS messages travel via the air interface Uu and the RAN-Core transparently [33, 48].

96

5G NR Modeling in MATLAB®

(c) gNB-CU-User Plane (gNB-CU-UP). An en-CU gNB’s hosts the user plane for the PDCP protocol of the gNB-CU, while a gNB’s CU hosts the user plane for the PDCP protocol and the SDAP protocol. Terminating both the E1 interface from the gNB-CU-CP and the F1-U interface from the gNB-DU, the gNB-CU-UP is responsible for achieving Rx/Tx synchronization [44]. It communicates with the 5G Core’s AMF over the N2 interface as well. The interfaces related to the gNB-CU-CP are defined as follows: (i) Xn-U interface There are primarily two uses for this user interface. One of these is the Data Transfer function, which facilitates the exchange of information between NG-RAN nodes in order to facilitate either dual connectivity or mobility. The second is the flow control function, which allows an NG-RAN node to provide feedback information related to the data flow while it is receiving user plane data from another NG-RAN node [45]. (ii) N2 Interface Over the N3 referencing point, data is transmitted between the RAN and the UPF. When data is tunneled through N3, IP routing is performed based on the IP address of the tunnel header rather than the IP address of the end user. In this way, the device’s IP address may be reliably anchored in the network despite its mobility. The same transport techniques and routing can be used regardless of the data type being transported. Besides IP packets, Ethernet frames and “unstructured data” are also supported under the 5G architecture requirements. This is conceptually similar to the approach taken in the EPC architecture, where the analogous interface or reference point is known as S1-U. However, N3 introduces a fresh method for handling QoS for individual data flows and for assigning those flows to tunnels. (f) Non-3GPP Interworking Function (N3-IWF) Untrusted non-3GPP access networks, such as Wi-Fi, are supported for UE connectivity in the 5G CN. Through a non-3GPP interworking function, non3GPP access networks can communicate with the 5G CN (N3IWF). The N3IWF connects the 5G CN’s control plane and UPFs to outside the external network through the N2 and N3 interfaces. Connecting independent non-3GPP access networks to the control plane function and UPF of the 5G CN is done via the N2 and N3 reference points. With its support for IPsec between the UE and the N3IWF, N3IWF ensures a secure connection for UEs connecting to the 5GCN through a non-3GPP access network [49, 50]. WLANs that are not managed by a mobile network provider are considered to be untrusted. Convergence to a single 5GCN providing multiple IP-based services, on the other hand, is made possible by the addition of non-3GPP/WLAN access networks, which cannot be trusted.

5G and LTE Network Architectures

97

• Expanded capacity and smart traffic unloading can lessen data congestion and cut down on backhaul expenses. • Offer superior coverage and connectivity in congested urban and indoor settings. • Open up novel opportunities for profit through the use of mobile technology, enhanced services, and novel mobility solutions. • Costs for operators can be decreased by increased capacity and centralized management. • Provide better services to the consumer while keeping overhead to a minimum. Figure 2.28 depicts the network architecture for 5GCN interoperability with unsecured WLANs. In order to access the 5GCN, a UE must be able to use NAS signaling and must initially register and authenticate with the 5GCN using the N3IWF even if the UE is connected to an untrusted WLAN. The AUSF is used to register the UE and the AMF is used to authenticate the UE using EAP-AKA’/5G AKA authentication, which is similar to the registration and authentication methods used for 3GPP access rather than older architectures for untrusted WLAN. IPsec Security Association (SA) establishment between UE and N3IWF for encrypting NAS mobility and session management communications occurs before the registration process concludes. In order for the UE to communicate with the SMF through the AMF, it must first set up IPsec signaling SA sessions by sending session management messages over the NAS. As part of a PDU session setup, the N3IWF must build a GTPU tunnel with the UPF and IPsec Child SAs with the UE for the various QoS flows associated with the PDU session. Secure IPsec tunnel(s) between UE and N3IWF and the GTPU tunnel between N3IWF and UPF are used for UL and DL data packet transfer between UE and the data network [50]. The following interfaces are available for use with 5GCN and untrusted WLANs:

FIGURE 2.28  Untrusted WLAN access architecture via N3IWF [50].

98

5G NR Modeling in MATLAB®

To reliably transfer control-plane and user-plane communication between the UE and the 5GCN through untrusted non-3GPP access, an NWu reference point is set up between the UE and the N3IWF. • Y1 is the interface linking the UE and the WLAN. • Y2 is the interface linking the WLAN and the N3IWF for the transport of NWu traffic. • N1 is the interface linking the UE and the AMF. • N2 is the interface linking the N3IWF and the AMF. • N3 is the interface linking the N3IWF and the UPF. 2.3.2.2 5G Core Network Elements The 5G Core is divided into the following eight main blocks: (i) Packet Controller. It supports new 5G use cases by providing access, session, mobility, and gateway control functions. It was developed with cloudbased and Service-Oriented Architecture tools. It essentially consists of the AMF, SMF, SMSF, and UCMF. (ii) Subscriber Data Management. This block consists of entities such as the UDM, AUSF, 5G EIR, and HSS (for the transition from 4G). The primary function of this system is to manage subscriber information, including authentication, identity, billing, etc. (iii) Policy Management, This block enables the end-to-end automation of network policy setup, the granular configuration of services within network slices, and the establishment of advanced data communication services. It consists of entities such as the CHF and PCF. (iv) Shared Environment. This block maintains data and executes functions that are used by other parts of the 5G Core. It essentially consists of the UDSF and UDR. (v) Access and Network Exposure Function. This block provides access to networking capabilities and smooth communication between the application layer and the underlying network infrastructure. It consists of the AF and NEF. (vi) Network Resource Management. This block controls multiple aspects of the network, including resource distribution, addressing, routing, security, and the assignment of network slices to individual services. It consists of entities such as the NF, NRF, NSSAAF, NWDAF, and NSSF. (vii) Location Services. The main purpose of this block is to provide Location Services (LCS) to a UE or to other entities regarding one or more UEs. This is a collaborative effort between a number of Network Functions and service APIs in the 5GC, including the AMF, UDM, and NEF, but primarily the LMF and GMLC, which are the two primary pieces depicted in this block [51]. (viii) Signaling. It is crucial to have a robust signaling system to ensure communication amongst Network Functions in the event of unforeseen occurrences.

5G and LTE Network Architectures

99

Networks are becoming more intricate. Three signaling networks must be managed simultaneously for 5G: Signaling System 7 (SS7), Diameter, and HTTP. This results in increased network construction and management expenses. 5G signaling is mostly handled by SCP, BSF, and SEPP [52]. 2.3.2.2.1 5G Core Packet Controller Block The main elements and interfaces of the Packet Controller in the 5G CN are described as follows: (a) Access and Mobility Management Function (AMF) The main functions of the AMF are as follows: Termination of N1 and N2 interfaces. It communicates with the wireless network and the devices via the N2 and N1 interfaces, respectively. In this capacity, it terminates the gNB-CU-CP interface (N2) and the UE interface (N1). In contrast to the MME in the EPC architecture, the AMF is not responsible for session management. Instead, the AMF passes via the N11 interface any session management-related signaling signals received from the UE and gNB to the SMF Network Function. The AMF (as opposed to the MME) does not execute device authentication; instead, it orders this service from the AUSF Network Function [33, 53]. Registration Management. Registration Management is used to set the user’s context within the network and register or deregister UEs with the network. User equipment (UE) must register with the network in order to use any services that require it. The UE, once registered, may update its registration with the network for a variety of reasons, including to ensure it is still reachable (Periodic Registration Update), to reflect changes in its capabilities or to renegotiate its protocol settings [54]. The standard registration procedure is shown in Figure 2.29 [55]. 1. A Registration Request is sent by the UE. The registration type in the request indicates whether the UE is going to perform an Initial Registration, a Mobility Registration Update, a Periodic Registration Update, an Emergency Registration, or a Periodic Registration Update. The UE is in the RM-DEREGISTERED state and initiates a registration procedure due to its mobility, protocol parameters, or the need to request new network slices (i.e., the UE is in limited service state). • When the UE does an Initial Registration, it must provide the following UE identifying information: • If the UE is in RM-DEREGISTERED state, and if a native 5G GUTI has been allocated to the UE by the same or a similar PLMN, the UE should use it; otherwise, the UE should use a native 5G GUTI assigned by a different PLMN. • The AMF-allocated native 5G GUTI from the earlier Registration process must be provided if the UE is already in the RM-REGISTERED state via another access in the same or equivalent PLMN.

100

5G NR Modeling in MATLAB®

FIGURE 2.29  General UE registration procedure in 5G.

• The UE must have a native 5G GUTI (if available) assigned by a PLMN that is not the same as or equal to the PLMN in which the UE is already in RM-REGISTERED state if it is already in RM-REGISTERED state via another access in a PLMN that is not equivalent to the PLMN the UE is attempting to register with. If not, the UE is expected to have its Subscription Concealed Identifier (SUCI) included in the Registration Request.

5G and LTE Network Architectures











101

2. In the absence of a 5G GUTI or if that 5G GUTI does not point to a legitimate AMF, the (R)AN will make that choice using the (R)AT and the Requested NSSAI, if available. 3. The N2 message is transmitted from the (R)AN to the new AMF, and it consists of the following parts: N2 parameters, Registration Request (as explained in step 1), and information on the UE’s access selection and PDU session selection, UE Context request. 4. The new AMF can access the Subscription Permanent Identifier (SUPI) and UE context of an old UE stored in the UDSF through the Nudsf UnstructuredDataManagement Query service action if the UE’s 5G GUTI was part of the Registration Request, the serving AMF has changed since the last registration procedure, both the new and old AMFs are in the same AMF Set, and UDSF is in use. If the serving AMF has changed since the UE’s last Registration procedure, the new AMF may use the Namf_ Communication_UEContextTransfer service operation to request the UE’s SUPI and UE Context from the previous AMF by sending the previous AMF the complete Registration Request NAS message, which may be integrity protected. When the new AMF uses Namf_Communication_ UEContextTransfer, the old AMF will respond with the UE’s SUPI and UE Context if the old AMF was queried in step 4. 5. In cases when the SUCI cannot be obtained from the previous AMF or supplied by the UE, the Identity Request procedure is initiated by the AMF sending an Identity Request message to the UE. 6. When prompted, the UE will send back an Identity Response that contains the SUCI. The HPLMN’s public key is provided to the UE, and it uses that key to calculate the SUCI [55]. 7. An AUSF could be invoked by the AMF to begin the UE authentication procedure. When this occurs, the AMF chooses an AUSF according to SUPI or SUCI. 8. The AUSF must carry out UE authentication when requested to do so by the AMF. After UE authentication, the AUSF shares security-related data with the AMF. If the AMF has supplied the AUSF with an SUCI, the latter is required to supply the former with the SUPI only once authentication has been completed successfully. 9. If the AMF has changed, the new AMF notifies the old AMF via the Namf_ Communication RegistrationCompleteNotify service action that the registration of the UE in the new AMF is complete. 10. If the UE has not already supplied the PEI or retrieved it from the previous AMF, the AMF will send an Identity Request message to the UE to obtain it. Unless an Emergency Registration is being performed and the UE cannot be validated, the PEI transfer must be encrypted. 11. The new AMF may commence ME identity verification by using the N5geir_EquipmentIdentityCheck Get_service operation. 12. If step 14 is to be performed, the new AMF, based on the SUPI, selects a UDM, and then UDM may select a UDR instance.

102

5G NR Modeling in MATLAB®

13. (a)  Using Nudm_UECM_Registration, the new AMF registers with the UDM and subscribes to be alerted when the UDM deregisters this AMF. The UDM does not delete the AMF identity associated with the other Access Type. (b) Information about SMF Selection Subscriptions, UE context, and Access and Mobility Subscriptions are retrieved by the AMF using Nudm SDM Get. (c) After receiving a successful response, the AMF subscribes to be alerted when the requested data is updated using Nudm_SDM_Subscribe. When the UDM stores the associated Access Type (e.g., 3GPP) together with the serving AMF as indicated in step 14(a), it will cause the UDM to initiate a Nudm_UECM_DeregistrationNotification to the old AMF. Using Nudm_SDM_unsubscribe, the Old AMF unsubscribes from the UDM for subscription data. 14. The AMF initiates PCF communication, to obtain an Access and Mobility policy for the UE. 15. An AM Policy Association Establishment is performed by the new AMF. 16. In order to activate the User Plane connections of the PDU Sessions mentioned in the “List Of PDU Sessions To Be Activated”, the AMF must first submit a Nsmf_PDUSession_UpdateSMContext Request to the SMF(s) associated with the PDU Sessions in step 1. Nsmf_PDUSession_ ReleaseSMContext is a service action used by the AMF to request that the SMF release all network resources associated with a PDU Session once the UE has marked it as released. 17. If the AMF has changed and the previous AMF showed an NGAP UE association towards a N3IWF, then the new AMF will create an NGAP UE association towards the N3IWF that the UE is associated with. The previous AMF’s NGAP UE relationship with the N3IWF is automatically revoked as a result. 18. The N3IWF sends the N2 AMF Mobility Response () to the new AMF [55]. 19. The old AMF will execute an AMF-initiated Policy Association Termination if it had previously established a Policy Association to the PCF and had not transferred the PCF ID(s) to the new AMF (for example, the new AMF is in a different PLMN). 20. When a UE’s Registration Request is approved, the AMF will notify it via a Registration Accept message. In the event that a new 5G GUTI is assigned by the AMF, support for such identifier will be provided. 21. When a UE is successfully updated in response to a Network Slicing Subscription Change Indication, it will send a Registration Complete message to the AMF. If a new 5G GUTI has been assigned, the UE will notify the AMF via a Registration Complete message. 22. The AMF will transmit the UE’s confirmation to the UDM using the Nudm SDM Info message type if the Steering of Roaming information is part of the Access and Mobility Subscription data that the UDM sends to the AMF in 14(b) and the UDM requests it [55].

5G and LTE Network Architectures

103

- Connection Management. Establishing and disabling a UE’s connection to the AMF via NAS signaling via N1 are two of the main responsibilities of connection management. By establishing this connection, NAS signaling can be sent between the UE and the CN. It consists of the N2 connection for this UE between the AN and the AMF, as well as the AN-to-UE signaling connection (RRC Connection over 3GPP access, UE-N3IWF connection over untrusted N3GPP access, or UE-Trusted Non-3GPP Gateway Function (TNGF) connection over trusted N3GPP access). There are two CM states used to represent the NAS signaling Connection of the UE with the AMF: CM-IDLE and CM-CONNECTED [54]. Both the 3GPP and Non-3GPP CM states can be in a different CM state at the same time; for example, the 3GPP CM state can be idle while the Non-3GPP CM state is connected. When the Mobile does not have signaling with the Core Node (AMF), such as RRC Idle, it is in a state defined by CM-IDLE. Mobility based on cell reselection governs UE’s movement across cells when in CM-IDLE. In contrast to RRC-Connected and RRC-Inactive, UEs that are CM-CONNECTED have established a signaling relationship with the AMF. Upon receiving N2 context established, the UE transitions to the CM-CONNECTED state. Registration Request and Service Request may be utilized. When the UE is powered on for the first time, it identifies the optimal gNB based on the cell selection procedure and transmits the Registration Request to commence RRC connect setup signaling towards the gNB and N2 Signaling to the AMF. Registration Request instigates the change from CM-IDLE to CM-CONNECTED. When the UE is in CM-IDLE when it needs to transmit uplink data, it sends a Service Request NAS message to the AMF and transitions to CM-CONNECTED [56]. An AMF that has signaling or mobile-terminated data to send to a UE in a CM-IDLE and RM-REGISTERED state must initiate a network-triggered Service Request procedure by sending a Paging Request to the UE if the UE is not prevented from responding (by, for example, being in MICO mode or being subject to Mobility Restrictions). Once a N2 connection is made between the AN and the AMF for this UE, the AMF will change to the CM-CONNECTED state. Upon getting the first N2 message, AMF goes from CM-IDLE to CM-CONNECTED (e.g., N2 INITIAL UE MESSAGE). By activating MICO mode, for instance, the UE and AMF can improve the CM-IDLE state UE’s power efficiency and signaling efficiency. To complete the AN Release procedure, the logical NGAP signaling connection and the N3 user plane connection for this UE must be released, at which point the AMF will transition the UE’s CM state from CM-CONNECTED to CM-IDLE. Before a UE is unregistered from the CN, the AMF may hold the UE in a CM-CONNECTED state in the AMF. The transitions between the CM-IDLE and CM-CONNECTED states from the perspective of the UE and AMF are shown in Figure 2.30 [56]. - Reachability Management. For the network to communicate with the UE, it must first determine if the UE is reachable and then determine the UE’s location (i.e., the access node). It does this by monitoring the location of UE and paging UE. Tracking the UE's registration area (UE registration area update) and UE reachability (UE

104

5G NR Modeling in MATLAB®

FIGURE 2.30  CM state transitions in the UE and AMF.

periodic registration area update) are both parts of UE location tracking. Such features can be found at either 5GC (in the CM-IDLE state) or NG-RAN (in the CM-CONNECTED state). During the Registration process, the UE and the AMF negotiate the UE’s reachability characteristics in the CM-IDLE state. For the CM-IDLE state, the UE and AMF negotiate between two categories of reachability for the UE: 1. UE reachability allowing Mobile Terminated data while the UE is CM-IDLE state. Within this category, the network is aware of the UE’s location with a Tracking Area List level of precision, and standard paging protocols are in effect. In this category, both CM-CONNECTED and CM-IDLE states use mobile originating and mobile terminated data. 2. Mobile Initiated Connection Only (MICO) mode: • Mobile-originated data is supported for both CM-IDLE and CM-CONNECTED. • Mobile terminated data is supported only when the UE is in the CM-CONNECTED state. When a UE transitions from the RM-REGISTERED to the CM-IDLE state, it begins a periodic registration timer using the value it obtained from the AMF during the Registration procedure. The AMF assigns the UE a unique periodic registration timer value based on the UE’s location, the type of subscription the UE has, and any other information the AMF deems relevant. When the UE’s periodic registration clock runs out, it must complete a periodic registration. When the UE’s periodic registration timer expires, it must perform a Registration procedure as soon as it returns to network coverage. To keep track of when the UE is within mobile reach, the AMF uses a Mobile Reachable timer. When a UE in the RM-REGISTERED state transitions to the CM-IDLE state, the timer is reset to a value greater than the UE’s periodic registration timer. When the RAN initiates a UE context release that indicates the UE is

5G and LTE Network Architectures

105

FIGURE 2.31  UE reachability management by the AMF.

unreachable, the AMF may receive an elapsed time from the RAN that can be used to infer the Mobile Reachable timer value for the UE. If the UE CM state in the AMF transitions to the CMCONNECTED state, the AMF immediately resets the Mobile Reachable timer. Figure 2.31 depicts this procedure. AMF will determine that the UE is unreachable if the Mobile Reachable timer has elapsed, and the UE has not been reached. However, as the AMF has no way of knowing how long the UE would stay unreachable, it cannot deregister the UE right away. Instead, once the Mobile Reachable timeframe has expired, the AMF should clear the Paging Proceed Flag (PPF) and initiate a substantial Implicit Deregistration timer. If the AMF transitions the UE CM status in the AMF to CM-CONNECTED state [54, 57], the AMF must reset the Implicit Deregistration timer and set the PPF. Without a properly configured PPF, the AMF will not page the UE and will refuse any request to send DL signaling or data to that device. Before making contact with the network, the Implicit Deregistration timer triggers and the AMF implicitly deregisters the UE. The AMF must instruct the associated SMF of the unregistered UE to terminate any PDU Sessions that were originally started through the deregistered connection (3GPP or non-3GPP). - Mobility Management. The location of a UE within the network can be tracked with the help of mobility management. After initial registration, the UE must conduct frequent updates. These updates ensure that the UE is still active on the network and hasn’t wandered out of range or gone offline for any other cause using a mechanism known as keep-alive (for example UE stopped working or switched off). Due to its mobile nature, the UE must also complete updates. If the UE leaves the

106

5G NR Modeling in MATLAB®

registration region (the tracking area or the list of tracking areas in which the UE is registered), then these updates will occur [58]. For the same reason that it would be impractical to monitor a dormant UE’s movement between cells, searching for a UE across the whole network for every terminating event is also impractical (e.g., an incoming call). Therefore, cells are clustered into Tracking Areas (TA) to maximize efficiency, and a UE may be registered in one or more TAs (RA). The RA serves as a starting point for both the network’s search for the UE and the UE’s own location reporting. Each cell’s TA identification is broadcast by the gNB/ng-eNB, and the UE checks this identity against the identity of the TA or TAs it has stored as part of the RA it has been given. The UE initiates a procedure toward the network called a Registration procedure to tell it of its new position if the broadcasted Tracking Area is not part of the allotted RA. If a UE has been given a RA that includes TAs 1 and 2, and then enters a cell that is broadcasting TA 3, the UE will notice that the TAs in the broadcast information do not match the RA. In response to this disparity, the UE will conduct a Registration update transaction with the network. The UE uses this procedure to inform the network of its current TA. As part of the Registration update procedure, the network will provide a new RA to the UE, and the UE will store this RA in its memory while in transit [33]. In Figure 2.32, we see a high-level summary of the stages involved in a Registration Update caused by mobility (i.e., with Registration type set to Mobility Registration Update (MRU)):

FIGURE 2.32  Registration update procedure due to mobility [33].

5G and LTE Network Architectures

107



1. When UE performs a cell reselection and notices that the broadcast TA ID is not in the list of TAs in the RAN, the UE will initiate a Mobility Resource Update (MRU) procedure to the network, and the Next Generation Radio Access Network (NG-RAN) will route the MRU to an AMF serving the newly selected area. 2. The AMF verifies whether or not a context for the UE is already stored, and if not, it verifies the temporary identity (5G GUTI) of the UE to ascertain which AMF stores the UE context. Once this is established, the AMF contacts the previous AMF to obtain the UE context. 3. When switching to a new AMF, the UE context is passed from the previous AMF. 4. Upon receiving the old UE context, the replacement AMF notifies the UDM that the UE context has moved to a replacement AMF by registering with the UDM, subscribing to be notified when the UDM deregisters the AMF and requesting the UE's subscriber data from the UDM. 5–6. The UE context (for 3GPP Access Type) is removed from the legacy AMF by the UDM. 7. The UDM confirms receipt of the updated AMF and updates the AMF with information about the subscribers. 8. When an MRU is successful, the AMF updates the UE’s 5G GUTI (where the GUAMI points back to the AMF) and notifies it of the change [33]. In addition, when a different cell can provide better service than the cell the UE is presently using, the UE switches to that cell via a handover to reduce interference and ensure reliable data communication. The systems are built such that a UE only needs to listen to one gNB/ng-eNB at a time, reducing the complexity of the UE’s design and the amount of power it consumes. The UE takes readings of the signal strength of neighboring cells regularly, or when prompted to do so by the network, to determine whether to initiate handover. Signal quality is regularly monitored and reported using Radio Resource Control (RRC) signaling. Since the UE cannot simultaneously send and receive data, the network instructs the UE on which nearby cells are optimal and which ones to measure. There are periods during measurements when neither incoming nor outgoing data can be processed by the network (NG-RAN). The UE uses the silence between measurements to fine-tune its receiver to neighboring cells and gauge the strength of their signals. The NG-RAN may commence the handover process to another cell if the signal strength there is noticeably higher. Direct handover between NG-RAN nodes is possible because of the NG-direct RAN’s interface, also known as the Xn interface. With Xn-based Hand-Over (HO), both the source and the destination NG-RAN nodes do their part in getting the HO procedure ready to go. The HO’s final step is for the destination NG-RAN node to request that the AMF reroute downlink traffic from the source NG-RAN node to itself. The SMF then updates the UPF servicing the PDU Session after being instructed to do so by the AMF, which directs all traffic to the new NG-RAN node. The source NG-RAN node will use the Xn interface to send downlink packets before the UPF has switched the path to the new NG-RAN node [33]. Figure 2.33 depicts this example.

108

5G NR Modeling in MATLAB®

FIGURE: 2.33  UE handovers between source and target gNBs.

A handover requiring signaling via the 5GC network can be initiated by an NG-RAN node if the Xn interface is unavailable between the NG-RAN nodes. This is called N2-based handover. The signal is transmitted via the AMF in the N2-based HO method, which may also involve a switch to a different AMF and/or SMF/UPF. -Next-Generation Application Protocol (NGAP). The AMF also manages signalings between the AMF and gNB using the Next Generation Application Protocol (NGAP). Similar to S1AP in the case of 4G LTE, the NGAP parameters are outlined in [38]. S1 AP is between the MME and Base Station. As shown in Table 2.4 [59], there are several types of NGAP signaling methods. While a signaling radio bearer (SRB) is utilized to transmit NAS messages between UE and BTS, NGAP is used to transmit NAS messages between the BTS and AMF. End-to-end NAS message transmission between UE and AMF over the N1 interface is made possible by the combination of these hops. Figure 2.34 depicts the interplay between NAS and NGAP signaling [48, 54, 55, 59]. - Additional AMF Functions. There are several other important functions carried out by the AMF which are summarized in Table 2.5 [48, 54, 55, 59, 60]. (b) Session Management Function (SMF) The Session Management Function (SMF) controls the sessions of the end user (or, more precisely, the device). This comprises the creation, modification, and termination of individual sessions, as well as the allocation of IP addresses per session. The AMF relays session-related messages between the devices and the SMFs, allowing the SMF to communicate indirectly with end user devices. The SMF communicates with other Network Functions via producing and receiving services over its servicebased interface (as described in Subsection 2.2.1.2), but it also selects and manages

109

5G and LTE Network Architectures

TABLE 2.4 NGAP Procedures and the AMF Procedure

Description

PDU session management procedures

Used for initialization, modification, and release of Base station and UE resources. PDU Session Management is the responsibility of the SMF; the AMF follows these processes only after receiving instructions from the SMF.

UE mobility management procedures

Used in conjunction with handover processes. When performing a handover using the Xn protocol, the NGAP Path Switch Signaling method is used. For N2-based handovers, NGAP employs the Handover Required, Handover Request, Handover Command, and Handover Notify signaling methods. These procedures are used to set up the NG connection between the Base Station and AMF. The NG link between the BS and the AMF is used for both the N1 and N2 interfaces. Updates to the RAN and AMF configurations are made possible through the procedures of Interface Management. If the Base Station's supported PLMN or Tracking Areas have changed, for instance, the RAN configuration update will allow it to communicate this information to the AMF.

Interface management procedure

Configuration transfer procedure

This procedure facilitates communication between the Base Station and AMF for the purposes of Self-Optimizing Networks. Automatic Neighbor Relationships is one application of methods in this context (ANR). There may be two Base Stations involved in the end-to-end transfer of data, but if an Xn interface does not exist between them, the data must be transferred through the AMF.

the other UPF Network Functions in the network via the N4 network interface. This control configures individual sessions’ traffic guiding and enforcement in the UPF. In addition, the SMF plays a vital part in all network functionality pertaining to charging. It collects its own charging statistics and regulates the charging operation within the UPF. The SMF provides both offline and online charging capabilities. In addition, the SMF communicates with the PCF Network Function for Policy Control of user sessions via the N7 network reference point [33]. It communicates with the CHF via the N40 reference point to acquire charging information.

FIGURE 2.34  Brief of NAS and NGAP signaling paths.

110

5G NR Modeling in MATLAB®

TABLE 2.5 Additional AMF Functions Function

Description

5G Globally Unique Temporary Identifier (5G GUTI)

5G Temporary Mobile Subscription Identifier (UTMSI) and Globally Unique AMF Identifier (GUAMI) are concatenated to form the 5G Globally Unique Temporary Identifier (GUTI), which is assigned by the AMF (5G TMSI). The 5G GUTI provides greater privacy than the IMSI does since it is a temporary identity that can be changed at any time by the AMF. The 3GPP has defined the rules for mapping between 5G GUTI and 4G-GUTI.

AUSF Selection

During the activation procedure, AMF must decide on an AUSF that will be used for authentication. The UE can check the subscriber’s identity and network privileges with the 5G CN via the AUSF. The AMF can be configured to use a predefined AUSF, or it can use the 5G CN’s Network Function repository Function (NRF) to identify which AUSF is best suited for the current situation. While registering, AMF must decide on a suitable Unified Data Management (UDM) function. A user’s subscription details are handled by the UDM. The AMF can be set to function with a predetermined UDM, or it can make use of the Network Function Repository Function (NRF) to locate a UDM that handles the user’s subscription. When registering a new UE, it is the responsibility of the AMF to determine which Policy Control Function (PCF) will best serve the UE’s needs. An “Access and Mobility Policy” for the UE is provided by the PCF to the AMF. The tracking areas that are permitted or prohibited may be specified. The Associated Mobile Function (AMF) can be set to use a predetermined PCF, or it can use the Network Function Repository Function (NRF) to find a PCF that can supply the necessary UE data. When a PDU session is being established, it is the responsibility of the AMF to choose the SMF that will be in charge of the session. During the selecting process, AMF may take into account a variety of factors, including: (i) Data Network Name (DNN). DNN replaces the APN in 4G. It refers to the data network to which PDU Session connects. (ii) Subscription Information. During the registration process, AMF accesses the UDM feature to retrieve subscriber information. The set of DNNs to which a user has subscribed can be included there. After being received from the SMS Function (SMSF), mobile-terminated SMS are placed within a NAS message and sent on to the UE. Across the air interface, the NAS message is transmitted using a signaling Radio Bearer (SRB). When an SMS is sent from a mobile device, the AMF will pick it up as part of an uplink NAS message and deliver it to the SMSF. The Short Message Service Function (SMSF) can be disabled as a Network Function.

UDM Selection

PCF Selection

SMF Selection

Support for Short Message Service (SMS) Supports the N14 Roaming Interface

To facilitate UE roaming with AMF relocation (idle mode mobility), the N14 interface must be established as a roaming interface between access and mobility functions between PLMNs (AMF). Due to registration and authentication time, a successful attachment, which creates a user context in the visiting network, requires additional time. This is addressed by the extra roaming interface between AMFs (N14), which permits the AMF in the VPLMN to retrieve the UE context from the source AMF. The N14 interface also facilitates the re-establishment of the user plane on the new network. Since the new network is aware of the used UPF and UE IP address, the user plane is re-established as part of the new network’s tracking area update [60].

5G and LTE Network Architectures

111

FIGURE 2.35  PDU session establishment.

The main functionalities of the SMF are elaborated as follows: - PDU Session Management. In order to communicate with a DN, the UE initiates the establishment of a PDU Session. A connection between the UE and a certain DN is made during each PDU Session. DNN of the DN to which the UE intends to connect may be sent to the 5G CN by the UE during the establishment of a PDU Session establishment request. Figure 2.35 provides an overview of the PDU Session Establishment call flow, outlining the critical Network Functions and process processes involved [33]. - IP Address Allocation. It is the responsibility of the SMF to assign an IP address to the UE. The SMF identifies the PDU Session Type based on the IP versions supported by the DN when it receives the UE’s request to establish a PDU Session. During the PDU Session Establishment method, the UE sets the requested PDU Session Type depending on its IP stack capabilities when it requests an IP-based PDU Session. • Any UE that may use both IPv4 and IPv6 must use the operator’s provided configuration or policy to determine which protocol version to use when sending the PDU requesting a session (i.e., IPv4, IPv6, or IPv4v6). • If UE can only use IPv4, then it must request PDU Session Type “IPv4”. • If a UE can only communicate using IPv6, it must request PDU Session Type “IPv6”. • PDU Session Type “IPv4v6” must be requested by the UE when the IP version capabilities of the UE is unknown (for example, when the IP stack is implemented on a device other than the 5G modem). - GTP-U Tunnel Management. Session Management’s primary responsibility is to manage the User Plane for the PDU Session. Actual end-user data is transported between the UE and the DN on the User Plane. User Plane in NG-RAN is comprised of one or more Data Radio Bearers

112

5G NR Modeling in MATLAB®

(DRBs) maintained by NG-RAN. Over the N3 and N9 reference points, GTP-U tunnels transport User Plane data. GTP-U Tunnel Management is responsible for managing the GTP-U tunnel used by the user plane between the Base Station and the UPF. Users’ plane traffic is routed through GTP-U tunnels between the BS and UPF. User plane packets can be routed through a GTP-U tunnel by adding IP/UDP/GTP-U headers. For packet routing between the BS and the UPF, the IP layer is used. The GTP-U port is determined by the UDP layer, which also offers connectionless data transfer [33, 61]. For each PDU Session, a user plane packet has a unique Tunnel Endpoint Identifier (TEID) that is defined by the GTP-U layer. - UPF Selection. In order to make appropriate UPF selections, SMF needs to be aware of the various UPFs and their accompanying properties, such as UPF capacities, load status, etc. There are a variety of approaches that can be used. First, O&M can set up the SMF to use any of the various UPFs. So that SMF is aware of the position and connectivity of UPFs, this configuration may include topology-related information (e.g., properties of the links between). Because of this, the SMF is able to select appropriate UPFs, for instance, depending on the UE’s location. Available UPFs can be located with the help of the NRF as well. In this case, the SMF can issue a query to the NRF to retrieve a list of UPFs and some fundamental information about each UPF, such as the DNN(s) and network slice(s) (S-NSSAI) that each UPF supports. Further, the N4 protocol makes it possible for SMF and UPF capabilities to be traded off at the first N4 connection setup. The UPF’s load [33] and other information, such as whether it supports features like traffic steering (service chaining) on N6-LAN, header enrichment, traffic rerouting, etc., will be learned by the SMF. Some of the two main network reference point interfaces associated with the SMF are described as follows: (i) N4 interface. N4 Interface connects the control plane to the user plane. To that end, it acts as a bridge between the UPF and the SMF, reporting consumption and events of PDUs and handling session management for PDU traffic. For tasks unrelated to individual N4 sessions, such as establishing and managing the interface between an SMF and a UPF, the N4 node-level procedures are employed. N4 interfaces are created and destroyed during the setup and release processes. The release process is always begun by the SMF, but the setup and update procedures can be started by either the SMF or the UPF. In case there is a modification to the set of capabilities that are supported by the network, the update mechanism will notify the N4 peer of the modification. In addition to informing the SMF of resource availability, a UPF can instruct the SMF to begin a release procedure by using the update procedure [62]. As described in [63], the N4 employs the Packet Forwarding Control Protocol (PFCP).

5G and LTE Network Architectures

113

(ii) N11 Interface. An N11 interface is used by the AMF to relay session management requests to the SMF. The addition, modification, or removal of a PDU session over the user plane is triggered by messages received via the N11 interface. Using the Packet Forwarding Control Protocol (PFCP) [64], the SMF communicates with the UPF over the N4 reference interface. (iii) N16 Interface. Two SMFs can be found at the N16 Reference point. It would take place between a Visited SMF and the Home SMF in a roaming scenario [65]. (c) Short Message Service Function (SMSF) Text messages can be sent and received using the SMSF, which allows for NASbased SMS communications. In this role, the SMSF will interface with the AMF to check subscriptions and act as a relay between the device and the Short Message Service Centre (SMSC) (Core Access and Mobility Management Function). The SMSF allows for the following features to be used to support SMS over NAS [38]: • Verifying subscriber information and sending out SMS messages as needed as part of an SMS management system. • UE communication using Short Message Relay Protocol (SM-RP) and Short Message Control Protocol (SM-CP). • Sender Message (SM) relaying from UE to SMS-GMSC/IWMSC/ SMS-Router. • Send the SM that was originally sent from the SMS-GMSC/IWMSC/SMSRouter to the UE. • CDR for SMS. • Lawful interception. • Procedure for notifying AMF and SMS-GMSC that a user equipment is not available for SMS transfer. Figure 2.36 provides an illustration of the Non-roaming System Architecture for SMS over NAS.

FIGURE 2.36  Non-roaming system architecture for SMS.

114

5G NR Modeling in MATLAB®

Standard interfaces are provided in [66,67] for connecting the SMSF and UDM to the SMS-GMSC/IWMSC/SMS Router. In a registered PLMN, each UE can only ever be linked to a single SMS Function. This Release of the standard [38] does not permit SMSF reallocation while the UE is in the RM-REGISTERED state in the serving PLMN. The source AMF sends the SMSF identification along with the UE context when a new serving AMF is allocated. In the event of inter-PLMN mobility, for example, the target AMF will carry out SMSF selection if it determines that no SMSF has been selected in the serving PLMN. As for SMSF’s two network interfaces, they are as follows: • N20. Link between AMF and SMSF for SMS transfer. • N21. Interface between SMSF and UDM for SMSF address registration management and SMS Management Subscription data retrieval. (d) UE Radio Capability Management Function (UCMF) Dictionary entries corresponding to PLMN-assigned or Manufacturer-assigned UE Radio Capability IDs are stored in the UCMF. Any AMF can subscribe to the UCMF to have access to the new values of the UE Radio Capability ID that the UCMF assigns for local caching [38]. The AF communicates with the UCMF in order to add entries for the manufacturer-assigned UE Radio Capability IDs. This can be done directly, through the NEF, or through Network Management. The UCMF is responsible for assigning the values used by the PLMN to identify the UE’s radio capabilities. The PLMN provides an identifier for each UE model’s radio capabilities called the UE Radio Capability ID. The TAC of the UE for which the UE Radio Capability information is requested is supplied by the AMF when the UCMF is asked to assign a UE Radio Capability ID. The UCMF keeps track of the Version ID value for PLMN-supplied UE Radio Capability IDs, ensuring that it is included in the UE Radio Capability IDs granted by the PLMN. This setup is performed in the UCMF. It is possible for the PLMN to provide the UCMF with a list of TACs for which it has gotten UE Radio Capability IDs and a dictionary of Manufacturer-issued UE Radio Capability IDs, including a “Vendor ID” relevant to the manufacturers of these UE. The UCMF will keep any Radio Capability IDs for UEs that have been allocated to it by a PLMN, provided that they are linked to at least a TAC value. Any UE Radio Capability IDs in the UCMF that were allocated to the UE by the PLMN are no longer associated with the TAC value for the UE model once it has been designated for operation based on manufacturer-provided UE Radio Capability IDs. Figure 2.37 shows the interface connections and reference point from AMF to UCMF. The main interfaces of the UCMF are as follows [38]: N55. Link between the UCMF and the AMF. N56. Link between the UCMF and the NEF. N57. Link between the UCMF and the AF.

5G and LTE Network Architectures

115

FIGURE 2.37  UCMF connections.

(e) User Plane Function (UPF) The User Plane Function (UPF) is a crucial part of the 3GPP 5G Core Network’s overall system architecture. As part of their Release 14 specifications, the 3GPP recommended the UPF as an enhancement to preexisting Evolved Packet Cores (EPCs) by separating the control plane from the user plane. In order to distribute the data-forwarding component, CUPS separates the PGW’s control plane from its user plane (PGW-U). Because of this, packet processing and traffic aggregation can be handled closer to the network’s edge, improving bandwidth efficiency while reducing network strain. Signaling traffic PGWs (PGW-C) are still located in the core, northbound of the MME [68]. CUPS was developed to ease the introduction of 5G NR, which in turn would allow for the development of early Internet of Things (IoT) applications and higher transfer rates. Nevertheless, implementing a 5G UPF, such as network slicing, offers several advantages, whereas committing to a thorough implementation of control and user plane separation is a challenging proposition. Service-Based Architectures (SBAs) rely on packet processing, which is provided by the UPF when it is implemented within a dynamic cloud-native computer infrastructure [68]. The UPF performs the following functions as specified in the 3GPP TS 23.501 [33, 38, 68, 69]: • It encapsulates and decapsulates GPRS Tunneling Protocol for the user plane (GTPU) and serves as an interface between the mobile infrastructure and the Data Network (DN). • It sends and relays end markers to the source NG-RAN node. When offering mobility between Radio Access Technologies (RATs), it serves as the session anchor point for Protocol Data Units (PDUs) and sends one or more end marker packets to the gNB. The PDU session for the UE, which includes the UPF node, serves as both an anchor for the session and a reference point for the handover procedure. For the UPF to make the change to the N3 routes, the SMF must first send an N4 Session Modification Request message containing the updated AN Tunnel Info of NG-RAN. Also, the SMF

116

•

•

• •

•

•

5G NR Modeling in MATLAB®

directs the UPF to use the previous N3 user plane path for transmitting End Marker packets. When the UPF receives the signal, it generates the End Markers and sends them down each N3 GTP-U tunnel leading back to the source NG-RAN once the last PDU has been transmitted along the old path. It acts as an Intermediate UPF (I-UPF) with several connections to PDU session anchors (PSA), a Branching point, an Uplink Classifier (UL-CL) (directing flows to specific data networks based on traffic matching filters), and a regular UPF (UFP). Based on the data stored in the Ethernet PDUs’ local cache, it can respond to requests for Address Resolution Protocol (ARP) and IPv6 Neighbor Solicitation. When receiving an ARP or IPv6 Neighbor Solicitation Request, the UPF will reply with the relevant MAC address. It identifies applications through the use of traffic filter templates from the Service Data Flow (SDF) or the 3-tuple (protocol, server-side IP address, and port number) Packet Flow Description (PFD) from the SMF. It performs reflective QoS (DSCP) marking and rate limiting on the downlink, as well as UL and DL transport level packet marking. As an added feature, it can label packets with QoS indicators for transmission over the radio network or to other networks. In the event of network congestion, the transport network can use this to provide each packet with the priority it requires. It reports traffic use for billing purposes and acts as an interface for Lawful Intercept (LI) collectors. It creates traffic use data for the SMF, which are included in billing reports by the SMF for other Network Functions. Packet inspection, in which the UPF examines the contents of user data packets, can be used to inform policy decisions, or form the foundation of traffic use reporting. It carries out a wide range of user and network policies, such as gating, traffic rerouting, and rate limiting. When a device is in a disconnected state and the network sends data to it, the UPF stores the data and then pages the device to get it to reconnect so it may receive the information.

The following interfaces are distinct interfaces for the UPF: • N3. Interface linking the gNB to the (initial) UPF. • N9. Interface linking two UPFs together (the Intermediate I-UPF and the UPF Session Anchor). • N6: Interface linking the Data Network (DN) and the UPF. • N4. Interface linking the Session Management Function (SMF) to the UPF. Figure 2.38 depicts these reference point connections as well as the data flow from the Endpoints (UE and other devices) to the CN. The GPRS Tunneling Protocol (GTP) with 5G-specific header modifications, Segment Routing (SRv6 or NSH), or an Information-Centric Networking (ICN) protocol may be used on the N3 and N9 interfaces. Identifier Locator Addressing (ILA) and the Locator/ ID Separation data plane protocol (LISP-DP) are two additional protocols that can be

5G and LTE Network Architectures

117

FIGURE 2.38  UPF reference points and connections between endpoints and the CN.

used on top of GTP. As shown in Figure 2.39, these protocols are terminated by the UPF PDU Session Anchor, while an I-UPF serves as a relay [68]. The UPF may determine the direction of traffic based on information received from the SMF via the N4 reference point. The N4 interface employs the Packet Forwarding Control Protocol (PFCP), which was originally defined in 3GPP technical specification 29.244 [63] for usage on Sx reference points in favor of CUPS. To support mobile networks, PFCP can be modified to incorporate only the functionalities that are required. Setting up PFCP sessions with the UPF allows the latter to define policies for packet detection (using Packet Detection Rules), forwarding (using Forwarding Action Rules), processing (using Buffering Action Rules), marking (using Quality of Service Enforcement Rules), and reporting (using Usage Reporting Rules). Figure 2.40 illustrates this procedure. To accommodate the primary requirement of 5G, granular capacity or application-driven, instantiation and up/down-scaling, the UPF must be designed as a pure cloud-native network function leveraging modern microservices approaches and deployable within a serverless framework. High packet throughputs with complex pipelines and low latencies have historically been achieved with dedicated hardware and specialized silicon. Intricate real-time data processing concerns must be resolved, and a pipeline with a high degree of adaptability must be introduced, if a cloud native UPF is to be provided on shared resources, which must account for traffic tunneling, people mobility, and infrastructure overlay. Further, UPF activation must be automatically and systematically initiated. To achieve this, collaboration with numerous cloud orchestration platforms, such as Kubernetes [68] is required. Furthermore, the creation or enhancement of user-space data plane acceleration, runtime programmability techniques, and tight integration is necessary.

118

5G NR Modeling in MATLAB®

FIGURE 2.39  5G user plane protocol stack showing the UPF reference points.

FIGURE 2.40  Packet processing flow in the user plane function.

2.3.2.2.2 5G Core Subscriber Management Block The elements of the 5G Core Subscriber Management Block are described as follows: (a) Unified Data Management (UDM) UDM is a centralized system for managing data generated by network users. Similar to Home Subscriber Service (HSS) in 4G/LTE, this service is cloud-based and optimized for 5G. As part of a 5G network, the HSS is divided into the Authentication Server Function (AUSF) and the UDM [70]. It provides access to the user subscription information held in the UDR and carries out critical operations when requested by various Network Functions (NFs). To store subscriber profiles, policy information, structured data, and application data, UDR can be used in conjunction with this technology. The UDM provides services to other 5GC components such as the AMF, SMF, SMSF, AUSF, etc. through its Nudm service-based interface. The network reference points between the UDM and other entities in the 5GC is shown in Figure 2.41 [70].

5G and LTE Network Architectures

119

FIGURE 2.41  Network reference point connections to the UDM.

The main network reference point connections are as follows [38]: • • • • • • •

N8. Interface linking the UDM with the AMF. N10. Interface linking the UDM with the SMF. N13. Interface linking the UDM with the AUSF. N21. Interface linking the UDM with the SMSF. N35. Interface linking the UDM with the UDR. N52. Interface linking NEF with the UDM. N59. Interface linking UDM with the NSSAAF.

The main functions of the UDM are as follows: • 3GPP AKA Authentication Credentials creation. • Handling of User Identification Handling. This includes the storage and management of subscribers’ SUPI. • Support of the deconcealment of SUCI. • Provision of access authorization based on subscription information (e.g., roaming restrictions). • Management of UE’s Serving NF Registration. This includes storing serving AMF for UE and storing serving SMF for the subscribers’ PDU Session). • Support for service and session continuity. This can be done by keeping SMF/DNN assignment of ongoing sessions. • Support for the delivery of MT-SMS. • Lawful Interception (especially in outbound roaming cases where UDM is the only point of contact for LI).

120

5G NR Modeling in MATLAB®

• Management of Subscription and SMS. • 5GLAN group management handling. • Support for the provision of external parameters (Expected UE behavior parameters or network configuration parameters). If the UDR stores subscription data (including authentication data), then a UDM can perform the application logic without needing to keep any user information locally, and many UDMs can serve the same user for various transactions. Additionally, the UDM saves UE’s Service Area Restrictions with the UE’s subscription information. The AMF retrieves the UE’s Service Area Restrictions from the UDM upon registration, which the PCF can then modify if necessary. If the UE’s Service Area Restrictions are not already in the AMF. • If the NEF has access to the IMSI and application port ID, it can query the UDM for the GPSI. • If a UE is serviced by both a 3GPP access and a non-3GPP access (i.e., via a N3IWF, TNGF, and W-AGF) of the same PLMN, then the UE will have two RM contexts, one for each access. For each access, the UDM controls separate/independent UE Registration operations. • The UDM is required to provide the AMF with the defined information regarding any NR or E-UTRA access restrictions imposed on a subscriber by the operator, taking into account factors such as the customer’s location while roaming. If NR is not authorized as primary or secondary access in licensed or unlicensed bands, the AMF will know. When E-UTRA is blocked as primary or secondary access in licensed or unlicensed bands, the AMF is informed. • Based on subscriber information in the UDM or configuration on a persubscriber, per-DNN, and per-S-NSSAI basis, the 5GC may also allow the allocation of a static IPv4 address and/or a static IPv6 prefix. The SMF will retrieve the static IP address/prefix from the UDM during the PDU Session Establishment function [38] if it is present in the UDM. (b) Authentication Server Function (AUSF) As stated in [71], the Authentication Server Function (AUSF) allows for UE authentication for a Disaster Roaming service as well as authentication for 3GPP access and untrusted non-3GPP access. As it can be seen in Figure 2.24, it communicates with the AMF via the N12 network reference point and the UDM via the N13 network reference point. The Authentication and Key Agreement (AKA) process allows for secure communication in any cellular network by performing mutual authentication between the User Device and the network and then deriving crypto keys to protect the U-plane and C-plane data. Each generation of mobile communication systems introduces a new authentication mechanism to ensure that only authorized users are granted access to the network. For 4G LTE, 3GPP defined EPS-AKA; similarly, three authentication mechanisms are defined for 5G: • 5G AKA which stands for 5G Authentication and Key Agreement.

5G and LTE Network Architectures

121

• EAP-AKA which stands for Extensible Authentication ProtocolAuthentication and Key Agreement. • EAP-TLS which stands for Extensible Authentication Protocol-Transport Layer Security. In order to facilitate a unified authentication framework, 3GPP has suggested a Service Based Architecture for the CN. This architecture will include new network entities and new services. This framework utilizes three authentication techniques— 5G AKA, EAP-AKA’, and EAP-TLS—to make the 5G AKA procedure open and access-network agnostic [72,73]. Some of the new entities relevant to 5G authentication are as follows: • During the authentication procedure between a UE and its primary network, the Security Anchor Function (SEAF) acts as a “middleman” from within a serving network. Even though it can refuse UE authentication, it largely depends on the home network of the UE to accept the authentication. • The home network Authentication Server Function (AUSF) is responsible for verifying the identity of a UE. While it chooses whether or not to employ 5G AKA or EAP-AKA’ for UE authentication, it must rely on a backend service to generate the necessary authentication data and keying materials. • When authentication is required, the AUSF relies on the Authentication Credential Repository and Processing Function (ARPF), a data management function hosted by the UDM entity, to select an authentication method based on subscriber identity and configured policy and to compute the authentication data and keying materials. • Subscription Concealed Identifier (SUCI) decryption is performed by the Subscription Identifier Deconcealing Function (SIDF), which then returns the Subscription Permanent Identifier (SUPI), such as the International Mobile Subscriber Identity (IMSI). Long-term subscriber identifiers are always communicated across radio interfaces in 5G, but they are encrypted. Specifically, the SUPI is encrypted using a public key. As a result, UEs’ SUPI encryption relies on public keys that can only be decrypted by the SIDF. Using a unified framework, Figure 2.42 shows how 5G authentication can be made open (for example, by enabling EAP) and access-network agnostic (for example, supporting both 3GGP access networks and non-3GPP access networks like Wi-Fi and cable networks). By way of example, whether EAP-AKA’ or EAP-TLS is employed, EAP authentication takes place between the UE (an EAP peer) and the AUSF (an EAP server) via the SEAF (functioning as an EAP pass-through authenticator). Non-3GPP Interworking Function (N3IWF) is a new entity that acts as a VPN server to enable the UE to connect to the 5G Core through untrusted, non-3GPP access networks via IPsec (IP Security) tunnels when authentication takes place over such networks.

122

5G NR Modeling in MATLAB®

FIGURE 2.42  5G authentication framework.

By establishing several security contexts with a single authentication execution, UEs can seamlessly transition from 3GPP access networks to non-3GPP networks without requiring re-authentication. New authentication-related services have been established by 3GPP for 5G. For instance, AUSF offers its authentication service via Nausf_UEAuthentication, while UDM offers its authentication service via Nudm_UEAuthentication. The following figure depicts the sequence and authentication vector, which only contain some of the information. A primary authentication method in a 5G network must use either 5G AKA or 5G EAP-AKA’. It is possible to utilize other EAP-based authentication mechanisms if desired. If it helps, let us think of the authentication process as having two stages: Phase 1. Initiation of authentication procedure and selection of the authentication method. Phase 2. Mutual authentication between the network and the UE. Figure 2.43 shows the authentication procedure. The authentication procedure is as follows: 1. If a 5G GUTI has not been assigned to the UE by the serving network, the UE must instead give the SEAF either a temporary identification (a 5G GUTI) or an encrypted permanent identifier (a SUCI). When the SUPI is encrypted with the home network’s public key, the resulting string is called the SUCI. Accordingly, in 5G, a UE’s permanent identifier, such as the IMSI, is never transmitted in plain text across the radio networks. Compared to older technologies like 4G, it offers much better protection. 2. After receiving a registration request from a UE, the SEAF will send an authentication request (Nausf_UEAuthentication authenticate Request)

5G and LTE Network Architectures

123

FIGURE 2.43  5G AKA authentication procedure.

message to the AUSF, including the SNN of the providing network and the SUPI or SUCI, depending on whether or not the 5G GUTI is valid. Connecting the service ID and the Serving Network ID yields the SNN (SN Id). 3. Upon receiving the authentication request, the AUSF checks to see if the asking SEAF has been granted access to the SNN, a form of 5G home control. If the serving network is not permitted to use the SNN (Nausf_ UEAuthentication authenticate Response), AUSF will respond with “serving network not authorized” in the authentication response. In that case, the AUSF will forward the authentication request (Nudm_UEAuthentication Get Request) to the UDM/ARPF/SIDF. The SUCI or SUPI and the SNN make up this request. If you want to get the SUPI out of the SUCI, then you need to invoke SIDF. Based on SUPI and subscription information, the UDM/ARPF selects an appropriate authentication method. 4. The UDM/ARPF starts the 5G AKA process, derives the KAUSF and generates the RAND, AUTH, XRES*, and KAUSF for use in the 5G Home Environment AV (5G HE AV). 5. The UDM/ARPF then transmits the authentication response to the AUSF along with an authentication vector containing, among other data,

124

5G NR Modeling in MATLAB®

an AUTH token, an XRES token, the key KAUSF, and the SUPI if applicable (for instance, when a SUCI is provided in the related authentication request). 6. The AUSF computes a hash of the expected response token (HXRES) and stores the KAUSF. 7. Then, the AUSF includes the authentication response, the AUTH token, and the HXRES in a Nausf_UE_Authentication_Authenticate Response message that it delivers to the SEAF. In this authentication response, the SUPI is not sent to the SEAF. It is only sent to the SEAF when the UE has been successfully authenticated. 8. The HXRES is saved by the SEAF, and the AUTH token is sent to the UE along with a request for authentication. 9. The AUTH token is checked by the UE against the secret key it has with the home network. 10. If the validation is successful, the UE will accept the network as legitimate. To proceed with authentication, the UE generates a RES token and sends it to the SEAF. 11. The SEAF validates the RES by computing HRES* from RES* and compares HRES* with HXRES*. The SEAF will consider the authentication as complete if the values are the same. 12. If the authentication is successful the SEAF sends the Nausf_UE_ Authentication_Authenticate Request message containing the SUPI or SUCI and the SNN, to the AUSF. 13. The AUSF verifies the message to enable increased home control. 14. When the AUSF verifies the UE’s RES token as genuine, it generates an anchor key (KSEAF) and passes it on to the SEAF, along with the SUPI if necessary. The AUSF also informs UDM/ARPF of the authentication results so they can log the events. 15. The KSEAF is then deleted, and the SEAF proceeds to produce the AMF key (KAMF), which it then sends on to the adjacent Access and Mobility Management Function (AMF). The Next Generation NodeB (gNB) base station uses the key KgNB to derive the keys used to protect subsequent communication between the UE and the gNB, while the AMF uses the KAMF to derive (a) the confidentiality and integrity keys required to protect signaling messages between the UE and the AMF, and (b) another key, KgNB, which is sent to the gNB.2.44. (c) 5G Equipment Identity Register (5G EIR) To prevent network exploitation and the unauthorized usage of premium services, 5G EIR will be an essential tool for authenticating mobile devices in the network, including IoT devices. Fifth-Generation Enhanced Interoperability for Radio Access (5G EIR) networks is a standalone network component coupled via Service-Based Interfaces (SBIs) that provides security support to telecom operators. With this technology, mobile networks now have a way to limit access to rogue user terminals. With this setup, business owners may keep their devices and agreements distinct.

5G and LTE Network Architectures

125

Thus, the Enea 5G EIR limits just the device, as opposed to the entire service, when a listing is necessary per subscriber demand. [74,75]. 5G EIR is a network function of 5G Core that is primarily used to monitor the status of PEI (Permanent Equipment Identifier) (e.g., PEI blacklist status). It is linked to the AMF by network reference point N17. Its primary functions include: • Device authentication. Handles the AMF’s requests for PEI checks and relays device status update information to the AMF. • Device capacity notification. It notifies the UDM about the 5G PEI device’s capacity (Unified Data Management). • Arbitrary device change processing. Handles requests for configuration modifications that may be made to devices. • SBI processing. Processes N5G EIR SBI. • Authentication and authorization verification. Authentication and control of access to resources by NF. 2.3.2.2.3 5G Core Policy Management Block The elements of the 5G Core Policy Management Block are described as follows: (a) Policy Charging and Control Function (PCF) The role of Policy and Charging Control (5G PCC) is crucial. The utilization of Network resources during real-time service delivery can be monitored and managed with this feature’s help. The PCF (Policy Charging and Control Function) controls the operations of the Control plane and the operations of the User plane by enforcing the rules of the Policy. Specifically, it is used in combination with CHF (Charging Function) to provide a comprehensive view of usage. PCF allows operators to control and regulate the operation of their networks. PCF supports essential features such as QoS management, Traffic Steering/ Routing, Detection of Applications and their Capabilities, Subscriber Spending/ Usage Monitoring, Interworking with IMS Nodes, Enabling Differentiated Services, Gating Control, Network Slice Enablement, Roaming Support, etc. [76, 77]. In the 5GS, the functions of the PCF can be categorized as shown in Table 2.6. The underlying procedures for managing the policies are depicted in Figure 2.44 [33]. When a PCF is notified of an AMF change due to Inter-PLMN mobility, the PCF may be required to revise its regulations governing access to the Service Area. If this information changes, AMF may page the UE to give the new information, and it will also update NG-RAN [33]. There are 3 procedures defined between AMF and PCF for policy management, these are: AM Policy Association Establishment procedure is triggered by the AMF when the UE moves from EPS to 5GS and no longer has an AMF-PCF association, or when the AMF is changed for a UE registering for the first time and the PCF is also changed. Policy association between the AMF and PCF for the UE they are servicing is established through this process.

126

5G NR Modeling in MATLAB®

TABLE 2.6 PCF Functions [76] Non-Session Management-Related Policy Control Requirements Access and mobilityrelated policy control requirements

The AMF’s Access and Mobility Function (AMF) relies on the Policy Control Function (PCF) to provide service-based interfaces for interacting with the AMF’s policy enforcement for access and mobility. • Access and Mobility Management policies can be made available to the AMF by the PCF. • Policy decisions made by operators in response to events sent by the AMF must be evaluated by the PCF.

UE access selection and PDU session selection related policy (UE policy) control requirements

The 5GC must have the ability to relay PCF policy details to the UE. The following are examples of policy information: • Access Network Discovery & Selection Policy (ANDSP). The UE makes use of this to choose an access network that does not conform to the 3GPP standard. • UE Route Selection Policy (URSP). The UE consults this policy when deciding where to send outgoing data. Network status analytics Slice-specific network status analytics should be readily available to the information PCF through the NWDAF. In order to transmit network data analytics requirements (such as load level information) to PCF at the network slice level, NWDAF is not required to be aware of the subscribers using the slice. The PCF board will be allowed to factor such information into its decisions. Management of packet This function refers to the capacity to add, modify, or delete PFDs in the flow descriptions NEF (PFDF) and distribute them from the NEF (PFDF) to the SMF and then the UPF. When the UPF is set up to recognize an ASP’s designated application, this function can be activated. Session Management-Related Policy Control Requirements Charging related Charging control must be independent of policy control and be able to be requirements implemented on a per-service data flow and per-application basis; this is what the PCC architecture is designed to do. Gating control The UPF will apply per-service data flow-based gating controls. The AF requirements must notify the PCF of session events (such as a session’s termination or modification) in order to facilitate the PCF’s gating control decisions. In gating control, session termination can cause packet blocking or “closing the gate” respectively. IP-based service data flows are eligible for Gating Control. QoS control at service As a result of QoS control per service data flow, the PCC framework can data flow level inform the SMF of the authorized QoS to be imposed for each service data flow in accordance with the PCF's previously defined policies. QoS control at QoS flow The QoS utilized in QoS reservation procedures (QoS control) shall be level calculable in accordance with established PCF policies. QoS control at PDU Depending on the PDU session type and/or RAT type, the PCF should be session level able to unconditionally or conditionally give the allowed Session-AMBR values, default 5QI/ARP combination for IP, Ethernet, and unstructured PDU sessions. (Continued )

5G and LTE Network Architectures

127

TABLE 2.6 (CONTINUED) PCF Functions [76] Subscriber spending limits requirements

Usage monitoring control requirements

Application detection and control requirements Traffic steering control

Limits on how much a subscriber can spend will be enforceable. Policy counters will be kept by the CHF to monitor renewal costs. Before they can be used over the N28 interface, certain policy counters need to be made available in the CHF. A PCF must set and convey monitoring thresholds to an SMF before the latter may make dynamic policy decisions based on usage statistics. The monitoring procedure requires the establishment of consumption criteria, either in terms of time or absolute numbers. The PCF could send either restriction to the SMF. The PCF must activate the proper PCC rules in the SMF to advise the SMF on which applications to detect and whether to submit a start or stop event to the PCF. The PCF may be prevented from receiving reports of application detection’s beginning and ending. Subscriber traffic can be “steered” to the appropriate operator or third-party service functions in the (S)Gi-LAN by activating or deactivating traffic steering policies from the PCF in the SMF. This includes features like NAT, antimalware, parental control, and DDoS defense. Upon request from the AF, the DNAI can route user traffic that matches the PCC rule’s traffic filters to a neighboring data network. Only non-roaming and home-routed scenarios are compatible with the traffic steering control.

FIGURE 2.44  Access and mobility policy management procedure [33].

128

5G NR Modeling in MATLAB®

The AMF or PCF can start n AM Policy Association Modification when a local event, such as a UDM update, modifies the AMF’s current policy-related subscription information, when the PCF's local policy information modifies as a result of a local trigger or trigger from the UDR, or when an AMF relocation results in a new AMF re-establishing association with the PCF. By executing this process, any and all policy-related entities will be updated. AM Policy Association Termination is triggered when a performing UE deregistration, AMF change, or 5GS to EPS mobility with N26 connectivity where AMF is no longer available for that UE. When a UE undergoes this procedure, the policy associated with it is removed [33]. The PCF has connections to several components of the 5GC as shown in Figure 2.45 [76]. The N5 Network reference point is the bridge between the AF and the PCF. Information about an application’s session is forwarded between the Application Framework and the Policy Control Function [76, 77]. This data includes the application’s bandwidth requirements for QoS, the identity of its service provider and its applications, the routing information for traffic based on the applications’ access, and the identification of its traffic for billing and policy control. The PCF can be reached from the UDR using the N25 Network reference point. PCF accesses UDR to collect policy/subscription/app-specific information. Subscription and application-related policy control data is provisioned into UDR. UDR can also send out alerts if there is a change to a subscriber's account that affects their price, as determined by the Operator’s pricing structure. The PCF can reach the NWDAF through the N23 Network reference point. The PCF needs to be able to get slice-specific network status analytics directly from the NWDAF. Although NWDAF is not necessary to be aware of the current subscribers utilizing the slice, it does so to offer PCF with network data analytics (load level statistics) on a network slice level. Policymakers at PCF will be free to put that information to use.

FIGURE 2.45  Connections between the PCF and 5GC entities.

5G and LTE Network Architectures

129

The N30 Network reference point connects the NEF to the PCF. Through NEF, network functions and their associated resources are made available to the wider world. It reveals the network functions' potential for bolstering PCF’s Policy and Charging. The N28 Network reference point connects the CHF to the PCF. This interface behaves the same as between PCRF and OCS in the 4G Network. Through this interface, operators may track and regulate subscriber expenses and usage. CHF records policy counter-information against the subscriber’s price plan and notifies PCF anytime a subscriber exceeds the usage-based policy thresholds. PCF then implements the policy decision by interacting with SMF after receiving policy trigger data (which in turn informs UPF for policy enforcement). AMF and PCF are linked through the N15 Network reference point. The AMF functions as a single access point for the UE connection. PCF offers access and mobility policies to the AMF in order to activate policy rules on the UE or user sessions. The SMF is connected to the PCF by the N7 Network reference point. The PCF triggers policy and charging control decisions on the SMF, whereas the SMF triggers the PCF to enforce policy decisions on session management [76, 77]. (b) Charging Function (CHF) It is possible to provide charging services to authorized network functions using the new charging function (CHF) provided in the 5G system architecture. Information gathered during the charging process can equip operators with the resources they need to adapt their charging models to accommodate a wide range of clients. The model continues to offer two primary payment methods, Offline and Online charging, even though the labels Online and Offline have no intrinsic connection to the method by which end-users are invoiced. These are the two channels through which financial information about customers is gathered and transmitted to the billing system, where it can be processed in accordance with the customers’ preferred billing methods and used to resolve financial obligations between service providers and their customers. Offline charging makes it possible to obtain data on charges at the same time that the resources are being used. Information about offline charging is compiled in the many parts designed for that purpose. Each user’s information is gathered separately, and then, depending on the operator’s settings, it may be forwarded to the billing domain. The overall charging event needs to be able to receive and process all relevant data for a single service/session in real-time in order to deliver correct, billable data to end-users, but it is not necessary for the different types of information to be sent in a synchronous way. Therefore, all Charging Data Records (CDR) processing for the purpose of billing the end user is done offline, after the utilization of the network resources has concluded. Offline billing and settlement are two processes that the billing domain is in charge of generating and managing [33]. For online pre-network resource consumption authorization to be done, a subscriber must have a CHF pre-paid account. Two common practices, Direct Debiting and Unit Reservation, are used to make this happen. Direct debiting, as the name implies, immediately deducts the amount of resource usage required for that service/

130

5G NR Modeling in MATLAB®

session from the user’s account, whereas unit reservation involves setting aside a set number of units for use and allowing the user to consume as many of those units as they need during the service/session in question. Over-reserved amounts are recredited to the subscriber’s account and the correct amount is debited from the CHF when resource usage is complete (session terminated, service completed, etc.). The network entity responsible for monitoring the usage must return the actual amount of resource usage (i.e., the used units) to the CHF [33]. The CHF is linked to the PCF through the N28 network reference point and the SMF through the N40 network reference point. The following are included in the 5G charging in Release 15 [78]: • 5G data connectivity charging. Detailed in TS 32.255 [79] and comprising PDU session in SMF, Service data flows (inside PDU session), and QoS flows (within PDU session). Release 15 supports only home-routed charging. This billing information is gathered by the CHF in each PLMN as QoS flow-Based Charging (QBC). • 5GSMS charging. TS 32.274 [80], 32.290 [81], 32.291 [82], and 32.298 [83] introduced SMSF charging and the enhancement of the IP-SMGW charging for 5G converged charging. Release 16 is proposed to define the following for 5G charging: • Charging aspects of network slicing study. The current 5G data connectivity charging includes details regarding the network slice instance that was utilized. The 5G specifications TS 23.501 [84] and TS 23.502 [85] identify network slicing as a significant feature. As described in TS 22.261 [86] and TS 28.541 [86], a network slice is typically considered to be a composition of network functions that offers communication services with specific network characteristics (such as coverage, UE mobility level, sharing level, QoS, etc.). According to the description in TS 28.530 [87], Communication Service Providers (CSPs) may offer Communication Service Customers (CSCs) communication services utilizing network slice instances. These services fall into the following categories: Business-to-Consumer (B2C) services (such as mobile web browsing, 5G voice, rich communication services), Business-to-Business (B2B) services (such as Internet access, LAN interconnection), and Business-to-Household (B2H) services (such as services offered to other CSPs offering themselves communication services to their customers). CSPs can provide NSaaS to CSCs in the form of a communication service, and there is also the “Network Slices as NOP internals” model, in which network slices are not included in the CSP service offering and are therefore not visible to CSCs; instead, they exist solely to support communication services. These various applications of the network slice could necessitate novel charging schemes. Using the 3GPP working groups’ SA2 and SA5 (OAM) specifications as a foundation, the TR 32.845

5G and LTE Network Architectures

131

[88] examines the charging aspects of a network slice, such as the business roles, potential charging requirements, important issues, and solutions. Support from the administration structure will be required. • Charging Access and Mobility Management Function (AMF). Only 5G data connectivity (i.e., PDU session from SMF) and SMS are supported by the service-based charging interface in Release 15. In order to better meet the various types of installations and services, this will now be expanded outside the field of resource utilization gathered under session management (including control of UPFs) and SMS over NAS functions. The reason for this is that in order to charge for or compile statistics about the use of other types of 5GS resources, such as those related to Access connection and Mobility, it is crucial for operators to collect usage data for these resources. This means that the AMF’s approved features, as outlined in TS 32.256 [89], can be charged for with better transparency. These features include registration management, mobility management, and access connection management. • Offline charging services. The CHF offers CDRs for both online and offline charging, making up the convergent charging introduced in Release 15. TS 32.290 [81] and 32.291 [82] detail the relevant Nchf_ConvergedCharging service. It is suggested to define a new service, called the “offline charging service”, to allow for more adaptable deployment of charging via a servicebased interface. • Charging enhancement of 5GC interworking with EPC. It is necessary for UEs to be able to handle handover between EPS/E-UTRAN and 5GS/NR connections in order to support interworking between 5GS and EPC when PCF + PCRF, PGW-C + SMF, and UPF + PGW-U are utilized. As described in TS 23.501 [84] and TS 23.502 [85], interoperable networks with EPC may or may not provide interworking procedures, and those processes may or may not employ the N26 interface. The MME and 5GSAMF use the N26 inter-CN interface to allow the EPC and NGcore to talk to one another. The service-based architecture of the CHF will be explained in Chapter 3. 2.3.2.2.4 5G Core Shared Environment Block The elements of the 5G Core Shared Environment Block are described as follows: (a) Unified Data Repository (UDR) The functionalities below are supported by the Unified Data Repository (UDR): • • • •

Subscription data storage and retrieval by the UDM. Policy data storage and retrieval by the PCF. Structured data storage and retrieval for exposure. Application data. Information such as Packet Flow Descriptions (PFDs) for application detection, AF request details for multiple UEs, and 5GLAN group information for 5GLAN management all fall under this category.

132

5G NR Modeling in MATLAB®

• Storage and retrieval of NF Group ID which corresponds to subscriber identifier (e.g., IMPI, IMPU, SUPI). Data stored in and retrieved from the UDR by NF service users uses the Nudr, which is hosted in the same PLMN as those consumers. Nudr is an intra-PLMN interface. Collocate UDR and UDSF at the deployment's discretion. The UDR is connected to the UDM, PCF and NEF in the 5GC via the following network reference points: • N35. Interface that links the UDM with the UDR. • N36. Interface that links the PCF with the UDR. • N37. Interface that links the NEF with the UDR. Figure 2.46 illustrates how the 5G system architecture permits the UDM, PCF, and NEF to store data in the UDR. This data includes subscription and policy information from the UDM and PCF, as well as structured exposure and application data from the NEF (e.g., Packet Flow Descriptions (PFDs) for application detection and AF request information for multiple UEs). Each PLMN has the option to deploy UDR, which serves the following characteristics: • The NEF is located on the same PLMN as the UDR it accesses. • If a UDM supports a split architecture, the UDR it accesses will be part of the same PLMN as the UDM itself. • The PCF accesses the UDR that is located in the same PLMN as the PCF itself. Each PLMN’s UDR can serve as a data repository for roaming subscribers’ applications. Data (such as subscriptions, subscription policies, exposure information, and application information) and/or NFs (such as firewalls) can be maintained in one or more UDRs, although there can be several UDRs installed in a network. It is feasible

FIGURE 2.46  Data storage architecture of the 5G UDR.

5G and LTE Network Architectures

133

to implement setups where a single UDR contains the data for a single NF and is hence integrated with that NF. In order for network functions (i.e., NF Service Consumers) such as UDM, PCF, and NEF to read, update (i.e., add, modify, delete), and subscribe to the notification of key data changes, the Nudr is utilized. Further information on the SBI of the UDR will be given in Chapter 3. Each NF Service Consumer using Nudr to access the UDR will have access only to the data that it is authorized to modify or delete. The UDR is tasked with performing this authorization at the data set and NF service consumer level (and maybe at the UE, subscription level as well). The following data must be standardized in the UDR settings that are presented and kept by Nudr for each NF service consumer: • • • •

Subscription Data. Policy Data. Structured Data for exposure. Application data. Application detection and AF request information for multiple UEs is provided via Packet Flow Descriptions (PFDs).

The data sets expose 3GPP-defined information elements, and the service-based Nudr interface specifies their content and format/encoding. Moreover, the NF Service Consumers will have access to operator-specific data sets and data for each data set via the UDR. Data and data sets that are unique to a given operator are not susceptible to standardization on the basis of their content or format/encoding. There will be no uniformity in the UDR’s storage of its many data types. (b) Unstructured Data Storage Function (UDSF) Any NF can utilize the UDSF as a supplementary feature to help manage and access data in an unstructured format. For the purposes of this specification, “structured data” is data whose structure is defined by 3GPP specifications. When discussing data, 3GPP does not specify a structure, we say that data is unstructured. All Network Functions in pre-5G cellular networks were stateful, meaning that they cached user/connection/ association data locally. Stateful Network Functions, however, lead to a slew of connection-related issues in the event of a breakdown and necessitate a dedicated backup network to keep things moving, all of which raise maintenance costs and decreases network reliability. As a solution to the problem of where to save all that data while using stateful Network Functions, 3GPP has introduced the UDSF [32, 90]. Each and every Network Function in 5G is stateless. The information generated by stateless components will be kept in a dedicated database known as the Unified Data Storage Facility (UDSF). Owing to 5G Network Functions’ statelessness, networks may be optimized more effectively, and they are more reliable than ever before. The UDSF is providing a critical role for the 5G Core as a producer of network functions. In other words, it acts as a repository for information that Network Function service users can access. Unstructured data can be stored and retrieved using the UDSF by any 5G NF [90].

134

5G NR Modeling in MATLAB®

FIGURE 2.47  Data storage architecture for unstructured data storage using UDSF.

By referring to Figure 2.47, it can be seen that the 5G System design makes it possible for any NF to save and recover its unstructured data into/from a UDSF (such as UE contexts) via the N18 reference point. In this case, the UDSF is part of the same PLMN as the node performing the network function. Each CP NF may have its own UDSF for storing unstructured data or may share a UDSF (for example, if a UDSF is located near the NF) [32, 90]. The “core” network in 4G is dependent on physical hardware, while in 5G it will be hosted on the cloud. NFV stands for “Network Function Virtualization”. As a backend service for Virtual Network Functions (VNFs), UDSF enables the cloud native technology that underpins the 5G cloud-based network. Data traffic places enormous strains on network operators, who must constantly innovate to keep up with user demands for ever-faster service. By implementing UDSF, data flow can be decreased. As in Figure 2.47, the UDSF will be installed in the same network as the Control Plane NF, and all of the PLMN’s NFs may use the same UDSF to store and retrieve their respective data, or each NF may have its own UDSF depending on operator configuration [32]. 2.3.2.2.5 5G Core Application and Network Exposure Block The Application and Network Exposure functions are described as follows: (a) Network Exposure Function (NEF) Secure, robust, and developer-friendly access to exposed network services and capabilities is made possible via the 5G Network Exposure Function (NEF). Both internal (within the trust domain of the network operator) and external applications can access the network domain using a collection of northbound RESTful (or web-style) APIs. NEF is similar to the 4G Service Capabilities Exposure Function (SCEF). Mobile apps and endpoints that can switch between 4G and 5G networks will benefit from a SCEF + NEF node that conceals the underlying network technology. In order to integrate with both 4G core endpoints using the Diameter protocol and 5G Core endpoints using the service-based interfaces that are specified as part of the new 5G Core Service Based Architecture, it is essential that the southbound network interfaces be flexible (SBA) [91]. Northbound Application Programming Interfaces (APIs) allow authorized third-party developers and businesses to build new network services on demand. Interactions between application servers with network analytics, edge computing components, and network slicing may further improve Service Assurance and

5G and LTE Network Architectures

135

network automation. To facilitate policy decisions at the application, business, and infrastructure levels, the NEF can provide a multilayer policy framework. Essentially the functions of the NEF as described in [32] are as follows: - Exposure of capabilities and events: NEF may safely expose NF capabilities and events to third parties, Application Functions, and Edge Computing. With the use of a standardized interface (Nudr), the NEF is able to store and retrieve data from the Unified Data Repository (UDR) in an organized fashion. - Secure provision of information from external application to 3GPP network: Information such as expected UE behavior, 5G LAN group information, and servicespecific information can be securely transmitted from the Application Functions to the 3GPP network. In that instance, the NEF may perform authentication and authorization for the Application Functions and even help with throttling them. - Translation of internal-external information: It interprets data sent to and received from the AF for use inside the internal network. To give only one example, it translates between the DNN and S-NSSAI used by a 5G Core and the AF-Service-Identifier. According to network policy, NEF is in charge of masking private data about the network and its users when communicating with external AFs. - Receiving information from other NFs: Information from the many different network functions is passed to the Network Exposure Function (based on exposed capabilities of other network functions). The data is stored in a uniform format in a UDR, which NEF communicates with via a standard interface. For other purposes, such as analytics, the NEF can “re-exposed” the stored data to other parts of the network and applications. - Support to PFD Function: A NEF may additionally host a PFD Function, which is able to store and retrieve PFDs from the UDR and supply them to the SMF upon request (pull mode) or at the request of the NEF’s PFD management (push mode). - Support to a 5GLAN Group Management Function: The 5GLAN group information may be stored in the UDR by the NEF’s 5GLAN Group Management Function using UDM. - Exposure of analytics: The NEF may provide secure access to NWDAF’s analytic results for third parties. - Retrieval of data from external party by NWDAF: NWDAF may use NEF to gather the third party’s data for analytics generation. The NEF processes and relays messages between the NWDAF and the AF.

136

5G NR Modeling in MATLAB®

- Support of Non-IP Data Delivery: Through the N33/Nnef interface, NEF provides the NIDD APIs outlined in TS 23.502 [3], allowing for the administration of NIDD setup and the supply of MO/MT unstructured data. If a NEF instance possesses at least one of the aforementioned features, it is possible for it to provide a subset of the APIs specified for capability exposure. The NEF is able to access the UDR in the same PLMN as the NEF. It is possible to configure the NEF’s IP address(es) and port(s) locally in the AF, or the AF may discover it along with the Fully Qualified Domain Name (FQDN) by performing a DNS query with the use of either a single UE’s External Identifier or a collection of UEs’ External Group Identifiers. Alternatively, the AF may use the NRF to find the FQDN if it has the operator’s trust. NEF exists in the HPLMN for external exposure of services associated to specified UE(s). Depending on the operator agreements, the HPLMN NEF may have interface(s) with VPLMN NF(s). An SCEF + NEF is utilized for service exposure when a UE possesses the ability to toggle between EPC and 5GC. The NEF is connected via the following network reference points to different entities in the 5GC: • • • • • • •

N29. Interface connecting the NEF with the SMF. N30. Interface connecting the PCF with the NEF. N33. Interface connecting the NEF with the AF. N37. Interface connecting the NEF with the UDR. N51. Interface connecting the AMF with the NEF. N52. Interface connecting the NEF with the UDM. N56. Interface connecting the NEF with the UCMF.

The interconnections are also illustrated in Figure 2.48.

FIGURE 2.48  NEF interconnections in the 5GC.

5G and LTE Network Architectures

137

(b) Application Function (AF) The Application Function (AF) communicates with the 3GPP CN to provide services, such as supporting interactions with the policy framework for policy control, the time synchronization service, and IMS connections with 5GC. Figure 2.49 depicts its relationships with the elements of the 5GC. The main reference points are as follows: • N5. Reference point between the PCF and an AF. • N33. Reference point between NEF and AF. • N57. Reference point between AF and the UCMF. Based on operator deployment, Application Functions deemed trustworthy by the operator are permitted to interface directly with relevant Network Functions. Application Functions that are not permitted by the operator to access Network Functions directly must communicate with appropriate Network Functions through the external exposure framework via the NEF. The AF additionally supports the following: -Application influence on traffic routing An AF can send requests to the SMF to affect the way the latter routes PDU Session data. UPF (re)selection and (I-)SMF (re)selection can be influenced by AF requests, which in turn can direct user traffic to a nearby Data Network (identified by a DNAI).

FIGURE 2.49  AF connections to the 5GC.

138

5G NR Modeling in MATLAB®

Requests on behalf of applications not owned by the PLMN servicing the UE can be sent by the AF. If an AF isn’t given direct network access by the operator, it will have to rely on the NEF to communicate to the 5GC. The AF may be responsible for the (re)selection or transfer of applications inside the local portion of the DN (as defined in TS 23.548). In the event of a change in AF instance, the AF may make relocation information requests [92]. Requests from AFs authorized to communicate directly with the 5GC NFs are sent to the PCF either directly or through the Network Evolution Function (NEF) in the event of requests aimed at specific active PDU Sessions of individual UEs. The NEF is used to send AF requests that may be addressed to one or more PCF and which are intended for the PDU Sessions of one or more UEs, either now active or scheduled to begin. Requests from the AF are translated by the PCF(s) into policies that can be used in PDU Sessions. Notifications of UP path management events are sent to the AF either directly from the SMF(s) or via a NEF to which the AF has subscribed (without involving the PCF). -Accessing Network Exposure Function The address information of the UE may be the only way for an AF to determine the intended recipient of a request to externally expose 5GC capabilities (such as Data Provisioning or Event Exposure for a certain UE). The NEF cannot complete the AF request unless it has first retrieved the UE's Permanent identifier. With the UE’s address (which may be an IP address or MAC address) and the relevant DNN and/ or S-NSSAI information (which may have been provided by the AF or calculated by the NEF based on the asking AF), the NEF can calculate the UE’s permanent identification. If an AF requests a translation from the UE’s address to a unique UE identifier (through Nnef_UEId service) or if an AF requests external exposure regarding an individual UE identified by its address, then NEF may give the AF with an AF-specific UE Identifier [92]. 2.3.2.2.6 5G Core Network Resource Management Block The elements of the 5G Core Application and Network Exposure Block are described as follows: (a) Network Function (NF) NF represents any network function found in the Network Resource Management block. It is connected to the UDSF via the N18 reference point, through which any network function can contact the UDSF. (b) Network Slice Selection Function (NSSF) Network slicing is the practice of creating autonomous, end-to-end segments of a larger network, wherein individual applications, services, and connections are given their own dedicated set of infrastructure and network resources. A network slice is considered as a dynamically created logical end-to-end network. Multiple slices may be accessed by the same UE over the same Access Network (e.g., over the same radio

5G and LTE Network Architectures

139

interface). Each slice may serve a certain service type in accordance with the Service Level Agreement (SLA). As seen in Figure 2.50, a Network Slice is defined within a Public Land Mobile Network (PLMN) and comprises the CN CP and UP Network Functions in addition to the 5G Access Network (AN). The AUSF, UDM, and NSSF continue to be shared by all network slices [93]. Slices 1 and 2 are provided to two distinct UE applications, as seen. Also, within the same device, two distinct apps might be executed (traffic and Engine IoT in this case). The AMF, PCF, and NRF are shared in this instance. Slices of a network allow service providers to create specialized networks that meet the needs of their customers in terms of both functionality (like mobility) and performance (e.g., latency, availability, reliability, … etc.). Network slices can have a variety of S-NSSAIs and Slice/Service Types, depending on the features and network function optimizations that are turned on for that particular slice. The operator may deploy multiple Network Slice instances with the same Slice/Service Type but different Slice Differentiators in order to provide the same set of services to different groups of UEs, for example because each instance provides a different committed service and/or is dedicated to a customer. The requirement for determining the particular network function linked to a slice is met by NSSF [94,95]. In a 5G environment where many services are supplied, the NSSF system selects the appropriate network slice for the user’s requested service. It also gives the optimal

FIGURE 2.50  Network slicing in 5G.

140

5G NR Modeling in MATLAB®

Access and Mobility Management Function (AMF) or AMF set information to support the user’s network-authorized service request. The NSSF system provides the following service processing operations via HTTP2-based Nnssf SBI (Service-based interface demonstrated by NSSF) on 3GPP 5G system architecture in order to provide the slice selection function: • Identifies the approved and configured Network Slice Selection Assistance Information (NSSAIs) and AMF to service the UE, and then chooses the NSI to use for network slicing. As part of the UE’s initial registration and PDU establishment process, the AMF can retrieve the UE’s NRF, NSI ID, and target AMFs. Additionally, it can find out which S-NSSAIs are subscribed to if that is a requirement. • Provides the ability to restrict Network Slices and Network Slice instances using data from the NWDAF. • Supports interaction with NRF and allows retrieving specific NF services to be used for registration request. When requested by the AMF, NSSF must present the following data: • • • • • •

NSSAIs which are allowed. NSSAIs which are configured. NSSAIs which are restricted. Candidate AMF List (in case of registration). Network Slice instance ID (for PDU registration). Slice-level NRF information (for PDU Connectivity).

The NSSF connections with the 5GC are illustrated in Figure 2.51.

FIGURE 2.51  NSSF connections in the 5GC.

5G and LTE Network Architectures

141

Additionally, the NSSF provides the following features: • NSSAI Availability Service. In addition to handling subscriptions and notifications for TAI-specific S-NSSAI support information, this service also manages S-NSSAI support information in general. • NS data management. Manages network slice (S-NSSAI) information, network slice instance information, NF (AMF, NRF) information including network slice instances, and manages AMF NSSAI availability information. • NS selection standard management. Manages network selection information by tracking area, HPLMN NSSAI mapping information by PLMN, manages rejected NSSAI information by PLMN and rejected NSSAI information by tracking area. • NS status management. Acquires the load-level information of the instance of the network slice through interworking with NWDAF. • NRF interworking. Processes the NSSF profile information register and periodic NSSF status updates. • Authentication and authorization monitoring. Sends NRF interconnection access token issuance request, service request access token validation check and access token validation check. • Hierarchical NSSF. Provides intermediate redirection and forwarding. • HTTP2 interconnection. Registers IPs as a white list to, manages the FQDN registration of NFs using multiple IPs, sets up TSL interworking by NF and performs overload control. • Roaming. Manages multiple HPLMN information and connects roaming NSSF through SEPP interconnection.

142

5G NR Modeling in MATLAB®

(c) Network Slice-Specific Authentication and Authorization Function (NSSAAF) Functions like these are supported by the Network Slice-Specific and Standalone Non-Public Network (SNPN) Authentication and Authorization Function (NSSAAF): Adherence to TS 23.502 [55]'s requirements for network-slice-specific authentication and authorization using a AAA Server (AAA-S). When a third party’s AAA-S is involved, the NSSAAF may reach out to it through the AAA Proxy (AAA-P). This Procedure is illustrated in Figure 2.52 and proceeds in the following steps: Step 1 The AMF can begin the Network Slice Specific Authentication and Authorization procedure for S-NSSAIs in response to a change in subscription information or a trigger from the AAA-S. The AMF may conclude, based on UE Context in the AMF, that the UE has already been authenticated following the Registration procedure on the first access if the Registration procedure triggers Network Slice Specific Authentication and Authorization. Depending on the result (success/failure) of Network Slice Specific Authentication and Authorization during the initial access, the AMF may decide, based on Network regulations, to bypass this step during Registration on subsequent access for these S-NSSAIs [32, 55].

FIGURE 2.52  Network slice-specific authentication and authorization procedure.

5G and LTE Network Architectures

143

All S-NSSAIs that need Network Slice-Specific Authentication and Authorization must be part of the authorized NSSAIs. This happens when either the AAA Server triggers UE re-authentication and re-authorization for one or more S-NSSAIs or when the AMF triggers it due to operator policy or a subscription change. Step 2 Within a NAS MM Transport message that also contains the S-NSSAI, the AMF may send an EAP Identity Request for the S-NSSAI. This is the H-S-NSSAI, PLMN’s not the S-NSSAI as it is mapped locally. Step 3 In addition to the S-NSSAI, the UE also includes the EAP Identity Response for the S-NSSAI in a NAS MM Transport message addressed to the AMF. Step 4 In a Nnssaaf_NSSAA_Authenticate Request, the AMF provides the NSSAAF with the EAP Identity Response (EAP Identity Response, GPSI, S-NSSAI). Step 5 If the AAA-P is present, the NSSAAF will forward the EAP ID Response message to the AAA-P (for instance, if the AAA-S belongs to a third party and the operator utilizes proxies for third parties). With no AAA-P available, the NSSAAF relays the information to the AAA-S. The NSSAAF is responsible for routing NSSAA queries to the appropriate AAA-S, taking into account the local AAA-S address configuration as specified by S-NSSAI. In order to communicate with the AAA-P or AAA-S, the NSSAAF uses the AAA protocol. The AAA-S is compatible with this type of message because it uses the same protocol. Step 6 The AAA-P will send the AAA-S, which can be located by its address, the EAP Identity message, which includes the S-NSSAI and GPSI. After receiving the EAP ID response message, the AAA-S will save the GPSI and associate it with the user’s EAP Identity. The AAA-S can then use it to cancel an existing authorization or initiate a new one. Steps 7–14 The UE and the server exchange EAP-messages. It is possible that these procedures will be repeated once, or multiple times. Step 15 The EAP authentication process has finished. Since the AAA-S keeps tabs on the S-NSSAI for which permission has been granted, it can decide to require renewed authentication and authorization if it so chooses. Whether the EAP session was successful or not, a message with the GPSI and S-NSSAI is sent to the AAA-P. (or, if the AAA-P is not available, directly to the NSSAAF).

144

5G NR Modeling in MATLAB®

Step 16 If AAA-P is employed, a message consisting of (EAP-Success/Failure, S-NSSAI, GPSI) is transmitted to the NSSAAF via the AAA-P. Step 17 An Nnssaaf_NSSAA_Authenticate Response (EAP-Success/Failure, S-NSSAI, GPSI) is transmitted from the NSSAAF to the AMF. Step 18 The AMF will then send the UE a NAS MM Transport message indicating the outcome of the EAP handshake. When an S-NSSAI completes the NSSAA process (steps 1–17), the AMF will save the EAP result. Step 19a [Conditional] If a new Allowed NSSAI (including any new S-NSSAIs in a Requested NSSAI for which the NSSAA procedure succeeded and/or excluding any S-NSSAI(s) in the existing Allowed NSSAI for the UE for which the procedure has failed, or including default S-NSSAI(s) if all S-NSSAIs in a Requested NSSAI or in the existing Allowed NSSAI are subject to NSSAA and, due to failure of the NSSAA procedures, they cannot be in the Allowed NSSAI) and/or new Rejected S-NSSAIs (including any S-NSSAI(s) in the existing Allowed NSSAI for the UE for which the procedure has failed, or any new requested S-NSSAI(s) for which the NSSAA procedure failed) need to be delivered to the UE, or if the AMF reallocation is required, the AMF initiates the UE Configuration Update procedure, for each Access Type, as described in clause 4.2.4.2. In the event that the Network Slice-Specific Re-Authentication and Re-Authorization procedure fails and there is a PDU session associated with the S-NSSAI for which the NSSAA procedure failed, the AMF is required to follow the steps outlined in clause 4.3.4 to release the PDU sessions with the appropriate cause value. Step 19b [Conditional] The Network-initiated Deregistration procedure, as outlined in clause 4.2.2.3.3, must be carried out by AMF. Any UE that fails Network Slice-Specific Authentication and Authorization for all S-NSSAIs in the existing Allowed NSSAI and (if applicable) for all S-NSSAIs in the Requested NSSAI, without the ability to add a default S-NSSAI to the Allowed NSSAI, must be explicitly deregistered. The list of S-NSSAIs that were rejected together with their respective rejection cause values can be requested. - Support for access to SNPN using credentials from Credentials Holder using AAA server (AAA-S) as follows: • With SUPI and subscription information, the UDM can determine if the AAA Server in CH should handle primary authentication. From the SUCI sent by AUSF, UDM creates the Home Network Identifier. After that, the UDM notifies the AUSF that a AAA Server located in a CH is needed for

5G and LTE Network Architectures

• • • •

145

primary authentication. After identifying and selecting the NSSAAF, the AUSF will then relay EAP communications to the latter. The NSSAAF is responsible for determining the AAA Server’s domain name using the SUPI’s realm component, forwarding EAP messages from the AUSF to the AAA Server (or AAA proxy), and performing any necessary protocol conversions. The AAA Server acts as the EAP Server for primary authentication [32, 55]. The SA WG3 will determine if only SUCI employing a null scheme with anonymized SUPI should be supported for this application. When first communicating with the AAA Server for authentication and authorization, the UE is identified by its SUPI. Using the Home Network Identifier (realm portion) and Routing Indicator contained in a UE’s configured SUCI, the AMF is able to locate and choose the AUSF. It is required that the AMF and SMF use SUPI to retrieve the UE subscription data from UDM.

Figure 2.53 shows the SNPN Credential Holder’s primary authentication and authorization being handled by a AAA server in a 5G system. The service-based interfaces in Figure 2.53 will be described in Chapter 3 It can also provide access to SNPN using credentials from the Default Credentials Server when the AAA server is used (AAA-S). Network Slice-Specific Authentication and Authorization is enabled in a PLMN when the NSSAAF is deployed, and Network Slice-Specific Authentication and

FIGURE 2.53  5G system architecture with access to SNPN using credentials from credentials holder using AAA server.

146

5G NR Modeling in MATLAB®

Authorization is provided in an SNPN, and/or access to the SNPN is supported when credentials from a Credentials Holder are used [32, 55]. (d) Network Data Analytics Function (NWDAF) NWDAF offers analytic services to 5GC NFs and OAM. An NWDAF might include the following logical functions: • Analytics Logical Function (AnLF). An NWDAF logical function that exposes analytics service (Nnwdaf_AnalyticsSubscription or Nnwdaf_ AnalyticsInfo), does inference, and derives analytics information (statistics and/or predictions depending on Analytics Consumer request). • Model Training Logical Function (MTLF). New Machine Learning (ML) model training and service exposure is accomplished by this NWDAF logic function (e.g. providing a trained ML model). Analytics information is either statistical information about past events or predictive information. Different NWDAF instances may exist in the 5GC, with possible analytics-typespecific customizations. The NWDAF profile saved in the NRF describes the capabilities of an NWDAF instance. The NWDAF is connected to the 5GC via two network reference points namely N23 and N34 as shown in Figure 2.54 [96]. The NWDAF is responsible for providing the load level and identity of a network slice instance. Subscribers and unsubscribers of periodic and threshold-exceeding notifications can be handled using the NWDAF. It delivers the following services to NF customers [96]: The Policy Control Function (PCF): • Facilitates subscription and unsubscription to NWDAF notifications of analytics data pertaining to slice load levels. • Helps users subscribe and unsubscribe to NWDAF’s analytics-based alerts on data pertaining to their service experiences on the network level. • Lets users subscribe to or unsubscribe from NWDAF alerts detailing network performance analytics. • Allows for subscription and unsubscription to NWDAF alerts on anomalous UE behavior in terms of analytics data.

FIGURE 2.54  NWDAF reference point connections in the 5GC.

5G and LTE Network Architectures

147

• Allows for subscription and unsubscription to NWDAF’s notifications of QoS sustainability analytics data. • Supports taking into account one or more of the NWDAF inputs listed above when making decisions about how to allocate network resources and/ or how to direct traffic. The Network Slice Selection Function (NSSF): • Helps with subscribing and unsubscribing to notifications of analytics data on slice load levels from NWDAF. The Access and Mobility Management Function (AMF): • Allows for subscription and unsubscription to NWDAF’s analytics on SMF load data for use in making SMF selections. • Allows subscribing and unsubscribing to NWDAF’s notifications of analytics data regarding expected UE behavior (UE mobility and/or UE communication) in order to track UE activity. • Allows users to subscribe or unsubscribe to updates regarding the NWDAF’s analytics on abnormal UE behavior, which can be used to fine-tune the network’s handling of UE mobility in order to mitigate any potential threats. The Session Management Function (SMF): • Facilitates subscription and unsubscription to NWDAF’s statistics on UPF loads for use in selecting the appropriate UPF. • Allows users to subscribe or unsubscribe to receiving notifications from NWDAF on analytics data pertaining to expected UE behavior (UE mobility and/or UE communication). • Allows subscribing and unsubscribing to NWDAF’s notification of analytics data on abnormal UE behavior in order to determine the need to alter network parameters connected to UE communication in order to mitigate abnormal risk. The Network Exposure Function (NEF): • Allows for the transmission of untrusted UE mobility information from NWDAF to the AF. • Allows for the transmission of untrusted UE communication information from NWDAF to the AF. • Allows for the transmission of trusted UE behavioral information (UE mobility and/or UE communication) from NWDAF to the AF. NWDAF to the AF when it is untrusted; • Allows for the transmission of abnormal behavior information from NWDAF to the AF.

148

5G NR Modeling in MATLAB®

• Allows for the transmission of user data congestion information from NWDAF to the AF. • Allows for the transmission of network performance information from NWDAF to the AF. • Allow for the transmission of QoS Sustainability information from NWDAF to the AF. The Unified Data Management (UDM): • Enables the NWDAF to be used to inform the monitoring of UE behavior by considering expected UE behavior (UE mobility and/or UE communication). The Application Function (AF): • Allows for the reception of UE mobility information from NWDAF or via the NEF. • Allows for the reception of UE communication information from NWDAF or via the NEF. • Allows for the reception of expected UE behavioral information (UE mobility and/or UE communication) from NWDAF or via the NEF. • Allows for the reception of abnormal behavior information from NWDAF or via the NEF. • Allows for the reception of user data congestion information from NWDAF or via the NEF. • Allows for the reception of network performance information from NWDAF or via the NEF. • Allows for the reception of QoS Sustainability information from NWDAF or via the NEF. The Operation, Administration, and Maintenance (OAM): • Allows for the reception of observed service experience from NWDAF. • Allows for the reception of NF load information from NWDAF. • Allows for the reception of network performance information from NWDAF. • Allows for the reception of UE mobility information from NWDAF. • Allows for the reception of UE communication information from NWDAF. • Allows for the reception of expected UE behavior information (UE mobility and/or UE communication) from NWDAF. • Allows for the reception of abnormal UE behavior information from NWDAF. The Network Data Analytics Function (NWDAF) can provide load-level information, and the Network Slice Selection Function (NSSF) can use this information to identify the most appropriate slices.

5G and LTE Network Architectures

149

The interactions between 5GC NF(s) and the NWDAF take place within a PLMN. The NWDAF has no notion about NF application logic. Only for statistical purposes will NWDAF use subscriber data. Many NWDAF instances can be organized in a hierarchical structure with any number of layers and branches thanks to the architecture of NWDAF. Deployment options still exist for how many layers of the hierarchy to use and how to arrange them, as well as for the capabilities of each NWDAF instance. When neither Data Collection and Coordination Function (DCCF) nor Messaging Framework Adaptor Function (MFAF) is available in a network, NWDAFs may offer data collection exposure capability for generating analytics based on the data gathered by other NWDAFs in a hierarchical deployment. When it comes to compelling business-driven use cases, analytics use cases may be grouped into three categories, with the primary category being the reduction of operational and capital expenses (OPEX and CAPEX) and greater efficiency. New technologies necessitate the efficient operation of networks, which is impossible without the use of AI. The second category is enhanced customer experience, in which CSPs seek to differentiate themselves by providing network services with a superior customer experience. The third element is new revenue, which occurs when CSPs offer new capabilities to businesses or consumers, resulting in new business. Table 2.7 provides examples of the first wave of use cases (supported by the standards) that CSPs should begin evaluating across categories [97]. (e) Network Repository Function (NRF) 3GPP 5G architecture is associated with the NF (Network Function) Repository Function. It is useful for the discovery of services. It is able to take in NF Discovery Requests from NF instances and report back on the NF instances that have been found. The NRF serves as a central repository for Network Functions (NFs) on the network. In practice, this means when a new Network Function/Network Element is connected to the 5GC, the NRF will expose it to other NFs on the network, register the new NF and let every other NF become aware of this new NF as and when required. For example, if a new AMF is added to the network, it only needs the NRF details, so that it can discover all other NFs it needs. The new AMF will register itself to the NRF, advertise what Network Functions it can offer (i.e., AMF services), and it will in turn be able to learn about what Network Functions it can consume—for example, the UDMs it can query data from [98]. The NRF supports the functionalities given in Table 2.8 [32, 99]. 2.3.2.2.7 5G Core Location Services Block (a) Location Management Function (LMF) When a UE connects to or registers with 5GCN, the LMF is responsible for coordinating and allocating the necessary resources to determine the UE’s accurate location. An estimated accuracy for the final location and any estimated velocity are also calculated or verified. The serving AMF communicates with the LMF via the

150

5G NR Modeling in MATLAB®

TABLE 2.7 NWDAF Use Cases Use Case

Description

Category

Anomaly detection

Many different use cases including network optimization, user experience, or stability can be addressed by anomaly detections. Anomaly detection enabled by AI has the ability to uncover hidden patterns by integrating data from many sources and handling various business situations. AI-enabled anomaly detection can greatly benefit functions related to Quality of Experience (QoE) or Internet of Things (IoT) devices.

Relentless efficiency (OPEX)

Encrypted video QoE

For encrypted traffic that would be difficult to decipher without advanced traffic analysis, proactive assurance is provided. The quality of the services experienced by subscribers is reflected in the carefully chosen Key Performance Indicators (KPIs). Aiming to automate complicated LCM processes using ML algorithms is the goal. Continuous network modifications, upgrades, and capability additions are automated based on customer insights and RAN data, and operations are derisked. One use of mobility predictions is paging optimization. One of the most common forms of network signaling is paging. A significant step toward more efficient use of computing resources is lowering the amount of paging attempts. According to past experiences, paging signaling can be reduced by as much as 60% using mobility predictions. The path that a device will travel over a network can be learned using NWDAF mobility predictions. Most of the time, it is knowing which cell to enter next. In a number of cases, this could lead to better network optimization or an improved client experience. Decreases in load (as in paging optimizations) and Quality of Experience (QoE) are two examples (such as slice management).

Customer experience

Overall network performance and quality of service monitoring at the slice or even user level is necessary to guarantee SLAs are kept. To avoid an SLS breach and keep network performance efficient overall, automated enforcement is required when a breach is about to occur. A bird's-eye perspective of network best enforcement can be obtained by meticulously monitoring Key Performance Indicators (KPIs) at the slice or user level. The guarantee is provided by end-to-end analytics, which encompass RAN, transport, core, and infrastructure.

New revenue stream

Intelligent RAN Automation (ORAN) Paging optimization

Predicted mobility

Slice Service Level Agreement (SLA) assurance

Relentless efficiency (OPEX/CAPEX)

Relentless efficiency and customer experience

Relentless efficiency and customer experience

151

5G and LTE Network Architectures

TABLE 2.8 NRF Functionalities Functionality

Description

Service discovery

Provides information about discovered NF instances to the requesting NF instance or SCP after receiving an NF Discovery Request from the requesting NF instance or SCP. Supports SCP discovery by SCP instances.

NF profiles

Manages NF profile and service information per NF instance. Maintains SCP profile of available SCP instances. Notifies the subscribing NF service consumer or SCP of new, updated, or deregistered NF and SCP instances and of any associated NF services. Provides access taken with valid authentication/authorization for the requested service. Manages NF status according to receipt of HeartBeat messages Manages access token issuance information and provides HTTPS-based JWK. Provides intermediate redirection and forwarding.

Notifications OAuth2 authorization service NF status management Access token management Hierarchical NRF configuration HTTP2 interconnection

Roaming

Network slicing

• Manages IP white list registration. • Manages FQDN registration of NFs using multiple IPs. • NF interconnection TLS setting. • Overload control. Manages multiple HPLMN information and connects roaming NRF through SEPP connection. It is possible to use many NRFs in various networks. The Visiting PLMN’s NRF (vNRF) is set up with data specific to the Visiting PLMN. The hNRF (Home PLMN NRF) stores configuration data for the home PLMN that is used by the vNRF over the N27 interface. Based on network implementation, multiple NRFs can be deployed at different levels: • PLMN level (NRF settings provide data for the entire PLMN). • Shared-slice level (information pertaining to a group of Network Slices is entered into the NRF’s configuration). • Slice-specific level (the NRF has settings specific to an S-NSSAI).

Nlmf interface to request the UE’s location. The LMF communicates with the UE and either the NG-RAN, the N3IWF, or the TNAN to receive location information [100], and it communicates with the UE to exchange location information for use in UE-assisted and UE-based position procedures. The positioning’s geographic and/or local coordinates, as per [101], shall be determined by the LMF. The UE’s velocity may also be included in the positioning result upon request and if it is accessible. When LMF receives a location request, it evaluates the LCS Client type and the supported GAD shapes to determine the coordinate

152

5G NR Modeling in MATLAB®

type(s). When a regulated LCS Client type is included in a location request, the Location Matching Function (LMF) is obligated to provide both a geographic location and, if desired, a local coordinate location. In cases when the UE's location request indicates a premium LCS client, the LMF may use either local or global coordinates to pinpoint the UE’s precise location. LMF shall determine a geographical location if the supported GAD shapes are not received or if Local Co-ordinates are not included in the supported GAD shapes. The LMF serves as the core of the 5G positioning architecture. With the help of the access and mobility management function (AMF) and the NLs interface, as shown in Figure 2.55, the LMF may detect the UE’s location by collecting measurements and assistance information from the NG-RAN and the mobile device. In order to transmit positioning data between the NG-RAN and LMF over the NG-new RAN’s control plane interface with the CN, the NR Positioning Protocol A (NRPPa) protocol was developed (NG-C). These modifications to the 5G architecture underpin the technology’s positioning capabilities. LTE positioning protocol is used by the LMF through the AMF to configure the UE (LPP). The Radio Resource Control (RRC) protocol is utilized by the NG RAN in order to setup the UE for both LTE-Uu and NR-Uu. The addition of new reference signals to the NR specifications allows for more precise positioning measurements than were previously possible with LTE. The downlink positioning reference signal (NR PRS) and the uplink Sounding Reference Signal (SRS) are the two signals used for pinpointing precise locations. Positioning techniques that rely on the downlink are supported primarily by the downlink Positioning Reference Signal (PRS). While other signals may be used, PRS is optimized to minimize or eliminate interference while providing the highest possible levels of precision and coverage. Due to the necessity of signal reception from potentially far-flung neighboring base stations for position estimation, great care was taken in designing an efficient PRS by providing a wide delay spread range for the signal.

FIGURE 2.55  Positioning architecture in 5G.

5G and LTE Network Architectures

153

We accomplish this by spreading PRS transmission across multiple symbols that can be aggregated to create a larger total symbol power level, thereby covering the entire NR bandwidth. Specifically, the comb size is the number of subcarriers that are used up by a given PRS symbol. Multiple comb-2, comb-4, comb-6, and comb-12 scenario- and case-specific PRS patterns are available with varying degrees of configurational flexibility. Comb-6, in which three base stations are multiplexed throughout a single time slot, produces the layout depicted in the figure. Each of the subcarriers in the frequency domain can be protected by combining N symbols, which is what comb-N PRS does. Subcarrier sets can be independently transmitted by each base station to prevent signal overlap. This solution is latency efficient because multiple base stations can simultaneously transmit without interfering with one another. Additionally, the PRS signal from one or more base stations can be muted at any given time according to a muting pattern, further decreasing the potential interference. The PRS can be configured to be repeated to enhance hearability in use cases with higher transmission loss (such as in macro-cell deployments). An example PRS with three base stations is shown in Figure 2.56(a). In 3GPP Release 16, the SRS was implemented as a positioning tool for use in the uplink direction. The new signal solves two problems associated with positioning. The new signal needs to have enough range to reach not only the serving base station to which the UE is connected but also the neighboring base stations involved in the positioning process. In order to ensure that all subcarriers are accommodated, the SRS is designed to encompass the full bandwidth, with the necessary resource elements being dispersed among the various symbols. So, just like the PRS, the SRS is designed on a comb-like structure. By designating distinct comb patterns, multiple UEs can share a single transmitting symbol. The UE can be set up with multiple SRS instances, each with its own power control loop to reduce interference. This improves the hearability of SRS directed at neighbor cells and reduces interference in the serving cell. An example of SRS by a UE is shown in Figure 2.56(b).

FIGURE 2.56  DL-PRS and UL-SRS reference signals for positioning.

154

5G NR Modeling in MATLAB®

A variety of measurements may be necessary for various positioning techniques. Measurements of power, angle, and time for the PRS have all been standardized by the 3GPP. Figure 2.57 depicts a PRS beam sweep across a resource set. Each beam can be considered as a resource. Depending on the situation, measurements may be taken from a single resource or from a set of resources. In the downlink, a large number of antennas at the receiver enables fine Angle of Arrival (AOA) measurements with NR, and in the uplink, beamforming improves the Signal-toNoise Ratio (SNR) due to beamforming gain while also providing UE location information in terms of the Angle of Departure (AOD) based on the beam ID accessed by the UE. In order to facilitate a wide range of positioning techniques, many of these measurements have been standardized. Beginning with 4G LTE, mobile networks allowed for the use of positioning techniques like Observed Time Difference of Arrival (OTDOA), Uplink Time Difference of Arrival (UL-TDOA), and power measurements for positioning. Positioning based on both Round Trip Time (RTT) and angles is now supported thanks to 5G. High accuracy positioning is made possible for various 5G use cases thanks to the incorporation of new positioning methods and enhancements to existing positioning methods. (b) Gateway Mobile Location Center (GMLC) The Gateway Mobile Location Center (GMLC) consists of LCS-supporting features. There may be multiple GMLCs in a single PLMN. The 5G architecture recycles the GMLC concept and adds a new CN that manages location within the 5G-specific component and retrieves [100]: • Information about the cell’s general position and, if desired, its precise geographical coordinates, as supplied by the CN Access and Mobility Management Function (AMF).

FIGURE 2.57  Beamforming, multiantenna aspects in 5G positioning.

5G and LTE Network Architectures

155

• Coordinates for a certain location, as reported by a powerful location server (LMF). As shown above, several Network Functions and service APIs in the 5GC collaborate to provide Location Services (LCS) to a UE or to other entities regarding one or more UEs. There are two modes for each of the three types of requests used to initiate location reporting [102,103]: • Network Induced Location Requests (NI-LR) are initiated by an AMF on behalf of a regulatory agency to determine the location of a UE (e.g. to determine location during an IMS emergency call). • Mobile Terminated Location Requests (MT-LR) are initiated by internal or external LCS clients and may be associated with a service or application accessed by the UE, regulatory agency requests, or PLMN operator requests. • Mobile Originated Location Requests (MO-LR) are triggered by the UE in order to locate itself or to share its location with an external client. If the LCS client initiating the request needs a quick response, they can issue an Immediate Location Request and specify the necessary QoS. Using a Deferred Location Request, an LCS client can subscribe for either event-based or periodic location reporting from an MT-LR. The 5G Location Network Architecture is shown in Figure 2.58 [104]. When connecting to a PLMN, an external LCS client will initially connect to a GMLC (i.e., the UE reference point is supported by the GMLC). In either case, AFs and NFs have access to GMLC through NEF. Using the Nudm interface, the GMLC can inquire about routing details and/or target UE privacy. When a GMLC receives a location request, it authenticates the requesting LCS Client or AF, verifies the privacy settings of the targeted UE, and then forwards the request to a serving AMF via

FIGURE 2.58  5G Location network architecture.

156

5G NR Modeling in MATLAB®

the Namf interface, or to a GMLC in another PLMN via the Ngmlc interface, if the requesting UE is roaming [100]. Prior to sending a location estimate, the home PLMN of the targeted UE must always verify the UE’s privacy profile settings. A “Visited GMLC” (VGMLC) is a GMLC that is linked to the target UE’s serving node. For each UE, there is a dedicated GMLC responsible for doing privacy checks; this GMLC is known as the “Home GMLC” (HGMLC). The following are the features of what a GMLC could do to help with location services [100]: • If more than one AMF is capable of servicing a certain UE, that UE can have its serving AMF identified by an HGMLC. • Target UEs at an HGMLC are responsible for deciding whether or not to attempt a second location request from a different AMF when the location information given by the first AMF does not fulfill QoS criteria and more than one serving AMF is available. • Support periodic, triggered, and UE available location events at an HGMLC with a 5GC-MT-LR and a deferred 5GC-MT-LR from an external LCS client or NEF. • Location queries from roaming UEs are forwarded from HGMLCs to VGMLCs or serving AMFs in the VPLMN, depending on how the networks are set up. • Event reports for a delayed 5GC-MT-LR at a periodic or triggered location are returned from a VGMLC or LMF to an external LCS Client or NEF at an HGMLC. • Allow for the suspension of a recurring or triggered event at an HGMLC. • If a UE requests it, an HGMLC will pull location data from a VGMLC for a 5GC-MO-LR and send it on to an LCS Client or an AF (through NEF). • A VGMLC is responsible for relaying HGMLC location requests for roaming UEs to active Mobile Foundations. • It is the responsibility of the VGMLC to accept and forward to the HGMLC any event reports from LMFs about delayed 5GC-MT-LRs for periodic or triggered locations for roaming UEs. • When an AMF transmits a 5GC-MO-position LR’s data to a VGMLC, the data is relayed to an HGMLC. • A LCS request from a client should be denied by an HGMLC if the client’s Maximum Target UE Number is greater than the number of Target UEs in the LCS request. • Each LCS client on the outside must submit their location request to an HGMLC, where a unique reference number will be assigned. • If the service request includes a pseudonym indicator, the HGMLC will assign a pseudonym and send it along to the LCS client when necessary (for example, when the CN forwards the UE’s location data to the LCS client). If the verinym and pseudonym are both sent by the LCS client, resolve them.

5G and LTE Network Architectures

157

• At an HGMLC, during the bulk operation method, UE identifiers are resolved to group identifiers and replies are summed for transmission to the LCS Client or NEF. (c) Cell Broadcast Centre Function (CBCF) The capability of mobile networks to quickly send important messages to many or all users in the network in more or less real time is a crucial one, and in many countries, it is even a legal requirement. Natural disasters like earthquakes, tsunamis, and severe storms, as well as ongoing criminal actions like child abductions and terrorist attacks, are common use cases for a Public Warning System (PWS). As another example of its utility, it can be used to broadcast traffic reports [33]. Using a concept called Cell Broadcasting, the radio network can be triggered to send a single short message to multiple devices in the network all at once, allowing the 5G architecture to support public warning systems. Messages can be sent to the entire network or to more limited regions, even as small as a single radio cell. This is managed centrally by the network at the sender’s request. 5G’s cell broadcast capabilities are not revolutionary; they are similar to those of previous generations of wireless technology (2G, 3G, and 4G). The Network Functions and protocols used in 5G networks are new, so some of the implementation details are different. When both the new 5G Radio and the 5G Core are used, as shown in Figure 2.59 [33], the PWS architecture changes accordingly. Messages are generated and transmitted from what 3GPP refers to as a “Cell Broadcast Entity” (CBE), but neither its nature nor its connection to the mobile network’s “Cell Broadcast Center” (CBC) is defined. A country’s CBE may be housed within a government agency concerned with public security or crime prevention [33]. The CBC determines the message’s coverage area, duration, and retransmission frequency. The CBC requests the N50 or SBc interface to the relevant AMFs. 3GPP has specified two implementation variants for this interconnection, which is why there

FIGURE 2.59  Architecture for broadcasting of public warning messages.

158

5G NR Modeling in MATLAB®

are two options. Basically, service-based interfaces are used, such as Namf in AMF, if the CBC provides one. In a logical point-to-point architecture, such service-based interface interaction is represented by the number N50 in Figure 2.59. As shown in Fig. 2.59, CBC is then formally referred to as CBCF. Cell Broadcasting over 4G/LTE uses SBc if the CBC only has a conventional diameter interface. Detailing the various possible approaches to implementation is outside the scope of this book. Regardless, the CBC still communicates with the relevant AMFs and transmits the message to them along with instructions for which regions to broadcast it. Once the AMF has received the request to transmit the message, it will send out requests to all radio base stations within the specified region via the N2 interface. While traditional forms of messaging, such as SMS, involve the CN and the devices exchanging information, Cell Broadcasting involves only the AMF sending a message to the devices over the radio network. The AMF relays information to the CBC about the transmission’s success or failure via radio network reports [33]. The 3GPP defines the CBCF as a CN function for 5G [105]. Several AMFs could be linked to the CBCF. Multiple CBEs may be linked to the CBCF. The CBCF is tasked with overseeing all CBS communications, which includes but is not limited to: • Serial numbers allocation. • Modification or deletion of CBS messages stored in the NG-RAN node. • Starting broadcast by sending fixed-length CBS messages to an NG-RAN node for each language provided by the cell and, if necessary, padding the pages to a length of 82 octets (see 3GPP TS 23.038 [3]). • Deciding when a CBS message should first be broadcast and to what group of cells, as well as specifying this range of cells inside the Serial Number for each CBS message. • Deciding when a CBS message should be aired. • Deciding when a CBS message’s transmission should end and then instructing every node in the NG-RAN to stop sending the message. • Deciding how often the CBS message should be transmitted. • In order to distinguish emergency messages transmitted by CBS from regular CBS messages, such as those with an “emergency indication”, a “Cell ID/Service Area ID list”, and a “warning type” or “warning message”" is assigned. Only UEs specifically built for testing purposes are allowed to display a warning message when the “warning type” is set to “test”. A service-oriented protocol is supported by the CBCF. The CBCF makes use of AMF communication services to relay warning messages to the NG-RAN and to sign up for alerts regarding the delivery of such messages [105]. 2.3.2.2.8 5G Core Signaling Block The main components of the Core Signaling Block are described as follows:

5G and LTE Network Architectures

159

(a) Service Communication Proxy (SCP) Control and data are separated in SCP, making it a decentralized system. It is used in conjunction with 5G Network Functions (NF) to make the CN more resilient, flexible, and observable. A single instance of an SCP might be able to support a subset or even the full set of SCP features. Below is a list of the features: [32, 34] • Indirect Communication. Direct interactions between NF Service consumers and NF Service producers are possible, as are indirect interactions mediated by an SCP. Figure 2.60 depicts examples of both direct and indirect communication. The local configuration of the NF Service Consumer/Producer determines whether Direct Communication is used (for example, in the case of requests or subscriptions) or Indirect Communication (via an SCP) is used. Based on the local configuration, an NF might not be able to rely solely on SCP for its communications. Direct Communication involves the NF Service consumer discovering the NF Service producer they wish to interact with, either locally through configuration or remotely through NRF. The NF Service user coordinates with the desired NF Service provider through direct interaction. With Indirect Communication, the SCP mediates communications between the NF Service user and the NF Service provider (the target). The NF Service consumer can be set up to execute discovery of the intended NF Service producer on their own, or they can delegate this task to the SCP being used for indirect communication. In the second case, the SCP finds and chooses the appropriate NF Service producer based on the parameters offered by the NF Service consumer. Consumers of NF Services can set their own SCP addresses locally [32, 34]. • Delegated Discovery. CN entities (NFs or Service Communication Proxy (SCP)) can use NF discovery and NF service discovery to learn about available NF instances and NF service instances for a targeted NF service or NF type. Access to NF services is made possible by the NF discovery process. If the requester NF is set up for delegation, it can forego the NRF discovery process in favor of having the Service Control Point (SCP) handle it on its behalf. In this case, the requester NF equips the SCP with the necessary

FIGURE 2.60  NF/NF service intercommunication.

160

5G NR Modeling in MATLAB®

criteria for finding and selection by including them in the request. The SCP may communicate with the NRF to conduct and collect discovery results, and with the NRF or UDR to collect the NF Group ID corresponding to the subscriber identifier. If the SCP is using a UDR, it can first ask it for the HSS/UDM Group ID for the specified user identity, and then rely on the NRF to discover the group of HSS/UDM instance(s) providing the supplied user identity. • Forwarding and routing of messages to their NF/NF service destination. • Forwarding and routing of messages to a next hop SCP. • Communication security (such as authorization of the NF Service Consumer to access the NF Service Producer API), load balancing, monitoring, overload control, etc. • Interact with UDR, if necessary, to resolve the UDM Group ID, UDR Group ID, AUSF Group ID, PCF Group ID, CHF Group ID, and HSS Group ID according to the UE’s identity (using SUPI or IMPI/IMPU, for example). The SCP can be set up in a decentralized fashion. It is possible for multiple SCPs to coexist along the path that NF Services use to communicate with one another. PLMN-level, shared-slice, and slice-specific SCP deployments are all possible. Operator deployment is responsible for enabling communication between SCPs and the appropriate NRFs. To allow SCPs to route messages through multiple SCPs (i.e., next SCP hop discovery; see clause 6.3.16), an SCP may register its profile in the NRF. As an alternative, local configuration can be used [32, 34]. [b] Security Edge Protection Proxy (SEPP) The SEPP is the entity at the edge of the 5G network whose job it is to protect data packets as they travel over the N32 interface (between two 5G networks). The SEPP [106, 107, 71]: • Provides security for all service layer messages sent from the network function and forwards them over the N32 interface. • Verifies the security of all incoming communications on the N32 interface before forwarding them. Information passed between two network functions in two different Public Land Mobile Networks (PLMNs) is protected by the SEPP’s application layer security. Figure 2.61 illustrates the role of the SEPP in the security architecture of 5G.

FIGURE 2.61  SEPP in the security architecture of 5G. Source: 3GPP.

5G and LTE Network Architectures

161

The SEPP safeguards the Request Uniform Resource Identifier (URI), the sensitive information in the HTTP message header, and the payload of the Hypertext Transfer Protocol (HTTP) message. On the other hand, not all payload data is secured in the same way. End-to-end encryption may be necessary for some data, while end-to-end integrity protection may be sufficient for other data, provided that intermediary Internetwork Packet Exchange (IPX) providers are allowed to make changes to the message [106, 107, 71]. The SEPP ensures the confidentiality of sensitive data transmitted between two networks. This prohibits third-party networks (such as IPX) from gaining access to private information (such as authentication vectors). While the IPX needs to make changes to data parameters (for example, when mediating for interoperability), both networks need to agree on the scope of such modifications and ensure that the data’s integrity is preserved. Any changes made by an IPX are checked by the receiving network. In the event an IPX gets a message that has been tampered with without permission, the SEPP will be able to detect this. Traditional gateway features, such as topology concealing, malformed packet protection, signaling storm protection, and message source validation [106, 107, 71], are also provided by the SEPP. (c) Binding Support Function (BSF) The Session Correlation for HTTP/2 is guaranteed by the Binding Support Function (BSF), which also enables policy/charging (PCF/CHF) scaling in the 5G network. The BSF can synchronize the session state between HTTP/2 and Diameter in converged networks. The BSF’s primary purpose is to keep tabs on sessions regardless of where they happen to be in the network, so long as they meet certain criteria such as having the same subscriber identifier [108]. It is fair to compare the 5G Binding Support Function (BSF) to the 4G Session Binding Function on the Diameter Routing Agent (DRA). When there are multiple Policy Control Function (PCF) systems in use throughout the infrastructure, this becomes a prerequisite. BSF allows operators to scale their networks by correlating sessions across multiple policy servers. Specifications for the BSF such as the ones below can be found in 3GPP TS 23.502 [85], TS 23.503 [76], and TS 29.513 [109]: • Discovering the necessary binding information (e.g., the address information of the selected PCF). • Giving systems (like PCF) the ability to register, update, and delete binding details. • Facilitating the identification of binding information by systems (like AF and NEF) (e.g., the address information of the selected PCF). Figure 2.62 illustrates the interactions of the BSF with both the 4G and 5G network entities. More details on the service-based interface of the BSF will be given in Chapter 3. 2.3.2.3 IMS Core/Access The unified packet core is an evolution in system architecture supported by both wired and wireless network operators (UPC). The IP Multimedia Subsystem (IMS)

162

5G NR Modeling in MATLAB®

FIGURE 2.62  Interactions of the BSF with 5G and 4G network entities.

is part of the UPC, and it is driven by CableLabs, ETSI, and 3GPP standards bodies. The IMS is capable of delivering a wide variety of multiscreen offerings, which is crucial to the success of emerging 4G/LTE Advanced and other next-generation infrastructures [110, 111, 112]. Carriers can build a full suite of immersive telephony services on top of IMS, including voice and video over LTE (VoLTE/V2oLTE) and the GSMA-defined rich communication suite RCS/RCS-e (Joyn). To realize both voice and data services over the 5G network, a new technology called Voice over New Radio (VoNR) has been developed [113]. VoNR is based on the IMS, which allows for phone calls to be made over the Internet. Early on in the rollout of 5G SA, EPS Fallback is implemented as a workaround for the limited 5G NR coverage, paving the way for the eventual deployment of 5G voice. Eventually, as 5G NR coverage expands, users will be able to make and receive calls over 5G’s high-speed data Internet service, while also taking advantage of VoNR’s enhanced audio and video call quality. In the event that VoNR is not available, Figure 2.63 depicts a typical architecture that allows for a fallback to VoLTE [113]. Vo5G (also known as VoNR) can replace or supplement VoLTE once a 4G/LTE interworking function is in place, or once 5G is deployed on its own. An IMS is still required, but the advantages of a 5G-ready IMS Core are considerable. A 5G IMS must now be built cloud natively with microservices methodologies, requiring the use of containerized OS virtualization rather than virtual machines for all the

5G and LTE Network Architectures

163

FIGURE 2.63  VoNR and VoLTE co-operation with IMS.

advantages that it brings. Network slicing is a critical technical and commercial objective of 5G, and this can be achieved using a cloud-native IMS core. The essential concept of service isolation is expanded into the voice control plane by instantiating highly granular and optimized IMS slices for specific applications and steering traffic via the 5G Network Slice Selection Function (NSSF) [114]. Yet, in order to incorporate the 5G Service-Based Architecture’s (SBA) key components, deployment of Vo5G/VoNR requires revisions to the IMS interfaces, which have not been updated in decades. A Technical Report TR 23.794 on the 3GPP entitled “Study on enhanced IP Multimedia Subsystem (IMS) to 5GC integration” is mostly focused on this topic. TR 23.794 provides in-depth guidance for upgrading and switching to Service-Based Interfaces from Diameter (SBIs). In this way, a 5G IMS core can operate with both traditional Producers (in the language of Service Oriented Architecture) and the more recent, 5G-specific network ­functions that have been introduced within the SBA. It is possible that our interworking strategy will need the use of hybrid configurations in which a conventional Home Subscriber Server (HSS) is discovered by sending an SBI Nnrf NFDiscovery Request message to the NRF, which then queries the live HSS database through a proxy. The IMS design [113] that allows for 5G operation is depicted in Figure 2.64.

164

5G NR Modeling in MATLAB®

FIGURE 2.64  IMS architecture for EPC and 5GC.

This IMS architecture consists of the following entities [113]: Application Servers • IP-SM-GW. Includes SMPP-based network interoperability for sending and receiving SMS messages on VoLTE and other devices. • MMTel/TAS. Serves as a conference center for VoLTE devices and offers a variety of value-added features, including as call forwarding and call blocking. • MRF. Offers network announcements and conferencing capabilities. Designed as a combined MRF-Controller (MRFC) and MRF-Processor (MRFP) in accordance with RFC4240 (Basic Media Services in SIP). • SR-VCC. Provides a media anchor for voice calls and permits seamless handover from 4G/5G to 2G/3G at the beginning or middle of a call. • LI. Provides X1 to X3 interfaces toward the mediation function. • I-CSCF. S-CSCF is chosen according to user capabilities and load, and the system provides full support for Cx/Dx interfaces. Functions • I-CSCF. Supports the full Cx/Dx interface and chooses the appropriate S-CSCF for the current user and workload. • S-CSCF. Offers adaptable application execution via a standards-based ISC interface and enables charging integration via Ro/Rf interfaces as an additional, voluntary feature.

5G and LTE Network Architectures

165

• P-CSCF. Offers full AMR/AMR-WB transcoding capabilities via a dedicated RTP worker. • BGCF. Provides topology concealing and other interworking features (several inbound and outbound routing options). Interfaces • Rx. Connects the PCRF with the P-CSCF. • ENUM. Connects the S-CSCF with the ENUM-DNS server. • Sh. Connects the AS with the HSS. • ISC. Connects the AS with the CSCFs. • Gm. Connects the SBC/P-CSCF with the UE (via EPC/PGW). • Cx/Dx. Connects the CSCF with the HSS. • Mg/Mj. Connects the CSCF with the MGCF for PSTN-IMS interconnect. • SNMP. Towards Network Management System. • Ro. Connects the CSCFs with the IN/OCS. • Rf. Connects the CSCFs with the CCF. A more detailed view of the IMS interaction with the 5GC elements is shown in Figure 2.65 [114] and Figure 2.66 [115]. Cloud-native IMS CN functions that expose Cx or Dx interfaces to the HSS or a Subscription Locator Function are included here, as are the P/I/S-CSCFs that execute the actual consuming (SLF). The end goal is to ease users into using the UDM Service provided by the SBA. Supporting NFs such application servers (Sh) and Policy Control Functions (Rx) that rely on a diameter-based reference interface will need to make the switch to service-based interfaces (SBIs) as NFs adopt cloud-native characteristics. To date, TS 29.228 and TS 29.229 have served as definitions. As part of the 3GPP investigation, new Nhss IMS prefixed IMS services are being explored with the intention of eventually replacing all existing interfaces.

FIGURE 2.65  Support for Vo5G/VoNR with enhanced IMS within the service based architecture.

166

5G NR Modeling in MATLAB®

FIGURE 2.66  5G Core interaction with IMS.

The Session Border Controller (SBC) plays a pivotal role in the IMS architecture. By bridging incompatible signaling messages and media flows (sessions) from end devices or application servers, SBCs protect Voice Over IP (VoIP) networks from intrusion. The use of SBCs is commonplace in the delivery of commercial residential, business, fixed line, and mobile VoIP services and is not limited to the domain of Enterprise infrastructures or carrier networks. Both at the “edge” of the network, where users and service providers meet and at “carrier interconnects” where providers meet each other, they are frequently used. SBCs act as back-to-back user agents, securing a core SIP network and application servers and facilitating client/server interworking (B2BUA). To exert finegrained control over a communications session, a SBC must effectively terminate and re-establish each session, serving as both the User Agent Server (UAS) and the User Agent Client (UAC) for all signaling messages on each call leg. Besides implementing extensive ingress Access Control Lists (ACLs) and rate restriction to protect against DDOS assaults, SBCs also parse each message to remove faulty packet vulnerabilities. Each SIP header and payload, including the Session Description Protocol, can be processed independently, allowing for the application of complex rules to modify message contents and enable interworking (SDP). Before the widespread adoption of industry-wide protocols (STUN, TURN, and ICE), SIP traffic had to be routed through SBCs in order to pass through devices executing IPv4 Network Address Translation (NAT). SBCs process signaling messages and all media traffic, usually in the form of RTP, as part of their normal operation. Because of this, a Session Border Controller can transcode media when a client and server cannot agree on a common codec. Also, lawful intercept is carried out at the SBC [110, 111, 112].

167

5G and LTE Network Architectures

FIGURE 2.67  3GPP IMS reference architecture: functional elements of an SBC [112].

TABLE 2.9 Functional Elements of an SBC IMS Component

Functions Signaling Plane

P-CSCF

• • • • • • • •

Authentication, authorization, and registration for UEs. Security for SIP. Encryption for SIP. Transmission and routing for SIP messages. Management and normalization of SIP messages. NAT and firewall traversal. Interworking of IPv6 and IPv4 (IMS-ALG). Lawful intercept (signaling).

I-BCF

• • • • • •

IMS-AGW

• • • • •

Security for SIP. Message transmission, routing, and load balancing for SIP. Management and normalization of SIP messages. NAT and firewall traversal. Interworking of IPv6 and IPv4. Lawful intercept (signaling). Media Plane Firewalling, filtering, bandwidth control, and steering for media flow. Security for media flow. Encryption for media flow. Interworking for media flow (SRTP-RTP, MSRP-MSRPS, IPv6-IPv4). Lawful intercept (media).

TrGW

• • • •

Firewalling, filtering, bandwidth control, and steering for media flow. Security for media flow. Transcoding. Lawful intercept (media).

168

5G NR Modeling in MATLAB®

Decoupling the signaling and media components allows them to function as independent network nodes in modern SBC implementations. Since each function can scale out separately, it can be placed in the access/edge for media and the core for signaling, respectively, within the network. IP Multimedia System (IMS) reference architecture is a multilayer, hierarchical, highly decomposed model consisting of multiple, distinct, functional components with standardized interfaces; an SBC with discrete signaling and media functions is consistent with this. In the 3GPP IMS Technical Specification TS 23.228 [112], the roles and responsibilities of border controllers are separated according to whether they are handling signaling or media and whether they are located in the access or interconnect domains. IMS-related specifications define an advanced method of session border control using a decentralized signaling and media architecture, with the primary responsibility of facilitating scalable, centralized service delivery. Meanwhile, implementation models have expanded SBC functionality to include other integral parts of IMS, such as the Proxy Call Session Control Function (P-CSCF). An IMS SBC must adhere to the standards for the Interconnect Border Control Function (IBCF) and the Transition Gateway (TrGW) when it is operating in an access network environment. Figure 2.67 depicts the SBC interconnections in the IMS [110, 111, 112]. The functions of the different components shown in Figure 2.67 are given in Table 2.9 [110, 111, 112].

REFERENCES



1. Stefania Sesia, Issam Toufik and Matthew Baker, LTE – The UMTS Long Term Evolution: From Theory to Practice. John Wiley & Sons, Ltd, © 2009. ISBN: 978-0-470-69716-0. 2. J. Duplicy, B. Badic, R. Balraj, et al., “MU-MIMO in LTE Systems”, J Wireless Com Network 2011, 496763 (2011). https://doi​.org​/10​.1155​/2011​/496763 3. D. Martín-Sacristán, J. F. Monserrat, J. Cabrejas-Peñuelas, et al. “On the Way towards Fourth-Generation Mobile: 3GPP LTE and LTE-Advanced”, J Wireless Com Network 2009, 354089 (2009). https://doi​.org​/10​.1155​/2009​/354089 4. 3GGP Release 8, “Technical Specifications and Technical Reports for a UTRAN-based 3GPP System”, 3GPP TR 21.101, Available Online: https://portal​.3gpp​.org​/desktopmodules​/Specifications​/Spe​cifi​cati​onDetails​.aspx​?specificationId​=544 5. Jeanette Wannstrom, “LTE Advanced”, 3GPP, June 2013, Available Online: https:// www​.3gpp​.org​/technologies​/ keywords​-acronyms​/97​-lte​-advanced 6. Samsung, “5G Standalone Architecture”, Technical Whitepaper, January 2021, Available Online: https://images​.samsung​.com ​/is​/content ​/samsung​/p5​/global ​/ business ​ / networks ​ / insights ​ / white ​ - papers ​ / 0107​_ 5g​ - standalone ​ - architecture ​ /5G ​ _ SA ​ _ Architecture​_Technical​_White​_ Paper​_ Public​.pdf 7. Erik Dahlman, Stefan Parkvall and Johan Skold, 4G, LTE-Advanced Pro and The Road to 5G. Third Edition. Academic Press, 2016. ISBN: 978-0-12-804575-6. 8. Martin Sauter, From GSM to LTE‐Advanced Pro and 5G An Introduction to Mobile Networks and Mobile Broadband. John Wiley & Sons Ltd, © 2017. ISBN 9781119346937 (epub) | ISBN 9781119346869 (cloth). 9. Christopher Cox, An Introduction to LTE, LTE, LTE-ADVANCED, SAE, AND 4G Mobile Communications. John Wiley & Sons Ltd, © 2012. ISBN 978-1-119-97038-5 (cloth).

5G and LTE Network Architectures

169

10. Harri Holma and Antti Toskala, LTE for UMTS: Evolution to LTE-Advanced. 2nd Edition. John Wiley & Sons Ltd, © 2011. ISBN: 978-0-470-66000-3. 11. Magdalena Nohrborg, “LTE Overview”, Available Online: https://www​.3gpp​.org​/technologies​/ keywords​-acronyms​/98​-lte 12. Yang Bo, “Equipment in the LTE Network”, China Academy of Information and Communications Technology and ITU, Available Online: https://www​.itu​.int ​/en ​/ ITU​ -D​/ Regional​-Presence ​/AsiaPacific​/SiteAssets​/ Pages​/ Events​/2016​/Oct​- CandI2016​/ CAICT2016​/Session​%206​- 4​%20Equipment​_ in​_ LTE ​_ network ​_ noNote​%20​%E6​%9D​ %A8​%E6​%B3​%A2​-final​.pdf 13. 3GPP TS 27.001 (September 2011), “General on Terminal Adaptation Functions (TAF) for Mobile Stations (MS), Release 10, Section 4”. 14. 3GPP TS 31.102 (October 2011), “Characteristics of the Universal Subscriber Identity Module (USIM) Application, Release 10”. 15. 3GPP TS 36.306 (October 2011), “Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) Radio Access Capabilities, Release 10”. 16. TechPlayon, “3GPP Release-15 UE Cat Types, Throughput, Modulation and DL/ UL Combinations”, Available Online: https://www​.techplayon​.com​/3gpp​-release​-15​ -ue ​- category​- types​- throughput​-performance ​-modulation​-and​- supported​-ue ​- dl​-ul​ -combinations/ 17. 3GPP, “LTE ue-Category”, Available Online: https://www​.3gpp​.org​/ keywords​-acronyms​/1612​-ue​-category 18. electronicnotes, “4G LTE Relay: LTE Advanced Relaying”, Available Online: https:// www​.electronics​-notes​.com​/articles​/connectivity​/4g​-lte​-long​-term​-evolution​/ lte​-relaying​.php 19. 3GPP TS 36.300 (October 2011), “Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall Description; Stage 2, Release 10, Section 4.6”. 20. Cisco, “HeNB Gateway in Wireless LTE Network”, HeNB-GW Administration Guide, StarOS Release 21.4, Available Online: https://www​.cisco​.com ​/c​/en ​/us​/td ​/docs​/wireless​/asr​_ 5000​/21​- 4​_ N5​-7​/ HeNBGW​/21​- 4​-HeNBGW​-Admin​/21​-2​-HeNBGW​-Admin​ _chapter​_01​.html 21. CableFree, “Explaining the Interfaces in LTE”, Available Online: https://www​.cablefree​.net​/wirelesstechnology​/4glte​/ lte​-interfaces/ 22. Magnus Olsson, Shabnam Sultana, Stefan Rommer, Lars Frid and Catherine Mulligan, EPC and 4G Packet Networks – Driving the Mobile Broadband Revolution. 2nd Edition. Elsevier, 2013. ISBN: 978-0-12-394595-2. https://doi​.org​/10​.1016​/C2011​-0​-04551-9 23. M.J. Sharma and V.C. Leung, “IP Multimedia Subsystem Authentication Protocol in LTE-Heterogeneous Networks”, Hum. Cent. Comput. Inf. Sci. 2, 16 (2012). https://doi​ .org​/10​.1186​/2192​-1962​-2​-16 24. 3GPP TS 36.401 (September 2011), “Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Architecture Description, Release 10, Section 5”. 25. Harri Holma and Antti Toskala (Eds), LTE for UMTS: OFDMA and SC-FDMA Based Radio Access. John Wiley & Sons, Ltd, 2009. ISBN: 978-0-470-99401-6 26. IETF, Robust header compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and Uncompressed, RFC 3095. 27. ETSI TS 136 413 V10.0.1 (2011-01), “LTE; Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP) (3GPP TS 36.413 Version 10.0.1 Release 10)”, Available Online: https://www​.etsi​.org​/deliver​/etsi​_ts​/136400​ _136499​/136413​/10​.00​.01​_60​/ts​_136413v100001p​.pdf 28. Paresh Khatri, “The Impact of 5G on IP Transport Networks”, APNIC, Available Online: https://blog​.apnic​.net ​/2019​/11​/13​/the​-impact​-of​-5g​-on​-ip​-transport​-networks/

170

5G NR Modeling in MATLAB®

29. Sami Tabbane, “5G Networks and 3GPP Release 15”, ITU PITA Workshop on Mobile Network Planning and Security, 23–25 October 2019 – Nadi, Fiji Islands, Available Online: https://www​.itu​.int​/en​/ ITU​-D​/ Regional​-Presence​/AsiaPacific​/SiteAssets​/ Pages ​ / Events ​ / 2019​ / ITUPITA2018 ​ / ITU​ -ASP​ - CoE ​ -Training​ - on- ​ /5G ​ %20networks​ %20and​%203GPP​%20Release​%2015​_vf​.pdf 30. RF Wireless World, “CPRI vs eCPRI | Difference between CPRI and eCPRI Used in 5G”, Available Online: https://www​.rfwireless​-world​.com​/Terminology​/CPRI​-vs​-eCPRI​.html 31. Anna-Kaarina Pietilä and Phil Marshall, “Tap into the Next Big Thing with Cloud RAN”, Nokia, Available Online: https://www​.nokia​.com ​/ blog​/tap​-into​-the​-next​-big​ -thing​-with​-cloud​-ran/ 32. ETSI TS 123 501, “System Architecture for the 5G System (3GPP TS 23.501 Version 15.3.0 Release 15)”, Available Online: https://www​.etsi​.org​/deliver​/etsi​_ts​/123500​ _123599​/123501​/15​.03​.00​_60​/ts​_123501v150300p​.pdf 33. Stefan Rommer, Peter Hedman, Magnus Olsson, Lars Frid, Shabnam Sultana and Catherine Mulligan, 5G Core Networks: Powering Digitalization. Elsevier Science, 2019. ISBN:0081030096, 9780081030097. 34. Devaki Chandramouli (Rapporteur, Nokia, Germany), “System Architecture for the 5G System” Tech-Invite, Available Online: https://www​.tech​-invite​.com​/3m23​/tinv​ -3gpp​-23​-501​.html 35. Marin Ivezic, “Introduction to 5G Core Service-Based Architecture (SBA) Components”, Available Online: https://5g.security/5g-technology/5g-core-sba-components-architecture/ 36. SIA, “5G Wireless Infrastructure Semiconductor Analysis”, Available Online: https:// www​.semiconductors​.org​/wp​-content​/uploads​/2020​/07​/SIA​-5G​-Report​_2​.pdf 37. CableFree, “Remote Radio Head for CPRI and 4G, 5G & LTE Networks”, Available Online: https://www​.cablefree​.net​/wirelesstechnology​/4glte​/remote​-radio​-head/ 38. ETSI TS 138 401, “5G;NG-RAN;Architecture Description (3GPP TS 38.401 Version 15.2.0 Release 15)”, Available Online: https://www​.etsi​.org​/deliver​/etsi​_ts​/138400​ _138499​/138401​/15​.02​.00​_60​/ts​_138401v150200p​.pdf 39. TechPlayon, “5G NR gNB Higher Layer Split (HLS)”, Available Online: https://www​ .techplayon​.com​/5g​-nr​-gnb​-higher​-layer​-split​-hls/ 40. TechPlayon, “Open Midhaul F1 Interface F1-C and F1-U”, Available Online: https:// www​.techplayon​.com ​/open​-midhaul​-f1​-interface​-f1​-u​-and​-f1​-c/ 41. ETSI TS 138 470 V16.2.0 (2020-07), “F1  General Aspects and Principles (3GPP TS 38.470 Version 16.2.0 Release 16)”, Available Online: https://www​.etsi​.org​/deliver​/etsi​ _ts​/138400​_138499​/138470​/16​.02​.00​_60​/ts​_138470v160200p​.pdf 42. ETSI TS 138 473 V15.3.0 (2018-10), “F1  Application Protocol (F1AP)”, Available Online: https://www​.etsi​.org​/deliver​/etsi​_TS​/138400​_138499​/138473​/15​.03​.00​_60​/ts​ _138473v150300p​.pdf 43. ETSI TS 138 425 V15.2.0 (2018-07), “NR User Plane Protocol (3GPP TS 38.425 Version 15.2.0 Release 15)”, Available Online: https://www​.etsi​.org​/deliver​/etsi​_ts​ /138400​_138499​/138425​/15​.02​.00​_60​/ts​_138425v150200p​.pdf 44. ETSI TS 138 401 V15.2.0 (2018-07), “5G; NG-RAN; Architecture Description (3GPP TS 38.401 Version 15.2.0 Release 15)”, Available Online: https://www​.etsi​.org​/deliver​/ etsi​_ts​/138400​_138499​/138401​/15​.02​.00​_60​/ts​_138401v150200p​.pdf 45. ETSI TS 138 420 V15.0.0 (2018-07), “Xn General Aspects and Principles (3GPP TS 38.420 Version 15.0.0 Release 15)”, Available Online: https://www​.etsi​.org​/deliver​/etsi​ _ts​/138400​_138499​/138420​/15​.00​.00​_60​/ts​_138420v150000p​.pdf 46. ETSI TS 138 460 V15.0.0 (2018-07), “E1  General Aspects and Principles (3GPP TS 38.460 Version 15.0.0 Release 15)”, Available Online: https://www​.etsi​.org​/deliver​/etsi​ _ts​/138400​_138499​/138460​/15​.00​.00​_60​/ts​_138460v150000p​.pdf

5G and LTE Network Architectures

171

47. emblasoft, “Testing 3GPP N1 and N2 Interface Functionality from the 5G NG-RAN / gNodeB”, Available Online: https://emblasoft​.com​/ blog​/testing​-3gpp​-n1​-and​-n2​-interface​-functionality​-from​-the​-5g​-ng​-ran​-gnodeb/ 48. ETSI TS 138 413 V16.2.0 (2020-07), “NG Application Protocol (NGAP) (3GPP TS 38.413 Version 16.2.0 Release 16)”, Available Online: https://www​.etsi​.org​/deliver​/etsi​ _ts​/138400​_138499​/138413​/16​.02​.00​_60​/ts​_138413v160200p​.pdf 49. Sassan Ahmadi, 5G NR Architecture, Technology, Implementation, and Operation of 3GPP New Radio Standards. Elsevier Inc, Copyright © 2019. All rights reserved. https://doi​.org​/10​.1016​/C2016 ​- 0 ​- 04944-6 50. wipro, “Untrusted Non-3GPP Access Network Internetworking with 5G Core Using the Non-3GPP Interworking Function (N3IWF)”, Available Online: https://www​.wipro​ .com ​/network​-edge​-providers​/untrusted​-non​-3gpp​-access​-network​-interworking​-with​ -5g​-core/ 51. Developing Solutions, “5G Location Services”, Available Online: https://www​.developingsolutions​.com​/products​/dstest​-5g​-core​-network​-testing​/5g​-location​-services/ 52. Lalit Kumar Garg, “You Need a Robust Signaling Solution in 5G Too!”, Erisson Blogs, Available Online: https://www​.ericsson​.com​/en​/ blog​/2019​/10​/you​-need​-a​-robust​-signaling​-solution​-in​-5g​-too 53. metaswitch, “What is the 5G Access and Mobility Management Function (AMF)?”, Available Online: https://www​.metaswitch​.com​/ knowledge​-center​/reference​/what​-is​ -the​-5g​-access​-and​-mobility​-management​-function​-amf 54. ETSI TS 123 501 V16.6.0 (2020-10), “System Architecture for the 5G System (5GS) (3GPP TS 23.501 Version 16.6.0 Release 16)”, Available Online: https://www​.etsi​.org​/ deliver​/etsi​_ts​/123500​_123599​/123501​/16​.06​.00​_60​/ts​_123501v160600p​.pdf 55. ETSI TS 123 502 V15.2.0 (2018-06), “Procedures for the 5G System (3GPP TS 23.502 Version 15.2.0 Release 15)”, Available Online: https://www​.etsi​.org​/deliver​/etsi​_ts​ /123500​_123599​/123502​/15​.02​.00​_60​/ts​_123502v150200p​.pdf 56. TechPlayon, “5G System Connection Management: CM-Idle and CM-Connected”, Available Online: https://www​.techplayon​.com​/5g​-system​-connection​-management​ -cm​-idle​-and​-cm​-connected/ 57. apis, “What Does the Word ‘Reachability’ Really Mean in 5G?”, Available Online: https://apistraining​.com​/reachability​-in​-5g/ 58. TECHTRAINED, “Network Function | Access & Mobility Management Function (AMF) in 5G Core Network | 5G System (5GS)”, Available Online: http://www​.techtrained​.com ​/network​-function​-access​-mobility​-management​-function​-amf​-in​-5g​-core​ -network​-5g​-system​-5gs/ 59. TECHTRAINED, “Network Function | Access & Mobility Management Function (AMF) in 5G Core Network | 5G System (5GS)”, Available Online: http://www​.techtrained​.com ​/network​-function​-access​-mobility​-management​-function​-amf​-in​-5g​-core​ -network​-5g​-system​-5gs/ 60. 5GAA, “Cross-Working Group Work Item Network Reselection Improvements (NRI)”, 5GAA Automotive Association, Technical Report, Available Online: https://5gaa​.org​/ wp​-content​/uploads​/2021​/06​/5GAA​_TR​-XW7​-200012 ​_compressed​.pdf 61. TECHTRAINED, “Network Function | Session Management Function (SMF) in 5G Core Network | 5G System (5GS)”, Available Online: http://www​.techtrained​.com​/network​-function​-session​-management​-function​-smf​-in​-5g​-core​-network​-5g​-system​-5gs/ 62. Developing Solutions, “N4  Interface”, Available Online: https://www​.developingsolutions​.com​/products​/dstest​-5g​-core​-network​-testing​/n4​-interface/ 63. ETSI TS 129 244, “Interface between the Control Plane and the User Plane Nodes (3GPP TS 29.244 Version 16.5.0 Release 16)”, Available Online: https://www​.etsi​.org​/ deliver​/etsi​_ts​/129200​_129299​/129244​/16​.05​.00​_60​/ts​_129244v160500p​.pdf

172

5G NR Modeling in MATLAB®

64. metaswitch, “What is the 5G Session Management Function (SMF)?”, Available Online: https://www​.metaswitch​.com ​/ knowledge​-center​/reference​/what​-is​-the​-5g​-session​-management​-function​-smf 65. MPIRICAL, “N16  Reference Point”, Available Online: https://www​.mpirical​.com​/ glossary​/n16​-n16​-reference​-point 66. ETSI TS 123 040 V16.0.0 (2020-07), “Digital Cellular Telecommunications System (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); LTE; 5G; Technical Realization of the Short Message Service (SMS) (3GPP TS 23.040 Version 16.0.0 Release 16)”, Available Online: https://www​.etsi​.org​/deliver​/etsi​_ts​/123000​ _123099​/123040​/16​.00​.00​_60​/ts​_123040v160000p​.pdf 67. ETSI TS 124 011 V7.1.0 (2009-06), “Digital Cellular Telecommunications System (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; Point-toPoint (PP) Short Message Service (SMS) Support on Mobile Radio Interface (3GPP TS 24.011 Version 7.1.0 Release 7)”, Available Online: https://www​.etsi​.org​/deliver​/etsi​_ts​ /124000​_124099​/124011​/07​.01​.00​_60​/ts​_124011v070100p​.pdf 68. metaswitch, “What is the 5G User Plane Function (UPF)?”, Available Online: https:// www​.metaswitch​.com​/knowledge​-center​/reference​/what​-is​-the​-5g​-user​-plane​-function​ -upf 69. Cisco, “Chapter: 5G-UPF Overview”, Ultra Cloud Core 5G User Plane Function, Release 2020.02 - Configuration and Administration Guide, Available Online: https:// www​.cisco​.com ​/c​/en ​/us​/td ​/docs​/wireless​/ucc​/upf​/ Ultra​- Cloud​- Core​-5G​-UPF​- Config​ -Guide​/ b​_UPF​_chapter​_011011​.html 70. 5G Zone, “Unified Data Management”, Available Online: https://the5gzone​.com​/index​ .php​/unified​-data​-management/ 71. ETSI TS 133 501 V15.4.0 (2019-05), “Security Architecture and Procedures for 5G System (3GPP TS 33.501 Version 15.4.0 Release 15)”, Available Online: https://www​ .etsi​.org​/deliver​/etsi​_ts​/133500​_133599​/133501​/15​.04​.00​_60​/ts​_133501v150400p​.pdf 72. CableLabs, “A Comparative Introduction to 4G and 5G Authentication”, Available Online: https://www​.cablelabs​.com​/insights​/a​-comparative​-introduction​-to​- 4g​-and​-5g​ -authentication 73. Techplayon, “5G Authentication and Key Management 5G-AKA”, Available Online: https://www​.techplayon​.com ​/5g​-authentication​-and​-key​-management​-aka​-procedure/ 74. Enea, “Authentication of Mobile Devices to Prevent Misuse of Network and Abuse of Paid Services”, Available Online: https://www​.enea​.com​/products​-services​/5g​-data​ -management ​/enea​-Equipment​-Identity​-Register 75. TELCOWARE, “5G-EIR”, Available Online: http://www​.telcoware​.com​/eng​_191127​ /01​_product ​/0903​_ 5geir​.asp 76. ETSI TS 123 503 V15.2.0 (2018-07), “Policy and Charging Control Framework for the 5G System; Stage 2 (3GPP TS 23.503 Version 15.2.0 Release 15)”, Available Online: https://www​.etsi​.org​/deliver​/etsi​_ts​/123500​_123599​/123503​/15​.02​.00​_60​/ts​ _123503v150200p​.pdf 77. Rajarshi Pathak, “Policy and Charging Control in a 5G Network”, Available Online: https://www​.rajarshipathak​.com ​/2020​/01​/policy​-and​-charging​-control​-in​-5g​-network​ .html 78. Robert Törnkvist and Chen Shan, “Charging and Billing Architecture for 5G Network”, Journal of ICT 7(2), 2019, 185–194. River Publishers. https://doi​.org​/10​.13052​/jicts2245​ -800X​.728 79. 3GPP TS 32.255, “Telecommunication Management; Charging Management; 5G Data Connectivity Domain Charging; Stage 2”. 80. 3GPP TS 32.274, “Telecommunication Management; Charging Management; Short Message Service (SMS) Charging”.

5G and LTE Network Architectures

173

81. 3GPP TS 32.290, “Telecommunication Management; Charging Management; 5G System; Services, Operations and Procedures of Charging using Service Based Interface (SBI)”. 82. 3GPP TS 32.291, “Telecommunication Management; Charging Management; 5G System; Charging Service, Stage 3”. 83. 3GPP TS 32.298, “Telecommunication Management; Charging Management; Charging Data Record (CDR) Parameter Description”. 84. 3GPP TS 23.501, “System Architecture for the 5G System (5GS)”. 85. 3GPP TS 23.502, “Procedures for the 5G System (5GS)”. 86. 3GPPTS 28.541, “Management and Orchestration; 5G Network Resource Model (NRM); Stage 2 and Stage 3”. 87. 3GPPTS 22.261, “Service Requirements for Next Generation New Services and Markets”. 88. 3GPP TS 32.845, “Charging Management; Study on Charging Aspects of Network Slicing”. 89. 3GPP TS 32.256, “Charging Management; 5G Connection and Mobility Domain Charging; Stage 2”. 90. K.S. Keerthi and R. Bhagya, “Unstructured Data Storage Function for 5G Core Network” (July 9, 2021). Proceedings of the International Conference on IoT Based Control Networks & Intelligent Systems - ICICNIS 2021, Available at SSRN: https:// ssrn​.com​/abstract​=3883465 or http://dx​.doi​.org​/10​.2139​/ssrn​.3883465 91. Andrew D’Souza, “Network Exposure: Opening Up 5G Networks to Partners”, Available Online: https://www​.openet​.com​/ blog​/5g​-networks/ 92. TS 23.548, Available Online: https://portal​.3gpp​.org​/desktopmodules​/Specifications​/ Spe​cifi​cati​onDetails​.aspx​?specificationId​=3856 93. Laurent Desaunay, “5G Cloud Native Packet Core and Network Slicing Automation”, Available Online: https://www​.ciscolive​.com ​/c​/dam ​/r​/ciscolive​/emea ​/docs​/2020​/pdf​/ BRKSPM​-2743​.pdf 94. Oracle® Communications, “Network Slice Selection Function (NSSF) Cloud Native User's Guide”, Available Online: https://docs​.oracle​.com​/cd​/F17999​_01​/docs​.10​/NSSF​.pdf 95. TELCOWARE, “NSSF”, Available Online: http://www​.telcoware​.com​/eng​_191127​/01​ _product ​/0910​_nssf​.asp 96. ETSI TS 129 520 V16.5.1 (2020-11), “5G System; Network Data Analytics Services; Stage 3 (3GPP TS 29.520 Version 16.5.1 Release 16)”, Available Online: https://www​ .etsi​.org​/deliver​/etsi​_ts​/129500​_129599​/129520​/16​.05​.01​_60​/ts​_129520v160501p​.pdf 97. Jitendra Manocha, Stephen Terrill, Ulf Mattsson, Zlatko Filipovic, Erik Westerberg and Dirk Kopplin, “Accelerating the Adoption of AI in Programmable 5G Networks”, Erisson, White paper, Available Online: https://www​.ericsson​.com​/en​/reports​-and​ -papers​/white​-papers​/accelerating​-the​-adoption​-of​-ai​-in​-programmable​-5g​-networks 98. MPIRICAL, “NF Repository Function”, Available Online: https://www​.mpirical​.com​/ glossary​/nrf​-nf​-repository​-function 99. TELCOWARE, “NRF”, Available Online: http://www​.telcoware​.com​/eng​_191127​/01​ _product ​/0909​_nrf​.asp 100. ETSI TS 123 273 V16.4.0 (2020-07), “5G System (5GS) Location Services (LCS); Stage 2 (3GPP TS 23.273 Version 16.4.0 Release 16)”, Available Online: https:// www​.etsi​.org​/deliver​/etsi​_ ts​/123200​_123299​/123273​/16​.04​.00​_ 60​/ts​_123273v1604 00p​.pdf 101. ETSI TS 123 032 V15.1.0 (2018-09), “Digital Cellular Telecommunications System (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); Universal Geographical Area Description (GAD) (3GPP TS 23.032 Version 15.1.0 Release 15)”, Available Online: https://www​.etsi​.org​/deliver​/etsi​_TS​/123000​_123099​/123032​/15​.01​ .00​_60​/ts​_123032v150100p​.pdf

174

5G NR Modeling in MATLAB®

102. Satyam Dwivedi, Johannes Nygren, Florent Munier and Fredrik Gunnarsson, “5G Positioning: What You Need to Know”, ERICSSON, Available Online: https://www​ .ericsson​.com ​/en ​/ blog​/2020​/12​/5g​-positioning-​-what​-you​-need​-to​-know 103. Developing Solutions, “5G Location Services”, Available Online: https://www​.developingsolutions​.com ​/products​/dstest​-5g​-core​-network​-testing​/5g​-location​-services/ 104. GSMA, “MIoT Location in Roaming”, Version 1.0, 20 May 2020, Available Online: https://www​.gsma​.com ​/newsroom ​/wp​-content​/uploads/​/ NG​.120​-v1​.0​.pdf 105. ETSI TS 123 041 V15.2.0 (2018-06), “Digital Cellular Telecommunications System (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); Technical Realization of Cell Broadcast Service (CBS) (3GPP TS 23.041 Version 15.2.0 Release 15)”, Available Online: https://www​.etsi​.org​/deliver​/etsi​_ts​/123000​_123099​/123041​/15​ .02​.00​_60​/ts​_123041v150200p​.pdf 106. The Communications Security, “Reliability and Interoperability Council VII: Report on Recommendations for Identifying Optional Security Features that Can Diminish the Effectiveness of 5G Security”, March 2021, Available Online: https://www​.google​.com​ /url​?sa​=t​&rct​=j​&q=​&esrc​=s​&source​=web​&cd=​&ved​=2ahUKEwjlh​_KoxsX3AhUYQ​ _EDH​d BcB​Sk4K​BAWe​g QIBRAB​& url​= https​%3A​%2F​%2Fwww​.fcc​.gov​%2Ffile​ %2F20606​%2Fdownload​&usg​=AOv​Vaw3​tprj​48KZ​Isgt​m4TDA1tX4 107. ETSI TS 129 500 V16.4.0 (2020-11), “5G System; Technical Realization of Service Based Architecture, Stage 3 (3GPP TS 29.500 Version 16.4.0 Release 16)”, Available Online: https://www​.etsi​.org​/deliver​/etsi​_ts​/129500​_129599​/129500​/16​.04​.00​_60​/ts​ _129500v160400p​.pdf 108. BroadForward, “Binding Support Function”, Available Online: https://www​.broadforward​.com​/ binding​-support​-function​-bsf/ 109. ETSI TS 129 513 V16.6.0 (2021-01), “5G System; Policy and Charging Control Signalling Flows and QoS Parameter Mapping; Stage 3 (3GPP TS 29.513 Version 16.6.0 Release 16)”, Available Online: https://www​.etsi​.org​/deliver​/etsi​_ts​/129500​ _129599​/129513​/16​.06​.00​_60​/ts​_129513v160600p​.pdf 110. metaswitch, “What is a Session Border Controller (SBC)?”, Available Online: https:// www​.metaswitch​.com ​/ knowledge​-center​/reference​/what​-is​-a​-session​-border​-controller​-sbc 111. metaswitch, “Session Border Control in IMS and VoLTE / V2oLTE”, Available Online: https://www​.metaswitch​.com ​/ knowledge​- center​/reference​/session​-border​- control​-in​ -ims​-and​-volte-/​-v2olte 112. ETSI TS 123 228 V16.5.0 (2020-10), “Digital Cellular Telecommunications System (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); LTE; IP Multimedia Subsystem (IMS); Stage 2 (3GPP TS 23.228 Version 16.5.0 Release 16)”, Available Online: https://www​.etsi​.org​/deliver​/etsi​_ts​/123200​_123299​/123228​/16​.05​ .00​_60​/ts​_123228v160500p​.pdf 113. IPLOOK, “Voice over NR(VoNR)”, Available Online: https://www​.iplook​.com​/products​/ims​-vonr 114. Simon Dredge, “The Role of IMS in Voice Over 5G (VoNR)”, metaswitch, Available Online: https://www​.metaswitch​.com​/ blog​/the​-role​-of​-ims​-in​-voice​-over​-5g​-vo5g 115. TechPlayon, “Voice Over NR (VoNR Call Flow)”, Available Online: https://www​.techplayon​.com​/voice​-over​-nr​-vonr​-call​-flow/

3

5G Service-Based Architecture, Protocol Stack, and Interoperation

3.1 5GC SERVICE-BASED ARCHITECTURE Prior to LTE, cellular core networks relied on telecom-specific protocols executed on telecom-specific hardware. The first steps toward virtualization were taken using LTE vEPC. The advancement of this strategy, known as Service-Based Architecture (SBA), has been embraced by the 5G System [1, 2]. In the 5G Core network, known as SBA, the control plane elements are Virtualized Network Functions (VNFs). One VNF can provide “services” to other VNFs using RESTful-based Application Programming Interface (API) interchange [3]. Several NFs offer their services to other authorized NFs in SBA. Simply put, these NFs are just software implementations deployed on Commercial Off The Shelf (COTS) hardware in the cloud. Any number of functions can be provided by an NF. A client-server architecture and welldefined APIs are used to interface NFs. API calls on a logically shared service bus [4, 5] replace the need for traditional telecom signaling messages. In a 5G network, a service is an atomized capability that has high cohesion, loose coupling, and autonomous management. This enables on-demand service deployment and incremental updates to specific services that have minimal impact on other services. In response to an operator or service provider’s specifications, a service will deliver the intended results in exchange for specified inputs. As will be discussed in Subsection 3.1.1 with regard to the AMF, a service is deployed based on the service framework, which includes service registration, service authorization, and service discovery. There is always an API or other interface through which a service is called into action. All interactions between services must be implemented through service invocation, and each service must provide unique capabilities and display Service-Based Interfaces (SBIs) to service consumers. Here are a few of the most important ones that the 5G SBA offers: [6]: (i) Control Plane Services (CPS) provide network management services such as access control, mobile device management, policy management, data leakage protection, legal intercept, and billing management. (ii) User Plane Services (UPS) can facilitate a wide range of tasks, including packet forwarding and routing, traffic management (including Quality of Service (QoS) enforcement and firewalls), serving as a hub for intra- and

DOI: 10.1201/9781003465393-3

175

176

5G NR Modeling in MATLAB®

inter-Radio Access Technology (RAT) mobility, packet inspection, and packet replication (e.g., for lawful intercept). (iii) The Service Framework (SF) includes tools for service discovery, registration, and authentication used by all CP/UP services on the network. (iv) The Data Service provides a centralized location for all UE data. Subscription and policy information, mobility and session management settings, and session management context data are only some of the UE-related information that may be found in operator networks. A more detailed treatment of these services with respect to the SBA is given in Subsections 3.1.1 to 3.1.8. SBA shall bring the following benefits to 5G: (i) Updating Production Network: The loose coupling between services in modern networks makes it possible to upgrade specific services with minimal impact on the rest of the network. Benefits to operations include faster bug fixes and new network features and operator apps through shorter testing and integration times thanks to the shift toward continuous integration. (ii) Extensibility: Through a lightweight service-based interface, services can communicate with one another directly. Unlike the traditional hop-by-hop paradigm, the SBI can be readily extended without adding new reference points and corresponding message flows. (iii) Modularity and Reusability: The network is made of modularized services, which represent the network capabilities, and give support to essential 5G technologies such as network slicing. Each service can be reused extensively because it is simple for other services to call it (with the right permissions). (iv) Openness: Using a specialized service, information about a 5G network may be made available to external users like third parties (e.g., enterprises) without the need for complex protocol translation [6]. This is possible because of the management and control functionalities that are built into 5G networks. In conventional networks, data is exchanged between nodes using predetermined points of contact. Such anchor points are distinguished by the presence of distinct peer-to-peer nodes and flows. A service’s purpose in a SBA is to provide an interface via which services’ capabilities can be accessed by their users. Such type of interface shall have characteristics such as: • Implementing a common data model and protocol for interoperability across vendors. • Having a small footprint for effective interaction, such as high concurrency, low latency, etc.

5G Service-Based Architecture, Protocol Stack, and Interoperation

177

• Having a low barrier to entry for invocation or reuse both internally and externally. • Having access to a wide variety of powerful software development resources. There are several SBIs in the 5G SBA architecture. These interfaces can be grouped under eight main categories of services as shown in Figure 3.1 which depicts a complete 5G SBA architecture with all the main components shown [7, 8, 9, 10]. The services provided by each of these components will be detailed in Subsections 3.1.1 to 3.1.8. For Release 15, 3GPP has decided on a set of protocols for SBIs. The protocol uses Transmission Control Protocol (TCP) for transport, JavaScript Object Notation (JSON) for serialization, the RESTful design pattern if possible (falling back to custom methods otherwise), and OpenAPI as its Interface Description Language (IDL). Alternatives like the Internet Engineering Task Force’s Quick

FIGURE 3.1  5G SBA and SBIs.

178

5G NR Modeling in MATLAB®

FIGURE 3.2  The 5G SBI protocol stack.

UDP Internet Connections (QUIC) over User Datagram Protocol (UDP) are also being considered [6]. A typical protocol stack for the 5G SBI is shown in Figure 3.2. The different components of this protocol stack are described as follows: (a) RESTful APIs As can be seen in Figure 3.3, 3GPP made the foresightful choice to employ RESTful APIs not only for exposing third party functionality but also via the SBIs. Thus, the 5G Core Network’s internal communication follows the same principles as the functional exposure, allowing for a unified and comprehensive technological approach to the entire 5G system that is in sync with the modern paradigms that underpin so many of the services enjoyed by end users and the industries they work in [5]. Known as the REST architectural style, it was first outlined by Roy Fielding in his dissertation [11] that was published in the year 2000. While its acronym, REST, suggests otherwise, the REpresentational State Transfer model is not a protocol nor a description language, nor is it a concrete architectural style. It is commonly referred to as a paradigm or set of guiding ideas. In order to make the development and deployment of distributed services more adaptable, consistent, and scalable, Fielding [11] outlines six principles at the heart of RESTful service architecture design and service development. (i) Resource, Serialization, and Representation REST allows for the storage of resources in arbitrary formats on servers (such as Network Repository Function (NRF)) and allows resources to exist in arbitrary internal states (such as the SMF Service Profile used in Service Registration). Uniform Resource Identifiers (URIs) are used to create, modify, and delete resources, and each resource has its own unique URI. During these processes, it is common for a client (in this case, SMF) and a server to exchange some or all of the data that pertains to the resource in question

5G Service-Based Architecture, Protocol Stack, and Interoperation

179

FIGURE 3.3  RESTful APIs for the service-based interfaces and northbound communication.

(ii)

(iii)



(iv) (v)

(here: NRF). The resource is serialized, or all of its data is written into a document, so that it may be transferred easily. For 5G SBA, data is stored as JSON documents. Client/Server Principle The REST principle of “client/server” requires a clear separation of labor between the party making a request for a resource (the “client”) and the party making the resource itself (the “server”). In 5G SBA, for instance, the SMF plays the role of client toward the NRF during the Service Registration process, while the NRF plays the role of server. Stateless Principle Stateless is the REST concept which specifies that the server does not keep any state-related information concerning the conversation with specific clients. Therefore, it is imperative that clients provide complete and accurate information in their service requests to the server. Since the required services can be made available by a group of servers, to which load can be spread on a per-request basis, this not only frees up resources at the server but also allows for load balancing and resiliency in a distributed environment. In 5G SBA, the NRF and the SMF, when playing the role of service producers, simply send back the requested data to their respective customers (like the AMF). Neither NRF nor SMF maintains any further state regarding the AMF communication. Cacheable Principle The cacheable REST principle requires that servers indicate to clients if the data they have received can be stored locally and reused by the client at a later time. Layered System Principle The REST concept of a layered system stipulates that the client must be in the dark about which server it is communicating with and whether or

180

5G NR Modeling in MATLAB®

not various sorts of requests are handled by different servers. The AMF manages access to services and mobility for its customers, session management is handled by the SMF, network slices are chosen with the help of the Network Slice Selection Function (NSSF), and so on. All of these functionalities are essential to enable services like mobility, roaming or security easily available throughout the global system to a client. However, the client is in the dark about the origin of these services. (vi) Code-on-Demand Principle The REST idea of “code on demand” enables the server to dynamically and flexibly deliver code to the client, improving the responsiveness and adaptability of the service. 5G SBA does not yet apply this idea because its services do not necessitate adaptability [5]. (b) HTTP and REST In addition to backwards compatibility with HTTP/1.1, the Internet Engineering Task Force (IETF) designed HTTP/2 to improve the management of (RESTful) API operations and general web-service development, for example [5]: • HTTP POST request generates a new resource whose URI can be used to fulfil the request. • HTTP GET request returns a list containing the resources associated with a given URI. • HTTP PUT request changes the resource at the URI to match the representation in the request. • HTTP PATCH request modifies the state of the resource at the given URL using the request’s representation. • HTTP DELETE request removes the resource identified by its URI. In 5G SBA, there are several network entities which make use of HTTP-based RESTful communications in, for example. procedures such as service registration, service discovery, and service request. A typical example involves an exchange of messages between the AMF, PCF, and NRF as shown in Figure 3.4 [12]. The call flow proceeds as per the following steps:

1. The PCF provides the NRF with details about itself, including its services, network address, and identity, via an HTTP PUT message. 2. After verifying the request’s authenticity, logging the PCF registration data, and sending a response, the NRF completes the PCF registration process. Using the NRF, additional NFs can now access the PCF services. 3. Next, another NF like the AMF needs to make use of a PCF’s resources. The first step in accomplishing this is to conduct a search in the NRF for PCFs that provide the desired assistance. The term “Service Discovery” describes this period. Here, the AMF is the Service Customer, while the NRF plays the role of Service Provider. In its query to the NRF, the AMF specifies the type of Network Function it needs and the services

5G Service-Based Architecture, Protocol Stack, and Interoperation

181

FIGURE 3.4  HTTP call flow in 5G SBA.

the requested NF must be able to provide. The GET method of the HTTP protocol is used for this. 4. The AMF makes a request, and the NRF determines which of the registered Network Functions can fulfil that request. 5. At this point, the AMF can choose a PCF that meets the service requirements and initiate communication with that PCF by sending a Service Request. This time around, it is the PCF who is the Service Producer and the AMF who is the Service Consumer. The HTTP POST method is used for this purpose. 6. After receiving this service request, the PCF will identify the appropriate policy that the AMF has asked for and send a response to them via HTTP [12]. (c) JSON JavaScript Object Notation, or JSON for short, is a compact data-exchange standard. The JSON is a simple text format for exchanging information between computers. It can be understood by people of any language because it is “self-describing”. The syntax of JavaScript objects is quite close to the JSON format. Therefore, it is simple for a JavaScript program to transform JSON data into JavaScript objects. JSON data is easily transferred between computers and can be used by any programming language [13] due to the format's text-only nature. An HTTP server responds with status codes and a body in JSON or XML as per Table 3.1 [14]. For example, when a message such as GET https://clientdata​.com​/people​/John is sent to the client data server, it may respond with 200 (OK) and information in JSON format as follows [14]:

182

5G NR Modeling in MATLAB®

{ “first-name”:“John”, “last-name”“Fleming”, “job”:“Professor”, “education”:“PhD”, “web-site”:“www​.jfleming​.com” } TABLE 3.1 HTTP Status Codes Status Code

Description

1xx

Informational

2xx 3xx 4xx

Successful (e.g., 200 OK, 201 created) Redirection Client Error (e.g., 400 bad request, 401 unauthorized, 402 payment required, 404 not found)

5xx

(e.g., 500 Internal Server Error, 501 Not Implemented, 503 Service Unavailable)

The response may also be XML format as follows:

John Fleming Professor PhD www​.jfleming​.com

(d) QUIC, TCP, and TLS For many years, Transmission Control Protocol (TCP) has been the preferred transport protocol on the Internet because of the reliability and congestion control it provides [15, 16]. Transport Layer Security (TLS) protocol is used to guarantee authentication and encryption [17]. However, Google published Quick UDP Internet Connections (QUIC) [18] rules for a new transport protocol in 2012. After the protocol was presented to the Internet Engineering Task Force (IETF), it underwent extensive revisions and development [8]. QUIC aims to decrease the time it takes to establish a connection between two devices, hence improving the responsiveness of Web applications. It was also crucial to fix the Head-of-Line (HOL) blocking issue that had been bothering HTTP/2 over TCP [18].

3.1.1 5G Core Packet Controller Services The packet controller services include four main classes of services and SBIs described as follows:

183

5G Service-Based Architecture, Protocol Stack, and Interoperation

FIGURE 3.5  AMF reference model.

(a) Access and Mobility Management Services The SMF, other AMFs, LMF, PCF, GMLC, SMSF, CBCF, NWDAF, PWS-IWF, and NEF are all 5GC nodes that can take advantage of the AMF’s services thanks to the Namf SBI (as given described 3GPP TS 23.501 [19], 3GPP TS 23.502 [20] and 3GPP TS 23.288 [21]). AMF and the scope of this specification are highlighted in Figure 3.5, which also includes the reference model. There are four main services offered by the AMF and each service has a corresponding API as given in Table 3.2: (i) AMF Communication Service Through this service, an NF can exchange N1 Non-Access Stratum (NAS) communications with a User Equipment (UE) or with an Access Network (AN) (both UE and non-UE specific). The NF can interact with the UE and the AN through the below service operations. The primary features of this NF service are as follows.: • Operate as a service to convey N1 messages to the UE. • Give NFs the option to subscribe and unsubscribe to N1 message alerts from the UE. TABLE 3.2 API Descriptions for the AMF Service Name

Description

OpenAPI Specification File

apiName

Namf_ Communication

AMF Communication Service

TS29518​_Namf​ _Communication​.​yaml

namfcomm

Namf_ EventExposure Namf_MT

AMF Event Exposure Service AMF Mobile Terminated Service

TS29518​_Namf​ _EventExposure​.​yaml TS29518​_Namf​_MT​.​yaml

namf-evts

Namf_Location

AMF Location Service

TS29518​_Namf​_Location​ .​yaml

namf-loc

namf-mt

184

5G NR Modeling in MATLAB®

FIGURE 3.6  NAMF-COMMUNICATION Service operations.

• Make it possible for NFs to subscribe for and unsubscribe from receiving specific alerts from AN. • Facilitate the initiation of N2 messages towards the AN via service activities. • Security Context Management. • Information administration and transmission in UE (including its security context). This service supports several service operations as shown in Figure 3.6. An overview of the call flow diagrams of the service operations which use the HTTP Request/Response are briefly described in Figure 3.7. An overview of the call flow diagrams of the service operations for N1N2 Subscribe/Notify are briefly described in Figure 3.8. An overview of the call flow diagrams of the service operations for NonUeN2Info operations are briefly described in Figure 3.8. An overview of the call flow diagrams of the service operations for AMFStatusChange operations are briefly described in Figure 3.9.

5G Service-Based Architecture, Protocol Stack, and Interoperation

185

FIGURE 3.7  Service operations of NAMF COMMUNICATION with HTTP Request/ Response.

Namf_Communication Service API The Namf_Communication service uses the Namf_Communication API. According to 3GPP TS 29.501 [22], the following format must be utilized for the request URI in HTTP requests sent from NF service consumers to NF service producers: {apiR​oot}/​/​/

Its components are described as follows:

186

5G NR Modeling in MATLAB®

FIGURE 3.8  N1N2 Subscribe/Notify call flow diagrams.

• {apiRoot} shall be configured according 3GPP TS 29.501 [22] requirements i.e.,: • Scheme (“http://” or “https://”). • Authority (host and optional port) as defined in IETF RFC 3986. A string that begins with “/” and contains deployment-specific information. • The must be fixed to “namf-comm”. • The must be fixed to “v1”. • The must be fixed according to Figure 3.10. Figure 3.10 also shows the resource name and the corresponding HTTP methods which maps the resource to a given service operation. For example, the resource / ue-contexts /{ueContextId} uses the PUT method to trigger the CreateUE context

5G Service-Based Architecture, Protocol Stack, and Interoperation

187

FIGURE 3.9  AMFStatusChange call flow operations.

service operation. The data types supported by each operation and the description of the operations are also given in Figure 3.10. (ii) AMF Event Exposure Service To allow an NF to subscribe to event alerts for itself or on behalf of another NF, the AMF may provide this service as a Service Producer. NEF, SMF, UDM, and NWDAF are the currently known Service Consumers. Table 3.3 [22] lists all of the events that can be expected from the Namf EventExposure Service. This service supports several service operations as shown in Figure 3.11. The call flow diagrams pertaining to Subscribe/Notify for the Namf_ EventExposure service are summarized in Figure 3.12. Namf_EventExposure Service API The Namf_EventExposure service uses the Namf_EventExposure API. HTTP requests from NF service consumers to NF service producers must employ a request URI that conforms to the structure specified in 3GPP TS 29.501 [22], i.e.: {​apiRo​ot}///​

It has the following components: • • • •

{apiRoot} shall be fixed as described in 3GPP TS 29.501 [22]. must be fixed to “namf-evts”. must be fixed to “v1”. The must be fixed as per Figure 3.13.

188

5G NR Modeling in MATLAB®

FIGURE 3.10  Namf_Communication API’s resource URI structure.

(iii) Namf_MT Service The Namf MT service provides the NF with the ability to inquire about the UE’s MT signaling and data transmission capabilities. This NF service’s primary features are as follows: • Paging UE if the latter is in IDLE state and replies to other NF when the UE enters the CM-CONNECTED state. • If the UE is in the CONNECTED state, it will reply to the requesting NF.

5G Service-Based Architecture, Protocol Stack, and Interoperation

189

TABLE 3.3 Namf_EventExposure Service Events Event

Description

Location-Report

By subscribing to this event, an NF will be alerted if AMF detects a change in the location of any subscribed UEs, regardless of whether they belong to the same group or not.

Presence-In-AOIReport

By subscribing to this event, an NF will be alerted whenever a User Equipment (UE) or group of UEs enters or exits a designated Area of Interest (AOI). The area could be identified by a TA list, an area ID, or a specific interested area name like “LADN”. If an NF has subscribed to this event, it will be notified whenever AMF detects a change in the time zone of a User Equipment (UE) or a group of UEs. If an NF is subscribed to this event, it will be notified if AMF learns that an individual User Equipment (UE), a group of UEs, or any UE has changed its access type. A TA list, area ID, or interesting area name like “LADN” could be used to identify the location. If an NF is interested in knowing how the registration status of a certain UE, a set of UEs, or all UEs has changed, it can subscribe to this event and receive notifications from AMF. A TA list, area ID, or interesting area name like “LADN” could be used to pinpoint the location. If an NF is interested in knowing how a particular user equipment (UE) or group of UEs are handling their connections, it can subscribe to this event and obtain that information from AMF. When a UE’s reachability status changes from REACHABLE to UNREACHABLE or REGULATORY ONLY, the AMF will notify any NFs that have subscribed to the “UE Reachability Status Change” event, so that they can alter the reachability status of the affected UEs. If the AMF detects a RAN or NAS failure, the NF can subscribe to this event to receive the Communication failure report of a UE, a group of UEs, or any UE. This event is subscribed to by an NF so that it may learn the density of UEs in a given region. In either case, an NF can request that AMF actively search for UEs in the vicinity based on their current location or their last-known location. The NF can subscribe to this event to be notified when a specific UE or set of UEs become unreachable for signaling or user plane communication as determined by the AMF. In order for an NF to obtain a UE’s 5GS User State, it must subscribe to this event. After a DDN failure, an NF can learn whether or not a UE is available by subscribing to this event. This event can be subscribed to by an NF to receive the TAC from a single UE, a set of UEs, or all UEs.

Time-Zone-Report Access-Type-Report

Registration-StateReport

Connectivity-StateReport Reachability-Report

CommunicationFailure-Report UEs-In-Area-Report

Loss-ofConnectivity 5GS-User-StateReport Availability-afterDDN-failure Type-AllocationCode-Report Frequent-MobilityRegistration-Report

This event can be subscribed to by an NF to obtain the total number of mobility registrations made by a single UE, a set of UEs, or all UEs within a given time period.

190

5G NR Modeling in MATLAB®

FIGURE 3.11  Namf_EventExposure Service operations.

FIGURE 3.12  Call flow diagrams for the Namf_EventExposure operations.

• Letting the consumer NF know how to choose a domain as a termination point for IMS voice calls. This service supports several service operations as shown in Figure 3.14. The call flow diagrams for the Namf_MTService are briefly described in Figure 3.15. Namf_MT Service API The Namf_MT uses the Namf_MT API. The following is the format that must be used for the request URI in an HTTP request from an NF services consumer to an NF service producer:

5G Service-Based Architecture, Protocol Stack, and Interoperation

191

FIGURE 3.13  Namf_EventExposure API’s resource URI format.

FIGURE 3.14  Service operations of the Namf_MTService.

{​apiRo​ot}///​

with the following components: • • • •

{apiRoot} shall be set as described in 3GPP TS 29.501 [22]. must be fixed to “namf-mt”. must be fixed to “v1”. must be fixed as per Figure 3.16.

192

5G NR Modeling in MATLAB®

FIGURE 3.15  Call flow diagrams for the Namf_MTService.

FIGURE 3.16  Namf_MT API’s resource URI format.

5G Service-Based Architecture, Protocol Stack, and Interoperation

193

FIGURE 3.17  Service operations on Namf_Location.

(iv) Namf_Location Service NF service consumers can utilize the Namf Location service to make positioning queries to the AMF and provide their current location details. It is also used to inform NF service consumers when their location has changed. This NF service's primary features are as follows: • Allow NFs to request the current geodetic and possibly civic position of a target UE. • Permit NFs to be informed about emergency session-related events. • Permit NFs to ask for a target UE’s local time zone and/or Network Provided Location Information (NPLI). This service supports several service operations as shown in Figure 3.17. The call flow diagrams of the Namf_Location service operations are briefly described in Figure 3.18. Namf_ Location API The Namf_Location uses the Namf_ Location API. An HTTP request from a user of NF services to an NF service provider must use the following format for the request URI: {apiR​oot}/​/​/ with the following components: • • • •

{apiRoot} must be fixed as described in 3GPP TS 29.501 [22]. must be fixed to “namf-loc”. must be fixed to “v1”. must be fixed as per Figure 3.19.

(b) SMF Through the Nsmf SBI, the SMF provides services to the AMF, other SMFs (V-SMFs or H-SMFs), the PCF, and the NEF within the 5GC (see 3GPP TS 23.501 [19] and 3GPP TS 23.502 [20]). Focusing on the SMF and the purview of this specification, Figure 3.20 presents the reference model.

194

5G NR Modeling in MATLAB®

FIGURE 3.18  Call flow diagrams of the Namf_Location Service operations.

FIGURE 3.19  Namf_Location Service API’s resource URI format.

5G Service-Based Architecture, Protocol Stack, and Interoperation

195

FIGURE 3.20  Reference model—SMF.

The SMF supports the following two main services: (i) Nsmf_PDUSession. This service controls the PDU sessions by applying the PCF-provided policy and billing regulations. This NF service makes it possible for consumer NFs to create, modify, and tear down PDU sessions through the service activities it exposes. (ii) Nsmf_EventExposure. Events occurring during PDU sessions are made available to consumer NFs via this service. The Nsmf PDUSession service utilizes PDU Sessions to perform its functions. This service makes available the service actions necessary for other NFs to create, modify, and remove PDU Sessions. The following are the key functionalities of this NF service: • PDU Sessions’ SM contexts are created, updated, and deleted when they receive an N1 message notification from the AMF delivering the NAS’s SM messages. For a given PDU session, an SM context indicates the connection between the NF Service Consumer (such as an AMF) and the SMF. • Accessing PDU session SM contexts using the N26 interface, for example, to redirect PDU sessions to the EPC. • PDU sessions between the V-SMF and H-SMF can be created, modified, and deleted in HR roaming scenarios. • Tying policy and charging rules to flows and associating policy and charging rules with PDU Sessions. • User plane session setup, management, and teardown requiring communication with the UPF over N4. • Handle UPF user plane events and implement policy and billing rules. The service operations shown in Figure 3.21 are supported by the Nsmf_PDUSession service.

196

5G NR Modeling in MATLAB®

FIGURE 3.21  Nsmf_PDUSession Service supports the service operations.

The call flow diagrams of the NSMF PDU Session HTTP Subscribe/Notify operations are shown in Figure 3.22. The call flow diagrams of the NSMF PDU Session HTTP Request Response operations are shown in Figure 3.23. The Nsmf_PDUSession Service API shall have the following root: {​apiRo​ot}/{​apiNa​me}/{​apiVe​rsion​}/

where the “apiName” must be fixed to “nsmf-pdusession” and the “apiVersion” must be fixed to “v1” for the current version of this specification. Figure 3.24 describes the resource URI format of the Nsmf_PDUSession API.

FIGURE 3.22  Call flow diagrams of the NSMF PDU session HTTP Subscribe/Notify operations.

5G Service-Based Architecture, Protocol Stack, and Interoperation

197

FIGURE 3.23  Call flow diagrams of the NSMF PDU session HTTP Request/Response operations.

(c) SMSF The SMSF provides services to the AMF within the 5GC through the Nsmsf SBI [19] [20]. The reference model is shown in Figure 3.25, with the SMSF and the scope of this specification.

198

5G NR Modeling in MATLAB®

FIGURE 3.24  Nsmf_PDUSession API’s resource URI format.

To enable the NF Service Consumer (like AMF) to authorize and activate SMS for a service user on SMSF, the SMSF provides the Nsmsf SMService service. This NF service’s primary features are as follows: • In SMSF, a UE Context for SMS is created, updated, or deleted whenever the SMS service is activated or deactivated for a certain service user. • Uplink SMS content transmission to SMS Focus. The Nsmf_PDUSession service supports the service operations shown in Figure 3.26.

FIGURE 3.25  Reference model—SMSF.

5G Service-Based Architecture, Protocol Stack, and Interoperation

199

FIGURE 3.26  Nsmsf_PDUSession Service operations.

The call flow diagram of the Nsmf_PDUSession service operations is shown in Figure 3.27. The Nsmsf_SMService Service API shall have the following structure: {apiRoot}/{apiName}/{apiVersion}/ where the “apiName” must be fixed to “nsmsf-sms” and the “apiVersion” must be fixed to “v1” for the current version of this specification. Figure 3.28 describes the resource URI format of the Nsmsf-sms API. (d) UCMF The UCMF provides services to the NF (such as AMF and MME) within the 5GC using the Nucmf SBI [19][20]. Focusing on the UCMF and the purview of this specification, Figure 3.29 presents the reference model. For managing the associations between UE Radio Capability ID and UE Radio Access Capability Information, the UCMF provides the Nucmf

FIGURE 3.27  Call flow diagram of the Nsmsf_PDUSession Service operations.

200

5G NR Modeling in MATLAB®

FIGURE 3.28  Nsmsf-sms API’s resource URI format.

UECapabilityManagement service. This service provides the following service activities to the service consumer NF: • To access the radio access capabilities of a UE using its unique (manufacturer-assigned or PLMN-assigned) UE Radio Capability ID. • To find out what radio access capabilities an individual UE has by obtaining its PLMN-assigned UE Radio Capability ID. • To subscribe or unsubscribe for updates on new definitions in the UCMF dictionary.

FIGURE 3.29  Reference model UCMF.

5G Service-Based Architecture, Protocol Stack, and Interoperation

201

FIGURE 3.30  Nucmf_UECapabilityManagement Service operations.

• To receive updates on the addition and removal of entries from the UCMF dictionary. The Nucmf_UECapabilityManagement service supports the service operations shown in the following Figure 3.30: The call flow diagram of the Nucmf_UECapabilityManagement Service Operations is shown in Figure 3.31:

FIGURE 3.31  Call flow diagram of the Nucmf_UECapabilityManagement Service operations.

202

5G NR Modeling in MATLAB®

FIGURE 3.32  Nucmf_UECapabilityManagement API’s resource URI format.

The Nucmf_UECapabilityManagement service uses the Nucmf_ UECapabilityManagement API. The following is the format that must be used for the request URI in an HTTP request from a consumer of NF services to an NF service producer: {apiR​oot}/​/​{apiV​ersio​n}/ Where the must be fixed to “nucmf-uecm” and the {apiVersion} must be fixed to “v1”. Figure 3.32 describes the resource URI format of the Nucmf_ UECapabilityManagement API.

3.1.2 5G Core Subscriber Management Services The Subscriber Management services include three main classes of services and SBIs described as follows: (a) Unified Data Management (UDM) Through its Nudm SBI, the UDM provides services to the AMF, SMF, SMSF, NEF, and AUSF within the 5GC (3GPP TS 23.501 [19] and 3GPP TS 23.502 [20]). The reference model is shown in Figure 3.33. The UDM supports the following main services [23]:

5G Service-Based Architecture, Protocol Stack, and Interoperation

203

FIGURE 3.33  Reference model—UDM.

(i) Nudm_SubscriberDataManagement. This service retrieves subscription data pertinent to the consumer NF from the UDM for the user equipment. Additionally, it is utilized to subscribe to data change notifications, to opt out of data change notifications and to be notified when UDM modifies the subscription data. (ii) Nudm_UEContextManagement. This service is used for UDM registration, deregistration, retrieval of previously stored registration data, modification of previously stored registration data, and notification of the requirement for P-CSCF restoration as determined by the UDM. (iii) Nudm_UEAuthentication. This service is utilized by the AUSF to request the UDM to choose an authentication method, generate a new Authentication Vector (AV), and deliver it to the AUSF. It is also utilized by the AUSF to inform the UDM whether authentication was successful or unsuccessful. (iv) Nudm_EventExposure. This service allows customer NF to register for updates whenever a certain event occurs. When an event that can be detected by the AMF occurs, the UDM will perform the appropriate AMF service operation to subscribe on behalf of the consumer NF. Consumer NFs that have subscribed to notifications use the Nudm EventExposure service to both unsubscribe and receive notifications from the UDM whenever a subscribed event happens on the UDM. (v) Nudm_ParameterProvision. This service allows a UE’s subscription information to be updated by consumer NFs. (i) UDM Subscriber Data Management Service This service supports several service operations as shown in Figure 3.34. An overview of the call flow diagrams of the service operations which are supported by Nudm_SubscriberDataManagement is given in Figure 3.35 and Figure 3.36. The Nudm_SubscriberDataManagement service uses the Nudm_ SubscriberDataManagement API. The following is the format that must be used for the request URI in an HTTP request from a consumer of NF services to an NF service producer: {apiR​oot}/​/​{apiV​ersio​n}/

204

5G NR Modeling in MATLAB®

FIGURE 3.34  UDM Subscriber Data Management Service operations.

FIGURE 3.35  Call flow diagram of the UDM Subscriber Data Management Service operations (Part A).

Where the must be fixed to “nudm-sdm” and the {apiVersion} must be fixed to “v1”. Figure 3.37 describes the resource URI format of the Nudm_ SubscriberDataManagement API. (ii) UDM Context Management Service This service supports several service operations as shown in Figure 3.38. An overview of the call flow diagrams of the service operations which are supported by Nudm_UEContextManagement Service is given in Figure 3.39 and Figure 3.40. The Nudm_UEContextManagement service uses the Nudm_ UEContextManagement API. The following is the format that must be used for the

5G Service-Based Architecture, Protocol Stack, and Interoperation

205

FIGURE 3.36  Call flow diagram of the UDM Subscriber Data Management Service operations (Part B).

request URI in an HTTP request from a consumer of NF services to an NF service producer: {apiR​oot}/​/​{apiV​ersio​n}/ Where the must be fixed to “nudm-uecm” and the {apiVersion} must be fixed to “v1”. Figure 3.41 describes the resource URI format of the Nudm_ UEContextManagement API. (iii) UDM UE Authentication Service This service supports several service operations as shown in Figure 3.42. An overview of the call flow diagrams of the service operations which are supported by Nudm_UEAuthentication is given in Figure 3.43.

206

5G NR Modeling in MATLAB®

FIGURE 3.37  Nudm_SubscriberDataManagement Service API’s resource URI format.

The Nudm_UEAuthentication service uses the Nudm_UEAuthentication API. The following is the format that must be used for the request URI in an HTTP request from a consumer of NF services to an NF service producer: {apiR​oot}/​/​{apiV​ersio​n}/ Where the must be fixed to “nudm-ueau” and the {apiVersion} must be fixed to “v1”.

FIGURE 3.38  UDM Context Management Service operations.

5G Service-Based Architecture, Protocol Stack, and Interoperation

207

FIGURE 3.39  Call flow diagram of the UDM Context Management Service operations (Part A).

208

5G NR Modeling in MATLAB®

FIGURE 3.40  Call flow diagram of the UDM Context Management Service operations (Part B).

Figure 3.44 describes the resource URI format of the Nudm_UEAuthentication API. (iv) UDM Event Exposure Service This service supports several service operations as shown in Figure 3.45. An overview of the call flow diagrams of the service operations which are supported by Nudm_EventExposure is given in Figure 3.46. The Nudm_EventExposure service uses the Nudm_EventExposure API. The following is the format that must be used for the request URI in an HTTP request from a consumer of NF services to an NF service producer: {​apiRo​ot}//{​apiVe​rsion​}/​

5G Service-Based Architecture, Protocol Stack, and Interoperation

209

FIGURE 3.41  Nudm_UEContextManagement Service API’s resource URI format.

FIGURE 3.42  UDM UE Authentication Service operations.

Where the must be fixed to “nudm-ueau” and the {apiVersion} must be fixed to “v1”. Figure 3.47 describes the resource URI structure of Nudm_EventExposure API. (v) UDM Parameter Provision Service This service supports several service operations as shown in Figure 3.48. The call flow diagram of the Nudm_ParameterProvision Service Operations is shown in Figure 3.49:

210

5G NR Modeling in MATLAB®

FIGURE 3.43  Call flow diagram of the UDM UE Authentication Service operations.

FIGURE 3.44  Nudm_UEAuthentication Service API’s resource URI format.

FIGURE 3.45  UDM Event Exposure Service operations.

The Nudm_ParameterProvision service uses the Nudm_ParameterProvision API. The following is the format that must be used for the request URI in an HTTP request from a consumer of NF services to an NF service producer: {​apiRo​ot}//{​apiVe​rsion​}/​

5G Service-Based Architecture, Protocol Stack, and Interoperation

211

FIGURE 3.46  Call flow diagram of the UDM Event Exposure Service operations.

FIGURE 3.47  Nudm_EventExposure Service API’s resource URI format.

FIGURE 3.48  UDM Parameter Provision Service operations.

Where the must be fixed to “nudm-pp” and the {apiVersion} must be fixed to “v1”. Figure 3.50 describes the resource URI structure of Nudm_ParameterProvision API. (b) Authentication Server Function (AUSF) The requester NF uses the AUSF to authenticate the UE, receive keying material, and secure the Steering Information List [24]. The reference model is shown in Figure 3.51.

212

5G NR Modeling in MATLAB®

FIGURE 3.49  Call flow diagram of the UDM Parameter Provision Service operations.

FIGURE 3.50  Nudm_ParameterProvision Service API’s Resource URI format.

FIGURE 3.51  Reference model—AUSF.

The AUSF supports the following main services [24]: (i) Nausf_UEAuthentication. This service offers the requesting NF a UE authentication service. This service allows the UE to be authenticated and for the provider to supply one or more master keys from which the AMF generates further keys. (ii) Nausf_SoRProtection. In order to prevent the VPLMN from removing or tampering with the Steering Information List, the NF Service Consumer can use this service to obtain the SoR-MAC-IAUSF and CounterSoR. The SoR-XMAC-IUE, which verifies that the UE got the Steering Information List, can be provided to the NF Service Consumer through this service as well.

5G Service-Based Architecture, Protocol Stack, and Interoperation

213

FIGURE 3.52  AUSF UE Authentication Service operations.

(iii) Nausf_UPUProtection. To prevent the VPLMN from tampering with or erasing the UE Parameters Update Data, this service makes it possible to supply the NF Service Consumer with the UPU-MAC-IAUSF and CounterUPU. This service can also be used to supply the UPU-XMACIUE, which the NF Service Consumer can utilize to ensure the UE has received the right UE Parameters Update Data. (i) AUSF UE Authentication Service This service supports several service operations as shown in Figure 3.52. The call flow diagram of the Nausf_UEAuthentication Service Operations is shown in Figure 3.53: The Nausf_UEAuthentication service uses Nausf_UEAuthentication API. The following is the format that must be used for the request URI in an HTTP request from an NF services consumer to an NF service producer: {apiR​oot}/​/​{apiV​ersio​n}/ Where the must be fixed to “nausf-auth” and the {apiVersion} must be fixed to “v1”.

FIGURE 3.53  Call flow diagram of the AUSF UE Authentication Service operations.

214

5G NR Modeling in MATLAB®

FIGURE 3.54  Nausf_UEAuthentication Service API’s resource URI format.

FIGURE 3.55  AUSF SoR Protection Service operations.

FIGURE 3.56  Call flow diagram of the AUSF SoR Protection Service operations.

Figure 3.54 describes the resource URI structure of Nausf_UEAuthentication API. (ii) AUSF SoR Protection Service This service supports several service operations as shown in Figure 3.55. The call flow diagram of the Nausf_SoRProtection Service Operations is shown in Figure 3.56: The Nausf_SoRProtection service uses the Nausf_SoRProtection API. The following is the format that must be used for the request URI in an HTTP request from an NF services consumer to an NF service producer: {apiR​oot}/​/​{apiV​ersio​n}/ Where the must be fixed to “nausf-sorprotection” and the {apiVersion} must be fixed to “v1”.

5G Service-Based Architecture, Protocol Stack, and Interoperation

215

FIGURE 3.57  Nausf_SoRProtection Service API’s resource URI format.

FIGURE 3.58  AUSF UPU Protection Service operations.

FIGURE 3.59  Call flow diagram of the AUSF UPU Protection Service operations.

Figure 3.57 describes the resource URI structure of Nausf_SoRProtection API. (iii) AUSF UPU Protection Service This service supports several service operations as shown in Figure 3.58. The call flow diagram of the Nausf_UPUProtection Service Operations is shown in Figure 3.59: The Nausf_UPUProtection service uses the Nausf_UPUProtection API. The following is the format that must be used for the request URI in an HTTP request from an NF services consumer to an NF service producer: {​apiRo​ot}//{​apiVe​rsion​}/​

Where the must be fixed to “nausf-upuprotection” and the {apiVersion} must be fixed to “v1”. Figure 3.60 describes the resource URI structure of Nausf_UPUProtection API. (c) 5G Equipment Identity Register (5G EIR) The 5G EIR is used to check whether an equipment’s identity has not been blacklisted [25]. The reference model is shown in Figure 3.61. The reference point N17

216

5G NR Modeling in MATLAB®

FIGURE 3.60  Nausf_UPUProtection Service API’s resource URI format.

FIGURE 3.61  Reference model—5G EIR.

shows the interaction between 5G EIR and the enabling the check of the status of the mobile equipment identity. The 5G EIR supports the following main services [25]: (i) N5g-eir_EquipmentIdentityCheck. This service is used to check whether the Permanent Equipment Identifier is in the blacklist. (i) EIR Equipment Identity Check Service This service supports several service operations as shown in Figure 3.62. The call flow diagram of the N5g-eir_EquipmentIdentityCheck Service Operations is shown in Figure 3.63: The N5g-eir_EquipmentIdentityCheck service uses the N5g-eir_ EquipmentIdentityCheck API. The following is the format that must be used for the request URI in an HTTP request from an NF services consumer to an NF service producer: {​apiRo​ot}//{​apiVe​rsion​}/​

Where the must be fixed to “n5g-eir-eic” and the {apiVersion} must be fixed to “v1”.

217

5G Service-Based Architecture, Protocol Stack, and Interoperation

FIGURE 3.62  EIR Equipment Identity Check Service operations.

FIGURE 3.63  Call flow diagram of the EIR Equipment Identity Check Service operations.

FIGURE 3.64  N5g-eir_EquipmentIdentityCheck Service API’s resource URI format.

FIGURE 3.65  Reference model—PCF.

Figure 3.64 describes the EquipmentIdentityCheck API.

resource

URI

structure

of

N5g-eir_

3.1.3 5G Core Policy Management Services The Policy Management service include two main classes of services and SBIs described as follows:

218

5G NR Modeling in MATLAB®

(a) Policy Charging and Control Function (PCF) The reference model of CHF is shown in Figure 3.51. More details about the PCF are given in Section 3.2. (b) Charging Function (CHF) The reference model of CHF is shown in Figure 3.51. The CHF supports the converged charging and offline-only charging service operations as shown in Figures 3.67 and 3.68 [26]. More details about the CHF are given in Section 3.2.

3.1.4 5G Core Shared Environment Services The Shared Environment service includes two main classes of services and SBIs described as follows:

FIGURE 3.66  Reference model—CHF.

FIGURE 3.67  CHF Converged Service operations.

FIGURE 3.68  CHF OFF-LINE Service operations.

5G Service-Based Architecture, Protocol Stack, and Interoperation

219

(a) Unified Data Repository (UDR) The UDR is responsible for the storage and retrieval of subscription data, policy, structured data for exposure and application data. It is also used for subscribing to notification and to notify about subscribed data changes [27]. The reference model is shown in Figure 3.69 The UDR supports the following main services: (i) Nudr_DataRepository. This service permits users of NF services to access, add to, edit, and delete information kept in the UDR. Users of the NF service can opt in or out of receiving data update notifications and subscriptions. (i) UDR Data Repository Service This service supports several service operations as shown in Figure 3.70. The call flow diagram of the Nudr_DataRepository Service Operations is shown in Figure 3.71: The Nudr_DataRepository service uses the Nudr_DataRepository API. The following is the format that must be used for the request URI in an HTTP request from an NF services consumer to an NF service producer: {apiR​oot}/​/​{apiV​ersio​n}/

FIGURE 3.69  Reference model—UDR.

FIGURE 3.70  UDR Data Repository Service operations.

220

5G NR Modeling in MATLAB®

FIGURE 3.71  Call flow diagram of the UDR Data Repository Service operations.

Where the must be fixed to “nudr-dr” and the {apiVersion} must be fixed to “v1”. Figure 3.72 describes the resource URI structure of Nudr_DataRepository API. (b) Unstructured Data Storage Function (UDSF) The UDSF is a repository and retrieval system for unstructured data (data that is not defined in 3GPP specifications). All the NFs in the PLMN may use the same UDSF to save/retrieve data, as it is deployed in the same network as the CP NF. Depending on the operator's settings, an NF may also have its own UDSF [28]. The reference model is shown in Figure 3.73. The UDSF supports the following main services: (i) Nudsf_DataRepository. The UDSF data repository service is made available to the NF service user through this service. The UDSF can be used to store unstructured data by any NF.

5G Service-Based Architecture, Protocol Stack, and Interoperation

FIGURE 3.72  Nudr_DataRepository Service API’s resource URI format.

FIGURE 3.73  Reference model—UDSF

221

222

5G NR Modeling in MATLAB®

(i) UDSF Data Repository Service This service supports several service operations as shown in Figure 3.74. The call flow diagram of the Nudsf_DataRepository Service Operations is shown in Figures 3.75, 3.76, and 3.77:

FIGURE 3.74  UDSF Data Repository Service operations.

FIGURE 3.75  Call flow diagram of the UDSF Data Repository Service operations (Part A).

5G Service-Based Architecture, Protocol Stack, and Interoperation

223

FIGURE 3.76  Call flow diagram of the UDSF Data Repository Service operations (Part B).

The Nudsf_DataRepository service uses the Nudsf_DataRepository API. The following is the format that must be used for the request URI in an HTTP request from an NF services consumer to an NF service producer: {​apiRo​ot}//{​apiVe​rsion​}/​

Where the must be fixed to “nudsf-dr” and the {apiVersion} must be fixed to “v1”. Figure 3.78 describes the resource URI structure of Nudsf_DataRepository API.

224

5G NR Modeling in MATLAB®

FIGURE 3.77  Call flow diagram of the UDSF Data Repository Service operations (Part C).

3.1.5 5G Core Application and Network Exposure Services The Application and Network Exposure service include two main classes of services and service-based interfaces described as follows: (a) Network Exposure Function (NEF) The NEF is a functional element that supplies data about applications and users to those who use NF services. The NF consumer(s) can (un)subscribe to event notifications and will be notified when an event of interest is found in their monitoring [29]. The reference model is shown in Figure 3.79. The NEF supports the Nnef_EventExposure service. This service notifies NF service consumers who have subscribed to receive information about events on the NEF and allows them to subscribe, change, and unsubscribe from application events. (i) NEF Event Exposure Service This service supports several service operations as shown in Figure 3.80.

5G Service-Based Architecture, Protocol Stack, and Interoperation

225

FIGURE 3.78  Nudsf_DataRepository Service API’s resource URI format.

The call flow diagram of the Nnef_EventExposure Service Operations is shown in Figure 3.81: The Nnef_EventExposure service uses the Nnef_EventExposure API. The following is the format that must be used for the request URI in an HTTP request from an NF services consumer to an NF service producer: {​apiRo​ot}//{​apiVe​rsion​}/​

Where the must be fixed to “nnef-eventexposure”. Figure 3.82 describes the resource URI structure of Nnef_EventExposure API. (b) Application Function (AF) The AF notifies NF service consumers which have subscribed to receive notifications about events on the AF and lets them subscribe, edit, and unsubscribe from application events [30]. The reference model is shown in Figure 3.83.

226

5G NR Modeling in MATLAB®

FIGURE 3.79  Reference model—NEF.

FIGURE 3.80  NEF Event Exposure Service operations.

FIGURE 3.81  Call flow diagram of the NEF Event Exposure Service Operations.

5G Service-Based Architecture, Protocol Stack, and Interoperation

227

FIGURE 3.82  Nnef_EventExposure Service API’s Resource URI format.

FIGURE 3.83  Reference model—AF.

FIGURE 3.84  AF Event Exposure Service operations.

The AF supports Naf_EventExposure service [30]: this service notifies NF service customers with a corresponding subscription about events seen on the AF and lets them subscribe, change, and unsubscribe for application events. (ii) AF Event Exposure Service This service supports several service operations as shown in Figure 3.84. The call flow diagram of the Naf_EventExposure Service Operations is shown in Figure 3.85: The Naf_EventExposure service uses the Naf_EventExposure API. The following is the format that must be used for the request URI in an HTTP request from an NF services consumer to an NF service producer:

228

5G NR Modeling in MATLAB®

FIGURE 3.85  Call flow diagram of the AF Event Exposure Service operations.

FIGURE 3.86  Naf_EventExposure Service API’s resource URI format.

{apiR​oot}/​/​{apiV​ersio​n}/ Where the must be fixed to “naf-exposure”. Figure 3.86 describes the resource URI structure of Naf_EventExposure API.

3.1.6 5G Core Network Resource Management Services The Network Resource Management service includes four main classes of services and SBIs described as follows: (a) Network Slice Selection Function (NSSF) To the AMF and NSSF on a different PLMN, the 5GC’s NSSF provides services through its Nnssf SBI. Focusing on the NSSF and the scope of the present specification [31], Figure 3.87 offers the reference model.

5G Service-Based Architecture, Protocol Stack, and Interoperation

229

FIGURE 3.87  Reference model—NSSF

FIGURE 3.88  NSSF NS Selection Service operations.

The NSSF supports the following main services [31]: (i) Nnssf_NSSelection. With this service, both roaming and non-roaming users can retrieve data on their network slices. For the Serving PLMN, this allows the NSSF to supply the AMF with both the Allowed and Configured NSSAI. (ii) Nnssf_NSSAIAvailability. The NF service consumer makes use of this service to modify the S-NSSAI(s) supported by the AMF per TA on the NSSF, to subscribe and unsubscribe to notifications of changes to the NSSAI availability information per TA, and to determine which S-NSSAIs are available per TA (unrestricted) and which SNSSAI(s) are restricted in the PLMN serving the UE's PLMN. (i) NSSF NS Selection ServiceThis service supports several service operations as shown in Figure 3.88. The call flow diagram of the Nnssf_NSSelection Service Operations is shown in Figure 3.89: The Nnssf_NSSelection service uses the Nnssf_NSSelection API. The following is the format that must be used for the request URI in an HTTP request from an NF services consumer to an NF service producer: {​apiRo​ot}//{​apiVe​rsion​}/​

Where the must be fixed to “Nnssf-nsselection”. Figure 3.90 describes the resource URI structure of Nnssf_NSSelection API. (ii) NSSF NSSAI Availability Service This service supports several service operations as shown in Figure 3.91.

230

5G NR Modeling in MATLAB®

FIGURE 3.89  Call flow diagram of the NSSF NS Selection Service operations.

FIGURE 3.90  Nnssf_NSSelection Service API’s resource URI format.

FIGURE 3.91  NSSF NSSAI Availability Service operations.

The call flow diagram of the Nnssf_NSSAIAvailability Service Operations is shown in Figure 3.92: The Nnssf_NSSAIAvailability service uses the Nnssf_NSSAIAvailability API. The following is the format that must be used for the request URI in an HTTP request from an NF services consumer to an NF service producer: {​apiRo​ot}//{​apiVe​rsion​}/​

Where the must be fixed to “nnssf-nssaiavailability” and the {apiVersion} must be fixed to “v1”.

5G Service-Based Architecture, Protocol Stack, and Interoperation

231

FIGURE 3.92  Call flow diagram of the NSSF NSSAI Availability Service operations.

Figure 3.93 describes the resource URI structure of Nnssf_NSSelection API. (b) Network Slice-Specific Authentication and Authorization Function (NSSAAF) When a network slice requires authentication and authorization for a single User Equipment (UE) and S-NSSAI, the AMF must rely upon the NSSAAF service. Slice re-authentication notifications and slice authorization revocation notifications delivered from the AAA-S must be received by the AMF using the NSSAAF service [32]. The reference model is shown in Figure 3.94. The NSSAF supports the following main service [32]: (i) Nnssaaf_NSSAA. Slice-specific authentication and authorization, reauthentication of a given UE, and revocation of slice-specific authorization are handled by this service. (i) NSSAAF NSSAA Service This service supports several service operations as shown in Figure 3.95.

232

5G NR Modeling in MATLAB®

FIGURE 3.93  Nnssf_NSSAIAvailability Service API’s resource URI format.

FIGURE 3.94  Reference model—NSSAAF

The call flow diagram of the Nnssaaf_NSSAA Service Operations is shown in Figure 3.96: The Nnssaaf_NSSAA service uses the Nnssaaf_NSSAA API. The following is the format that must be used for the request URI in an HTTP request from an NF services consumer to an NF service producer: {apiR​oot}/​/​{apiV​ersio​n}/ Where the must be fixed to “nnssaaf-nssaa”. Figure 3.97 describes the resource URI structure of Nnssaaf_NSSAA API. (c) Network Data Analytics Function (NWDAF) The NWDAF provides analytics on network data (such as load levels) and alerts on congestion occurrences in slices [33]. The reference model is shown in Figure 3.98.

5G Service-Based Architecture, Protocol Stack, and Interoperation

233

FIGURE 3.95  NSSAF NSSAA Service operations.

FIGURE 3.96  Call flow diagram of the NSSAF NSSAA Service operations.

The NWDAF supports the following main services [33]: (i) Nnwdaf_EventsSubscription: Instances of network slices can subscribe to and unsubscribe from load events through this service, which then notifies subscribed NF consumers. (ii) Nnwdaf_AnalyticsInfo: With this service, NF users can inquire about the load status of a given network slice instance.

234

5G NR Modeling in MATLAB®

FIGURE 3.97  Nnssaaf_NSSAA Service API’s resource URI format.

FIGURE 3.98  Reference model—NWDAF.

FIGURE 3.99  NWDAF Event Subscription Service operations.

(i) NWDAF Event Subscription Service This service supports several service operations as shown in Figure 3.99. The call flow diagram of the Nnwdaf_EventsSubscription Service Operations is shown in Figure 3.100: The Nnwdaf_EventsSubscription service uses the Nnwdaf_EventsSubscription API. The following is the format that must be used for the request URI in an HTTP request from an NF services consumer to an NF service producer: {​apiRo​ot}//{​apiVe​rsion​}/​

Where the must be fixed to “nnwdaf-eventssubscription” and the {apiVersion} must be fixed to “v1”. Figure 3.101 describes the resource URI structure of Nnwdaf_EventsSubscription API.

5G Service-Based Architecture, Protocol Stack, and Interoperation

235

FIGURE 3.100  Call flow diagram of the NWDAF Event Subscription Service operations.

FIGURE 3.101  Nnwdaf_EventsSubscription Service API’s resource URI format.

FIGURE 3.102  NWDAF Analytics Info Service operations.

(ii) NWDAF Analytics Info Service This service supports several service operations as shown in Figure 3.102. The call flow diagram of the Nnwdaf_AnalyticsInfo Service Operations is shown in Figure 3.103: The Nnwdaf_AnalyticsInfo service uses the Nnwdaf_AnalyticsInfo API. The following is the format that must be used for the request URI in an HTTP request from an NF services consumer to an NF service producer:

236

5G NR Modeling in MATLAB®

FIGURE 3.103  Call flow diagram of the NWDAF Analytics Info Service operations.

FIGURE 3.104  Nnwdaf_AnalyticsInfo Service API’s resource URI format. {​apiRo​ot}//{​apiVe​rsion​}/​

Where the must be fixed to “nnwdaf-analyticsinfo” and the {apiVersion} must be fixed to “v1”. Figure 3.104 describes the resource URI structure of Nnwdaf_AnalyticsInfo API. (d) Network Repository Function (NRF) The NRF keeps track of which services are supported by each NF instance and which services are supported by each SCP instance. The registration of new NF instances of a specific kind in NRF can be monitored by other NF or SCP instances which subscribe to receive such notifications. In addition, SCP instances can subscribe to NRF to be alerted whenever a new SCP instance is registered [34]. It also has the capability of discovering new services. Instances of NF and SCP can send NF Discovery Requests to it, and it will respond with details about the available NF instances that meet their requirements. The SCP discovery feature is also supported. It takes in requests from other SCP instances for profile information and returns a list of those that meet the specified criteria [34]. The reference model is shown in Figure 3.105. The UDM supports the following main services [34]: (i) Nnrf_NFManagement. An NF or SCP Instance in the providing PLMN can use this service to register, modify, or deregister its profile with the NRF. In addition, a profile in one NRF can be registered, updated, or deleted in another NRF within the same PLMN. An NF or SCP can also sign up for alerts on new or updated NF Instances, profile changes, and the availability of associated services. It also allows SCP instances to subscribe for notifications of other SCP instances’ registration, deregistration, and profile updates.

5G Service-Based Architecture, Protocol Stack, and Interoperation

237

FIGURE 3.105  Reference model—NRF.

(ii) Nnrf_NFDiscovery. Using this service, an NF or SCP Instance can learn about other NF Instances in the area and the services they may provide by querying the nearby NRF. A SCP can use the Nnrf NFDiscovery service to find other SCP instances. Additionally, it enables a PLMN NRF to re-issue a discovery request to another PLMN NRF. (iii) Nnrf_AccessToken. This service provides a “Token Endpoint” for NF Service Consumers to use in order to make requests for the Access Token Request service. (iv) Nnrf_Bootstrapping. This service informs NF Service Consumers of the NRF about the supported service endpoints using a version-independent URI that may be accessed without first utilizing a Discovery service to locate it. This service is required whenever the PLMN-A NRF has to invoke services from the PLMN-B NRF without any prior knowledge of the version of the services installed in PLMN-B. To avoid statically configuring information about the service versions disseminated in the NRF in the multiple NFs, this service may also be used in intra-PLMN scenarios. (i) NRF NF Management Service This service supports several service operations as shown in Figure 3.106. The call flow diagram of the Nnrf_NFManagement Service Operations is shown in Figure 3.107: The Nnrf_NFManagement service uses the Nnrf_NFManagement API. The following is the format that must be used for the request URI in an HTTP request from an NF services consumer to an NF service producer: {​apiRo​ot}//{​apiVe​rsion​}/​

238

5G NR Modeling in MATLAB®

FIGURE 3.106  NRF NF Management Service operations.

Where the must be fixed to “nnrf-nfm” and the {apiVersion} must be fixed to “v1”. Figure 3.108 describes the resource URI structure of Nnrf_NFManagement API. (ii) NRF NF Discovery Service This service supports several service operations as shown in Figure 3.109. The call flow diagram of the Nnrf_NFDiscovery Service Operations is shown in Figure 3.110: The Nnrf_NFDiscovery service uses the Nnrf_NFDiscovery API. The following is the format that must be used for the request URI in an HTTP request from an NF services consumer to an NF service producer: {​apiRo​ot}//{​apiVe​rsion​}/​

Where the must be fixed to “nnrf-disc” and the {apiVersion} must be fixed to “v1”. Figure 3.111 describes the resource URI structure of Nnrf_NFDiscovery API. (iii) NRF Access Token Service This service supports several service operations as shown in Figure 3.112. The call flow diagram of the Nnrf_AccessToken Service Operations is shown in Figure 3.113: The Nnrf_AccessToken service uses the Nnrf_AccessToken API. The following is the format that must be used for the request URI in an HTTP request from an NF services consumer to an NF service producer:

1. {nrfA​piRoo​t}/oa​uth2/​

Figure 3.114 describes the resource URI structure of Nnrf_AccessToken API. (iv) NRF Bootstrapping Service This service supports several service operations as shown in Figure 3.115.

5G Service-Based Architecture, Protocol Stack, and Interoperation

239

FIGURE 3.107  Call flow diagram of the NRF NF Management Service operations.

The call flow diagram of the Nnrf_Bootstrapping Service Operations is shown in Figure 3.116: The Nnrf_Bootstrapping service uses the Nnrf_Bootstrapping API. The following is the format that must be used for the request URI in an HTTP request from an NF services consumer to an NF service producer:

240

5G NR Modeling in MATLAB®

FIGURE 3.108  Nnrf_NFManagement Service API’s resource URI format.

FIGURE 3.109  NRF NF Discovery Service operations.

FIGURE 3.110  Call flow diagram of the NRF NF Discovery Service operations.

FIGURE 3.111  Nnrf_NFDiscovery Service API’s resource URI format.

5G Service-Based Architecture, Protocol Stack, and Interoperation

FIGURE 3.112  NRF Access Token Service operations.

FIGURE 3.113  Call flow diagram of the NRF Access Token Service operations.

FIGURE 3.114  Nnrf_AccessToken Service API’s resource URI format.

FIGURE 3.115  NRF Bootstrapping Service operations.

FIGURE 3.116  Call flow diagram of the NRF Bootstrapping Service operations.

241

242

5G NR Modeling in MATLAB®

FIGURE 3.117  Nnrf_Bootstrapping Service API’s resource URI format.

FIGURE 3.118  Reference model—LMF.

{nrfA​piRoo​t}/ Figure 3.117 describes the resource URI structure of Nnrf_Bootstrapping API.

3.1.7 5G Core Location Services The Location service includes two main classes of services and SBIs described as follows: (a) Location Management Function (LMF) The LMF provides location measurements in the uplink from the NG RAN and nonUE associated support data, as well as downlink location measurements from the UE or an estimate of its location. It also relays cipher keys to an AMF and broadcasts assistance data to UEs [35]. The reference model is shown in Figure 3.118. The LMF supports the following main services [35]: (i) Nlmf_Location. This service allows an NF to obtain location determination (current geodetic and optionally civic location) for a specific UE or to request location determination at regular intervals or in response to an event. (ii) Nlmf_Broadcast. In order to send encrypted location assistance data to subscriber UEs, an NF can use this service to receive the necessary ciphering keys and associated settings.

5G Service-Based Architecture, Protocol Stack, and Interoperation

243

(i) LMF Location Service This service supports several service operations as shown in Figure 3.119. The call flow diagram of the Nlmf_Location Service Operations is shown in Figure 3.120: The Nlmf_Location service uses the Nlmf_Location API. The following is the format that must be used for the request URI in an HTTP request from an NF services consumer to an NF service producer: {apiR​oot}/​/​{apiV​ersio​n}/ Where the must be fixed to “nlmf-loc”. Figure 3.121 describes the resource URI structure of Nlmf_Location API.

FIGURE 3.119  LMF Location Service operations.

FIGURE 3.120  Call flow diagram of the LMF Location Service operations.

244

5G NR Modeling in MATLAB®

FIGURE 3.121  Nlmf_Location Service API’s Resource URI format.

FIGURE 3.122  LMF Broadcast Service operations.

FIGURE 3.123  Call flow diagram of the LMF Broadcast Service operations.

(ii) LMF Broadcast Service This service supports several service operations as shown in Figure 3.122 The call flow diagram of the Nlmf_Broadcast Service Operations is shown in Figure 3.123: The Nlmf_Broadcast service uses the Nlmf_Broadcast API. The following is the format that must be used for the request URI in an HTTP request from an NF services consumer to an NF service producer:

5G Service-Based Architecture, Protocol Stack, and Interoperation

245

{apiR​oot}/​/​{apiV​ersio​n}/ Where the must be fixed to “nlmf-broadcast”. Figure 3.124 describes the resource URI structure of Nlmf_Broadcast API. (b) Gateway Mobile Location Centre (GMLC) In the 5GC, Location Services are supported by the GMLC, a network entity. Ngmlc is a service-based interface that the GMLC uses within the 5GC to provide services to the AMF, GMLC, and NEF [36]. The GMLC is the primary emphasis of the reference model shown in Figure 3.125. The GMLC supports the following main services: (i) Ngmlc_Location. The consumer NF can use this service to check a target UE’s current geodetic and optionally civic location, subscribe or unsubscribe to receiving updates on the location of that UE in response to the detection of specific events, terminate any active periodic or triggered location requests for that UE, and receive updates on the location of that UE in response to the detection of specific events. (i) GMLC Location Service This service supports several service operations as shown in Figure 3.126. The call flow diagram of the Ngmlc_Location Service Operations is shown in Figure 3.127:

FIGURE 3.124  Nlmf_Broadcast Service API’s resource URI format.

FIGURE 3.125  Reference model—GMLC.

246

5G NR Modeling in MATLAB®

FIGURE 3.126  GMLC Location Service operations.

FIGURE 3.127  Call flow diagram of the GMLC Location Service operations.

The Ngmlc_Location service uses the Ngmlc_Location API. The following is the format that must be used for the request URI in an HTTP request from an NF services consumer to an NF service producer: {​apiRo​ot}//{​apiVe​rsion​}/​

Where the must be fixed to “ngmlc-loc”. Figure 3.128 describes the resource URI structure of Ngmlc_Location API. (c) Cell Broadcast Centre Function (CBCF) Details about the CBCF are given in Section 2.

5G Service-Based Architecture, Protocol Stack, and Interoperation

247

FIGURE 3.128  Ngmlc_Location Service API’s resource URI format.

FIGURE 3.129  Reference model—BSF.

3.1.8 5G Core Signaling Services The signaling services include one main class of services and SBIs described as follows: (a) Binding Support Function (BSF) The BSF offers a PDU session-binding feature, which directs requests from AF to the correct PCF in charge of the requested PDU Session [37]. The reference model is shown in Figure 3.129. The BSF supports the following main service [37]: (i) Nbsf_Management. NF services consumers can use this service to sign up for bindings, modify existing bindings, delete bindings, and retrieve binding information. This service supports several service operations as shown in Figure 3.130

248

5G NR Modeling in MATLAB®

FIGURE 3.130  BSF NF Management Service operations.

FIGURE 3.131  Call flow diagram of the BSF NF Management Service operations.

The call flow diagram of the Nbsf_NFManagement Service Operations is shown in Figure 3.131: The Nbsf_NFManagement service uses the Nbsf_NFManagement API. The following is the format that must be used for the request URI in an HTTP request from an NF services consumer to an NF service producer: {​apiRo​ot}//{​apiVe​rsion​}/​

Where the must be fixed to “nbsf-management”. Figure 3.132 describes the resource URI structure of Nbsf_NFManagement API.

3.2 5G PROTOCOL STACK 3.2.1 Control Plane Protocol Stack The overall structure of the control plane protocol stack of 5G is shown in Figure 3.133 [38, 39]. There are two parts to N1’s NAS protocol: NAS-MM and NAS-SM. 3.2.1.1 5G Non-Access Stratum (NAS) Protocols NAS is made up of two fundamental protocols—the 5G NAS Mobility Management (NAS -MM) protocol and the 5G NAS Session Management (5G NAS-SM)

5G Service-Based Architecture, Protocol Stack, and Interoperation

249

FIGURE 3.132  Nbsf_NFManagement Service API’s resource URI format.

FIGURE 3.133  Overall structure of the 5G control plane protocol stack.

protocol—that allow for the aforementioned features to be supported. The NAS-MM protocol is the foundational NAS protocol that handles UE registrations, mobility, security, and transmission of the NAS-SM protocol and other sorts of messages between the UE and the AMF. Connectivity management for PDU Sessions is handled by the NAS-SM protocol, which is transmitted between the UE and the SMF (via the AMF). The NAS-MM protocol is used to transport it. Information is also transferred between UE and PCF, UE and SMSF, etc. via the NAS-MM protocol, as depicted in Figure 3.134. In N1 NAS, the UE only establishes a single signaling connection per access. An endpoint for N1 can be found in AMF. All messages and processes associated with a UE’s SM are transmitted via the same N1 NAS signaling link that is used for Registration Management and Connection Management (RM/CM). The UE’s whereabouts, the UE’s authenticity, and the UE’s protection and ciphering of its data are all managed with the help of NAS-MM protocols. Using these steps, the network can provide the UE with a new temporary identifier (5G Global

250

5G NR Modeling in MATLAB®

FIGURE 3.134  NAS protocol stack with NAS-MM and NAS-MM protocols [38].

Unique Temporary Identifier (GUTI)) and also inquire about the UE’s identification (using Subscription Concealed Identifier (SUCI) and Permanent Equipment Identifier (PEI)). In addition, the UE’s capability information is communicated to the network via the 5GMM protocols, and the network may supply the UE with details on certain services. Therefore, the NAS-MM protocol differs from the NAS-SM protocol in that it functions at the UE level (per Access Type). The following are the fundamental steps involved in the NAS-MM communication between the UE and the AMF [38, 39]: • • • • • • • • • • •

Registration. Deregistration. Authentication. Security mode control. Service request. Notification. Uplink NAS transport. Downlink NAS transport. UE configuration update. UE identity request. The User Plane’s PDU Sessions and QoS are controlled by NAS-SM processes. Establishing and terminating PDU Sessions, as well as making changes to PDU Sessions in order to add, remove, or alter QoS rules, all fall under this category. The secondary authentication for a PDU Session is likewise performed using the NAS-SM methods. The NAS-SM protocol, in contrast to the NAS-MM standard, operates at the PDU Session level. The fundamental NAS-SM procedures are as follows:

5G Service-Based Architecture, Protocol Stack, and Interoperation

• • • • •

251

PDU Session establishment. PDU Session release. PDU Session modification. PDU Session authentication and authorization. 5GSM status (to exchange PDU Session status information).

3.2.1.2 UE to gNB Protocols 5G New Radio transmits data over a wide range of physical frequencies. These channels convey both User Plane (UP) and Control Plane (CP) information. The 5G NR protocol stack, on the other hand, consists of multiple layers, each of which communicates with its peer at a different level of abstraction. Unlike lower-layer PDUs, higher-layer PDUs are not directly mapped to the Physical Layer (PHY) for transmission. Instead, PDUs at a given layer are mapped to channel types appropriate to the level of functionality and abstraction at which they are being sent. Logical channels are used to carry Radio Link Control’s (RLC) PDUs to the Media Access Control (MAC), while transport channels are used to carry MAC’s PDUs to the PHY. We can streamline the stack’s design and development with the aid of channels. Prioritizing and optimizing a channel can be done in a variety of ways. Although some uplink and downlink channels share the same nomenclature, they serve different purposes [40]. Figure 3.135 depicts the three primary channels and their respective features. Figures 3.136 and 3.137 show the layers and channel mappings of the 5G downlink and uplink transmission system [41]. (i) Radio Resource Control (RRC) Connection and setup, security configuration, mobility management, and system configuration are all control-plane protocols that make up the RRC layer. Information applicable to UEs in the RRC CONNECTED state, such as common

FIGURE 3.135  Types of channels in 5G NR.

252

5G NR Modeling in MATLAB®

FIGURE 3.136  Layers and channel mapping for the 5G downlink transmission.

FIGURE 3.137  Layers and channel mapping for the 5G uplink transmission.

channel configuration information [42, 43], is also broadcast, along with NAS common control information and information applicable to UEs in the RRC IDLE and RRC INACTIVE states, such as cell selection/reselection parameters and neighboring cell information.

5G Service-Based Architecture, Protocol Stack, and Interoperation

253

The following are RRC connection control functions: • Estab​lishm​ent/m​odifi​catio​n /sus​pensi​on/re​sumpt​ion/r​eleas​e of RRC connections including assignment/modification of UE identity. • Paging. • Access barring. • Establishment, modification, suspension, resumption, and release of Signaling Radio Bearers (SRBs) except SRB0. • Initial security activation including initial configuration of AS integrity protection (SRBs, DRBs), and AS ciphering (SRBs, DRBs). • Mobility Management including handling of security-related tasks, such as key or algorithm changes, and the specification of RRC context data that is exchanged between network nodes. • Establishment, modification, suspension, resumption, and release of radio bearers carrying user data (DRBs); radio configuration control including assignment/modification of ARQ configuration, HARQ configuration, and DRX configuration. SRBs are used to communicate RRC messages to UEs; these messages are built on the same set of protocol layers as user-plane packet processing (with the exception of the Service Data Adaptation Protocol (SDAP) sublayer). Once the link is created, the SRBs are mapped to the Dedicated Control Channel (DCCH) from the Common Control Channel (CCCH). The MAC layer allows for multiplexing of control-plane and user-plane data for transmission to the endpoint inside the same Transmission Time Interval (TTI). SRBs are defined as dedicated radio bearers for the exclusive use of sending RRC and NAS communications. In particular, the new radio has defined the following four categories of SRBs: • SRB0 for RRC communications over the CCCH channel. • SRB1 for RRC communications that may have a piggybacked NAS message, and for NAS messages before SRB2 is established using DCCH logical channel. • SRB2 for NAS messages using DCCH logical channel (SRB2 has a lower priority than SRB1 and may be configured by the network after security activation). • SRB3 for designated RRC communications while the UE is operating in EN-DC mode and using the DCCH logical channel. Bearer establishment/ modification/release are the sole downlink purposes served by piggybacking of NAS messages. Only the first NAS messages sent during connection setup and connection resuming are transferred via piggybacking of NAS messages in the uplink. There is no RRC protocol control information in the NAS messages that are transmitted using SRB2. The Packet Data Convergence Protocol (PDCP) sublayer provides integrity protection and encrypts all RRC messages on SRB1, SRB2, and SRB3 once security is

254

5G NR Modeling in MATLAB®

enabled, regardless of whether or not they contain NAS contents. The NAS encrypts and protects its messages’ integrity on its own [43]. The System Information (SI) is broken down into two categories—minimum SI and other SI—and features both a Master Information Block (MIB) and several SIBs. The minimum SI includes the bare essentials that UEs need to get access and acquire any additional SI. The MIB is part of the minimum SI and includes the cellbarred status information and necessary PHY information of the cell that UEs need to get additional SI. The MIB is occasionally aired on BCH. SIB1 is also part of the minimal SI because it specifies when the other SIBs will be accessed for the first time and provides other crucial information for that purpose. The SIB1, which is also known as the Remaining Minimal System Information (RMSI), is transmitted to UEs in the RRC CONNECTED state by periodic broadcast on DL-SCH or specialized transmission on DL-SCH. All SIBs not included in the required minimum SI broadcast fall within the other SI’s purview. These SIBs can be provided to UEs in RRC CONNECTED state either in a periodic broadcast on DL-SCH, an on-demand broadcast on DL-SCH in response to a request from UEs in RRC IDLE or RRC INACTIVE state, or in a dedicated manner on DL-SCH. These SIBs make up the remainder of the other SI [44]: • SIB2 provides data on the serving cell’s reselection status. • SIB3 includes both frequency-wide and cell-specific cell reselection parameters, as well as information regarding the serving frequency and intrafrequency neighbor cells. • SIB4 includes common cell reselection parameters for a frequency as well as cell-specific reselection parameters, information about neighboring frequencies in the NR, and information about cells that are inter-frequency neighbors. • SIB5 includes both frequency-wide and cell-specific reselection parameters for cell reselection, as well as information about E-UTRA frequencies and neighbor cells. • SIB6 contains an Earthquake and Tsunami Warning System (ETWS)7 primary notification. • SIB7 contains an ETWS secondary notification. • SIB8 contains a Commercial Mobile Alert System (CMAS)8 warning notification. • SIB9 includes data on Coordinated Universal Time (UT) and the Global Positioning System (GPS). The RRC sublayer is controlled by a state machine that specifies the possible states a UE can be in at any one time. A new RRC state, RRC INACTIVE, has been introduced in NR alongside the familiar RRC CONNECTED and RRC IDLE states from LTE. A UE, as depicted in Figure 3.138, enters a disconnected and idle state after it is turned on. However, once initial access and an RRC connection have been established, the UE can switch to the connected state. After a short period of inactivity, the UE will put its current session on hold and enter inactive mode. However, it is

FIGURE 3.138  NR UE states.

5G Service-Based Architecture, Protocol Stack, and Interoperation

255

256

5G NR Modeling in MATLAB®

possible to continue working on the session by switching to the connected mode. 5G services and applications vary in their specifics. It was crucial to provide a new RRC state machine and a dormant state in order to decrease the control-plane latency in order to suit the needs of various services. Devices providing Ultra-Reliable LowLatency Communication (URLLC) services must maintain a low-activity state and periodically transmit uplink data and/or status reports with small payloads to the network because these services are characterized by the transmission of frequent/ infrequent small packets that require very low latency and high reliability. Downlink small packet transfers are also required on an as-needed or as-required basis. From either the RRC connected or RRC inactive states, a UE can transition to the RRC idle mode. Due to the lack of cell registration and UE context in the radio access network, communication between the device and the network is impossible while in the RRC IDLE state. From the CN’s point of view, the device is in the CM-IDLE state where no data transfer can take place because the device is in sleep mode to conserve battery life. The UEs in idle mode will occasionally awaken to check for network-sent paging messages. Cell reselection is used to control the user’s mobility in this mode. Due to the breakdown in uplink synchronization that occurs in the idle mode, the UE must undergo a random-access operation before entering the connected mode. At the RRC CONNECTED stage, the device and the network have both established the UE context. From the CN’s point of view, the device has successfully registered with the network and is now in the CM-CONNECTED state. In NG-RAN, the UE is identified through its cell affiliation and a temporary identifier known as the C-RNTI when it is in connected mode. While data transfers to and from the device are the primary function of the connected mode, a DRX cycle can be set up when the device is not in use to lower the UE’s power consumption. The time it takes to switch from DRX mode to connected mode and begin data transfer is reduced thanks to the fact that the gNB already has a context for the UE. The network controls mobility in this setting. In order for the network to advise the device to undertake a handover, the device must send information about its neighbor cells. In RRC INACTIVE, the RRC context is maintained in both the device and the gNB, but the UE may lose uplink synchronization and need to run a random-access process to be synchronized. From the perspective of the core network, the device is also in a connected state (CM CONNECTED). So, getting into a linked state where data may be sent quickly is possible. There is no requirement for signaling at the network’s core. Transitions from inactivity to activity can be managed by the radio-access network, and the RRC context is already in place. Mobility is handled locally, via cell reselection, thus no network interaction is required, while the device is permitted to sleep similarly to the idle state. Because of this, RRC INACTIVE can be thought of as a combination of the disconnected and active statuses [45]. (ii) Packet Data Convergence Protocol (PDCP) Sequence numbering; encrypting, decrypting, and protecting data integrity; transferring data from one control plane to another; reordering and detecting duplicates; delivering duplicates in sequence; duplicating PDCP PDUs; and signaling duplicate

5G Service-Based Architecture, Protocol Stack, and Interoperation

257

discard to lower layers are all core services provided by the PDCP sublayer. For each radio bearer, the PDCP first compresses the IP header (which is optional) and then encrypts the data. A PDCP header is appended, including information essential for decoding on the other end, as well as a sequence number utilized for retransmission and in-sequence delivery [42, 44]. Figure 3.139 shows the functional overview of the PDCP layer. The discard timer and a COUNT are both initiated by the PDCP entity on the transmit side for each PDCP SDU. It encrypts IP packets to safeguard user privacy and provides integrity protection for control-plane messages to guarantee the authenticity and integrity of control messages. It also compresses packet headers in the user plane. Depending on whether the total data volume is below or above the preset threshold, the PDCP PDU will be sent to either the RLC primary path or the secondary path if the split bearer is set up. The entity that receives PDCP does the decryption and decompression work based on the COUNT value of the PDCP it has received. In addition to sequentially delivering packets, the PDCP eliminates duplicate PDUs. The source gNB’s PDCP sublayer will forward any downlink PDUs that were not delivered to the UE prior to the handover to the peer entity of the target gNB. If any uplink packets fail to reach the gNB, the device’s PDCP entity will resend them after flushing the HARQ buffers during handover. In this circumstance, some PDUs may be received in duplicate

FIGURE 3.139  PDCP Transmission and Reception [46].

258

5G NR Modeling in MATLAB®

form, possibly from both the source and the target gNBs. In this situation, duplicates will be deleted by the PDCP. To guarantee sequential delivery of SDUs to upperlayer protocols, the PDCP entity might be set to rearrange them [42]. PDCP also has a significant impact on the development of dual connectivity. Devices with dual connectivity are linked to both the Master Cell Group (MCG) and the Secondary Cell Group (SCG). Different gNBs can deal with the two types of cells. In most cases, only one cell group is responsible for a given radio carrier, however, in the situation of split bearers, responsibility for a given radio bearer would be shared by both cell groups. As shown in Figure 3.140, the PDCP is responsible for passing information from the MCG to the SCG in this scenario [41]. (iii) Radio Link Control (RLC) The RLC layer of the 5G NR protocol stack communicates with both the PDCP and MAC layers. It interfaces to PDCP via RLC channels and to MAC via logical channels. Each RLC channel’s SDUs are assigned to a single logical channel in a one-to-one mapping.​ When using NR sidelink communication, one 5G UE’s RLC entity will communicate with its peer RLC entities in the gNB or other UEs. Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM) are the three possible transmission modes for an RLC entity. Various capabilities are available in various modes. The requirements of the higher layer service dictate the mode, which is specified by RRC. Multiple RLC organizations are permitted in the RLC sublayer. All entities fall under one of several modes. RLC PDUs are sent from an RLC entity to MAC via a logical channel and RLC SDUs are received from PDCP over an RLC channel in the transmit direction. The TM version of an RLC PDU omits the header but includes the RLC SDU.

FIGURE 3.140  PDCP for sual connectivity with split bearer.

5G Service-Based Architecture, Protocol Stack, and Interoperation

259

Each TM and UM RLC entity can be set up to send or receive data. The AM RLC entity is a bidirectional transmitter and receiver. Thus, TM and UM RLC entities are unidirectional and AM RLC entity is bidirectional. For each RLC entity, there is a corresponding PDCP entity. However, there is a limit of eight RLC entities which a single PDCP entity can transmit its PDUs. For instance, two UM RLC entities (one for transmission and one for reception) are mapped to a bidirectional PDCP object. Some examples of situations in which a PDCP entity translates to several RLC entities include Dual Connectivity (DC), Dual Active Protocol Stack (DAPS), and PDCP duplication [47]. The BCCH, SBCCH, PCCH, and DL/UL CCCH logical channels are all transmitted over the TM. System broadcast, sidelink broadcast, paging, and SRB0 signaling all fall under this category. The DL/UL DTCH, SCCH, and STCH logical channels are all usable in UM. AM is used for any signals not originating from SRB0. DL/UL DCCH is the related logical channel. This mode also carries user aircraft traffic on DL/UL DTCH. SCCH and STCH are sidelink logical channels that are allowed in AM. As a result, SRBs are assigned to either TM (SRB0) or AM (non-SRB0). Data Radio Bearers (DRBs) are mapped by RRC signaling to either UM or AM. The main functions of 5G NR RLC are summarized in Table 3.4. Upper-layer PDUs can be transmitted in all three ways. The simplest form of TM entity is the RLC. There are no new RLC SDUs for the header or segments added. A RLC SDU can also function as a PDU. Each RLC PDU is subdivided into SDUs and given a header by the UM RLC entity. In the receiving direction, the entity puts the pieces back together to send an

FIGURE 3.141  Overview model of 5G NR RLC [47].

260

5G NR Modeling in MATLAB®

TABLE 3.4 5G NR RLC Functions Functions Transfer of upper layer PDUs Error Correction through ARQ Segmentation and reassembly of RLC SDUs Re-segmentation of RLC SDU segments Duplicate Detection RLC SD discard RLC re-establishment Protocol error detection Group cast and broadcast on sidelink RLC header RLC control PDU

TM Yes

UM

AM

Yes

Yes

Yes

Yes

Yes Yes Yes Yes

Yes Yes Yes Yes Yes Yes Yes Yes Yes

RLC SDU in its whole to the higher layers. Based on the Sequence Number (SN), reassembly window size, and reassembly period, the receiving entity may discard RLC segments and SDUs. Error correction via ARQ is a crucial characteristic of AM RLC entities. STATUS PDUs require feedback from the receiving entity. If a PDU was not received correctly, the sending entity will be instructed to send it again. Thus, an AM RLC entity is distinguished by its ability to send data in both directions, acknowledge receipt of data, and retransmit data. It has the ability to identify and filter out duplicate PDUs. Like the UM RLC entity, it has the ability to divide, reassemble, and discard data. Additionally, before retransmitting, an AM RLC entity can resegment segments that were previously lost or incorrect. One of the most important roles of RLC is segmentation, which is depicted in Figure 3.142. The analogous LTE feature, which allows for concatenation, is also shown in the diagram. A scheduler chooses a Transport Block (TB) size, or quantity, of data to move based on its priorities. As part of NR’s general low latency design, the device learns of the scheduling decision in the instance of an uplink transmission only seconds or even Orthogonal Frequency Division Multiplexing (OFDM) symbols before transmission. LTE concatenation fails to meet the low-latency requirement of NR because the RLC PDU cannot be constructed before the scheduling decision is known. This adds time to the uplink transmission. Once the scheduling decision is received, the device merely needs to forward the appropriate number of RLC PDUs to the MAC layer, the number depending on the scheduled TB size. This is made possible by removing the concatenation from RLC. The final RLC PDU may include a piece of an SDU in order to completely fit the TB size. The process of segmentation is straightforward. The device modifies the header to indicate it is a segmented SDU [39, 41, 42] once it receives the scheduling grant and inserts the necessary data to fill the TB.

5G Service-Based Architecture, Protocol Stack, and Interoperation

261

FIGURE 3.142  LTE and NR RLC segmentation.

The RLC retransmission technique also ensures that data reach higher layers without interruption. This is done by utilizing a retransmission procedure between the receiver and transmitter RLC entities. The receiving RLC can detect dropped packets by checking the sequence numbers in the packets’ headers (the RLC sequence number is independent of the PDCP sequence number). The transmitting RLC entity receives status reports and is prompted to resend any PDUs that went unreceived. The RLC entity at the transmitter can retransmit the lost PDUs based on the status report it receives. Error-free delivery is typically handled by the MAC-based hybrid-ARQ protocol, even though the RLC can manage transmission problems due to noise, unforeseen channel variations, etc. (iv) Media Access Control (MAC) The PHY and RLC are the two layers that the MAC sublayer of the 5G NR protocol stack interfaces with. It establishes a connection between the logical and physical transmission of data. As can be seen in Figure 3.143, the distinction between logical and transport channels centers on the nature of the data being transmitted. Information sent via a transport medium is organized into TBs, the structure of which is specified by a given Transport Format (TFs). A transport unit is size can change on the fly. The Transmission Time Interval (TTI) is the time period during which the MAC sends just one TB. RRC layer controls MAC settings. Typically, only one MAC entity exists per UE. The existence of numerous MAC entities on a single UE is, nonetheless, possible. In TS 38.321 [48], the MAC sublayer is defined from the user equipment's point of view.

262

5G NR Modeling in MATLAB®

FIGURE 3.143  Architecture of 5G NR MAC sublayer in the UE.

For NR, the following logical-channel kinds are defined: Broadcast Control Channel (BCCH) serves to broadcast system-level data from the network to all cell-level devices. A device must first acquire the system information in order to learn how the system is configured and, more generally, how to act properly within a cell before it can access the system. The BCCH used to transmit Master Information Blocks (MIBs) is mapped onto the BCH used for the Physical Broadcast Channel (PBCH). Physical Downlink Shared Channel (PDSCH) is mapped onto Downlink Control Channel (BCCH) for System Information Blocks (SIBs). Be aware that there is no BCCH and only LTE system information is available in a non-standalone configuration. Paging Control Channel (PCCH) allows devices whose location within a cell cannot be determined by the network to be paged. Therefore, the paging message must be sent across more than one cell. In the case of non-standalone operation, the LTE system handles paging instead of the PCCH. Common Control Channel (CCCH) is used by a UE during first access when no RRC connection exists. The Dedicated Control Channel (DCCH) and the Dedicated Traffic Channel (DTCH) become available to the UE once the connection has been made. Dedicated Control Channel (DCCH) serves to transmit and receive commands between devices. Both the downlink and the uplink feature this dedicated channel for sending and receiving device-specific setup data and handover messages. SRB1, SRB2, and SRB3 are associated to DCCH1, DCCH2, and DCCH3 respectively in Figures 3.136 and 3.137. Dedicated Traffic Channel (DTCH) serves to transmit information to and from a user’s device. All uplink and downlink user data is transmitted via this

5G Service-Based Architecture, Protocol Stack, and Interoperation

263

logical channel type. DRBs 1 to 5 are associated to DTCH 1 to 5 respectively in Figures 3.136 and 3.137. The MAC layer makes use of services provided by the PHY through the utilization of transport channels. How and what kind of information is transmitted over the radio interface defines a transport channel. Transport blocks are a data organization mechanism for a transport channel. During a given TTI, a maximum of one transport block of variable size is sent and received over the radio interface (in the case of spatial multiplexing of more than four layers, there are two TBs per TTI). Associated with each TB is a Transport Format (TF), indicating how the transport block is to be broadcast over the radio interface. Information about the modulation and coding technique, transport block size and antenna mapping are all part of the transport format. The MAC layer can accomplish this by selecting a different transport format, allowing for a range of achievable data rates. The following transport-channel types are defined for NR: • The Broadcast Channel (BCH) has a predetermined transmission format defined by the standards. The so-called Master Information Block of the Basic Channel Control and Headend (BCCH) system is transmitted using this method. • The Paging Channel (PCH) uses the PCCH logical channel to send and receive paging data. By only waking up to receive the PCH at predetermined time instants, the device can save battery life thanks to the PCH’s support for Discontinuous Reception (DRX). • The Downlink Shared Channel (DL-SCH) primarily serves as the downlink’s data-carrying conduit in NR. HARQ with soft combining (SDM) and spatial multiplexing are also supported, along with other essential NR characteristics like dynamic rate adaptation and channel-dependent scheduling in the time and frequency domains. It also works with DRX, which helps devices use less power while remaining always-on. Additionally, the DL-SCH is utilized to transmit data from the BCCH that cannot be mapped to the BCH. There is one DL-SCH for each cell that a given device is associated with. For devices, there is an extra DL-SCH in time slots reserved for system data. • The Uplink Shared Channel (UL-SCH) is the corresponding uplink transport channel to the DL-SCH and is used for uplink data transmission. In addition, the Random Access Channel (RACH) is considered a transport channel as well [41], despite the fact that it does not deliver transport packets. An RLC Protocol Data Unit (PDU) include both an RLC header and an RLC payload. An RLC PDU is referred to as a MAC SDU when it is sent at the MAC sublayer (Service Data Unit). A MAC subPDU is built by appending a subheader to this. Control Elements (CEs) are also transmitted and received by MAC, and they each have their own subheader. The dynamic configuration modifications made possible by MAC CE signaling supplement the RRC signaling.

264

5G NR Modeling in MATLAB®

More than one MAC SDU or CE can be contained within a single MAC PDU. A MAC PDU is packaged into a TB and delivered over a transport channel before arriving at the PHY. The PHY receives MAC PDUs via transport channels including MAC PDUs. This process is shown in Figure 3.144. In Figure 3.145, each MAC PDU is broken down into one or more MAC subPDUs. There is always a subheader at the beginning of a MAC subPDU. A MAC SDU, MAC CE, or padding comes after the subheader. A padded MAC subPDU is added when the number of MAC subPDUs does not exactly fill a TB. Zero-length padding is implied by a MAC subPDU consisting of simply a subheader. There can be exactly one MAC PDU in a TB [48]. MAC SDUs, CEs and subheaders are all byte-aligned and in multiples of 8 bits. The leftmost bit is the most significant bit. A MAC PDU has a specified subPDU order. Concatenation of MAC SDUs, CEs, and padding occurs in that order in both the sidelink and the uplink. A MAC CE comes first in downlink, followed by an SDU, and then padding. Padding is always the final subPDU. Except for an SDU transporting UL CCCH, MAC SDUs have variable sizes. There are both small and large MAC CEs available. With transparent MAC (BCH, PCH, BCCH on DL-SCH, SL-BCH), the MAC subheader is omitted. There is one TB of data for every MAC SDU. The main fields of a 5G NR MAC subheader are shown in Figure 3.146 [49]: The MAC subheader consists of the following fields: Reserved. R bit is fixed to zero. Potentially useful for future MAC revisions. Format. The F bit represents the length of the L field. If F = 0, then L is 8 bits; otherwise, L is 16 bits.

FIGURE 3.144  MAC PDU construction in 5G NR.

FIGURE 3.145  Structure of DL and UL MAC PDU [48, 49].

5G Service-Based Architecture, Protocol Stack, and Interoperation

265

266

5G NR Modeling in MATLAB®

FIGURE 3.146  Structure of 5G NR MAC subheader.

Length. A MAC SDU or CE of varying size has an associated L field that specifies its size in bytes. When a fixed-size CE, padding, or MAC SDU containing UL CCCH is used, this field is omitted. The size of a UL CCCH MAC SDU is always 64 bits (or 48 bits if the LCID is LCID = 52). Logical Channel ID (LCID). The CE or padding carried in a MAC subPDU is identified by this 6-bit field. Extended Logical Channel ID (eLCID). This broadens the range of the LCID field. The size is 1 byte for LCID = 34 and 2 bytes for LCID = 33. eLCID with only two bytes is reserved for IAB backhaul connections [49]. (v) Hybrid ARQ with Soft Combining It is up to the gNB implementation to use hybrid ARQ, which is only supported for the DL-SCH and the UL-SCH. Like LTE, the hybrid-ARQ protocol employs a number of stop-and-wait processes in tandem. The receiver tries to decode a transport block it has received and communicates the result to the sender via an acknowledgement bit that indicates if the decoding was a success or not or whether the transport block should be resent. It is obvious that the receiver has to know which hybrid-ARQ process an acknowledgement belongs to. An acknowledgement's timing can be used to associate it with a specific hybrid-ARQ process, or in the event of concurrent acknowledgements, the acknowledgement's location in the hybrid-ARQ codebook can be used. The downlink and uplink both use an asynchronous hybrid-ARQ protocol, with the latter requiring the usage of a hybrid-ARQ process number to indicate which process is being addressed. Retransmissions in an asynchronous hybrid-ARQ protocol are, in principle, scheduled in the same way as the original transmissions. Data from the hybrid-ARQ mechanism may be supplied out of order if numerous concurrent

5G Service-Based Architecture, Protocol Stack, and Interoperation

267

hybrid-ARQ processes are used for a device. While this may be appropriate for some uses, the PDCP also allows for in-sequence delivery. In the RLC protocol, insequence delivery is not offered for the sake of minimizing delay. Retransmission of Codeblock Groups (CBGs) is a feature of the hybrid-ARQ mechanism in NR that was absent from LTE. This is useful for very long transport blocks or when a transport block is partially interfered with by another preempting transmission. To keep the channel-coding complexity low, a transport block is divided into one or more codeblocks, and error-correcting coding of no more than 8448 bits is applied to each codeblock as part of the channel-coding operation in the physical layer. Simply resending the erroneous code blocks will result in a successful reception of the transport block. However, if hybrid-ARQ allows code blocks to be addressed separately, the control signaling overhead would be excessive. As a result, codeblock groups are established. Only the incorrectly received code block groups are retransmitted if per-CBG retransmission is set up, and feedback is provided per CBG (Figure 3.147). This may use fewer resources than resending the entire transport block. Although CBG retransmissions are part of the hybrid-ARQ process [41], they are not visible to the MAC layer and are instead managed by the physical layer. (vi) Scheduling In 5G, scheduling can be regarded as the mechanism of assigning resources for the transmission of data. The timing and manner in which resources are allocated to a user can be affected by a number of factors. Scheduling in 5G depends on a number of elements, some of which are shown in Figure 3.148. The QoS requirements of each user equipment (UE) and the radio carriers to which it is attached, as well as the state of the UE buffers, are taken into account when deciding how to divide up available resources. The radio conditions at the UE, as indicated by measurements performed at the base station and/or provided by the UE, may also have an effect on the scheduler’s resource allocation. Radio resources are allocated via slots, which can range in size from a single mini-slot to many slots. In response to a scheduling request, the UE will be assigned a scheduling channel

FIGURE 3.147  Codeblock group retransmission.

268

5G NR Modeling in MATLAB®

FIGURE 3.148  5G Scheduler (5G/NR—Scheduling) [50].

and given access to the allocated resources. The reports for the uplink buffer status, which assess the data held in the logical channel queues of the UE, are one of the measurements used to determine scheduler operation. They serve to make QoS packet scheduling possible. Power headroom reports, which calculate the difference between the UE’s maximum transmit power and the estimated power for uplink transmission [50], are also used by power-aware packet scheduling. The two primary scheduling types employed by 5G are frequency domain scheduling and time domain scheduling [50]. A resource element is the basic time-frequency unit of resource that can be used for either uplink or downlink transmission. As an alternative definition, we might think of it as a single sub-carrier using a single OFDM symbol [51]. The smallest radio resource unit that can be allocated to a single user is a Resource Block (RB), which consists of twelve sub-carriers that are continuous in frequency and cover one time slot. The four radio resource categories are radio frames, subframes, slots, and mini-slots. The radio frame, which lasts 10 ms, is divided into ten segments, each of which lasts 1 ms. Each subframe consists of a group of 14 OFDM symbols spread across one or more neighboring slots. Mini-slots in Release 15 consist of 2, 4, or 7 OFDM symbols, and the length of a slot is determined by the sub-carrier spacing [52]. This is depicted in Figure 3.149. Many new scheduling mechanisms have been created in 5G to accommodate the massive user base and complex features. One of the most notable innovations brought about by 5G is the massive MIMO. Due to NR’s separation of downlink and uplink scheduling, scheduling decisions for each can be made individually (within the limits set by the duplex scheme in the case of half-duplex operation). The downlink scheduler chooses (dynamically) which devices to send to and, for each of these devices, which blocks of available resources should be used to send the ‘DL-SCH. As shown in the left side of Figure 3.150, the gNB decides the transport format (choice of transport-block size, modulation method, and antenna mapping) and logical-channel multiplexing for downlink transmissions.

5G Service-Based Architecture, Protocol Stack, and Interoperation

269

FIGURE 3.149  Structure of Frame for 5G [52].

FIGURE 3.150  5G NR downlink and uplink scheduling.

Similar functionality is provided by the uplink scheduler, which (dynamically) determines which devices transmit over which UL-SCHs and when/where specific uplink time/frequency resources are used (including component carrier). While the transport format of the device is decided by the gNB scheduler, it is important to note that the uplink scheduling decision does not explicitly schedule a particular logical channel but rather the device itself. Consequently, although the gNB scheduler controls the payload of a scheduled device, the device is responsible for selecting from which radio bearer(s) the data are obtained according to a set of rules, the parameters

270

5G NR Modeling in MATLAB®

of which are configurable by the gNB. Figure 3.150 shows how the device handles logical-channel multiplexing [41], while the gNB scheduler is in charge of the transport format. (vii) Carrier Aggregation Carrier Aggregation relies heavily on MAC (CA). One TB per TTI is produced, and MAC PDUs and CEs are dispersed among many CCs. Figure 3.151 depicts that within MAC, each CC has its own independent HARQ entity. Multiple carriers or cells are involved in CA, although they all belong to the same cellular category. All CA-involved cells within a given cell group are serviced by a single MAC entity. One or more Secondary Cells (SCells) aggregate over and around a single Primary Cell (PCell). Multiple transport channel instances can exist within a single MAC entity, including one DL-SCH, one UL-SCH, and one RACH for a Special Cell (SpCell), one DL-SCH for each SCell, and, optionally, one UL-SCH and one RACH for each SCell. Whether in MCG or SCG, SpCell is the PCell. This means that CA and Dual Connectivity can work together. When a device uses either carrier aggregation or dual connectivity, it is connected to two separate cells at once. Although they share certain similarities, there are also key distinctions, especially with the degree of coordination between the various cells and whether or not they share a gNB. Carrier aggregation involves very tight coordination, with all the cells belonging to the same gNB. All of the device's connected cells share a single scheduler that makes scheduling choices in coordination. The looser coordination between cells is made possible by dual connection. In the case of non-standalone operation, the cells may be associated

FIGURE 3.151  Carrier aggregation with HARQ.

5G Service-Based Architecture, Protocol Stack, and Interoperation

271

with separate gNBs and even different radio-access technologies, as in the case of NR-LTE dual connectivity [42, 44, 45]. (viii) Physical and Sidelink Channels Data transmission services are provided by the physical layer to the higher levels. These services are accessed through the media access control (MAC) layer’s transport channels. The information passed from the media access control layer to the physical layer is known as a transport block [53]. The following data transport service requirements are placed on the physical layer: • • • • • • • • •

Transport channel error detection and reporting to higher layers. FEC encoding/decoding of the transport channel. Hybrid ARQ soft-combining. Coded transport channel rate matching for various physical channels. Physical channel mapping for a coded transport channel. Physical channel power weighing. Physical channel modulation and demodulation. Synchronization of frequency and timing. Measuring radio frequency characteristics and providing feedback to higher levels. • MIMO antenna processing. • Radio Frequency processing. The following physical-channel types are defined for NR: • The Physical Downlink Shared Channel (PDSCH) is the primary medium for unicast data transmission, as well as other uses (such as paging, random-access response messages, and system information delivery) [53]. The processing steps that are relevant for the physical-layer model, e.g., in the sense that they are configurable by higher layers, are highlighted in blue in Figure 3.152. The main steps depicted in Figure 3.152 are listed below: • • • • • • •

Higher-layer data passed to/from the physical layer. Indication of CRC error and transport block error. Rate-matching and FEC. Modulation. Physical Resource Mapping; Multiantenna processing. Hybrid ARQ-related signaling and L1 control support.

The Physical Broadcast Channel (PBCH) transmits data necessary for the device to join a network. When it comes to the BCH physical layer model, there is a predetermined transport format. Every 80 ms, the BCH will receive a TB. According to

FIGURE 3.152  Physical-layer model for DL-SCH transmission.

272 5G NR Modeling in MATLAB®

5G Service-Based Architecture, Protocol Stack, and Interoperation

273

FIGURE 3.153  PBCH physical-layer-processing chain.

Figure 3.153 [53], the BCH physical-layer model is explained in terms of the PBCH physical-layer processing chain. The main steps depicted in Figure 3.153 are listed below: • • • • • •

Higher-layer data passed to/from the physical layer. Indication of CRC error and transport block error. Rate-matching and FEC. Modulation. Physical resource mapping. Multiantenna processing.

The Physical Downlink Control Channel (PDCCH) is used to receive PDSCH and to transmit PUSCH by granting scheduling permissions, both of which require downlink control information, primarily scheduling decisions. The Physical Uplink Shared Channel (PUSCH) is the uplink equivalent of the PDSCH. For each uplink component carrier, there can be at most one PUSCH. Based on the appropriate PUSCH physical-layer-processing chain, Figure 3.154 [53] describes the physical-layer model for Uplink Shared Channel transmission. The main steps depicted in Figure 3.154 are listed below: • Higher-layer data passed to/from the physical layer. • Indication of CRC error and transport block error.

274

5G NR Modeling in MATLAB®

FIGURE 3.154  Physical-layer model for UL-SCH transmission.

• • • • •

Rate-matching and FEC. Modulation. Physical resource mapping. Multiantenna processing. Hybrid ARQ-related signaling and L1 control support

The Physical Uplink Control Channel (PUCCH) is utilized to report channel states to help with downlink channel-dependent scheduling, request uplink transmission resources when needed, and send hybrid-ARQ acknowledgements to the gNB indicating whether or not downlink transport blocks were received successfully [53]. • The Physical Random-Access Channel (PRACH) is utilized for random access. Standalone Physical ChannelsIt should be noted that not every physical channel has a corresponding transport channel. This is especially true of the channels used to transmit downlink and uplink control information (PDCCH and PUCCH). Slot Format Indicator (SFI) and Downlink Control Information (DCI) are transmitted on the PDCCH on the downlink. DCI is in charge of PDSCH and PUSCH scheduling. It includes instructions for adjusting the Transmission Power (TPC). There are several different types of DCI, and one of them includes SFI to tell the UE which slot format to use. Uplink Control Information (UCI) is transmitted on PUSCH, although it can also be transmitted on PUCCH. HARQ-ACK, scheduling requests, and channel reports are all carried out by UCI [40].

5G Service-Based Architecture, Protocol Stack, and Interoperation

275

(ix) 5G NR Physical Signals and RNTI A few physical signals are inextricably linked to the functioning of physical channels. Primary Synchronization Signal (PSS) and Secondary Synchronization Signal (SSS) are used for downlink synchronization (SSS). They are broadcast simultaneously with PBCH. Demodulation Reference Signal (DM-RS) is utilized in both the downlink and uplink for acquisition and channel estimation. All of the PBCHs, PDCCHs, PDSCHs, PUCCHs, and PUSCHs can use it. When PUCCH and PUSCH are not planned, a Sounding Reference Signal (SRS) is utilized to estimate channels in the uplink. Downlink placement positioning is accomplished with the help of Positioning Reference Signal (PRS). Uplink placement is determined using SRS. For phase tracking and phase noise compensation for PDSCH and PUSCH, Phase Tracking Reference Signal (PT-RS) is employed. This method uses precise time and frequency tracking to counteract path delay spread and Doppler spread. The downlink utilizes Channel State Information Reference Signal (CSI-RS) for beam control to a linked UE. Using a Radio Network Temporary Identifier (RNTI), a cell, a radio channel, a group of users, users for whom the eNB issues power control, and users to whom the 5G gNB transmits system information can all be distinguished from one another. RNTI is a 16-bit identifier whose value is determined by the RNTI type. More details are given in [53, 54]. The main RNTI types used in the downlink physical channels are summarized in Table 3.5. (x) Sidelink Channels The sidelink channels in 5G are shown in Figure 3.155. Direct device-to-device communication is made possible through sidelink channels. This is unique to communications between vehicles [40, 53]. Physical Sidelink Broadcast Channel (PSBCH), Physical Sidelink Control Channel (PSCCH), Physical Sidelink Shared Channel (PSSCH), and Physical Sidelink Feedback Channel are all examples of sidelink physical channels (PSFCH). Each of PSCCH and PSFCH is a separate channel. The Sidelink Channel Information (SCI) is transmitted in two ways, with one path flowing over PSCCH and the other via PSSCH. The PSFCH is where you will find the Sidelink Feedback Control Info (SFCI). PSFCH relays HARQ reception feedback to PSSCH. Sidelink Broadcast Channel (SL-BCH) and Sidelink Shared Channel (SL-SCH) are two examples of transport channels (SL-SCH). The Sidelink Broadcast Control Channel (SBCCH), Sidelink Control Channel (SCCH), and Sidelink Traffic Channel are all logical channels (STCH). Mapping of these are PBCCH/SL-BCH/PSBCH, SCCH/SL-SCH/PSSCH and STCH/SL-SCH/PSSCH. Sidelink primary synchronization signal (S-PSS) and secondary synchronization signal (S-SS) are examples of sidelink physical signals (S-SSS). PSCCH is linked to DM-RS. Both DM-RS and PT-RS are linked to PSSCH. 3.2.1.3 gNB-DU-CP – gNB-CU-CP Protocols Figure 3.156 shows the protocol stack for the gNB-DU-CP – gNB-CU-CP connection on the F1-C interface [39, 41, 42].

276

5G NR Modeling in MATLAB®

TABLE 3.5 Main Types of RNTI in 5G NR RNTI

Description

Paging-RNTI (P-RNTI)

It is used by the UEs for the reception of paging. It is also a common RNTI meaning that it is not allocated to any UE explicitly.

Cell RNTI (C-RNTI)

It is a unique identification used for identifying RRC Connection and scheduling which is dedicated to a particular UE. The gNB assigns different C-RNTI values to different UEs. It is used for the broadcast of system information. It is a common RNTI meaning that, it is not allocated to any UE explicitly and is common to all UEs in the cell. It is used during Random Access procedure, the gNB’s MAC generates Random Access Response (RAR) as a response to the Random Access Preamble transmitted by the UE. This identifier is used in 5G as part of Configured Scheduling (CS) resource allocation. It enables RRC to define the periodicity of the CS grant using the CS-RNTI. This resource can then be implicitly reused according to the periodicity defined by RRC.

System Information RNTI (SI-RNTI) Random Access RNTI (RA-RNTI) Configured Scheduling— RNTI (CS-RNTI)

MCS-C-RNTI

MCS-C-RNTI is a unique UE identification used for indicating an alternative Modulation and Coding Scheme (MCS) table for PDSCH and PUSCH.

FIGURE 3.155  MAC structure showing sidelink logical and transport channels.

5G Service-Based Architecture, Protocol Stack, and Interoperation

277

FIGURE 3.156  gNB-DU-CP – gNB-CU-CP protocols protocol stack.

(i) F1AP The F1AP functions cannot be achieved without the signaling service provided by F1AP between the gNB-DU and the gNB-CU. There are two categories of F1AP services: • Non-UE-associated services: Together, the gNB-DU and gNB-CU form a non-UE-associated signaling link that is related to the entire F1 interface instance. • UE-associated services: They are related to one UE. The signaling connection between the F1AP and the UE is maintained so that these services can be provided. One protocol endpoint may only have one active F1AP procedure for a given UE at any one time unless otherwise specified in the procedure specification. (ii) Stream Control Transmission Protocol (SCTP) The SCTP is a transport protocol, just like the more common User Datagram Protocol (UDP) and the Transmission Control Protocol (TCP). SCTP has additional features and is more resilient to network outages than TCP and UDP. SCTP provides (similarly to TCP and in contrast to UDP) reliable transport assuring that data reaches the destination without error. All data exchanged between two SCTP endpoints is done so as part of a session (or association, as it is called by SCTP) [39], making it comparable to TCP but different from UDP. A comparison between TCP, UDP and SCTP is provided in Table 3.6. TCP ensures that data is transferred reliably and is delivered in a predetermined order, while UDP does not guarantee either of these properties. Some use cases necessitate dependable transfer but are content with less-than-perfect data order,

278

5G NR Modeling in MATLAB®

TABLE 3.6 Comparison between TCP, UDP, and SCTP Feature

SCTP

TCP

UDP

Connection-oriented

Yes

Yes

No

Reliable transport Preserves message boundary In-order delivery Un-ordered delivery Data checksum Flow and congestion control Multiple streams within a session Multihoming support

Yes Yes Yes Yes Yes (32 bit) Yes Yes Yes

Yes No Yes No Yes (16 bit) Yes No No

No Yes No Yes Yes (16 bit) No No No

Protection against SYN flooding attacks

Yes

No

N/A

whereas others desire dependable transfer but care less about sequence maintenance. Since TCP will not send the data up to the next layer until all segments have been received in the correct order, this causes delivery delays. SCTP addresses this problem by including a capability for multiple streams. With this capability, data can be split up into several streams, each of which can be sent in its own controlled message sequence. SCTP’s multistreaming functionality is achieved by separating data reliability and transmission order (Figure 3.157). In contrast to TCP, where the two concepts are joined together, they remain separate. SCTP uses two different kinds of sequence numbers. When a packet is lost, the Transport Sequence Number is checked to determine whether or not a retransmission is necessary. Additionally, SCTP assigns a sequence number known as the Stream Sequence Number to each stream inside the data. The receiver uses the stream sequence numbers to ensure that the packets are delivered in the correct order for each individual stream. SCTP also allows users to avoid the sequenced delivery service altogether, guaranteeing that messages will be sent to the user in the same order in which they

FIGURE 3.157  Multistreaming in SCTP.

5G Service-Based Architecture, Protocol Stack, and Interoperation

279

FIGURE 3.158  Multihoming with SCTP.

were received. Applications that need dependable transit but do not necessitate sequential delivery or have their own means to handle received packet sequencing may benefit from this [39]. SCTP’s multihoming capabilities are another major improvement over TCP. Each endpoint in a TCP session uses the same IP address, and if that IP address becomes unreachable, the session ends. Since the endpoints can be reached via numerous IP addresses, using TCP to provide highly accessible data transfer capacity is challenging when employing multihomed hosts. On the other hand, SCTP is made to deal with hosts with multiple IP addresses, and each SCTP endpoint can have more than one IP address. These IP addresses could also result in other channels of communication between the SCTP nodes. For example, the IP addresses may belong to various local networks or to different backbone carrier networks. If the primary IP address goes down for any reason, the SCTP packets can be automatically redirected to the backup address. [39].​ 3.2.1.4 gNB-CU-CP-AMF Protocols Figure 3.159 shows the gNB-CU-CP and AMF protocols protocol stack. The SCTP protocol is the same as described previously. (i) Next Generation Application Protocol (NGAP) The NG-Cand N2-reference points are used in NGAP messages passed between the RAN and the 5GC, the two nodes most heavily involved in CP communication. The Next Generation Access Protocol (NGAP) can be used with the 3GPP Access over gNodeB, Next Generation eNodeB (ng-eNodeB), and non-3GPP Access over a N3WIF, TNGF, TWIF, or Wireline Access Gateway Function (W-AGF). Paging, UE context management, UE mobility management, UE session management, Network Area Service (NAS) transport, warning message transmission, AMF management, AMF load balancing, multiple TNL associations, location reporting, and UE radio capability management are just some of the core mobile network functions that NGAP supports [55,56].

280

5G NR Modeling in MATLAB®

FIGURE 3.159  gNB-DU-CP – gNB-CU-CP protocols protocol stack.

The NGAP interactions between AMF and (R)AN are divided into two groups: • Non-UE-associated services. The entire instance of the NG interface between the (R)AN node and the AMF is connected to these NGAP services. Examples of their use include managing certain types of overload and exchanging configuration data between the RAN and AMF using the NGAP signaling connection. • UE-associated services. Each UE is associated with its own set of NGAP services. The procedures in which a UE participates—during Registration, PDU Session Establishment, etc.—are tied to this NGAP signaling. The NGAP protocol supports the following functions [39]: • NG (i.e., N2) interface administration features such as initial NG interface configuration in addition to Load Balancing, Reset, Overload Indication, and Error Indication. • The capability of setting up an initial UE context in the (R)AN node is known as Initial UE Context Setup. • Providing the AMF with information on the UE’s capabilities (when received from the UE). • Path Switch request and other UE mobility services that make handover possible in an NG-RAN. • Resource preparation, modification, and release for PDU Sessions (User Plane resources). • Paging, which allows 5GC to contact the UE. • Communication between the UE and the AMF using NAS signals. • Managing how one NGAP UE association binds to another at the transport network layer for a given UE. • In-sequence delivery and duplication avoidance during handover are supported by the status transfer feature, which moves information about PDCP Sequence Number status from the source NG-RAN node to the target NG-RAN node using an AMF.

5G Service-Based Architecture, Protocol Stack, and Interoperation

281

• Trace of active UEs. • Positioning and location reporting functionality for UE. • Transmission of warning messages. The NGAP messages support four main procedures, listed in the following:

1) Interface management: manages the interface between the NGAP and the NAS, called the NG Control Plane (NG-C), and ensures that all necessary signaling between the two ends of the interface occurs without interruption. Methods for distinguishing between AMF and NG-RAN and selecting resources as networking slices based on PLMN in AMF are also included. 2) Transport of NAS messages: transports NAS data between the NG-RAN and the AMF. Before being sent on to the NG-C interface, NAS communications are encapsulated in the NGAP protocol. 3) UE context management: supplies NG-RAN with information on UEs, including UE security status, UE radio capabilities, UE security capabilities, PDU session context, mobility restriction list, authorized networking slices, AMF connected information, and UE radio capabilities. 4) PDU session management: oversees the administration of resources for predetermined PDU sessions. NG-RAN and 5GC share these assets, which together create the data-plane interfaces known as Radio Interface (Uu) and NG-U. 3.2.1.5 AMF and SMF Protocols The protocols between the AMF and SMF over the N11 interface are shown in Figure 3.160. The HTTP2 protocol was defined in Section 3.1 The TCP/IP protocols are standard protocols as defined in the TCP/IP reference model. The L2 and L1 protocols pertain to the RLC and MAC layers were defined in Subsection 3.2.1.2. 3.2.1.6 SMF and UPF Protocols The protocols between the SMF and UPF over the N4 interface are shown in Figure 3.161. (i) Packet Forwarding Control Protocol (PFCP) The UPF is managed by the SMF through the usage of the PFCP across the N4 reference point. 3GPP TS 29.244 is where PFCP is formally defined. A PFCP Request message uses the UDP port number of 8805, and the protocol used is UDP. Two distinct categories of PFCP processes (and associated messages) exist: (i) Node-Related Procedures Communication between the CP Function (SMF) and the UP Function (UPF) and between the nodes themselves is facilitated by the Node-related procedures. The associated PDU Sessions are managed by the Session-related procedures. Before initiating any PFCP Sessions on a UP function, a CP function must first establish a PFCP Association with that UP function at the node level. Initiating a PFCP Association can be done using either the CP or UP function (it is compulsory

282

5G NR Modeling in MATLAB®

FIGURE 3.160  AMF to SMF protocols.

FIGURE 3.161  Protocols between the SMF and UPF over the N4 interface.

5G Service-Based Architecture, Protocol Stack, and Interoperation

283

in products to support CP-initiated and optional to support UP-initiated PFCP Association setup). Additional node-related operations, such as node-level configuration, heartbeats, and load/overload handling, are supported in addition to the initial PFCP Association setup. The following PFCP Node-related procedures are supported: • • • • • • • •

PFCP Association Setup. PFCP Association Update. PFCP Association Release. PFCP Node Report. Heartbeat. Load Control. Overload Control. PFCP Packet Flow Description (PFD) management.

(ii) Session-Related Procedures The User-Plane for PDU Sessions is managed by PFCP Sessions. (It can also be used to handle traffic on the User Plane that is not part of PDU Sessions; for example, if SMF needs to communicate to DHCP or AAA servers in the DN, it can do so by setting up a UPF.) The SMF chooses at least one UPF to serve a newly generated PDU Session. To advise the UPF on how to handle User Plane traffic for the PDU Session, the SMF will initiate a PFCP Session establishment towards this UPF. When the SMF chooses to include additional UPFs in a PDU Session (by serving as I-UPF or ULCL, for example), it also starts a PFCP Session directed at those UFPs. Therefore, each PDU Session has exactly one PFCP Session for each UPF along the PDU Session's path. Each endpoint (SMF and UPF) creates a Session Endpoint Identifier when a PFCP Session is initiated (SEID). Each PFCP session at a given IP address is identified by its SEID. The destination SEID is supplied in all session-related messages to help the receiver determine which PFCP Session the message pertains to. The following PFCP Session related procedures are supported: • • • •

PFCP Session Establishment. PFCP Session Modification. PFCP Session Deletion. PFCP Session Report.

In addition to the PFCP message header, a Node-related or Session-related PFCP message may have one or more Information Elements. The format of a PFCP message is depicted in Figure 3.162 [39, 41, 42]. PFCP messages can be either node-related (meaning they apply to the SMF or UPF) or session-related, and the formats for these two types of messages are slightly different (applicable to a specific PFCP session). Session-related communications include the SEID, but node-related ones do not. In the current release of PFCP, Version is set to 1. The MP-flag specifies whether a Message Priority is included in the header or not, while the S-flag indicates whether an SEID is included or not.

284

5G NR Modeling in MATLAB®

FIGURE 3.162  PFCP message format.

By creating, updating, and removing PFCP Session contexts and supplying (i.e., adding, altering, and removing) particular rules that describe the User Plane activities that shall be done by the UPF, the SMF exerts control over the packet processing in the UP function. Essentially, the SMF is using the N4 rules to instruct the UPF on how to process packets. Messages concerning a PFCP Session will have the N4 rules appended as Information Elements. These rules are given below:​ • The UPF can be instructed by a rule known as a Packet Detection Rule (PDR) on how to recognize and categorize incoming user data traffic (PDUs). Packet Detection Information (such as IP filters) is stored in the PDR for use in traffic monitoring and classification. Uplink and downlink PDRs are kept in isolation. • QoS Enforcement Rule (QER). QoS enforcement instructions, including bit rate parameters, are included in this rule. • Usage Reporting Rule (URR). In this regulation, we lay out the specifics for how the UPF should track and report packet and byte utilization to the SMF. Events that must be reported to SMF are also detailed in the URR. • Forwarding Action Rule (FAR). This rule specifies the destination of an uplink or downlink packet (PDU) from the UPF, such as the Data Network or the Radio Access Network. • Buffering Action Rule (BAR). For example, if a UE is in CM-IDLE state [39, 41, 42], this rule specifies how packets should be buffered. 3.2.1.7 gnB-CU-CP to gNB-CU-CP Protocols The XnAP supports the functions of the Xn-C interface defined in Chapter 2. The other protocols in this stack have already been defined in the previous subsections.

5G Service-Based Architecture, Protocol Stack, and Interoperation

285

FIGURE 3.163  gnB-CU-CP to gNB-CU-CP protocol stack.

3.2.2 User Place Protocol Stack The user place protocol stack is shown in Figure 3.164. Most of the protocols have similar functionalities to the control place protocols. A description of only the protocols not found in the control plane or having different functions than their control place counterparts is given next. (i) PDU Layer The PDU that travels between the UE and the DN is represented by this layer. When an IPv4, IPv6, or IPv4v6 PDU Session Type is specified, the corresponding data units are IPv4 packets, IPv6 packets, or both; when an Ethernet PDU Session Type is specified, the corresponding data units are Ethernet frames, and so on. (ii) Service Data Adaptation Protocol (SDAP) In both the gNB and the UE, the SDAP sublayer is only found in the user plane. DRBs connect it to the PDCP lower layer and QoS flows connect it to the higher tiers (DRBs). The data from the QoS flows is routed to the proper DRBs. SDAP plays a crucial part in this. Since QoS flows are a feature exclusive to 5G, the SDAP layer is not present in 4G/LTE networks. QoS Flows are used in 5G to implement QoS. DRBs are used to transport data packets over the Uu air interface connecting gNB and UE. To assign DRBs to QoS flows, rules are either configured or derived. SDAP is where this mapping is carried out. Each PDU session on the gNB-UE Uu interface can have its own SDAP entity in the SDAP sublayer. RRC is responsible for initiating the creation and deactivation

286

5G NR Modeling in MATLAB®

FIGURE 3.164  User plane protocol stack.

of SDAP entities. Multiple QoS flows can be mapped to a single DRB, hence the mapping between the two is not one-to-one. In Figure 3.165 an example of a single PDU session with four QoS flows mapped to three DRBs is provided. There is just one DRB assigned to the first two flows. Depending on the RLC mode, one or two PDCP entities may be responsible for each DRB. Only one DRB can be assigned to a QoS flow in the uplink. A PDU session always includes at least one DRB. Each PDU session can only have one default DRB. When no uplink mapping is present, SDAP PDUs are transmitted using the primary DRB. Separate DRBs are used for packets that are part of distinct PDU sessions [57, 58, 59]. The SDAP sublayer can take a few different forms, some of which are depicted in Figure 3.166. RRC is responsible for setting up the SDAP layer. QoS flows are mapped to DRBs. Each DRB can be mapped to one or more QoS flows. On the uplink, however, a single QoS flow is assigned to a single DRB. Entities with SDAP properties can be found in the SDAP layer. A single UE can have several SDAP entities. Each PDU session has its own unique SDAP entity configured. Each SDAP entity communicates with its peers via lower levels, sending and receiving SDAP data PDUs and SDAP control SDUs. When an SDAP entity on the transmitting side receives an SDAP SDU from higher layers, it builds the corresponding SDAP data PDU and sends it to lower layers. When an SDAP entity on the receiving end receives an SDAP data PDU from one of the lower layers, it looks up the appropriate SDAP SDU and sends it on to the next higher tier. The SDAP entity’s sublayer functional block diagram is shown in Figure 3.166 [3]. If a downlink SDAP header is set up, the UE is responsible for

5G Service-Based Architecture, Protocol Stack, and Interoperation

287

FIGURE 3.165  User plane stack for one PDU session in SDAP.

FIGURE 3.166  High-level SDAP sublayer functional architecture.

mapping the reflective QoS flow to the DRB. The SDAP sublayer transports userplane data and exclusively delivers services to the user-plane upper layers. Userplane data transfer, identifying QFI in downlink and uplink packets, and reflective QoS flow to DRB mapping for uplink SDAP data PDUs [57, 58, 59] are all supported by the SDAP sublayer, as shown in Figure 3.166.

288

5G NR Modeling in MATLAB®

The SDAP data PDU formats for both UL and DL transmission are shown in Figure 3.167. The payload of an SDAP data PDU might be anything from one byte long to 255 bytes long. The SDAP and PDCP layers share information about the payload’s length. The DRB determines whether or not the UL and DL should include the SDAP header. If the DRB is simply transporting a single QoS flow, then no header is needed. If reflective QoS is activated, DL header presence can be altered. A handover is an example of a coordinated modification to the presence of headers. The DL SDAP header consists of a 6-bit QFI, a 1-bit RQI (Reflective QoS Indication), and a 1-bit RDI (Reflective QoS flow to DRB mapping Indication). The UL SDAP header has QFI built in. Uplink QoS flow to DRB mapping is updated by the UE when RDI = 1. Once the RQI value is set to 1, the UE notifies the NAS that the rules for mapping Service Data Flow (SDF) to QoS have been modified. The data PDU indicator is a 1 in the D/C field’s single bit. There is a reserved bit in the R field. The Reflective QoS Attribute (RQA) may be included in QoS flows that are non-GBR. With this, the NG-RAN is instructed to add QFI to data sent over the downlink. Uplink packets from the UE can be configured to include QFI. As can be seen in Fig. 3.168, SDAP uses a single control PDU (called end-marker). Whenever a QoS flow is no longer associated with the DRB/SL-DRB that this control PDU is being delivered from, this message is transmitted. A 6-bit QFI/PQFI field denotes the QoS traffic direction. To signify a control PDU, the D/C bit is set to

FIGURE 3.167  SDAP data PDU formats.

FIGURE 3.168  SDAP end-marker control PDU format.

5G Service-Based Architecture, Protocol Stack, and Interoperation

289

zero. There will be no use for the R bit. After a new mapping is configured by RRC, SDAP will transmit the DRB or SL-end-marker DRB's PDU. The latter could be a DRB/SL-DRB that has been set up in the past, or the DRB/SL-DRB that is set up by default [59, 60].​ (iii) Packet Data Convergence Protocol (PDCP) The PDCP supports sequence numbering, header compression/decompression, user data transfer, reordering, duplicate detection, in-sequence delivery, PDCP PDU routing in multiconnectivity, PDCP SDU retransmission, PDCP SDU retransmission, ciphering/deciphering, integrity protection, PDCP SDU discard, PDCP re-establishment/data recovery for RLC-AM and PDCP status reporting for RLC-AM. The main differences and similarities between the PDCP functions at the control and user planes are summarized in Table 3.7 [39, 41, 42]. (iv) GTP-U For the User Plane, GPRS employs a Tunneling Protocol (GTP-U) The Control Plane subset of GTP (GTP-C) and the User Plane subset of GTP (GTP-U) are the two primary subsets of GTP (GTP-U). When it comes to managing and controlling PDN Connections and the User Plane tunnels that make up the User Plane path, 3G/GPRS and 4G/EPS rely on the Generic Tunneling Protocol-Control (GTP-C). The GTP-U operates via UDP transport and utilizes a tunnel method to transfer user data traffic. Although GTP-U is being reused to transport User Plane data between N3 and N9 (and N4) in 5G, HTTP/2 and NGAP are being used as the control protocol to maintain the tunnel IDs, etc. When 5GC is collaborating with EPC, only GTP-C is employed. For this reason, we shall focus solely on defining GTP-U. In order to segment data and voice traffic, GTP-U tunnels are established between pairs of GTP-U nodes. Each node's tunnel endpoint is distinguished by its IP address, UDP port, and local Tunnel Endpoint Identifier (TEID), and the TEID assigned for the communication must match that of the receiving entity. 5GC uses GTP-U TEIDs and IP addresses to set up tunnels from (R)AN to SMF. Between SMF and AMF, HTTP/2 is used for this communication, while NGAP is TABLE 3.7 PDCP Functions at User and Control Planes Functions

Control Plane

User Plane

Sequence numbering of PDCP PDUs

Yes

Yes

Header compression and decompression using Robust Header Compression (ROHC)mechanism Reordering and duplicated PDCP PDU detection Security functions such as ciphering, deciphering, and integrity protection PDCP status reporting for ARQ operation in RLC AM

No

Yes

Yes Yes

Yes Yes

No

Yes

Duplication of PDCP PDUs to enhance reliability of transmission

No

Yes

290

5G NR Modeling in MATLAB®

FIGURE 3.169  User plane protocol stack for a PDU session.

FIGURE 3.170  GTP-U header.

used between AMF and (R)AN. Therefore, 5GC does not employ GTP-C for tunnel management via GTP-U. The user plane protocol stack for a PDU Session is shown in Figure 3.169 over the Xn-U interface [39, 41, 42]. Every node has its own unique IP and UDP port that together define a GTP path. Multiple GTP tunnels can be connected to the same destination via different pathways. If a GTP-U header contains a TEID, then the payload is associated with a certain tunnel. So, between any two provided Tunnel Endpoints, GTP-U will multiplex and demultiplex packets as needed. In Figure 3.170, we can see the GTP-U header. 3GPP TS 29.281 [61] provides the specifications for the GTP-U protocol.

5G Service-Based Architecture, Protocol Stack, and Interoperation

291

3.3 5G NON-STANDALONE AND STANDALONE ARCHITECTURE OPTIONS Though 5G has been standardized, it has a variety of options. The rollout of 5G can look extremely different depending on the network provider. This selection is influenced by a number of factors, including the operator’s spectrum licensing, the terrain and population density of the area served, the capabilities of the equipment in use, and the operator’s business objectives (cash flow and decision-making). In terms of the Radio Access Network (RAN) and the Core Network, 3GPP has outlined alternatives for both 4G and 5G technologies (CN). These options help guide operators as they shift from current 4G deployments to 5G deployments. It is widely believed that operators will roll out 5G New Radio first, allowing coexistence between 4G RAN and 5G NR before moving on to 5G Core. This suggests that 4G+5G devices, which can communicate with both 4G eNB and 5G gNB, will debut first [62]. 5G deployment from LTE can take one of two forms, both of which are introduced by the 3rd Generation Partnership Project (3GPP): Non-Standalone (NSA) and Standalone (SA). NSA allows for low-cost, quick deployment of 5G services by piggybacking on existing LTE networks. Since the SA consists of a single RAT, we can offer complete 5G improvements optimized for the 5G New Radio (NR) SA architecture. An operator must take into account a variety of considerations when deciding which 5G deployment option is most appropriate for its network deployment situation. With its ability to use existing LTE infrastructure, NSA, for instance, could be the most cost-effective choice for a rapid 5G rollout. However, not all 5G-specific services, such URLLC and network slicing [63], can be supported by the NSA deployment option.

3.3.1 NR Architecture Options Figure 3.171 displays the six possible NR deployment architectures developed by the 3GPP. These architecture options are separated into two deployment scenarios: SA and NSA [64, 65]. The SA uses a single RAT to deliver NR service, whereas the NSA leverages preexisting LTE infrastructure to make NR deployment possible. Options 1, 2, and 5 are SA, while Options 3, 4, and 7 are NSA. However, Option 1 is not taken into account when dealing with NR deployment situations because it is a legacy LTE system in which an E-UTRAN NodeB (eNB) is connected to an Evolved Packet Core (EPC), also known as a 4G Core Network (CN). The four different RAN elements are as follows: eNB: a part of a 4G system. Connects a 4G UE to an EPC network. Options 1 and 3.4 are related to this. gNB: a newly introduced 5G network element. Connects to a 5G UE and 5G Core. This relates to Options 2, 4 and 7. en-gNB: connects a 5G UE to an EPC while residing in a 4G RAN. By employing dual connection, both 4G and 5G radio resources can be used

292

5G NR Modeling in MATLAB®

FIGURE 3.171  SA and NSA architecture options.

simultaneously. The eNB serves as the primary node, while the en-gNB acts as a backup. The letter “en” stands for E-UTRA New Radio. This relates to Option 3. ng-eNB: connects to 5G Core but serves a 5G UE over 4G radio. “ng” refers to Next Generation. The following applies to choices 4, 5, and 7. Option 4 (gNB as primary, ng-eNB as backup) and Option 7 (gNB as primary, ngeNB as backup) support this feature (ng-eNB is master, gNB is secondary). Multiradio Dual Connectivity (MR-DC) allows a UE to be connected to two separate RAN nodes (i.e., a gNB and an eNB) in an NSA deployment. Both nodes are involved, however only one is the Master Node (MN) (SN). Connected to the SN and the 4G/5G CN is the MN. Depending on preferences, the SN can be linked to the Core [4]. Table 3.8 displays the typical classifications used to label MR-DC. For the control plane, UEs in MR-DC link up with the MN/CN and talk to the SN over the MN. A UE can establish a connection to the user plane via MN/SN or SN via MN [63]. (i) Option 2 Option 2 uses NR in both the user-plane and the control-plane, and has nothing to do with Long Term Evolution (LTE). Devices, radio access networks (gNBs), and the

5G Service-Based Architecture, Protocol Stack, and Interoperation

293

TABLE 3.8 MR DC-Lists Associated CN

Associated Option

E-UTRA-NR Dual Connectivity (EN-DC)

EPC

Option 3

eNB acts as an MN and en-gNB as a SN.

NR-E-UTRA Dual Connectivity (NE-DC) NG-RAN E-UTRA-NR Dual Connectivity (NGEN-DC)

5GC

Option 4

5GC

Option 7

gNB acts as an MN and ng-eNB acts as a SN. ng-eNB acts as an MN and another gNB as a SN.

NR-NR Dual Connectivity (NR-DC)

5GC

Option 2

Lists

Note

One gNB acts as an MN and another gNB as a SN.

core network all make up what is known as the 5G System (5GS), which includes 5G SA Option 2. (5GC). Enhanced Mobile Broadband (eMBB), Massive Machine-Type Communication (mMTC), Ultra-Reliable Low-Latency Communication (URLLC), and network slicing are just some of the new 5G services that can take advantage of this capability. Upgrading an eNB for interworking with the NR system is simplified by the fact that dual connection is not required [66]. (ii) Option 3/3a/3x Figure 3.172 shows the architecture of these three options [67]. In Option 3, all traffic (including 5G NR traffic) must go through the eNB that serves as an MN. There is no direct connection between the en-gNB and the EPC. The key features are: • The S1-U and S1-C which stand for the user plain and control plain interfaces respectively are anchored at the eNB as shown in Figure 3.172. • It is not possible for the EPC to observe mobility signaling between an LTE eNB and an NR en-gNB. • S1-U and S1-C are split at the eNB. • The eNB is put under more stress because it must handle user traffic from both LTE and 5G networks. • The X2-C and X2-U interfaces accommodate the control plane and 5G user traffic, as well as the related needs for flow control and latency. • Split/switched bearer in eNB i.e., traffic delivered over LTE when UE is outside of NR coverage has a minimal effect on UE mobility interruption (NR to LTE). In Option 3a, both the eNB and the gNB can directly communicate to the EPC. The X2-C interface solely carries control signals and does not transmit any data. The key features are:

FIGURE 3.172  Comparing Options 3, 3a, and 3x.

294 5G NR Modeling in MATLAB®

5G Service-Based Architecture, Protocol Stack, and Interoperation

295

• The S1-U is anchored at en-gNB. • S1 path transition reveals mobility signals between the older eNB and the en-gNB to the EPC. • There is no data delivery across NR, and S1-U is not partitioned. There is no need for the eNB to control more traffic or take on additional load. • X2-interface is used for control plane traffic only. • The need for an S1-U route transfer from an en-gNB to an eNB increases the impact of UE mobility interruptions (from NR to LTE). The third possible configuration (3x) establishes a direct connection between the engNB and the EPC, allowing for unrestricted data transfer between the two nodes. A subset of the data can also be delivered to the eNB across the X2-U interface. The key features are: • The S1-U is anchored at the gNB. • Mobility between eNB (LTE) and gNB (NR) is visible to EPC due to the S1-U path switch. • S1-U splits at the en-gNB. • The eNB can transmit some fraction of user data. • X2-interface needs to support a control plane, split user traffic, flow control and strict latency requirements. • Impact of UE mobility interruption (NR to LTE) is limited due to split/ switched bearer i.e., traffic sent via X2-interface to LTE when UE is outside the coverage of NR. S1 path switch also leads to some impact [67]. (iii) Option 4/4a The NSA Option 4 family has the gNB connected to the 5GC and the ngNB connected to the gNB. If you go this route, you will need to upgrade your eNB to a ng-eNB so it can communicate with your 5GC or gNB. With this configuration, NR and LTE traffic can be aggregated in a single NE-DC. The option is further divided into two types depending on the traffic split method used, as shown in Figure 3.173. The NSA Option 4 has the gNB connected to the 5GC and the ngNB connected to the gNB. If you go this route, you will need to upgrade your eNB to a ng-eNB so it can communicate with your 5GC or gNB. With this configuration, NR and LTE traffic can be aggregated in a single NE-DC. In Option 4/4a, there can be a Dual Connectivity between the gNB (similar role as MeNB in TS 36.300) and the NGC with NSA E-UTRA (similar role as SeNB in TS 36.300). The E-UTRA user plane connection to the NGC can go either via the gNB, i.e., Option 4 or directly i.e., Option 4a [63]. (iv) Option 5 Option 5 is an SA configuration in which the ng-eNB is linked to the 5GC via the NG interface, but no NR systems are used. The 5GC would take the place of the EPC in the current LTE network should this option be chosen. The eNB must be

296

5G NR Modeling in MATLAB®

FIGURE 3.173  Options 4 and 4a.

updated so that it can communicate with the 5GC. The ng-eNB can provide various 5GC-enabling benefits such as network slicing. This option, however, is not optimal because it does not make use of the mmWave, numerous numerologies, and variable frame structure that are hallmarks of the 5G NR air interface. (v) Option 7/7a/7x The Option 7 family is an NSA configuration in which the eNB is linked to the 5GC and the gNB is linked to itself. For this to operate, the eNB would need to be updated to a ng-eNB so that it could communicate with a 5GC or gNB. NGEN-DC, or dual connection, is supported so that NR and LTE traffic can be combined. This option is divided into three types based on the traffic split method as shown in Figure 3.174. When considering the control plane, it is important to note that for all variants of Option 7, the master ng-eNB is linked to the 5GC and communicates with the gNB via the Xn interface. However, in Option 7, traffic splitting occurs at the 5GC for the user plane, whereas in Option 7a, it occurs at the ng-eNB. As per Option 7, the ng-eNB can either relay all user plane traffic from the 5GC to the UE over the LTE air interface, bypassing the gNB via the Xn interface, or relay some of the data through the gNB. Option 7a allows for user traffic to be sent and received between the 5GC and both the ng-eNB and the gNB. Option 7x is a hybrid of Options 7 and 7a, in which the 5GC sends user traffic to either the ng-eNB or the gNB, and then the ng-eNB sends the traffic to the UE over the LTE air interface. Data received from the 5GC can be sent directly to the UE over the NR air interface by the gNB, or some of the traffic can be sent to the ng-eNB via the Xn interface [63]. (vi) Non-Standalone vs Standalone Table 3.9 summarizes the major differences between the different NR deployment options, as specified in the previous section. Options 1 (legacy LTE) and 5 (least likely to be adopted) are not considered. For Options 3, 4, and 7 that use the current

FIGURE 3.174  NR architecture variants of Option 7.

5G Service-Based Architecture, Protocol Stack, and Interoperation

297

298

5G NR Modeling in MATLAB®

TABLE 3.9 Comparison between Deployment Options NSA

SA

Items

Option 3

Associated DC

EN-DC

Opt. 4: NE-DC Opt. 7: NGEN-DC

Option 4, Option 7

NR-DC (Not mandatory)

Option 2

Required CN Required RAN Feasibility of 5G Spectrum Required time for 5G Deployment LTE Upgrade Alignment with LTE Interworking with LTE

EPC eNB, en-gNB Sub-6 GHz, mmWave

5GC ng-eNB, gNB Sub-6 GHz, mmWave

Short

Long

5GC gNB Sub-6 GHz (desirable), mmWave Long

Control anchor

Major upgrade Preferred Tight interworking between LTE and NR LTE

Minor upgrade Not required CN-level interworking (Inter-RAT mobility) NR

Supporting 5G service

eMBB

Supporting voice service

VoLTE

Major upgrade Preferred Tight interworking between LTE and NR Opt. 4: NR Opt. 7: LTE Support at gNB side (eMBB, URLLC, mMTC, Network Slicing) VoNR (VoLTE by fallback is possible when VoNR is unavailable)

Multivendor interoperability

Not Easy

Not Easy

Easy

Full support (eMBB, URLLC, mMTC, Network Slicing) VoNR (VoLTE by fallback is possible when VoNR is unavailable)

LTE network, sub-6GHz bands are recommended for NR implementation due to the need for alignment with the LTE network. They also need to cooperate closely with LTE by employing dual connectivity options like EN-DC/NE-DC or NGEN-DC. However, configuring a 5G network for NR rollout using Option 2 is without cost. For instance, mmWave can be used for urban hotspots, whereas mid-band can be used for widespread NR coverage. While Option 3 can offer some form of 5G service, such eMBB, due to EPC, only alternatives 2, 4, and 7 can offer true 5G-only services. It is feasible to consider Options 4 and 7 as SA because the architecture that includes NR RAN as an MN and 5GC [63] allows them to provide 5G-specific services, despite the fact that they are classified as NSA by the 3GPP.

3.3.2 Migration Paths to 5G Standalone Architecture Both a direct migration to Option 2, the ultimate 5G aim, and an indirect migration to Option 2, via Option 3, are feasible alternatives among the several NR deployment options [63].

5G Service-Based Architecture, Protocol Stack, and Interoperation

299

(a) Direct Migration to Option 2 This migration strategy begins using 5G CN and RAN. It establishes an independent 5G network and does not rely on the existing LTE network to offer a 5G service. The recommended migration route is depicted in Figure 3.175 for Option 2. Its straightforward design makes it easy to administer, and it has minimal effect on the current LTE infrastructure because LTE and NR networks are managed by separate entities. This architecture calls for standard-based interworking between the EPC and 5GC for inter-RAT mobility. Vendor lock-ins are avoided, and new 5G vendors can enter the market. Since both the 5G CN and RAN are ready to go from the get-go, there is no major limitation to delivering 5G capabilities and services like URLLC or network slicing. Inter-RAT mobility is supported via the N26 interface between the EPC and 5GC, ensuring reliable service continuity. As will be seen below, an SA UE is capable of handling both LTE and NR connections independently, connecting to either the LTE or NR network as needed. When a UE is in a 5G coverage region, it can join the 5G network. After leaving 5G coverage and entering 4G coverage, the gNB evaluates the UE's measurement report to determine if inter-RAT mobility should be performed. The gNB then uses the EPC-5GC interface to determine whether to do a handover or a redirection based on the results of the measurements. As a result, the UE establishes a connection with the LTE network and disconnects from the 5G network while retaining the same IP address to ensure uninterrupted service. In this case, dual connectivity is optional. As illustrated in Figure 3.176, an operator needs to consider additional NR migration on its remaining LTE band as the number of LTE-only UE decreases and the number of NR UE rises. Spectrum refarming is the standard migration approach in such cases, but it can take a long time and a lot of work to accomplish. As an alternate migration path, Dynamic Spectrum Sharing (DSS) enables the 5G network to utilize the current LTE spectrum. DSS makes it possible for both LTE and NR to

FIGURE 3.175  Migration architecture based on Option 2.

300

5G NR Modeling in MATLAB®

FIGURE 3.176  Migration method on remaining LTE band.

use the same legacy LTE carrier. As the traffic demands of LTE and NR fluctuate in real-time, DSS dynamically reallocates resources between the two networks [68].​ One drawback of this migration strategy is the high up-front cost associated with launching standalone 5G networks comprising 5GC and gNB. An operator’s OPEX is increased since the EPC must be maintained until the 4G network is replaced with the 5G network. Since there is no LTE capability in Option 2, an operator’s cell coverage may degrade if they choose to deploy NR utilizing the mid-band rather than the NSA option. In this situation, the 3GPP defines Massive MIMO, DFT-S-OFDM, and High Power UE (HPUE) to improve UL coverage. An early adopter operator that uses SA will have a competitive advantage over those that wait to roll out their 5G services. This operator has a better chance of profiting from emerging 5G markets. Since temporary NSA UEs are unnecessary, a seamless and rapid transition to a fully functional 5G SA network is feasible. (b) Migration Path to Option 2 via Option 3 Family For operators who already have an LTE network with EPC, 5G deployment utilizing EN-DC (Option 3) may be the best solution. With this method, an existing LTE network can get 5G up and running quickly and at a minimal cost by adding en-gNB. However, until a 5GC is integrated into the network, 5G-specific services such as URLLC and network slicing cannot be provided by this option. If an operator wants to provide users with the entire breadth of 5G services, it will need to migrate to Option 2 at some point in the future, which rules out Option 3. In addition, with option 3, more time is required until all interim NSA UEs have been relocated. Figure 3.177 depicts potential routes for migrating to 5G using NSA options like 3x and 4 [63]. Migration Phase I Option 3x is applied on the traditional LTE network. The existing LTE network has an en-gNB added to it and it is linked to the EPC. In order to boost data throughput, 5G NSA UE with EN-DC capability can connect to the LTE network and aggregate both LTE and NR via EN-DC, whereas LTE UE connects only to the legacy LTE network. In areas with limited NR coverage, LTE eNB is used to make the service more reliable. Radio resources in EN-DC are shared between Master Cell Group (MCG)-bearers (using LTE) and Secondary Cell Group (SCG)-bearers (using NR). When a bearer is split, it uses both LTE and NR data. Since 5GC has not been released yet, the QoS mechanism relies on

301

FIGURE 3.177  Example of migration roadmap to 5G SA via NSA options.

5G Service-Based Architecture, Protocol Stack, and Interoperation

302

5G NR Modeling in MATLAB®

4G. For this to operate, the eNB and en-gNB must communicate effectively with one another using the X2 interface. Therefore, in order for legacy eNB and EPC to interoperate with en-gNB, both must be upgraded. Options 2 and 4 are likewise open to operators who are deciding about implementing a 5GC [63]. Migration Phase II-a At this stage, NSA Option 3 is supplemented with SA Option 2, which includes 5GC. In this setting, the NSA opt.3 UE, SA opt.2 UE, and legacy LTE UE all coexist. If the temporary NSA UE no longer exists, the operator may skip Migration Phase II-a and proceed directly to the NR SA Phase. The LTE UE just connects to the LTE network, while the NSA UE uses EN-DC to connect to the LTE network while aggregating traffic from both LTE and NR. The SA UE can connect to either LTE or NR depending on its coverage. At this point, the SA UE is ready to receive any and all 5G services. Migration Phase II-b Legacy LTE UE, NSA Option3/4 UE and SA Option 2 UE can all coexist in this stage, as SA Option 2 and NSA Option 4, with 5GC, are added to NSA Option 3. Similar to how we discussed in Migration Phase II-a, NSA Option 3 UE or SA UE functions in the exact same way. The NSA Option 4 UE connects to the gNB with traffic aggregation of both NR and LTE via NE-DC. When comparing LTE Carrier Aggregation (CA) and EN-use DC’s of many carriers, the SA UE may not benefit from the same massive amounts of data. To deliver 5G services, Options 2 and 4 must be implemented alongside the 5GC. NR SA Phase This is the final step before launching 5G SA. It may take an operator longer to reach this point if there are still a large number of NSA UEs in use. To increase capacity, NR-DC can aggregate traffic across both NR frequencies if they are both accessible. If an operator wants to make use of the remaining LTE band, they may decide to migrate it to NR by refarming or DSS. This would be carried out on the premise that the quantity of LTE UEs is negligible [63, 68].

REFERENCES

1. Keith Allan, “vEPC in LTE Networks: Time to Move Ahead”, Nokia Blog, Available Online: https://blog​.tmcnet​.com ​/next​-generation​-communications​/2015​/03​/vepc​-in​-lte​ -networks​-time​-to​-move​-ahead​.html 2. Devopedia, “5G Service-Based Architecture”, 2022. Version 6, February 15, Available Online: https://devopedia​.org​/5g​-service​-based​-architecture [Accessed 10 October 2022]. 3. Service Based Architecture, “MPIRICAL”, Available Online: https://www​.mpirical​ .com​/glossary​/sba​-service​-based​-architecture 4. ETSI, “TS 129 500: 5G; 5G System; Technical Realization of Service Based Architecture; Stage 3”, 2021e, V16.6.0, January, Available Online: https://www​.etsi​.org​ /deliver​/etsi​_ts​/129500​_129599​/129500​/16​.06​.00​_60​/ts​_129500v160600p​.pdf 5. Georg Mayer, “RESTful APIs for the 5G Service Based Architecture”, Journal of ICT Standardization 6(1&2), 101–116 (2018). https://doi​.org​/10​.13052​/jicts2245​-800X​.617

5G Service-Based Architecture, Protocol Stack, and Interoperation

303

6. Dan Wang and Tao Sun (Eds), “Service-Based Architecture in 5G”, NGMN Alliance, 2018, Available Online: https://www​.ngmn​.org​/wp​-content​/uploads​/ Publications​/2018​ /180119​_ NGMN​_ Service​_Based​_ Architecture​_in​_ 5G​_v1​.0​.pdf 7. ETSI TS 123 501, “System Architecture for the 5G System (3GPP TS 23.501 Version 15.3.0 Release 15)”, Available Online: https://www​.etsi​.org​/deliver​/etsi​_ts​/123500​ _123599​/123501​/15​.03​.00​_60​/ts​_123501v150300p​.pdf 8. Stefan Rommer, Peter Hedman, Magnus Olsson, Lars Frid, Shabnam Sultana and Catherine Mulligan, 5G Core Networks: Powering Digitalization. Elsevier Science, 2019. ISBN: 0081030096, 9780081030097. 9. Devaki Chandramouli (Rapporteur, Nokia, Germany), “System Architecture for the 5G System”, Tech-Invite, Available Online: https://www​.tech​-invite​.com​/3m23​/tinv​ -3gpp​-23​-501​.html 10. Marin Ivezic, “Introduction to 5G Core Service-Based Architecture (SBA) Components”, Available Online: https://5g.security/5g-technology/5g-core-sba-components-architecture/ 11. R. Fielding, “Architectural Styles and the Design of Network based Software Architectures”, Dissertation, University of California, Irvine, 2000, Available Online: https://www​.ics​.uci​.edu/∼fielding/pubs/dissertation/fielding dissertation​.p​df 12. Stefan Rommer, Peter Hedman, Magnus Olsson, Lars Frid, Shabnam Sultana and Catherine Mulligan, 5G Core Networks: Powering Digitalization. Elsevier Science, 2019. ISBN:0081030096, 9780081030097 13. W3Schools, “JSON – Introduction”, Available Online: https://www​.w3schools​.com​/js​/ js​_ json​_intro​.asp 14. dspcsp​.com, “5G Core and Service Based Architecture”, Available: https://www​.dspcsp​ .com​/tau​/5G​/09​-core​.pdf 15. Pethrus Gärdborn, “Is QUIC a Better Choice than TCP in the 5G Core Network Service Based Architecture?”, Degree Project Information And Communication Technology, Stockholm, 2020, Available Online: https://www​.diva​-portal​.org​/smash​/get​/diva2​ :1520258​/ FULLTEXT01​.pdf 16. Ka-cheong Leung, Victor O.K. Li and Daiqin Yang, “An Overview of Packet Reordering in Transmission Control Protocol (TCP): Problems, Solutions, and Challenges”, IEEE Transactions on Parallel and Distributed Systems 18(4), 522–535 (Apr. 2007). ISSN: 2161-9883. https://doi​.org​/10​.1109​/ TPDS​.2007​.1011 17. RFC 8446, “The Transport Layer Security (TLS) Protocol Version 1.3”, Available Online: https://datatracker​.ietf​.org​/doc​/rfc8446/ 18. Jim Roskind, “Multiplexed Stream Transport over UDP”, Available Online: https:// docs​.google​.com​/document​/d​/1RNHkx​_VvKWyWg6Lr8SZ - saqsQx7rFV - ev2jRFUoVD34 / 19. ETSI TS 123 501 V16.6.0 (2020-10), “System Architecture for the 5G System (5GS) (3GPP TS 23.501 Version 16.6.0 Release 16)”, Available Online: https://www​.etsi​.org​/ deliver​/etsi​_ts​/123500​_123599​/123501​/16​.06​.00​_60​/ts​_123501v160600p​.pdf 20. ETSI TS 123 502 V15.2.0 (2018-06), “Procedures for the 5G System (3GPP TS 23.502 Version 15.2.0 Release 15)”, Available Online: https://www​.etsi​.org​/deliver​/etsi​_ts​ /123500​_123599​/123502​/15​.02​.00​_60​/ts​_123502v150200p​.pdf 21. ETSI TS 123 288 V17.4.0 (2022-05), “5G; Architecture Enhancements for 5G System (5GS) to Support Network Data Analytics Services (3GPP TS 23.288 Version 17.4.0 Release 17)”, Available Online: https://www​.etsi​.org​/deliver​/etsi​_ts​/123200​_123299​ /123288​/17​.04​.00​_60​/ts​_123288v170400p​.pdf 22. ETSI TS 129 501 V16.4.0 (2020-11), “5G; 5G System; Principles and Guidelines for Services Definition; St age 3 (3GPP TS 29.501 Version 16.4.0 Release 16)”, Available Online: https://www​.etsi​.org​/ deliver​/etsi​_ts​/129500​_129599​/129501​/16​.04​.00​_60​/ts​_129501v160400p​.pdf

304

5G NR Modeling in MATLAB®

23. ETSI TS 129 503 V15.0.0 (2018-07), “5G;5G System; Unified Data Management Services; Stage 3 (3GPP TS 29.503 Version 15.0.0 Release 15)”, Available Online: https://www​ . etsi ​ . org ​ / deliver ​ / etsi ​ _ ts ​ / 129500 ​ _ 129599​ / 129503​ / 15​ . 00​ . 00​ _ 60​ / ts​ _129503v150000p​.pdf 24. ETSI TS 129 509 V15.4.0 (2019-07), “5G; 5G System; Authentication Server Services; Stage 3 (3GPP TS 29.509 Version 15.4.0 Release 15)”, Available Online: https://www​ .etsi​.org​/deliver​/etsi​_ts​/129500​_129599​/129509​/15​.04​.00​_60​/ts​_129509v150400p​.pdf 25. ETSI TS 129 511 V15.5.0 (2020-01), “5G; 5G System; Equipment Identity Register Services; Stage 3 (3GPP TS 29.511 Version 15.5.0 Release 15)”, Available Online: https:// www​.etsi​.org​/deliver​/etsi​_ts​/129500​_129599​/129511​/15​.05​.00​_60​/ts​_129511v150500p​ .pdf 26. ETSI TS 132 290 V16.5.0 (2020-11), “5G; Telecommunication Management; Charging Management; 5G System; Services, Operations and Procedures of Charging Using Service Based Interface (SBI) (3GPP TS 32.290 Version 16.5.0 Release 16)”, Available Online: https://www​.etsi​.org​/deliver​/etsi​_ts​/132200​_132299​/132290​/16​.05​.00​_60​/ts​ _132290v160500p​.pdf 27. ETSI TS 129 504 V15.1.0 (2018-10), “5G; 5G System; Unified Data Repository Services; Stage 3 (3GPP TS 29.504 Version 15.1.0 Release 15)”, Available Online: https:// www​.etsi​.org​/deliver​/etsi​_ ts​/129500​_129599​/129504​/15​.01​.00​_ 60​/ts​_129504v150 100p​.pdf 28. ETSI TS 129 598 V16.1.0 (2020-07), “5G; Unstructured Data Storage Services (3GPP TS 29.598 Version 16.1.0 Release 16)”, Available Online: https://www​.etsi​.org​/deliver​/ etsi​_ts​/129500​_129599​/129598​/16​.01​.00​_60​/ts​_129598v160100p​.pdf 29. ETSI TS 129 591 V16.1.0 (2020-08), “5G; 5G System (5GS); Network Exposure Function Southbound Services; Stage 3 (3GPP TS 29.591 Version 16.1.0 Release 16)”, Available Online: https://www​.etsi​.org​/deliver​/etsi​_ts​/129500​_129599​/129591​/16​.01​.00​ _60​/ts​_129591v160100p​.pdf 30. ETSI TS 129 517 V16.1.0 (2020-08), “5G; 5G System; Application Function (AF) Event Exposure Service; Stage 3 (3GPP TS 29.517 Version 16.1.0 Release 16)”, Available Online: https://www​.etsi​.org​/deliver​/etsi​_ts​/129500​_129599​/129517​/16​.01​.00​_60​/ts​ _129517v160100p​.pdf 31. ETSI TS 129 531 V16.3.0 (2020-07), “5G; 5G System; Network Slice Selection Services; Stage 3 (3GPP TS 29.531 Version 16.3.0 Release 16)”. 32. ETSI TS 129 526 V16.2.0 (2021-01), “5G; 5G System; Network Slice-Specific Authentication and Authorization (NSSAA) services; Stage 3(3GPP TS 29.526 Version 16.2.0 Release 16)”, Available Online: https://www​.etsi​.org​/deliver​/etsi​_ts​/129500​ _129599​/129531​/16​.03​.00​_60​/ts​_129531v160300p​.pdf 33. ETSI TS 129 520 V15.3.0 (2019-04), “5G; 5G System; Network Data Analytics Services; Stage 3 (3GPP TS 29.520 Version 15.3.0 Release 15)”, Available Online: https://www​ .etsi​.org​/deliver​/etsi​_ts​/129500​_129599​/129520​/15​.03​.00​_60​/ts​_129520v150300p​.pdf 34. ETSI TS 129 510 V16.4.0 (2020-07), “5G; 5G System; Network Function Repository Services; Stage 3 (3GPP TS 29.510 Version 16.4.0 Release 16)”, Available Online: https:// www​.etsi​.org​/deliver​/etsi​_ts​/129500​_129599​/129510​/16​.04​.00​_60​/ts​_129510v160400p​ .pdf 35. ETSI TS 129 572 V16.6.0 (2021-04), “5G; 5G System; Location Management Services; Stage 3 (3GPP TS 29.572 Version 16.6.0 Release 16)”, Available Online: https://www​ .etsi​.org​/deliver​/etsi​_ts​/129500​_129599​/129572​/16​.06​.00​_60​/ts​_129572v160600p​.pdf 36. ETSI TS 129 515 V16.1.0 (2020-07), “5G; 5G System; Gateway Mobile Location Services; Stage 3 (3GPP TS 29.515 Version 16.1.0 Release 16)”, Available Online: https:// www​.etsi​.org​/deliver​/etsi​_ts​/129500​_129599​/129515​/16​.01​.00​_60​/ts​_129515v160100p​ .pdf

5G Service-Based Architecture, Protocol Stack, and Interoperation

305

37. ETSI TS 129 521 V15.3.0 (2019-04), “5G; 5G System; Binding Support Management Service; Stage 3 (3GPP TS 29.521 Version 15.3.0 Release 15)”, Available Online: https:// www​.etsi​.org​/deliver​/etsi​_ts​/129500​_129599​/129521​/15​.03​.00​_60​/ts​_129521v150300p​ .pdf 38. ETSI TS 123 501 V15.3.0 (2018-09), “5G; System Architecture for the 5G System (3GPP TS 23.501 Version 15.3.0 Release 15)”, Available Online: https://www​.etsi​.org​/ deliver​/etsi​_ts​/123500​_123599​/123501​/15​.03​.00​_60​/ts​_123501v150300p​.pdf 39. Stefan Rommer, Peter Hedman, Magnus Olsson, Lars Frid, Shabnam Sultana and Catherine Mulligan, 5G Core Networks: Powering Digitalization. Elsevier Science, 2019. ISBN: 0081030096, 9780081030097. 40. Devopedia, “5G NR Channels”, Available Online: https://devopedia​.org​/5g​-nr​-channels​#Electronics​-Notes​-2021 41. Erik Dahlman, Stefan Parkvall and Johan Sköld, 5G NR The Next Generation Wireless Access Technology. Academic Press, Copyright © 2018 Elsevier Ltd. All rights reserved. https://doi​.org​/10​.1016​/C2017​- 0​- 01347-2 42. Sassan Ahmadi, 5G NR Architecture, Technology, Implementation, and Operation of 3GPP New Radio Standards. Elsevier Inc, Copyright © 2019. All rights reserved. https://doi​.org​/10​.1016​/C2016 ​- 0 ​- 04944-6 43. 3GPP TS 38.331, “NR, Radio Resource Control (RRC); Protocol Specification (Release 15)”, December 2018. 44. 3GPP TS 38.300, “NR, Overall Description, Stage-2 (Release 15)”, December 2018. 45. 3GPP TS 38.321, “NR, Medium Access Control (MAC) Protocol Specification (Release 15)”, December 2018. 46. Abhijeet Kumar, “Packet Data Convergence Protocol(PDCP) NR”, Cafetele 2023, Available Online: https://cafetele​.com ​/packet​-data​-convergence​-protocolpdcp​-nr/ 47. ETSI TS 138 322 V16.2.0 (2021-01), “5G; NR; Radio Link Control (RLC) Protocol Specification (3GPP TS 38.322 Version 16.2.0 Release 16)”, Available Online: https:// www​.etsi​.org​/deliver​/etsi​_ts​/138300​_138399​/138322​/16​.02​.00​_60​/ts​_138322v160200p​ .pdf 48. ETSI TS 138 321 V16.1.0 (2020-07), “5G; NR; Medium Access Control (MAC) Protocol Specification (3GPP TS 38.321 Version 16.1.0 Release 16)”, Available Online: https:// www​.etsi​.org​/deliver​/etsi​_ts​/138300​_138399​/138321​/16​.01​.00​_60​/ts​_138321v160100p​ .pdf 49. Devopedia, “5G NR MAC PDU”, Available Online: https://devopedia​.org​/5g​-nr​-mac​ -pdu 50. ETSI, 2018, ETSI TS 138 300 V15.3.1 (2018–10) [Online], Available Online: https://www​ .etsi​.org​/deliver​/etsi​_ts​/138300​_138399​/138300​/15​.03​.01​_60​/ts​_138300v150301p​.pdf 51. Sciencedirect, “Physical Resource Block” [Online] 2018, Available Online: https:// www​.sciencedirect​.com ​/topics​/computer​-science​/physical​-resource​-block 52. Intel, “5G NR-Driving Wireless Evolution into New Vertical Domains” [Online] 2018, Available Online: https://www​.intel​.ca​/content​/www​/ca​/en​/wireless​-network ​/5g​-technology​/standards​-and​-spectrum​/5g​-nr​-technology​.html 53. ETSI TS 138 202 V15.3.0 (2018-10), “5G; NR; Services Provided by the Physical Layer (3GPP TS 38.202 Version 15.3.0 Release 15)”, Available Online: https://www​.etsi​.org​/ deliver​/etsi​_ts​/138200​_138299​/138202​/15​.03​.00​_60​/ts​_138202v150300p​.pdf 54. Techplayon, “5G NR Physical Signals and RNTI”, Available Online: https://www​.techplayon​.com ​/5g​-nr​-radio​-network​-temporary​-identifier​-rnti/​#google​_vignette 55. Lucas Dominato, Henrique Cesar de Resende, Cristiano Both, Johann Marquez-Barja, Bruno Silvestre and Kleber Cardoso, “Tutorial on Communication between Access Networks and the 5G Core”, Available Online: https://www​.researchgate​.net​/publication​ /356891201​_Tutorial​_on​_communication​_between​_access​_networks​_and​_the​_5G​_core

306

5G NR Modeling in MATLAB®

56. 3GPP, “NG Application Protocol (NGAP)”, 3rd Generation PartnershipProject-3GPP, Sophia Antipolis CEDEX, France, Tech. Rep. 3GPP TS38.413 V16.2.0, 08 2020, https:// www​.3gpp​.org​/ftp​/Specs​/archive​/38series​/38​.413/ 57. 3GPP TS 23.502 V16.3.0, Procedures for the 5G System (5GS); Stage 2. (December 2019). 58. Enida Mataj, “Network Slicing and QoS in 5G Systems and their Impact on the MAC Layer”, Master Thesis, Department of Electronics and Telecommunications, Politecnico di Torino, 2020, Available Online: https://webthesis​.biblio​.polito​.it​/15275​/1​/tesi​.pdf 59. Devopedia, “5G NR SDAP”, Available Online: https://devopedia​.org​/5g​-nr​-sdap 60. ETSI, “TS 137 324: LTE; 5G; Evolved Universal Terrestrial Radio Access (E-UTRA) and NR; Service Data Adaptation Protocol (SDAP) Specification”, V16.2.0, November 2020a, Available Online: https://www​.etsi​.org​/deliver​/etsi​_ts​/137300​_137399​/137324​ /16​.02​.00​_60​/ts​_137324v160200p​.pdf 61. ETSI TS 129 281 V15.7.0 (2020-01), “Universal Mobile Telecommunications System (UMTS); LTE; 5G; General Packet Radio System (GPRS), Tunnelling Protocol User Plane (GTPv1-U), (3GPP TS 29.281 Version 15.7.0 Release 15)”, Available Online: https://cdn​.standards​.iteh​.ai​/samples​/59004​/531​627d​a ff2​5432​4887​bd42​1c37793d5​/ ETSI​-TS​-129​-281​-V15​-7​- 0​-2020​- 01-​.pdf 62. Devopedia, “5G Deployment Options”, Available Online: https://devopedia​.org​/5g​ -deployment​-options 63. Samsung, “5G Standalone Architecture”, Technical White Paper, January 2021, Available Online: https://images​.samsung​.com ​/is​/content ​/samsung​/assets​/global ​/ business​/networks​/insights​/white ​-papers​/0107​_ 5g​-standalone ​-architecture​/5G ​_ SA​ _Architecture​_Technical​_White​_ Paper​_ Public​.pdf 64. 3GPP TR38.801, “Radio Access Architecture and INTERFACE” Rel.14. 65. 3GPP TR23.799, “Study on Architecture for Next Generation System” Rel.14. 66. GSMA, “5G Implementation Guidelines: SA Option 2”, June 2020, Available Online: https://www​.gsma​.com ​/futurenetworks​/wp​-content ​/uploads​/2020​/06​/5G​-SA​-Option​-2​ -Imp​leme​ntat​ionG​uideline​-v1​.3​.pdf 67. M. Agiwal, H. Kwon, S. Park and H. Jin, “A Survey on 4G-5G Dual Connectivity: Road to 5G Implementation”, IEEE Access 9, 16193–16210 (2021). https://doi​.org​/10​.1109​/ ACCESS​.2021​.3052462 68. G. Barb, F. Alexa and M. Otesteanu “Dynamic Spectrum Sharing for Future LTE-NR Networks”, Sensors 21, 4215 (2021). https://doi​.org​/10​.3390​/s21124215

4

Physical Layer Processing with Numerical and MATLAB® Modeling

5G New Radio (NR) is the fifth generation of cellular network which will bring massive improvements in throughput, latency, and capacity. 5G NR will be a powerful platform that can support vertical industries such as e-health, transport, energy, media, and factories automation. The 3rd Generation Partnership Project (3GPP) is actively working on the technical specifications of 5G NR. 5G NR first appeared in 3GPP Release 14 where a thorough study on the technologies was carried out. Then in 3GPP Release 15, the technical specifications for Enhanced Mobile Broadband (eMBB) were established. 3GPP Release 16 in which the technical specifications for Ultra-Reliable Low Latency Communications (URLLC) and Massive Machine-Type Communications (mMTC) is in the works. In this book, the transmission of transport blocks over 5G NR’s Packet Data Shared Channel (PDSCH) is described in detail along with MATLAB® codes which can be used to simulate the latter. To better illustrate the processes involved in the PDSCH processing chain, numerical examples are also given. MathWorks introduced MATLAB’s 5G Toolbox which provides standardcompliant functions and examples for the simulation of the 5G environment. In this book, functions from the toolbox were used to build the 5G NR end-toend physical layer model for PDSCH processing and to calculate the PDSCH throughput, Bit Error Rate (BER) and Block Error Rate (BLER). The processing loop is summarized in Figure 4.1 and each process block is described in detail in Sections 4.1 and 4.2. The modeling of the processing chain using MATLAB is then demonstrated in Chapter 5.

4.1 TRANSMITTER MODELING In this section, the transmitter of the 5G physical layer model for PDSCH processing is described. Figure 4.2 shows the process blocks in the transmitter model and the data formats at each input of each process block. 5G NR can support the transmission of up to two parallel message code-words simultaneously. We denote the input code-word to the Downlink Shared Channel (DLSCH) process block for the message code-word with index a (0 or 1) as in a and the bits in the code-word as in a ( 0 ) , in a (1) ,¼, in a ( N A - 1) , where N A is the total number of bits per input message code-word [1]. For example, if two message DOI: 10.1201/9781003465393-4

307

308

5G NR Modeling in MATLAB®

FIGURE 4.1  5G NR physical layer PDSCH processing loop.

FIGURE 4.2  5G NR physical layer PDSCH processing transmitter model.

309

Physical Layer Processing with Numerical and MATLAB® Modeling

code-words are transmitted simultaneously, the first bit in the second message codeword is denoted as in1 ( 0 ) . Cyclic Redundancy Check (CRC) attachment is performed on the input code-words to produce the output code-word with bits denoted by b a ( 0 ) , b a (1) ,¼, b a ( N B - 1) . The code-word is then segmented into NC segments of size K and the bits in segment x for the message code-word is denoted by c xa ( 0 ), c xa (1) ,…, c xa ( K - 1) [1]. Low Density Parity Check (LDPC) encoding is applied to each segment to produce LDPC code-words of length ND, where the bits in the xth segment of the message code-word with index a are represented in the form d xa ( 0 ) , d xa (1) ,…, d xa ( N D - 1) . Rate matching is then performed on each LDPC code-word to obtain code-words of

(

)

lengths N F a consisting of the bit sequence f xa ( 0 ) , f xa (1) ,¼, f xa N F a - 1 . Finally, x x all rate-matched outputs are sequentially concatenated in a single code-word of length NG [1]. The concatenated code-word for the message code-word with index a is denoted as g a ( 0 ) , g a (1) ,¼, g a ( N G - 1) . PDSCH encoding is then performed on the concatenated code-words. The concatenated code-words g a ( 0 ) , g a (1) ,¼, g a ( N G - 1) are scrambled into code-words of similar length, denoted by g ’a ( 0 ) , g ’a (1) ,¼, g ’a ( N G - 1) . The bits in the scrambled code-words are then mapped onto sets of complex-valued modulation symbols denoted by h a ( 0 ) , h a (1) ,¼, h a ( N H - 1) . Finally, the modulation symbols are mapped onto Multi-Input Multi-Output (MIMO) layers. The lth layer, J l-1 , consists

)

(

of symbols j l -1 ( 0 ) , j l -1 (1) ,¼, j l -1 N J ( l -1) - 1 where N J ( l-1) is the number of symbols in the lth layer [1]. Precoding is then performed to map the layer-mapped symbols to antenna ports. The symbols mapped on the pth antenna port are denoted by

)

(

k r -1 ( 0 ) , k r -1 (1) ,¼, k r -1 N k( r -1) - 1 where N k ( r -1) is the number of symbols in the pth port [1]. Finally, Cyclic Prefix-Orthogonal Frequency Division Multiplexing (CP-OFDM) is performed to obtain a time-continuous signal where the mth OFDM symbol in a r ,m subframe is denoted by s ( ) t where µ is the waveform numerology discussed in m

()

Subsection 4.1.4.3. The CP-OFDM signal is then transmitted through the channel [1]. The process blocks in the transmitter are described in detail in Subsections 4.1.1 to 4.1.4.

4.1.1 DLSCH Encoding The Downlink Shared Channel (DLSCH) is a transport channel used to transmit downlink data. DLSCH processing is composed of four subprocesses as illustrated in Figure 4.3. The DLSCH subprocesses are described in Subsections 4.1.1.1 to 4.1.1.7. 4.1.1.1 Transport Block 3GPP has specified a list of Transport Block Sizes (TBS) which are to be used with Release 15 5G NR in the 3GPP Technical Specification (TS) 38.214 [2]. The

310

5G NR Modeling in MATLAB®

FIGURE 4.3  DLSCH encoding.

TBS determination for PDSCH of a User Equipment (UE) in a slot is described next. The number of Resource Elements (REs) allocated for PDSCH within one Physical Resource Block (PRB), N ’RE , is calculated using Equation (4.1) [2]:

(

)

PRB sh PRB N ’RE = N scRB ´ N symb - N DMRS - N oh (4.1)

Physical Layer Processing with Numerical and MATLAB® Modeling

311

FIGURE 4.4  Physical resource block.

Where, N scRB - Number of subcarriers per PRB = 12 sh N symb - Number of symbols of the PDSCH allocation within the slot. PRB N DMRS - Number of REs allocated for Demodulation Reference Signal (DMRS) per PRB PRB N oh - Number of REs allocated for overheads by higher layer protocols

An illustration of a PRB is given in Figure 4.4. The total number of REs in the slot allocated for PDSCH, N RE , is calculated using Equation (4.2) [2].

¢ ) ´ nPRB (4.2) N RE = min ( 156, N RE

Where, nPRB - Total number of PRBs allocated to the UE The intermediate number of information bits, Ninfo , can then be calculated using Equation (4.3) [2].

Ninfo = N RE ´ R ´ Qm ´ v (4.3)

Where, R - PDSCH Code Rate Qm - Modulation Order v - Number of PDSCH Layers N RE - Number of resource elements allocated for PDSCH. TBS is then determined using Ninfo as described below: Case 1: If Ninfo £ 3824 , The quantized intermediate number of information bits, N ’info is obtained using Equation (4.4) [2].

Ninfo æ N ’info = max ç 24, 2 n ´ n ç 2 è

ö ÷÷ (4.4) ø

312

5G NR Modeling in MATLAB®

TABLE 4.1 5G LDPC-Supported Lifting Sizes as per 3GPP TS 38.212 [1] Index

TBS

Index

TBS

Index

TBS

Index

TBS

Index

1

24

21

184

41

552

61

1288

81

2600

TBS

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

32 40 48 56 64 72 80 88 96 104 112 120 128 136 144 152 160 168

22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

192 208 224 240 256 272 288 304 320 336 352 368 384 408 432 456 480 504

42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59

576 608 640 672 704 736 768 808 848 888 928 984 1032 1064 1128 1160 1192 1224

62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79

1320 1352 1416 1480 1544 1608 1672 1736 1800 1864 1928 2024 2088 2152 2216 2280 2408 2472

82 83 84 85 86 87 88 89 90 91 92 93

2664 2728 2792 2856 2976 3104 3240 3368 3496 3624 3752 3824

20

176

40

528

60

1256

80

2536

(

) )

Where,

(

n = max 3, log2 N info - 6

Finally, the smallest TBS which is larger than N ’info is selected from Table 4.1. Case 2: If Ninfo > 3824, The quantized intermediate number of information bits, N ’info is obtained using Equation (4.5).

æ æ æ Ninfo - 24 ö ö ö N ’info = max ç 3840, ç 2 n ´ round ç ÷ ÷÷ ÷ (4.5) n ç ç 2 è ø ø ÷ø è è

Where,

(

)

n = log2 N info - 24 - 5

Finally, TBS is calculated using Equation (4.6):

Physical Layer Processing with Numerical and MATLAB® Modeling

313

é N ’info + 24 ù TBS = 8 ´ C ê - 24 ú (4.6) ë 8´C û

Where,

é N ’info + 24 ù 1 , if R < ê ú 4 ê 3816 ú ê N ’info + 24 ú C=ê , if N ’info > 8424 ú ê 8424 ú ê 1, otherwise ú ê ú êë úû



A numerical example is given below to demonstrate TBS calculation using parameters that are used in the MATLAB simulation given in Section 5.1. NUMERICAL EXAMPLE 4.1 The TBS calculation for a 5G transmission using the parameters below is demonstrated: Number of subcarriers per PRB, N scRB = 12. sh Number of symbols of the PDSCH allocation within the slot, N symb = 12. Number of REs allocated for Demodulation Reference Signal (DMRS) in the PRB, PRB N DMRS = 4. Number of REs allocated for overheads by higher-layer protocols, PRB N oh = 0. Total number of PRBs allocated to the UE, nPRB = 24. 40 PDSCH code rate, R = . 1024 Modulation order, Qm = 2. Number of PDSCH layers, v = 2. The number of REs allocated for PDSCH within one PRB, N ’RE , is calculated using Equation (4.1):

(

)

sh PRB PRB ¢ = N scRB ´ N symb N RE - N DMRS - N oh = (12 ´ 12 ) - 4 - 0 = 140

The total number of resource elements in the slot allocated for PDSCH is calculated using Equation (4.2): ¢ ) ´ nPRB = min (156,140 ) ´ 24= 3360 N RE = min (156, N RE The intermediate number of information bits is calculated using Equation (4.3).

314

5G NR Modeling in MATLAB®

40 ´ 2 ´ 2 = 525 1024 TBS is then determined using Ninfo as described below: Ninfo = N RE ´ R ´ Qm ´ v = 3360 ´

Case 1: Ninfo £ 3824 , The quantized intermediate number of information bits, N ’info is obtained using Equation (4.4). æ é N info ù ö N ’info = max ç 24, 2 n ´ ê n ú ÷ ç ÷ ë 2 ûø è

(

)

n = max 3, log2 ( 525 ) - 6 = max ( 3, 3 ) = 3 525 ö æ ¢ = max ç 24, 23 ´ N info ÷ = max ( 24, 520 ) = 520 23 ø è Finally, the smallest TBS which is larger than N ’info is selected from the table given in Table 4.1. TBS = 528 The hPDSCHTBS function, which is generated in the 5G Toolbox’s NR PDSCH Throughput example’s folder as described in Section 5.1, can be used to perform the TBS calculation. The function’s syntax is as follows: Tbs = hPDSCHTBS (chs,ndre,scaling) The inputs to the function specified in the syntax are described below: chs: A structure array containing the following fields: TargetCoderate- Code rate used to calculate transport block sizes. PRBSet- PRBs allocated to the PDSCH. NLayers- Number of PDSCH layers. Modulation- Modulation order. ndre: Number of RE allocated per PRB to PDSCH. scaling: Scaling factor to be applied to the intermediate number of information bits (default value is 1). The function returns the transport block size tbs. A screenshot of the command window after the execution of the function is shown in Figure 4.5. The inputs to the function used in Figure 4.5 are described below: pdsch- Array corresponding to the input chs in the function’s syntax. pdschIndicesInfo.NREPerPRB- Field from the pdschIndicesInfo structure array to store the number of RE allocated per PRB to PDSCH.

Physical Layer Processing with Numerical and MATLAB® Modeling

315

FIGURE 4.5  Command window result—TBS calculation.

The input scaling is not specified, leading the program to use its default value of “1”. 4.1.1.2 Hybrid Automatic Repeat Request (HARQ) 5G NR uses Hybrid Automatic Repeat Request (HARQ) which consists of a combination of the Automatic Repeat Request (ARQ) technique with Forward Error Correction (FEC) to provide reliable data transmission. 5G NR uses a type of HARQ called Incremental Redundancy HARQ (IR-HARQ). In this type of HARQ, the exact replica of the erroneous coded bits are not sent during retransmissions. Instead, another set of coded bits are generated and sent and the use of different parity bits in the retransmitted coded bits allow the code-rate to be lowered and the coding gain to be increased [3]. 5G supports up to 16 HARQ processes for downlink transmission [4]. This implies that instead of transmitting one packet and then waiting to receive an ACK response from the UE before sending the next packet, 16 packets are sent in succession before checking if ACK responses have been received for each packet. In the event of retransmission is required because an ACK response for an HARQ process is not received, a segment of the packet is retransmitted based on a start bit index as defined in Table 4.3. The different versions of the same packet which are sent in case retransmissions are required are called Redundancy Versions (RV). Four RVs are defined in 5G NR and the sequence in which they are used to prioritize performance is [1, 2, 3, 5]. The illustration of the retransmission process given in Figure 4.6 is an example where 16 HARQ processes are used for 5G downlink transmission, with the RV sequence [1, 2, 3]. In this example, packets transmitted in HARQ processes 2, 6, 7, and 13 are erroneously received. Thus the receiver sends a NACK message back to the transmitter. After that the first 16 HARQ processes have been completed, the next 16 processes will include new packets with RV 0 except for HARQ processes 2, 6, 7, and 13 where the same packets which were erroneously received will be sent but using the packets’ RV 2 (based on the RV sequence).

5G NR Modeling in MATLAB®

FIGURE 4.6  HARQ.

316

Physical Layer Processing with Numerical and MATLAB® Modeling

317

The hNewHARQProcesses function, which is generated in the 5G Toolbox’s NR PDSCH Throughput example’s folder as described in Section 5.1, can be used to initialize an array for tracking the HARQ processes. The function’s syntax is as follows: [harqProcesses] = hNew​HARQP​roces​ses(n​umHAR​QProc​esses​,rvse​quenc​e,ncw​) The input to the function specified in the syntax are described below: numHARQProcesses: Number of HARQ processes. rvsequence: Redundancy Version sequence. ncw: Number of code-words. The function returns a structure array containing the following fields: RVSequence- Redundancy Version sequence. ncw- Number of code-words. blkerr - Block error indicator. RV- Redundancy version. RVIdx- Redundancy version ID. The hUpdateHARQProcesses function, which is generated in the 5G Toolbox’s NR PDSCH Throughput example’s folder as described in Section 5.1, can be used to update the array created using the hNewHARQProcess function after each HARQ process. The function’s syntax is as follows: [harqProcess] = hUpdateHARQProcess(harqProcess,ncw) The input to the function specified in the syntax are described below: harqProcess: Array created by hNewHARQProcess which needs to be updated. ncw: Number of code-words. The function returns harqProcess which is an updated version of the input structure array harqProcess. 4.1.1.3 CRC Attachment Cyclic Redundancy Check (CRC) is used in data communication to detect errors in transmitted data streams on the receiver’s side. The data stream to be transmitted is processed using a cyclic generator polynomial which generates a stream of CRC bits which are then appended to the data stream before transmission. On the receiver side, the same polynomial is applied to the CRC encoded data to check if errors have been introduced to the latter. CRC attachment is implemented as the first procedure in the DLSCH encoding block of 5G. For DLSCH, the two cyclic generator polynomials given in Equations (4.7) and (4.8) are defined in 3GPP TS 38.212 [1] to generate CRC of lengths 16 and 24 bits respectively from the input code-word in a :

318



5G NR Modeling in MATLAB®

gCRC16 ( D ) = é D16 + D12 + D 5 + 1ù (4.7) ë û

gCRC 24 A ( D ) = é D 24 + D 23 + D18 + D17 + D14 + D11 + D10 + D 7 + D6 + D 5 + D 4 + D3 + D + 1ù ë û

(4.8) The cyclic generator polynomial gCRC16 ( D ) is used if the message block size, NA, is less than or equal to 3824 bits. Otherwise, gCRC 24 A ( D ) is used. The length of the output of the CRC attachment sub-block is given:

N B = ( N A + N L1 ) bits (4.9)

Where, NL1 is the number of CRC bits appended to the message block.NA is the message block size. We denote the output from the CRC attachment process for the message code-word with index a, as B a and the bits in the output code-word as b a ( 0 ) , b a (1) ,¼, b a ( N B - 1) .

NUMERICAL EXAMPLE 4.2 A short message block size is used with a short CRC polynomial so that all intermediate processes can be clearly shown. Given the CRC polynomial: gCRC 6 ( D ) = é D6 + D 5 + 1ù ë û And message block in0 =1010101010, the CRC bits are obtained through the following XOR procedure: 1010101010 000000 -message bits right padded with six 0 bits ⊕1100001 -divisor based on CRC polynomial 0110100010 000000 ⊕ 1100001 0000100110 000000 ⊕ 110000 1 0000010110 100000 ⊕ 11000 01 0000001110 110000 ⊕ 1100 001 0000000010 111000 ⊕ 11 00001 0000000001 111010

Physical Layer Processing with Numerical and MATLAB® Modeling

319

⊕ 1 100001 0000000000 011011 The calculated CRC bits are: 011011 Hence the output of CRC attachment process block is B0 =1010101010011011 In MATLAB, CRC attachment can be performed by the nrCRCEncode function which is available from the 5G Toolbox. The syntax for the function is as follows: Crced = nrCRCEncode(blk, poly) The inputs to the function specified in the syntax are as follows: blk: Input transport block on which CRC will be appended. poly: Selected CRC polynomial ('6', '11', '16', '24A', '24B' or '24C'). The function returns the CRC encoded data crced. A screenshot of the command window after the execution of the function is shown in Figure 4.7. The inputs to the function used in Figure 4.7 are described below: trBlk- Array corresponding to the input blk in the function’s syntax. chinfo.CRC- Field from the chinfo structure array for specifying the CRC polynomial to be used.

FIGURE 4.7  Command window result—CRC encoding.

320

5G NR Modeling in MATLAB®

4.1.1.4 Code Block Segmentation Code block segmentation is performed on B a because code blocks to be sent to an LDPC encoder should have lengths that are multiples of the available LDPC lifting sizes and not exceed the maximum code block sizes, K cb , which are 8448 and 3840 for LDPC Base Graph (BG) 1 and 2 respectively. The output of this process block consists of segmented code blocks, C xa where x is used to denote the segment index and x = 1, 2,¼, NC .The bits in the xth segmented code block for the message codeword with index a is denoted by c xa ( 0 ), c xa (1) ,…, c xa ( K - 1) . The segmentation operation splits input blocks having lengths exceeding the maximum code block sizes into multiple smaller code blocks and appends additional 24 CRC bits to each code block. The CRC generator polynomial used in this case is as follows:

gCRC 24 B ( D ) = é D 24 + D 23 + D6 + D 5 + D + 1ù ë û

The resulting number of output segments is calculated by the following ceil function:

é ù NB NC = ê ú (4.10) ë K cb - N L 2 û

Where, N B is the length of the output of the CRC attachment sub-block.K cb is the maximum code block size.N L2 is the length of additional CRC bits appended to each code block (24 bits). If N B is less than the maximum code block size K cb , the code block is not split into multiple segments and additional CRC bits are not added (N L2 = 0 ). The number of output segments, NC = 1. K ’ which is the sum of the number of bits from B a distributed evenly with the number of additional CRC bits per code block is given by:

K ’=

N B + NC N L 2 (4.11) NC

For the scenario where N B is less than K cb , K ’= N B . From here, an appropriate lifting size Zc for the BG matrix should be chosen. Eight sets of lifting sizes indexed as iLS , have been defined based on the parameter α. Available lifting sizes are determined using the equation Z c = a ´ 2 j and all the lifting sizes defined for eMBB using supported values of a and j are given in Table 4.2. The minimum value of LDPC lifting size satisfying the following equation is chosen: K’ Zc ³ (4.12) Kb Where, For LDPC BG1,

321

Physical Layer Processing with Numerical and MATLAB® Modeling

TABLE 4.2 5G LDPC-Supported Lifting Sizes as per 3GPP TS 38.212 [1] iLS

Zc

iLS

=0 α=2

j



iLS

=1 α=3

iLS

=2 α=5

iLS

=3 α=7

,α

iLS

=4 α=9

iLS

=5 α = 11

iLS

=6 α = 13

iLS

=7 α = 15

0

2

3

5

7

9

11

13

15

1 2 3 4 5 6

4 8 16 32 64 128

6 12 24 48 96 192

10 20 40 80 160 320

14 28 56 112 224 -

18 36 72 144 288 -

22 44 88 176 352 -

26 52 104 208 -

30 60 120 240 -

7

256

384

-

-

-

-

-

-

K b = 22

For LDPC BG2, K b = 10 , if N B > 640 K b = 9, if 560 < N B £ 640 K b = 8, if 192 < N B £ 560 K b = 6, if N B £ 192 Using Z c , the length, K, of each segmented code block can be obtained as follows:

K = 22 Z c for LDPC BG1



K = 10 Z c for LDPC BG 2 (4.13)

If K ’ is less than K, ( K - K ’) filler bits are appended to each code block segments C xa . Filler bits are denoted by elements in C xa . NUMERICAL EXAMPLE 4.3 In this example, the Code Block Segmentation process is demonstrated for a transport block of the size calculated in the numerical example in Subsection 4.1.1.1 (528 bits) having a 16-bit CRC attachment. If N B = 544 is used with BG2 (K cb = 3840), the input is not split as N B < K cb and additional CRC bits are not added. Furthermore, as N B < K cb , K ¢ = N B = 544. The LDPC lifting size is obtained using Equation (4.12): Zc ³

K¢ Kb

322

5G NR Modeling in MATLAB®

As 192 < N B £ 560 , K b = 8. Hence, 544 Zc ³ ³ 68 8 \ Z c = 72 ( closest match fromTable 2.1) The length of each segment is calculated using Equation (4.13): K = 10 Z c = 10 ´ 72= 720 The number of filler bits added per segment is calculated as follows: Number of filler bits = K - K ¢= 720 - 544 = 176 The output of the Code Block Segmentation process is as follows: C10 = 11011001¼11011011¼- 1 - 1 - 1 - 1 The MATLAB 5G Toolbox includes the nrCodeblockSegmentLDPC function which can be used to perform code block segmentation. The function’s syntax is as follows: Segmented = nrCodeblockSegmentLDPC(crced,bgn) The inputs to the function specified in the syntax are as follows: crced: Input data block to be segmented. bgn: Selected LDPC base graph number (1 or 2). The function returns a matrix segmented in which each column corresponds to a code block segment. A screenshot of the command window after the execution of the function is shown in Figure 4.8. The inputs to the function used in Figure 4.8 are described below: crced- Array corresponding to the input crced in the function’s syntax. chinfo.BGN- Field from the chinfo structure array for specifying the LDPC base graph number. 4.1.1.5 LDPC Encoding LDPC codes are the channel codes selected for the data channels of eMBB [6]. eMBB employs protograph-based Quasi-Cyclic (QC) LDPC codes constructions whereby two rate-compatible base graphs defined by 3GPP are used to generate the parity check matrix using the lifting size Z c which was determined in Subsection 4.1.1.4. The parity check matrix composes of cyclically shifted identity matrices denoted by Q Pi, j of size Z c ´ Z c having a right cyclic shift of Pi, j for all non-zero Pi, j

( )

entries. Pi, j entries of value 0 refer to a Z c ´ Z c identity matrix. Pi, j entries of value “−1” correspond to a Z c ´ Z c zero matrix [1].

Physical Layer Processing with Numerical and MATLAB® Modeling

323

FIGURE 4.8  Command window result—code block segmentation.

For example, cyclically shifted matrices for Pi, j = 2 and −1 with lifting sizes 4 are given below:



é0 ê 0 Q (2) = ê ê1 ê ë0

0 0 0 1

1 0 0 0

0ù ú 1ú 0ú ú 0û



é0 ê 0 Q ( -1) = ê ê0 ê ë0

0 0 0 0

0 0 0 0

0ù ú 0ú 0ú ú 0û

The structure of an m × n QC-LDPC code parity check matrix, H , is as follows:



é Q ( P0,0 ) Q ( P0,1 ) ê ê Q( P1,0 ) Q ( P1,1 ) H=ê ê   ê êëQ ( Pm -1,0 ) Q ( Pm -1,1 )

Q ( P0,n -1 ) ù ú ¼ Q ( P1,n -1 ) ú ú ú   ú ¼ Q ( Pm -1,n -1 ) úû ¼

The parity check matrix has a one-to-one mapping on an exponent matrix in which each value represents the cyclic shift Pi, j as follows:

324



5G NR Modeling in MATLAB®

é P0,0 ê P1,0 P=ê ê  ê êë Pm -1,0

P0,1 P1,1  Pm -1,1

¼ ¼

P0,n -1 ù ú P1,n -1 ú   ú ú ¼ Pm -1,n -1 úû

In the 3GPP TS 38.212 [1], the given rate-compatible base matrices of 5G are given in terms of elements Vi, j which can be converted to Pij by Pi, j = mod(Vi, j , Z c ) . NUMERICAL EXAMPLE 4.4 In this example, the derivation of a parity check matrix is demonstrated. Using Z c = 4 and i LS = 0, From 3GPP TS 38.212, é250 69 ù ê ú VBG1 = ê 2 -1 ú êë   úû Hence, the exponent matrix is obtained using Pi, j = mod (Vi, j , Z c ) .

PBG1

é mod ( 250, 4 ) mod ( 69, 4 ) ù ê ú = ê mod ( 2, 4 ) -1 ú ê   úû ë

é2 1 ù ê ú = ê2 -1 ú êë   úû The parity check matrix is obtained by expanding the exponent matrix with Z c ´ Z c cyclically shifted identity matrices and zero matrices: é0 0 1 0 ù ê ú 0 0 0 1ú For example, for P0,0 = 2, Q ( P0,0 ) = ê ê1 0 0 0 ú ê ú ë0 1 0 0 û Hence, the parity check matrix is obtained as follows: éQ ( P0,0 ) Q ( P0,1 ) ù ê ú H P = ê Q ( P1,0 ) Q ( P1,1 ) ú ê ú ê   ú ë û

Physical Layer Processing with Numerical and MATLAB® Modeling

é0 ê ê0 ê1 ê ê0 H P = ê0 ê ê0 ê1 ê ê0 ê ë

0 0 0 1 0

1 0 0 0 1

0 1 0 0 0

0 0 0 1 0

1 0 0 0 0

0 1 0 0 0

0 0 1 0 0

0 0 1 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0       

325

ù ú ú ú ú ú ú ú ú ú ú ú ú û

The 5G LDPC base graphs consist of five submatrices denoted by A, D, O, E, and I which are arranged as follows:

Each submatrix has specific characteristics and purposes as described below [7]: 1. Submatrix A generates systematic bits. 2. Submatrix D is a double diagonal matrix that generates parity bits. 3. Submatrix O is a zero matrix. 4. Submatrix E composes of single parity-checks that give support for lower rates, which are essential for Incremental Redundancy Hybrid Automatic Requests (IR-HARQ). 5. Submatrix I is an identity matrix. BG1 is optimized for encoding large transmit blocks and achieving high code-rates of up to 8/9 and supports input code block sizes of up to 8448 bits whereas BG2 is optimized for encoding small transmit blocks and achieving low code-rates, with the

326

5G NR Modeling in MATLAB®

lowest code-rate achievable being 1/5 and supports input code block sizes of up to 3840 bits [1]. BG2 is used if any one of the following conditions is met:

N A £ 292

N A £ 3824 and target code-rate, R £ 0.67

R £ 0.25

Otherwise, BG1 is used. Before LDPC encoding, filler bits denoted by elements in segments a C x (obtained from the code block segmentation sub-block) are replaced by bits of value 0. LDPC encoding of each segment C xa is performed using an LDPC generator matrix in the following matrix equation to obtain the LDPC code-word Dxa :

Dxa = C xa .G (4.14)

To derive the generator matrix, first, the Gauss–Jordan elimination is performed on the parity check matrix to obtain HGJ in the following form:

HGJ = éë I N - K

P ùû (4.15)

Where, P is an ( N - K ) ´ K parity check matrix. I N - K is an ( N - K ) ´ ( N - K )identity matrix. Then, the generator matrix is obtained by reshaping HGJ as follows:

G = éIK ë

P T ù (4.16) û

NUMERICAL EXAMPLE 4.5 In this example, the LDPC encoding process is applied on a short binary message using a short parity check matrix to properly demonstrate each step of the process. Given the binary message, u = éë1 0 1ùû and the parity check matrix: é1 0 0 1 0 1ù ú ê H1 = ê1 1 0 1 1 1ú êë0 0 1 0 1 1úû

Physical Layer Processing with Numerical and MATLAB® Modeling

327

Gauss–Jordan elimination is performed on H1, HGJ is obtained as follows: é1 0 0 1 0 1 ù ê ú HGJ = ê0 1 0 0 1 0 ú êë0 0 1 0 1 1 úû Then using Equation (4.16) the calculated generator matrix is as follows: é1 0 0 1 0 0 ù ê ú G1 = ê0 1 0 0 1 1 ú êë0 0 1 1 0 1 úû The LDPC code-word for message u is then generated as follows:

CLDPC

é1 0 0 1 0 0 ù ê ú = éë0 1 0 ùû . ê0 1 0 0 1 1 ú êë0 0 1 1 0 1 úû = éë0 1 0 0 1 1ùû

The first 2Z c systematic bits generated by the LPDC encoder are always punctured. Therefore, for code segments, C xa , the generated LDPC code-word Dxa has a length N D which is equal to 66Z c and 50Z c for BG1 and BG2 respectively [1]. In MATLAB, 5G LDPC encoding can be performed using the nrLDPCEncode function which is available from the 5G Toolbox. The syntax for the function is as follows: Encoded = nrLDPCEncode(segmented,bgn) The inputs to the function specified in the syntax are as follows: segmented: Input data block on which LDPC encoding will be performed. bgn: Selected LDPC base graph number (1 or 2). The function returns the LDPC encoded data encoded. A screenshot of the command window after the execution of the function is shown in Figure 4.9. The inputs to the function used in Figure 4.9 are described below: segmented- Array corresponding to the input segmented in the function’s syntax. chinfo.BGN- Field from the chinfo structure array for specifying the LDPC base graph number.

328

5G NR Modeling in MATLAB®

FIGURE 4.9  Command window result—LDPC encoding.

4.1.1.6 Rate Matching The rate of the base matrices is calculated using the number of systematic bits input to the LDPC encoder (K ) and the length of the LDPC code-word (N D ) as follows: R=



K (4.17) ND

Hence the rates of LDPC code-words obtained from BG1 and BG2 are as follows:

RBG1 =

22 Z c 1 K = = N D 66 Z c 3



RBG 2 =

10 Z c 1 K = = N D 50 Z c 5

However, the rate-compatible LDPC codes of 5G allow some of the parity bits to be punctured to increase the rate of the LDPC codes. In 5G, rate matching consists of the bit selection and bit interleaving procedures. For each LDPC code-word Dxa , the bit selection procedure is performed to choose bits that need to be transmitted based on the HARQ redundancy version and the number of parity check bits to exclude. Furthermore, all filler bits are removed from the code-words. The output code-word of this process for each input code-word, Dxa ,

329

Physical Layer Processing with Numerical and MATLAB® Modeling

is denoted by E xa . The lengths of each output code-word, N E a , is calculated using the x ceil or floor equations given in Equation (4.18):

NEa x

é é æ ö ùù G G , if x > êC - mod ç , N c ÷ - 1ú ú ê N Layers .Qm . N Layers .Qm . N c ê êë è N L .Qm . N c ø úû ú . (4.18) =ê ú G ú êN . . , Q otherwise ú ê Layers m N Layers .Qm . N c ë û

Where, G is the length of the output rate-matched code-word. N Layers is the number of PDSCH layers. Qm is the modulation order. N c is the number of segments. The index from which the bits start to be selected is determined by the LDPC base graph number and the redundancy version. Table 4.3 relates the redundancy version with the start bit index for both LDPC base graphs. The interleaving of bits is then performed on each code-word E xa to obtain outputs

(

)

Fxa which consists of the bit sequence f xa ( 0 ) , f xa (1) ,¼, f xa N F a - 1 , where x

N F a = N E a . The procedure is performed through the following steps: x x NEa x The code-word E xa is reshaped into an ×Qm matrix as shown below: Qm TABLE 4.3 Start Bit Index Based on Redundancy Version as Defined in 3GPP TS 38.212 [1] Start Bit Index Redundancy Version

LDPC BG1

LDPC BG2

0

0

0

1

ê 17 N D ú ê ú Zc ë 66 Z c û

ê 13 N D ú ê ú Zc ë 50 Z c û

2

ê 33 N D ú ê ú Zc ë 66 Z c û

ê 25 N D ú ê ú Zc ë 50 Z c û

3

ê 56 N D ú ê ú Zc ë 66 Z c û

ê 43 N D ú ê ú Zc ë 50 Z c û

330



5G NR Modeling in MATLAB®

M ER

æ æ NEa ö ç exa ( 0 ) exa ç x ÷ ç ç Qm ÷ è ø ç ç æ NEa ö ç exa (1) exa ç x + 1 ÷ ç = ç Qm ÷ è ø ç ç   ç ç æN a ö æ 2NEa ö x ç exa ç E x - 1 ÷ exa ç + 1÷ ÷ ç Qm ÷ ç ç Qm ø è ø è è

æ æ NEa öö ö exa ç ç x ( Qm - 1) ÷ ÷ ÷ ÷÷ ÷ ç ç Qm øø ÷ èè æ æ NEa ö ö÷ ¼ exa ç ç x ( Qm - 1) ÷ + 1 ÷ ÷÷ ÷ ÷ (4.19) ç ç Qm ø ø÷ èè ÷   ÷ ÷ ÷ ¼ exa N E a - 1 x ÷ ø ¼

(

)

The matrix is transposed:

M ET

æ ç exa ( 0 ) exa (1) ç ç ç æ NEa ö æ NEa ö ç exa ç x ÷ exa ç x + 1 ÷ ç Qm ÷ ç Qm ÷ =ç è ø è ø ç ç   ç æ æ NEa ö ö öö ç a æ æ N E xa Qm - 1) ÷ ÷ exa ç ç x ( Qm - 1) ÷ + 1 ÷ ( ç ex ç ç ÷ ÷ ÷÷ ç ç Qm ç ç çè Qm ø ø øø èè è è

æ NEa öö exa ç x - 1 ÷ ÷ ç Qm ÷÷ è ø÷ æ 2NEa ö÷ x ¼ exa ç + 1÷ ÷ ç Qm ÷ ÷ è ø÷ ÷   ÷ ÷ a ¼ ex N E a - 1 ÷ x ÷ ø ¼

(

)

(4.20) The elements from the transposed matrix are arranged in a column order to obtain Fxa :



æ ö exa ( 0 ) ç ÷ æ NEa ö ç ÷ x ÷ ç exa ç ÷ ç Qm ÷ ç ÷ è ø ç ÷  ç ÷ ç ÷ öö÷ ç a æç æ N E a x ÷ (Qm - 1) ÷÷ ÷ ÷ ç ex çç Fxa = ç çè è Qm ø ø ÷ (4.21) ç ÷ a ex (1) ç ÷ ç ÷ N æ ö Eax ç ÷ a + 1÷ ex ç ç ÷ ç Qm ÷ ç ÷ è ø ç ÷  ÷ ç ÷ ç a e N 1 ÷ ç x Eax è ø

(

)

Physical Layer Processing with Numerical and MATLAB® Modeling

331

The rate-matching process is demonstrated in the numerical example below using a short 16-bit code-word. NUMERICAL EXAMPLE 4.6 In this example, the rate-matching process applied to a short code-word is demonstrated. Given a 16-bit code-word, E11 = 1 0 1 0 1 1 1 1 0 0 0 0 0 1 0 1 and modulation order, Qm = 4,

1) The code-word E11 is reshaped into a 4×4 matrix as shown below:

æ1 ç 0              ç ç1 ç è0

0 0 0 0

0ö ÷ 1÷ 0÷ ÷ 1ø

0 1 0 1

1 1 0 0

0ö ÷ 1÷ 0÷ ÷ 1ø

1) The matrix is transposed:

æ1 ç 1              ç ç0 ç è0

1 1 1 1

2) The elements from the transposed matrix are arranged in a column order to obtain F11 :

F11 = (1 1 0 0 0 1 0 1 1 1 0 0 0 1 0 1)

T

4.1.1.7 Code Block Concatenation In this process block, the rate-matched outputs Fxa , are sequentially concatenated in a single code-word, G a of length NG as shown in Figure 4.10 [1].

FIGURE 4.10  Code block concatenation process.

332

5G NR Modeling in MATLAB®

NUMERICAL EXAMPLE 4.7 In this example, the code block concatenation of the following ratematched segments is demonstrated: F10 = 1010 F20 = 1110 F30 = 1111 F40 = 0000 The output of the code block concatenation process is obtained by sequentially concatenating each rate-matched segment as follows: G a = F10 F20 F30 F40 = 1010111011110000

In MATLAB, rate-matching and code block concatenation are both performed by the nrRateMatchLDPC function. The function’s syntax is as follows: Codeword = nrRa​teMat​chLDP​C(enc​oded,​outle​n ,rv,​mod,n​L ayer​s,Nre​f) The inputs required by the function specified in the syntax are as follows: encoded: LDPC encoded data on which rate-matching and code block concatenation will be performed. outlen: Length of the rate-matched and concatenated output. rv: Redundancy version of the transmission. mod: Modulation scheme used. nLayers: Number of transmission layers. Nref: Limited Rate-matching Buffer size (optional input). The function returns the Rate-matched data codeword. A screenshot of the command window after the execution of the function is shown in Figure 4.11. The inputs to the function used in Figure 4.8 are described below: encoded- Array corresponding to the input encoded in the function’s syntax. outCWLen- Array corresponding to the input outlen in the function’s syntax.

Physical Layer Processing with Numerical and MATLAB® Modeling

333

FIGURE 4.11  Command window result—code block concatenation.

rv- Array corresponding to the input rv in the function’s syntax. modulation- Array corresponding to the input mod in the function’s syntax. nlayers- Array corresponding to the input nLayers in the function’s syntax. obj.LimitedBufferSize- Field from the obj structure array for specifying the limited rate-matching buffer size.

4.1.2 PDSCH Encoding The PDSCH is a physical channel that carries the DLSCH coded data. PDSCH encoding process composes of scrambling, modulation and layer mapping subprocesses as illustrated in Figure 4.3. The subprocesses are described in Subsections 4.1.2.1 to 4.1.2.3. 4.1.2.1 Scrambling Scrambling is the process of replacing a binary sequence of bits with another, which has better synchronization properties. The scrambled sequence is constructed such that the probability of the sequence to have continuous streams of zeroes or ones is reduced [8]. This is because for properly recovering a message at the receiver, the receiver’s clock must be well synchronized to properly distinguish the intervals between the bits. Continuous streams of zeroes or ones may confuse the receiver about the bit intervals.

334

5G NR Modeling in MATLAB®

Furthermore scrambling helps to eliminate inter-cell interference. When a UE uses a known cell-specific scrambling sequence to descramble a message from an interfering cell, the interference will be incorrectly descrambled and will appear as uncorrelated noise at the receiver [9]. PDSCH scrambling in 5G NR is performed by XORing the code-words G a which consists of bits g a ( 0 ) , g a (1) ,¼, g a ( NG - 1) with a length-31 Gold sequence c to obtain code-word G ’a consisting of bits g ’a ( 0 ) , g ’a (1) ,¼, g ’a ( NG - 1) . The nth value of the gold sequence is generated using sequences x1 and x2 in Equation (4.22) [10].

(

)

c ( n ) = x1 ( n + N Gc ) + x2 ( n + N Gc ) mod 2 (4.22)

Where,

NGc = 1600 for PDSCH Scrambling The 31-bit sequence x1 is initialized with all the values set to 0 except the first one, x1 ( 0 ), set to 1. The 31-bit sequence x2 is initialized with cinit which is obtained by Equation (4.23). Equation (4.23) gives cinit in decimal which needs to be converted to binary to initialize x2 [10]. cinit = nRNTI .215 + a.214 + nID (4.23)

Where,

nRNTI equals to the Radio Network Temporary Identifier (RNTI) associated with the PDSCH transmission, a is the code-word index (0 or 1), nID equals the higher layer parameter dataScramblingIdentityPDSCH if it is configured (taking integer values in the range 0–1024), cell nID equals the physical layer cell ID, N ID , given in Equation (4.24) otherwise. (1) (2) cell N ID = 3 N ID + N ID (4.24)

Where, (1) N ID Î {0,1,¼, 335} , (2) N ID Î {0,1, 2}.

The values in sequences x1 and x2 can be determined using Equations (4.25) and (4.26) [10].

Physical Layer Processing with Numerical and MATLAB® Modeling

(

335

)



x1 ( n + 31) = x1 ( n + 3 ) + x1 ( n ) mod 2 (4.25)



x2 ( n + 31) = x2 ( n + 3 ) + x2 ( n + 2 ) + x2 ( n + 1) + x2 ( n ) mod 2 (4.26)

(

)

Where, x1 (1) is the least significant bit in the sequence x1. The sequences {x1(NGc ), x1(NGc +1),…, x1(NGc +NG -1)} and {x2 (NGc ), x2 (NGc +1),…, x2 (NGc +NG -1)} which are determined using Equations (4.25) and (4.26) are used to find the Gold sequence c of length NG using Equation (4.22). c is then XORed with input blocks to obtain the scrambled block [10]. NUMERICAL EXAMPLE 4.8 In this example, the scrambling process is applied to one message bit to clearly demonstrate the intermediate steps. Given message bit, g(33) = 1, RNTI = 65,000, Code-word index a = 1, nID = 1, For simplicity, assume N C = 0 The scrambling bit is evaluated using Equation (4.23),

(

)

c ( 33 ) = x1 ( 33 + N c ) + x2 ( 33 + N c ) mod 2

(

)

= x1 ( 33 ) + x2 ( 33 ) mod 2 (1)



Evaluating x1 ( 33 ) x1 is initialized as follows: x1= 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 x1 ( 33 ) can berewritten as x1 ( 2 + 31) , Using Equation (4.25),

(

)

x1 ( 33 ) = x1 ( 2 + 3 ) + x1 ( 2 ) mod 2

(

)

= x1 ( 5 ) + x1 ( 2 ) mod 2 = 0 (2)

Evaluating x2 ( 33 ) ,

cinit = nRNTI .215 + a.214 + nID

336

5G NR Modeling in MATLAB®

= 65000 ´ 215 + 1 ´ 214 + 1 = 2129936385 x2 is initialized by converting cinit to a 31-bit binary value: x2 = 1 1 1 1 1 1 0 1 1 1 1 0 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 x2 ( 33 ) can berewritten as x2 ( 2 + 31) , Using Equation (4.26),

(

)

x2 ( 2 + 31) = x2 ( 2 + 3 ) + x2 ( 2 + 2 ) + x2 ( 2 + 1) + x2 ( 2 ) mod 2

(

)

= x2 ( 5 ) + x2 ( 4 ) + x2 ( 3 ) + x2 ( 2 ) mod 2 = ( 0 + 0 + 0 + 0 ) mod 2 = 0



(3)

Substitute 2 and 3 in 1 c ( 33 ) = ( 0 + 0 ) mod 2 Hence the scrambled bit,

(

)

’ 33 g ( ) = b ( 33 ) + c ( 33 ) mod 2

(

)

= b (1) + c ( 0 ) mod 2 =1 The nrPDSCHPRBS function from the MATLAB 5G Toolbox can be used to generate the scrambling sequence. The function’s syntax is as follows: [seq,cinit] = nrPDSCHPRBS(nid,rnti,q,n) The inputs to the function specified in the syntax are described below: nid: Scrambling identity as described in Equation (4.23). rnti: RNTI of the UE. q: Code-word index (0 or 1). n: Size of the required scrambling sequence. The function returns the scrambling sequence seq and the initialization value cinit. The scrambling sequence can then be XORed with the message block to obtain the scrambled code-word, scrambled.​

Physical Layer Processing with Numerical and MATLAB® Modeling

337

FIGURE 4.12  PDSCH encoding.

A screenshot of the command window after the execution of the function is shown in Figure 4.13. The inputs to the function used in Figure 4.13 are described below: nid- Array corresponding to the input nid in the function’s syntax. rnti- Array corresponding to the input rnti in the function’s syntax. q-1- Array corresponding to the input q in the function’s syntax. length(cellcws{q})- Value corresponding to the input n in the function’s syntax. cellcws is a cell array in which each DLSCH code-words is stored in a cell. The message can then be scrambled by XORing it with the scrambling sequence. A screenshot of the command window after performing the scrambling is shown in Figure 4.14.

338

5G NR Modeling in MATLAB®

FIGURE 4.13  Command window result—generation of scrambling sequence.

The inputs to the XOR function used in Figure 4.14 are described below: cellcws{q}- Cell array in which each DLSCH code-words is stored in a cell. c- Scrambling sequence. 4.1.2.2 Modulation Binary input bits are mapped to complex-valued modulation symbols based on the selected modulation order, q. The real and complex parts of the symbols represent the in-phase and quadrature components of the symbol component. The modulated symbol sequence for the code-word with index a is denoted by H a . The total number N of modulated symbols obtained after modulation, N H = G . The modulation q schemes defined for PDSCH include Quadrature Phase Shift Keying (QPSK) and Quadrature Amplitude Modulation (QAM) schemes, which are described next [10]. QPSK (2 bits/symbol), q = 2 Each pair of bits, g ’a ( 2i ) and g ’a ( 2i + 1) are mapped to modulation symbols as per equation (4.27) [10]:

Physical Layer Processing with Numerical and MATLAB® Modeling

339

FIGURE 4.14  Command window result—scrambling.

ha (i ) =



(

) (

1 é 1 - 2 g ’a ( 2i ) + j 1 - 2 g ’a ( 2i + 1) 2 êë

)ùúû (4.27)

5G NR’s QPSK constellation diagram is given in Figure 4.15. 16-QAM (4 bits/symbol), q = 4 Each quadruplet of bits g ’a ( 4i ), g ’a ( 4i + 1) , g ’a ( 4i + 2 ), and g ’a ( 4i + 3 ) are mapped to modulation symbols as per Equation (4.28) [10]: ha ( i ) = 1

{

(

)

(

)}

é1 - 2 g ’a ( 4i ) ù é2 - 1 - 2 g ’a ( 4i + 2 ) ù + j é1 - 2 g ’a ( 4i + 1) ù é2 - 1 - 2 g ’a ( 4i + 3 ) ù êë ûú ëê ûú ëê ûú ûú 10 ëê

(4.28) 5G NR’s 16-QAM constellation diagram is given in Figure 4.16. 64-QAM (6 bits/symbol), q = 6 Each set of 6 bits g a ’( 6i ) , g ’a ( 6i + 1), g ’a ( 6i + 2 ) , g ’a ( 6i + 3 ), g ’a ( 6i + 4 ) , and g ’a ( 6i + 5 ) are mapped to modulation symbols as per Equation (4.29) [10]:

h a ( i ) =

340

FIGURE 4.15  5G QPSK constellation.

FIGURE 4.16  5G 16-QAM constellation [10].

5G NR Modeling in MATLAB®

341

Physical Layer Processing with Numerical and MATLAB® Modeling



( (

)

(

)

(

)

ì 1 - 2 g ’a 6i é 4 - 1 - 2 g ’a 6i + 2 é2 - 1 - 2 g ’a 6i + 4 ù ù + ü ( ) ëê ( ) ëê ( ) ûú ûú ïï ïï í ý ï j 1 - 2 g ’a ( 6i + 1) é 4 - 1 - 2 g ’a ( 6i + 3 ) é2 - 1 - 2 g ’a ( 6i + 5 ) ù ù ï (4.29) êë úû úû ïþ êë ïî 42

)

(

) (

)

5G NR’s 64-QAM constellation diagram is given in Figure 4.17. 256-QAM (8 bits/symbol), q = 8 Each octuplet of bits g ’a ( 8i ) , g ’a ( 8i + 1) , g ’a ( 8i + 2 ) , g ’a ( 8i + 3 ) , g ’a ( 8i + 4 ) , g ’a ( 8i + 5 ), g ’a ( 8i + 6 ), and g ’a ( 8i + 7 ) are mapped to modulation symbols as per Equation (4.30) [10]:

FIGURE 4.17  5G 64-QAM Constellation [10].

342

5G NR Modeling in MATLAB®

FIGURE 4.18  5G 256-QAM constellation [10].

h a ( i ) =



( (

) ( ) (

) ( ) (

) ( ) (

)

ì é é a a a a é ùùù ü ï 1 - 2 g ’ ( 8i ) ê8 - 1 - 2 g ’ ( 8i + 2 ) ê 4 - 1 - 2 g ’ ( 8i + 4 ) ëê2 - 1 - 2 g ’ ( 8i + 6 ) ûú ú ú + ï ë ûû ï ë ï í ý ï j 1 - 2 g ’a ( 8i + 1) é8 - 1 - 2 g ’a ( 8i + 3 ) é 4 - 1 - 2 g ’a ( 8i + 5 ) é2 - 1 - 2 g ’a ( 8i + 7 ) ù ù ù ï ê êë êë úû úû úû ï ïî ë þ 170

)

(4.30) 5G NR’s 256-QAM constellation diagram is given in Figure 4.18.

NUMERICAL EXAMPLE 4.9 In this example, 64-QAM modulation applied to a code-word is demonstrated. Given a 600-bit block G ¢ = 110001 010101 … 111111, the 64-QAM modulation is performed using Equation (4.29) as follows:

343

Physical Layer Processing with Numerical and MATLAB® Modeling

h1 ( 0 ) =

( (

)

(

))

(

))

ì 1 - 2 g ’1 6 ´ 0 é 4 - 1 - 2 g ’1’ 6 ´ 0 + 2 é2 - 1 - 2 g ’1 6 ´ 0 + 4 ù ù + ü ( ) êë ( ) ( ) úû úû ïï ïï ëê í ý ï j 1 - 2 g ’1 ( 6 ´ 0 ) + 1 é 4 - 1 - 2 g ’1 ( 6 ´ 0 ) + 3 é2 - 1 - 2 g ’1 ( 6 ´ 0 ) + 5 ù ù ï êë úû ûú ïþ ïî ëê 42

(

))

(

(

(

))

(

)

(

)

(

(

))

(

(

)

ì 1 1 1 é é ùù ü ïï 1 - 2 g ’ ( 0 ) ëê 4 - 1 - 2 g ’ ( 2 ) êë2 - 1 - 2 g ’ ( 4 ) úû úû + ïï ý í ï j 1 - 2 g ’1 (1) é 4 - 1 - 2 g ’1 ( 3 ) é2 - 1 - 2 g ’1 ( 5 ) ù ù ï êë ëê ûú úû ïþ ï =î 42

(

(

)

(

)

(

) (

)

)

(

)

ì 1 - 2 (1) é 4 - 1 - 2 ( 0 ) é2 - 1 - 2 ( 0 ) ù ù + ü ë ûû ï ï ë í ý ï j 1 - 2 (1) é 4 - 1 - 2 ( 0 ) é2 - 1 - 2 (1) ù ù ï ë ûû þ ë =î 42

(

)

(

-3

=

42

)

(

)

1

-j

42

h1 (1) =

( (

)

(

))

(

))

ì 1 - 2 g1 ’ 6 ´ 1 é 4 - 1 - 2 g1 ’ 6 ´ 1 + 2 é2 - 1 - 2 g1 ’ 6 ´ 1 + 4 ù ù + ü ( ) ëê ( ) ( ) ïï ïï ëê ûú ûú ý í ï j 1 - 2 g1 ’ ( 6 ´ 1) + 1 é 4 - 1 - 2 g1 ’ ( 6 ´ 1) + 3 é2 - 1 - 2 g1 ’ ( 6 ´ 1) + 5 ù ù ï êë úû úû ïþ êë ïî 42

))

(

(

(

(

))

(

)

(

(

(

)

))

(

(

)

ì 1 - 2 g1 ’ 6 é 4 - 1 - 2 g1 ’ 8 é2 - 1 - 2 g1 ’ 10 ù ù + ü ( ) ëê ( ) êë ( ) úû ûú ïï ïï ý í ï j 1 - 2 g1 ’( 7 ) é 4 - 1 - 2 g1 ’( 9 ) é2 - 1 - 2 g1 ’(11) ù ù ï êë ëê ûú úû ïþ ï =î 42

(

(

)

(

)

(

) (

)

(

)

) )

ì 1 - 2 ( 0 ) é 4 - 1 - 2 ( 0 ) é2 - 1 - 2 ( 0 ) ù ù + ü ë ûû ï ï ë í ý ï j 1 - 2 (1) é 4 - 1 - 2 (1) é2 - 1 - 2 (1) ù ù ï ë ûû þ ë =î 42

(

)

(

)

(

344

5G NR Modeling in MATLAB® 3 7 -j 42 42

=

Total number of 64-QAM modulated symbols obtained by a 600-bit code block, N NH = G q =

600 6

= 100 Therefore, the last modulated symbol, h1 ( 99 ) =

(

( ) ( )) ( (

))

(

))

ì ü é 1 1 1 ùù é ïï 1 - 2 g ’( 6 ´ 99 ) êë 4 - 1 - 2 g ’ ( 6 ´ 99 ) + 2 êë2 - 1 - 2 g ’ ( 6 ´ 99 ) + 4 úû úû + ïï í ý ï j 1 - 2 g1 ’ ( 6 ´ 99 ) + 1 é 4 - 1 - 2 g1 ’ ( 6 ´ 99 ) + 3 é2 - 1 - 2 g1 ’ ( 6 ´ 99 ) + 5 ù ù ï ú ê ïî ëê ûú û ïþ ë 42

(

(

(

)

(

))

(

)

(

))

(

(

)

ì 1 - 2 g1 ’ 594 é 4 - 1 - 2 g1 ’ 596 é2 - 1 - 2 g1 ’ 598 ù ù + ü ( ) êë ( ) êë ( ) ûú úû ïï ïï ý í ï j 1 - 2 gC1 ’( 595 ) é 4 - 1 - 2 g1 ’( 597 ) é2 - 1 - 2 g1 ’( 599 ) ù ù ï ëê ûú ûú ïþ ï ëê =î 42

(

)

(

(

) (

)

(

)

(

)

)

ì 1 - 2 (1) é 4 - 1 - 2 (1) é2 - 1 - 2 (1) ù ù + ü ë ûû ï ï ë í ý ï j 1 - 2 (1) é 4 - 1 - 2 (1) é2 - 1 - 2 (1) ù ù ï ë ûû þ ë =î 42

(

)

(

=

-7 42

)

-j

(

)

7 42

Hence, the modulated symbols are as follows: æ -3 1 H1 = ç -j 42 è 42

öæ 3 7 -j ÷ ,ç 42 ø è 42

ö æ -7 7 ö -j ÷ ,¼ , ç ÷ 42 ø ø è 42

Physical Layer Processing with Numerical and MATLAB® Modeling

345

The nrSymbolModulate function included in the MATLAB 5G Toolbox can be used to modulate binary data to complex modulated symbols. The syntax of the function is as follows: Modulated = nrSy​mbolM​odula​te(sc​rambl​ed,mo​d ,'Ou​tputD​ataTy​pe',d​ataty​pe) The inputs to the function specified in the syntax are as follows: scrambled: Block of bits to be modulated. mod: Selected modulation order. 'OutputDataType' and datatype: Specified data type of modulated output symbols ('double' or 'single')—Optional. The function returns the complex modulated symbols modulated. A screenshot of the command window after the execution of the function is shown in Figure 4.19. The inputs to the function used in Figure 4.19 are described below: scrambled{q}- Array corresponding to the input scrambled in the function’s syntax. scrambled is a cell array in which each scrambled code-words is stored in a cell. mods{q}- Array corresponding to the input mod in the function’s syntax. mods is a cell array in which the modulation order of each code-words is specified in a cell. varargin{:}- Array corresponding to the input 'OutputDataType' and datatype in the function’s syntax. In this scenario, the function is nested in another function that accepts any number of input arguments through the use of MATLAB’s varargin input variable.

FIGURE 4.19  Command window result—modulation.

346

5G NR Modeling in MATLAB®

FIGURE 4.20  Layer mapping of two Code-words over seven MIMO layers.

4.1.2.3 Layer Mapping The complex-valued modulated symbols for each message code-word, h a ( 0 ) , h a (1) ,¼, h a ( N H - 1) are mapped onto MIMO layers. The total number of MIMO layers is denoted by N Layers . The lth layer, J l-1 , consists of symbols

(

)

j l -1 ( 0 ) , j l -1 (1) ,¼, j l -1 N J ( l -1) - 1 where N Jl is the number of symbols in the lth

layer. 5G supports the transmission of up to eight layers. For up to four layers, the transmission of a single message code-word is supported whereas, for five to eight layers, the transmission of two simultaneous message code-words is supported. Details about the symbols contained on each MIMO layer given quantity of layers and codewords are given in Table 4.4 and the layer mapping process of two code-words over seven MIMO layers is illustrated in Figure 4.20 [10]. NUMERICAL EXAMPLE 4.10 In this example, the mapping of the modulated symbols from two message code-words below onto five layers is demonstrated: æ -3 H1 = ç -j è 42 æ -3 +j ç è 42

1 ö æ 3 +j ÷,ç 42 ø è 42 7 ö æ -7 -j ÷,ç 42 ø è 42

7 ö æ 3 7 ö æ -7 7 ö -j -j ÷, ÷,ç ÷,ç 42 ø è 42 42 ø è 42 42 ø 7 ö ÷ 42 ø

æ 3 H2 = ç -j è 42 æ -3 +j ç è 42

1 ö æ 7 +j ÷,ç 42 ø è 42 7 ö æ -3 -j ÷,ç 42 ø è 42

7 ö æ 3 7 ö æ 7 7 ö -j -j ÷, ÷,ç ÷,ç 42 ø è 42 42 ø è 42 42 ø 7 ö ÷ 42 ø

347

Physical Layer Processing with Numerical and MATLAB® Modeling

TABLE 4.4 Layer Mapping [10] Number of Layers, NLayers

Number of Message Code-Words

Layer Mapping

1

1

j 0 ( i ) = h1 ( i )   N J 0 = N H

2

1

j 0 ( i ) = h1 ( 2i )

NJ 0 = NH / 2

j1 ( i ) = h1 ( 2i + 1) N J 1 = N H / 2 3

1

j 0 ( i ) = h1 ( 3i )

NJ 0 = NH / 3



j1 ( i ) = h1 ( 3i + 1)

 

j 2 ( i ) = h1 ( 3i + 2 ) 4

1

2

NJ 2 = NH / 3

j 0 ( i ) = h1 ( 4i )  N J 0 = N H / 4 j1 ( i ) = h1 ( 4i + 1)

5

N J1 = N H / 3

N J1 = N H / 4

 

j 2 ( i ) = h1 ( 4i + 2 )

 

NJ 2 = NH / 4

j 3 ( i ) = h1 ( 4i + 3 )

 

NJ 3 = NH / 4

j 0 ( i ) = h1 ( 2i )

N   J 0

= NH / 2

j1 ( i ) = h1 ( 2i + 1) N J 1 = N H / 2   j 2 ( i ) = h2 ( 3i )

N    J 2

= NH / 3

j 3 ( i ) = h2 ( 3i + 1) N J 3 = N H / 3 j 4 ( i ) = h2 ( 3i + 2 ) N J 4 = N H / 3 6

2

j 0 ( i ) = h1 ( 3i )

NJ 0 = NH / 3



j1 ( i ) = h1 ( 3i + 1) N J 1 = N H / 3   j 2 ( i ) = h1 ( 3i + 2 ) N J 2 = N H / 3   j 3 ( i ) = h2 ( 3i )

   

NJ 3 = NH / 3

j 4 ( i ) = h2 ( 3i + 1) N J 4 = N H / 3 j 5 ( i ) = h2 ( 3i + 2 ) N J 5 = N H / 3 (Continued )

348

5G NR Modeling in MATLAB®

TABLE 4.4 (CONTINUED) Layer Mapping [10] Number of Layers, NLayers 7

Number of Message Code-Words

Layer Mapping

2

j 0 ( i ) = h1 ( 3i )

N

 J 0

= NH / 3

j1 ( i ) = h1 ( 3i + 1) N J 1 = N H / 3   j 2 ( i ) = h1 ( 3i + 2 ) N J 2 = N H / 3   j 3 ( i ) = h 2 ( 4i )

8

2

    

NJ 3 = NH / 4

j 4 ( i ) = h2 ( 4i + 1)

  

NJ 4 = NH / 4

j 5 ( i ) = h 2 ( 4i + 2 )

  

NJ 5 = NH / 4

j 6 ( i ) = h2 ( 4i + 3 )

  

NJ 6 = NH / 4

j 0 ( i ) = h1 ( 4i )

  

NJ 0 = NH / 4

j1 ( i ) = h1 ( 4i + 1)

N J1 = N H / 4

j 2 ( i ) = h1 ( 4i + 2 )

NJ 2 = NH / 4

j 3 ( i ) = h1 ( 4i + 3 )

NJ 3 = NH / 4

j 4 ( i ) = h 2 ( 4i )

NJ 4 = NH / 4

j 5 ( i ) = h2 ( 4i + 1)

NJ 5 = NH / 4

j 6 ( i ) = h2 ( 4i + 2 )

NJ 6 = NH / 4

j 7 ( i ) = h 2 ( 4i + 3 )

NJ 7 = NH / 4

Number of modulated symbols per message code-words, N H = 6. Using equations in Table 4.4 for mapping on five layers, N J 0 = N J1 =

NH 2 =3

Physical Layer Processing with Numerical and MATLAB® Modeling

349

NJ 2 = NJ 3 = NJ 4 =

NH 3 =2

Modulated symbols from first message code-word are mapped onto the first two layers as follows: æ -3 1 ö j 0 ( 0 ) = h1 ( 0 ) = ç -j ÷ 42 ø è 42 æ 3 7 ö j 0 (1) = h1 ( 2 ) = ç -j ÷ 42 ø è 42 æ -3 7 ö j 0 ( 2 ) = h1 ( 4 ) = ç +j ÷ 42 ø è 42 æ 3 7 ö j1 ( 0 ) = h1 (1) = ç +j ÷ 42 ø è 42 æ -7 7 ö j1 (1) = h1 ( 3 ) = ç -j ÷ 42 ø è 42 æ -7 7 ö j1 ( 2 ) = h1 ( 5 ) = ç -j ÷ 42 ø è 42 Modulated symbols from the second message code-word are mapped onto the last three layers as follows: æ 3 1 ö j 2 ( 0 ) = h1 ( 0 ) = ç -j ÷ 42 ø è 42 æ 7 7 ö j 2 (1) = h1 ( 3 ) = ç -j ÷ 42 ø è 42 æ 7 7 ö j 3 ( 0 ) = h1 (1) = ç +j ÷ 42 ø è 42 æ -3 7 ö j 3 (1) = h1 ( 4 ) = ç +j ÷ 42 ø è 42

350

5G NR Modeling in MATLAB®

æ 3 7 ö j 4 ( 0 ) = h1 ( 2 ) = ç -j ÷ 42 ø è 42 æ -3 7 ö j 4 (1) = h1 ( 5 ) = ç -j ÷ 42 42 ø è Layer mapping of complex modulated symbols can be simulated in MATLAB using the nrLayerMap function from the 5G Toolbox. The function’s syntax is as follows: Sym = nrLayerMap(modulated,nLayers) The inputs to the function specified in the syntax are as follows: modulated: Block of complex modulated symbols. nLayer: Number of transmission layers. The function outputs a matrix, sym, in which each column corresponds to a mapped layer of complex symbols. A screenshot of the command window after the execution of the function is shown in Figure 4.21. The inputs to the function used in Figure 4.21 are described below:

FIGURE 4.21  Command window result—layer mapping.

351

Physical Layer Processing with Numerical and MATLAB® Modeling

modulated- Array corresponding to the input modulated in the function’s syntax. nlayers- Array corresponding to the input nLayer in the function’s syntax.

4.1.3 Precoding Precoding is the process where layer-mapped QAM symbols are distributed to a defined number of antenna ports, P, such that throughput is maximized as per

(

)

Equation (4.31). The pth port consists of symbols k r -1 ( 0 ) , k r -1 (1) ,¼, k r -1 N k ( r -1) - 1

where N k ( r -1) is the number of symbols in the pth port. Based on 3GPP TS 38.211, the mapping of the layer-mapped symbols on the antenna ports for PDSCH is performed such that PDSCH layers are mapped onto antenna ports as per Equation (4.31) [10]. é k 0 (i ) ù é j0 (i ) ù ê 1 ú ú ê 1 ê k (i ) ú ê j (i ) ú ê ú =Wê ú (4.31)  ê ú ê  ú ê ( P -1) ú ê l -1 ú ( i )û ë j ( i )û ëk



Where, W - Precoding matrix For non-codebook-based transmission, W is an identity matrix. For codebook-based transmission using a single layer and a single antenna port, W = 1. Otherwise, W is given by matrices defined by Tables 6.3.1.5-1 to 6.3.1.5-7 of the 3GPP TS 38.211. The precoding matrix selection is also based on the Transmitted Precoding Matrix Indicator (TPMI) index which can be obtained from the Downlink Control Information (DCI) scheduling the uplink transmission or the higher layer parameters. NUMERICAL EXAMPLE 4.11 In this example, precoding is demonstrated for a codebook-based, threelayer transmission using four antenna ports. The TPMI index is set to 0 and the layer-mapped symbols are given in the following matrix: éæ êç êè êæ êç êè ê êæ êç ëè

1 ö æ 3 7 ö æ -3 7 öù - j� + j� ÷ ç ÷ ç ÷ú 42 42 ø è 42 42 ø è 42 42 ø ú 3 7 ö æ -7 7 ö æ -7 7 ö úú + j� - j� - j� ÷ ç ÷ ç ÷ 42 42 ø è 42 42 ø è 42 42 ø ú ú 7 ö æ 7 7 öú 3 1 ö æ 7 - j� - j� - j� ÷ ç ÷ ÷ ç 42 ø è 42 42 ø úû 42 42 ø è 42

-3

- j�

352

5G NR Modeling in MATLAB®

The precoding matrix obtained by referring to Table 6.3.1.5-6 in the 3GPP TS 38.211 is as follows: é1 ê 1 0 W= ê 2 ê0 ê ë0

0 1 0 0

0ù ú 0ú 1ú ú 0û

The mapping of the layer-mapped symbols on the antenna ports is determined using Equation (4.31) as follows: é k 0 (i ) ù é j0 (i ) ù ê 1 ú ú ê 1 ê k (i ) ú ê j (i ) ú ê ú =Wê ú  ê ú ê  ú ê ( P -1) ú ê l -1 ú ( i )û ë j ( i )û ëk é1 ê 1 0 = ê 2 ê0 ê ë0

0 1 0 0

é æ ê1 ´ ç ê è ê æ 1 ê1 ´ ç = ê è 2ê ê æ ê1 ´ ç ê è êë

éæ êç 0 ù êè ú 0 ú êæ êç 1 ú êè úê 0 û êæ êç ëè

æ -3 7 öù + j� ç ÷ú 42 ø ú è 42 æ -7 7 ö úú j� ç ÷ 42 ø ú è 42 ú 3 1 ö æ 7 7 ö æ 7 7 öú - j� j� j� ÷ ç ÷ ç ÷ 42 42 ø è 42 42 ø è 42 42 ø úû

1 ö ÷ 42 42 ø 3 7 ö + j� ÷ 42 42 ø

-3

- j�

æ ç è æ ç è

7 ö ÷ 42 42 ø -7 7 ö - j� ÷ 42 42 ø 3

- j�

æ 3 æ -3 1 ö 7 ö 7 öù - j� + j� ÷ 1´ ç ÷ 1´ ç ÷ú 42 42 ø 42 ø 42 ø ú è 42 è 42 æ -7 æ -7 3 7 ö 7 ö 7 ö úú 1 1 + j� ´ j� ´ j� ÷ ç ÷ ç ÷ 42 42 ø 42 ø 42 ø ú è 42 è 42 ú æ 7 æ 7 1 ö 7 ö 7 öú 3 - j� - j� - j� ÷ 1´ ç ÷ 1´ ç ÷ 42 ø 42 ø 42 ø úú 42 è 42 è 42 úû 0 0 0

-3

éæ -3 êç êè 2 42 êæ 3 êç = êè 2 42 ê êæ 3 êç 2 42 êè ëê

- j�

öù ÷ú øú æ -7 7 ö æ -7 7 ö úú - j� - j� ç ÷ ç ÷ 2 42 ø è 2 42 2 42 ø ú è 2 42 ú æ 7 7 ö æ 7 7 öú - j� - j� ç ÷ ç ÷ 2 42 ø è 2 42 2 42 ø úú è 2 42 úû 0 0

- j�

ö æ 3 7 ö æ -3 7 - j� + j� ÷ ç ÷ ç 2 42 ø è 2 42 2 42 ø è 2 42 2 42

+ j�

ö ÷ 2 42 ø

- j�

ö ÷ 2 42 ø

0

1

7

1

Physical Layer Processing with Numerical and MATLAB® Modeling

353

In the MATLAB script, perfect channel estimation is used. Hence, the precoding matrix is determined using Singular Value Decomposition (SVD) which is known to achieve the MIMO channel capacity [18]. The precoding matrix is fetched using the getPrecodingMatrix local function, given and described below: function wtx = getPr​ecodi​ngMat​rix(P​RBSet​,NLay​ers,h​estGr​id) % Calculate precoding matrix given an allocation and a channel estimate       % Allocated subcarrier indices       allocSc = (1:12)' + 12*PRBSet(:).';       allocSc = allocSc(:);        

    % Average channel estimate     [~,~,R,P] = size(hestGrid);     estAllocGrid = hestGrid(allocSc,:,:,:);     Hest = permu​te(me​an(re​shape​(estA​llocG​rid,[​],R,P​)),[2​ 3 1]);

      % SVD decomposition       [~,~,V] = svd(Hest);       wtx = V(:,1:NLayers).'; end

4.1.4 CP-OFDM For each antenna port, a virtual resource grid is generated. The size of the resource grid is determined based on the number of subcarriers and the number of slots per symbol. The PDSCH data is mapped onto REs starting from the lowest frequency Resource Element (RE) to the highest frequency RE on the grid. After mapping on the highest frequency RE is completed, the mapping is continued on the lowest frequency of the next OFDM symbol. The sequence of symbol mapping for the pth antenna port starts with the symbol k p-1 ( 0 ) v. Some REs are not assigned with PDSCH data and are reserved for information such as [1]: • Demodulation Reference Signal (DM-RS). • Phase Tracking Reference Signal (PT-RS). • Control Resource Set (CORESET).

Synchronization Signal (SS)/Physical Broadcast Channel (PBCH). As an example, the mapping of nine consecutive port-mapped symbols on a virtual resource grid consisting of five subcarriers is demonstrated in Figure 4.22. 4.1.4.1 Demodulation Reference Signal Demodulation Reference Signal (DM-RS) is a UE-specific reference signal transmitted on demand to the receiver for radio channel estimation to increase the accuracy

354

5G NR Modeling in MATLAB®

FIGURE 4.22  Virtual resource grid mapping.

of demodulation for data transmissions on all antenna ports. The DM-RS is composed of a sequence r ( n ) given in Equation (4.32) as defined in 3GPP TS 38.211 [10]. r (n) =



1

(1 - 2c ( 2n )) + j 2

1 2

(1 - 2c ( 2n + 1)) (4.32)

Where c ( n ) is a pseudorandom Gold sequence given in Equation (4.22) and is initialized using Equation (4.33) [10].

( (

)(

)

)

slot m cinit = 217 N sym ns, f + l + 1 2 N IDSCID + 1 + 2 N IDSCID + nSCID mod231 (4.33)



n

n

Where, slot N sym is the number of OFDM symbols per slot. m ns, f is the slot number within the frame. l is the OFDM symbol number in the slot. nSCID - scrambling initialization. nSCID Î {0,1} and is given in the DM-RS initialization field of the PDSCH-associated Downlink Control Information (DCI) if DCI format 1_1 is used. Otherwise, nSCID = 0.

Physical Layer Processing with Numerical and MATLAB® Modeling

355

N IDSCID - scrambling identity. N IDSCID Î {0,1,¼, 65536} and is given higherlayer parameters in the DMRS-DownlinkConfig if provided. Otherwise, n cell . N IDSCID = N ID n

n

The PDSCH mapping type (A or B) impacts the DM-RS symbols positioning on the resource grid. When PDSCH mapping Type A is used, the DM-RS symbols are positioned in OFDM symbol 2 or 3 of the slot. If PDSCH mapping Type B is used, the DM-RS symbols are positioned in the first symbol of the PDSCH allocation. The two types of mapping are illustrated in Figure 4.23. PDSCH mapping Type B is preferred mainly when the PDSCH allocation begins somewhere near the middle of the slot. 5G also supports both single and double symbol DM-RS. In single symbol DM-RS configuration, only one OFDM symbol in the slot contains DM-RS as shown in Figure 4.23 whereas, in double symbol DM-RS configuration, two consecutive OFDM symbols in the slot contain DM-RS as shown in Figure 4.24. Double symbol DM-RS increases the channel estimation accuracy at the receiver. Channel estimation accuracy can further be increased in 5G NR by the inclusion of DM-RS on up to four OFDM symbols in the same PRB. A large number of DM-RS can be opted for especially in high-speed scenarios where the channel conditions change quickly. Figure 4.25 illustrates DM-RS transmission on four OFDM symbols in the same PRB. DM-RS are mapped on PRBs using configuration Type 1 or Type 2 based on the higher layer parameter called dmrs-Type. In configuration Type 1, DM-RS are allocated on every other resource element in the frequency domain. In configuration Type 2, two consecutive DM-RS are mapped in each group of six resource elements in the frequency domain.

FIGURE 4.23  DM-RS mapping types.

356

5G NR Modeling in MATLAB®

FIGURE 4.24  DM-RS double symbol.

FIGURE 4.25  DM-RS transmission over four OFDM symbols.

Physical Layer Processing with Numerical and MATLAB® Modeling

357

4.1.4.2 Synchronization Signals 5G NR uses physical signals called Synchronization Signals (SS) for synchronizing the receivers with the radio transmission. The two types of SS used in 5G NR are the Primary Synchronization Signal (PSS) and the Secondary Synchronization Signal (SSS). A SS block (SSB) consists of the PSS, SSS, and Physical Broadcast Channel (PBCH). As defined in the 3GPP TS 38.300 [11], the PSS and SSS each occupy one OFDM symbol in the time domain and 127 subcarriers in the frequency domain whereas the PBCH spans across three OFDM symbols and 240 subcarriers but with a gap in the second OFDM symbol where the SSS is sandwiched as shown in Figure 4.26. SSBs are transmitted in half frames (five subframes) and their exact positions in the time domain are determined based on the subcarrier spacing (SCS). Table 4.5 relates the SCS with the OFDM symbol index for SSBs. Index 0 refers to the first symbol of the first slot in a half frame. The whole set of SSBs in the half frame is called the SS Burst. The SSBs are transmitted at regular intervals depending on an SSB periodicity which can be set as 5, 10, 20, 40, 80, or 160 ms. Furthermore, the network may choose not to transmit all SSBs within the half frame. In this case, the transmission pattern is communicated to the UE in the form of a bitmap in which the first bit (most

FIGURE 4.26  SS block [4].

358

5G NR Modeling in MATLAB®

TABLE 4.5 SSB Index, n, as per 3GPP TS 38.214 [2] Block Pattern

F≤3 GHz

3 GHz < f ≤ 6 GHz

F > 6 GHz

OFDM Symbol Index

Case A (SCS = 15 kHz)

N = 0, 1

N = 0, 1, 2, 3

NA

{2,8} + 14n

Case B (SCS = 30 kHz) Case C (SCS = 30 kHz) Case D (SCS = 120 kHz)

N=0

N = 0,1

NA

{4,8,16,20} + 28n

N = 0, 1

N = 0, 1, 2, 3

NA

{2,8} + 14n

NA

NA

N = 0, 1, 2, 3, 5, 6, 7, 8, 10, 11, 12, 13, 15, 16, 17, 18

{4,8,16,20} + 28n

Case E (SCS = 240 kHz)

NA

NA

N = 0, 1, 2, 3, 5, 6, 7, 8

{8, 12, 16, 20, 32, 36, 40, 44} + 56n

significant) represents the first occurring SSB, the second bit represents the second occurring SSB and so on. The value of each bit indicates whether the SSB should be transmitted. NUMERICAL EXAMPLE 4.12 Consider the scenario where Case B SSB transmission is performed over a frequency of less than 3 GHz. With bitmap 1111, SSBs are transmitted on OFDM symbol indexes {4, 8, 16, 20}. With bitmap 1010, SSBs are transmitted only on OFDM symbol indexes {4, 16}. Illustration of the SSBs in the time domain for bitmaps 1111 and 1010 are given in Figure 4.27 and Figure 4.28 respectively. All SSBs are contained in the first two subframes. Alternatively, the mapping of SSB on the resource grid for bitmaps 1111 and 1010 are given in Figure 4.29 and Figure 4.30 respectively.

FIGURE 4.27  SS burst—case B with bitmap 1111.

359

Physical Layer Processing with Numerical and MATLAB® Modeling

FIGURE 4.28  SS burst—case B with bitmap 1010. SS burst, block pattern = Case B, SCS = 30 kHz PSS SSS PBCH PBCH DM-RS

4 3

Frequency (MHz)

2 1 0 –1 –2 –3 –4 5

10

15 20 OFDM symbols

25

30

FIGURE 4.29  Resource grid—SSB Case B with bitmap 1111.

The hSSBurst function, which is generated in the 5G Toolbox’s NR PDSCH Throughput example’s folder as described in Section 5.1, can be used to create an OFDM resource grid that contains the SS burst. The function’s syntax is as follows: [waveform, grid, info] = hSSBurst (burst) The input to the function specified in the syntax are described below: burst: A structure array containing the following fields: BlockPattern - SS block pattern ('Case A', 'Case B', 'Case C', 'Case D' or 'Case E') NCellID - Physical layer cell identity (0…1007)

360

5G NR Modeling in MATLAB® SS burst, block pattern = Case B, SCS = 30 kHz 6

PSS SSS PBCH PBCH DM-RS

Frequency (MHz)

4

2

0

–2

–4

5

10

15 20 OFDM symbols

25

30

35

FIGURE 4.30  Resource grid—SSB Case B with bitmap 1010.

SampleRate - Desired sample rate of burst waveform in Hz NFrame - System Frame Number (0…1023) NHalfFrame - Half frame number (0 or 1) SSBTransmitted - Bitmap indicating blocks transmitted in the burst SSBPeriodicity - Burst set periodicity in ms (5, 10, 20, 40, 80, 160) The function returns the SS Burst waveform in array waveform, the subcarrier grid in array grid and details on the burst signal in the structure info. A screenshot of the command window after the execution of the function is shown in Figure 4.31. The inputs to the function used in Figure 4.31 are described below: ssburst- Structure array corresponding to the input burst in the function’s syntax. 4.1.4.3 Waveform Parameters 5G supports flexible numerologies (µ) such that waveform configurations, like the number of slots per frame and the SCS, can be adapted to support diverse user requirements and services. The 5G NR’s frame duration is 10 ms and each frame consists of ten 1 ms subframes. The subframes consist of slots that contain 14 OFDM

361

Physical Layer Processing with Numerical and MATLAB® Modeling

FIGURE 4.31  Command window result—SSB waveform generation.

symbols. For all numerologies, one PRB consists of 12 subcarriers in the frequency domain and one slot in the time domain. The five 5G NR numerologies defined in 3GPP TS 38.211 [10] are listed in Table 4.6 with their corresponding waveform configurations. Among all the five numerologies, only µ = 2 supports both normal and extended cyclic prefixes. If an extended cyclic prefix is chosen, the number of OFDM symbols which can fit in one slot is reduced to 12. The waveform configuration for µ = 1 is illustrated in Figure 4.32. Given the SCS and the transmission bandwidth, the number of RBs which may fit the bandwidth is determined using Table 4.7 [4].

TABLE 4.6 5G NR Numerologies µ

Subcarrier Spacing (kHz)

Number of Slots per Frame

Number of Slots per Subframe

0

15

10

1

1 2 3

30 60 120

20 40 80

2 4 8

4

240

160

16

25

11

N/A

SCS = 30 kHz

SCS = 60 kHz

5MHz

SCS = 15 kHz

Maximum Bandwidth

11

24

52

10 MHz

18

38

79

15 MHz

24

51

106

20 MHz

25 MHz

31

65

133

TABLE 4.7 Maximum NRB for Each Transmission Bandwidth [4]

38

78

160

30 MHz

NRB

51

106

216

40 MHz

65

133

270

50 MHz

79

162

N/A

60 MHz

107

217

N/A

80 MHz

121

245

N/A

90 MHz

135

273

N/A

100 MHz

362 5G NR Modeling in MATLAB®

Physical Layer Processing with Numerical and MATLAB® Modeling

363

FIGURE 4.32  Waveform configuration for µ = 1.

Guard bands are included within the total transmission bandwidth, at the two ends of the bandwidth. The minimum guard bands are each calculated using Equation (4.34) [4]: Guard band =



BW - N RB ´ SCS ´ 12 SCS (4.34) 2 2

Where, BW - Total transmission bandwidth in kHz N RB - Number of PRB SCS- Subcarrier spacing in kHz

NUMERICAL EXAMPLE 4.13 The minimum guard bands used for 5G NR with a bandwidth of 100 MHz, subcarrier spacing of 30 kHz and a total of 273 PRB is calculated as follows: Using Equation (4.34), Minimum Guard band =

BW - N RB ´ SCS ´ 12 SCS 2 2

364

5G NR Modeling in MATLAB®

(100 ´10 ) - ( 273 ´ 30 ´12 ) - 30 3

=

2

2

= 845kHz 4.1.4.4 Virtual Resource Grid to Physical Resource Grid Mapping The virtual resource grids are mapped on the physical resource grids. The two available mapping schemes are interleaved and non-interleaved mapping. For non-interleaved mapping, the physical resource grid is simply a replica of the virtual resource grid. However, if the PDSCH transmission is scheduled by a DCI format 1_0, the nth

(

CORESET Virtual Resource Block (VRB) is mapped onto the n + N start

)

th

\ PRB, where

CORESET N start is the first PRB in the CORESET where the DCI was received [10]. Interleaved mapping consists of grouping consecutive resource blocks into fixedsize bundles. The number of bundles is denoted by N bundle . The arrangement of the bundles is performed as follows [10]:

• The last VRB bundle, N bundle -1 is mapped onto the last PRB bundle, N bundle -1. • The remaining VRB bundles, j , are mapped onto PRB bundles f ( j ) where,

f ( j ) = rC + c



j = cR + r



r = 0,1,¼, R - 1



c = 0,1,¼, C - 1



R = 2



C = N bundle / R

NUMERICAL EXAMPLE 4.14 In the scenario where N bundle = 100, a VRB to PRB bundle mapping is demonstrated below: R=2

Physical Layer Processing with Numerical and MATLAB® Modeling

C=

365

N bundle R

= 100 / 2 = 50 \ c = 0,1,¼, 49 r = 0,1 When c = 2 and r = 1, j = cR + r = (2 ´ 2) + 1 =5 f ( j ) = rC + c f ( 5 ) = (1 ´ 2 ) + 2 =4 Hence the fifth VRB bundle is mapped onto the fourth PRB bundle. The continuous-time signal for each OFDM symbol is then generated. The signal on antenna port p for the mth OFDM symbol in a subframe at time t is given using Inverse Fast Fourier Transform (IFFT) as shown in Equation (4.35) as follows:



r ,m sm( ) ( t ) =

size ,m RB N grid N sc -1

å

size ,m RB m m j 2p ( k + k0m - N grid r ,m , x N sc / 2 ) Df ( t - NCP ,m Tc - t start ,m ) a k( ,m ) .e (4.35)

k =0

Where,

m Î {0,1,¼, M - 1}



subframe slot M = N slot N symbol



start , m size, m RB RB m0 - m 0 0 k0m = N grid , x + N grid , x / 2 N sc - N grid , x + N grid , x / 2 N sc 2



m m m m t start ,m £ t £ t start ,m + N u + NCP , m Tc

(

)

(

start , m

(

size, m

)

)

366

5G NR Modeling in MATLAB®

m t start , m is the starting position of OFDM symbol for numerology m in a subframe and is given by:

0 ìï m=0 m t start = í ,m m m m t + N u + NCP ,m -1 Tc otherwise îï start ,m -1

(





)

Num = 2048k.2 - m m NCP ,m

ì 512k .2 - m ïï = í144k .2 - m + 16k ï -m ïî 144k .2



extended cyclic prefix normal cyclic prefix, m = 0 or m = 7 . 2 m normal cyclic prefix m ¹ 0 or m ¹ 7 . 2 m

and Df is the subcarrier spacing

k = 64



Tc is the basic time unit in NR and has a value of 5.086 ´ 10 -10 r ,m a k( ,m ) is a complex value representing the resource element at frequency-domain index k and symbol position m in the time domain for antenna port r and numerology m . m t start ,m



start , m N grid , x is the first resource block in the resource grid. Subscript x is set to DL or UL

to identify between downlink and uplink transmissions respectively. size, m N grid , x is the size of the resource grid. N scRB is the number of subcarriers per resource block. subframe N slot is the number of slots per subframe. slot N symbol is the number of OFDM symbols per slot.

m0 is the largest value of m specified by the higher layer parameter scs-SpecificCarrierList. NUMERICAL EXAMPLE 4.15 In this example, IFFT is demonstrated given the following parameters: FFT size, N = 4 Frequency domain samples, X ( k ) = 8 X (n) =

1 N

N -1

å

X (k )´ e

k =0

j 2p kn N

Physical Layer Processing with Numerical and MATLAB® Modeling

3

1 = 8´e 4 k =0

å

= 2e

jp n 2

367

jp kn 2

{1 + e + e 1

X ( n ) = 62.4e

2

+ e3

}

jp n 2

5G utilizes CP-OFDM where samples at the end of every OFDM symbol in the time domain are copied to the start of the symbol. The CP acts as a guard band that reduces Inter-Symbol Interference (ISI) over channels containing multipath. Furthermore, the use of CP converts linear convolution with the channel to circular convolution, hence making it possible to use single-tap equalization at the receiver’s end [12]. The hOFDMModulate function, which is generated in the 5G Toolbox’s NR PDSCH Throughput example’s folder as described in Section 5.1, can be used to perform OFDM modulation. The function’s syntax is as follows: txWaveform =hOFDMModulate (gnb,grid) The inputs to the function specified in the syntax are described below: gnb: A structure array containing the following fields: NRB- Number of downlink/uplink resource blocks CyclicPrefix- Cyclic prefix length SubcarrierSpacing- Subcarrier spacing (kHz) NSymbol- First symbol number within subframe UseDCSubcarrier- Transmit data on the DC subcarrier ('On'(default), 'Off') Windowing- The number of time-domain samples over which windowing and overlapping of OFDM symbols is applied grid: Resource grid in a three-dimensional array. The function returns the OFDM modulated waveform, txWaveform. A screenshot of the command window after the execution of the function is shown in Figure 4.33. The inputs to the function used in Figure 4.33 are described below: gnb- Structure array corresponding to the input gnb in the function’s syntax. pdschGrid- Array corresponding to the input grid in the function’s syntax.

4.1.5 Channel Model 4.1.5.1 Clustered Delay Line (CDL) Channel Models Three CDL models (CDL-A, CDL-B, and CDL-C) have been defined for Non-Lineof-Sight (NLOS) scenarios and two CDL models (CDL-D and CDL-E) have been

368

5G NR Modeling in MATLAB®

FIGURE 4.33  Command window result—OFDM modulation.

defined for Line-of-Sight (LOS) scenarios. All of the CDL models have scalable delays and angle spreads. As per the 3GPP TR 38.901 [13], CDL channel coefficients are generated using the steps below: i) Generate the departure and arrival angles using Equation (4.36):

Æ n,m, AOA = Æ n, AOA + c ASAa m (4.36) Where, m is the ray’s index n is the cluster index Æ n, AOA is the cluster azimuth angles of arrival (AOA)

c ASA is the cluster-wise root-mean-square (RMS) azimuth spread of arrival angles a m is the ray offset angles within a cluster The azimuth angle of departure (Æ n,m, AOD ), zenith angle spread of arrival (q n,m, ZOA ) and zenith angle spread of departure (q n,m, ZOD ) are generated using the same procedure as for Æ n,m, AOA . ii) Randomly couple Æ n,m, AOD to Æ n, AOA , q n,m, ZOD with q n,m, ZOA and Æ n,m, AOD with q n,m, ZOD within a cluster n. iii) The cross-polarization power ratio is calculated using Equation (4.37)

k n,m = 10 X /10 (4.37)

369

Physical Layer Processing with Numerical and MATLAB® Modeling

Where, X is the per-cluster cross-polarization power ratio in dB.

{

}

qf fq ff iv) Draw random initial phase Fqq n,m , F n,m , F n,m , F n, m for four polariza-

tion combinations (qq ,qf , fq , ff ) . The initial phases are distributed

uniformly within ( -p , p ). v) Generate the channel coefficients for each cluster and for each receiver and transmitter element pair u, s using Equation (4.38):

()

HuNLOS , s, n t =

Pn M

T é M éF q n,m, ZOA , fn,m, AOA ù ê , , q rx u ê ú

( ) å êF ú ,f q m =1 êë rx,u,f ( n,m, ZOA n, m, AOA ) úû

.

( (

éF q ,f ê tx,s,q n,m, ZOD n,m, AOD êF q ,f ëê tx,s,f n,m, ZOD n,m, AOD

(

)

exp jFqq n, m ê ê k -1 exp jFfq n, m êë n,m

(

)

(

)

ù k n,m -1 exp jFqf n, m ú ú ú exp jFff n, m úû

(

)

)ùú æç j2p (rˆrxT ,n,m .drx,u ) ö÷ æç j2p (rˆtxT,n,m .dtx,s ) ö÷ æç rˆrxT ,n,m .v ö÷ exp ç t ÷ exp ç ÷ exp ç j 2p ÷ l0 l0 l0 ÷ ÷ ç )úúû çè è ø ø ø è (4.38)

Where, Pn is the cluster powers M is the number of rays per cluster. Frx ,u,q and Frx ,u,f are the field patterns of the receive antenna element u in the direction of the spherical basis vectors qˆ and fˆ respectively. Ftx ,s,q and Ftx ,s,f are the field patterns of the transmit antenna element s in the direction of the spherical basis vectors qˆ and fˆ respectively. rˆrxT ,n,m is the spherical unit vector with azimuth arrival angle fn,m, AOA and elevation é sinq n,m, ZOA cosfn,m, AOA ù ê ú angle q n,m, ZOA given by: rˆrxT ,n,m = ê sinq n,m, ZOA sinfn,m, AOA ú ê ú cosq n,m, ZOA ë û rˆtxT,n,m is the spherical unit vector with an azimuth departure angle fn,m, AOD and an é sinq n,m, ZOD cosfn,m, AOD ù ê ú T elevation angle q n,m, ZOD given by: rˆtx,n,m = ê sinq n,m, ZOD sinfn,m, AOD ú ê ú cosq n,m, ZOD ë û drx ,u is the location vector of the receive antenna element u. dtx ,s is the location vector of the transmit antenna element s. l0 is the wavelength of the carrier frequency.

370

5G NR Modeling in MATLAB®

The Doppler frequency component is given by Equation (4.39).

vn,m =



r^ Ttx ,n,m.v

l0



(4.39)

Where, v is the UT velocity vector with speed v, travel azimuth angle fv and elevation angle ¸ v and is given by: v = v. éë sinq v cosfv

sinq v sinfv

T

cosq v ùû

In MATLAB, the nrCDLChannel object from the 5G Toolbox can be used to simulate the transmission of an input signal through a CDL channel. The following object properties need to be specified: DelayProfile: CDL delay profile ('CDL-A', 'CDL-B', 'CDL-C', 'CDL-D' or 'CDL-E') DelaySpread: Desired root-mean-square delay spread in seconds. TransmitAntennaArray: Transmit antenna array characteristics. SampleRate: Sample rate of input signal in Hz. The system object can then be called in the following form to obtain the channelimpaired signal: [rxWaveform, pathgains, sampletimes] = channel (txWaveform) channel is the nrCDLChannel system object with all the properties properly defined. The input to the system object is described below: txWaveform: Input signal. The function returns the channel-impaired signal in rxWaveform, the MIMO channel path gains of the underlying fading process in pathgains, and the sample times of the channel snapshots of pathgains in sampletimes. A screenshot of the command window after calling the system object is shown in Figure 4.34. The inputs to the function used in Figure 4.34 are described below: txWaveform- Array corresponding to the input txWaveform in the function’s syntax. 4.1.5.2 Tapped Delay Line (TDL) Channel Models Three TDL models (TDL-A, TDL-B, and TDL-C) have been defined for NLOS scenarios and two TDL models (TDL-D and TDL-E) have been defined for LOS scenarios. TDL models are used for non-MIMO evaluations and have scalable delay spread. TDL models are generated from CDL models through spatial filtering. The procedures for generating a TDL model from a CDL one are as follows:

Physical Layer Processing with Numerical and MATLAB® Modeling

371

FIGURE 4.34  Command window result—CDL channel.

’ i) Choose spatial filters Atx’ and Arx defined in the Local Coordinate System (LCS). For example, the filter for an isotropic pattern in LCS is given in Equation (4.40):

 

A{’tx ,rx} (q ¢, f ¢ ) = 1 (4.40)

ii) Transform the spatial filters to the global coordinate system (GCS) to obtain Atx and Arx with the pointing direction q p , f p centered within the filter. iii) Determine the TDL cluster power values using Equation (4.41)

(

 

)

PnTDL = PnCDL Arx (q n, ZOA , fn, AOA ) Atx (q n, ZOD , fn, AOD )

(4.41)

In MATLAB, the nrTDLChannel object from the 5G Toolbox can be used to simulate the transmission of an input signal through a TDL channel. The following object properties need to be specified: DelayProfile: CDL delay profile ('TDL-A', ' TDL-B', 'TDL-C', 'TDL-D' or 'TDL-E') DelaySpread: Desired root-mean-square delay spread in seconds. NumTransmitAntennas: Number of transmit antennas. NumReceiveAntennas: Number of receive antennas. SampleRate: Sample rate of input signal in Hz.

372

5G NR Modeling in MATLAB®

FIGURE 4.35  Command window result—TDL channel.

The system object can then be called in the following form to obtain the channelimpaired signal: [rxWaveform, pathgains, sampletimes] = channel (txWaveform) channel is the nrTDLChannel system object with all the properties properly defined. The input to the system object is described below: txWaveform: Input signal. The function returns the channel-impaired signal in rxWaveform, the MIMO channel path gains of the underlying fading process in pathgains, and the sample times of the channel snapshots of pathgains in sampletimes. A screenshot of the command window after calling the system object is shown in Figure 4.35. The inputs to the function used in Figure 4.35 are described below: txWaveform- Array corresponding to the input txWaveform in the function’s syntax. A plot of the path gain of a simple TDL channel is given in Figure 4.36.

4.2 RECEIVER MODELING The receiver of the 5G physical layer model for PDSCH processing is described in this section. Figure 4.37 shows an illustration of process blocks in the transmitter model and the data formats at the input of the process blocks. The UE uses the received SSBs to synchronize with the gNodeB. The symbols on the resource grid are then recovered by using CP-OFDM demodulation and channel estimation is performed.

Physical Layer Processing with Numerical and MATLAB® Modeling

373

FIGURE 4.36  Channel path gain.

The received data block in the lth layer over which PDSCH decoding is performed is denoted as J l and symbols in this block are labelled as j l ( 0 ) , j l (1) , …, j l ( N Jl - 1) , where N Jl is the number of symbols in that layer. Layer demapping is performed to combine the symbols in each layer into their corresponding PDSCH code-words. The recovered PDSCH code-word with index a is denoted H l and symbols in the code-word are denoted as h a ( 0 ) , h a (1), …, h a ( N H - 1) . The symbols are then demodulated to obtain soft bits denoted by g a’ ( 0 ) , g a¢ (1) ,¼, g a ’ ( NG - 1) . Descrambling is then performed on these soft bits to obtain code-word g a ( 0 ) , g a (1) ,¼, g a ( NG - 1) . DLSCH decoding is then initiated. Rate recovery is performed on the descrambled code-word to obtain the code-word d xa ( 0 ), d xa (1) ,…, d xa ( N D - 1) . LDPC decoding is then executed to obtain the decoded code-word cxa ( 0 ) , cxa (1) ,…, cxa ( K - 1) . Desegmentation is applied to obtain code-word b a ( 0 ) , b a (1), …, b a ( N B - 1) over which CRC decoding is performed. The output of the PDSCH decoding block is denoted as out a ( 0 ), out a (1) , …, out a ( N A - 1) . The process blocks in the receiver and the MATLAB codes used to simulate each block are described in Subsections 4.2.1 to 4.2.5.

4.2.1 Synchronization In the 5G NR network, the UEs decode the SSBs to acquire the necessary timing information required to synchronize with the gNodeB. This includes information

374

5G NR Modeling in MATLAB®

FIGURE 4.37  5G NR physical layer PDSCH processing receiver model.

about the SS block pattern, the waveform sample rate and the number of SS blocks in a burst as described in Subsection 4.1.4.2. The nrPerfectTimingEstimate function from the MATLAB 5G Toolbox can be used to perform perfect timing estimation necessary for synchronization at the receiver’s end. The function’s syntax is as follows: [offset,mag] = nrPerfectTimingEstimate (pathGains,pathFilters) The inputs to the function specified in the syntax are described below: pathGains: Channel path gains of the fading process. pathFilters: Impulse response of path filter.

Physical Layer Processing with Numerical and MATLAB® Modeling

375

FIGURE 4.38  Command window result—synchronization.

The function returns the timing offset of samples offset and the magnitude of the channel impulse response mag. A screenshot of the command window after the execution of the function is shown in Figure 4.38. The inputs to the function used in Figure 4.38 are described below: pathGains- Array corresponding to the input pathGains in the function’s syntax. pathFilters- Array corresponding to the input pathFilters in the function’s syntax.

4.2.2 CP-OFDM Demodulation CP-OFDM demodulation is performed on the received signal by using Fast-Fourier Transform to recover the symbols received from the resource grid. The hOFDMDemodulate function generated in the MATLAB example’s folder can be used to perform CP-OFDM demodulation. The function’s syntax is as follows: rxGrid = hOFDMDemodulate(gnb,rxWaveform) The inputs to the function specified in the syntax are described below:

376

5G NR Modeling in MATLAB®

gnb: A structure array containing the following fields: NRB- Number of downlink/uplink resource blocks CyclicPrefix- Cyclic prefix length ('Normal' (default) or 'Extended') SubcarrierSpacing- Subcarrier spacing (kHz) (default value is 15) NSymbol- First symbol’s index within subframe (default value is 0) UseDCSubcarrier- Define if data is transmitted on the DC subcarrier ('On' (default) or 'Off') WaveformType- Waveform OFDM type ('CP-OFDM'(default), 'F-OFDM', 'W-OFDM') Windowing- The number of time-domain samples over which windowing and overlapping of OFDM symbols is applied rxWaveform: Received waveform to be demodulated. The function outputs the resource element array rxGrid which contains the CP-OFDM demodulated complex symbols. A screenshot of the command window after the execution of the function is shown in Figure 4.39. The inputs to the function used in Figure 4.39 are described below: gnb- Structure array corresponding to the input gnb in the function’s syntax. rxWaveform- Array corresponding to the input rxWaveform in the function’s syntax.

FIGURE 4.39  Command window result—CP-OFDM demodulation.

Physical Layer Processing with Numerical and MATLAB® Modeling

377

4.2.3 Channel Estimation Channel estimation is necessary to increase the accuracy of demodulation. In 5G radio transmission, a Channel Status Information Reference Signal (CSI-RS) is sent by the gNodeB to allow UEs to perform channel estimations. The CSI-RS contains a pseudo random sequence and is mapped to specific resource elements on the resource grid. A CSI-RS is configured on a per-device basis and occupies a single resource element per port in resource blocks. CSI-RS can be allocated a position on the resource grid such that it does not collide with other signals such as the DM-RS, CORESET, and SS blocks. The CSI-RS structure is illustrated in Figure 4.40. CSI-RS resource elements can be Zero-Power (ZP-CSI-RS) or Non-Zero-Power (NZP-CSI-RS). ZP-CSI-RS refer to transmission gaps on the resource grid where the UE can make measurements for interference signals. On the other hand, NZPCSI-RS are mainly used for channel estimation [14]. The channel response at each subcarrier can be estimated by using the reference signals placed on the subcarriers. The estimation is performed by dividing the received version of the reference signal in the subcarrier by the known transmitted value in the reference signal as follows [15]: H (w )w = k Df =



Y (w )w = k Df

X (w )w = k Df

(4.42)

11 10 CSIRS

9

Subcarrier

8 7 6 5 4 3 2 1 0 0

1

2

3

4

5

6

7

8

OFDM Symbol

FIGURE 4.40  CSI-RS structure—single port.

9

10

11

12

378

5G NR Modeling in MATLAB®

Where, X (w ) - Transmitted signal in frequency domain. Y (w ) - Received signal in frequency domain. fk - Integer multiple of subcarrier spacing. For simulation purposes, the channel estimation procedure can be simplified by using the channel’s actual parameters on the receiver’s side to reconstruct the channel’s impulse response. OFDM demodulation is then performed to obtain the overall channel estimate grid. The nrPerfectChannelEstimate function available from the MATLAB 5G Toolbox can be used to perform perfect channel estimation. The function’s syntax is as follows: estChannelGrid = nrPe​rfect​Chann​elEst​imate​(path​Gains​,path​Filte​rs,nr​b,scs​,init​ ialSl​ot,to​f fset​, sampleTimes, cpl) The inputs to the function specified in the syntax are described below: pathGains: Channel path gains of the fading process. pathFilters: Impulse response of path filter. nrb: Number of resource blocks. scs: Subcarrier spacing. initialSlot: Initial slot number. toffset: Timing offset in samples. sampleTimes: Sample times of channel snapshots. cpl: Cyclic prefix length. The function returns the perfect channel impulse response estimate, estChannelGrid. A screenshot of the command window after the execution of the function is shown in Figure 4.41. The inputs to the function used in Figure 4.41 are described below: pathGains- Array corresponding to the input pathGains in the function’s syntax. pathFilters- Array corresponding to the input pathFilters in the function’s syntax. gnb.NRB- Field from the gnb structure array to store the number of resource blocks. gnb.SubcarrierSpacing-Field from the gnb structure array to specify the subcarrier spacing. pdsch.Nslot- Field from the pdsch structure array to specify the initial slot number. offset - Array corresponding to the input toffset in the function’s syntax.

FIGURE 4.41  Command window result—channel estimation.

Physical Layer Processing with Numerical and MATLAB® Modeling

379

380

5G NR Modeling in MATLAB®

sampleTimes - Array corresponding to the input sampleTimes in the function’s syntax. gnb.CyclicPrefix- Field from the gnb structure array to specify the cyclic prefix length.

4.2.4 PDSCH Decoding PDSCH decoding is performed on the OFDM demodulated signal to recover the DLSCH data. The decoding process involves sub-processes illustrated in Figure 4.42 and elaborated in Subsections 4.2.4.1 to 4.2.4.3. 4.2.4.1 Layer Demapping The first step in PDSCH decoding is layer demapping. The N Layers layers received at the receiver are combined into NCW PDSCH code-words by using the reverse mapping given in Table 4.4. The symbols in the code-word with index a is denoted as h a ( 0 ) , h a (1), …, h a ( N H - 1) .

FIGURE 4.42  PDSCH decoding subprocesses.

Physical Layer Processing with Numerical and MATLAB® Modeling

381

NUMERICAL EXAMPLE 4.16 In this example, the layer demapping of the five layers below onto two PDSCH code-words is demonstrated: j 0 = ( -0.46 - 0.16 j ) , ( 0.46 - 1.09 j� ) , ( -0.47 + 1.05 j� ) j 1 = ( 0.45 + 1.08 j ) , ( -1.07 - 1.05 j� ) , ( -1.10 - 1.11 j� ) j 2 = ( 0.41 - 0.13 j� ) , (1.02 - 1.06� j ) j 3 = (1.04 + 1.08 j� ) , ( -0.44 + 1.03� j ) j 4 = ( 0.46 - 1.05 j� ) , ( -0.43 - 1.06� j ) Applying the inverse of the equations in Table 4.4 used for mapping two PDSCH code-words on five layers, the indices of each symbol from the five layers in the two PDSCH code-words are defined as follows: h 1 ( 2i ) = j 0 ( i ) h 1 ( 2i + 1) = j 1 ( i ) h 2 ( 3i ) = j 2 ( i ) h 2 ( 3i + 1) = j 3 ( i ) h 2 ( 3i + 2 ) = j 4 ( i ) Taking i = 0, h 1 ( 0 ) = j 0 ( 0 ) = ( -0.46 - 0.16 j ) h 1 (1) = j 1 ( 0 ) = ( 0.45 + 1.08 j ) h 2 ( 0 ) = j 2 ( 0 ) = ( 0.41 - 0.13 j ) h 2 (1) = j 3 ( 0 ) = (1.04 + 1.08 j ) h 2 ( 2 ) = j 4 ( 0 ) = ( 0.46 - 1.05 j )

382

5G NR Modeling in MATLAB®

Taking i = 1, h 1 ( 2 ) = j 0 (1) = ( 0.46 - 1.09 j ) h 1 ( 3 ) = j 1 (1) = ( -1.07 - 1.05 j ) h 2 ( 3 ) = j 2 (1) = (1.02 - 1.06 j ) h 2 ( 4 ) = j 3 (1) = ( -0.44 + 1.03 j ) h 2 ( 5 ) = j 4 (1) = ( -0.43 - 1.06 j ) Taking i = 2, h 1 ( 4 ) = j 0 ( 2 ) = ( -0.47 + 1.05 j ) h 1 ( 5 ) = j 1 ( 2 ) = ( -1.10 - 1.11 j ) Hence the output of the layer demapping process is as follows: H 1 = ( -0.46 - 0.16 j ) , ( 0.45 + 1.08 j ) , ( 0.46 - 1.09 j ) , ( -1.07 - 1.05 j ) ,

( -0.47 + 1.05 j ) , ( -1.10 - 1.11 j ) H 2 = ( 0.41 - 0.13 j ) , (1.04 + 1.08 j ) , ( 0.46 - 1.05 j ) , (1.02 - 1.06 j ) , ( -0.444 + 1.03 j ) ,

( -0.43 - 1.06 j )

The 5G MATLAB toolbox includes the nrLayerDemap function to perform the layer demapping process. The syntax of the function is as follows: Symbols = nrLayerDemap(sym) The function converts the input sym consisting of the layered symbols into output array, symbols, which consists of one or two code-words based on the number of layers. A screenshot of the command window after the execution of the function is shown in Figure 4.43. The inputs to the function used in Figure 4.43 are described below: sym- Array corresponding to the input sym in the function’s syntax.

Physical Layer Processing with Numerical and MATLAB® Modeling

383

FIGURE 4.43  Command window result—layer demapping.

4.2.4.2 Demodulation Soft decision is used to demodulate the complex symbols h a ( 0 ) , h a (1), …, h

a

( N H - 1) in every PDSCH code-word to soft bits g a’ ( 0 ) , g a’ (1) , …, g a ’ ( NG - 1)

. Compared to hard decision which simply outputs the closest constellation symbol from the detected symbol, soft decision indicates how far the detected symbol is from the constellation’s symbols. Such an indication is essential for more accurate error correction. The soft decision of each bit is made by calculating their Logarithm Likelihood Ratio (LLR) given in Equation (4.43). æ P ( g ’ = 1) ö LLR = ln ç ÷ (4.43) ç P ( g ’= 0) ÷ è ø

Where,

P ( g ’= 1) is the probability of the bit being 1. P ( g ’= 0 ) is the probability of the bit being 0.

384

5G NR Modeling in MATLAB®

NUMERICAL EXAMPLE 4.17 In this example, 64-QAM demodulation is applied to the following received symbol using a noise variance scaling factor Ã2 = 0.0661: h 1 ( 0 ) = ( -0.46 - 1.08 j ) We denote the real part of the received symbol as ry and the imaginary part as qy. We also denote the x-coordinates and y-coordinates for points on the 64-QAM constellation (given in Figure 4.17) as follows: a1 = 0.1543 a2 = 0.4629 a3 = 0.7715 a4 = 1.080 æ ( ry - a1 )2 ( ry - a 2 )2 ( ry - a 3)2 ( ry - a 4 )2 ö 2 2 2 ç - s2 +e s +e s +e s ÷ = ln ç e ÷÷ ç - ( ry + a1 )2 ( ry + a 2 )2 ( ry + a 3)2 ( ry + a 4 )2 ø ç e s 2 + e- s 2 + e- s 2 + e- s 2 è

ö ÷ ÷ ÷ ÷ ø

æ ( qy - a1 )2 ( qy - a 2 )2 ( qy - a 3)2 ( qy - a 4 )2 2 2 2 ç æ P g ’(1) = 1 ö s2 +e s +e s +e s ÷ = ln ç e g 1¢ (1) = ln ç 2 2 2 ç - ( qy + a1 ) ç P g ’(1) = 0 ÷ ( qy + a 2 ) ( qy + a 3) ( qy + a 4 )2 è ø 2 2 2 2 çe s +e s +e s +e s è

ö ÷ ÷ ÷ ÷ ø

( (

) )

æ P g ’ (0) = 1 1¢ g ( 0 ) = ln ç çç P g ’ 0 = 0 ( ) è = -6.10

( (

) )

= -23.26 æ ( ry + a1 )2 ( ry + a 2 )2 ( ry - a1 )2 ( ry - a 2 )2 2 2 2 2 ç æ P g ’( 2 ) = 1 ö s +e s +e s +e s ÷ = ln ç e g 1¢ ( 2 ) = ln ç ç - ( ry + a 3)2 ç P g ’( 2 ) = 0 ÷ ( ry + a 4 )2 ( ry - a 3)2 ( ry - a 4 )2 è ø 2 2 2 2 çe s +e s +e s +e s è = 1.68

ö ÷ ÷ ÷ ÷ ø

æ ( qy - a1 )2 ( qy - a 2 )2 ( qy + a1 )2 ( qy + a 2 )2 2 2 2 ç - s2 ö +e s +e s +e s ÷ = ln ç e ç - ( qy - a 3)2 ÷ ( qy - a 4 )2 ( qy + a 3)2 ( qy + a 4 )2 ø ç e s 2 + e- s 2 + e- s 2 + e- s 2 è

ö ÷ ÷ ÷ ÷ ø

( (

( (

) )

) )

æ P g ’( 3 ) = 1 g 1¢ ( 3 ) = ln ç ç P g ’( 3 ) = 0 è = -5.97

Physical Layer Processing with Numerical and MATLAB® Modeling

385

) )

æ ( ry + a 2 )2 ( ry + a 3)2 ( ry - a 2 )2 ( ry - a 3)2 2 2 2 ç - s2 ö +e s +e s +e s ÷ = ln ç e ç - ( ry + a1 )2 ÷ ( ry + a 4 )2 ( ry - a1 )2 ( ry - a 4 )2 ø ç e s 2 + e- s 2 + e- s 2 + e- s 2 è

ö ÷ ÷ ÷ ÷ ø

) )

æ ( qy + a 2 )2 ( qy + a 3 ) 2 ( qy - a 2 )2 ( qy - a 3)2 ö 2 2 2 ç - s2 +e s +e s +e s ÷ = ln ç e ÷÷ ç - ( qy + a1 )2 ( qy + a 4 )2 ( qy - a1 )2 ( qy - a 4 )2 ø ç e s 2 + e- s 2 + e- s 2 + e- s 2 è

ö ÷ ÷ ÷ ÷ ø

( (

æ P g ’( 4 ) = 1 g 1¢ ( 4 ) = ln ç ç P g ’( 4 ) = 0 è = 1.60

( (

æ P g ’ ( 5) = 1 1¢ g ( 5 ) = ln ç çç P g ’ 5 = 0 ( ) è = -1.43

Hence the demodulated code-word is as follows: G1¢ = -6.10 - 23.26 1.68 - 5.97 1.60 - 1.43

The nrSymbolDemodulate function from MATLAB’s 5G Toolbox can be used to perform demodulation. The syntax of the function is as follows: Demodulated = nrSymbolDemodulate(symbols,mod,nVar) The inputs to the function specified in the syntax are described below: symbols: Code-word to demodulate. mod: Modulation scheme. nVar: Noise variance. The function returns the demodulation output bits in the form of array demodulated. A screenshot of the command window after the execution of the function is shown in Figure 4.44. The inputs to the function used in Figure 4.44 are described below: symbols{q}- Array corresponding to the input symbols in the function’s syntax. scrambled is a cell array in which each scrambled code-words is stored in a cell. mods{q}- Array corresponding to the input mod in the function’s syntax. mods is a cell array in which the modulation order of each code-words is specified in a cell. nVar- Array corresponding to the input nVar in the function’s syntax.

386

5G NR Modeling in MATLAB®

FIGURE 4.44  Command window result—demodulation.

4.2.4.3 Descrambling The soft-bits sequences, G a’ obtained from the demodulator are descrambled using the same gold sequence that is used to scramble the data. The outputs are denoted as g a ( 0 ) , g a (1), …,g a ( NG - 1) . The gold sequence is generated using the same procedures as demonstrated in Subsection 4.1.2.1. However, the gold sequence is signed before being applied to the soft-bits. That is, all ones in the gold sequence, c, are substituted by “−1” and all zeroes are substituted by “1”. The descrambling is performed using the element-wise multiplication of the G a’ and c arrays. NUMERICAL EXAMPLE 4.18 In this example, a soft-bit stream, G1' = (−21 −11 32 15 20 −40 13 −12 33 −9) is de-scrambled using a signed gold sequence c = (1 1 1 −1 1 1 −1 −1 −1 1): The output of the descrambling process, G1 = G1¢ .* c = ( -21 -11 .* ( 1

1

= ( -21 -11

32 15 1 -1

20 -40 13 -12 1

1 -1

33 -9 )

-1 -1

1

)

32 -15 20 -40 -13 12 -33 -9 )

The nrPDSCHPRBS function from MATLAB’s 5G Toolbox, described in Subsection 4.1.2.1 can be used to generate the scrambling sequence to perform descrambling.

Physical Layer Processing with Numerical and MATLAB® Modeling

387

FIGURE 4.45  Command window result—descrambling.

A screenshot of the command window after the execution of the function is shown in Figure 4.45. The inputs to the function used in Figure 4.45 are described below: nid- Array corresponding to the input nid in the function’s syntax. rnti- Array corresponding to the input rnti in the function’s syntax. q-1- Array corresponding to the input q in the function’s syntax. length(demodulated{q})- Value corresponding to the input n in the function’s syntax described in Subsection 4.1.2.1. demodulated is a cell array in which each demodulated code-words is stored in a cell.

4.2.5 DLSCH Decoding The DLSCH decoding process involves the sub-processes illustrated in Figure 4.46 to recover the transport blocks at the receiver’s side. The subprocesses are explained in Subsections 4.2.5.1 to 4.2.5.4. 4.2.5.1 Rate Recovery The rate recovery process involves code-block deconcatenation, bit deinterleaving and the reverse bit selection process. In the code block deconcatenation, the received code blocks, G a are split back into multiple rate-matched segments Fxa . The receiver determines the number of segments to be produced based on the transport block size and the PDSCH target code-rate communicated to it by the gNodeB. The lengths of each segment are then calculated using Equation (4.18).

388

5G NR Modeling in MATLAB®

FIGURE 4.46  DLSCH dDecoding subprocesses.

Bit deinterleaving is then performed in each segment to reorder the bits into their original positions using the steps below:



1) Reshape the code-word Fxa into a Qm ´

MF

R

æ ç f a (0) x ç ç ç = çç f xa (1) ç ç  ç ç f a Q -1 ç x ( m ) è

NEa x

Qm

f xa ( Qm )

¼

f xa ( Qm + 1)

¼





f xa ( 2Qm - 1) ¼

matrix as shown below:

æ æ NEa öö ö f xa ç Qm ç x - 1 ÷ ÷ ÷ ç Qm ÷÷ ÷ ç è øø ÷ è æ æ NEa ö ö ÷÷ aç x f x Qm ç - 1 ÷ + 1 ÷ ÷ (4.44) ç Qm ÷ ÷ ç è ø ø÷ è ÷  ÷ ÷ a fx NEa - 1 ÷ x ø

(

)

389

Physical Layer Processing with Numerical and MATLAB® Modeling



2) Transpose the matrix:



MF

T

æ f xa ( 0 ) ç ç f xa ( Qm ) ç  =ç ç æ æN öö ç f a ç Q ç E xa - 1 ÷ ÷ x m çç ç ç Qm ÷÷ è øø è è

f xa (1)

¼

f xa ( Qm + 1) 

¼ 

æ æ NEa ö ö f xa ç Qm ç x - 1 ÷ + 1 ÷ ¼ ç Qm ÷ ÷ ç è ø ø è

f xa ( Qm - 1) ö ÷ f xa ( 2Qm - 1) ÷ ÷  ÷ ÷ a f x N E a - 1 ÷÷ x ÷ ø

(

)

(4.45) 3) Arrange the elements from the transposed matrix in a column order to obtain E xa : æ ö f xa ( 0 ) ç ÷ ç ÷ f xa ( Qm ) ç ÷  ç ÷ ç æ æ NEa öö÷ ç f a ç Q ç x - 1÷ ÷ ÷ m ç x ç Qm ÷÷÷ a E x = ç çè è øø÷ ç ÷ f xa (1) ç ÷ ç ÷ f xa ( Qm + 1) ç ÷ ç ÷  ç ÷ ÷ ç f xa N E a - 1 x è ø



(

(4.46)

)

The reverse bit selection process is then performed on segments E xa to obtain segments Dxa . In this process, filler bits, denoted by value 0, are added back to the input code block segments so that LDPC decoding can be performed. Furthermore, based on the redundancy version of the transmission, the bits are placed at the proper index. The start bit position for each redundancy version is given in Table 4.3. NUMERICAL EXAMPLE 4.19 In this example, the bit deinterleaving process is performed on the following descrambled code-word for the case where modulation order, Qm = 4: F10 = ( -21� � -11 � � � � � � 32 � � -15 � � 20 � -40 � -13 � � � 12 �� )

1) The code-word F10 is reshaped into a 4×2 matrix as shown below:

390

5G NR Modeling in MATLAB®

æ -21 20 ö ç ÷ ç -11 -40 ÷ ç 32 -13 ÷ ç ÷ è -15 12 ø



2) The matrix is transposed: æ -21 -11 32 -15 ö ç ÷ è 20 -40 -13 12 ø 3) The elements from the transposed matrix are arranged in a column order to obtain E10 : E10 = ( -21 20 -11 -40 32 -13 -15 12 )

T

The nrRateRecoverLDPC function from the MATLAB’s 5G Toolbox can be used to perform rate recovery. The syntax of the function is as follows: Raterecovered ,numC​B,Nre​f)

=

nrRa​teRec​overL​DPC(r​xSoft​Bits,​trblk​len,R​,rv,m​od,nL​ayers​

The inputs to the function specified in the syntax are described below: rxSoftBits: Received descrambled soft-bits. trblklen: Transport block length. r: Target code-rate. rv: Redundancy version. mod: Modulation scheme. nLayers: Number of transmission layers. numCB: Number of scheduled code block segments. Nref: Limited buffer rate matching. The function returns the rate-recovered code-block segments in the form of matrix raterecovered. A screenshot of the command window after the execution of the function is shown in Figure 4.47. The inputs to the function used in Figure 4.47 are described below: • rxSoftBits- Array corresponding to the input rxSoftBits in the function’s syntax. • outCWLen- Array corresponding to the input trblklen in the function’s syntax. • targetCodeRate- Array corresponding to the input r in the function’s syntax.

Physical Layer Processing with Numerical and MATLAB® Modeling

391

FIGURE 4.47  Command window result—rate recovery.

• • • •

rv- Array corresponding to the input rv in the function’s syntax. modScheme- Array corresponding to the input mod in the function’s syntax. nlayers- Array corresponding to the input nLayers in the function’s syntax. ncb- Array corresponding to the input numCB in the function’s syntax.

obj.LimitedBufferSize- Field from the obj structure array for specifying the limited rate-matching buffer size. 4.2.5.2 LDPC Decoding In 5G NR DLSCH, LDPC decoding is performed on each segment, Dxa , using algorithms such as the Belief-Propagation Algorithm (BPA) to obtain LDPC decoded segments denoted by C xa . Belief-Propagation Algorithm The BPA involves the following steps: The LLR of the bit © if the received symbol is w is calculated as follows:

LLR ( W ) = log

P(w = 0 | ©) (4.47) P(w = 1 | ©)

For Additive White Gaussian Noise (AWGN) channels, the LLR of the received noisy vector y is approximated as follows [16]:

392

5G NR Modeling in MATLAB®

LLR = -



2y

s2

(4.48)

Where, σ 2 is the variance of the noisy vector. A matrix M of the same size as H is initialized such that it contains all the LLR values at all the positions where there is a 1 in H . Matrices A and B are obtained from matrix H such that A stores the position of each variable node connected to each check node and B stores the position of each check node connected to each variable node [16]. Matrix E that contains the extrinsic message is computed as follows:



æ E j,i = 2tanh -1 ç tanh M j,i¢ / 2 ç ¢ÎB j , i’¹ i i è

Õ

(

ö

) ÷÷ (4.49) ø

The total LLR of the ith bit, Li , is the sum of input a priori LLR, ri , and the LLRs from every check node connected to the bit [16]:

Li = ri +

åE

j, i (4.50)

jÎAi

The sign of the total LLR of each bit is used to decode the code-word by performing hard decision. Bits with positive total LLRs are decoded as zeroes whereas those with negative total LLRs are decoded as ones. The syndrome s is then calculated using Equation (4.51) to check if all the paritycheck constraints have been satisfied [17].

s = HzT (4.51)

Where, z is the decoded LDPC code-word. If the syndrome is zero, it implies that all the parity check constraints are satisfied, and the decoding process ends [17]. Else matrix M is updated with the message received by the check nodes from the bit nodes as follows:

M j ,i = Li - E j ,i (4.52)

The decoder then proceeds with the next iteration which begins with the calculation of the extrinsic message with Equation (4.49) using the updated matrix M .

Physical Layer Processing with Numerical and MATLAB® Modeling

393

NUMERICAL EXAMPLE 4.20 In this example, the LDPC decoding using the BPA is demonstrated. Given the following received noisy vector r and parity check matrix H: r = [0.0290 −0.2253 −0.7231 2.5375 1.2323 −1.4329 −0.0972 1.9412] é1 ê 0 H =ê ê1 ê ë0

1 0 0 1

1 0 0 0

0 1 1 0

0 1 0 1

0 1 0 0

0 0 1 0

0ù ú 0ú 0ú ú 1û

The LDPC decoding is performed as follows: Using Equation (4.48), the LLR of r is calculated (Assuming σ = 0.717). LLR = éë -0.0809 0.6285 2.0170 - 7.0781 - 3.4374 3.9969 0.2711 - 5.4148 ùû Matrices A and B are obtained from H : é 1 1 1 ¥ ¥ ¥ ¥ ¥ù ê ú ¥ ¥ ¥ 2 2 2 ¥ ¥ú A=ê ê 3 ¥ ¥ 3 ¥ ¥ 3 ¥ú ê ú ë¥ 4 ¥ ¥ 4 ¥ ¥ 4 û é 1 2 3 ¥ ¥ ¥ ¥ ¥ù ê ú ¥ ¥ ¥ 4 5 6 ¥ ¥ú B=ê ê 1 ¥ ¥ 4 ¥ ¥ 7 ¥ú ê ú ë¥ 2 ¥ ¥ 5 ¥ ¥ 8 û Matrix M is initialized by mapping the LLRs on the rows of the parity check matrix: 0 0 0 0 0 ù é -0.0809 0.6285 2.0170 ê ú -7.0781 -3.4374 3.9969 0 0 0 0 0 ú 0 M( ) = ê ê -0.0809 0 0 -7.0781 0 0 0.2711 0 ú ê ú 0.6285 0 0 0 0 -3.4374 -5.4148 ûú êë 0

The extrinsic information for the first iteration is computed using Equation (4.49). The computation of the first value in the extrinsic information matrix is shown below:

394

5G NR Modeling in MATLAB®

æ æ 0.6285 ö æ 2.0170 ö ö (1) E1,1 = 2tanh -1 ç tanh ç ´ tanh ç ÷ ÷ ÷ = 0.4743 è 2 ø è 2 øø è The extrinsic information matrix for the first iteration is given below: 0 0 0 0 0 ù é 0.4743 -0.0619 -0.0246 ê ú -2.9860 -3.9521 3.4115 0 0 0 0 0 ú ê -0.22707 0 0 -0.0109 0 0 0.0808 0 ú ê ú 3.3079 0 0 0 0 -0.6225 -0.5869 ûú êë 0

1 E( ) = ê

The values in each column of the extrinsic information matrix and each intrinsic LLR value are used to calculate the total LLR value corresponding to the first bit in the code-word using Equation (4.50). The calculation for the first total LLR value is shown below:

(

(1) L1 = -0.0809 + 0.4743 + ( -0.2707 )

) = 0.1227

Similarly, the values in the second column of the extrinsic information matrix and the second intrinsic LLR value are used to calculate the total LLR value for the second bit in the code-word:

(

)

(1) L2 = 0.6285 + ( -0.0619 ) + 3.3079 = 3.8745

The calculated total LLR for the LDPC code-word is given below: 1 L( ) = éë0.1227 3.8745 1.9924 -10.0750 -8.0120 7.4084 0.3519 -6.0017 ùû

The decoded sequence for the first iteration is obtained by decoding positive total LLRs as 0 and negative total LLRs as 1: 1 z ( ) = éë00011001ùû

The syndrome is then computed using Equation (4.51) and is obtained as: s = éë0010 ùû The decoder proceeds with the next iteration because the syndrome is not zero. Using Equation (4.52), the matrix M is updated. The computation of the first value in matrix M is shown below:

Physical Layer Processing with Numerical and MATLAB® Modeling

395

M1,1 = -0.0809 + ( -0.2707 ) = -0.3516 The updated M matrix is obtained as follows: 0 0 0 0 0 ù é -0.3516 3.9363 2.0170 ê ú -7.0890 -4.0599 3.9969 0 0 0 0 0 ú ê 0.3934 0 0 -10.0641 0 0 0.2711 0 ú ê ú 0.5666 0 0 0 0 -7.3894 -5.4148 ûú êë 0

1 M( ) = ê

For the second iteration, the extrinsic information matrix and the decoded sequence is obtained as follows: 0 0 0 0 0 ù é 1.8827 -0.2678 -0.3378 ê ú -3.3351 -3.9525 4.0127 0 0 0 0 0 ú ê -0.22711 0 0 0.0524 0 0 0 ú -0.3934 ê ú 5.2848 0 0 0 0 -0.5613 -0.5658 úû êë 0

2 E( ) = ê

2 z ( ) = éë00011011ùû

The syndrome calculated at this iteration is zero. Hence the decoding pro2 cess is stopped and the decoder outputs z ( ).

The nrLDPCDecode function from the MATLAB’s 5G Toolbox can be used to perform LDPC decoding. The syntax of the function is as follows: [decoded,actNumIter,finalParityChecks] = nrLD​PCDec​ode(r​atere​cover​edD,b​ gn,ma​xNumI​ter,N​ame,V​alue)​ The inputs to the function specified in the syntax are described below: raterecoveredD: Rate-recovered soft-bits in double-precision numeric data type. bgn: Base graph number. maxNumIter: Maximum number of decoding iterations.

396

5G NR Modeling in MATLAB®

Name-Value pair: Allow the user to specify the following: Name “OutputFormat” “DecisionType” “Algorithm”

Value

To output only information bits.

“whole” “hard” “soft” “Belief propagation”

To output complete decoded code-word. To output hard decoded data. To output LLRs. To specify the use of belief-passing or messagepassing algorithm. To specify the use of the layered belief-passing algorithm. To specify the use of the layered belief propagation algorithm with normalized min-sum approximation. To specify the use of the layered belief propagation algorithm with offset min-sum approximation.

“Layered belief propagation” “Normalized min-sum”

“Offset min-sum”

“ScalingFactor” “Offset” “'Termination”

Description

“info”

Scalar in the range of 0 to 1 Non-negative finite real scalar “early”

Scaling factor for normalized min-sum decoding.

“max”

Terminate decoding after reaching maxNumIter number of iterations.

Offset for offset min-sum decoding. Terminate decoding after all parity checks are satisfied.

The function returns the following outputs: decoded: Decoded LDPC code-word. actNumIter: Actual number of iterations (optional output). finalParityChecks: Final parity check results (optional output). A screenshot of the command window after the execution of the function is shown in Figure 4.48. The inputs to the function used in Figure 4.48 are described below: raterecoveredD- Array corresponding to the input raterecoveredD in the function’s syntax. info.BGN- Field from the info structure array for specifying the base graph number. obj.MaximumLDPCIterationCount- Field from the obj structure array for specifying the maximum number of decoding iterations.

Physical Layer Processing with Numerical and MATLAB® Modeling

397

4.2.5.3 Code Block Desegmentation Code block desegmentation is then performed by combining the segments C xa back into code-words B a which contains the information bits and CRC bits as shown in Figure 4.49. CRC bits that were included in each segment during the segmentation process described in Subsection 4.1.1.4 are also extracted and checked at this point.

FIGURE 4.48  Command window result—LDPC decoding.

FIGURE 4.49  Code block desegmentation process.

398

5G NR Modeling in MATLAB®

NUMERICAL EXAMPLE 4.21 In this example, the code block desegmentation of the following LDPC decoded segments is demonstrated. The last bit in each segment is assumed to be a received CRC bit introduced during the segmentation process at the transmitter. C10 = 11101 C20 = 10100 C30 = 10110 C 40 = 01001 The output of the code block desegmentation process is obtained by sequentially concatenating each LDPC decoded segment without their CRC bits as follows: B 0 = 1110101010110100

The nrCodeblockDesegmentLDPC function from the MATLAB’s 5G Toolbox can be used to perform code-block desegmentation. The syntax of the function is as follows: [desegmented,err] = nrCo​deblo​ckDes​egmen​tLDPC​(deco​ded,b​gn,bl​klen)​ The inputs to the function specified in the syntax are described below: decoded: Code-block segments. bgn: Base graph number. blklen: Output block length. The function returns the following outputs: desegmented: Concatenated data block. err: CRC errors in segments. A screenshot of the command window after the execution of the function is shown in Figure 4.50. The inputs to the function used in Figure 4.50 are described below: decoded- Array corresponding to the input decoded in the function’s syntax.

Physical Layer Processing with Numerical and MATLAB® Modeling

399

FIGURE 4.50  Command window result—code block desegmentation.

info.BGN- Field from the info structure array for specifying the base graph number. trBlkLen+info.L- Equals to the output block length. 4.2.5.4 CRC Decoding CRC decoding uses the CRC bits in code-words B a to check if they have been decoded without any error and outputs the DLSCH code-words denoted as out a , which should match the input to the system ina if there is no error introduced. In this process, for each code-word, the CRC bits are recalculated and compared with the ones obtained through the transmission. If the recalculated and transmitted CRC bits do not match, it implies that there is an error in the received code-word. The nrCRCDecode function from MATLAB’s 5G Toolbox can be used to perform CRC decoding. The syntax of the function is as follows: [blk,err] = nrCRCDecode(desegmented,poly) The inputs to the function specified in the syntax are described below: desegmented: CRC encoded data. poly: CRC polynomial. The function returns the following outputs: rxBits: CRC decoded data. err: CRC errors data.

400

5G NR Modeling in MATLAB®

FIGURE 4.51  Command window result—CRC decoding.

A screenshot of the command window after the execution of the function is shown in Figure 4.51. The inputs to the function used in Figure 4.51 are described below: desegmented- Array corresponding to the input desegmented in the function’s syntax. info.CRC- Field from the info structure array for specifying the CRC polynomial.

REFERENCES

1. 3GPP, “Technical Specification Group Radio Access Network; NR; Multiplexing and Channel Coding (Release 15)”, Technical Report (TR) 38.212, 2019. 2. 3GPP, “Technical Specification Group Radio Access Network; NR; Physical Layer Procedures for Data (Release 15)”, Technical Report (TR) 38.214, 2019. 3. J. Chuang, L. Cimini and N. Sollenberger “Wideband Wireless Packet Data Access”, Multimedia Communications, 221–246 (2001). 4. 3GPP, “Technical Specification Group Radio Access Network; NR; User Equipment (UE) Radio Transmission and Reception; Part 1: Range 1 Standalone (Release 15)”, Technical Report (TR) 38.101-1, 2019.

Physical Layer Processing with Numerical and MATLAB® Modeling

401

5. Intel Corporation, “RV Order for Special Cases”, 3GPP TSG RAN WG1 Meeting 90bis, R1-1717405, 2017. 6. Session Chairman (Nokia), “Chairman’s Notes of Agenda Item 7.1.5 Channel Coding and Modulation”, 3GPP TSG RAN WG1 Meeting 87, R1-1613710, 2016. 7. T. Nguyen, T. Nguyen Tan and H. Lee “Efficient QC-LDPC Encoder for 5G New Radio”, Electronics 8(6), 668 (2019). 8. B. Forouzan and S. Fegan Data Communications and Networking. 4th Edition. New York: McGraw-Hill Higher Education, 118, 2007. 9. Mathworks, “Downlink Control Channel- MATLAB & Simulink”, [Online] 2020, Available Online: https://www​.mathworks​.com ​/ help​/ lte​/ug​/downlink​-control​-channel​ .html [Accessed 16 September 2020]. 10. 3GPP, “Technical Specification Group Radio Access Network; NR; Physical Channels and Modulation Physical Channels and Modulation (Release 15)”, Technical Report (TR) 38.211, 2019. 11. 3GPP, “Technical Specification Group Radio Access Network; NR; NR and NG-RAN Overall Description; Stage 2 (Release 15)”, Technical Report (TR) 38.300, 2019. 12. D. Shah B. Rindhe and S. Narayankhedkar “Effects of Cyclic Prefix on OFDM System”, Proceedings of the International Conference and Workshop on Emerging Trends in Technology - ICWET '10, 2010. 13. 3GPP, “Technical Specification Group Radio Access Network; Study on Channel Model for Frequencies from 0.5 to 100 GHz (Release 15)”, Technical Report (TR) 38.901, 2019. 14. E. Dahlman, S. Parkvall and J. Skold 5G NR – The Next Generation Wireless Access Technology. San Diego: Elsevier Science & Technology, 2018. 15. H. Zarrinkoub Understanding LTE with MATLAB. 1st Edition. John Wiley & Sons, West Sussex, 2014. 16. W. E. Ryan An Introduction to LDPC Codes. CRC Handbook for Coding and Signal Processing for Recording Systems (B. Vasić, ed.). CRC Press, 2004. 17. A. Neubauer, J. Freudenberger and V. Kühn, Coding Theory. 1st Edition. Chichester: John Wiley, 2007, 34. 18. E. Telatar, “Capacity of Multi-antenna Gaussian Channels”, European Transactions on Telecommunications 10(6), 585–595 (1999).

5

MATLAB® Simulation Model and Performance Analysis of 5G PDSCH

5.1 SIMULATION OF 5G PROCESSING CHAIN ON MATLAB In this section, the modeling of the 5G PDSCH processing chain using Mathworks MATLAB is demonstrated. The simulation model is built using functions available on MATLAB’s 5G Toolbox (Version 1.1) [1]. Figure 5.1 shows the end-to-end PDSCH processing simulation model in which the MATLAB function for each processing block is given. The simulation model described in this section is based on the NR PDSCH Throughput example available from the 5G Toolbox. By launching the NR PDSCH Throughput example, MATLAB generates a folder with the main script NewRadio PDSCHThroughputExample.m, and additional functions necessary for the system model simulation. The folder structure is shown in Figure 5.2. In this chapter, the codes in the NewRadioPDSCHThroughputExample.m are explained and modifications are made to it to include bit error rate and block error rate calculations. A flowchart summarizing the simulation process is given in Figure 5.3. The transmission of a defined number of radio frames is simulated over a range of Signal-to-Noise Ratios (SNRs). Hence, the main script NewRadioPDSCHThrough putExample.m, begins with the definition of the number of radio frames and the Eb N 0 range [1]. The initialization of arrays to store simulated PDSCH Throughput, the number of bit errors and the number of block errors for the calculation of BER and BLER is also executed as shown in the main script below. Simulation parameters are stored in a structure array labeled as simParameters. %% Defining Simulation parameters clear all rng(200); % Set Random Number Generator state for repeatability simParameters=[];                      % Clear simParameters structure array simParameters.NFrames=1000;        % Set number of 10ms frames to simulate

402

DOI: 10.1201/9781003465393-5

MATLAB® Simulation Model and Performance Analysis

403

FIGURE 5.1  MATLAB end-to-end PDSCH simulation model. EbN0=[-5:15]; % Convert Eb/N0 to SNR TargetCodeRate=40/1024;                                % PDSCH  code rate bps=2;                                                        % bits per symbol, 1 for BPSK, 2 for QPSK EsNo=EbN0 + 10*log10(bps); snrdB=EsNo + 10*log10(R);      % SNR in dB simParameters.SNRIn=snrdB;      % Set SNR range % Initialize array to store the maximum throughput for all SNR points maxTh​rough​put=z​eros(​lengt​h(sim​Param​eters​.SNRI​n),1)​; % Initialize array to store the simulation throughput for all SNR points simTh​rough​put=z​eros(​lengt​h(sim​Param​eters​.SNRI​n),1)​; % Initialize array to store total number of errors in decoded code-words for all SNR points numer​rcomb​ined=​zeros​(leng​th(si​mPara​meter​s.SNR​In),1​); % Initialize array to store total number of erroneous blocks for all SNR points numbl​kerr=​zeros​(leng​th(si​mPara​meter​s.SNR​In),1​);

FIGURE 5.2  NR PDSCH Throughput example generated folder content.

404 5G NR Modeling in MATLAB®

MATLAB® Simulation Model and Performance Analysis

FIGURE 5.3  Simulation codes flowchart.

405

406

5G NR Modeling in MATLAB®

The waveform parameters are then defined as shown in the script below. As an example, a bandwidth of 10 MHz with SCS 30 kHz is used. The number of PRBs for this numerology is 51 as per 3GPP TS 38.101 [3]. %% Defining Waveform parameters simParameters.NRB=24;                                      % Number of resource blocks as per selected bandwidth simParameters.SubcarrierSpacing=30;    % Set subcarrier spacing (kHz) simParameters.CyclicPrefix=‘Normal’;  % Specify cyclic prefix type

Parameters such as the number of PDSCH layers, number of code-words, number of transmitting and receiving antennas, PDSCH code-rate, and modulation order are then defined [1]: %% Defining DL-SCH/PDSCH parameters simPa​ramet​ers.P​DSCH.​PRBSe​t=0:s​imPar​amete​rs.NR​B-1; % PDSCH PRB allocation simPa​ramet​ers.P​DSCH.​Symbo​lSet=​0:11;​          ​     % PDSCH symbol allocation in each slot simPa​ramet​ers.P​DSCH.​Enabl​eHARQ​=true​;          ​       % Enable/disable HARQ simParameters.PDSCH.NLayers=2;                          % Set number of PDSCH layers simParameters.NTxAnts=2;                               % Set number of PDSCH transmission antennas ModOrder= ‘QPSK’  % Set modulation order: ‘QPSK’, ‘16QAM’, ‘64QAM’ or ‘256QAM’ if simParameters.PDSCH.NLayers > 4              % Determine if multicode-word transmission is required based on NLayers     simParameters.NumCW=2;                                % Number of code-words     sim​Param​eters​.PDSC​H.Tar​getCo​deRat​e=[Ta​rgetC​odeRa​te TargetCodeRate];    % Set PDSCH code rate for each code-word     simParameters.PDSCH.Modulation={ ModOrder, ModOrder };    % Set modulation order for each code-word     sim​Param​eters​.NRxA​nts=8​;        ​      ​      ​   % Number of UE receive antennas else     simParameters.NumCW=1;                        % Number of code-words     sim​Param​eters​.PDSC​H.Tar​getCo​deRat​e=Tar​getCo​deRat​e;        % Set PDSCH code rate     sim​Param​eters​.PDSC​H.Mod​ulati​on=Mo​dOrde​r;          ​ % Set modulation order: ‘QPSK’, ‘16QAM’, ‘64QAM’, ‘256QAM’     simParameters.NRxAnts=2;                      % Number of UE receive antennas end

MATLAB® Simulation Model and Performance Analysis

407

The DM-RS parameters described in Subsection 4.1.4.1 are initialized as follows [1]: %% Defining DM-RS parameters simPa​ramet​ers.P​DSCH.​PortS​et=0:​simPa​ramet​ers.P​DSCH.​NLaye​rs-1;​                                                  % DM-RS ports to use for the layers simParameters.PDSCH.PDSCHMappingType=‘A’;    % Set DM-RS mapping type (‘A’(slot-wise),’B’(non slot-wise)) simPa​ramet​ers.P​DSCH.​DMRST​ypeAP​ositi​on=2;​      % For mapping type A only, set first DM-RS symbol position (2,3) simParameters.PDSCH.DMRSLength=1;                      % Set number of front-loaded DM-RS symbols (1(single symbol),2(double symbol)) simPa​ramet​ers.P​DSCH.​DMRSA​dditi​onalP​ositi​on=0;​ % Set additional DM-RS symbol positions (max range 0...3) simPa​ramet​ers.P​DSCH.​DMRSC​onfig​urati​onTyp​e=2;  ​ % Set DM-RS configuration type (1,2) simParameters.PDSCH.NIDNSCID=1;                              % Set DM-RS scrambling identity (0...65535) simParameters.PDSCH.NSCID=0;                                        % DM-RS Scrambling initialization (0,1)

Some resource elements cannot be allocated to PDSCH because they are reserved for CORESET and forward compatibility functions. For simplicity, in the MATLAB simulation, these reservations are not performed. Therefore, the reserved resources are set as null as shown in the script below [1]: %% Defining Reserved PRB patterns (for CORESETs, forward compatibility etc) simPa​ramet​ers.P​DSCH.​Reser​ved.S​ymbol​s=[];​      % Define no Reserved PDSCH symbols simPa​ramet​ers.P​DSCH.​Reser​ved.P​RB=[]​;            ​   % Define no Reserved PDSCH PRBs simPa​ramet​ers.P​DSCH.​Reser​ved.P​eriod​=[];  ​     % Periodicity of reserved resources set to null pdsch=simParameters.PDSCH;

The channel model is implemented using nrCDLChannel or nrTDLChannel system objects available from the 5G Toolbox. Channel parameters are stored in a structure array labeled as channel. The definition of a CDL channel requires the use of hArrayGeometry helper function which is generated in the example’s folder shown in Figure 5.2. This function is required to turn the overall number of antennas into an antenna panel array geometry. The definition of the channel model is shown in the script below [1]: %% Defining Channel Model simParameters.ChannelType=‘CDL’; % Specify channel model: ‘CDL’ or ‘TDL’

408

5G NR Modeling in MATLAB®

nTxAnts=simParameters.NTxAnts; nRxAnts=simParameters.NRxAnts; if strcmpi(simParameters.ChannelType,’CDL’)     channel=nrCDLChannel;      % Create CDL channel object     channel.DelayProfile=‘CDL-C’; % Specify CDL delay profile: ‘CDL-A’, ‘CDL-B’, ‘CDL-C’, ‘CDL-D’ or ‘CDL-E’     channel.DelaySpread=300e-9; % Set Delay Spread in seconds     % Turn the overall number of antennas into a specific antenna panel array geometry     [channel.TransmitAntennaArray.Size, channel. ReceiveAntennaArray.Size]=...         hArrayGeometry(nTxAnts,nRxAnts); elseif strcmpi(simParameters.ChannelType,’TDL’)     channel=nrTDLChannel; % Create TDL channel object     channel.DelayProfile=‘TDL-C’; % Specify TDL delay profile: ‘TDL-A’, ‘TDL-B’, ‘TDL-C’, ‘TDL-D’ or ‘TDL-E’     channel.DelaySpread=300e-9; % Set Delay Spread in seconds     channel.NumTransmitAntennas=nTxAnts;     channel.NumReceiveAntennas=nRxAnts; end

SS bursts are also included in the simulation. The block pattern, bitmap, and SSB periodicity, described in Subsection 4.1.4.2, are defined as follows [1]: %% Defining SS burst parameters simParameters.SSBurst.BlockPattern=‘Case B’;        % Specify SSB block pattern simParameters.SSBurst.SSBTransmitted=[0 1 0 1]; % Specify SSB bitmap simPa​ramet​ers.S​SBurs​t.SSB​Perio​dicit​y=20;​              % SSB periodicity in ms (5, 10, 20, 40, 80, 160)

A structure array labeled as gnb is created to contain the OFDM waveform parameters. The sampling rate for the channel model is set equal to the sampling rate of the OFDM modulator. The sampling rate of the OFDM modulator is calculated using the hOFDMInfo helper function generated in the NR PDSCH Throughput example’s folder. The MATLAB codes to be included in the simulation script to set the sampling rate are given below [1]: %% Setup of the sampling rate for the channel model gnb=simParameters; waveformInfo=hOFDMInfo(gnb); % Generate OFDM waveform information chann​el.Sa​mpleR​ate=w​avefo​rmInf​o.Sam​pling​Rate;​ % Include sampling rate information in channel system object

The maximum number of delayed samples by one channel multipath component is determined so as the channel filter can be flushed to properly receive the signal:

MATLAB® Simulation Model and Performance Analysis

409

%% Get the maximum number of delayed samples by a channel multipath component. chInfo=info(channel); maxCh​Delay​=ceil​(max(​chInf​o.Pat​hDela​ys*ch​annel​.Samp​leRat​e)) + chInfo.ChannelFilterDelay;

The positions of SSBs on the resource grid can then be reserved using the script below. SS burst parameters are stored in a structure array labeled as ssburst. SS burst information is obtained by inputting the SS burst parameters, cell ID, and SS burst sampling rates to the hSSBurstInfo helper function provided in the NR PDSCH Throughput example’s folder. The hSSBurstInfo function utilizes the hSSBurst helper function, which is also obtained from the same example’s folder, to generate SS burst signals [1]. %% Reserve PDSCH Resources Corresponding to SS burst % Create SS burst information structure ssburst=simParameters.SSBurst; % Create structure array gnb.NCellID=1;                % Set Cell identity ssburst.NCellID=gnb.NCellID; ssbur​st.Sa​mpleR​ate=w​avefo​rmInf​o.Sam​pling​Rate;​ ssbInfo=hSSBurstInfo(ssburst); % Create structure array with burst configuration details % Map the occupied subcarriers and symbols of the SS burst % (defined in the SS burst numerology) to PDSCH PRBs and symbols in the % data numerology [mapp​edPRB​,mapp​edSym​bols]​=mapN​umero​logy(​ssbIn​fo.Oc​cupie​dSubc​ arrie​rs,ss​bInfo​.Occu​piedS​ymbol​s,ssb​Info.​NRB,g​nb.NR​B,ssb​Info.​ Subca​rrier​Spaci​ng,gn​b.Sub​carri​erSpa​cing)​; % Configure the PDSCH to reserve these resources so that the PDSCH % transmission does not overlap the SS burst reservation.Symbols=mappedSymbols; reservation.PRB=mappedPRB; reser​vatio​n.Per​iod=s​sburs​t.SSB​Perio​dicit​y * (gnb. SubcarrierSpacing/15); % Period in slots pdsch.Reserved(end+1)=reservation;

The mapping of SS burst numerology to PDSCH numerology is performed using the mapNumerology local function, given and described below. This function must be included in the main script [1]. function [mapp​edPRB​,mapp​edSym​bols]​=mapN​umero​logy(​subca​rrier​ s,sym​bols,​nrbs,​nrbt,​fs,ft​) % Map the SSBurst numerology to PDSCH numerology. The outputs are: %  - mappedPRB: 0-based PRB indices for carrier resource grid (arranged in a column)

410

5G NR Modeling in MATLAB®

%  - mappedSymbols: 0-based OFDM symbol indices in a slot for carrier resource grid (arranged in a row) %    carrier resource grid is sized using gnb.NRB, gnb. CyclicPrefix, spanning 1 slot % The input parameters are: %  - subcarriers: 1-based row subscripts for SSB resource grid (arranged in a column) %  - symbols: 1-based column subscripts for SSB resource grid (arranged in an N-by-4 matrix, 4 symbols for each transmitted burst in a row, N transmitted bursts) %    SSB resource grid is sized using ssbInfo.NRB, normal CP, spanning 5 subframes %  - nrbs: source (SSB) NRB %  - nrbt: target (carrier) NRB %  - fs: source (SSB) SCS %  - ft: target (carrier) SCS     map​pedPR​B=uni​que(f​ix((s​ubcar​riers​-(nrb​s*6) - 1)*fs/(ft*12) + nrbt/2),’stable’);     symbols=symbols.’;     symbols=symbols(:).’ - 1;     if (ft < fs)               % If ft/fs < 1, reduction             m​apped​Symbo​ls=un​ique(​fix(s​ymbol​s*ft/​fs),’stable’);     else            % Else, repetition by ft/fs               mappedSymbols=reshape((0:(ft/fs-1))’ + symbols(:)’*ft/ fs,1,[]);     end end

HARQ is then initialized as shown in the script below. This includes the redundancy version sequence and the number of HARQ processes to be executed in the simulation. %% Initialisation of HARQ if pdsch.EnableHARQ           rvSeq=[0 2 3 1]; % Set up Redundancy Version (RV) sequence else           rvSeq=0; end NHARQProcesses=16; % Specify the number of HARQ processes harqSequence=1:NHARQProcesses; % Specify the sequence in which the HARQ processes are used

MATLAB’s 5G Toolbox includes the nrDLSCH system object which performs DLSCH encoding. The system object requires the properties below and inputs to perform the encoding and to output the DLSCH coded bits:

MATLAB® Simulation Model and Performance Analysis

411

Properties:

1. MultipleHARQProcesses- 2. TargetCoderate-

Flag for multiple HARQ processes. Target PDSCH code-rate.

Input:

1. mod- 2. nLayers- 3. outlen- 4. rv- 5. harqID-

Modulation scheme. Number of MIMO layers. Output code-word length. Redundancy version. HARQ process number.

The nrDLSCH system object incorporates the 5G Toolbox’s functions listed in the MATLAB program structure given in Figure 5.4. These functions perform the subprocesses involved in DLSCH encoding, described in Subsection 4.1.1. The system object is defined using the codes below before the start of the processing loop in the main script [1]: %% Creation of DLSCH Encoder system objects encodeDLSCH=nrDLSCH; % Create DLSCH encoder system object encodeDLSCH.MultipleHARQProcesses=true; % Enable multiple HARQ processes encod​eDLSC​H.Tar​getCo​deRat​e=pds​ch.Ta​rgetC​odeRa​te;

DLSCH decoding [2] is performed using the nrDLSCHDecoder system object included in the 5G Toolbox. The system object requires the properties below and inputs to output the DLSCH decoded transport blocks:

FIGURE 5.4  MATLAB program structure for nrDLSCH system object.

412

5G NR Modeling in MATLAB®

Properties:

1. MultipleHARQProcesses- Flag for multiple HARQ processes. 2. TargetCoderate- Target PDSCH code-rate. 3. TransportBlockLength- Length of decoded transport block. 1. MaximumLDPCIterationCount- Maximum of LDPC iterations. 5. LDPCDecodingAlgorithm- Selected LDPC decoding algorithm. 6. ScalingFactor- Scaling factor used in min-sum algorithm. 7. Offset- Offset for min-sum algorithm.

Inputs:

1. softbits- 2. Mod- 3. nLayer- 4. Rv- 5. harqID-

LLR softbits to be decoded. Modulation scheme. Number of MIMO layers. Redundancy version. HARQ process number.

The nrDLSCHDecode system object incorporates functions from the 5G Toolbox’s functions given in Figure 5.5 to perform DLSCH decoding. The system object is defined before the start of the processing loop in the main script as follows: %% Creation of DLSCH Decoder system objects decodeDLSCH=nrDLSCHDecoder; % Create DLSCH decoder system object decodeDLSCH.MultipleHARQProcesses=true; % Enable multiple HARQ processes decod​eDLSC​H.Tar​getCo​deRat​e=pds​ch.Ta​rgetC​odeRa​te;

FIGURE 5.5  MATLAB program structure for nrDLSCHDecode.

MATLAB® Simulation Model and Performance Analysis

413

At the start of the processing loop for each SNR, the DLSCH decoder object, simulation counters, HARQ processes’ state, and pointers pointing at the start of the PDSCH transmission are reset as shown in the script below. The script includes the use of the hNewHARQProcesses helper function, which is available from the example’s generated folder, for the creation of new HARQ processes [1]. %% Initialisation of Processing Loop for snrIdx=1:numel(simParameters.SNRIn) rng(‘default’); % Set the random number generator settings to default values reset(decodeDLSCH); % Reset object’s properties to default values SNRdB=simParameters.SNRIn(snrIdx); % Pick SNR value from range to be simulated % Initialize counters to be used in the simulation bitTput=[];          % Number of successfully received bits per transmission txedBlkNum=0;          % Number of transmitted blocks txedTrBlkSizes=[];    % Number of transmitted info bits per transmission txedAlpBlkSizes=[];    % Number of transmitted alphabets per transmission % Initialize the state of all HARQ processes harqP​roces​ses=h​NewHA​RQPro​cesse​s(NHA​RQPro​cesse​s,rvS​eq,gn​b.Num​ CW); harqProcCntr=0; % HARQ process counter % Reset the channel so that each SNR point will experience the same channel realization reset(channel); % Calculate total number of OFDM symbols in the simulation period NSymbols=gnb.NFrames * 10 * waveformInfo.SymbolsPerSubframe; % Initialize OFDM symbol pointer at the start of each PDSCH transmission gnb.NSymbol=0; % Initialize slot pointer pdsch.NSlot=0; % Initialize index to the start of the current set of SS burst samples to be transmitted ssbSampleIndex=1; % Obtain a precoding matrix (wtx) to be used in the transmission of the % first transport block

414

5G NR Modeling in MATLAB®

estCh​annel​Grid=​getIn​itial​Chann​elEst​imate​(gnb,​nTxAn​ts,ch​annel​); newWt​x=get​Preco​dingM​atrix​(pdsc​h.PRB​Set,p​dsch.​NLaye​rs,es​tChan​ nelGr​id);

A channel estimate is obtained using the getInitialChannelEstimate local function and the precoding matrix is determined using the getPrecodingMatrix local function. The two local functions are given and described below and should be included at the end of the main script [1]. function estCh​annel​Grid=​getIn​itial​Chann​elEst​imate​(gnb,​nTxAn​ ts,ch​annel​) % Obtain channel estimate before first transmission. This can be used to % obtain a precoding matrix for the first slot.     ofdmInfo=hOFDMInfo(gnb);     chInfo=info(channel);     max​ChDel​ay=ce​il(ma​x(chI​nfo.P​athDe​lays*​chann​el.Sa​mpleR​ate))​ + chInfo.ChannelFilterDelay;     % Temporary waveform (only needed for the sizes)     tmp​Wavef​orm=z​eros(​(ofdm​Info.​Sampl​esPer​Subfr​ame/o​fdmIn​fo.Sl​ otsPe​rSubf​rame)​+maxC​hDela​y,nTx​Ants)​;     % Filter through channel     [~,​pathG​ains,​sampl​eTime​s]=ch​annel​(tmpW​avefo​rm);     % Perfect timing synch     pathFilters=getPathFilters(channel);     off​set=n​rPerf​ectTi​mingE​stima​te(pa​thGai​ns,pa​thFil​ters)​;     nsl​ot=gn​b.NSy​mbol/​ofdmI​nfo.S​ymbol​sPerS​lot;     % Perfect channel estimate     est​Chann​elGri​d=nrP​erfec​tChan​nelEs​timat​e(pat​hGain​s,pat​hFilt​ ers,g​nb.NR​B,gnb​.Subc​arrie​rSpac​ing,n​slot,​offse​t,sam​pleTi​mes);​ end function wtx=g​etPre​codin​gMatr​ix(PR​BSet,​NLaye​rs,he​stGri​d) % Calculate precoding matrix given an allocation and a channel estimate     % Allocated subcarrier indices     allocSc=(1:12)’ + 12*PRBSet(:).’;     allocSc=allocSc(:);     % Average channel estimate     [~,~,R,P]=size(hestGrid);     estAllocGrid=hestGrid(allocSc,:,:,:);     Hes​t=per​mute(​mean(​resha​pe(es​tAllo​cGrid​,[],R​,P)),​[2 3 1]);     % SVD decomposition

MATLAB® Simulation Model and Performance Analysis

415

    [~,~,V]=svd(Hest);     wtx=V(:,1:NLayers).’; end

In the processing loop, the simulation of PDSCH transmission is performed one slot at a time. At the start of the processing loop, the SS burst is generated using the hSSBurst function available from the example’s generated folder. The HARQ process is updated based on the previous slot transmission. The transport block size is determined using hPDSCHTBS function, available from the generated MATLAB example’s folder. Furthermore, errors in the previous slot’s transmission are checked so that retransmission is performed if required. The MATLAB codes below are included in the script to perform these operations. The script includes the hPDSCHResources function, which returns RE indices for the PDSCH and DM-RS transmission based on the 3GPP standards. The script also includes the hUpdateHARQProcess function which updates the HARQ process if there was a block error in the previous slot transmission. Both the hPDSCHResources and hUpdateHARQProcess functions are available from the generated example’s folder [1]. %% Start of Processing Loop while gnb.NSymbol < NSymbols  % Move to next slot, gnb.NSymbol increased in steps of one slot % Generate a new SS burst when necessary if (ssbSampleIndex==1)     nSubframe=gnb.NSymbol / waveformInfo.SymbolsPerSubframe; % Calculate number of subframes     ssburst.NFrame=floor(nSubframe / 10); % Calculate number of frames     ssburst.NHalfFrame=mod(nSubframe / 5,2); % Calculate number of half-frames     [ss​bWave​form,​~,ssb​Info]​=hSSB​urst(​ssbur​st); % Create SSB waveform end % Get HARQ process index for the current PDSCH transmission from HARQ index table harqP​rocId​x=har​qSequ​ence(​mod(h​arqPr​ocCnt​r,len​gth(h​arqSe​quenc​ e))+1​); % Update current HARQ process information based on CRC results % in the previous transmission for this HARQ process harqP​roces​ses(h​arqPr​ocIdx​)=hUp​dateH​ARQPr​ocess​(harq​Proce​sses(​ harqP​rocId​x),gn​b.Num​CW); % Calculate the transport block sizes for the code-words in the slot [pdsc​hIndi​ces,d​mrsIn​dices​,dmrs​Symbo​ls,pd​schIn​dices​Info]​=hPDS​ CHRes​ource​s(gnb​,pdsc​h); % Find RE indices of PDSCH and DMRS data

416

5G NR Modeling in MATLAB®

trBlk​Sizes​=hPDS​CHTBS​(pdsc​h,pds​chInd​icesI​nfo.N​REPer​PRB);​ % HARQ: check CRC from previous transmission per code-word for cwIdx=1:gnb.NumCW   if harqProcesses(harqProcIdx).blkerr(cwIdx) % If CRC failed     if (harq​Proce​sses(​harqP​rocId​x).RV​Idx(c​wIdx)​==1) % If end of rvSeq       re​setSo​ftBuf​fer(d​ecode​DLSCH​,cwId​x-1,h​arqPr​ocIdx​-1); % Reset HARQ soft buffer     end   else % If no error       trBlk{cwIdx}=randi([0 1],trBlkSizes(cwIdx),1); %Generate new transport block       se​tTran​sport​Block​(enco​deDLS​CH,tr​Blk{c​wIdx}​,cwId​x-1,h​arqPr​ ocIdx​-1); % Load transport block on DLSCH   end end

Then DLSCH encoding is then performed using the DLSCH encoder system object as follows: %% DLSCH Encoding % Encode the DLSCH transport blocks coded​TrBlo​ck=en​codeD​LSCH(​pdsch​.Modu​latio​n,pds​ch.NL​ayers​,...                               pdsch​Indic​esInf​o.G,h​arqPr​ocess​es(ha​rqPro​cIdx)​ .RV,h​arqPr​ocIdx​-1);

PDSCH encoding can be performed using the nrPDSCH function included in the 5G Toolbox. The function is composed of three main 5G Toolbox’s functions which perform the PDSCH encoding sub-processes. These sub-processes are described in Subsections 4.1.2.1 to 4.1.2.3. The structure of the nrPDSCH function is given in Figure 5.6.

FIGURE 5.6  MATLAB program structure for PDSCH.

MATLAB® Simulation Model and Performance Analysis

417

The nrPDSCH function uses the following inputs to output the PDSCH symbols:

1. DLSCH code block. 2. Modulation order. 3. Number of PDSCH layers. 4. Cell-ID. 5. Radio Network Temporary Identifier (RNTI).

The codes added to the script to perform PDSCH encoding are given below. The RNTI, which is an identifier given to each connected UE, is set to 1. %% PDSCH Encoding pdsch.RNTI=1; % Set RNTI pdsch​Symbo​ls=nr​PDSCH​(code​dTrBl​ock,p​dsch.​Modul​ation​,pdsc​h.NLa​ yers,​gnb.N​CellI​D,pds​ch.RN​TI);

Precoding is then performed in the processing loop by multiplying the precoding matrix to the PDSCH symbols’ matrix as follows: %% Precoding wtx=newWtx; % Get wtx (precoding matrix) calculated in previous slot pdschSymbols=pdschSymbols*wtx; % Apply precoding matrix to PDSCH symbols

The mapping of PDSCH and DMRS symbols onto resource elements is then performed as per the 3GPP standard. The resource grid is first constructed as a zero matrix and then the symbols are mapped onto the grid [1]: %% Resource Grid Mapping pdsch​Grid=​zeros​(wave​formI​nfo.N​Subca​rrier​s,wav​eform​Info.​Symbo​ lsPer​Slot,​nTxAn​ts); % Create resource grid [~,pd​schAn​tIndi​ces]=​nrExt​ractR​esour​ces(p​dschI​ndice​s,pds​chGri​ d); % Find PDSCH symbol indices on all transmit antennas pdschGrid(pdschAntIndices)=pdschSymbols; % Map PDSCH symbols on resource grid on all transmit antennas % PDSCH DM-RS precoding and mapping for p=1:size(dmrsSymbols,2) [~,dm​rsAnt​Indic​es]=n​rExtr​actRe​sourc​es(dm​rsInd​ices(​:,p),​pdsch​ Grid)​; % Find DMRS symbols’ indices pdsch​Grid(​dmrsA​ntInd​ices)​=pdsc​hGrid​(dmrs​AntIn​dices​) + dmrsSymbols(:,p)*wtx(p,:); % Map DMRS symbols on resource grid end

OFDM modulation is performed on the symbols mapped on the resource grid using the hOFDMModulate function, available from the generated example’s folder, with

418

5G NR Modeling in MATLAB®

the resource grid and the gnb structure array as inputs. The OFDM modulated waveform to be transmitted over the channel is stored in the txWaveform array. %% CP-OFDM Modulation txWaveform=hOFDMModulate(gnb, pdschGrid); %Perform OFDM Modulation

SS burst waveform is then added to the modulated waveform txWaveform as follows: %% Add SS-burst waveform to transmitted waveform Nt=size(txWaveform,1); txWaveform=txWaveform + ssbWaveform(ssbSampleIndex + (0:Nt1),:); % Add SSB to transmitted waveform ssbSampleIndex=mod(ssbSampleIndex + Nt,size(ssbWaveform,1)); % Set next SSB sample index

The modulated symbols are transmitted over the channel and AWGN is added using the codes below [1]: %% Pass through Channel Model % Append zeros at the end of the transmitted waveform to % flush channel content. This is a mix of multipath % delay and implementation delay. This value may % change depending on the sampling rate, delay profile and delay % spread txWaveform=[txWaveform; zeros(maxChDelay, size(txWaveform,2))]; [rxWa​vefor​m,pat​hGain​s,sam​pleTi​mes]=​chann​el(tx​Wavef​orm);​ % For AWGN, normalize noise power to take account of sampling rate, which is % a function of the IFFT size used in OFDM modulation. The SNR % is defined per RE for each receive antenna (TS 38.101-4). SNR=10^(SNRdB/20);    % Calculate linear noise gain N0=1/​(sqrt​(2.0*​nRxAn​ts*do​uble(​wavef​ormIn​fo.Nf​ft))*​SNR);​ noise​=N0*c​omple​x(ran​dn(si​ze(rx​Wavef​orm))​,rand​n(siz​e(rxW​avefo​ rm)))​; rxWaveform=rxWaveform + noise; % Add AWGN to the received time domain waveform

The received waveform is then processed at the receiver. In the MATLAB simulation, perfect synchronization is assumed and is performed using the nrPerfectTimingEstimate function in the 5G Toolbox. The function uses the channel path gains and the path filter response to reconstruct the impulse response, which is averaged across all

MATLAB® Simulation Model and Performance Analysis

419

channel snapshots and summed across all transmit and receive antennas for timing estimation. The function outputs the timing offset, used for synchronization, and the magnitude of the channel impulse response. The following codes are added to the script to perform perfect synchronization: %% Perfect Synchronization pathFilters=getPathFilters(channel); % Get path filters for perfect channel estimation [offs​et,ma​g]=nr​Perfe​ctTim​ingEs​timat​e(pat​hGain​s,pat​hFilt​ers);​ % Perform perfect timing estimate rxWaveform=rxWaveform(1+offset:end, :); % Synchronized signal

The hOFDMDemodulate function available from the generated example’s folder is used to perform OFDM demodulation. The following codes are included in the script to perform OFDM demodulation. The output of the function is the physical resource grid for the slot of 14 OFDM symbols being received. %% CP-OFDM Demodulation rxGrid=hOFDMDemodulate(gnb, rxWaveform);

In the simulation environment, perfect channel estimation is performed using the 5G Toolbox’s nrPerfectChannelEstimate function. The channel path gains array and path filter impulse response matrix are used by the function to reconstruct the channel impulse response over which OFDM demodulation is performed. An estimation of the noise is obtained by performing OFDM demodulation on the noise added to the transmitted signal [1]. %% Channel Estimation estCh​annel​Grid=​nrPer​fectC​hanne​lEsti​mate(​pathG​ains,​pathF​ilter​ s,gnb​.NRB,​gnb.S​ubcar​rierS​pacin​g,pds​ch.NS​lot,o​ffset​,samp​leTim​ es,gn​b.Cyc​licPr​efix)​; % Get perfect noise estimate (from the noise realization) noise​Grid=​hOFDM​Demod​ulate​(gnb,​noise​(1+of​fset:​end ,:)); noiseEst=var(noiseGrid(:));

To include PDSCH decoding in the MATLAB script, the PDSCH elements are first extracted from the resource grid. Minimum-Mean Squared Error (MMSE) equalization is then performed on the extracted PDSCH elements using the 5G Toolbox’s nrEqualiseMMSE function. Finally, PDSCH decoding is performed on the equalized PDSCH elements using the nrPDSCHDecode function from the 5G Toolbox. The program structure of the nrPDSCHDecode function is given in Figure 5.7. The MATLAB codes to be added to the script to perform PDSCH decoding are given below:

420

5G NR Modeling in MATLAB®

FIGURE 5.7  Program structure of nrPDSCHDecode function. %% PDSCH Decoding % Get precoding matrix for next slot newWt​x=get​Preco​dingM​atrix​(pdsc​h.PRB​Set,p​dsch.​NLaye​rs,es​tChan​ nelGr​id); % Apply precoding to Hest % Linearize 4D matrix and reshape after multiplication K=size(estChannelGrid,1); estCh​annel​Grid=​resha​pe(es​tChan​nelGr​id,K*​wavef​ormIn​fo.Sy​mbols​ PerSl​ot*nR​xAnts​,nTxA​nts);​ estChannelGrid=estChannelGrid*wtx.’; estCh​annel​Grid=​resha​pe(es​tChan​nelGr​id,K,​wavef​ormIn​fo.Sy​mbols​ PerSl​ot,nR​xAnts​,pdsc​h.NLa​yers)​; % Extract PDSCH resource elements from the received grid [pdsc​hRx,p​dschH​est]=​nrExt​ractR​esour​ces(p​dschI​ndice​s,rxG​rid,e​ stCha​nnelG​rid);​ % Perform Equalization using estimated channel information [pdsc​hEq,c​si]=n​rEqua​lizeM​MSE(p​dschR​x,pds​chHes​t,noi​seEst​); % Decode PDSCH physical channel [dlsc​hLLRs​,rxSy​mbols​]=nrP​DSCHD​ecode​(pdsc​hEq,p​dsch.​Modul​ation​ ,gnb.​NCell​ID,pd​sch.R​NTI,n​oiseE​st);

The MATLAB codes, which should be included to perform DLSCH decoding, are given below. The soft Channel State Information (CSI) obtained from the nrEqualiseMMSE function is used to scale the LLR of all the soft-bits obtained from the PDSCH decoder. The scaled soft-bits are then fed to the DLSCH decoder system object to perform DLSCH decoding [1]. %% DLSCH Decoding % Scale LLRs by CSI csi=nrLayerDemap(csi); % CSI layer demapping for cwIdx=1:gnb.NumCW

MATLAB® Simulation Model and Performance Analysis

421

    Qm=​lengt​h(dls​chLLR​s{cwI​dx})/​lengt​h(rxS​ymbol​s{cwI​dx});​ % Calculate number of bits per symbol     csi{cwIdx}=repmat(csi{cwIdx}.’,Qm,1);  % Expand by each bit per symbol     dlschLLRs{cwIdx}=dlschLLRs{cwIdx} .* csi{cwIdx}(:);  % Scale LLRs end % Decode the DL-SCH transport channel decod​eDLSC​H.Tra​nspor​tBloc​kLeng​th=tr​BlkSi​zes; % Input transport block size information to DLSCH decoder system object [decb​its,h​arqPr​ocess​es(ha​rqPro​cIdx)​.blke​rr]=d​ecode​DLSCH​(dlsc​ hLLRs​,pdsc​h.Mod​ulati​on,pd​sch.N​Layer​s,har​qProc​esses​(harq​ProcI​ dx).R​V,har​qProc​Idx-1​);

The decoded DLSCH bits can be compared with the transmitted message bits to count the number of erroneous bits and blocks received at the receiver’s end: %% Store Values for throughput, BER and BLER calculations if(any(trBlkSizes) ~= 0)   % Store number of erroneous blocks   bitTput=[bitTput trBlk​Sizes​.*(1-​harqP​roces​ses(h​arqPr​ocIdx​). blk​err)]​;

FIGURE 5.8  PDSCH Throughput results (TBS=528).

422

5G NR Modeling in MATLAB®

FIGURE 5.9  BER results (TBS=528).   % Store total number of bits transmitted   txedTrBlkSizes=[txedTrBlkSizes trBlkSizes];   % Store total number of blocks transmitted   txedBlkNum=txedBlkNum+gnb.NumCW;   for cwIdx=1:gnb.NumCW  %Store values for all PDSCH code-words   if gnb.NumCW==1   % Store total number of erroneous bits   nume​rr=  n​umel(​find(​doubl​e(dec​bits)​~=trB​lk{1}​));   else   % Store total number of erroneous bits   numerr(cwIdx)= numel​(find​(doub​le(de​cbits​{cwId​x})~=​trBlk​{cwId​ x}));​   end   % Store total number of erroneous bits for actual SNR   nume​rrcom​bined​(snrI​dx)=n​umerr​combi​ned(s​nrIdx​)+sum​(nume​rr);   % Store total number of erroneous blocks for actual SNR   numb​lkerr​(snrI​dx)=n​umblk​err(s​nrIdx​)+sum​( harqProcesses(harqProcIdx).blkerr);   end end

MATLAB® Simulation Model and Performance Analysis

423

FIGURE 5.10  BLER results (TBS=528).

After performing the DLSCH decoding of one slot, PDSCH transmission for the next slot is initiated by incrementing the indices of the pointers to the OFDM symbol, slot number and HARQ process as follows [1]: %% Preparation for next PDSCH transmission % Update starting symbol number of next PDSCH transmission gnb.NSymbol=gnb.NSymbol + size(pdschGrid,2); % Update count of overall number of PDSCH transmissions pdsch.NSlot=pdsch.NSlot + 1; % Update HARQ process counter harqProcCntr=harqProcCntr + 1; end  % Move to next slot processing

After decoding the last slot, the stored number of erroneous bits and blocks are used E to calculate the PDSCH throughput, BER, and BLER for the current simulated b N0 as shown in the script below. The calculated throughput, BER, and BLER are dynamically displayed in the Command Window to the user after the end-to-end E simulation at each b . If a BER of 0 has been obtained, the simulation at the next N0

424

5G NR Modeling in MATLAB®

Eb , which is also expected to be 0, is omitted. Otherwise, simulation at the next N0 defined

Eb value will begin. N0

%% Throughput, BER and BLER calculation maxTh​rough​put(s​nrIdx​)=sum​(txed​TrBlk​Sizes​); % Maximum possible throughput simThroughput(snrIdx)=sum(bitTput,2);      % Simulated throughput simTh​rough​putmb​ps(sn​rIdx)​=1e-6​*simT​hroug​hput(​snrId​x)/(g​nb.NF​ rames​*10e-​3);% Simulated throughput (Mbps) BER(s​nrIdx​)=num​errco​mbine​d(snr​Idx)/​sum(t​xedTr​BlkSi​zes);​ % Calculate BER BLER(snrIdx)= numblkerr(snrIdx)/txedBlkNum; % Calculate BLER % Display the results dynamically in the command window fprintf([‘\nAt Eb/N0=‘, num2str(EbN0(snrIdx))]); fprintf([[‘\nThroughput(Mbps) for ‘, num2str(gnb.NFrames) ‘ frame(s) ‘],...                 ‘= %.4f\n’], simThroughputmbps(snrIdx)); fprintf([[‘BER for ‘, num2str(gnb.NFrames) ‘ frame(s) ‘],...             ‘= %.4e\n’], BER(snrIdx)); fprintf([[‘BLER for ‘, num2str(gnb.NFrames) ‘ frame(s) ‘],...             ‘= %.4e\n’], BLER(snrIdx)); %% Do not simulate next SNR if BER is 0 if BER(snrIdx)==0     sim​Param​eters​.SNRI​n=sim​Param​eters​.SNRI​n(1:s​nrIdx​);     EbN0=EbN0(1:snrIdx);     break; end end

Finally, the calculated PDSCH throughputs, BER, and BLER for transmission over Eb every simulated can be displayed on graphs using the following codes: N0 %% Display Results figure; plot(EbN0,simThroughputmbps,’-x’,’Linewidth’,2) xlabel(‘Eb/N0’); ylabel(‘Throughput (Mbps)’); grid on; title(sprintf(‘PDSCH Throughput (%dx%d) / NRB=%d / SCS=%dkHz’,...      ​     nTx​Ants,​nRxAn​ts,gn​b.NRB​,gnb.​Subca​rrier​Spaci​ng));​ figure;

MATLAB® Simulation Model and Performance Analysis

425

semilogy(EbN0,BER,’r-x’,’Linewidth’,2) xlabel(‘Eb/N0’); ylabel(‘BER’); grid on; title(sprintf(‘BER (%dx%d) / NRB=%d / SCS=%dkHz’,...      ​                     nTx​Ants,​nRxAn​ts,gn​b.NRB​,gnb.​Subca​rrier​Spaci​ng));​ figure; semilogy(EbN0,BLER,’c-x’,’Linewidth’,2) xlabel(‘Eb/N0’); ylabel(‘BLER’); grid on; title(sprintf(‘BLER (%dx%d) / NRB=%d / SCS=%dkHz’,...      ​                       nTx​Ants,​nRxAn​ts,gn​b.NRB​,gnb.​Subca​rrier​Spaci​ng));​

The results displayed in the Command Window after the end of the simulation described in this section are given below: At Eb/N0=-5 Throughput(Mbps) for 1000 frame(s)=0.6914 BER for 1000 frame(s)=2.2968e-01 BLER for 1000 frame(s)=3.4525e-01 At Eb/N0=-4 Throughput(Mbps) for 1000 frame(s)=0.8121 BER for 1000 frame(s)=1.4976e-01 BLER for 1000 frame(s)=2.3100e-01 At Eb/N0=-3 Throughput(Mbps) for 1000 frame(s)=0.9122 BER for 1000 frame(s)=8.4471e-02 BLER for 1000 frame(s)=1.3615e-01 At Eb/N0=-2 Throughput(Mbps) for 1000 frame(s)=0.9890 BER for 1000 frame(s)=3.7603e-02 BLER for 1000 frame(s)=6.3400e-02 At Eb/N0=-1 Throughput(Mbps) for 1000 frame(s)=1.0331 BER for 1000 frame(s)=1.2453e-02 BLER for 1000 frame(s)=2.1700e-02 At Eb/N0=0 Throughput(Mbps) for 1000 frame(s)=1.0501 BER for 1000 frame(s)=3.0246e-03 BLER for 1000 frame(s)=5.5500e-03 At Eb/N0=1 Throughput(Mbps) for 1000 frame(s)=1.0551 BER for 1000 frame(s)=4.4261e-04 BLER for 1000 frame(s)=8.5000e-04 At Eb/N0=2 Throughput(Mbps) for 1000 frame(s)=1.0560 BER for 1000 frame(s)=0.0000e+00 BLER for 1000 frame(s)=0.0000e+00

426

5G NR Modeling in MATLAB®

The simulation results consisting of the PDSCH throughput, BER, and BLER over Eb the range of tested is given in Figures 5.11 to 5.13. N0 The simulation is repeated with a 5G bandwidth of 20 MHz, an SCS of 30 kHz 616 and a PDSCH target code-rate of with 64-QAM modulation. Moreover, eight 1024 transmit antennas with two receive antennas are defined. The transport block size in this scenario is 34,816 bits. The number of transmitted frames is reduced to 100 to E reduce the simulation time and an b range of −10 to 2 is used. The result displayed N0 in the Command Window after the end of the simulation with these new parameters is given below: At Eb/N0=-10 Throughput(Mbps) for 100 frame(s)=31.3344 BER for 100 frame(s)=0.3324 BLER for 100 frame(s)=0.5500 At Eb/N0=-9 Throughput(Mbps) for 100 frame(s)=33.5278

FIGURE 5.11  PDSCH Throughput results (TBS=34816).

MATLAB® Simulation Model and Performance Analysis

FIGURE 5.12  BER results (TBS=34816). BER for 100 frame(s)=0.3005 BLER for 100 frame(s)=0.5185 At Eb/N0=-8 Throughput(Mbps) for 100 frame(s)=38.5413 BER for 100 frame(s)=0.2509 BLER for 100 frame(s)=0.4465 At Eb/N0=-7 Throughput(Mbps) for 100 frame(s)=45.6438 BER for 100 frame(s)=0.1884 BLER for 100 frame(s)=0.3445 At Eb/N0=-6 Throughput(Mbps) for 100 frame(s)=52.8855 BER for 100 frame(s)=0.1268 BLER for 100 frame(s)=0.2405 At Eb/N0=-5 Throughput(Mbps) for 100 frame(s)=61.6591 BER for 100 frame(s)=0.0597 BLER for 100 frame(s)=0.1145 At Eb/N0=-4 Throughput(Mbps) for 100 frame(s)=66.3245

427

428

5G NR Modeling in MATLAB®

FIGURE 5.13  BLER results (TBS=34816). BER for 100 frame(s)=0.0244 BLER for 100 frame(s)=0.0475 At Eb/N0=-3 Throughput(Mbps) for 100 frame(s)=68.0653 BER for 100 frame(s)=0.0116 BLER for 100 frame(s)=0.0225 At Eb/N0=-2 Throughput(Mbps) for 100 frame(s)=68.9009 BER for 100 frame(s)=0.0054 BLER for 100 frame(s)=0.0105 At Eb/N0=-1 Throughput(Mbps) for 100 frame(s)=69.3187 BER for 100 frame(s)=0.0023 BLER for 100 frame(s)=0.0045 At Eb/N0=0 Throughput(Mbps) for 100 frame(s)=69.5624 BER for 100 frame(s)=0.0005 BLER for 100 frame(s)=0.0010 At Eb/N0=1 Throughput(Mbps) for 100 frame(s)=69.5972

MATLAB® Simulation Model and Performance Analysis

429

BER for 100 frame(s)=0.0003 BLER for 100 frame(s)=0.0005 At Eb/N0=2 Throughput(Mbps) for 100 frame(s)=69.6320 BER for 100 frame(s)=0.0000 BLER for 100 frame(s)=0.0000

The simulation results consisting of the PDSCH throughput, BER, and BLER over Eb the range of tested N is given in Figures 5.11 to 5.13. 0 By increasing the number of transmitted 10 ms frames, the accuracy of the plots may be increased but this will increase the total simulation time. Furthermore, a Eb smoother plot may be obtained by performing the simulation at values closer N0 to each other.

5.2 CREATION OF 5G MODEL SIMULATOR APP ON MATLAB MATLAB App Designer is a rich development environment that can be used to create interactive apps out of MATLAB codes [4]. It provides a Design View in which the Graphical User Interface (GUI) of the app can easily be built by adding visual components (such as buttons, drop-down menus, and edit fields) using drag-and-drop operations. The App Designer automatically generates the object-oriented codes for the GUI and the behavior of those visual components can then be defined in the Code View. In this chapter, the procedures for converting the script introduced in Section 5.1 to an app are described. The first step is to create the GUI over which the app user will be expected to input parameter values. The GUI created in Design View is given in Figure 5.14 (UI Figure) along with details about the chosen visual component. The outputs of the program after execution, which consists of performance results and plots and a wait bar showing the progress of the program’s execution, are also shown in the figure. The items in each drop-down list in Figure 5.14 are listed in Table 5.1. The App Designer will automatically generate the object-oriented code in the Code View window for the GUI. For each visual component with which the user will interact, a callback function must be written so that the user’s inputs can be used in the simulation. The callback function can be generated by right-clicking the visual component and selecting “Add ValueChangedFcn Callback”. By default, the function name will be in the form (field name)-(field type)-(callback function type) without the dashes and spaces. As an example, the generated value-changed function for the “Number of Frames” numeric edit field is given in the codes below: % Value changed function: NumberofFramesEditField function NumberofFramesEditFieldValueChanged(app, event) value=app.NumberofFramesEditField.Value; end

430

5G NR Modeling in MATLAB®

FIGURE 5.14  App design view layout.

The purpose of the “Simulate” push button is to launch the simulation, using all the user-determined parameters as input. Therefore, the whole script described in Section 5.1 must be converted to a function, labeled as the NRSystemModel function, which can be called by pressing the “Simulate” button in the GUI. This is

MATLAB® Simulation Model and Performance Analysis

431

TABLE 5.1 Items in Drop-Down Lists Drop-Down List Name Prefix Type Modulation Order

Block Pattern

Channel Type

Items Normal Extended QPSK 16QAM 64QAM 256QAM Case A Case B Case C Case D Case E CDL TDL

done by adding the codes below (in bold) at the beginning and the end of the script described in Section 5.1. function [BER,BLER,simThroughputmbps]= NRSys​temMo​del(E​bN0,s​ imPar​amete​rs,Mo​d,bps​,Targ​etCod​eRate​) Wait=waitbar(0,’Executing...’,’Name’,’NR System Model’); %% Codes described in Section 5.1. waitbar(1, Wait ,’Simulation Completed’); end

The simulation parameters, which will be made available to the app user to control from the GUI, are defined as inputs to the NRSystemModel function. The inputs to the NRSystemModel function are described below: EbN0: Eb/N0 value simParameters: A structure array containing fields for defining simulation parameters ModOrder: Modulation order bps: Number of bits per symbol based on the modulation order TargetCodeRate: PDSCH target code-rate The function returns the following outputs: BER: Bit error rate BLER: Block error rate simThroughputmbps: PDSCH throughput in Mbps

432

5G NR Modeling in MATLAB®

The MATLAB waitbar function is included at the beginning of the NRSystemModel function to create a wait bar dialog box to notify the user that the simulation has begun, as shown in Figure 5.15. At the end of the NRSystemModel function, the wait bar is updated to notify the user about the end of the simulation, as shown in Figure 5.16. The generated value-changed function for the “Simulate” button must be modified as follows to allow the app to feed all the user-defined inputs in the form of MATLAB arrays and objects which may be used in the NRSystemModel function: % Button pushed function: SimulateButton function SimulateButtonPushed(app, event) %% Simulation parameters simPa​ramet​ers.N​Frame​s=app​.Numb​erofF​rames​EditF​ield.​Value​; EbN0= app.E​bN0Lo​werLi​mitEd​itFie​ld.Va​lue:a​pp.Eb​N0Upp​erLim​itEdi​ tFiel​d.Val​ue; %% Defining Waveform parameters simPa​ramet​ers.N​RB=ap​p.Num​berof​RBsEd​itFie​ld.Va​lue; Targe​tCode​Rate=​app.T​arget​Coder​ateEd​itFie​ld.Va​lue; simPa​ramet​ers.S​ubcar​rierS​pacin​g=app​.Subc​arrie​rSpac​ingEd​itFie​ ld.Va​lue; simPa​ramet​ers.C​yclic​Prefi​x=app​.Pref​ixTyp​eDrop​Down.​Value​; ModOr​der=a​pp.Mo​dulat​ionOr​derDr​opDow​n.Val​ue; %% Determine number of bits per second to convert Eb/N0 to SNR in NRSystemModel function

FIGURE 5.15  Wait bar at beginning of the simulation.

FIGURE 5.16  Wait bar after completion of the simulation.

MATLAB® Simulation Model and Performance Analysis

433

if strcmp(ModOrder,’QPSK’)==1 bps=2; % Number of bits per symbol end if strcmp(ModOrder,’16QAM’)==1 bps=4; end if strcmp(ModOrder,’64QAM’)==1 bps=6; end if strcmp(ModOrder,’256QAM’)==1 bps=8; end %% Defining DL-SCH/PDSCH parameters simPa​ramet​ers.P​DSCH.​PRBSe​t=0:s​imPar​amete​rs.NR​B-1; simParameters.PDSCH.SymbolSet=0:11; simParameters.PDSCH.EnableHARQ=true; simPa​ramet​ers.P​DSCH.​NLaye​rs=ap​p.Num​berof​Layer​sEdit​Field​.Valu​e; simPa​ramet​ers.N​TxAnt​s=app​.Numb​erofT​xAntE​ditFi​eld.V​alue;​ %% Defining DM-RS parameters simPa​ramet​ers.P​DSCH.​PortS​et=0:​simPa​ramet​ers.P​DSCH.​NLaye​rs-1;​ simPa​ramet​ers.P​DSCH.​PDSCH​Mappi​ngTyp​e=app​.PDSC​HMapp​ingTy​peEdi​ tFiel​d.Val​ue; simPa​ramet​ers.P​DSCH.​DMRST​ypeAP​ositi​on=ap​p.DMR​SType​APost​ionEd​ itFie​ld.Va​lue; simPa​ramet​ers.P​DSCH.​DMRSL​ength​=app.​DMRSL​ength​EditF​ield.​Value​; simPa​ramet​ers.P​DSCH.​DMRSA​dditi​onalP​ositi​on=ap​p.DMR​SAddi​tiona​ lPosi​tionE​ditFi​eld.V​alue;​ simPa​ramet​ers.P​DSCH.​DMRSC​onfig​urati​onTyp​e=app​.DMRS​Confi​gurat​ ionTy​peEdi​tFiel​d.Val​ue; simPa​ramet​ers.P​DSCH.​NIDNS​CID=a​pp.DM​RSScr​ambli​ngIde​ntity​EditF​ ield.​Value​; simPa​ramet​ers.P​DSCH.​NSCID​=app.​DMRSS​cramb​lingI​nitia​lizat​ionEd​ itFie​ld.Va​lue; %% Defining Channel Model simParameters.ChannelType =app.ChannelTypeDropDown.Value; %% Defining SS burst parameters simPa​ramet​ers.S​SBurs​t.Blo​ckPat​tern=​app.B​lockP​atter​nDrop​Down.​ Value​; Bitmap=app.SSBBitmapEditField.Value; simPa​ramet​ers.S​SBurs​t.SSB​Trans​mitte​d=num​2str(​Bitma​p)-’0​’; simPa​ramet​ers.S​SBurs​t.SSB​Perio​dicit​y=app​.SSBP​eriod​icity​EditF​ ield.​Value​; %% Start Simulation [BER,BLER,simThroughputmbps]= NRSys​temMo​del(a​pp.Eb​N0Low​erLim​ itEdi​tFiel​d.Val​ue:ap​p.EbN​0Uppe​rLimi​tEdit​Field​.Valu​e,sim​Param​ eters​,ModO​rder,​bps,T​arget​CodeR​ate)

434

5G NR Modeling in MATLAB®

The script discussed in Section 5.1 used in the NRSystemModel function contained the definition of the variables in the above codes. Therefore, the definition of all these variables must be removed from the NRSystemModel function to avoid overwriting the user-defined parameters. The two lines of codes below are used to write the simulation results (BER, BLER, and PDSCH Throughput) in the text area in the app labeled as “Results”: %% Write BER, BLER and Throughput Results in App’s Text Area temp=​regex​p(fil​eread​(‘Com​​mandW​​indow​​​.txt’​ ), ‘\r?\n’, ‘split’); app.ResultsTextArea.Value=temp;

For these codes to work, the Command Window must be logged in a text file named “CommandWindow​.t​xt” when the results are displayed in the Command Window. Hence, the codes in the NRSystemModel function are modified to include the MATLAB diary function as follows (in bold): %Log Command Window dfile =‘CommandWindow​.t​xt’; if exist(dfile, ‘file’) ; delete(dfile); end % Delete dfile if existing diary(dfile) diary on % Display the results dynamically in the command window fprintf([‘\nAt Eb/N0=‘, num2str(EbN0(snrIdx))]); fprintf([[‘\nThroughput(Mbps) for ‘, num2str(gnb.NFrames) ‘ frame(s) ‘],...           ‘= %.4f\n’], simThroughputmbps(snrIdx)); fprintf([[‘BER for ‘, num2str(gnb.NFrames) ‘ frame(s) ‘],...          ‘= %.4e\n’], BER(snrIdx)); fprintf([[‘BLER for ‘, num2str(gnb.NFrames) ‘ frame(s) ‘],...           ‘= %.4e\n’], BLER(snrIdx)); diary off

Finally, the App Designer project can be saved as an mlapp file. By opening the mlapp file, the user will be prompted with the GUI in which he/she will need to input the simulation parameters. Then by pressing the Simulate button, the simulation will begin, and the user will be prompted with the wait bar shown in Figure 5.15. At the end of the simulation, the wait bar will be updated as shown in Figure 5.16, the Results text area will be populated with BER, BLER, and throughput results and graphs generated in the NRSystemModel will be displayed.

REFERENCES

1. Mathworks, “Downlink Control Channel- MATLAB & Simulink”, [online] 2020, Available Online: https://www​.mathworks​.com ​/ help​/ lte​/ug​/downlink​-control​-channel​ .html [Accessed 16 September 2020].

MATLAB® Simulation Model and Performance Analysis

435

2. 3GPP, “Technical Specification Group Radio Access Network; NR; Multiplexing and Channel Coding (Release 15)”, Technical Report (TR) 38.212, 2019. 3. 3GPP, “Technical Specification Group Radio Access Network; NR; User Equipment (UE) Radio Transmission and Reception; Part 1: Range 1 Standalone (Release 15)”, Technical Report (TR) 38.101-1, 2019. 4. Mathworks, “App Designer”, [online], 2020, Available Online: https://www​.mathworks​ .com ​/products​/matlab​/app​-designer​.html [Accessed 1 July 2023].

Index Abstract Syntax Notation One (ASN.1), 34, 35, 38 Active Antenna Units (AAUs), 86–87 App Designer, 429 Application Programming Interface (API), 135–136 Baseband unit (BBU), 54, 80 Base graph (BG), 325 Base station (BS), 21 Bearer, 54–56 Belief-Propagation Algorithm (BPA), 391–392 Broadcast Channel (BCH), 263 Broadcast Control Channel (BCCH), 69, 262 Carrier aggregation (CA), 270–271 Cell, 8 Cellular, 24 Channel estimation, 377 in Demodulation Reference Signal (DMRS), 353 Closed Subscriber Group (CSG), 58 Clustered Delay Line (CDL), 367–370 Code block concatenation, 331 Code block desegmentation, 397 Code block segmentation, 320–322 Common Control Channel (CCCH), 69 Control plane (CP) in LTE protocol stack, 64, 77 in NR protocol stack, 248–289 Control Plane Services (CPS), 175 Core network (CN) in 5G NR, 98–99 in Evolved Universal Terrestrial Radio Access Network (E-UTRAN), 53 Cyclic Prefix- Orthogonal Frequency Division Multiplexing (CP-OFDM), 353 Demodulation, 375 Modulation, 353 Cyclic Redundancy Check (CRC), 317 Dedicated Control Channel (DCCH), 69 Dedicated Traffic Channel (DTCH), 69 Demodulation, 383–384 in CP-OFDM, 353 Demodulation Reference Signal (DM-RS), 353–356 De-scrambling, 386 Domain, 4–5 Downlink Shared Channel (DL-SCH), 307

Duplex in LTE, 51 in NR, 268 Enhanced Mobile Broadband (EMBB), 17 Equipment Identity Register (EIR), 124–125 Evolved Nodeb (E-NB), 52 in Evolved Universal Terrestrial Radio Access Network (E-UTRAN), 53 home E-NB, 58 Evolved Packet Core (EPC), 59–63 Evolved Packet System (EPS), 53 Evolved Universal Terrestrial Radio Access Network (E-UTRAN), 53–59 Format in tranform format, 70 Frequency CP-OFDM, 353 scheduling, 267 synchronisation signals, 357 Gateway Gateway Mobile Location Center (GMLC), 154–157 Serving Gateway (SGW), 60–61 Packet Data Network Gateway (PGW), 61 Global System for Mobile (GSM), 8, 25–27 Gn, 59 Gnodeb (Gnb), 81–82 GPRS, 9 GPRS Tunneling Protocol (GTP), 77 Gxc interface, 62 Gx interface, 62 Handover, 56, 108 High-Speed Packet Access (HSPA), 11–12 Home eNB gateway (HeNB-GW), 58–59 Home Subscriber Server (HSS), 62–63 HPLMN, 61 Hybrid Automatic Repeat Request (HARQ), 315–316 Hypertext Transfer Protocol (HTTP), 180–181 IMT-2020, 30–31 Interleaving, 328–329 Inter-Symbol Interference (ISI), 367 Inverse Fast Fourier Transform (IFFT), 365 ITU-R, 42

437

438 augmented reality (AR), 43 extended reality (XR), 43 mixed reality (MR), 43 virtual reality (VR), 43 Javascript Object Notation (JSON), 181–182 Keys, 120 Layer demapping, 380 Layer mapping, 346–348 Lifting sizes, 312 Location Management Function (LMF), 149–157 Long-Term Evolution (LTE) Enodeb, 52 Evolved Packet Core (EPC), 59–63 latency, 15 layer, 63–64 link, 53–56 location, 65 LTE-Advanced, 51 Low Density Parity Check (LDPC) LDPC encoding, 322–328 LDPC decoding, 391–392 MATLAB, 402 Medium Access Control (MAC), 69–73 Mobile networks 1st Generation (1G), 8 Advanced Mobile Phone System (AMPS), 24 Code Division Multiple Access (IS-95/ CDMA), 25 Digital AMPS (IS-54/DAMPS), 25 Enhanced Improved Mobile Telephone System (IMTS), 24 Nordic Mobile Telephone (NMT), 25 Personal Digital Cellular (PDC), 25 Radio Telefono Mobile Integrato (RTMI), 25 Total Access Communications System (TACS), 24 2nd Generation GSM, 8 Future Public Land Mobile Telecommunication Systems (FPLMTS), 25 3rd Generation Universal Mobile Telecommunications Service, 8 High-Rate Packet Data (Cdma2000 HRPD), 27 Highspeed Downlink Packet Access (HSDPA), 27 High-Speed Uplink Packet Access (HSUPA), 27 IMT-2000, 28 3GPP CDMA Direct Spread (WCDMA), 28 3GPP CDMA Multi-Carrier (Cdma2000), 26

Index 3GPP CDMA TDD, 26 4th Generation Long Term Evolution, 8 Enhanced Machine Type Communications (EMTC), 29 IMT-Advanced, 51 Multimedia Broadcast Multicast Service (MBMS), 29 Ultra-Mobile Broadband (UMB), 28 5th Generation New Radio, 8 5G-Advanced, 6 5G core functions Access And Mobility Management Function (AMF), 99–108 Application Function (AF), 137–138 Authentication Server Function (AUSF), 120–124 Binding Support Function (BSF), 161 Cell Broadcast Centre Function (CBCF), 157–158 Charging Function (CHF), 129–131 Location Management Function (LMF), 149–154 Network Data Analytics Function (NWDAF), 146–149 Network Exposure Function (NEF), 134–136 Network Repository Function (NRF), 149 Network Slice Selection Function (NSSF), 228–230 Network Slice-Specific Authentication And Authorization Function (NSSAAF), 231–232 Policy Charging And Control Function (PCF), 125–129 Policy Control Function (PCF), 146 Session Management Function (SMF), 108–113 Short Message Service Function (SMSF), 113–114 UE Radio Capability Management Function (UCMF), 114–115 Unified Data Management (UDM), 118–120 Unified Data Repository (UDR), 131–133 Unstructured Data Storage Function (UDSF), 133–134 User Place Function (UPF), 22 5G Multimedia Services And Applications, 42–47 5GMS (Media Streaming), 42 High Data Rate Low Latency (HDRLL), 38 Low Latency, Low Loss, And Scalable Throughput (L4S), 45 Multicast Broadcast Services (MBS), 42–43

439

Index 6G IMT-2030, 10 Multi-Radio Dual Connectivity (MR-DC), 292–293

Relay node, 58 Representational State Transfer (REST), 178 Resource grid, 353–359

Network energy saving, 16 Network slicing (NS), 22–23, 130 Network Slice Selection Function, 138–141 Network Slice-Specific Authentication And Authorization Function, 142–146 Next Generation Application Protocol (NGAP), 279–281 Next Generation RAN (NG-RAN), 92 Non access stratum (NAS), 64–65 Non-Public Network (NPN), 18 Non-Terrestrial Networks (NTN), 31

Scrambling, 333–335 Secondary Synchronisation Signal (SSS), 357–358 Self-Organizing Networks (SON), 35 Service Based Architecture (SBA), 175 Service-Based Interface (SBI), 177 Service framework (SF), 176 Standardization process, 34 ITU-R Report, 30 Stage 1, 34 Stage 2, 34 Stage 3, 34 Standards Development Organizations (SDO), 32 ARIB, 32 ATIS, 32 ETSI, 32 TSDSI, 32 TTA, 32 TTC, 32 Stream Control Transmission Protocol (SCTP), 277–279 Subscription In HSS, 62 In UDR, 219 Synchronisation Signal Block (SSB), 357–358

Operation, Adminstration And Maintenance (OAM), 148–149 Packet Data Convergence Protocol (PDCP), 68, 256–258, 289 Packet Data Shared Channel (PDSCH), 307 Packet Data Unit (PDU) PDU session, 111 RLC PDU, 68 Packet delay variation (PDV), 45 Packet Forwarding Control Protocol (PFCP), 281 Paging Channel (PCH), 263 Paging Control Channel (PCCH), 69 Performance Indicators, 10 Physical Broadcast Channel (PBCH), 271–272 Physical Uplink Control Channel (PUCCH), 274 POST, 180 Precoding, 351 Primary synchronisation signal (PSS), 357 Project coordination group (PCG), 36 releases (R), 37 study item (SI), 4 Technical Report (TR), 4 technical specifications (TS), 4 working item (WI), 4 Quadrature Amplitude Modulation (QAM), 339–342 Quadrature Phase Shift Keying (QPSK), 338–339 Quality of Experience (QoE), 150 Quality of Service (QoS), 54 Radio Access Networks (RANs), 80 Radio Link Control (RLC), 258–261 Radio Network Temporary Identifier (RNTI), 275 Radio resource control (RRC), 65–67 Random-Access Channel (RACH), 71 Rate matching, 328–331 Rate recovery, 387–390

Tapped Delay Line (TDL), 370–371 Terminal, 57 3rd Generation Partnership Project (3GPP), 1 Technical Specification Groups (TSG), 39 Toolbox, 307 Ultra-Reliable Low-Latency Communications (URLLC), 17 Uplink Shared Channel (UL-SCH), 71 User equipment (UE), 57–58 User plane (UP), 78–80 User Plane Services (UPS), 175 Vendor, 114 Virtualization, 83 Virtualized Network Functions (VNF), 175 WCDMA, 26–28 World Radiocommunication Conferences (WRC), 30 Write-Replace Warning, 90 X2, 295 Xn-C, 93 Xn-U, 96