Mastering 5G Network Design, Implementation, and Operations

Mastering 5G Network Design,
Implementation, and Operations
A comprehensive guide to understanding, designing,

deploying, and managing 5G networks
Shyam Varan Nath
Ananya Simlai
Oğuzhan Kara
BIRMINGHAM—MUMBAI
Mastering 5G Network Design, Implementation,
and Operations
Copyright © 2023 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted
in any form or by any means, without the prior written permission of the publisher, except in the case
of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information
presented. However, the information contained in this book is sold without warranty, either express
or implied. Neither the authors, nor Packt Publishing or its dealers and distributors, will be held liable
for any damages caused or alleged to have been caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and
products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot
guarantee the accuracy of this information.
Associate Group Product Manager: Rahul Nair

Publishing Product Manager: Rahul Nair
Senior Editor: Sayali Pingale
Technical Editor: Rajat Sharma
Copy Editor: Safis Editing
Project Manager: Neil Dmello
Proofreader: Safis Editing
Indexer: Tejal Daruwale Soni
Production Designer: Shyam Sundar Korumilli
Marketing Coordinator: Marylou De Mello
First published: June 2023
Production reference: 1260523
Published by Packt Publishing Ltd.

Livery Place
35 Livery Street
Birmingham
B3 2PB, UK.
ISBN 978-1-83898-010-8
www.packtpub.com
I wish to thank all my professional colleagues, friends, and family, who are the inspiration for my continuous
learning and development. I am thankful to Internet of Things Solutions World Congress (IOTSWC),
where I regularly interact with a wide range of industry experts, working on emerging technologies.
Finally, many thanks to my co-authors and the editorial team at Packt, who made this book possible.
Shyam Varan Nath
To Saesha, the joy of my life. To Rajeev, my loving husband and my rock. To Uma and Gautam, my
parents, my roots. Thank you all for inspiring me, believing in me, and making me who I am.
Ananya Simlai
I’m extremely grateful to my wife, Elif, who supported me throughout this journey. Also, I would like to
extend my sincere thanks to Ananya and Shyam. This is a book we have all been immensely proud to write.
Oğuzhan Kara
Contributors
About the authors

Shyam Varan Nath is a specialist leader at Deloitte with a focus on emerging technologies such
as AI, IoT, Digital Twins, and 5G. Prior to that, he worked for Oracle, General Electric, IBM, and
Halliburton. He is the primary author of three books, Building Industrial Digital Twins, Industrial
Digital Transformation, and Architecting the Industrial Internet. Shyam has worked on driving digital
transformation at several large companies. He is a Distinguished Toastmaster (DTM) and is very
active on Twitter at @ShyamVaran. He was featured in Who’s Who in IoT? in 2021 and 2022 in
the Digital Twins category. Shyam has an undergraduate degree from IIT Kanpur, India. He has an
MSc in computer science and an MBA from FAU, Boca Raton, Florida. He is part of the Program
Committee at IoTSWC and a regular speaker at large global technology events. He can be contacted
at [email protected].
Ananya Simlai is a solutions architect with a primary focus on wireless 4G/5G mobility networks,
cloud native, and NFVI. She is a trusted advisor for service providers, helping them address their
technological challenges and thereby enabling them to smoothly transition across technologies such as
4G and 5G. She has been a speaker on 5G in international forums and also interacts with CTO teams
to help design their 5G story. She has published multiple papers on 5G and holds granted patents. She
has been instrumental in designing, implementing, and successfully rolling out one of the largest 5G
mobile networks in the globe. She is currently working as an architect at Google and has previously
worked at VMware, Cisco, Altiostar Networks, and Starent Networks.
I want to thank the people who have been close to me and supported me, especially my parents and
my husband.
Oğuzhan Kara is a microelectronics engineer with 14 years of experience with mobile technologies,
including 5G NR, VoLTE, LTE-A, O-RAN, IoT (Cat-M-NB-IoT), AI, and autonomous systems. He
is an expert in technical strategy development, performance management, optimization, and feature
trials and implementation. He has worked with vendors such as Ericsson, Nokia, and Huawei. He
founded Qrispy Limited, a telecommunications and technology consultancy firm, in 2021 in London,
and has provided various services to Qualcomm, Three UK, Vodafone UK, Entel, Blue Sky Network,
and Celfinet. He previously worked for PHI Networks (Israel), AT&T (the US), and Yota (Russia).
About the reviewers
Karthik Chandrasekaran has 19+ years of experience working in the telecom industry, with 10 years
spent on IP Multimedia Subsystem (IMS), Voice over LTE (VoLTE), and most recently, 5G SA and
Voice over NR (VoNR). He has worked on multiple launches with T-Mobile USA. He has a wide
range of experience within the telecom domain, including IMS, SMS, charging, and end-to-end voice
launches in packet-switched telecom networks. He has worked across multiple companies within the
telecom domain, such as TCS, Sasken, Nokia Siemens Networks, Mavenir, and T-Mobile. With his
experience of working on the first VoNR launch in North America with T-Mobile, he has a unique
set of knowledge to help review voice aspects of packet-switched networks.
Payam Alavizadeh has worked in the mobile communication industry for more than 20 years, with 16
years specifically dedicated to RF engineering. He has performed network investigation with the latest
methods for improving network quality. He is CEO and Founder of the Semantic Communication
Ltd and works with Canadian mobile operators in British Columbia Canada as a 5G RF engineering
consultant focusing on improving mobile network quality. His research interests include QoS ,QoE,
XR, and the next generation of mobile networks. He was selected as the IEEE DAY 2019 Winnipeg,
Canada Section Ambassador at the University of Manitoba. He was evaluated by the IEEE Admission
and Advanced Committee and was promoted to the grade of IEEE Senior Member (SMIEEE) on
Nov 2020.
I’d like to thank my wife, Mana Moosavi, who always supports me when I am reviewing chapters.
Thanks to everyone on the Packt Publishing team who helped me so much. Special thanks to Rahul
Nair, Neil D’mello, and Mohd Riyan Khan, the ever-patient publishing managers, and Aryaa Joshi for
coordinating this project.
I’d like to thank the authors; working in this field would not be possible without your support.
Gallery Quotes
“5G is a gift to the world and arguably the most important communications technology ever developed.
It delivers wireless broadband speeds to every corner of the planet to bridge the digital divide, while
providing the extra capacity needed to support the digital transformation of every industry. The book
you’re holding in your hands is an indispensable guide for anyone looking to design, build, and deploy
a 5G infrastructure to bring this connectivity miracle to life.”
- Rob Tiffany,
Founder and CEO of Sustainable Logix, @RobTiffany
“This book is written by leading technology experts, providing a great view of how 5G technologies
will essentially drive the next generation of innovation spanning across all industries on accelerated
compute platforms at hypersonic scale and speed.”
- Sunil Dadlani, CIO and CISO,
Atlantic Health System
“Any network technology is only as good as its design, deployment, and management. That is even
more true in complex and high-performance technology like 5G. In this book, Shyam Varan Nath,
Ananya Simlai, and Oğuzhan Kara address these topics in a simple, easy-to-understand, and practical
way such that everybody, from novices to experts, can master 5G.”
- Prakash Sangam, founder and principal,
Tantra Analyst, @MyTechMusings
“As Voltaire said circa the 18th century, With great power comes great responsibility, and this is very
much the case as new powerful and transformative emerging technologies such as the fifth-generation
Mobile Broadband Standard for wireless networks, AKA 5G, enter our professional lives. Yet again, we
are finding ourselves faced with the heady responsibility of making business and technology decisions
that can have great impact, from individual lives through to entire organizations and society as a whole.
It is with this very challenge in mind that we become acutely aware of the critical need to source the
best possible resources with which to inform ourselves of the key issues, the inner workings of, and
the facts surrounding technologies such as 5G, its capabilities, its strengths, its weaknesses, design and
implementation considerations, and direct or indirect impacts it can bring about or enable.
viii Gallery Quotes
This book is just such a resource, one which will indeed hold you in good stead, as well as those around
you, who will no doubt be affected by decisions you may soon need to make. I highly recommend
you not only read this book but also take notes, share your learnings, and put what you glean from
it into action.”
- Dez Blanchfield CEO,
Sociaall Inc., @dez_blanchfield
“Any complex system that a machine or society utilizes should include security principles at the
beginning of the design life cycle, not as an afterthought. Such a system should then entail what I call
Security, Privacy, and Safety (SPS) aspects within; and now, let’s not forget to include best practices
from reliability and resilience aspects as well. This book will uncover many nuggets of truth for any
practitioner in this space for 5G technologies and use cases. It’s up to you to apply such principles.”
- Mark Szewczul, MSEE, CISSP, product/cybersecurity strategist,
Founder of allthingsquantum.com
Table of Contents
Prefacexvii
Part 1: Introduction to 5G
1
Introduction to 5G 3
5G concepts and drivers 3 NG-RAN architecture 7
Key drivers 3 5G RAN deployment options 9
5G (IMT-2020) performance synopsis 5 NR and NG-RAN features 11
5G standardization 6 Summary16
5G NR and NG-RAN 7
2
End-to-End Architecture Components, Concepts, Security,
and Transport 19
A typical 5G network 19 The PCF 28
High-level components 21 The NEF 29
The NRF 30
The access network 21
The UDM 32
The packet core network 22
The AUSF 32
The transport network 22
The N3IWF 32
Data center design 23
The AF 32
5G network concepts 24 The UDR 33
The AMF 25 The SMSF 34
The SMF 27 The NSSF 34
The UPF 27 The SEPP 35
x Table of Contents
The NWDAF 35 5G QoS 40

The SCP 36 Session and Service Continuity (SSC) 44
The NSSAAF 37
5G identifiers 45
5G network concepts 38 Summary48
PDU sessions 38
3
Building Blocks – Cloud Native Infrastructure 49
The evolution of telecom infrastructure49 REST in 5G 58
Cloud-native infrastructure and AMF services 59
applications51 SMF services 61
Service-based architecture 52 UDM services 63
UDR services 66
What is REST? 54
AUSF services 67
Client/server – a REST principle applicable to
PCF services 67
5G54
NEF services 69
Cacheable – a REST principle applicable to 5G 55
NRF services 70
Stateless – a REST principle applicable to 5G
NFs56 AF services 71
A layered system – a REST principle Network Slice Selection Function (NSSF)
applicable to 5G NFs 56 services71
A uniform interface – a REST principle Summary72
applicable to 5G NFs 57
4
5G Air Interface and Physical Layer Procedures – Part 1 73
General physical layer procedures 73 Waveform, numerology, and frame
The NR physical layer at a glance 74 structure80
Confinement of the spectrum with improved Waveform80
spectral efficiency 75 NR numerology 81
NR channel structure 75 Frame structure 86
The downlink reference and synchronization Resource grid 88
signals76 Duplexing scheme 90
Uplink reference and synchronization signals 77 Slot Format Indication 91
NR cell definition 78
NR cell measurement signals 79
Summary93
Table of Contents xi
5
Initial access and beam management 95 initial access procedure 101
Initial access procedure 96 SS block 101
Beam-sweeping and initial access 97 PSS and SSS 107
Other remaining system information 98 PBCH definition 108
Message 1, 2, 3, and 4 transmissions 99 Random access preamble – the PRACH 110
Beam management 100
Summary113
Physical channels and signals for the
6
Downlink physical channels and The PUCCH 125
signals115 Channel coding schemes 128
The PDCCH 116
Transport channel coding chains 128
The PDSCH 117
Data retransmissions 130
PDSCH eMBB and URLLC multiplexing 119
CSI-RS and CSI reports 120 BWPs131
The TRS 121 Defining a BWP 132
PTRS122 BWP operations 132
BWP use cases 134
Uplink physical channels and signals 123
The PUSCH 123 Summary136
7
Packet Core Procedures 137
PDU session establishment in 5G 137 IMS 5G PDU session establishment 151
PDU session establishment with 4G/ VoNR call flow 163
N26/IWF146 Wi-Fi attach 168
4G (E-UTRAN) initial attach 147 Summary173
xii Table of Contents
8
Voice over New Radio (VoNR) 175
VoNR concepts and drivers 175 High-level call procedure activities 181
IMS network deployments growth 175 SIP signaling exchange 181
5G system service requirements 176 QoS flow establishment 183
Ultra-high-definition audio 176 QoS flow tear down 184
VoNR high-level architecture 176 Interworking and voice call continuity185

5G NR access and core networks 176 Interworking with legacy voice networks 186
IP multimedia subsystem 177 Packet switched handover from 5G to 4G 186
Single radio voice call continuity 187
VoNR initial procedures 178 EPS fallback 188
Subscriber provisioning 179 Radio access technology fallback 188
IMS connectivity establishment 179 Wi-Fi calling 189
IMS registration 180
Third-party registration 180 Summary190
VoNR call procedures 181
Part 2: 5G Network Design, Deployment Models,

and Advanced Use Cases
9
5G Deployment Options 195
5G network deployment architectures195 A technical comparison of NSA versus SA 202
NSA network architecture 197 An economic comparison of NSA versus SA 202
SA network architecture 199 4G to 5G migration strategies 203
The different 5G deployment options The evolution of the EPC to 5GC 206
defined by 3GPP 200 A comparison of the EPC and 5GC 206
SA options 200
Summary208
NSA options 201
Table of Contents xiii
10
5G Non-Standalone Networks 209
Introduction to NSA networks 209 5G NSA – option 3 call flows 218
Types of NSA networks 210 Advantages and shortcomings 225
A deep dive into NSA networks 213 Summary225
The architecture of the option 3 NSA network 214
11
5G Standalone Networks 227
Benefits and use cases of a 5G SA Designing a macro network 247
network227 Designing a non-public (private) network 249
5G SA network design fundamentals 228 5G network resilience and failure
Essential precursors 229 design252
5G SA network components and end-to-end Network performance analysis 253
call flow 233
Summary256
12
5G Infrastructure Design 257
Understanding NFV 257 Managing O-RAN infrastructure 269
The role of SDN 259 Using hybrid cloud 272
Understanding MEC C-RAN 261 The emergence of the telecom cloud 273
Carrier aggregation 264 Summary275
Understanding O-RAN 265
13
5G Network Slicing 277
Understanding network slicing 277 Network slicing challenges 283
Network slicing simplified 278 Overcoming the network-slicing challenges 283
xiv Table of Contents
Security considerations for network slicing 285 Architecture and flow diagram 289
Network slicing architecture and Use cases of network slicing 292

design286 Summary296
5G network slicing at work 287
14
5G and Autonomous Vehicles 297
A background on CAVs and their ADAS309
concepts297 V2X and 5G 310
Levels of automation 301 Network slicing and V2X 311
The 5G Automotive Association (5GAA) 303 5G V2X 313
The high-level architecture of AVs 304 V2X technology 314
Architecture for cooperative and intelligent The V2X standards 314
transportation305 Platooning316
The role of cloud providers 307 Cloud computing for V2X 317
AV intercommunication 308 Summary318
15
5G Fixed Mobile Convergence 319
Introduction to FMC in 5G 319 FMC’s architecture 329
Session Initiation Protocol 321 FMC security considerations 332
Real-Time Transport Protocol 322 SIP security 332
IP Multimedia Subsystem 322 UMA security 334
Unlicensed Mobile Access 323 Fixed Mobile Convergence (FMC) security 335
The Fixed-Mobile Convergence Alliance 325
The Broadband Forum 325
Summary337
16
5G and Satellite Communications 339
Introduction to satellite Satellite communication in 5G 346
communications339 The role of regulatory bodies 346
The Global Positioning System 344 Challenges to satellite communication 350
Table of Contents xv
Why do we need satellite Use cases of 5G and satellite

communication with 5G? 351 communication360
The architecture of 5G and satellite Summary366
communications352
17
Automation, Orchestration, and Testing 367
Automation infrastructure in 5G 368 Implementation of network slicing 378
Introduction to network orchestration375 Integration planning in a
Auto scale-in and scale-out 376 multivendor environment 378
Automatic failure recovery 377 Monetization via AI and ML 380
Congestion control by configuration
Summary381
management377
Further reading 381
Appendix383
Interview on 5G with Rob Tiffany, Health System 385
founder and CEO of Sustainable Interview on 5G with Aayush
Logix383 Bhatnagar, senior vice president of
Interview on 5G with Sunil Dadlani, Reliance Jio 388
global CIO and CISO of Atlantic Interview on 5G with ChatGPT 390
Index393
Other Books You May Enjoy 410

Preface
The interconnected world demands a fast and reliable network, which can be provided by 5G technology.
The versatility of 5G networks could revolutionize multiple industries with their speed and latency
characteristics. This book will help you develop a comprehensive understanding of the 5G technology,
network design, and operation, as well as applications and use cases. This book provides your recipe for
success in harnessing 5G technology for digital transformation and driving unique business outcomes.
Who this book is for

If you are a telecom enthusiast or working in the domain and want to learn more about building a 5G
network from the bottom up or an application modernization strategy maker, then this book is for you.
It provides a consumable explanation of the technology for network engineers, network architects, and
infrastructure decision-makers, helping them excel in their day-to-day work involving 5G technology.
What this book covers

Chapter 1, Introduction to 5G, introduces key aspects and methodologies of 5G New Radio, the next-
generation radio access network, and the end-to-end system architecture of 5G with a focus on the
concepts and drivers.
Chapter 2, End-to-End Architecture Components, Concepts, Security, and Transport, introduces the
end-to-end 5G architecture. You’ll learn about new concepts introduced in 5G and then deep dive
into the various 5G network functions.
Chapter 3, Building Blocks – Cloud Native Infrastructure, introduces the concept of cloud native
infrastructure and service-based architecture in 5G.
Chapter 4, 5G Air Interface and Physical Layer Procedures – Part 1, introduces the general physical
layer procedures, waveform, numerology, and the frame structure in NR.
Chapter 5, 5G Air Interface and Physical Layer Procedures – Part 2, covers initial access and beam
management together with the physical channels and signals that are utilized.
Chapter 6, 5G Air Interface and Physical Layer Procedures – Part 3, introduces the rest of the downlink
and uplink physical channels and signals and other aspects, such as the channel coding scheme and
bandwidth parts, that are related to physical layer procedures.
Chapter 7, Packet Core Procedures, delves into the details of 5G packet core call flows.
Chapter 8, Voice over New Radio (VoNR), describes and analyzes VoNR on an end-to-end basis with
a focus on the architecture requirements, initial procedures, call establishment, and interworking
with other technologies.
xviii Preface
Chapter 9, 5G Deployment Options, delves into the details of two main architectures, Non-Standalone
(NSA) and Standalone (SA), that the mobile network operators and communication service providers
can choose when transitioning from 4G to 5G technology.
Chapter 10, 5G Non-Standalone Networks, explains in detail the design and implementation of a 5G
non-standalone network.
Chapter 11, 5G Standalone Networks, explains in detail the design and implementation of a 5G
standalone network.
Chapter 12, 5G Infrastructure Design, focuses on network function virtualization and radio access networks.
Chapter 13, 5G Network Slicing, explains the purpose and the architecture of network slicing.
Chapter 14, 5G and Autonomous Vehicles, explains how 5G technologies are used with connected and
autonomous vehicles.
Chapter 15, 5G Fixed Mobile Convergence, describes how the convergence of fixed and mobile broadband
services happens over 5G.
Chapter 16, 5G and Satellite Communications, focuses on how terrestrial networks such as 5G work
together with non-terrestrial satellite networks.
Chapter 17, Automation, Orchestration, and Testing, describes in detail the role of automation and
orchestration in 5G networks and the process of testing a network before going to production.
Download the color images

We also provide a PDF file that has color images of the screenshots and diagrams used in this book.
You can download it here: https://packt.link/t9UMs.
Conventions used
There are a number of text conventions used throughout this book.
Code in text: Indicates code words in text, database table names, folder names, filenames, file
extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: “After a
successful transaction, UDM reports the 201 created message.”
Bold: Indicates a new term, an important word, or words that you see onscreen. For instance,
words in menus or dialog boxes appear in bold. Here is an example: “Select System info from the
Administration panel.”
Tips or important notes

Appear like this.
Preface xix
Note
Some of the images in this book have been inspired from Keysight Technologies - https://
www.3g4g.co.uk/5G/ and the Ericsson 5G Air Interface course - LZU1082750 (2022)
document. Efforts have been made to create these to the best of our ability in a new and
unique appearance whilst retaining the intended meaning of these images. We are happy to
add additional acknowledgements in subsequent editions of this publication where required.”
Get in touch
Feedback from our readers is always welcome.
General feedback: If you have questions about any aspect of this book, email us at customercare@
packtpub.com and mention the book title in the subject of your message.
Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen.
If you have found a mistake in this book, we would be grateful if you would report this to us. Please
visit www.packtpub.com/support/errata and fill in the form.
Piracy: If you come across any illegal copies of our works in any form on the internet, we would
be grateful if you would provide us with the location address or website name. Please contact us at
[email protected] with a link to the material.
If you are interested in becoming an author: If there is a topic that you have expertise in and you
are interested in either writing or contributing to a book, please visit authors.packtpub.com.
Share Your Thoughts

Once you’ve read Mastering 5G Network Design, Implementation, and Operation, we’d love to hear
your thoughts! Please click here to go straight to the Amazon review page for this book and share
your feedback.
Your review is important to us and the tech community and will help us make sure we’re delivering
excellent quality content.
Download a free PDF copy of this book
Thanks for purchasing this book!
Do you like to read on the go but are unable to carry your print books everywhere? Is your eBook
purchase not compatible with the device of your choice?
Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.
Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical
books directly into your application.
The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free content
in your inbox daily
Follow these simple steps to get the benefits:
1. Scan the QR code or visit the link below
https://packt.link/free-ebook/9781838980108
2. Submit your proof of purchase

3. That’s it! We’ll send your free PDF and other benefits to your email directly
Part 1:
Introduction to 5G
This part of the book will provide an overview of 5G technologies. You will develop a solid understanding
of the fundamental building blocks that enable 5G technology. The chapters in this part will unravel the
aspects that make 5G unique and capable of addressing high-quality demands in terms of bandwidth,
latency, and quality of service, as well as the technologies that back 5G, the enhancements to the air
interface, and the packet core, which come together to light up the network that is capable of this
performance. It will cover how to design and implement 5G macro and private networks and, at the
same time, explain the various design and deployment options available.
This part of the book comprises the following chapters:
• Chapter 1, Introduction to 5G
• Chapter 2, End-to-End Architecture Components, Concepts, Security, and Transport
• Chapter 3, Building Blocks – Cloud Native Infrastructure
• Chapter 4, 5G Air Interface and Physical Layer Procedures – Part 1
• Chapter 7, Packet Core Procedures
• Chapter 8, Voice over New Radio (VoNR)
1
Introduction to 5G
5G is the fifth-generation technology standard for mobile cellular networks, which is the successor
to 4G networks. This chapter introduces key aspects and methodologies of the 5G New Radio (NR),
with a focus on the concepts and drivers. It provides some basic understanding of the 5G NR and
Next-Generation Radio Access Network (NG-RAN) and the end-to-end system architecture at a
high level. Core network-related aspects will be evaluated in the upcoming chapters.
Understanding the lessons of this chapter, mainly 5G concepts and drivers, and some key features of
5G NR is important to build the foundation for the upcoming chapters in the book.
In this chapter, we will cover the following topics:
• 5G concepts and drivers

• 5G NR and NG-RAN
5G concepts and drivers

In this section, we will analyze key drivers for the need for 5G technology, key requirements, and the
standardization of 5G.
Key drivers
Mobile technologies such as 3G, 4G, and 5G were initially governed by the International Mobile
Telecommunications (IMT) requirements of the International Telecommunication Union –
Radiocommunication (ITU-R). IMT-2000 was established by ITU-R with detailed specifications
for the first 3G deployments that took place around 2000. In early 2012, ITU-R established the
specifications of IMT Advanced for 4G wireless cellular technology. Similarly, for the 5G technology,
ITU-R defined IMT-2020.
4 Introduction to 5G
Figure 1.1 – ITU-R and the IMT technologies
IMT-2020 is the benchmarks and guidelines that the ITU-R has set down for what a 5G network should
be. Today, organizations such as the 3rd Generation Partnership Project (3GPP) are working toward
fulfilling the requirements of IMT-2020. Within IMT-2020, there are three use cases that are the main
focus of 5G. Those use cases include Enhanced Mobile Broadband (eMBB), Ultra-Reliable and Low
Latency Communications (URLLC), and Massive Machine-Type Communications (mMTC). We
will consider each of these in turn.
Enhanced mobile broadband
From 2G all the way through to 4G we have seen constant increases in the mobile broadband data
rates that subscribers can expect to achieve. 5G is no exception with its promise of eMBB. To be able
to market 5G, some high data rates need to be provided to subscribers to show how competitive
it is against 4G. The headline data rates are roughly in the high hundreds of megabits per second.
Certainly, 5G will deliver data rates that satisfy applications such as Augmented Reality (AR), ultra
HD videos, or 3D applications.
Figure 1.2 – Evolution to ultra broadband
But certainly, with 5G, subscribers will typically experience data rates in the high hundreds of megabits
per second.
Ultra-reliable and low-latency communications
The second key use case is URLLC. When we consider URLLC, we need to consider the fact that 5G
will really be an enabler network. So, we see a variety of different applications here that might be able
to use the 5G Core (5GC) Network. Remote surgery, autonomous driving, industrial control, and
drone control are examples of applications that require low latency and high reliability.
5G concepts and drivers 5
Figure 1.3 – URLLC
URLLC has stringent requirements in terms of latency and reliability. The latency for the network
is set at around 1 ms. The network for certain applications needs to be super reliable as well, with
99.999% (five 9s) reliability.
Massive machine-type communications
The third key use case is mMTC and fundamentally, it is the cellular-Internet of Things (IoT).
Although we already had a cellular-IoT with earlier technologies, we see it again with 5G as well.
There are numerous different IoT applications that can use the services of the 5G infrastructure. The
network must be super flexible and super adaptable from the 5G service providers’ perspective. The
network needs to be able to provide exactly the correct requirements for the IoT applications that are
using it. Network function virtualization, network slicing, and edge computing came into prominence
as the three key aspects of 5G. These three aspects will be examined later in the upcoming chapters.
5G (IMT-2020) performance synopsis

The following table lists the enhancements of the minimum technical requirements of IMT Advanced
to IMT-2020:
Requirement Unit IMT Advanced IMT-2020

Peak data rate Gbits/s 1 20
User-experienced data rate Mbits/s 10 100
Spectrum efficiency bits/s/Hz 1x 3x
Mobility km/h 350 500
Latency ms 10 1
Connection density devices/km2 105 106
Network energy efficiency bit/Joule 1x 100x
Area traffic capacity Mbit/s/m2 0.1 10
The following list expands on the preceding performance synopsis and key areas that service providers
today are moving toward:
• Peak data rate (Gbits/s): This is the peak throughput target that can be achieved by a single
user in the ideal radio conditions, and it is measured in Gigabits per second.
• User-experienced data rate (Mbits/s): Shows the user-experienced throughput target, which
needs to be achieved by 95% of the users in dense urban areas. This is the speed the user will
experience in the field.
• Spectrum efficiency (bits/s/Hz): This is the number of bits per second per Hertz achieved
by 95% of users in the coverage area. It indicates how efficiently the subscribers can use the
valuable radio spectrum.
• Mobility (km/h): Shows how fast the subscribers can move while maintaining a specific
normalized traffic channel data rate.
• Latency (ms): Represents the one-way delay between the time from when the source sends an
application packet to when the destination receives it.
• Connection density (devices/km2): Shows how many devices can be supported per kilometer
squared. This is something closely related to the cellular-IoT.
• Network energy efficiency (bit/joule): Indicates how much energy is used in the network to
send a bit each time.
• Area traffic capacity (Mbit/s/m2): How many megabits of information can be sent per meter
squared per second.
5G standardization
Like many of the preceding technologies, 2G, 3G, and 4G, it is 3GPP that really defines the standards.
3GPP has defined the specifications for 5G, which are there to address the IMT-2020 requirements.
Some of the techniques that were introduced in Release 14 were carried on to Release 15 to be used
as 5G techniques.
5G was first standardized in Release 15. The first drop of Release 15 back in December 2017 provided
a standard for service providers for Non-Standalone (NSA) operation within the network. However,
Release 15 did not completely standardize every aspect of 5G. Release 16 and Release 17 includes
further enhancements to 5G to provide full capability and address IMT-2020’s requirements.
5G NR and NG-RAN 7
In terms of a timeline, back in 2017 and 2018, the earlier proprietary 5G systems started to appear;
however, standardization was not complete at the time, so some NSA 5G networks started to emerge.
The period of 2019-2020 was really the time in which the first Phase-1 deployments of standardized
5G based on 3GPP Release 15 commenced. However, most of the networks that were deployed in 2019
centered around NSA operation, which is composed of 5G RAN with Evolved Packet Core (EPC).
Phase-1 deployments are only centered on eMBB services. It is Phase 2 where we see those additional
two pillars of 5G, namely URLLC and mMTC.
Phase-2 deployments are based on a combination of Release 15 and Release 16 features. We see full
SA operations take place with the various features relating to URLLC and mMTC as well as eMBB.
In this section, we looked at the key drivers, performance synopsis, and standardization of 5G, which
will help us understand the forces driving the technology we will be studying in this book.
We will now look at 5G NR and NG-RAN.
5G NR and NG-RAN
Figure 1.4 shows the end-to-end architecture for the 5G system.
Figure 1.4 – 5G system high-level architecture
5G systems largely comprise the 5G NR, NG-RAN, and, finally, 5GC.
NG-RAN architecture
Figure 1.5 shows key elements within the architecture of the NG-RAN. The User Equipment (UE)
can be in the form of a mobile device, but it could also be in all manner of different forms, as can be
appreciated with the advent of IoT. In order to provide RAN coverage, there are gNBs, which stands
for New Radio Node B. A radio interface is needed to create connectivity between the UE and the
gNB. That radio interface is called 5G Uu. Notice also that there is connectivity between the gNBs.
So, the Xn reference points allow these gNBs to communicate with each other. Finally, connectivity
between gNBs and the core network is needed, which is also achieved by the N reference points. In
the diagram, the N2 reference point is providing the control plane flow, whereas the N3 reference
point is used for the user plane, which carries user traffic and user data.
Figure 1.5 – NG-RAN architecture
The gNB is responsible for radio resource management and a big part of that is scheduling uplink
and downlink data onto the radio interface. The gNB handles numerous different devices and its cell
or even cells. A single gNB may be in control of several different cells. It is responsible for scheduling
user data correctly onto the downlink or telling the UE when to transmit data on the uplink. The
gNBs are also responsible for handovers. The Xn reference point that sits between the gNBs allows
them to coordinate handovers between themselves. Security is a key factor as well, so the gNB will be
involved in the security across the radio link as well as the UE. Finally, the gNBs are responsible for
dual connectivity, which will be examined later in this chapter.
The UE is responsible for bidirectional data transfer via the 5G NR, ensuring a high quality of service.
So, the UE needs to be sure that the correct traffic is sent to the correct bearer. By being the other end
of the radio connection, the device is also responsible for security. Finally, the UE needs to support
dual connectivity if it is being used in the network architecture.
Tracking areas
Looking at the NG-RAN at a higher level, we can see that there are thousands of gNBs deployed to
provide that RAN coverage. In any mobile communication system, the UE is not constantly connected
to the network. The device will routinely be set to an IDLE state in order to preserve the battery
life. In the IDLE state, the UE will be conducting operations such as cell reselection. But it will also
periodically be listening to see whether it is being paged. Any data coming into the 5GC to be sent to
the UE requires paging. The network needs to know where that device is.
5G NR and NG-RAN 9
However, the problem is that the cell reselection that takes place in an IDLE state is done autonomously
and the device does not keep the network updated as to which specific cell it’s in. If we need to page
that UE, what we don’t want to have to do is page every single gNB in the NG-RAN. So, consequently,
the NG-RAN is broken down into tracking areas. What’s crucial in the system is that the UE might
be autonomously making cell reselection when it is in the IDLE mode. The UE will keep the network
updated as to which tracking area it is currently in. A tracking area is simply an administrative collection
of gNBs and their associated radio coverage, as depicted in the figure.
The 5G Core Access and Mobility Management Function (AMF) in the 5GC keeps track of the
tracking area that the subscriber is currently in. So, the subscriber’s UE will be required to update the
network any time it moves into a new tracking area. The User Plane Function (UPF) in the 5GC is
responsible for the user plane data. If user data comes into the UPF, it will inform the AMF and the
AMF will page a specific tracking area instead of paging every gNB in the network, since it already
knows which tracking area the UE is in.
Figure 1.6 – Tracking areas
The tracking areas effectively make paging much more efficient. As soon as the UE connects to the
network, the AMF will know its cell ID. But when it is IDLE, it just knows the location of the UE to the
granularity of the tracking area. Tracking area planning is all about making the paging more efficient.
5G RAN deployment options

Service providers will be in a transition phase as they move from 4G toward 5G networks. They can’t
just switch on the 5G network suddenly. There are some strategy options for service providers in
terms of migration. Now notice that in the diagram, there are 4G EPC and 5GCs. The first question
is, will the service provider be deploying the 5GC or 5G Radio Access Network first or will they both
be deployed in parallel? Either way, there are various connectivity and deployment options available
for the service providers to choose from. It is not necessarily the case of one or the other being used;
it could be a mixture.
With the NSA approach, there is a 5G gNB, which supports dual connectivity to a 4G eNB, which
stands for Evolved Node B. So, the UE will be in communication with both RAN nodes together. It
will have 4G radio connectivity to the eNB and 5G radio connectivity to the gNB. With the help of
5G radio connectivity, service providers can provide 5G services to their customers. In this approach,
notice that the control connectivity goes back into the 4G EPC since the eNB is the primary RAN
device in this architecture. So, this approach provides the benefits of 5G gNB with 5G RAN coverage.
Alternatively, 5GC can also be utilized. In this approach, there is a gNB again and that gNB is in
communication with a Next-Generation eNB (ng-eNB). The main difference is that the ng-eNB
connects to the 5GC. But it’s a similar scenario whereby dual connectivity is used with the gNB as a
secondary device and the ng-eNB as a primary device or master device and that control comes from
the 5GC down to the ng-eNB. Both these options are NSA. It depends on the service provider as to
which approach they want to go for.
The second option is SA, which is a pure 5G deployment. The UE is using the gNB and that gNB is
connecting directly to the 5GC.
Figure 1.7 – 5G Radio Access Network deployment options
Certainly, the NSA option is more straightforward to implement with a smaller investment. However,
in the long term, network architectures and thus network deployments will be based on SA.
5G NR and NG-RAN 11
NR and NG-RAN features

To meet the requirements of IMT-2020, such as coverage, capacity, and data rates, there are some
techniques and technologies that are employed. Let’s look at these in detail.
Dual connectivity
In a typical network deployment, there are UEs in communication with RAN nodes and RAN nodes
are connected to the core network through the control plane and user plane. In the context of dual
connectivity, the RAN node is the master RAN node. The master RAN node effectively controls any
dual connectivity activity that takes place, which includes adding a secondary RAN node. This is
where the dual connectivity terminology comes from.
With this approach, a secondary RAN node works in parallel with the master RAN node to improve
the effective data rate that the UE can achieve. To accomplish this, there must be a control and user
plane connection between the secondary and master nodes. Certainly, the data rate for the subscriber
device can be significantly increased by taking this approach.
The terminology used between the master RAN node and the secondary RAN node varies depending
on the network architecture and mobile technology. In 5G, for instance, the master and secondary RAN
nodes could both be gNBs. Alternatively, the master could be an ng-eNB and the secondary could be
a gNB. So, there are several different options available. From the service provider’s perspective, it is
up to them how to deploy their dual connectivity solution.
Figure 1.8 – Dual connectivity
Certainly, there are different approaches where a mixture of technologies is used between the master
and secondary RAN nodes, as can be found in 5G NSA deployments. Fundamentally, by using these
two nodes together, better coverage and improved data rates can be provided for the subscribers. Note
that the UE has also got to support dual connectivity. This is particularly important if, for example,
the master RAN node is an eNB and the secondary RAN node is a gNB, in which the device is then
supporting 4G and 5G radios simultaneously.
Small cells
Small cells are nothing new; they are not a new technology. Small cells have already been in use with
previous technologies for several years. In this section, small cells will be examined in the context of
dual connectivity in 5G.
5G is set to really benefit from the deployment of small cells. In the following scenario, small cells are
providing augmented indoor coverage where in-building penetration of the macro cell, especially in
a high-frequency range, might be quite difficult. Consequently, these small cells are deployed within
a building to improve indoor coverage and capacity in some cases. However, for 5G, indoor coverage
is an important aspect of small cells and indeed outdoor small cells will be routinely deployed.
There are macro-level RAN nodes and small cells with the outdoor small cell deployment approach.
These macro-level RAN nodes act as the master RAN nodes, whereas the small cells act as the secondary
RAN node within the dual connectivity deployment.
As the UE moves through the network, the blue line shows us the coverage that is experienced from
the macro-level RAN nodes. The small cells provide data rate boosts to the UE as it moves through
them. Therefore, in a dense urban environment, these small cells, which may only have a range of
hundreds of meters, can provide that augmented data rate boost to the network while increasing the
overall capacity.
Figure 1.9 – Macro coverage with small cells
These small cells can be set on the top of street poles, street furniture, lampposts, and so on. Small cells
are a strong deployment option for service providers to really achieve the data rates expected for 5G.
5G NR and NG-RAN 13
Increased spectrum
In meeting the target of 100 megabits per second as a mean data rate, or potentially 20 Gbps as a
peak data rate, it is essential for the service providers to have access to a more licensed spectrum.
Consequently, the licensed spectrum bands that are being considered for 5G operation have been
greatly increased.
For 5G deployments, there are several bands in use. They are below 1 GHz, 1-6 GHz, and 6-100 GHz
bands. The below 1 GHz and 1-6 GHz bands are not new, and they are used by service providers quite
routinely. 6-100 GHz is really the new band. So, let’s explain why this new band is needed.
Below 1 GHz is excellent for building penetration with wide area coverage. The coverage is potentially
about tens of kilometers depending on the topography. But the problem with operating below 1 GHz is
that there is not that much spectrum available for service providers, that is, there is limited spectrum
availability. So, what we need to do is start looking higher up in the radio spectrum.
1-6 GHz provides decent coverage, and there is also good spectrum availability. 6-100 GHz is low
range and only provides hundreds of meters of coverage, but there is greater amount of spectrum
available. However, it is the key enabler for unlocking the stringent data rate requirements. Service
providers will be operating in much bigger bands higher up in the licensed Radio Frequency (RF)
spectrum, which is essential for providing those data rates.
As it has been with technologies that have come before and at the same time as 5G, ITU is responsible
for standardization and global harmonization of the RF spectrum. At the World Radio Conference in
November 2015, they already started to discuss and define some of the operating bands for 5G, and
at the World Radio Conference in October 2019, those bands were set in place.
Radio enhancements
5G NR means that the UE needs to be able to support 5G radio, and so too does the gNB. There are
many different tweaks that have been employed in NR protocols. However, only two high-level aspects
are going to be examined here.
Fundamentally, one of the big changes is the employment of Cyclic Prefix Orthogonal Frequency
Division Multiplexing (CP-OFDM) to provide greater deployment flexibility, which adopts variable
subcarrier spacing. This helps service providers obtain much more flexibility in terms of what kind
of RAN coverage they want to provide. Therefore, CP-OFDM allows them to address whether to
deploy a small cell or a very large macro cell while allowing them to be very flexible in terms of the
frequency range that they can operate on. Moreover, variable subcarrier spacing allows addressing
specific latency requirements.
To address the requirements of the different IMT-2020 use cases, there will be a mixture of different
cell types. Some cells might require low latency and high frequency, whereas others might be long-
range cells. Therefore, to accommodate those different IMT-2020 requirements, such as latency and
coverage, CP-OFDM has been introduced.
Figure 1.10 – Radio enhancements
The other key area that has been introduced with 5G NR is the use of 256 Quadrature Amplitude
Modulation (256QAM), which is already in use with LTE Advanced technology. This is simply a
radio modulation technique and effectively allows squeezing even more data onto the radio carrier,
hence increasing those data rates as appropriate. However, to utilize 256QAM the UE needs to be in
a very good radio coverage environment.
Beam forming
On the left-hand side of Figure 1.11, traditional antenna coverage is represented. Traditionally, the
antennas might be sectored so they cover quite a large area. Within that coverage area, there might be
fixed wireless access subscribers within the houses, mobile phones, or even fast-moving subscribers.
But the idea of traditional antennas is to cover a wide area.
In 5G, Massive MIMO is set to be used. A Massive MIMO antenna is a totally new antenna design
that comprises a huge number of radio frequency elements, in effect radio frequency antennas.
One of the key advantages of Massive MIMO antennas is being able to form beams of radio frequency
energy. This Massive MIMO array can provide much finer grain coverage. If there is a UE within that
beam of coverage, the UE will get better general RAN coverage, which means the technologies such
as 256QAM can be used to achieve the optimum data rate.
Figure 1.11 – Beam forming with Massive MIMO

5G NR and NG-RAN 15
It is not only about creating that narrower beam of radio frequency energy; Massive MIMO antennas
should be able to do that for numerous subscribers within the cell. So, the beam will constantly be
flicking around to service different subscribers, which is called beam steering.
Beam steering
Beam steering is the concept of beams following a UE in the network. If the UE does not move too
quickly, it can constantly provide feedback to the antenna so that the antenna can adjust the direction
of the beam that it is sending. It is great for slow-moving UEs, while it is more challenging for fast-
moving UEs for the beam to keep track of them. Basically, it depends on the speed of the UE whether
the beam steering is used or not.
Figure 1.12 – Beam steering with Massive MIMO
Beam forming and beam steering are considered to be critical areas associated with 5G RAN deployments.
Cloud RAN
The final point related to 5G NR and NG-RAN techniques and technologies is the notion of cloud
RAN. Essentially, cloud RAN sees the introduction of virtualization technologies to the radio access
network. With cloud RAN, each individual gNB has separate compute and processing resources. The
idea behind cloud RAN is to take that compute and storage capability and move it to a Centralized
Unit (CU). This CU is responsible for conducting the processing and computing activities of all these
gNBs. So, the idea here is the compute capabilities are centrally located in a data center and all that
remains is down at the cell site are distributed units.
The distributed units are the transmit and receive elements of the gNB. This helps RAN deployment
to be simplified and potentially cheaper. The central controlling element fundamentally is sending
to the distributed units what they need to transmit. The distributed units are simply responsible for
transmitting, receiving, and exchanging that traffic with the CU.
Figure 1.13 – Cloud RAN high-level architecture
The optical transmission links that connect the CU to the distributed unit in this approach are very
critical. Fundamentally, these links must meet very low-latency requirements and they can be over a
kilometer long. But in summary, here, the CU is simply using virtualization technologies to control
several distributed units.
In this section, we analyzed the concepts of NG-RAN architecture, 5G RAN deployment options, and
NR and NG-RAN features, which create the basis for the upcoming chapters, where we will examine
them in detail.
Summary
5G standardization is being driven to meet the requirements of IMT-2020. We mentioned the three
pillars several times: eMBB, URLLC, and mMTC. The theoretical maximum data rate for 5G is 20
Gigabits per second, although the mean data rate for the subscriber is in the low hundreds of megabits
per second. RAN latency requirements are around sub-1 ms.
3GPP standardization for 5G started with Release 15 and moved on to Release 16. In Release 17, we
also see enhancements taking place.
Commercial deployments already started taking place in 2019 and onward into 2020 and 2021.
Summary 17
We also analyzed the main components of the 5G system, including the 5G NR and NG-RAN. In
terms of the NG-RAN, there are two main elements: the user equipment and the gNB.
We saw that tracking areas are designed to make paging more efficient by creating subgroups of gNBs
across the Radio Access Network.
We discussed the different RAN deployment options available to service providers. At a high level,
they are called NSA and SA deployments.
We also analyzed the NR and NG-RAN features, which gives us important knowledge for upcoming
chapters. First, we talked about dual connectivity. It can be used to significantly increase a subscriber’s
experienced data rate. It is a key technology enabler for 5G. Small cells are closely related to dual
connectivity. We talked about how they can be deployed indoors or outdoors. With respect to licensed
spectrum, we said it is essential to unlock an additional licensed spectrum for the service provider so
that they can operate the network at those high data rates.
We also talked about the new air interface technologies. We talked specifically about CP-OFDM and
the use of 256QAM. Beam forming antennas associated with the use of Massive MIMO will be critical
and with that, we also get beam steering. Then, finally, we discussed Cloud RAN. We talked about how
it can provide efficiency and potential cost savings to the service provider if they choose to deploy it.
In the next chapter, we will go over the end-to-end network architecture of 5G. We will learn about
some concepts and the high-level components of access networks, packet core networks, and transport
networks. We will also understand how the quality of service is managed in 5G networks.
2
End-to-End Architecture
Components, Concepts,
Security, and Transport
In this chapter, we will learn about the various components that make up a 5G network. We will go
into detail about the role of each of these components. We will introduce some terms newly introduced
in 5G and understand how they all fit in. The topics discussed here will create a foundation for
understanding a 5G network and its various Network Functions (NFs). This chapter will provide
the knowledge base upon which we will build in upcoming chapters to be able to design and operate
a commercial 5G network.
We will go over the end-to-end architecture of 5G. We will learn about what it takes to build a 5G
network from scratch. We will learn about the various components that make up the network. We will
also understand some concepts that are fundamental for understanding and building 5G networks.
We will touch upon the transport and security aspects of 5G and also provide a decision chart that
will help you with a jumpstart to build your own 5G network.
In this chapter, we’ll work through the following topics:
• A typical 5G network
• High-level components
• 5G network concepts
• 5G identifiers
A typical 5G network
A typical 5G network comprises three broad components that it uses to connect to the internet or
to applications. Firstly, we have the radio component, also known as the access network. Then, we
20 End-to-End Architecture Components, Concepts, Security, and Transport
have the packet core network, which comprises various 5G NFs that we will discuss shortly. Thirdly,
we see the transport network, which serves as the backbone of the 5G infrastructure and carries the
user and control traffic between the access network and the packet core network, finally reaching the
Application Functions (AFs) such as content servers or, simply put, the internet.
In Figure 2.1, we can see the 5G infrastructure components:
Figure 2.1 – 5G network overview
Let’s understand some of these components:
• ACCESS NETWORK: The access network comprises the radio components, basically the
G-NodeB (gNB), also known as New Radio (NR). The access network is responsible for
transmitting radio waves, which are received by the User Equipment (UE). This UE could
include a mobile handset in a conventional use case, a vehicle in V2X communications, or
sensors and so on in advanced IoT use cases. The access network is hence the radio network
and is restricted to communication over the air.
• PACKET CORE NETWORK: The packet core network comprises control and User Plane
Functions (UPFs) that are responsible for the management of the subscriber session, charging,
data processing, the Quality of Service (QoS), and so on. We will go over each component shortly.
• TRANSPORT NETWORK: The transport network is the backbone that connects the access
network with the packet core network and the internet. Here, the word internet is loosely
High-level components 21
used – it can be any AF or content server, such as Netflix, a server with custom content, or an
IoT platform. The most important facets of the transport network are that it should be able to
meet the latency and bandwidth requirements and also should be secure and not subject to
attack by rogue elements.
Now that we’ve understood the basic 5G network, let’s move on to looking at the high-level components.
High-level components
Multiple components come together to bring up a 5G network. In this section, we will learn about
the high-level components that are a must in creating and operating a 5G network. 5G provides a
lot of flexibility in the design of the network – we will also discuss the options as we go over each
high-level component.
The access network

The access network comprises mobile base stations (gNB), which may be split up further functionally
and physically into the following components – a Centralized Unit (CU), a Distributed Unit (DU),
and a Radio Unit (RU). When there is a functional and physical split of various components of a
base station, it is called a distributed architecture, simply because a single function of a gNB is now
distributed among other smaller components.
This split is very useful to support lower-latency use cases and helps serve mobile edge computing
use cases. Let us go over the components one by one:
• In the CU, the radio stack is decomposed to comprise Service Delivery Adaptation Protocol
(SDAP) for NR, Packet Data Convergence Protocol (PDCP), which uses packet processing
components, including ciphering and header compression, and Radio Resource Control
(RRC), which is responsible for controlling radio channels.
These components are not time-critical and hence they are good candidates for virtualization.
The CU is generally deployed in remote near-edge data centers and is usually co-located with
UPFs for low-latency applications. The mid-haul transport network connects the CU to the DU.
• The DU comprises the Radio Link Control (RLC), Medium Access Control (MAC), and
Physical (PHY) layers, along with the brain of the radio base station, the scheduler. The DU is
a logical node hosting the RLC, MAC, and PHY layers of the gNB, and its operation is partly
controlled by the CU. The components in the DU are responsible for rate adaptation, channel
coding, modulation, and scheduling radio resources among the UEs in its coverage. One DU
supports one or multiple cells. One cell is supported by one DU. The DU is connected to the CU
by an F1 interface. This is highly time-sensitive and must operate within the guardrails of the
latency requirements, which are in the order of milliseconds. The DU can be located in near-
edge data centers or can be collocated with the Remote Units (RUs) for far-edge sites.
• The RU is the entity that is deployed at the cell sites, also known as Remote Radio Head (RRH).
It connects to the DU through a CPRI or an eCPRI interface.
To summarize, the access network comprises the entities that control over-the-air communication between
the UE and the 5G network. We will get into the details of this communication in upcoming chapters.
The packet core network

The packet core network in 5G comprises multiple independent NFs that have different roles and
responsibilities. They are built on cloud-native development principles and operate following a
producer-consumer model. Each of these NFs provides a set of services to different NFs and similarly,
they consume services from other NFs. Some of the most popular and essential NFs are the Access
Management Function (AMF), Session Management Function (SMF), UPF, Charging Function
(CHF), Unified Data Manager (UDM), Policy Control Function (PCF), and so on. These NFs
provide mobility management, session management and control, user plane and data processing,
charging, subscription management, traffic policing, and QoS control and enforcement functions.
We will discuss each of them in the upcoming sections.
The transport network

The transport network ties each of these network segments together and provides connectivity
between them. The transport network can be in various forms, starting from the front-haul – which
is generally CPRI- or eCPRI-based and connects the RUs and the DU. Next is the mid-haul, which
connects the DU and the CU. This is followed by the back-haul network, which connects the CU to
the packet core network.
It should be noted that it is of utmost importance that the transport network is fast: it should have
low latency and be reliable. This ensures that it is failure-resistant and highly available. It should have
the necessary bandwidth to support high data volumes, and it should also be secure and not prone
to rogue attacks.
As you may have already guessed, the transport network will contain a web of networking gear,
such as switches, routers, leased lines, microwaves, optical fibers, and so on. Hence, based on the
requirements, the desired design is selected. The optical front-haul picks up gradually as it provides
reliable connectivity and increased bandwidth. Microwaves can be used for relatively long-distance
connectivity. Especially in rural and remote areas, solutions involve microwave long-hauls. Since
they are cost-effective and easy to deploy, they are a contender as the preferred choice over substitute
optical fibers in some cases.
In the preceding diagram, you may have noticed that a WAN is used to connect the back-haul network.
This is because when a 5G solution is deployed in an entire country spanning thousands of square
miles, it is imperative for the service provider network to leverage optical fiber leased lines to transport
the user traffic from the operator’s 5G network to the internet or content servers. Hence, leased lines
or a WAN are used to transport this data.
High-level components 23
Data center design

In the following diagram, we will go over a sample service provider 5G network template. Here, we can
discuss the basic principles of network architecture and design, and we will go over the assumptions
made and the options available that can be leveraged according to the use case at hand:
Figure 2.2 – 5G data center design
To design a 5G network, it is of the utmost importance to first decide on what use cases need to be
supported. The design of the network will change according to the latency, reliability, and bandwidth
needed to support a particular use case. In the example shown here, the use cases supported are
enhanced broadband, Ultra-Reliable Low Latency Communications (URLLC), and the IoT, which
means that this can be adapted to cover most applications.
Let us focus on the main components of this design one by one – firstly, a far-edge site. This is basically
the cell site in which the radio tower is erected. As most of us will know, an entire geographical
area is broken down into cells in which radio base stations transmit. The hexagonal figures denote a
combination of one or more cells, which can be connected to one or more RUs. Since this is close to
the user accessing the network, it is known as far-edge.
It should be noted that for some deployment options, a far-edge site can host both the DU and the RU.
In other cases, the DU can be located in a local data center close to a collection of sites to aggregate
the data. It is also possible to locate the DU, along with the CU, in a near-edge data center. The near-
edge data center can also host the UPF for delay-sensitive applications. It is also possible to collocate
the CU, DU, and RU in a far-edge data center. Hence, many different location configurations are
possible. It is the operator’s choice to select the appropriate combination. The general idea is that
closer proximity of these radio components to the UPF will reduce the latency and hence be more
appropriate for delay-sensitive applications.
The CU is then connected to the mobile packet core by optical fiber. The mobile packet core can be
centrally located. It is also possible to regionalize the packet core in cases where the geographical area
of a country is large. In this case, there can be multiple regions – for example, east, west, north, south,
and central – that cater to the traffic and subscribers in proximity in order to reduce latency. Hence, the
determining factor for the design choice is also the geographical area of coverage. Often, the connectivity
of the CU to the packet core is via leased lines, so it is important to ensure the lines are secure and use
security protocols to avoid malicious snooping and attacks that can cause denial-of-service.
5G network concepts
Multiple NFs come together to make the 5G System (5GS). Each of these NFs has a designated function
and is connected to one or more other NFs to provide its services or consume services provided by
another NF.
5G almost entirely ushers in the adaptation of virtualized infrastructure. The NFs have been designed
to operate over Commercial Off-The-Shelf (COTS) hardware and are no longer complicated or
expensive. These NFs are therefore virtualized. They can be virtual machine-based or use microservices-
based or bare-metal-based software capable of running microservices directly, bypassing the need for
a VM. The 3GPP standards on 5G have been written keeping this microservices-based virtualized
infrastructure in mind. Hence, 5G completes the cycle of telecom virtualization that started with 4G
and comes full circle with 5G.
3GPP has defined each of these connections between any two NFs, as shown by the reference point
architecture diagram in Figure 2.3. Each of the connections is named – this name comprises the letter
“N,” followed by a number to uniquely identify the connection between the two NFs.
We will go into the details of what role each of these NFs performs and how it interoperates with its
neighboring NFs:
5G network concepts 25
Figure 2.3 – 5G packet core reference points
This diagram details the various constituents of a 5G network. In the previous sections, we have focused
mainly on radio and transport. In the upcoming sections, we will cover each NF.
The AMF
A reference point diagram for an AMF is shown in Figure 2.4. The AMF is connected to various other
NFs via well-defined interfaces, as indicated here:
Figure 2.4 – AMF reference points

It must be noted that all these interfaces are service-based interfaces. We will learn more about the
service-based model in the next chapter. The numbers denote a specific connection name:
• N11: This is the interface that connects the AMF to the SMF, and the AMF controls it
• N15: This is the interface that connects the AMF to the PCF
• N2: This is the interface that connects the AMF to the N3-Interworking Function (N3-IWF)
and the Next Generation Radio Access Network (NG-RAN)
• N1: This is the virtual interface that connects the AMF to the UE for signaling
• N17: This is the interface that connects the AMF to the Equipment Identity Register (EIR)
• N20: This is the interface that connects the AMF to the Short Messaging Service Function (SMSF)
• N22: This is the interface that connects the AMF to the Network Slice Selection Function (NSSF)
• N12: This is the interface that connects the AMF to the Authentication Server Function (AUSF)
• N8: This is the interface that connects the AMF to the UDM
The AMF is responsible for the termination of the CP interface from the NG-RAN (N2). Hence, it is
connected to the gNB via the same interface. The AMF also terminates the NAS (N1) and is responsible
for ciphering and integrity protection of NAS messages exchanged between it and the UE. The AMF
undertakes the registration management of the UE and ensures that a legitimate UE is successfully
registered with the network. It will reject the registration of UEs without subscriptions or incorrect
subscriptions. Hence, it behaves as a gatekeeper to the network, only allowing legitimate subscribers
to access the network. Hence, it provides access authentication and authorization functions. It also
provides support for network slice-specific authentication and authorization.
The AMF is responsible for managing the connection of the subscriber. It is also responsible for
reachability management and will page an idle UE so that it can come back to a connected mode
and service a call. The AMF is also responsible for mobility management, which means that it is
responsible for successfully handing over UE from one tower to another, and also from one AMF
region to another. If the UE ventures outside of the coverage of the AMF, it is also responsible for
inter-RAT handovers to LTE or the WLAN (N3-IWF). It is responsible for providing an EPS bearer
ID for interworking with the 4G EPS.
The AMF events allow for lawful interception, and armed events can be sent to the authorities for law
enforcement. It also provides location services management to regulatory bodies. The AMF provides
a transparent container for Session Management (SM) messages between the SMF and the UE. An
AMF uses the N14 interface for AMF re-allocation for AMF-AMF information transfer. This can be
either intra- or inter-PLMN, and therefore be leveraged for both inter- and intra-PLMN mobility.
Additionally, to implement SMS functionality, it provides transport between the UE and the SMSF.
The SMF
The SMF is responsible for session establishment, modification, and release. It is responsible for
maintaining the tunnel between the UPF and the access node (the gNB). One of the most important
responsibilities of the SMF is UE IP address allocation and management. This UE IP address can be
locally allocated from a pre-configured IP pool, or it can be received from the UPF or an external data
network. The SMF is expected to perform DHCPv4 and DHCPv6 server and client functionalities. It is
responsible for responding to Address Resolution Protocol (ARP) requests and IPv4/IPv6 neighbor
solicitation requests based on the local cache for Ethernet Protocol Data Units (PDUs). The SMF
responds to ARP and neighbor solicitation requests by providing the MAC address corresponding
to the IP address sent in the request:
Figure 2.5 – SMF reference points
SMF selects the UPF that will service the subscriber, and this selection can be based on various
parameters, such as the current load on the UPF, the TAC, or cell ID-based selection for closer
proximity to the UE. It is responsible for providing traffic steering information to the UPF so that
traffic is routed to the proper destination. It interacts with the PCF via the N7 interface and receives
traffic rules and QoS parameters for each subscriber. The SMF also provisions lawful intercept probes
for law enforcement authorities. It is responsible for collecting charging data and providing it to the
CDF for billing purposes. The SMF is also the termination point for SM parts of NAS messages. It
provides support to downlink data notification messages and notifies the AMF of any incoming traffic
for a particular UE in idle mode. SMF determines the SSC mode for a session (we will discuss SSC
modes in the next section). The SMF supports PCSCF discovery for voice sessions.
The UPF
The UPF is the main data plane NF in the 5G packet core. It connects to the gNB (radio) using the N3
interface and the data network or the internet on the data plane using the N6 interface. It is connected
to the SMF on the control plane by the N4 interface. The user data traffic flows from the UE to the
gNB to the user plane and exits to the data network. No other node in the 5GS is in the data path:
Figure 2.6 – User plane reference points
The UPF is the anchor point for intra- and inter-RAT mobility. In some cases, the UPF can also
optionally allocate IP address prefixes in response to SMF requests. It carries out packet routing and
forwarding and it can be involved in packet inspection, which is used to detect the application based
on the service data flow template and the optional Packet Flow Descriptors (PFDs) received from
the SMF. The UPF enforces gating, redirection, or steering policies on the traffic – these policies
are received from the SMF but applied on the UPF, as it is directly in the traffic path. Hence, QoS
enforcement UL/DL is done here and also supports reflective QoS marking in DL.
The UPF plays an integral part in lawful interception and can forward data packets to law
enforcement servers.
The user plane also accounts for the volume of data packets and reports the same to the SMF. The
UPF carries out downlink packet buffering, which applies to minimizing packet loss, mainly during
handovers. It is responsible for sending and forwarding end markers to the NG-RAN node used in
UE mobility scenarios.
It also triggers downlink data notifications to the SMF when data arrives for UE in idle mode. The
UPF is also responsible for responding to router solicitation and ARP requests; it sends the MAC
address corresponding to the IP address in the request.
The UPF can duplicate packets in the downlink and eliminate them in the uplink direction in the
GTPU layer. It supports TSSS steering functionality to steer MA PDU session traffic.
The PCF
The PCF is responsible for providing a unified policy framework to govern network behavior. It provides
policy rules to control plane functions such as the SMF so that they can be passed on to the UPF to
enforce them. It also accesses subscription information from a Unified Data Repository (UDR) to
make relevant policy decisions. It accesses the CHF for usage monitoring information, based on which
it sends rules to the SMF. Hence, the PCF is used to manage the network QoS and traffic steering rules.
Figure 2.7 – PCF reference points
It interacts with the AF over N5 and receives application-level information, such as the bandwidth and
QoS requirements, and also takes a decision on traffic routing based on application traffic properties.
The PCF interacts with the UDR; it retrieves policy and subscription information. The UDR can also
send notifications based on subscription information changes to the PCF so that it can in turn notify
the SMF with updated rules for traffic policing.
N30 interfaces with the Network Exposure Function (NEF); it exposes the capabilities, services, and
resources of the PCF to the outside world.
The N28 interface of the PCF with the CHF is leveraged for usage control, to notify the PCF when the
subscriber crosses a usage threshold and needs to be throttled, as an example. When a threshold is
breached, the CHF notifies the PCF, which, in turn, sends throttling rules to the SMF to be enforced
on the UPF.
The AMF and the PCF exchange UE mobility-related information so that the PCF can trigger policies
based on RAT type, UE mobility, and so on.
The NEF
The NEF is responsible for securely exposing the NF capabilities and events to third-party AFs. The
NEF stores information to and retrieves information from the UDF located in the same PLMN and
securely provides information from non-3GPP networks. It also translates information between the
AF and the 5GS. It masks network and user information for external AFs based on the network policy.
Figure 2.8 – NEF reference points
The NEF can also support PFD storage, which it retrieves from the UDR and can supply to the SMF
using a push or pull method based on the request from the SMF. Network Data Analytics Function
(NWDAF) analytics can be securely exposed to AFs using the NEF. The NWDAF can also retrieve
information about the AF via the NEF. It can also support non-IP-based delivery.
The NRF
The Network Repository Function (NRF) is used for service discovery. It receives an NF discovery
request from the NF instance or Service Communication Proxy (SCP) and provides the requested
information to the requesting NF or SCP, whichever applies. It can be used to discover P-CSCF for
IMS calls. It maintains a profile of all the NFs that are registered with it and maintains a record of
the services they offer. It maintains the health of the NFs it discovers and keeps track of the load
information. It notifies the already registered NFs of any new NF registration and informs the other
NFs about the services available from new NFs. In the case of network slicing, multiple NRFs can be
deployed at the PLMN level, the shared slice level, or a slice-specific level.
The NRF maintains the following information on registered NFs:
• NF instance IDs
• NF types
• PLMN IDs
• Network slice identifiers
• IP addresses or FQDNs of the NFs
• NF capacity information
• NF priority information
• NF set IDs
• Names of supported services, if applicable
• Endpoint addresses of instances of each supported service
• TAIs
• NF load information
• Routing indicators for the UDM and AUSF
• GUAMIs for the AMF
• SMF area identities for the UPF
• UDM group IDs
• UDR group IDs
• AUSF group IDs
• PCF group IDs
• HSS group IDs
• Supported analytics IDs
• Event IDs supported by AFs for the NEF
• Application identifiers supported by the AFs for the NEF – ranges of external identities
Figure 2.9 – The reference architecture for the 5G core with a focus on the NRF
The UDM
The UDM function is the main repository for subscriber information and engages in subscriber
management. It is responsible for the generation of 3GPP – that is, authentication credentials. It stores
and manages the Subscription Permanent Identifier (SUPI) for each subscriber in the 5GS. It supports
the de-concealment of the SUPI to reveal privacy-protected subscriber information (the Subscription
Concealed Identifier (SUCI)). It provides access authentication based on the user subscription – for
example, for roaming users, it verifies whether the subscriber has roaming privileges in the requested
network. It manages the users serving NF registration by storing and retrieving the AMF for the UE
and storing SMFs for UE PDU sessions. It maintains the SMF/Data Network Name (DNN) assignment
for the UE and thereby helps maintain the session continuity in the case of handovers and so on. It
also supports lawful interception.
The UDM may use subscriber information stored in the UDR – in which case, the UDM only
implements the application logic and does not need to store data.
The AUSF
The AUSF supports authentication for 3GPP access and non-3GPP access; it is responsible for storing
keys and implementing an EAP authentication server.
The N3IWF
The N3 Interworking Function (N3IWF)enables the 5GS system to work with untrusted non-3GPP
access networks. It supports the establishment of IPsec tunnels connected to the UE. The N3IWF
terminates the IKEv2/IPSec protocols with the UE over the NWu. The information needed to authenticate
and authorize the UE within the 5GS is relayed over N2. It terminates the N2 and N3 interfaces of the
5G core network for the control plane and user plane. It relays UL/DL NAS signaling between the UE
and the AMF. It handles N2 messages from the SMF, which are transparently carried by the AMF and
related to the UE. It carries user traffic from non-3GPP access networks into the 5GS. It enforces the
QoS relayed in the N2 message. It terminates the data path between N3 and the UPF. It also serves as
the local mobility anchor within the untrusted 3GPP networks.
A classic example of the use of the N3IWF is WLAN support in a 5GS, where the WAN (which is
untrusted) is able to work with the 5GS.
The AF
The AF interacts with 3GPP packet core NFs to support application’s influence on traffic routing. It
has access to the NEF and interacts with the policy framework for policy control and IMS interactions
in the 5G core:
Figure 2.10 – AF reference points
The role of the AF is relevant in non-roaming cases. The AF can send requests to influence the SMF
routing decisions for the traffic in a PDU session. The AF may also influence the UP selection by
the SMF. The AF interacts with the PCF via N5 and hence can update policies related to an ongoing
PDU session.
The UDR
The UDR serves as the data store for the subscription information for UE. It helps in the storage and
retrieval of subscription data by the UDM. It helps with storage and the retrieval of policy data for
the PCF. It also stores and retrieves structured data for exposure via the NEF:
Figure 2.11– UDF reference points

It stores PFDs for application detection. It also stores and retrieves NF group IDs corresponding
to a subscriber. It must be noted that the UDR is an intra-PLMN NF and it will store and retrieve
information only for the NFs within the same PLMN.
The SMSF
The SMSF is responsible for providing the functionality of supporting SMS over NAS. It performs
SMS management subscription data checking and conducts SMS delivery accordingly. It relays the
message from the device toward the SMS-GMSC, IWMSC, or SMS router, and vice versa:
Figure 2.12 – SMSF reference architecture
It also generates CDRs related to the SMS. It can perform lawful interception and interacts with
the AMF and the SMS-GMSC for the notification procedure that communicates whether the UE is
available or unavailable for SMS transfer. It also notifies the SMS-GMSC to inform the UDM when
the UE is unavailable to receive SMS.
The NSSF
Network slicing is a concept introduced with 5G networks. Network slicing allows the operator to
design their physical infrastructure differently for different use cases. As an example, a URLLC use
case, an enhanced broadband use case, and an IoT use case can all be assigned different types of
infrastructure (hardware or networking) based on the requirements of latency, reliability, availability,
and so on. Hence, the operator can choose to deploy a latency-sensitive application for URLLC in a
CPU and a memory-intensive chipset with faster processors, while the enhanced broadband use case
can be deployed on COTS viable hardware. Hence, unlike the legacy model of one-size-fits-all, with
network slicing in 5G, this is no longer the case.
Network slices are assigned Network Slice Selection Assistance Information (NSSAI), with a given
slice and service type to identify the use case.
The NSSF is responsible for selecting a set of network slice instances to serve the UE. It determines the
allowed slices for the UE and the AMF set that will be used to serve the UE. This can be determined
through the static configuration of the AMF sets assigned to each slice on the NSSF or by querying
the NRF.
The SEPP
The Security Edge Protection Proxy (SEPP) is used to enable different 5G networks to securely
interconnect with each other. It is responsible for providing end-to-end confidentiality and integrity
between two operator networks in roaming cases. Hence, this NF is used to aid roaming partners to
interconnect securely. It carried out message filtering and policing on inter-PLMN control plane interfaces:
Figure 2.13 – The SEPP in a roaming scenario
It hides the network topology of the two networks it connects from each other. The SEPP protects
the connection between service producers and service consumers. It acts as a service relay between
the actual service provider (in one network) and the service consumer (in a different network), but
for both the service producer and the consumer, the result of the service relay is transparent. Hence,
it is equivalent to a direct service interaction.
The NWDAF
As the name suggests, this NF represents operator-managed network analytics. It implements service-
based interfaces to collect data via a subscription or request model from other NFs:
Figure 2.14 – The NWDAF
The objective is to provide an analytical capability in the network that can be leveraged for network
automation, monitoring, identifying challenges in the network, and so on. The NWDAF can be securely
exposed by the NEF for consumption by external entities.
The following use cases are supported by the NWDAF:
• Load-level computation and prediction for a network slice instance

• Service experience computation and prediction for an application/UE group
• Load analytics information and prediction for a specific NF
• Network load performance computation and future load prediction
• Expected behavior predictions for UE
• Abnormal behavior or anomaly detection for UE
• Mobility-related information and predictions for UE
• Communication pattern predictions for UE
• Congestion information – current and predicted for a specific location
• QoS sustainability, which involves reporting and predicting QoS changes
The SCP
The SCP is an optional NF that helps with indirect communication between a producer and a
consumer. It serves the additional role of load-balancing service requests among various producers.
Hence, when a consumer sends a request, the SCP selects the appropriate producer based on the load
and availability criteria:
Figure 2.15 – The SCP
The NFs can have direct communication, such as in the example in the preceding figure in which the
consumer and NRF directly communicate. However, communication can also happen via the SCP,
as in the example shown at the bottom of the diagram. In this case, the discovery of the NF can also
be delegated to the SCP, which, in turn, contacts the NRF to find the appropriate consumer and relay
the information to the consumer.
Among the other responsibilities of the SCP is communication security. It authorizes the NF consumer
to access the NF producer.
It monitors the NFs and balances the load. The SCP can be deployed in a centralized or distributed
manner. Similarly, more than one SCP can be present in the communication path between the producer
and consumer services. To ensure that multiple SCPs can route messages between a producer and
consumer, the SCP can also register its profile in the NRF. Alternatively, a local configuration should
also be supported.
It can be deployed at a PLMN level, shared slice level, or slice-specific level with the condition that
the SCP can communicate with the appropriate NRF.
The NSSAAF
The Network Slice Specific Authentication and Authorization Function (NSSAAF) is used for
slice-specific authorization and authentication with an AAA server, which can be hosted either by
the host PLM or by a third party that has a business relationship with the host operator, such as a
slice dedicated to a particular enterprise. This is executed with the help of the EAP framework. The
AMF performs the role of the EAP authenticator and communicates with the AAA server via the
NSSAAF. The NSSAAF is responsible for any AAA protocol-related interworking with the AAA
protocol supported by the AAA server.
The procedure of NSSAA is triggered by the AMF during a registration procedure when a certain
network slice requires slice-specific authentication, when there is a subscription change, or when the
AAA server requires a re-authentication.
In previous sections, we have learned about the key components of a 5G network, explored their role
and responsibility, and how they interwork with each other. In the next section, we will cover some
key 5G network concepts that are used.
5G network concepts
In this section, we will go over the various new concepts and terminologies introduced with 5G.
PDU sessions
A PDU session is the logical connection between the UE and the data network. It is by the means of
this logical connection that the UE is able to browse data, place calls, and so on.
Figure 2.16 – QoS in 5G
This connection determines the QoS experienced by the user. Consider a case in which the UE initiates
an attach request to the network so that it can access the internet; what happens in the background
is that a logical connection (or pipe) is created between the UE and the 5G network that carries the
data flows associated with browsing the internet.
This logical connection is defined by attributes such as a QoS parameter. Certain PDU sessions require
a guaranteed QoS, which must be provided by the network if the PDU session is accepted. Hence, the
network must reserve resources for this kind of PDU session. A classic example of this is an emergency
call. When a user places an emergency call, the network must admit the call and provide the necessary
resources. We will learn more about 5G QoS in the upcoming sections.
In the preceding diagram, three PDU sessions are depicted between the same UE and the network.
Each PDU session can have one or more QoS flows, differentiated by the QoS flow indicator.
In the example, one PDU session is an IMS session, the second can be a data session, and the third can
be IoT or enterprise access. Hence, the same device is able to cater to multiple types of applications
that require different types of resources from the network simultaneously.
Every PDU session in UE is associated with an identification number, which is known as the PDU
session ID. In the 5GS, this can range between 1 and 15. For a PDN connection established via MME,
the PDU session ID value is set to 64, plus the EPS bearer ID for the default EPS bearer of the PDN
connection; for a PDN connection established via an ePDG, the PDU session ID value is set to 80,
plus the EPS bearer ID for the default EPS bearer of the PDN connection:
Figure 2.17 – PDU session ID
The PDU session can be of the IPv4, IPv6, IPv4v6, unstructured, or Ethernet type.
5G QoS
To understand the 5G QoS better, it is best to start with the terminologies used to describe it:
Table 2.1 – QoS parameter description
Every PDU session in the 5GS has one or more QoS flows and each of these flows is identified by its
QFI. The SMF allocates the QFI based on the QoS needed for the particular user traffic. On the radio
interface, on the other hand, multiple QoS flows can be sent into one Dedicated Resource Bearer
(DRB). Only one GTPU tunnel is formed between the radio and user plane for each PDU session.
The GTPU header has a field to depict the QFI, which is used to differentiate flows. The QFI values
can be repeated within the same user equipment for different PDU sessions for the same subscriber.
Figure 2.18 – 5G PDU session
In the preceding figure, we can see that the UE is accessing the internet. The UE interacts with the
NG-RAN node, which is, in turn, connected to the 5G user and control planes. When the UE powers
up, a PDU session is established; this is the default session used to access the internet. In this case, it
has a 5Q1 of 9, indicating a class of QoS for non-guaranteed bitrate sessions with a delay budget of
300 ms, used for browsing, file downloads, and so on.
A second flow is installed within the same PDU session with a 5QI of 8, which has higher priority
than the first flow with a 5QI of 9. This flow is denoted within the PDU session by QFI 2. A single
GTPU tunnel will serve both flows in the PDU session, and hence a single tunnel endpoint identifier
is allocated to both these flows.
The diagram also shows the GTPU packet with the source and destination IP information, destination
port information, tunnel endpoint identifier details, QFI, and the actual data payload.
Next, considering that the UE now wishes to access voice services, a second PDU session will be set
up. Firstly, a flow with 5QI of 5 is set up, which is used for IMS signaling. Then, subsequently, when
the user actually places a voice call and dials a number, a second flow is installed with a 5QI of 1 and
this is used to carry the voice traffic. Note that within the PDU session, we have two flows denoted
by QFI 1 and QFI 2 with a 5QI of 5 and a 5QI of 1 respectively. There is a second GTPU tunnel in
addition to the one established earlier for the internet browsing session:
Figure 2.19 – Voice and data PDU sessions in 5G
It must be noted that each traffic flow is associated with a filter, as shown here. This is used by the UE
to separate the traffic for each flow. Also, note that the same QFI number does not indicate the same
packet filter. Every flow in the UE will be associated with its own filter, which is distinct regardless of
the similarity of the QFI number in different PDU sessions.
Multiple PCC rules (SDFs) can be bound to the same QoS flow as long as the 5QI and the ARP value
are the same.
There can be a maximum of 64 QoS flows in a PDU session. The number of DRBs on the RAN side
that the UE needs to support is 16. In the 5G core, not all PDU sessions may be active at the same time,
so this does not limit the number of PDU sessions that UE can support, although 16 PDU sessions
are quite a lot anyway.
The 5G 5QI-to-QoS mapping is shown here:
Default
Default Packet Packet Default
5QI Resource Maximum
Priority Delay Error Averaging Example Services
Value Type Data Burst
Level Budget Rate Window
Volume
1 20 100 ms 10-2 N/A 2,000 ms Conversational voice
2 40 150 ms 10-3 N/A 2,000 ms Conversational video (live streaming)
Real-time gaming, V2X messages (see
TS 23.287 [121])
3 30 50 ms 10-3
N/A 2,000 ms
Electricity distribution – medium
voltage, process automation monitoring
Non-conversational video
4 50 300 ms 10-6 N/A 2,000 ms
(buffered streaming)
Mission-Critical Push To Talk
65 7 75 ms 10-2 N/A 2,000 ms
(MCPTT) on the user plane
66 20 100 ms 10-2 N/A 2,000 ms Non-MCPTT on the user plane
67 GBR 15 100 ms 10-3 N/A 2,000 ms Mission-critical video on the user plane
75
“Live” uplink streaming (e.g., TS
71 56 150 ms 10-6 N/A 2,000 ms
26.238 [76])
72 56 300 ms 10-4 N/A 2,000 ms
26.238 [76])
73 56 300 ms 10-8 N/A 2,000 ms
26.238 [76])
74 56 500 ms 10-8 N/A 2,000 ms
26.238 [76])
76 56 500 ms 10-4 N/A 2,000 ms
26.238 [76])
5 10 100 ms 10-6 N/A N/A IMS signaling
Video (buffered streaming)
6 60 300 ms 10-6 N/A N/A TCP-based (e.g., www, email, chat, FTP,
P2P file sharing, progressive video, etc.)
Voice
7 70 100 ms 10-3 N/A N/A Video (live streaming)
Interactive gaming
Video (buffered streaming)
8 Non-GBR 80 300 ms 10-6 N/A N/A TCP-based (e.g., WWW, email, chat, FTP,
P2P file sharing, progressive video, etc.)
9 90
Mission-critical delay-sensitive signaling
69 5 60 ms 10-6 N/A N/A
(e.g., MC-PTT signaling)
Mission-critical data (e.g., example
70 55 200 ms 10-6 N/A N/A
services are the same as 5QI 6/8/9)
79 65 50 ms 10-2 N/A N/A V2X messages (see TS 23.287 [121])
Low-latency eMBB applications
80 68 10 ms 10-6 N/A N/A
Augmented reality
82 19 10 ms 10-4 255 bytes 2000 ms Discrete automation (see TS 22.261 [2])

Discrete automation (see TS 22.261 [2]);
1,354 bytes V2X messages (UE – RSU platooning,
83 22 10 ms 10-4 2,000 ms advanced driving, cooperative lane
(NOTE 3)
changes with low LoA. See TS 22.186
[111] and TS 23.287 [121])
1,354 bytes Intelligent transport systems (see TS
84 24 30 ms 10-5 2,000 ms
Delay- (NOTE 3) 22.261 [2])
critical
Electricity distribution – high-voltage
GBR
(see TS 22.261 [2])
85 21 5 ms 10-5 255 bytes 2,000 ms V2X messages (Remote driving. See
TS 22.186 [111], NOTE 16, see TS
23.287 [121])
V2X messages (Advanced driving,
collision avoidance, platooning with
86 18 5ms 10-4
1354 bytes 2000 ms
high LoA. See TS 22.186 [111], TS
23.287 [121])
Table 2.2 – 5QI values
Session and Service Continuity (SSC)

SSC is supported in the 5GS to address the need for continuity across various applications or services for
the UE. There are different modes of supporting this requirement, and they are well defined in the 5GS:
Figure 2.20 – SSC modes

5G identifiers 45
The SSC mode is associated with every PDU session, and it does not change during the lifetime of
the PDU session. The following are the various modes of session continuity – for example, in a UE
mobility use case when the user is traveling on a high-speed train:
• SSC Mode 1: In this case, the network needs to preserve the connectivity of the service provided
to the UE. As an example, for a PDU session of the IPv4, IPv6, or IPv4v6 type, the IP address
needs to be preserved.
• SSC Mode 2: In this case, it is not mandatory to maintain the connectivity. When the UE
moves from one region to another or undergoes a handover procedure triggered by any other
reason, the network can “break-before-make” in this case. Hence, the user connectivity or PDU
sessions can be released. As an example, if the UE is allocated an IPv4/IPv6 address during its
initial attachment, the address can be released and a new IP address can be assigned to the UE.
Hence, a disruption to the session continuity is accepted with SSC Mode 2.
• SSC Mode 3: As we learned, in SSC Mode 2, the technique of break-before-make is employed
and accepted, and SSC Mode 3 is an enhancement of that. A new PDU session is set up before
the already established PDU session is torn down. Hence, it is a “make-before-break” procedure.
The IP address, in this case, is also not preserved, as the new session may have a different IP
address assigned. However, this allows better service continuity than SSC Mode 2 due to the
make-before-break principle.
In the previous section, we learned about the key concepts of PDU sessions, 5G QoS, and SSC in 5G.
These concepts will be used widely by network engineers when designing and operating 5G networks.
5G identifiers
In telecommunication systems, the network operator allocates a SIM card to every device. This SIM
card is associated not just with the mobile number but also with a SUPI in the 5GS. It was known as
International Mobile Subscriber Identity (IMSI) in the 4G world.
Figure 2.21 – 5G identifiers
The authentication of the UE and the network is based on symmetric keys and is dependent on the
identification of the user. However, if the identification is sent in cleartext over the air from the UE to
the network, it is susceptible to being imitated by malicious entities, who can pose as legitimate users.
To avoid this, mobile networks use several temporary identifiers called Globally Unique Temporary
Identifiers (GUTIs).
These identifiers are frequently changed and used for identifying a UE over the air. However, in some
situations, like the first user registration, the SUPI is used, and then from thereon, a GUTI is used:
Figure 2.22 – 5G GUTIs

5G identifiers 47
The GUAMI serves as a globally unique identifier for each AMF within the 5G network. Between
different regions, AMF set IDs can be duplicated:
Figure 2.23 – The GUAMI
Now, in 5G, a SUPI can be an IMSI, as in 4G, or a Network Access Identifier (NAI), which can be
used in SIM-less devices.
A SUPI is a string of 15 decimal digits: 3 digits for the Mobile Country Code (MCC), 2 or 3 digits for
the Mobile Network Code (MNC), and the next 9 or 10 digits for the Mobile Subscriber Identification
Number (MSIN).
For privacy reasons, the SUPI from the 5G devices should not be transferred in cleartext and is instead
concealed inside the privacy-preserving SUCI. The SUPI is privacy-protected over the air of the 5G
RAN by using the SUCI. For SUCIs containing IMSI-based SUPIs, the UE, in essence, conceals the
MSIN of the IMSI. On the 5G operator side, the Subscription Identifier De-concealing Function
(SIDF) of the UDM is responsible for the de-concealment of the SUCI and resolves the SUPI from
the SUCI based on the protection scheme used to generate the SUCI.
The DNN performs the same function and follows the same format as the Access Point Name (APN)
in 2G, 3G, and 4G systems.
Figure 2.24 – The DNN
The DNN is essential for the UE to be able to identify to which network it needs to connect for a
particular type of service. Common use cases are accessing the internet and the ability to place voice
calls. In this case, the UE would need to connect to a mobile network, requesting access to DNN data
(for internet access) and the DNN IMS (for voice, video, and text services). Hence, two PDU sessions
will be established, one with DNN data and one with a DNN IMS. Similarly, there can be other DNNs
based on advanced 5G use cases, such as having a DNN for enterprise connectivity or for IoT devices.
Summary
In this chapter, we went over the various 5G NFs and some 5G concepts. The concepts discussed in
this chapter will be the foundations on which we will explore 5G deeper and the various procedures
and deployment options.
In upcoming chapters, we will deep-dive into the cloud-native and service-based infrastructure and
go into details of various 5G procedures, call establishment, and so on.
In the next chapter, we will discuss the building blocks of 5G, which is the cloud-native infrastructure.
We will compare and contrast the 4G and 5G network design principles.
3
Building Blocks – Cloud Native
Infrastructure
In this chapter, we will learn about the infrastructure building blocks of 5G. We will cover the evolution
of telecom infrastructure from legacy networks (3G–4G) to 5G networks. We will discuss in detail
producer-consumer models, cloud-native infrastructures, REST principles, and service-based interfaces
in 5G. Understanding these topics will help us understand the real transformation that 5G technology
is about to bring to the world of telecom applications and infrastructure.
By the end of this chapter, we will be able to understand the fundamentals of telecom infrastructure
and its evolution. We will also be delving into details about service-based infrastructure and how it
applies to 5G Network Functions (NFs). In addition to this, we will cover the services offered by
each network function and who consumes them. This will be more of an implementation view of the
functions, roles, and responsibilities of the NFs we discussed earlier in Chapter 2, in the context of
the services offered and consumed.
In this chapter, we’ll cover the following main topics:
• The evolution of telecom infrastructure

• Cloud-native infrastructure and applications
• Service-based architecture
• What is REST?
• REST in 5G
The evolution of telecom infrastructure

Over the past few decades, telecom infrastructure has been built primarily on proprietary appliance-
based hardware. The network elements in 3G and 4G were built using monolithic software principles
and were not designed for distributed functions. It was also not easy to scale these network elements
in or out without adding or removing bulky and space/power-hogging custom appliances.
50 Building Blocks – Cloud Native Infrastructure
In many cases, the service provider themselves would request only a fraction of the capacity of the
appliance for, say, adding a small percentage of users. It would still need to procure the hardware at
an appropriate size for the original larger capacity, hence greatly increasing the Capital Expenditure
(CAPEX) on building and expanding a mobile network.
Operators consistently have been under pressure to reduce data rates across the world; hence, it became
imperative for them to reduce the operational expenditure and CAPEX.
To mitigate this problem, over the last 10 years, a lot of work has been done to find solutions. The
most notable one was to build virtualized software for the network elements that could be deployed
on Commercial Off-The-Shelf (COTS) hardware. This would free the operator of expensive custom
appliances. Hence, the first step toward transformation was to free the mobility (3G/4G) software from
purpose-built hardware and virtualize it, so that the various software for mobility network elements
could now run on virtual machines over COTS servers.
This was further accelerated by open source projects such as OpenStack, which was adopted by
many telecom vendors as their infrastructure of choice. Hence, the first move from appliance-based
infrastructure to virtualized infrastructure took place years before discussions on 5G specifications
even started.
Figure 3.1 describes this transition; to the left of the figure, legacy purpose-built hardware with
3G and 4G packet core application software is shown. To the right, the block depicts a virtualized
infrastructure, a Management and Orchestration (MANO) framework, as proposed by the European
Telecommunications Standards Institute (ETSI).
In the virtualized infrastructure, the telecom software (in this case, the 4G packet core network elements)
are hosted on COTS hardware. This is made possible by Virtual Infrastructure Manager (VIM)
software, which is responsible for resource allocation and the management of the COTS hardware.
The VIM abstracts the hardware from the installed virtual machines and provides compute, storage,
and networking capabilities to the virtual machine installed on it.
Other components, such as the Virtual Network Function Manager, are responsible for the life cycle
management of the Virtual Network Function (VNF); in this case, it’s the virtual machine hosting 4G
packet core network elements such as the Mobility Management Entity (MME), the PDN Gateway
(PGW), and the Serving Gateway (SGW).
The Element Manager (EM) is responsible for managing the individual VNFs.
Cloud-native infrastructure and applications 51
Figure 3.1 – ETSI MANO NFV architecture
To summarize, the first major transformation of telecom applications came with virtualization. This
started with 3G and 4G software between 2012 and 2016. This trend has now been taken forward and
enhanced natively in 5G. Network functions and standards in 5G have incorporated the tenets of the
cloud and virtualization from the very beginning.
It is recommended to architect 5G NFs on cloud-native development principles. Cloud-native software
is built for reliability, consistency, and ease of scaling.
The preceding 5G specifications have justified the adoption of cloud-native development principles.
We will now go over the details of cloud native-based infrastructure in the next section.
Cloud-native infrastructure and applications

Cloud-native infrastructure removes the expensive proprietary appliance-based hardware used to
run applications and replaces it with cheaper COTS hardware. With advancements in virtualization
software, a network is also provided as a service. This improvement ushers in a whole new way of
developing software as microservices. Containers are a cloud-native way of providing infrastructure
to a cloud-native application. The runtime environment for executing code is provided by containers,
which could contain images of the operating system and other customizations that are needed to run
the application code (microservice). This brings in the portability aspect of cloud-native applications,
since the code is contained within the container and the execution environment is coupled with it;
hence, it can be moved across and scaled easily.
Figure 3.2 – Cloud-native infrastructure
This ushers in the capabilities of providing infrastructure as a service. Cloud-native infrastructure

has containers that hold microservices carrying the application code. Since these containers are
conventionally much smaller than virtual machines, they can be duplicated or moved around easily.
The cloud-native method of application development also results in a faster development time, as
modular coding and service-based design are inherently present.
Service-based architecture
As 5G has been developed on cloud principles, 5G NFs also follow web-scale application principles,
so it is designed in a manner in which the NFs provide and consume services to and from each other.
Hence, 5G is based on a producer-consumer model. The 3rd Generation Partnership Project (3GPP)
has chosen to use the widely adopted Representational State Transfer (REST) model to support
communication between various NFs in 5G.
A Service-Based Architecture (SBA) is a system architecture in which the functionality of the system
is achieved by applications providing services and consuming services to and from each other. In the
context of a 5G core, a service-based interface is between two NFs that provide or consume a service
to or from each other.
Figure 3.3 portrays the producer–consumer model of communication. In this example, consider three
applications – Application A hosting service A, Application B hosting service B, and Application
C hosting services C and D. In order to execute its function, Application A would need information
from Application C; hence, Application C produces the information via Service C, consumed by
Application A. Similarly, in order to execute its functionality, Application B would need information
from Application C, which is provided by service D. Hence, consumer B consumes the services
provided by service D hosted in application.
Service-based architecture 53
Figure 3.3 – The producer–consumer model
Note that an application can host any number of service producers or consumers.
To extend this concept to a 5G example, we could say that the Session Management Function (SMF)
would consume the SM policy services produced by the Policy Control Function (PCF), as shown
in Figure 3.4:
Figure 3.4 – SMF–PCF SM policy control
We will go into more detail about the services provided and consumed by the 5G NFs in the
upcoming sections.
To summarize the concepts we have covered so far, an SBA is a system architecture, in which the
functionality of the system is achieved by a set of NFs providing services to other NFs that are
authorized to access those services.
A network function service is basically a particular capability exposed by a network function (service
producer) to another authorized network function (service consumer). Each network function can
have one or more services.
In the next section, we will learn about REST, its principles, and the way it applies to 5G.
What is REST?
REST is a style of software architecture and uses a subset of HTTP. REST is used to create web applications
that provide and consume services from each other. A web service that follows the guidelines stated
by REST is called a RESTful application.
The main benefits of REST are the following:
• It makes scalable applications

• It improves the modifiability of applications
• It enhances the performance of an application
• It improves the simplicity of application communication
• It ensures the portability of applications
• It ensures the reliability of applications
• It is stateless
• It is HTTP-based and has a standard set of operations (Create, Read, Update, and Delete (CRUD))
• It is client/server-based
• It is cacheable
• It is a layered system
• It has a uniform interface
Let us discuss some of the aforementioned concepts.
Client/server – a REST principle applicable to 5G

The 3GPP 5G NFs have a dedicated split between the requesting entity (the client) and the entity
providing access to the resource requested (the server).
What is REST? 55
Figure 3.5 – Client/server – REST in 5G NFs
The client is called the service consumer and the server is called the service producer.
Cacheable – a REST principle applicable to 5G

The requested data from the server can be cached on the client, which reduces the number of transactions
for frequently used data, hence improving the efficiency of the system. To enable caching, the payload
received from the server can be implicitly or explicitly marked as cacheable or non-cacheable.
Figure 3.6 – Cacheable property – REST in 5G NFs

Hence, a requesting client can store some information – for example, a user subscription – for
further use, the client is notified when such information changes on the server, and the dirty cache
can be refreshed.
Stateless – a REST principle applicable to 5G NFs

The request sent by the client to the server must contain all the possible information the server will
need to process the request and respond to the client. The server does not need to maintain the state
for each client or request, nor does it retain any information that may be present in the client request.
Figure 3.7 – Stateless property – REST in 5G NFs
This stateless property is adopted by the 5G NFs and enables them to scale easily, without needing to
maintain a lot of information on memory or disks.
A layered system – a REST principle applicable to 5G NFs

The client or service consumer is unaware of whether the service is provided by multiple servers. It is
possible that the service requested is provided by multiple systems and an intermediary node is used
to load-balance between the servers.
What is REST? 57
Figure 3.8 – Layered system – REST in 5G NFs
The client does not need to know this detail; hence, the client does not need to be configured to contact
multiple servers, thus simplifying operations and configurations to a large extent.
A uniform interface – a REST principle applicable to 5G NFs

All the RESTful interfaces between various NFs have uniform communication methods. Every resource
in the producer and consumer is identified by a unique identifier, and this is uniform across all RESTful
NFs. In response to a request for a resource, the client receives a representation of that resource. The
client can understand the state by inspecting the representation and modify it. Resources are operated
on via messages that have standard meanings; these messages are the HTTP methods.
Figure 3.9 – Uniform interface – REST in 5G NFs

The aforementioned methods to manipulate resources are based on HTTP/HTTP2 and are as follows:
• POST: This message requests the server to create a new resource

• GET: This message retrieves the resource addressed by the URL within the request
• PUT: This replaces the resource addressed by the Universal Resource Identifier (URI) with
the payload of the request
• PATCH: This updates the resource addressed by the URI and does not replace the content entirely
• DELETE: This method deletes the resource addressed by the URI in the message
The POST, GET, PUT, PATCH, and DELETE methods are used extensively between 5G NFs to request
and provide services to each other.
REST in 5G
In this section, we will learn about the applicability of REST in 5G, and how all the various concepts
that we have gone through in the previous sections come together in a 5G system.
Figure 3.10 represents some of the RESTful interfaces in a 5G system:
Figure 3.10 – RESTful SBIs in 5G NFs
We explore the details of each of them and understand the services provided to and consumed by
each of these NFs. We will also understand the role of each of these services and how they contribute
to the functionality of the network function as a whole.
REST in 5G 59
AMF services
The following is a list of services offered by the AMF per 3GPP Release 16, 29.518; note that each service
has a name associated with it and can have one or more service operations. These communications
will be with a known consumer in the form of a request and response:
• The Namf_Communication service enables the network function to communicate via

the non-access Statum-N1 Non-Access Stratum (NAS) messages. Hence, this establishes
communication with the user equipment and the access network (AN). As shown in the
following table, the various service operations help to transport N1 messages from the AMF
to the UE. This helps the NFs to unsubscribe and subscribe to notifications of specific N1
messages from the UE and AN. Some of these service operations help in the security context
management of the UE and UE information transfer.
• The Namf_Communication_UEContextTransfer service operation is used to provide
UE context to the NF consumer. It returns the context of the UE, which is identified by SUPI
or 5G-GUTI, and also an indication of whether the registration request for the UE has been
validated or not.
• Namf_Communication_RegistrationStatusUpdate: The consumer network
function uses this service operation to inform the AMF that a prior UE context transfer has
resulted in the UE successfully registering with it.
• The Namf_Communication_N1MessageNotify service operation is used by the AMF
to notify a destination network function that an N1 message has been received from the UE.
• The Namf_Communication_N1N2MessageSubscribe service operation is used by a
network function to subscribe with the AMF, for notification of a particular N1 message type
or N2 information pertaining to UE.
Figure 3.11 – Services produced by the AMF
• The Namf_Communication_N1N2MessageUnSubscribe service operation is used by a

network function to unsubscribe with the AMF, for it to stop notifications for N1, or N2 for UE.
• The Namf_Communication_N1N2MessageTransfer service operation is used by a
network function to transport a downlink N1 or N2 message to UE or the AN through the AMF.
• The Namf_Communication_N1N2TransferFailureNotification service
operation is used by the AMF to notify a consumer network function that an earlier Namf_
Communication_N1N2MessageTransfer service operation has failed.
REST in 5G 61
• The Namf_Communication_N2InfoSubscribe and Namf_Communication_

N2InfoUnsubscribe service operations are invoked by a consumer network function to
subscribe/unsubscribe to the delivery information contained in a particular N2 message type.
• The Namf_Communication_N2InfoNotify service operation is used by the AMF to
notify its subscribed NFs of a particular N2 message. This is also used for N2 message redirection.
• The Namf_Communication_CreateUEContext service operation is used by a source
AMF during handovers to create UE context in the target AMF.
• The Namf_Communication_ReleaseUEContext service operation is used by the
source AMF during the handover cancel procedure to release the UE context in the target AMF.
• The Namf_Communication_EBIAssignment service operation is used to request
Evolved Packet System (EPS) bearer IDs for a PDU session.
• The Namf_Communication_AMFStatusChangeSubscribe and Namf_
Communication_AMFStatusChangeUnSubscribe operations are used by a network
function to subscribe/unsubscribe to and from an AMF status change.
• The Namf_Communication_AMFStatusChangeNotify service operation is used to
notify the subscribed NFs about an AMF status change.
• The Namf_Communication_NonUeN2MessageTransfer service operation is used
by a network function consumer to request the transfer of a non-UE-specific message to the
NG-RAN via N2.
• The Namf_Communication_NonUeN2InfoSubscribe/Namf_Communication_
NonUeN2InfoUnSubscribe service operations are used by the consumer to subscribe/
unsubscribe to and from the delivery of non-UE-specific information from the RAN to the
AMF via the N2.
• The Namf_Communication_RelocateUEContext service operation is used by the
initial AMF to relocate the UE context in a target AMF during the 4G to 5G handover, via N26.
• The Namf_EventExposure service enables a network function to subscribe and get notified
about a particular event ID.
• The Namf_Location service enables a network function to request the location information
of a specific UE.
These are the services offered by the AMF. In the next section, we will cover the services offered by
the SMF.
SMF services
In this section, we will see how the SMF provides the functionality of session management via the
various services it offers to its peer NFs, per 3GPP Release 16, 29.502.
The following table illustrates the SMF service operations. The SMF interfaces with the AMF, PCF,
UDM, NRF, NEF, UPF, and NWDAF to provide the following services:
• The Nsmf_PDUSession service controls the creation, modification, and deletion of PDU
sessions. The resource is handled between the SMF and AMF via CRUD operations. The created
context is associated with an SM context ID in the SMF.
• The Nsmf_PDUSession_Create service operation is used to create a new PDU session
in the SMF or associate it with an existing PDN connection (4G) in the home SMF and PDN
Gateway Control (PGW-c).
• The Nsmf_PDUSession_Update service operation is used by the SMF to update an existing
PDU session.
• The Nsmf_PDUSession_Release service operation is used by the SMF to release or
disconnect an already established PDU session.
• The Nsmf_PDUSession_CreateSMContext, Nsmf_PDUSession_UpdateSMContext,
and Nsmf_PDUSession_ReleaseSMContex services are respectively used to create,
update, or release an SMF-AMF association to support the PDU session and UE context.
• The Nsmf_PDUSession_SMContextStatusNotify service operation is used by the
SMF to notify its consumers of SM-context-related status changes – for example, whether a
PDU session is released for local reasons, or handovers.
• Nsmf_PDUSession_StatusNotify is used by the SMF to notify PDU-session-related
changes to its consumers.
Figure 3.12 – Services produced by the SMF

REST in 5G 63
• The Nsmf_PDUSession_ContextRequest service operation is used by consumers to

request an SM context for a particular subscriber.
• The Nsmf_PDUSession_ContextPushRequest is leveraged by the SMF to push SM
context to another SMF, which acts as a consumer. This is used mainly during roaming cases.
• The Nsmf_PDUSession_SendMOData service operation is used by the AMF to send
mobile-originating data that it has received from the UE as part of the NAS procedure to the SMF.
• The Nsmf_PDUSession_TransferMOData service operation is used by the visited or
intermediate SMF to forward the mobile-originated data that it received from UE as a part of
a NAS message to the home SMF.
• The Nsmf_PDUSession_TransferMTData service operation is used by the home SMF
to transfer MT data from the NEF to the visited or intermediate SMF.
• The Nsmf_EventExposure service is responsible for providing events related to PDU
sessions to its consumer network function. This allows NFs to subscribe to or unsubscribe
from a particular event relating to the PDU session.
• The Nsmf_NIDD_Delivery service operation is used by the consumer network function
to deliver unstructured data from itself to the SMF.
UDM services
As you saw in Chapter 2, the UDM is involved with subscriber information, so let’s take a deeper look
at what this information’s contents are. It’s an easy guess that it would include a subscriber identifier,
such as a SUPI, but what are the associated details of this SUPI? Let’s look at an exhaustive list of user
details, per Release 16, 23.502.
Figure 3.13 – Subscription data contents
• The UDM provides the Nudm_UECM_Registration service operation, which is used to

register the UE’s serving network function when the network function type is the AMF or SMF.
It also serves to register an NF service consumer in the UDM for a particular user.
• The Nudm_UECM_DeregistrationNotification service operation is used by the
UDM to notify any registered consumer that a particular NF consumer has been deregistered
in the UDM.
• The Nudm_UECM_Deregistration service operation is used by an NF consumer to request
that the UDM delete information related to itself in the UE context.
• The Nudm_UECM_Get service operation is used by the network function consumer to retrieve
the NF ID of the NF service in this UE.
REST in 5G 65
• The Nudm_UECM_Update service operation is used by the network function consumer to

update UE information, such as device capabilities, and the SMF + PGW-c FQDN.
• The Nudm_SDM_Get service operation is used by the consumer to get subscription data
related to a UE.
• The Nudm_SDM_Notification service operation informs network consumers of any
updates to a subscription in a UE.
Figure 3.14 – Services produced by the UDM
• The Nudm_SDM_Subscribe service operation can be leveraged by consumer NFs to receive

notifications of updates in the subscription data.
• The Nudm_SDM_Unsubscribe service operation can be leveraged by consumer NFs to stop
receiving updates on changes in subscription data for a UE.
• The Nudm_UEAuthentication service is used by the consumer NF to get authentication
information and provide information about the result of the authentication process.
• With the Nudm_EventExposure service, the consumer – in this case, the NEF – can subscribe
to a particular event from the UDM, and the event IDs can help the consumer request specific
events that it wants to be notified of.
• The Nudm_ParameterProvision service is used particularly by the NEF to provision

and update information relating to the UE, such as 5G-VN group data or enhanced coverage
restriction information.
UDR services
As we explored in Chapter 2, the UDR serves as the repository of subscription data. The details related
to subscription are retrieved by network function consumers by querying the UDR. Hence, like any
regular database, keys are used to retrieve datasets related to each user. The most common data key
is the Generic Public Subscription Identifier (GPSI) or SUPI.
Figure 3.15 lists the exposure data stored in the UDR:
Figure 3.15 – Exposure data stored in the UDR
The UDR offers the following services to its network function consumers:
Figure 3.16 – Services offered by the UDR
Let us go over the various service operations provided by the UDR, per 3GPP Release 16, 23.502:
REST in 5G 67
• The Nudr_DataManagement service operation, Nudr_DM_Query, is used by a requesting

consumer to request a set of data from the UDR. The query contains the key that is used to
retrieve the record from the database.
• The Nudr_DM_Create service operation is used to create a new entry in the UDR. Hence,
the service consumers can use this to insert a new record into the database.
• The Nudr_DM_Delete and Nudr_DM_Update service operations are used by the network
function consumer to respectively delete or update an existing record in the UDM.
• The Nudr_DM_Subscribe service operation is used by the network consumer to subscribe
to be notified of any changes or additions to the subscription data. The consumer can also
unsubscribe using the Nudr_DM_Unsubscribe service.
• The Nudr_DM_Notify service operation is used by the UDR to notify the subscribed network
consumers about any change in subscription information.
• The Nudr_GroupIDmap_query service operation is used by the UDR to allow the retrieval
of an NF group ID of a particular subscriber.
AUSF services
The AUSF services are used to provide a UE authentication service to the requesting network function.
The following table describes the services offered and the consumers of them.
Figure 3.17 – Services offered by the AUSF
The AUSF services are described as follows:
• The Nausf_UEAuthentication service is used to authenticate the UE and is an

AKA-based authentication
• The Nausf_SoRProtection service is provided by the AUSF to steer the roaming information
protection service to the requesting NF (UDM)
• The Nausf_UPUProtection service is provided by the AUSF to protect the UE parameters
that update to the requesting NF (UDM)
PCF services
The PCF provides a list of services to consumer NFs. These services are mostly related to UE policies.
The list of services is mentioned in the following list and table, per 3GPP Release 16, 23.502:
• The Npcf_AMPolicyControl service is used by the consumer – in this case, the AMF – to
create and manage an access and mobility policy for a UE identified by its SUPI.
• The Npcf_PolicyAuthorization service is provided by the PCF to authorize an Application
Function (AF) request and to create policies as requested by an AF for a particular PDU session.
• The Npcf_SMPolicyControl service is one of the most critical services offered by the
PCF to the SMF. This helps to create and maintain a policy associated with the SMF. The PCF
provides information about PDU-session-related policy information. PCC rules are leveraged
by the SMF to send traffic policing rules to the UPF, such as throttling a particular subscriber
or providing steering rules.
Figure 3.18 – Services offered by the PCF
• The Npcf_BDTPolicyControl service allows the creation and updation of a background

data transfer policy, based on requests from consumers such as the AF and NEF.
• The Npcf_UEPolicyControl service allows the service consumer, such as the AMF,
to create, update, and delete UE policy associations. When a policy control request trigger
condition is met, the consumer can contact the PCF to inform it about the trigger condition
being met. Similarly, the AMF can also use this service to notify the PCF to update the UE
policy when certain conditions of events have been met to trigger in a similar way – for example,
AMF relocation.
REST in 5G 69
• The Npcf_EventExposure service is used by a consumer to subscribe and be notified of

certain events taking place in the PCF.
NEF services
The NEF provides services to its consumers' AF, the NWDAF, and SMF consumers, per 3GPP Release
16, 23.502:
• The Nnef_EventExposure service, hosted by the NEF, is used by the NWDAF to collect
data from the AF. The NWDAF subscribes to events, and the event IDs are associated with the
data in the AF and exposed by the NEF.
• The Nnef_PFDManagement service is used by consumers such as the SMF and AF to create,
update, and remove packet flow descriptions.
Figure 3.19– Services offered by the NEF
• The Nnef_ParameterProvision service is used by the consumer to update UE information.

• The Nnef_Trigger service is used by the NF consumer to request a trigger to be sent to an
application on UE, along with a notification about the result of that trigger delivery.
• The Nnef_BDTPNegotiation service is used by the consumer to request the background

data transfer policy.
• The Nnef_TrafficInfluence service includes request authorization of consumer
requests, parameter mapping to 5GC parameters, and vice versa, and helps influence traffic
routing decisions.
• The Nnef_ChargeableParty service enables the consumer to request to be a chargeable
party for the UE's data session.
• The Nnef_AFsessionWithQoS service is leveraged by the consumer to request the network
for a specific QoS of an AF session.
• The Nnef_SMContext service provides the ability to create, update, or delete a connection
between the SMF and NEF.
• The Nnef_AnalyticsExposure service is leveraged by a consumer to request
analytics information.
NRF services
The NRF provides the following list of services, per 3GPP Release 16, 23.502:
• The Nnrf_NFManagement service is used to manage the registration of a network consumer

in the NRF, along with its NF profile
• The Nnrf_NFDiscovery service is used by an NF consumer to discover an NF instance,
or a set of NF instances, for a specific NF service type or a target NF type
• The Nnrf_AccessToken_service is used by the NF consumer to provide OAuth2 2.0
Access Tokens for NF-NF authorization
Figure 3.20 – Services offered by the NRF

REST in 5G 71
AF services
The Naf_EventExposure service offered by the AF enables the consumer network function to
subscribe for notifications of events. The consumer can be notified about the following events:
• Service experience information

• Performance data information
• UE mobility information
• UE communication information
Figure 3.21– Services offered by the AF
The Naf_ProSe service enables the consumer to request authorization for discovery requests.
Network Slice Selection Function (NSSF) services

The NSSF offers a set of services to its consumers. The list of the services offered is as follows, per
3GPP Release 16, 23.502.
Figure 3.22 – Services offered by the NSSF
Lets take a deep dive into each of these services provided by the NSSF:
• The Nnssf_NSSelection service is used to support network slice selection. The requesting
NF is the AMF in this case, and the NSSF provides to the AMF the allowed NSSAI and configured
NSSAI for the serving PLMN.
• The Nnssf_NSSAIAvailability service is for the AMF to inform the NSSF about the
S-NSSAIs (the S-NSSAI is used to uniquely identify a network slice) that the AMF supports per
Tracking Area and to get the availability of the S-NSSAIs per Tracking Area that is supported
by the AMF.
• The Nnssf_NSRestriction service enables a network service consumer to subscribe and
unsubscribe to network slice instance restriction notifications.
In this chapter, we have learned about the various services offered and consumed by the NFs in the
5G system, in order to process a data or voice call. We have gone over the services offered to police
traffic and also to charge the subscriber. This is how the producer-consumer model in 5G works to
realize the service-based infrastructure.
Summary
In this chapter, we went into detail about cloud-native infrastructure and service-based infrastructure,
delved into the details of foundational REST concepts, and finally, the services offered by key NFs. This
will help us to build the fundamentals of a 5G system from the bottom up. These services and methods
are used by the NFs to carry out various 5G procedures, such as attaching, voice calls, handovers,
network registration, authentication, and detaching.
In the next chapter, we will be introduced to the radio aspects of 5G, including the scheduling of
radio resources.
4
5G Air Interface and Physical
Layer Procedures – Part 1
In this chapter, we are going to introduce you to 5G New Radio (NR) physical layer procedures for
control and user planes. We will start by looking at general physical layer procedures and then continue
with waveform, numerology, and frame structure. Throughout the chapter, we will be comparing and
contrasting NR and Long-Term Evolution (LTE).
After reading this chapter, you will have a good understanding of NR’s physical layer structure, downlink
and uplink references, and synchronization signals. You will also have a good understanding of the
numerology concept, which is the main difference between NR and LTE in the air interface.
In this chapter, we’ll cover the following topics:
• General physical layer procedures

• Waveform, numerology, and frame structure
Let’s get started!
General physical layer procedures

In this section, we are going to analyze the structure of the 5G air interface and related physical layer
procedures. We will explain the following:
• NR’s general physical layer structure

• Improved spectral efficiency
• Channel structure of the radio interface and how it relates to LTE
• The NR cell concept and how it relates to LTE
74 5G Air Interface and Physical Layer Procedures – Part 1
The NR physical layer at a glance

In NR, in general, adaptive Orthogonal Frequency Division Multiplexing (OFDM) and Orthogonal
Frequency-Division Multiple Access (OFDMA) are used. We will go into detail about them later
when we discuss downlink and uplink transmissions, which are Cyclic Prefix – Orthogonal Frequency
Division Multiplexing (CP-OFDM) and Discrete Fourier Transform-spread-Orthogonal Frequency
Division Multiplexing (DFT-s-OFDM) respectively.
OFDMA, in general, helps channel-dependent scheduling and link adaptation in time and frequency
domains. In contrast to LTE, we have flexible numerology in NR, as shown in the following figure.
Figure 4.1 – Flexible numerology in NR
Flexible numerology allows the Subcarrier Spacings (SCS) to be scalable, and the subcarrier spacings
in this case are 15, 30, 60, 120, and 240 kHz. In the normal Cyclic Prefix (CP), there are 14 OFDM
symbols, as there are in LTE.
Similar to LTE, NR uses multiple antennas, both on mobile devices and in the gNB. There is high
utilization of massive Multiple-Input Multiple-Output (MIMO) in NR.
Figure 4.2 – Multiple antennas, both in the gNB and the Terminal
The dedicated antenna beams from Massive MIMO antennas bring TX and RX diversity and help to
reject and mitigate interference. This Massive MIMO will bring high bitrates and capacity, increased
coverage, and energy efficiency.
General physical layer procedures 75
Figure 4.3 – Flexible bandwidth in NR
As opposed to LTE, which has a maximum bandwidth of 20 MHz, we have flexibility with NR. We
can deploy different bandwidths up to 400 MHz.
Confinement of the spectrum with improved spectral efficiency

The more bandwidth available, the more subcarriers can be allocated within a given spectrum allocation.
This results in higher spectral efficiency.
Figure 4.4 – Enhanced spectral efficiency in NR
In NR, due to the larger number of subcarriers available, the spectral efficiency is between 94–99%,
while in LTE, it is 90%.
NR channel structure
Channel structure composes of logical channels, transport channels, and physical channels. Logical
channels are composed of control and data channels. They are basically the service flow between
Medium Access Control (MAC) and Radio Link Control (RLC) in the NR’s protocol stack. Transport
channels are the multiplexing of logical data in the logical channels, and this data is organized into
transport blocks to be transported by the physical channels. Therefore, the physical channels carry
these data blocks through the NR air interface.
In a nutshell, logical channels create transport channels, and then transport channels create physical
channels. We have also reference and synchronization signals. The left pane of the following figure
shows the downlink channels, whereas the right pane of the figure shows the uplink channels:
Figure 4.5 – NR channel structure
We will provide more details about these channels in the upcoming sections.
The downlink reference and synchronization signals

In the following figure, the downlink reference and synchronization signals for NR are listed.
Figure 4.6 – NR downlink reference and synchronization signals
Let’s look at these fields in detail:
• Synchronization Signal (SS): The time and frequency synchronization for random access. It
consists of a primary synchronization signal and a secondary synchronization signal.
• Primary Synchronization Signal (PSS): Time and carrier synchronization detection.
• Secondary Synchronization Signal (SSS): Used for frame synchronization.
• Phase Tracking Reference Signal (PTRS): Compensates phase shifts. It is associated with PDSCH.
• Demodulation Reference Signal (DMRS) for PDCCH: Demodulation reference signals

for PDCCH.
• Channel State Information Reference Signal (CSI-RS): Channel state measurements for beam
forming, beam management, and Link Adaptation (LA).
• Demodulation Reference Signal (DMRS) for PDSCH: Demodulation reference signals
for PDSCH.
• Tracking Reference Signal (TRS): In NR, there is no CRS to be used for fine time-frequency
tracking. A device is configured with TRS, which is expressed as CSI-RS in the specification –
that is, the device is configured with CSI-RS for tracking.
Now, let’s see the reference and synchronization signals in the uplink.
Uplink reference and synchronization signals

In the following figure, uplink reference and synchronization signals for NR are listed.
Figure 4.7 – NR uplink reference and synchronization signals
• Physical Random Access Channel (PRACH) preamble: This is used for the initial transmission
of a device. It is contention-based or contention-free. It is a timing and receiver beam estimation.
• Sounding Reference Signal (SRS): In reciprocity-based MIMO, this is used to estimate the
UL channel and set the DL precoding.
• Demodulation Reference Signal (DMRS) for PUCCH: Demodulation reference signals
for PUCCH.
• Demodulation Reference Signal (DMRS) for PUSCH: Demodulation reference signals
for PUSCH.
• Phase Tracking Reference Signal (PTRS): This is associated with the Physical Uplink Shared
Channel (PUSCH) to compensate for phase noise.
We’ve analyzed reference and synchronization signals. Now, let’s see how some of those are related
to the NR cell definition.
NR cell definition
A Synchronization Signal block (SSB – SS block) information defines an NR cell. The SS block is
composed of PSS, SSS, and a Physical Broadcast Channel (PBCH). We will analyze the SS block in
greater detail in the next chapter within initial access procedures.
A cell ID is created by PSS and SSS. The PBCH carries a Master Information Block (MIB). The MIB
provides important parameters to devices to acquire the System Information Block 1 (SIB1), which
contains the configuration for system access.
Figure 4.8 – NR cell definition
A SIB2 or higher can be specific to a cell or System Information (SI) area. There can be several cells
in an SI area.
The details of SIB1, SIB2, and the remaining SIB messages are listed here:
• SIB 1: Cell selection/barring, radio resource configuration, and scheduling of other SIBs
• SIB 2: Cell reselection (intra-frequency, inter-frequency, and Inter Radio Access Technology
(IRAT)) in common
• SIB 3: Intra-frequency cell reselection-specific information
• SIB 4: Inter-frequency cell reselection-specific information
• SIB 5: IRAT cell reselection-specific information
• SIB 6 and SIB 7: Earthquake and Tsunami Warning System (ETWS)
• SIB 8: Commercial Mobile Alert Service (CMAS)
• SIB 9: GPS time and Coordinated Universal Time (UTC)
We will now see how the reference signals are used for cell measurement.
NR cell measurement signals

NR has a lean design, and there are less frequent reference signals compared to LTE. There is no
Cell Specific Reference Signal (CRS) in NR. PSS, SSS, and CSI-RS are used instead. A device uses
CSI-RS to measure the channel and report the Channel Quality Information (CQI) to the gNB to
aid beamforming, beam management, and link adaptation. The SIB content is minimalistic in NR; if
the device needs more, it is sent by the network.
Let’s examine the ultra-lean design concept of NR and understand the energy efficiency of NR by
making a comparison of Power Amplifier (PA) usage of an empty cell in NR and LTE.
Ultra-lean design
NR minimizes network transmissions that are not directly related to user-data delivery.
Figure 4.9 – NR ultra-lean design
In LTE, the reference signals are always on. However, in NR there are no always-on reference signals.
NR schedules transmissions and measurements of reference signals. This design is also good for energy
efficiency and minimizing interference.
PA on time ratio – LTE versus NR
The ultra-lean design concept of NR brings energy efficiency. This can be analyzed by comparing
power amplifiers on time ratios of LTE and NR.
The following figure shows the power amplifier usage of an empty LTE cell. Due to always-on reference
signals, the power amplifier is on around 50% of the time.
Figure 4.10 – LTE power amplifier usage in an empty cell

Due to the ultra-lean design of NR, reference signal transmissions and measurements are not done
periodically; they are scheduled instead. SS blocks are sent periodically.
Figure 4.11 – NR power amplifier usage in an empty cell
In the preceding figure, you can see that the SS blocks are sent at intervals of 20 milliseconds, and
there are no always-on signals in an empty NR cell. This lowers power amplifier usage by around 5%,
which is one of the building blocks of energy efficiency in NR.
In this section, we have made a quick introduction to NR physical layer procedures and the air interface.
In the following section, we are going to analyze waveform, numerology, and frame structure.
Waveform, numerology, and frame structure

In this section, we will analyze NR waveform, numerology, and frame structure. We will first talk about
scalable numerology, slot duration, and how they help to multiplex different numerologies. Then, we
will talk about different NR scheduling schemes and related use cases.
Waveform
NR employs OFDM for downlink and uplink transmissions. These are the very same waveforms that
were used in LTE.
Figure 4.12 – A visualization of an OFDM waveform

Waveform, numerology, and frame structure 81
In the preceding figure, the visualization of an OFDM waveform is presented. It has a symmetric
design, and the same waveform is used in downlink and uplink transmissions. Besides supporting
MIMO in downlink and uplink transmissions, it also supports flexible numerology.
Within a given numerology, all other subcarriers are zero at sampling points. OFDM is a proven
technology, and it has several benefits:
• Frequency diversity
• It’s robust against Inter Symbol Interference (ISI)
• Easy to implement
• A flexible bandwidth
• Suitable for MIMO
However, there are also some drawbacks to it. For instance, it is sensitive to doppler shifts and frequency
errors. We also see a high Peak to Average Power Ratio (PAPR).
NR uses OFDM with a cyclic prefix or a CP-OFDM waveform in the downlink. In the uplink, it uses
both CP-OFDM and DFT-s-OFDM. DFT-s-OFDM is also referred to as transform precoding in 3GPP.
CP-OFDM in the uplink is intended for high throughput on MIMO scenarios, while DFT-s-OFDM
is better for power-limited scenarios due to its power efficiency. Both waveforms will be used in an
orthogonal multiple-access framework.
Transform precoding is controlled by the network. So, for the uplink, the selection between CP-OFDM
and DFT-s-OFDM is done by the network. DFT-s-OFDM is generally used to reduce PAPR and to
improve coverage in uplink coverage-limited scenarios.
The maximum number of carriers used in NR is 3,300. This requires Fast Fourier Transform (FFT)
sizes to go up to 4K, depending on the system bandwidth. The maximum FFT size used for LTE was 2K.
NR numerology
The subcarrier spacing is scalable to the power of 2 of 15 kHz in NR. This is called numerology and
it is represented with µ. The subcarrier spacing is fixed at 15 kHz only in LTE. The reason to choose
the subcarrier spacing as multiples of 15 kHz is to allow for better coexistence between LTE and NR.
It would be much more difficult if a different carrier spacing was selected.
Having different subcarrier spacings allows support for services with different International Mobile
Telecommunications (IMT) 2020 requirements, from high-reliability use cases to low-latency use
cases. 3GPP Release 15 supports the following numerologies for NR.
Figure 4.13 – Supported transmission numerologies for NR
Release 15 supports subcarrier spacings of 15, 30, 60, 120, and 240 kHz with the numerologies 0, 1,
2, 3, and 4 respectively.
The phase noise at high-frequency bands such as Millimeter Wave (mmWave) is bigger than the typical
phase noise that lower frequencies experience. One of the main ways to mitigate this increased phase
noise is to use larger subcarrier spacing. As a result, 15 and 30 kHz will be used for synchronization and
broadcast transmissions below 6 GHz, whereas 15, 30, and 60 kHz will be used for data transmissions
below 6 GHz. Note that 60 kHz subcarrier spacing for below 6 GHz is optional for devices. For
frequency bands above 6 GHz, 120 and 240 kHz will be used for synchronization and broadcast, and
above 60 kHz and 120 kHz for data transmission. A single cyclic prefix length is supported in all cases.
However, normal and extended cyclic prefix lengths can be included for 60 kHz subcarrier spacing.
In the future, specifications will include the data transmission at 240 and 480 kHz for forward-
compatibility purposes. We might also see 3.75 kHz subcarrier spacing in the future as new cases
are introduced.
Illustration of numerologies
The following figure shows an example of the different cyclic prefix lengths and OFDM symbol
lengths for all the supported subcarrier spacings. The lengths are indicated assuming a 4K FFT, as
was mentioned previously.
Figure 4.14 – An illustration of numerologies
There are some basic rules for numerology. The slot length is 1 millisecond in 15 kHz. Note that 15
kHz carrier spacing is the same as LTE for normal CP. This is to support LTE-NR coexistence in the
same radio frequency. As the subcarrier spacing increases, the slot duration halves. We always have
14 OFDM symbols in a slot regardless of the slot duration. There is an exception in 60 kHz subcarrier
spacing with an extended cyclic prefix. As you can see from the preceding diagram, when the extended
cyclic prefix is utilized, the OFDM symbols drop to 12.
All these rules guarantee OFDM symbol alignment between the different numerologies, which will
make multiplexing of different subcarrier spacing both in time and frequency much easier.
Numerology – delay and cell size
Frequency is one factor to consider when choosing numerology. A frequency’s phase noise determines
the minimum subcarrier spacing. The phase noise rises in the high-frequency bands. Therefore, larger
subcarrier spacing is required to compensate for the increased phase noise.
Figure 4.15 – Numerology and cell size
For a given frequency, the required cyclic prefix sets the maximum subcarrier spacing. Slot duration
affects latency based on subcarrier spacing.
Figure 4.16 – Numerology and latency
The use of large subcarrier spacing in small cells is capable of providing very low delays. It is necessary
to use an extended cyclic prefix in large cells.
Mixed numerology
NR supports multiplexing or the mixing of different numerologies, such as TDM and/or FDM in the
downlink and uplink, both in time and frequency. From a device’s perspective, FDM mixed numerology
is limited to data and SSB. NR does not mandate a device to transmit and receive with more than one
numerology at the same time.
There are two use cases for multiplexing numerologies in FDM. The first one is multiplexing data
channels with data channels using different numerologies. This case is not supported in Release 15,
but it will be supported to transmit and receive from a device using two different numerologies in
later releases. However, having the downlink in one numerology and the uplink in another one is
supported in Release 15.
The second use case is the multiplexing of the SS block and the data channels using different numerologies.
This case is optional from a device point of view, as mentioned before. It is important to note that a
device does not have to read both signals at once.
Figure 4.17 – Multiplexing SS block and data channels
Special care must be taken when transmitting and receiving simultaneously using different subcarrier
spacing. The OFDM waveforms for different subcarrier spacings are not always orthogonal with each
other, which means, for instance, a 30 kHz transmission can interfere with a 15 kHz transmission
on the adjacent frequency resources. To mitigate the interference, you can either include relevance
between different numerologies or filter the transmission of the different subcarrier spacings to reduce
the interference caused to adjacent channels. More complex options can be considered as well.
We already mentioned that multiple numerology downlink reception and uplink transmissions are
not supported from a device point of view. However, the gNB can still transmit or receive using
different numerologies to and from different devices. A gNB with good filtering characteristics
between numerologies can assign them close together. In the uplink, there will be no additional RF
requirements for the devices. Therefore, this needs to be considered by the gNB when planning the
uplink resources scheduling between devices using different numerologies.
NR numerology examples
Variable frequency bands and carrier bandwidths are supported by flexible numerology. In the following
diagram, you can observe different NR numerology examples.
Figure 4.18 – Numerology examples
To have large cell sizes and coverage, we should choose lower frequencies. However, larger time
dispersions happen in wide areas with lower frequencies. So, to overcome this situation, larger cyclic
prefixes are needed. Luckily, 15 kHz subcarrier spacing provides us with larger cyclic prefixes (4.7 μs,)
so we can easily choose 15 kHz for wide-area deployments.
Likewise, low- to mid-band frequencies have less time dispersion. Therefore, choosing 30 kHz
subcarrier spacing with a cyclic prefix of 2.4 μs would be enough to deal with fewer time dispersions.
On the other hand, we will also see small cell deployments with higher frequencies – for instance, MM
wave for high capacity. In this case, time dispersion is even less. So, for instance, a cyclic prefix of 0.59
μs would be enough if a 120 kHz subcarrier spacing is utilized. Note that this kind of deployment will
also provide lower latency compared to the other preceding cases, due to the shorter slot duration of
120 kHz subcarrier spacing.
Now, let’s understand the frame structure of NR by comparing it to LTE.
Frame structure
NR uses the same frame duration as LTE, which is 10 milliseconds. The frame is divided into tens
of subframes with 1 millisecond each, as in LTE. At this point, the similarities between LTE and NR
frame structures end.
The NR subframe is not related to the scheduling unit or Transmission Time Interval (TTI), as it
was in LTE. NR just provides a common time reference to which all numerologies can refer, and NR
is assigned to different units, slots, and mini-slots.
Figure 4.19 – NR frame structure
The slots are composed of 14 OFDM symbols, and the slot duration depends on the subcarrier spacing.
The slots are aligned with subframe boundaries, and they are a typical scheduling unit for type A for
PDSCH or PUSCH. Increasing the subcarrier spacing shortens the OFDM symbol duration in time;
hence, it reduces the slot duration accordingly. This can be seen in the preceding figure. A slot at 15
kHz corresponds to 1 millisecond, and the length reduces to the powers of 2 as the subcarrier spacing
increases. So, the number of slots in a subframe changes depending on the subcarrier spacing. This
also influences the TTI length, which can be from 1 millisecond at 15 kHz to 125 microseconds at
120 kHz subcarrier spacings.
A mini-slot is a unit shorter than a slot. It can be either 2, 4, or 7 OFDM symbols and can start at any
symbol boundary. It is a typical scheduling unit for type B for PDSCH or PUSCH.
Let us provide more information to elaborate more on type A and type B scheduling. There is a lot of
similarity between type A scheduling and LTE scheduling, and DMRS uses slot boundaries.
Figure 4.20 – Type A scheduling
In Type B scheduling, the transmission can start at any symbol. The length can range from 1 to 13
OFDM symbols. However, it is limited to 2, 4, and 7 OFDM symbols. DMRS is relative to the start
of the transmission.
Figure 4.21 – Type B scheduling
The slot-based scheduling assigns a slot to devices. The devices monitor the control channels in each
slot and the assignments are always referred to the slot boundaries.
Figure 4.22 – A slot and mini-slot
The device monitors control channels in the mini-slot and assignments are referred to in these mini-
slot boundaries, which can float within the slot, giving more flexibility in time domain assignments.
Mini-slot use cases
One of the motivations to have a non-slot-based scheduling scheme is to support low-latency use
cases. Low-latency traffic can be sent over mini-slots, since they are not required to be aligned with
slot boundaries, as described before. Once the traffic arrives to layer 1, it can start being transmitted
almost immediately without us having to wait for the next slot, which reduces the latency in the process.
The other motivation is having a finer time domain granularity for scheduling operations. This is very
interesting in the case of beamforming and the MM wave for different devices. The gNB can transmit
to one device in one mini-slot and move to another device in the next mini-slot. This process can be
repeated several times within a slot, since mini-slots are shorter than slots.
The third motivation is to support LTE and NR coexistence. When we have LTE and NR in the same
RF frequency, it is important for NR not to overlap with the first three LTE OFDM symbols that carry
the control channels (PDCCH). This can be easily done with the mini-slots. In LTE, it is rather useful
to have Multimedia Broadcast Single Frequency Network (MBSFN) subframes, where some OFDM
symbols are left blank. This has enabled many new features in LTE. So, having the option to schedule
devices in only a limited set of OFDM symbols in a slot will free those OFDM symbols for future use
without breaking compatibility with other devices, and they will support a mini-slot from the beginning.
Finally, this concept is forward-compatible toward an unlicensed spectrum operation.
Resource grid
Up to this point, we have analyzed the NR frame structure in the time domain. Now, let us focus
on the frequency domain. In the frequency domain, a Physical Resource Block (PRB) in NR is
composed of 12 subcarriers, like in LTE. A Resource Element (RE) corresponds to one OFDM
symbol in one subcarrier.
Figure 4.23 – NR resource grid
Note that a PRB in NR is not statically 180 kHz in the frequency domain, like in LTE. In NR, due
to the numerology, as the subcarrier spacing changes, 12 subcarriers will occupy different amounts
of bandwidth.
Figure 4.24 – Minimum and maximum resource blocks changing by numerology
The preceding table indicates the minimum system bandwidth limited by the synchronization signals
and the maximum number of PRBs, 275, which corresponds to 3,300 subcarriers. For the bigger
subcarrier spacing, the limiting factor is not the number of subcarriers but the component carrier
bandwidth, which cannot be more than 400 MHz.
The resource grid changes as the number of available subcarriers and the number of OFDM symbols change.
Figure 4.25 – Overlapping due to subcarrier spacing
All resource grids for each numerology are available at the same time and they overlap, as shown in
the preceding figure.
Duplexing scheme
The duplexing scheme is harmonized in NR. We have Frequency Division Duplex (FDD), static Time
Division Duplex (TDD), and dynamic TDD in NR. These are used for downlink and uplink transmissions.
Figure 4.26 – A harmonized FDD and TDD concept
As a result of harmonizing FDD and TDD, the maximum commonality between FDD and TDD
modes is achieved, which is crucial to LTE/NR coexistence.
We expect to have mainly FDD employment below 3 GHz deployments. For frequencies above 6
GHz, TDD will mainly be used. However, between 3 GHz and 6 GHz, we expect to see a mixture of
FDD and TDD deployments.
Figure 4.27 – FDD/TDD deployments among the frequency band
The slots can be either all downlinks or uplinks, or a mixed combination of the downlink and uplink
resource sets. We typically include a downlink symbol at the beginning of the slot and an uplink
symbol at the end of the slot.
An NR slot can be statically configured using a similar scheme as the uplink/downlink configurations
in LTE TDD. They can be also semi-statically and dynamically configured, meaning that a network
can dynamically and individually change the downlink and uplink direction of the regions in the slot
from one to another.
The transmission direction of data (uplink or downlink) is determined per slot as part of the scheduling
process. The main advantage of dynamic TDD is better spectrum efficiency, since uplink and downlink
resources can be dynamically scheduled based on traffic requirements.
But how are these dynamically changing downlink and uplink slots happening? The Slot Format
Indication (SFI) is defined for that purpose. Now, let us understand what an SFI is.
Slot Format Indication

SFI indicates whether an OFDM signal is configured as a downlink, an uplink, or flexible (also known
as special). Flexible configuration means that the transmission direction of a slot might be either a
downlink or an uplink. This slot format indication can also provide the link direction information
for one or multiple slots. Each device is configured with a table of different possible link direction
assignments, and the SFI will carry an index to that table, which is provided here.
Figure 4.28 – Slot formats – normal CP
SFI can be either dynamic or static. The dynamic SFI is carried over a Downlink Control Information
(DCI) message. This is a separate DCI from the one carrying the downlink and uplink grants. This
Summary 93
could potentially cause inconsistencies between SFIs, because SFI could signal one resource downlink
and the DCI uplink grant could indicate the same resource as an uplink, for instance. Note that a static
or semi-static SFI indication will be provided through Radio Resource Control (RRC) signaling.
In this section, we’ve learned about the OFDM waveform that is used in NR, like in LTE. We’ve also
analyzed the NR numerology that is designed for different NR use case requirements. We’ve also seen
how this scalable numerology affects slot duration and what advantages it brings. Furthermore, we
showed different NR scheduling schemes and slot formats.
Summary
In this chapter, we introduced you to NR general physical layer procedures and channel structure. We
made comparisons of bandwidths, energy efficiency, and spectral efficiency between LTE and NR.
Then, we covered all the important aspects regarding the NR waveform, numerology, and frame
structure. We learned that NR is OFDM-based with scalable subcarrier spacing. This changes the slot
durations to allow for different kinds of services, but it also presents challenges regarding how these
different subcarrier spacings can be multiplexed in the frequency domain without interfering between
them. We have also discovered that NR supports a slot-based scheduling mode. We saw that there are
several interesting use cases that necessitate the introduction of this scheduling mode, such as LTE/NR
coexistence or forward compatibility. Finally, we have described the dynamic TDD duplexing mode
that NR introduces and how it is signaled to devices by using the slot format indication.
In the next chapter, we are going to learn about initial access and management. We will refer to physical
channels and signals frequently to better understand the initial access procedure.
5
The next New Radio (NR) concept that we will cover in this chapter is the initial access to a network
and beam management procedures. These procedures are new to NR, and there is nothing similar
in Long-Term Evolution (LTE), especially for initial access. As we will see during this chapter, both
millimeter wave operation and reducing the number of signals that are always transmitted are the two
main drivers for this initial access procedure design. Upon completion of this chapter, we will understand
the concept of beam sweeping and especially its relationship with Millimeter Wave (mmWave)
frequency. We will focus on how a device and the gNB can identify the best special beams to be used
for transmission. We will also describe the beamforming’s effect on the initial access procedure. Upon
completion of this chapter, we will understand some of the design decisions regarding initial access,
as well as how decisions can enable LTE-NR coexistence in the same radio frequency.
In this chapter, we’ll cover the following topics:
• Initial access and beam management

• Physical channels and signals for the initial access procedure
Initial access and beam management

mmWave operation is noteworthy. It opens frequency bands that were not accessible before – for
example, Frequency Range 2 (FR2), as described in the first chapter. It brings more room for bigger
bandwidth, which enables higher capacity and throughput. However, the transmission of mmWave is
complicated. The path loss of mmWave due to free space propagation is much bigger than the typical
LTE frequency. This culminates in limited cell coverage and cell size. To partially overcome this issue,
directional beams are used on downlink transmission and uplink reception so that the path loss due
to the free space propagation is partially compensated.
Directional transmissions enable new methods of multiplexing different users in the spatial domain,
such as transmitting simultaneously to different directions instead of spatial multiplexing based on
precoders, as with LTE. However, such directional transmissions mean that when connecting to the
network for the first time, it will be challenging for a device to find it. In NR, no omnidirectional
transmission could be assumed like in LTE, especially for mmWave, so directional transmission is
going to be used as described. In the initial access procedure, we must allow for the gNB and the
device to initiate the communication using directional transmissions or beams, without any prior
knowledge of their physical location.
Note
For the sub-6 GHz frequencies, namely Frequency Range 1 (FR1), NR transmissions can be
omnidirectional, like in LTE.
That covers the initial access procedure and its relation to beams. We now know that the NR initial
access procedure must work in a single-beam scenario as well as a multi-beam one, and it must support
LTE-NR coexistence. Now, we will go into more detail about the initial access procedure.
Initial access procedure

The basic procedure consists of the gNB transmitting beams sequentially in multiple directions. The
gNB will use the concept of beam sweeping to transmit both the synchronization signals and the system
information, containing the minimum configuration for a device that needs to access the network.
Eventually, one of these beams or spatial directions is detected by the device, which provides random
access using the same beam direction to the gNB if channel reciprocity exists; if not, it performs beam
sweeping as well. Once the initial communication has been established between the device and the
gNB, the rest of the required system information is sent to the device on a dedicated beam, as shown
in the following figure:
Figure 5.1 – The initial access procedure

Initial access and beam management 97
This is the basic procedure by which communication shifts from a wide coverage scenario into a beam-
sweeping scenario. The beams to be used are further narrowed down once the data transmission is
done through beam refinement procedures.
Here, we have introduced the concept of channel reciprocity. This implies the channel conditions
measured in one link direction can be assumed to be equivalent in the other one, the reciprocal one.
For instance, if the device sees that the gNB downlink transmission is in one spatial direction, it will
assume that the transmitted uplink in the same direction will also be received by the gNB. Note that
this is only true in Time Division Duplex (TDD) systems where the same frequency is used for the
downlink and uplink transmissions.
Beam-sweeping and initial access

As we described during the initial access section, a network will transmit synchronization signals
and basic broadcast information using beam sweeping, as shown in Figure 5.2. In NR, both the
synchronization signals and the broadcast channels, or the Physical Broadcast Channels (PBCHs), are
transmitted in units of four OFDM symbols called Synchronization Signal (SS) blocks. The gNB will
transmit SS block multiplexes in time, and each SS block will use a different beam or a spatial direction
to cover the desired coverage area. Eventually, one of these SS blocks’ spatial direction will be better
suited for communicating with the device, which it will detect. The device will be able to decode the
basic system information that is carried in the SS block, thus initiating the random access procedure.
Figure 5.2 – Beam sweeping
So, the first step in the initial access procedure from a device point of view is identifying the best SS
block within those transmitted by a network. The device must obtain the time index of the received
SS block that uniquely identifies the selected block.
The time index discovery is very crucial because, without any other time reference, the device will
not know where the frame starts and where to transmit random access preambles. That is why all SS
blocks carry a time index indication dividing between the PBCH Demodulation Reference Signal
(DMRS) and explicit indication in the PBCH payload. With this time index information, the device
can completely identify the best SS block.
The device transmits the Physical Random Access Channel (PRACH) on a set of resources that
depend on the time index of the received SS block, by implicitly linking a set of PRACH resources
to a particular SS block. Then, the gNB will know which SS block is received by the device in the
downlink. With that information, the gNB can continue the rest of the initial access procedure in the
same beam spatial direction, as notified implicitly by the device in the PRACH.
On the left pane of the following figure, the gNB is transmitting the SS blocks in different directions.
The device is listening to the network from only one direction, although in a real environment it might
also be a beam-sweeping intersection. Eventually, the gNB’s transmission direction and the device’s
reception direction becomes aligned in such a way that the device can correctly decode the SS block.
Since the device knows the SS block time index, it can derive when and where to send a PRACH
transmission, as shown in the right pane of the figure.
Figure 5.3 – Mapping between DL and UL beam directions when UL/DL reciprocity is reliable
The network knows whether an SS block is transmitted in one spatial direction, and any devices
listening to it transmit the PRACH at a specific time and with a specific set of resources. Hence, the
gNB knows in advance that, at a given time, it must listen for the PRACH in the same direction as
the corresponding SS block in the downlink it sends. This is the assumption for both the gNB and
the device that will enable communication, without any prior knowledge of the physical location of
any of them.
Other remaining system information

As we described before, an SS block carries synchronization signals and the PBCH. The PBCH
contains the minimum system information, but that is not enough for a device to send the PRACH.
More information will be needed. This is where the Remaining Minimum System Information
Initial access and beam management 99
(RMSI) comes in. The RMSI carries all the information that a device requires to access a network,
and the minimum system information in the PBCH contains the basic information the device needs
to decode the RMSI.
The concept of beam sweeping is still used, and for each SS block, there is an RMSI transmitted in the
same direction as the corresponding SS block. The RMSI is carried on the PBCH, as we discussed, and
its configuration and the numerology to be used is contained in the PBCH payload.
The numerology used for RMSI is the following:
• 15 or 30 kHz for frequencies below 6 GHz

• 60 or 120 kHz for frequencies above 6 GHz
A dedicated Control Resource Set (CORESET) is used for delivery of the downlink grant for the
RMSI. More system information is transmitted to a device via the Physical Downlink Shared Channel
(PDSCH), per the device’s demand.
Note that the system information delivery is different from the LTE in the sense that, apart from the
SS block and RMSI, there is no periodic transmission of System Information Blocks (SIB); instead,
the information is provided on a device-specific manner on a demand basis. This reduces the number
of blocked resources due to broadcast information transmission to a minimum. This is also due to
NR having an ultra-lean design.
Message 1, 2, 3, and 4 transmissions

Now, let us discuss how the gNB and a device can transmit synchronization signals and the PRACH
respectively. The random access procedure is based on a four-step approach, as shown in the
following figure:
Figure 5.4 – A four-step random access approach

Note that this was the case for the LTE as well. So, up to four different messages are exchanged in this
procedure. Message 1 (Msg 1) or PRACH defines a random access response window (RAR window),
where the device expects a Message 2 (Msg 2) response from the gNB. After that, Message 3 (Msg
3) and Message 4 (Msg 4) follow with a set of timers that are configured to trigger retransmissions
of the messages, in case they are not received correctly. Let us now analyze the message flows for the
random access procedure in detail.
Msg 1 or PRACH is sent from the device to the gNB to start the random access procedure. Keep in
mind that the different Subcarrier Spacings (SCs and formats are defined for PRACH, and we will
examine them in detail in the next section of this chapter. For the moment, we will imagine that the
subcarrier spacing used in the PRACH by the device is indicated in the RACH configuration of the
RMSI, and we are not interested in the PRACH format. Note also that the beam used by the device at
this point was selected by itself, based on the received SS block in the downlink.
The next message, Msg 2, is sent from the gNB to the device. It uses the same numerology as the
RMSI, and the beam used is derived from the beam that the device used or selected in the PRACH
transmission, as we described earlier.
Then, the device sends Msg 3 to the gNB, using the configured numerology in an RMSI and a device-
selected beam, which will be typically the same as the Msg 1 beam.
Finally, the gNB sends Msg 4 to the device using the same numerology as Msg 2. For the beam to be
used in transmission, there are two options. The first one is that the previous message from the device
to the gNB does not contain any beam report information; in that case, the same beam as Msg 2 is
used. If Msg 3 from the device to the gNB contains beam report information, the gNB can use it to
select a better beam from which to send a message.
The initial access and random access procedures that we described here are part of NR beam management.
Now, we are going to understand what beam management is.
Beam management
Beam management is responsible for maintaining a set of beams in the gNB and a device that can be
used for downlink transmission and uplink reception. This consists of several aspects:
• Beam determination: This concept is defined by what means the gNB or the device selects its
own transmission and reception beams
• Beam measurement: This is used to measure the characteristics of the received beam-formed signals
• Beam reporting: This is used by the device to report to the gNB information about the received
beamforming signals, obtained through the previous beam measurement
• Beam sweeping: As we already know, this is the operation intended to cover a special area,
with beams transmitted during a time interval in a predetermined way
Physical channels and signals for the initial access procedure 101
For these purposes, devices in idle mode will use the signals in the SS block. For connected devices,
beam management is based on a Channel State Information Reference Signal (CSI-RS) in the
downlink and Sounding Reference Signals (SRS) in the uplink. This also indicates that those signals
must support beam sweeping, and the beam report will contain the measurement results from them.
Multi-beam operations and FDM
Working in a multi-beaming scenario as we are currently doing can potentially force a device to receive
and transmit simultaneously in two different spatial directions. For Release 15, devices will not be
mandated to support this operation, since typical device implementation at first will have a single
panel. From a device point of view, it cannot, for instance, measure SS blocks on one beam and then
receive the PBCH on a different beam. Note that this is only from the device’s point of view. From a
gNB point of view, nothing prevents it from transmitting on two different devices simultaneously in
different spatial directions if it supports it.
So far, we have covered the initial access procedure and its relationship with beam sweeping and beam
management. Now, we will observe the role of some physical channels and synchronization signals
in the initial access procedure.
Physical channels and signals for the initial access

procedure
We have covered the general aspects of the initial access procedure. In this section, we will be discussing
the details of how the SS blocks and the PRACH are defined. The channels that define SS block are
the Primary Synchronization Signal (PSS) and Secondary Synchronization Signal (SSS), and they
are placed at the PBCH. These downlink signals are the only ones that are periodically transmitted in
NR. Note that they can be turned off by the network thanks to NR’s ultra-lean design.
As we emphasized, coexistence and forward compatibility with LTE are crucial for NR. To achieve this,
it is necessary to have as few blocked resources as possible. So, even though SS block transmission is
periodic, having the option to turn off certain SS block locations or opportunities will help the network
avoid interference with LTE or other featured services.
SS block
The SS block is composed of four consecutive OFDM symbols that contain one symbol for PSS,
another symbol for SSS, and two symbols for the PBCH. The SS blocks are grouped in SS bursts and
those are grouped again in SS burst sets. The SS burst set is periodically transmitted at each system
default value of 20 milliseconds, and all the SS blocks are contained in 5-millisecond windows at the
beginning of the 20-millisecond period, as shown in the following figure:
Figure 5.5 – SS blocks in SS bursts
Each of these SS blocks can be transmitted over different spatial directions to implement the beam-
sweeping technique we described earlier. This is represented on the right hand of the preceding diagram.
Now, we will continue going into more detail about the SS block. First, we will give a definition of the
SS burst set, and then we will discuss its composition, mapping locations, and SS block utilization in
LTE-NR coexistence.
SS burst set definition
So, as we saw in the previous figure, all SS blocks are confined in a 5-millisecond period that repeats
every 20 milliseconds. This is the default periodicity that each device will assume. This indicates that
a network can change periodicity to another value, but the devices that have not accessed the network
yet will have to assume this periodicity as 20 milliseconds. Once the devices are connected, they will
be notified of the actual value set by the gNB. The same happens in the case of the network turning
off certain SS blocks.
The number of SS blocks that are periodically repeated depends on the frequency band. For frequencies
less than 3 GHz, there are only four SS blocks in an SS burst set supported. Between 3 GHz and 6
GHz 8 SS blocks are supported in an SS burst set and this number is increased to 64 for mmWave.
The underlying reason for this is that as the frequency increases, the likelihood of using beamforming
increases. In the case of mmWave, a significant amount of SS blocks may be needed so that many
spatial directions can be used to accommodate the desirable beamforming pattern.
Frequency Range Max SS Blocks per SS Burst Set (L)

<3 GHz 4
3-6 GHz 6
mmWave 64
Table 5.1 – Supported SS blocks in SS burst sets
The different channels in the SS blocks are multiplexed in time. The frequency location of the SS
block is not fixed and can be located anywhere within the carrier bandwidth. This frequency location
of the SS block cannot even be aligned to Physical Resource Blocks (PRB). This, together with the
Bandwidth Part (BWP) concept that we will discuss in the next chapter, gives us a lot of flexibility
in defining a cell.
In NR, the SS block can be located in any position in the frequency domain in contrast to LTE, where
synchronization signals are located in the center of the spectrum. Several simultaneous transmissions
of SS blocks in different frequency resources are also possible. The use case for this is about how devices
can access a network in NR. In LTE, all devices must support the maximum 20 MHz bandwidth;
however, this is not the case for NR.
Any device, no matter the supported minimum bandwidth, can access a network, no matter what the cell
bandwidth is. Also, depending on a device chipset’s processing capabilities, it could potentially access
the network as a single carrier or as intra-band contiguous Carrier Aggregation (CA). For instance,
a device can access a 400 MHz cell as a single cell with 400 MHz bandwidth or as four contiguous
Component Carriers (CCs), as each one of them is 100 MHz. For this last case, a different set of SS
blocks can be configured for each of the 100 MHz CCs, so the devices accessing the network in this
CA mode can consider each of these CCs.
SS block composition
Now, we will take a deeper look at the SS block structure. As shown in the following figure, the SS
block is composed of four consecutive OFDM symbols that span over 20 PRBs.
Figure 5.6 – A detailed SS block structure

The PSS is transmitted on the central 127 subcarriers of the SS block in the first OFDM symbol. The
SSS is transmitted in the same resource elements or subcarriers in the third OFDM symbol. The
PBCH uses the entire 20 PRBs of the second and fourth OFDM symbols, as well as four PRBs at each
side of the SSS symbol.
The devices perform matched filtering to find PSS. PSS and SSS together indicate an Physical Cell
ID (PCI):
• 3 x SSS [range is {0, 1….335}] + PSS [range is {0, 1, 2}] = 1,008 PCIs [range is {0, 1….1,007}]
The SS block has a frequency offset to the Common Resource Block (CRB) grid. The device is informed
of the offset or is given the Absolute Radio-Frequency Channel Number (ARFCN).
As mentioned before, the SS block is sent periodically, and its default value is 20 milliseconds. It is
possible to sweep the SS block with different indexes in different beams.
Devices decode the Master Information Block (MIB) in the PBCH.
SS block mapping locations
Now, we will see the location in time of different SS blocks for the case of frequency bands below 6
GHz. If you recall from the beginning of the section, the SS blocks for below 6 GHz are transmitted
with either 15 kHz or 30 kHz subcarrier spacing. For both cases, there are two SS block positions in
each slot, as shown in the following figure:
Figure 5.7 – SS block mapping locations – below 6 GHz (FR1)
In the 15 kHz case, the slot duration is 1 millisecond, and two possible SS block positions can be seen
in the figure. In the 30 kHz case, the slot duration is 500 microseconds. So, two SS block locations are
possible in this period. As you can see in the preceding figure, there are two different mappings for
30 kHz. The second one is intended for low-latency use cases. It has an empty pair of OFDM symbols
within SS blocks, which allows downlink and uplink transmissions for low-latency scenarios.
SS block locations show an alteration for frequencies above 6 GHz. The following figure presents the
SS block locations in a slot for the 120 kHz and 240 kHz subcarrier spacings:
Figure 5.8 – SS block mapping locations – above 6 GHz (FR2)
In 120 kHz, we have two SS block locations in a 125 microseconds slot, whereas we can see 4 SS block
locations in the case of 240 kHz.
SS blocks for LTE-NR coexistence
What we mean by LTE and NR coexistence is providing LTE and NR networks at the same RF frequency
and that share the same bandwidth. This coexistence requires that NR SS blocks shall not collide with
LTE cell reference signals; otherwise, this would create interference. This is crucial for the sake of LTE
network performance. The 30 kHz subcarrier spacing case is the only one that can guarantee that no
interference occurs between NR SS blocks and LTE cell reference signals.
Figure 5.9 – The SS block for LTE-NR coexistence
The preceding figure shows the 30 kHz mapping during 1 millisecond of the LTE subframe, and in
red, you can see the locations of the LTE cell reference signals. Recall from the previous chapter that
for LTE, µ=0 has a subcarrier spacing of 15 kHz. The yellow SS block will not interfere with the LTE
cell reference signals, while, in contrast, the green one does interfere. Therefore, the gNB must turn
it off to avoid interference. This is the underlying reason for the LTE-NR coexistence requirement
that we mentioned.
In a nutshell, LTE and NR coexistence forces the SS block to use 30 kHz subcarrier spacing, and the
gNB must turn off any colliding SS blocks with LTE cell reference signals. A consequence of this is
that LTE-NR coexistence requires a minimum bandwidth of 10 MHz, since this is the bandwidth used
by the SS block at this 30 kHz subcarrier spacing.
SS burst set composition
In the following figure, the SS block locations are displayed relative to a 5-millisecond window. Blue
and orange colors indicate the slots containing two SS blocks, whereas the green and yellow colors
show a set of two slots containing four SS blocks in this time window.
Figure 5.10 – SS burst set composition
As we detailed in previous sections, below 6 GHz, we have a total of either four or eight SS blocks,
depending on exactly which frequency band is used, and above 6 GHz, we have a total amount of 64
SS blocks.
SS block time index indication
We saw that the SS blocks are transmitted using beam sweeping. If we recall the beginning of this
section, it is important to identify these SS blocks with the time indexes so that devices can derive
the resources to transmit the PRACH.
In NR, three bits of the SS block time index will be carried out by selecting the PBCH DMRS sequence.
This is enough for the following 6 GHz case, where the number of SS blocks in an SS burst set is eight
or less. For higher frequencies, up to 64 SS blocks can be transmitted. In that case, we need three extra
bits where those bits are signaled explicitly in the PBCH payload.
Now that we understand the details of an SS block structure, we will now provide a brief overview of
the different channels that composed SS blocks. We will start with the PSS and the SSS.
PSS and SSS

PSS and SSS are mapped to 127 consecutive subcarriers in the first and third OFDM symbols in the
SS block respectively. Their center frequency is aligned with the center frequency of the PBCH.
Figure 5.11 – PSS and SSS mapping
PSS is a 3 length 127 M sequences, and it is created by cyclic shifts of a basic M sequence. SS is 336
length 127 M sequences with the addition of two M sequences. The following figure represents how
this sequencing works:
Figure 5.12 – Sequencing
After the detection of PSS and SSS, the device knows the PCI and the timing of the PBCH.
Figure 5.13 – A cell search flow diagram

As described previously, PSS and SSS are used for cell search. The preceding figure represents the cell
search flow diagram. The device first detects the SS block SCS and the frequency. Then, it gets the
SSS symbol timing and the cell ID, which can be 0, 1, or 2. Later, the device detects the cell ID group
that comes from SSS.
Now, it is time to discuss the PBCH, which is the other part that composes the SS block.
PBCH definition
The PBCH is broadcasted as part of the SS block. This is the last channel that composes the SS block.
Moreover, the PBCH, PSS, and SSS are transmitted on the same antenna port using a single antenna
transmission scheme. Sample data that the PBCH carries is represented in the following figure:
Figure 5.14 – Sample PBCH data
The PBCH transmission time interval is 80 milliseconds and its payload is 56 bits, including the CRC.
This is enough for the minimum system information, as we described before. Those bits are channel-
encoded using the polar coding scheme. In the next chapter, we will discuss further channel coding
schemes that NR uses in more detail.
MIB
Recall that the PBCH carries the MIB for devices to decode. The 3rd Generation Partnership Project
(3GPP) describes the MIB, as shown in the following figure:
Figure 5.15 – MIB
A device gets the following information through decoding:
• A System Frame Number (SFN)

• Subcarrier spacing for initial access
• The SS block subcarrier offset
• The DMRS type A position
• If the cell is barred
Now, we will see how the resource element mapping occurs for the PBCH.
PBCH resource element mapping
The following figure shows the basic processing chain for the PBCH. The payload will go through
two different scrambling operations. The first one happens before encoding, whereas the second one
happens after decoding.
Figure 5.16 – PBCH resource element mapping
The first scrambling is initialized based on the cell ID and the system frame number. The second
scrambling is initialized based on the cell ID and the SS block time index.
The last channel that we will discuss in this section is the PRACH.
Random access preamble – the PRACH

As in LTE, the PRACH is based on Zadoff-Chu-based sequences. Two different PRACH types are
defined in NR, long-sequence (L=839) and short-sequence (L=139).
The long-sequence PRACH is only used below 6 GHz and it is composed of long sequences in time,
with low subcarrier spacing. In this case, 1.25 kHz subcarrier spacing with a bandwidth of 1.25 MHz
and 5 kHz subcarrier spacing with a bandwidth of 5 MHz are used.
Figure 5.17 – Long-sequence PRACH formats
Four different formats are defined for the long-sequence PRACH. As we realized, this format has a
small subcarrier spacing and lasts a very long time. The long-sequence PRACH originates from the
LTE preambles. A long-sequence PRACH consists of a Cyclic Prefix (CP), followed by one or more
sequences, and finishing with a guard period to align to the slot boundaries.
Figure 5.18 – The long-sequence PRACH structure
Since the subcarrier spacing is larger, the slot duration is shorter. This makes a long-sequence PRACH
extremely useful in frequency bands above 6 GHz in combination with beam sweeping.
The main difference between the short-sequence and long-sequence PRACH types is that the subcarrier
spacing is much higher in a short-sequence PRACH. 15 kHz and 30 kHz subcarrier spacings below
6 GHz frequency and 60 kHz and 120 kHz subcarrier spacings above 6 GHz are used.
Format Numerology Number CP length Preamble length

of repetitions (not incl. CP)
A1 2 9.4 µs 133 µs
A2 4 18.7 µs 267 µs
A3 6 28.1 µs 400 µs
B1 2 7.0 µs 133 µs
B2 15/30/60/120 4 11.7 µs 267 µs
B3 6 16.4 µs 400 µs
B4 12 30.5 µs 800 µs
C0 1 40.4 µs 66.7 µs
C2 4 66.7 µs 267 µs
Table 5.2 – Short-sequence PRACH formats

The short PRACH structure is essentially the same as the long one, with a CP, followed by a repetition
of PRACH sequences, and ending with a guard period, as shown in the following figure:
Figure 5.19 – The short-sequence PRACH structure
The PRACH and subcarrier spacing combinations are presented in the following figure for convenience.
Figure 5.20 – PRACH and SCS combinations
In this detailed table, you can find the allocated bandwidth, which is expressed in the number of RBs
for PUSCH and the subcarrier index.
Summary 113
Format lRA ΔƒRA Νu Ν

RA Support for
CP restricted sets
0 839 1.25 kHz 24576K 3168K Type A, Type B
1 839 1.25 kHz 2.24576K 21024K Type A, Type B
2 839 1.25 kHz 4.24576K 4688K Type A, Type B
3 839 5 kHz 4.6144K 3168K Type A, Type B
Format lRA ΔƒRA Νu Ν

RA Support for
CP restricted sets
A1 139 15.2µ kHz 2. 2048K . 2 –µ 288K . 2 –µ −
A2 139 15.2µ kHz 4. 2048K . 2 –µ 576K . 2 –µ −
A3 139 15.2µ kHz 6. 2048K . 2 –µ 864K . 2 –µ −
B1 139 15.2µ kHz 2. 2048K . 2 –µ 216K . 2 –µ −
B2 139 15.2µ kHz 4. 2048K . 2 –µ 360K . 2 –µ −
B3 139 15.2µ kHz 6. 2048K . 2 –µ 504K . 2 –µ −
B4 139 15.2µ kHz 12 2048K . 2 –µ 936K . 2 –µ −
C0 139 15.2µ kHz 20 48K . 2 –µ 1240K . 2 –µ −
C2 139 15.2µ kHz 4. 2048K . 2 –µ 2048K . 2 –µ −
Table 5.3 – PRACH and SCS combinations
The preceding table above shows the length of the sequences, the number of repeated sequences, the
used subcarriers, the subcarrier spacings, the length of the cyclic prefixes, and their formulas, where
ĸ is taken as 64 in the calculations.
In this section, we analyzed physical channels and signals playing a role in the initial access procedure.
We examined in detail the SS block, PSS/SSS, and PBCH. Then, we saw a random access preamble,
which is basically the PRACH. We finished the section by analyzing and comparing short- and long-
sequence PRACH formats.
Summary
In this chapter, we learned that beam sweeping is required when operating at an mmWave frequency.
The use of beam sweeping affects the synchronization signals and PRACH design, since the initial
access procedure must account for the directionality of the transmissions.
We have seen how identifying this SS block transmission in each beam with different time indexes
and linking the PRACH resources to these indexes helps in this procedure. This directional aspect of
the transmission is new to NR.
Finally, we have also gone through some of the considerations about LTE-NR coexistence, especially
how the SS block transmissions can utilize 30 kHz subcarrier spacing to avoid interference with the
LTE cell-specific reference signals.
In the next chapter, we will detail the remaining downlink and uplink physical channels and signals. We
will analyze one of the other different concepts of NR, which is called the PDCCH Control Resource
Set (CORESET). We will also see different channel coding schemes, such as a Low-Density Parity
Check (LDPC) and polar coding. Then, we will examine another new concept, bandwidth parts, and
their related use cases.
6
Regarding physical channels, we have discussed the Primary Synchronization Signal (PSS), Secondary
Synchronization Signal (SSS), and Physical Broadcast Channel (PBCH) in the downlink, as well
as the Physical Random Access Channel (PRACH) in the uplink, in the previous chapter. In this
section, we will go through the rest of the New Radio (NR) physical channels and other aspects related
to physical layer procedures. Briefly, we will cover the different channel coding schemes used for NR,
and we will go through the processing chain of the downlink and uplink data channels. In this chapter,
we will pay particular attention to how the channel structure is changed to allow for lower-latency use
cases and how lower latency impacts the operation of Enhanced Mobile Broadband (eMBB) data
traffic. Finally, we will discuss Bandwidth Parts (BWPs).
• Downlink physical channels and signals

• Uplink physical channels and signals
• Channel coding schemes
• BWPs
Now, let’s start with the downlink physical channels and signals.
Downlink physical channels and signals

NR defines a similar set of physical channels to Long-Term Evolution (LTE). We already covered the
PSS, SSS, and PBCH. In this section, we will cover the Physical Downlink Control Channel (PDCCH),
the Physical Downlink Shared Channel (PDSCH), as well as the Channel State Information
Reference Signal (CSI-RS). The Tracking Reference Signal (TRS) and Phase Tracking Reference
Signal (PTRS) are new reference signals that have been introduced in NR – we will see what they are
used for. Let’s learn about the PDCCH.
The PDCCH
In NR, the PDCCH carries the Downlink Control Information (DCI), like LTE. The modulation
used for the channel is Quadrature Phase Shift Keying (QPSK) and the Radio Network Temporary
Identifier (RNTI) masks the DCI Cyclic Redundancy Check (CRC) bits as it was done in LTE.
The PDCCH is divided into Control Channel Elements (CCEs) in NR. Each CCE is composed of
six Resource Element Groups (REGs), where each REG is composed of one Physical Resource
Block (PRB) in one Orthogonal Frequency Division Multiplexing (OFDM) symbol. The PDCCH
is encoded in several CCEs depending on the aggregation level used. The PDCCH uses a one-port
transmit diversity scheme in which the REG bundling is applied per CCE. The device can assume
that the same precoder is applied to a set of REGs within a REG bundle.
PDCCH CORESETs
The set of resources to which a PDCCH can be mapped is called a Control Resource Set (CORESET).
It is equivalent to the control region in LTE. A CORESET contains a set of REGs, and it is configured
by the network using Radio Resource Control (RRC) signaling.
Figure 6.1 – A PDCCH CORESET
The CORESET configuration consists of the frequency domain resources to use the starting OFDM
symbol and the time duration. This configuration provided by the network can be device-specific
and the CORESET defines the cell search space for the device to use to monitor the control channels.
This is the main difference between it and LTE. In LTE, the control region was located at the first
three OFDM symbols and was shared between all users in the service area. In NR, the control region
Downlink physical channels and signals 117
is defined specifically for each device. Additionally, this adds flexibility to resource control allocation
and allows devices not capable of running at maximum bandwidth to operate. A device with a smaller
bandwidth support can be also configured so that the CORESET spans only on supported bandwidth.
Group-Common PDCCH
A special case of PDCCH is a Group-Common PDCCH. This is a PDCCH intended for a group of
devices. First, it carries the Slot Format Indicator (SFI). As discussed in the previous chapters, the
SFI indicates which OFDM symbols in a slot are configured as downlink, uplink, or flexible. Second,
it carries the Preemption Indicator (PI). This is related to low-latency traffic. We will discuss this
further in this chapter.
So far, we have covered the control channel for the downlink. Now, let’s analyze the shared channel.
The PDSCH
Now that we have briefly described the PDCCH, which is mainly used for scheduling decisions
required for the downlink data channel, the PDSCH, let’s have a look at the PDSCH. The general
aspects of this channel are similar to LTE. It carries user data. The modulated symbols are mapped
across layers associated with the codeword first, followed by subcarriers, and lastly OFDM symbols.
The supported modulations in NR are QPSK, 16 Quadrature Amplitude Modulation (QAM), 64
QAM, and 256 QAM.
PDSCH is rate-matched around Synchronization Signal Blocks (SS blocks) and CORESETs in case its
transmission overlaps with them. If there is an overlap with an SS block, the network can specifically
indicate to a device whether the PDSCH is rate-matched around an SS block or not. This is related to
the fact that the gNB may choose not to transmit some SS blocks, as we mentioned in previous chapters.
PDSCH DMRS
One difference between LTE and PDSCH mapping is the position of the Demodulation Reference
Signal (DMRS). In NR, the PDSCH DMRS is front-loaded. This means that DMRS is located very
early in the slot. Thus, a device can make a channel quality estimation sooner and start decoding very
early in the slot transmission, which results in reduced latency.
There are two mapping types for the modulation reference signals, namely, DMRS mapping Type A
and DMRS mapping Type B. Type A uses slot-based scheduling. In Type A, the DMRS OFDM symbol
is fixed regardless of the PDSCH assignment, and it is configurable between OFDM symbols 2 and 3.
In Type B, the first OFDM symbol is assigned to the PDSCH:
Figure 6.2 – PDSCH mapping Type A
Type B employs non-slot-based scheduling in which assignments are not referred to the slot boundaries.
This makes it impossible to use a fixed location for the DMRS in the slot due to the mini slots, which
can be assigned anywhere in the slot.
Figure 6.3 – PDSCH mapping Type B
If a single channel estimation at the beginning of a slot is not enough – for example, in high-speed
mobility scenarios – additional DMRS symbols can be configured. This is the case, for instance, for a
PDSCH that carries broadcast information, Remaining Minimum System Information (RMSI), or
multicast information. The gNB will have to transmit this information to many devices and it will not
know which devices are in high-speed or not, so it will use these extra DMRS symbols as a precaution.
Now, we will cover other PDSCH-related aspects.
The PDSCH processing chain
The following figure indicates the processing chain for the PDSCH. It is very similar to LTE. The PDSCH
supports up to two codewords, which are scrambled, modulated, and then mapped onto layers. The
layers are then mapped onto the Resource Elements (REs), together with the DMRS, and transmitted:
Figure 6.4 – The PDSCH processing chain
Notice that there is no precoder defined as in LTE transmission mode 9, for instance. Depending on
the device feedback, the gNB employs a suitable precoder, which is applied to both data and DMRS.
PDSCH eMBB and URLLC multiplexing

So, we have covered the basic structure of the downlink data channel for NR. We have talked about
multiplexing the eMBB traffic with the low-latency traffic. Both are carried onto the PDSCH. We
already discussed that low-latency transmissions are typically done using mini slots, which allows
the transmissions to start without having to wait for a slot boundary.
In NR, it is possible to share resources between eMBB and low-latency traffic. This can happen in
two ways. The first one is preemption. This allows low-latency traffic to be transmitted while eMBB
traffic is on the air, sharing the same resources dynamically with the eMBB traffic. The second way is
to assign the low-latency traffic to frequency resources that don’t overlap with the eMBB traffic. Both
options are optionally indicated to all devices receiving the original eMBB traffic.
Downlink PIs
In the following figure, we have an example of eMBB traffic being preempted by low-latency traffic. A
device receives the eMBB slot and suddenly a mini slot is scheduled with some low-latency mission-
critical traffic. The situation is flagged to the device using the PI in either the same or a later slot. Why
is that useful? Well, if the device knows that an OFDM symbol was punctured by other traffic, it can
just skip decoding the affected code blocks and save power and processing time.
Figure 6.5 – A downlink PI
There is a minimum processing time called N1, which defines the minimum processing time in the
device to send the Hybrid Automatic Repeat Request (HARQ) feedback. The device notifies the
gNB about N1 time and the PI is given afterward.
Now, let’s move to the next downlink physical signal, the CSI-RS.
CSI-RS and CSI reports

A CSI-RS is used for two main purposes: CSI acquisition and beam management. For CSI acquisition,
they are used to measure the channel characteristics and to report that information back to the gNB.
Thus, it can be taken into account when scheduling downlink data. For beam management, it provides a
way for the device to measure different downlink beams and report the measurements back to the gNB.
So, the CSI-RS is used by the device for channel and beam measurements and to report the CSI feedback
to the gNB. This feedback can be of two different types – normal or enhanced. The normal feedback
is similar to that of LTE. The channel matrix is reported using a set of Precoding Matrix Indicators
(PMIs) with normal spatial resolution. The enhanced CSI feedback type allows for higher resolution
or explicit channel matrix reporting. This latter feedback type is crucial. Better CSI feedback means
better channel estimation for the gNB, which results in efficient downlink scheduling.
NR and LTE, under the same conditions, for instance, with 15 kHz subcarrier spacing and 20 MHz
bandwidth at the same frequency band, will perform similarly with normal CSI feedback. However,
enhanced CSI feedback allows NR to outperform LTE under the same conditions.
Mapping the CSI-RS to antennas
The CSI-RS is mapped to antenna ports and antenna ports are mapped to physical antennas. However,
the details of mapping are not specified:
Figure 6.6 – CSI-RS antenna mapping
The implementation-specific relation is modeled by the F matrix here. The device estimates the
composite channel, including F. Quasi-Colocation (QCL) relations describe what assumptions the
device may make about F.
Let’s move to the next downlink physical signal, the TRS, which is new in NR.
The TRS
NR has no Cell Specific Reference Signal (CRS) to use for fine time-frequency tracking. Therefore,
the TRS is employed to track time, frequency, delay spread, and Doppler spread more efficiently. The
TRS is managed as device-specific. An example of the TRS format is illustrated here:
Figure 6.7 – TRS format example

A TRS can be configured in different ways. For instance, it can consist of bursts of four consecutive
OFDM symbols in two consecutive slots. Another typical configuration is a TRS burst of two TRS
symbols in two adjacent slots.
Let’s move to the next downlink physical signal, PTRS, which is also new in NR.
PTRS
A device can be configured in downlink and uplink with PTRS to track phase variations, mainly for
high bands:
Figure 6.8 – PTRS occurring every second PRB and every symbol
PTRS is dense in time and occurs every second or every fourth symbol depending on the scheduled
Modulation and Coding Scheme (MCS). PTRS is sparse in frequency and exists for one subcarrier
every second or every fourth PRB depending on the scheduled BW. PTRS is not presented at low
scheduled MCSs and bandwidths or for random access, System Information (SI), and paging messages.
In this section, we’ve covered the downlink physical channels, PDCCH, PDSCH, and some of their
aspects, together with the downlink physical channels such as CSI-RS, TRS, and PTRS. In the next
section, we will cover the physical channels and signals in the uplink.
Uplink physical channels and signals

Now, let’s have a look at the physical uplink channels and signals. In previous chapters, we covered
the PRACH and Sounding Reference Signals (SRS). In this section, we will learn the physical uplink
control and data channels, and signals such as the Physical Uplink Shared Channel (PUSCH), PUSCH
Demodulation Reference Signal (DMRS), and Physical Uplink Control Channel (PUCCH). Let’s
start with the PUSCH.
The PUSCH
The PUSCH carries data and also optionally Uplink Control Information (UCI). As we described
before in previous chapters, the uplink waveform can be either Cyclic Prefix OFDM (CP-OFDM) or
Discrete Fourier Transform-Spread-OFDM (DFT-s-OFDM). The waveform to be used is signaled
to the device by the network. DFT-s-OFDM is only used for single-layer transmissions, and it is
intended for power-limited scenarios. This waveform also supports intra-slot frequency hopping for
more diversity.
As in the downlink case, PUSCH mapping is done in the same order as in LTE; first, across the layers
associated with the codeword, then across the subcarriers, and, finally, across the OFDM symbols.
The PUSCH uses the same modulation as the downlink with the exception that Binary Phase Shift
Keying (pi/2-BPSK) can be employed for DFT-s-OFDM. The intention is to provide more Peak-to-
Average Power Ratio (PAPR) gain for the waveform.
The uplink transmission can be either codebook-based or non-codebook-based, and the transmission
can be grant-based or grant-free. A grant-based transmission is a transmission signaled by the network
using the corresponding DCI. A grant-free transmission is an uplink transmission made automatically
by the device without any explicit prior grant being transmitted in the downlink.
Grant-free transmissions are crucial for low latency. In a normal scenario, a device requests an uplink
data transmission using a Scheduling Request (SR) and then waits for the gNB to deliver an uplink
grant. With grant-free transmission, the device can send data in the uplink once it is available. There
are two types of grant-free transmissions: Type 1 and Type 2. In both cases, the set of resources that
the device can use for uplink transmissions is configured semi-statically via RRC. In Type 1, there is
no Layer 1 (L1) signaling while in Type 2, additional L1 signaling is required to activate or deactivate
the resources configured for this grant-free transmission.
The PUSCH DMRS
The PUSCH reference signal structure is similar to the downlink case. The DMRS is front-loaded and
additional OFDM symbols can be configured for high-mobility cases. The only difference is that the
DMRS sequence itself changes depending on the waveform. For CP-OFDM, it is the same as in the
downlink, and for DFT-OFDM, it is a Zadoff-Chu-based sequence.
The PUSCH processing chain
The following figure shows the PUSCH coding chain for the CP-OFDM waveform. It is very similar
to the downlink case. The only difference, in this case, is that the precoder is included after the layer
mapping. The precoder to be used in the uplink is explicitly included in the specification. One of the
reasons is Multi-User Multiple Input Multiple Output (MU-MIMO). When the gNB configures
MU-MIMO, it must coordinate the precoders between different devices so that the data streams for
each one can be correctly separated:
Figure 6.9 – PUSCH processing chain for the CP-OFDM
In the downlink, this is not a problem. The gNB has total freedom in defining the precoders and then
coordinating them accordingly. However, if freedom was given to the devices in the uplink, that would
be impossible. To make uplink transmissions from different devices, we use precoders that enable
MU-MIMO. The precoder that a device uses must be explicitly indicated:
Figure 6.10 – PUSCH processing chain for the DFT-s-OFDM
The figure here shows the same coding chain for the DFT-s-OFDM. The transform precoder is inserted
between the layer mapper and the precoding. Notice that only one codeword is used in this case.
Now that we have covered the PUSCH, PUSCH DMRS, and the processing chain for different OFDM
schemes in the uplink, the last physical channel we are going to cover in the uplink is the PUCCH.
The PUCCH
The PUCCH carries UCI, HARQ feedback, and SR. Two different PUCCHs are defined; long and
short. The long PUCCH spans over many OFDM symbols while the short PUCCH uses only one or
two OFDM symbols.
PUCCH Format Length in OFDM Symbols Number of Bits

0 (SHORT) 1-2 ≤2
1 (LONG) 4-14 ≤2
2 (SHORT) 1-2 >2
3 (LONG) 4-14 > 2, < N
4 (LONG) 4-14 >N
In the table presented here, you can see different PUCCH formats divided between long and short
PUCCH formats and classified as a function of the supported number of information bits.
The short PUCCH
Format 0 for the PUCCH is a short PUCCH for up to two information bits. This PUCCH is based on
sequence selection, which means that the bits are not modulated in the signal. Instead, four different
12 subcarrier sequences are defined and the sequence that is used depends on the information bits.
Figure 6.11 – PUCCH format 0
In the figure here, you can see four PUCCH sequences with the information bits presented.
Format 2 for the PUCCH is another short PUCCH with no multiplexing in the same PRB, and
contiguous PRB allocation. The DMRS is mapped on REs 1, 4, 7, and 10 for each PRB. In the figure
here, you can see where the DMRS is mapped in a PRB used for this PUCCH format.
The long PUCCH
Format 1 is a long PUCCH used with two bits or fewer. This format uses 12 subcarriers, and it is
between 4 and 12 OFDM symbols. Information bits are modulated onto a single modulated symbol,
which is spread using a Zadoff-Chu sequence for each OFDM symbol. The DMRS is introduced in
every other symbol in the time domain, as can be seen from the following figure:

Formats 3 and 4 are the remaining long PUCCH formats. These can be configured with intra-slot
frequency hopping for more diversity and can span over more than one slot with inter-slot frequency
hopping, which is optionally available.
In this section, we’ve covered the downlink physical channels, PUSCH and PUCCH, and some of their
aspects. Thereby, we have covered the main physical channels and signals in the downlink and uplink.
To complete the physical layer description, we also need to consider the channel coding schemes.
Channel coding schemes

Low-Density Parity Check (LDPC) code is used for eMBB physical data channels in which polar
codes are employed for eMBB physical control channels, as well as for the PBCH. These channel coding
schemes provide better throughput and latency performance compared to what we have in legacy
LTE. Note that channel coding for other use cases such as massive Machine Type Communications
(mMTC) and Ultra-Reliable Low Latency Communications (URLLC) are not part of Release 15’s
scope. So, let’s start.
Transport channel coding chains

The following figure represents the basic coding scheme for the downlink shared channel. The diagram
is very similar to what we have in LTE. A CRC is attached to the transport block, it is segmented onto
the code blocks, and then, additional CRSes are attached to each code block:
Channel coding schemes 129
Figure 6.14 – Transport channel coding for the downlink shared channel
Then, LDPC coding is performed for each code block and the last steps are rate matching, interleaving,
and concatenating those code blocks.
Figure 6.15 – Transport channel coding for an uplink shared channel

The same applies to the uplink with the exception that UCI can be piggybacked on the PUSCH as was
the case in LTE. In that case, there is an extra Data and Control Multiplexing operation as shown
in the figure here.
Data retransmissions
Now that we understand the transport channel coding chains in NR, let’s compare LTE and NR
regarding transport block retransmissions.
Code Block Group (CBG)-based retransmissions
One of the main differences between data retransmissions in NR and LTE is the addition of CBG-based
retransmissions to NR. In NR, it is possible to only retransmit the code blocks that failed at the decoding
stage, rather than the entire transport block. This saves resources during retransmission and improves
latency since the processing time of the older retransmissions will be shorter because only a few of
the originally transmitted code blocks will be decoded:
Figure 6.16 – CBG-based retransmissions
The DCI includes information not only about the group of code blocks that is retransmitted but also
the soft buffer. When processing the error retransmission, the new information received is traditionally
combined with the previous original transmission. This combining scheme works if the codeword
was retransmitted due to the Signal to Interference and Noise Ratio (SINR).
If the original transmission fails since it is pre-empted by low-latency traffic, then the information
from the original transmission does not correspond to the retransmission. In that case, it is better to
flush the previously received information from the soft buffers rather than using a combining scheme
because it corresponds to the low-latency traffic.
The HARQ principle
NR supports adaptive and asynchronous HARQ in both the downlink and uplink:
BWPs 131
Figure 6.17 – A HARQ process
The number of HARQ processes is configured to the device with at most 16 HARQ processes:
15 kHz 30 kHz 60 kHz 120 kHz LTE R8

PDSCH → PUCCH 8; 0.57 10; 0.36 17; 0.3 20; 0.18 2.3 ms
PDCCH → PUSCH 10; 0.71 12; 0.42 23; 0.41 36; 0.31 3 ms
NR defines two device capabilities for the minimum HARQ processing time. Initially, most devices
will support the baseline capability shown in the preceding table. The following table indicates the
second device capability that is defined by the specification:
15 kHz 30 kHz 60 kHz LTE R8

PDSCH → PUCCH 3; 0.21 4.5; 0.16 9; 0.16 (FR1) 2.3 ms
PDCCH → PUSCH 5; 0.35 5.5; 0.2 11; 0.2 (FR1) 3 ms
A HARQ process needs to feedback multiple acknowledgments at the same time – for instance, for
carrier aggregation, multiple downlink slots followed by an uplink slot. Note that the number of
bits to feedback depends on the number of downlink transmissions and some of these downlink
transmissions might be missed by the device.
Finally, a HARQ codebook can be a semi-static codebook (Type 1) or a dynamic codebook (Type 2).
In this section, we listed the channel coding schemes for NR, and we showed how they are introduced
in channel processing chains. We’ve also discussed the retransmission schemes by comparing them
with LTE. Now, it is time to learn the final revolutionary aspect of the NR physical layer.
BWPs
In this last section of this chapter, we will cover another concept introduced in NR, which is the
BWPs. This concept is new in NR and very powerful for a few interesting and important use cases.
In this section, we will learn what BWPs are and how they are configured, activated, and deactivated.
We will also describe the main use cases for BWPs to better understand their importance in the NR
physical layer.
Defining a BWP
So, let’s start by defining what a BWP is. A BWP is a set of contiguous PRBs with nested bandwidths
where the devices are only allowed to transmit or receive. Each BWP has its own configuration with
a specific numerology to use and a set of reserved resources for which transmission is not allowed.
Devices always operate using BWPs. This means that at least one initial BWP must be defined by the
PBCH so that all devices can access it. This initial BWP will also contain the CORESET and PDSCH
for the RMSI. However, a BWP does not need to contain an SS block.
BWP parameters
A device must be configured with one uplink and one downlink BWP at least. However, it can be
configured with multiple BWPs as well. It is important to know that these configured BWPs may
overlap in the frequency domain. Note that in Release 15, only one of them is active, so only one
uplink and one downlink BWP can be active at the same time. Among others, the main parameters
that can be configured for BWPs are the numerology, the frequency location, the number of PRBs,
and the CORESET with which the control channel must be monitored.
BWP operations
Devices can only transmit and receive using the active resources of the BWP with the associated
numerology. The BWPs can be activated or deactivated by many different means, including dedicated
RRC signaling, DCI with explicit indication, or timer-based activation:
BWPs 133
Figure 6.18 – BWP operation
In the figure here, you can see a basic example of how BWPs operate. There is an initial BWP that
is used by all devices for initial access. Then, either by DCI or RRC, the devices can be assigned to
different BWPs based on their frequency resource needs.
Now, let’s understand BWPs deeply by evaluating their use cases.
BWP use cases

So, what are the use cases for these BWPs? The first one is supporting devices with a reduced bandwidth
capability. We already discussed that NR is different from LTE in this respect. LTE mandated all
devices to support all the bandwidth available and the device would always access the network using
the cells’ bandwidth. In NR, on the other hand, a device with less bandwidth support is still able to
access the cells. The cells define a BWP according to the devices’ minimum bandwidth and assign it
to the device to support this kind of bandwidth-limited scenario:
Figure 6.19 – Supporting reduced device bandwidth capability
Another interesting use case is energy saving. If a device does not require high throughput, it can be
transferred to another BWP with less bandwidth. Therefore, the device can then reduce its baseband
processing clock and save power:
Figure 6.20 – Supporting reduced device energy consumption
Another use case is being able to multiplex the numerologies. Each BWP has its own numerology, as
discussed previously. So, devices with different numerologies can be separated by the configurations of
the BWP. Moreover, in situations in which the numerology for a device should change – for example,
a traffic type change – the device is assigned to another BWP associated with that new numerology:
BWPs 135
Figure 6.21 – Supporting different numerologies
Another use case is the support of the non-contiguous spectrum. If all the BWPs defined in a cell
block a certain frequency range, the network frees those resources and avoids any transmission from
the network for the devices on those frequencies:
Figure 6.22 – Supporting a non-contiguous spectrum
One final use case is forward compatibility. This is also related to the previous use case. This is basically
the possibility to avoid the transmission of all the devices in a given frequency range, which could
make it easier to support new features in the future without having to consider the impact on the
device penetration in the network.
Figure 6.23 – Supporting forward compatibility

So, BWPs are one of the main improvements for NR. We have explored at a high level how they are
configured and activated and some of the main scenarios in which they can be employed.
Summary
In this chapter, we went through the downlink and uplink physical channels and signals for NR.
Although certain aspects are taken from LTE, we still covered the similarities and differences for
NR. We discussed channel coding schemes, LDPC code, and polar coding. We finished the chapter
by evaluating the use cases of BWPs. As such, this chapter has fully covered the NR air interface and
physical layer procedures.
Next, we’ll look at the packet core procedures in 5G.
7
Packet Core Procedures
In this chapter, we will consolidate the concepts and fundamental knowledge from the previous
chapters and map them to real 5G system procedures. We will see how the fundamentals of cloud-
native infrastructure give shape to the communications between the various network functions in a
producer-consumer relationship to bring about the reality of the 5G system and various procedures
that enable a 5G device to get access to mobile broadband. All the call flows explained in detail here
are expected to be implemented in code that has been built based on cloud-native development
methods; these are mainly container-based and have a producer-consumer method of providing and
consuming services.
In Chapter 2, we learned about the role of the network functions in the 5G packet core, and in
Chapter 3, Building Blocks – Cloud Native Infrastructure, we learned about the services offered by each
of those network functions. In this chapter, we will see how all the network functions come together
to service a 5G device. We will get into the details of call flows of fundamental procedures that enable
a 5G device in a network.
In the upcoming sections, we will go over the following topics:
• PDU session establishment in 5G

• PDU session establishment 4G/IWF
• PDU session establishment 5G - IMS
• VoNR call flow
• Wi-Fi Attach
PDU session establishment in 5G

In Chapter 2, we discussed a Protocol Data Unit (PDU) session, wherein we learned that a PDU
provides end-to-end connectivity to user equipment (UE) to avail of data services. A PDU session
can be imagined to be a pipe that is associated with every UE and is identified by a PDU session ID;
138 Packet Core Procedures
this pipe is used for the user data to flow between the 5G packet core to the UE. The PDU session ID
is generated by the UE. Figure 7.1 shows a PDU session along with various Quality of Service (QoS)
flows associated with it:
Figure 7.1 – PDU session in 5G
The establishment of a PDU session involves the UE along with a number of network functions. These
network functions exchange messages with each other, and when all these message transactions are
successful, a PDU session is finally established.
Figure 7.2 describes the procedure through which this end-to-end connectivity is established. It can
be noticed here that the participating nodes are as follows:
• UE
• gNB (gNodeB/RAN)
• AMF (Access and Mobility Function)
• SMF (Session Management Function)
• SCP (Service Communications Proxy)
• UDM (Unified Data Management)
• PCF (Policy Control Function)
• CHF (Charging Function)
• UPF (User Plane Function)
Note that, optionally, a Network Registration Function (NRF) can also be used for service registration
and discovery, but we have left it out of our example here for the sake of simplicity.
PDU session establishment in 5G 139
Figure 7.2 – PDU session establishment in 5G – part 1
Let us elaborate on each of the steps mentioned.

In Steps 1 and 2, the UE initiated a PDU session establishment message, which is directed from the
UE to the AMF via the gNB. This comprises a NAS container that has various information, such as
the following:
• S-NSSAI(s)
• UE-generated PDU session ID
• DNN information
• Request type, which could be one of the following:
i. Initial Request – corresponding to the request for a new PDU session

ii. Existing PDU Session – if the request refers to an existing PDU session switching
between 3GPP and non-3GPP access, or in the case of being handed over from a 4G
Evolved Packet Core (EPC)
iii. Emergency Request – for establishing a PDU session for emergency calls
• PDU session type (IPv4, IPv6, IPv4v6, Ethernet, unstructured, etc.)

• Requested SSC mode type
• 5GSM capability, which contains information on whether the Ethernet PDU session type is
supported, whether Reflective QoS is supported, whether it is a Multi-Homed IPv6 PDU Session,
ATSSS capability, and the transfer of port management information containers
• PCO container
• SM PDU DN request containers (number of packet filters, and header compression configuration);
the number of packet filters co-relates to the number of filters for the signaled QoS rules
Hence, Steps 1 and 2 are used to relay the UE request to establish a PDU session and the related
information to ascertain the type of request and the UEs capability, and so on. The gNB transparently
relays this message to the AMF.
In Step 3, the AMF selects the SMF based on DNN, NSSAI, PLMN, TAI, request type, or based on
local configuration, if available. After this, the AMF sends the SMF the Nsmf_PDUSession_
CreateSMContext request; this message relays to the SMF the information gathered by the AMF.
This relates to PDU session creation, so the AMF (with information such as the request type, DNN,
PDU type, etc.) requests the SMF to create a session. Based on this information, the SMF decides
whether it can accept the request by fulfilling all the criteria in the request or not. For example, the SMF
can reject the message if the request is for an IPv6 PDN type and the SMF/UPF only supports IPv4.
In Steps 4 and 5, the SMF registers itself to be mapped to this session with the UDM as its serving
SMF. The UDM determines whether the SMF is authorized to be its consumer. It also uses the same
to be implicitly notified if it is deregistered in the UDM.
In Steps 6 and 7, the subscription data pertaining to the UE is fetched. The UDM queries the UDR
(as discussed in Chapter 3, Building Blocks – Cloud Native Infrastructure) by a key such as SUPI to
retrieve this information. The following list contains some of the contents of the subscription data
fetched by the SMF from the UDM:
• Subscribed UE-AMBR, which is the aggregation ID, the UL, and DL MBRs across all
non-guaranteed QoS flows
• Subscribed S-NSSAIs
• Any restriction on the RAT type
• Forbidden areas, if any, and service area restrictions, if any
• CAG information
• DNN list
• Charging characteristics
• SMF+PGW-C FQDN for interworking with 4G EPC
• SSC modes allowed
• Static IP address or prefix, if applicable
In Steps 8 and 9, the SMF requests the UDM to notify in the case of any subscription information
being changed. Also, the UDM delivers any Steering of Roaming information to the UE. Basically,
these procedures ensure that the SMF is notified in case of changes to UE subscription information,
and thereby, it can implement the same to modify its existing session.
In Step 10, the Nsmf_PDUSession_CreateSMContext response is sent from the SMF to the
AMF. If the SMF can successfully process the request, it responds by providing an SM context ID to
the AMF. This message contains a cause field that determines success, and in the case of failure,
provides a cause value and an N1 container to be relayed to the UE indicating the outcome.
In Steps 11 and 12, the SMF selects the PCF that it needs to communicate with for retrieving the
policies associated with the subscriber for this PDU session request. The SMF can use the NRF to
discover the PCF, or it can also select the PCF based on local static configuration. After this, the SMF
performs an SM policy association procedure with the PCF and retrieves the default PCC rules for
the PDU session. The PCF responds with a Policy Create Response message with the PCC
rules for the PDU session:
In Steps 13 and 14, the IP address for the PDU session is allocated; this is done by the SMF. Also at
this stage, the SMF selects the UPF that it will use to further establish the data plane for the PDU
session. The allocated UE IP address or prefix, access type, RAT type, policy control triggers, serving
network information, UE time zone, and user location information is communicated to the PCF
using this update message:
Figure 7.4 – Packet capture PCF Response-201 Created
In Steps 15 and 16, if a charging system is allocated in the network, the CHF Create Request message
is used to trigger the charging system. It is used to notify the Session Creation event to the charging
system. This message would be the initial invocation and will contain an invocation sequence number
that would increment with each subsequent transaction of the SMF with the CHF – for example, for
reporting volume or when any other trigger condition such as a RAT type change happens, the SMF
sends the subscriber an identifier and a Notify URL.
The CHF responds with PDU session charging information and the list of triggers:
Figure 7.5 – Packet capture CHF Response-201 Created
In Steps 17 and 18, the SMF sends an N4 session establishment request to the selected UPF and
provides the packet detection, enforcement, and reporting rules that it had received from the PCF
in Steps 13 and 14. These include the PDR, QER, FAR, and URR. The UPF responds with the uplink
tunnel information.
Steps 19 and 20 are applicable only if N26-based interworking is enabled in the network and the SMF
plays the role of PGW-c/SMF. This is a request to the AMF to assign an EPS bearer ID to this PDU
session for a future handover to the 4G EPS system. If N26-based handover is not supported, this is
not applicable.
In Steps 21 and 22, the message from the SMF to the AMF carries an N1 container to be passed on
to the UE and an N2 container for the gNB; a lot of important information about the PDU session is
packed in these containers, such as the following:
• PDU session ID
• N2 SM information, including the following:
PDU session ID
QFI(s)
QoS profile,
CN tunnel info
S-NSSAI from the allowed NSSAI
Session-AMBR
PDU session type
User Plane Security Enforcement information
UE integrity protection maximum data rate
• N1 SM container (PDU session establishment accept):
QoS rules and QoS flow level, and QoS parameters, if needed, for the QoS flows associated
with the QoS rules
Selected SSC mode
S-NSSAIs
UE requested DNN
Allocated IPv4/v6/v4v6 address
Interface identifier
Session-AMBR
Selected PDU session type, and reflective QoS timer, when available
P-CSCF addresses within the PCO, if requested
Control Plane Only indicator, when available
Header compression configuration, when available
Always-on PDU Session Granted, when available
Small data rate control parameters, when available
Small data rate control status, when available
Serving PLMN rate control
• If multiple UPFs are used for the PDU session, the CN tunnel info contains tunnel information
related to the UPFs that terminate N3
The CN tunnel information included in the N2 container has the core network addresses of the N3
tunnel corresponding to the PDU session that is provided to the gNB via the AMF. It also provides
the QoS information and profiles to the RAN via N2 and via N1 to the UE.
In Step 23, the message is directed from the AMF to the RAN (gNB). The N2 PDU session request
contains N2 SM information and a NAS message. The NAS message contains the PDU session ID and
N1 SM container containing the PDU Session Establishment Accept message.
Hence via this message, the AMF directs the NAS container to the UE and the SM message for the gNB.
In Step 24, the RAN may send an RRC connection reconfiguration message, which will relay to the
UE the QoS rules for the PDU session. The gNB also allocates the RAN tunnel information for the
PDU session.
In Step 25, the PDU session response is sent from the RAN to the AMF; this contains the PDU
session ID, the cause, N2 SM information comprising of the PDU session ID, AN tunnel information
(which corresponds to the N3 tunnel information), list of accepted or rejected QFIs, and a user plane
enforcement policy notification.
With the availability of the N3 tunnel information, the first uplink user data can now be sent from
the UE to the 5G core.
In Step 26, the PDU Session Update SM Context Request message is sent from the AMF
to the SMF. It is used to forward the N2 SM information received from the RAN to the SMF. The SMF
is provided with the list of accepted QFIs, which it further enforces via the UPF.
In Steps 27 and 28, the N4 session modification procedure with the UPF is carried out by the SMF.
The SMF provides the AN tunnel info it has received from the gNB via the AMF, and the UPF receives
the forwarding rules.
The UPF responds with an N4 Session Modification Response to the SMF.
After this step, the UPF is ready to deliver any data packet in the downlink direction to the UE.
In Step 29, the PDUSession_UpdateSMContext response message is sent from the SMF to the
AMF. The SMF can subscribe to any UE mobility event notification from the AMF, and with the help
of this, the SMF is notified about relevant events to the SMF.
In the case of PDU session types IPv6 or IPv4v6, the SMF generates an IPv6 router advertisement and
sends it to the UE after this stage. For the Ethernet PDU session type, the SMF can send the MAC
address and the DS-TT Ethernet port.
This marks the end of the PDU session establishment procedure.
In this section, we have gone through the details of the PDU establishment procedure and the call
flow to set up a PDU session in 5G. We have also learned about the concept of a PDU and the role it
has to play in establishing connectivity for a UE. In the next section, we will go through the call flow
to establish a 4G call using the 5G packet core network.
PDU session establishment with 4G/N26/IWF

3GPP has specified provisions for the UEs capable of supporting both 5G and 4G NAS to connect to
the E-UTRAN and 5G core network. An SMF capable of the EPS interworking support would act as a
PGW-C+SMF and would have the S5/S8 interface with SGW to receive the 4G session creation request.
PDU session establishment with 4G/N26/IWF 147
Figure 7.7 – 4G interworking function
All the other interfaces involved in a 4G session creation (for example, Gx, Gy, Gz, etc.) are replaced
by the corresponding 5G core SBI interfaces (Npcf, Nudm, and Nchf). The SMF+PGW-C provides
information over N4 to the UPF+PGW-U related to the handling of traffic over S5-U.
This option will be used typically by network operators when most of their network has a 5G core
deployed. In this case, it makes sense to slowly retire the legacy of the 4G-based core and leverage the
interworking function of the 5G core to cater to 4G devices.
In Figure 7.7, we see how interworking is supported between the 5G and 4G cores. Another key feature
that is enabled by this design is the fact that handovers between 4G and 5G and vice-versa would be
seamless, which would be made possible by leveraging a common UPF that will serve both 4G and
5G sessions. Hence, continuity can be maintained on the user plane and the user traffic will not be
disrupted during this transaction.
4G (E-UTRAN) initial attach

In this section, we will go into detail on how to establish a 4G session using the interworking function
within the 5G core. This is one of the key aspects that will enable service providers to later use parts
of 5G core for operating their 4G network as well, thereby reducing the need to operate full-fledged
4G and 5G core networks.
Figure 7.8 – 4G initial attach with IWF (5G core)

PDU session establishment with 4G/N26/IWF 149
Some of the key features in the call flow are as follows:
• The PGW in the procedure is replaced by SMF+PGWC.

• The MME selects the PGWC/SMF by checking the N1 mode support from the UE capability – that
is, within the registration request sent by the UE during the initial attach and the subscription
from HSS. The MME sends the DNS query based on the service type to select the best match
for PGWC/SMF according to the top one:
Figure 7.9 – N1 node in a packet capture
• The MME sets the 5GIWKS indication flag on CSReq:
Figure 7.10 – 5GS interworking indication in a packet capture
• The SMF/PGWC allows the 4G session. Either the PDU session ID is received on PCO/APCO
or the CSReq will have a 5GIWKS bit set.
• During PDN connection establishment in the EPC, the UE allocates the PDU session ID and
sends it to the PGW-C+SMF via PCO. An S-NSSAI associated with the PDN connection is
determined based on the operator policy and is sent to the UE in the PCO together with a
PLMN ID that the S-NSSAI relates to.
• X2 and S1-based handover for EPS. When the UE is attached to E-UTRAN, all handover
procedures will result in SMF+PGW-C seeing only a Modify Bearer Request message
from SGW for either location change and/or SGW change during handover.
The following diagram denotes the detailed flow:
Figure 7.11 – 4G initial attach with IWF (5G core) – part 2

IMS 5G PDU session establishment 151
In this section, we have gone over the details of the process to establish a 4G session using the 5G
interworking function. This may turn out as a popular choice for the telecom operators to deploy, as it
encourages the use of common infrastructure and network functions for both 4G and 5G, and hence
the need to maintain two large 4G and 5G networks simultaneously is reduced to a large extent. This
saves operational expenses (OPEX) to a large extent. In the upcoming section, we will explore how
voice calls are supported in a 5G network.
IMS 5G PDU session establishment

Voice and video calls are use cases that need to be supported by every service provider network. The
IP Multimedia Subsystem (IMS) enables these services in a telecom network. In this section, we will
see how voice, video, and rich communication services are provided with the help of the IMS in 5G,
which is very similar to the support of voice in 4G (VoLTE). Figure 7.12 shows the establishment of
an IMS PDU session in 5G:
Figure 7.12 – IMS 5G PDU attach in 5G – part 1

Let’s look at these steps in detail:

Step 1: The UE initiates the N1 message with the PDU session establishment request by including a
container identifier, P-CSCF IPv4/v6 Request contained within the ePCO (extended Protocol
Configuration Options) IE, and DNN set to IMS.
Step 2: The AMF sends the Nsmf_PDUSession_CreateSM context request to the SMF by including
N1 and N2 messages as multipart, along with the ePCO IE if it is received from the UE in the PDU
session establishment request.
Step 3: The SMF sends an HTTP PUT request for UDM registration.
Step 4: After a successful transaction, the UDM reports with a 201 created message.
Step 5: The SMF fetches the session management subscription data for the corresponding SUPI, DNN,
and S-NSSAI with this HTTP GET message.
Step 6: For a successful transaction, the UDM responds with 200 OK and sends the DNN configurations
5G QoS profile, 5QI , ARP, session AMBR values, and so on.
Step 7: SMF sends an HTTP post subscription notification request to the UDM for this SUPI.
Step 8: After a successful transaction, the UDM responds with a 201 created message.
Step 9: The SMF sends an Nsmf_PDUSession_CreateSM context response with the cause, N1
SM container by processing the PDU session establishment request.
Here are some snapshots:
Figure 7.13 – Packet capture: AMF TO SMF PDU session create SM context request
The UDM to SMF subscription fetch message is shown next. It depicts some of the important fields,
such as the DNN configurations, allocation, and retention priority values, and so on:
Figure 7.14 – Packet Capture: UDM to SMF subscription fetch response
The SMF to AMF communication as is seen on the wire is depicted next. It contains an acknowledgment
of the session created and mapped to a unique subscriber context with the IMSI details, as shown in
the following figure:
Figure 7.15 – Packet Capture: SMF to AMF SM Created message
The following shows the IMS 5G PDU attach call flow (continued from earlier):
Figure 7.16 – IMS PDU attach procedure – part 2

The subsequent details of the IMS PDU session establishment procedure are listed next via Steps 10 to 16:
Step 10: The SMF sends HTTP GET request /nnrf-disc/v1/nf-instances?dnn =
ims&requester-nf-type=SMF&target-nf-type=PCF for PCF instances, and the NRF
responds with 200 OK with the service instance ID, API versions, NF (Network Function) service
status, and IPv4 addresses.
Step 11: The SMF initiates the Npcf_SMPolicy Control_Create request by including SmPolicy
ContextData, which contains SUPI, GPSI, PDU session ID, RAT type, serving network, user
location info, UE time zone, PEI, online/offline charging, charging characteristics, PDU session type,
allocated UE IP address/prefix(es), and subsDefQos.
Step 12: The PCF responds with 201 Created, PolicyCreation, SessRules, policyCtrlReq
triggers, chargingInfo.pccRules, and revalidation time.
Step 13: The SMF initiates a POST request/npcf – smpolicycontrol/v1 /smpolicies/
ism.l.imsi-123123xxxxxx/update to PCFUpdate with access type, IPv6 address prefix,
RAT type, reppolicyCtrire triggers, serving network, UE time zone, user location info.
Step 14: The PCF responds with 200 OK for the successful transaction.
Step 15a: The SMF sends an HTTP GET request //x.x.x.x:8080/nnrf-di Sc/V1/
nf-instances?preferred locality= honoulu & requester-nf-type=SMF&target-
nf-type-CHF for CHF instances, and the NRF responds with 200 OK with service instance ID,
API versions, NF service status, and IPv4 addresses.
Step 15b: The SMF sends an HTTP POST request /nchf-convergedcharging /V2/
chargingdata to CHF initial with invocation Sequence Number, Timestamp PDU Session Charging
Information, Subscriber Identifier, and Notify URI.
Step 16: The CHF responds with 201 Created with triggers and PDU session charging information.
Next, we will present some snapshots from real traces.
Figure 7.17 shows a packet capture between the PCF and SMF. This message contains the session and PCC
rules sent by the PCF, along with a revalidation timer value, various triggers, and supporting features:
Figure 7.17 – Packet capture PCF to SMF policy created response
Figure 7.18 shows the packet capture depicting a discover message between the SMF and NRF. The
NRF provides the details of a PCF that the SMF would need to contact to process the call:
Figure 7.18 – Packet capture SMF to NRF discover message

Figure 7.19 shows the policy update message exchanged between the SMF and the PCF:
Figure 7.19: Packet capture SMF to PCF policy update message
Note the different types of information exchanged between the two network functions. Next, we’ll
continue with the IMS PDU session establishment procedure.
Step 17: The SMF sends a PFCP session establishment/modification request to the UPF and provides
packet detection, enforcement, and reporting rules to be installed on the UPF for this PDU session
(PDR, QER, FAR, and URR).
Step 18: The UPF responds with uplink tunnel information.
Step 19: The SMF sends an HTTP GET request, http://x.x.x.x:8080/nnrf-disc/v1/
nf-instances?requester-nf-type=SMF&target-nf-instance-id=bbe596c6-
0a81-4e94-85bc-f3b1b4a9a52f&target-nf-typ AMF/, for AMF instances, and the
NRF responds with 200 OK with the service instance ID, API versions, NF service status, and
IPv4 addresses.
Step 20: In the sm create context request, AMF sends epsinterworkingind":"WITH_N26, and
seeing this indicator, the SMF sends an AssignEBI HTTP POST request to the AMF (http://
x.x.x.x:8080/na mf-comm/v1/ue-contexts/imsi-123xxxxxxx/assigebi/)
with the ARP list and PDU session ID.
Step 21: The AMF responds with assignedEbiList (ARP, value, and EPS bearer ID).
Step 22: The SMF sends an HTTP POST request to AMF (http://x.x.x.x:8080/namf-comm/
v1/ue-contexts/imsessages/N1N2MessageTransfer Session) with details (PDU
information ID, N2 (PDU SM Session ID), QFI(s), QoS Profile(s), CNTunnel Info, S-NSSAI from the
Allowed NSSAI Session - AMBR, PDU Session Establishment type, N1 SM container (PDUAccept
([QoS Rule(s) and QoS flow level QoS parameters if needed for the QoS flow(s) associated with the
QoS rule(s)], selected SSC mode, S – NSSAI(S), DNN, allocated IPv4 address, interface identifier,
Session - AMBR, selected PDU session type, [reflective QoS timer] available), [P - CSCF address(es)],
[Always-on PDU SessionGranted). Multiple UPFs are used for the PDU Session. CNTunnel Info
contains tunnel information related with the UPF that terminates N3.
Figure 7.22 shows a wire capture of the SMF and NRF transaction for the discovery of an AMF; the
requestor and target field can be used to identify which network function is requesting the details of
the target network function from the NRF.
Figure 7.22 – Packet capture SMF to NRF discovery
Figure 7.23 shows the content of the N1N2 message transfer transaction between the SMF and the
AMF. Some key fields, such as the Always on indicator and protocol configuration
options, depict the kind of information exchanged with this message:
Figure 7.23 – Packet capture SMF to AMF N1N2 message transfer
Figure 7.24 depicts the contents of a successful N1N2 message transfer transaction:
Figure 7.24 – Packet capture SMF to AMF N1N2 Message Transfer Success
Step 23: The AMF acknowledges the request with 200 OK and responds with a cause, N1+N2+TRANSFER_
INITIATED.
Step 24: Resource setup for the uplink tunnel.
VoNR call flow 163
Step 25: PDU establishment response to the UE.

Step 26: The downlink tunnel of gNB.
Step 27: The AMF sends a PDU session update SMC context request to the SMF, which triggers the
SMF to (optionally) start establishing N4 to the UPF to retrieve GTP tunnel identifiers, or retrieve
them from an already established N4 tunnel if established asynchronously.
Step 28: The SMF sends the tunnel information to the UPF for setting up the downlink data path.
Steps 29 and 30: The Sx modification response will contain the status of the transaction – whether
it has passed or failed. If it was successful, it will convey the same to the AMF in the PDU session
update context response message.
In this section, we have gone through the details of the IMS PDU session establishment. We have
studied the contents of the various HTTP messages exchanged between the network functions, and seen
how the whole IMS PDU session is set up and the various network functions used when setting it up.
In the upcoming section, we will study the details of Voice over New Radio (VoNR).
VoNR call flow

In the previous section, we saw how an IMS PDU session is established. In this section, we will go
over the VoNR call flow, which is used when a user places a voice call.
Figure 7.25 – VoNR call flow – part 1

Step 1: The UE initiates SIP registration toward the called party via UPF, and P-CSCF through the
IMS core network in the backend.
Step 2: P-CSCF sends Npcf_PolicyAuthorization_Update to the PCF to enforce policies,
modify service information, apply gate control for traffic shaping and policing, modify subscription
to SDF notification/deactivation, and so on.
Step 3: The PCF sends an HTTP POST request (/callbacks/v1/smPoliciesUpdate
Notification/imsi-123xxxxxx:1:1591309591702656285/update) to
the SMF to update PCC rules (SIP VoNR audio), policy control request triggers, SDF, and
charging-related information.
Step 4: The SMF processes the received PCC rules and sends a 204 No Content (200 OK) message
for a successful transaction.
Step 5: The SMF sends an HTTP POST request to AMF (http://x.x.x.x:8080/namf-comm/
v1/uecontexts/imsi-123xxxxxxxxx/n1-n2-messages/NIN2) with details (PDU
session modification command ID, QFIS, QoS profile(s), and Session - AMBR), N1SM container
(PDU session modification command (PDU Session ID, QoS rule(s), QoS flow level parameters if
needed for the QoS flow(s) associated with the QoS rule(s), QoS rule operation, and QoS flow level
QoS parameters operation, Session - AMBR)).
Step 6: The AMF acknowledges the request with 200 OK and responds with a cause: N1_N2_
TRANSFER_INITIATED.
Step 7: The AMF sends N2 PDU session request N2 SM information received from the SMF, NAS
message PDU Session ID, and NI SM container (PDU session modification command).
Step 8: Access Network Specific Resource modification process takes place and the gNB notifies to
UE about any change in parameters and UE acknowledges the same.
Step 9: An N2 PDU Session Acknowledgment message is sent from the gNB to the AMF with a
confirmation that the radio-related modifications in Step 8 is successful.
VoNR call flow 165
The following are some snapshots from actual traces:
Figure 7.26 – Packet capture PCF to SMF policy control update notify
The following figure shows the N1N2 message transfer packet capture during the establishment of a
voice call. The key information elements are shown in the diagram:
Figure 7.27 – Packet capture SMF to AMF N1N2 transfer message
We will now continue to the next phase of the call flow and go over the remaining steps one by one:
VoNR call flow 167
Figure 7.28 – VoNR call flow – part 2
Step 10: The AMF forwards the N2 SM information and the user location information received from
the (R) AN to the SMF, and if the (R) AN rejects QFls, the SMF updates the QoS rules and QoS
parameters if needed for the QoS flow(s).
Step 11: The SMF acknowledges with 204 No Content.
Step 12: The UE acknowledges the PDU session modification command by sending a NAS message
(PDU session ID, N1 SM container (PDU session modification command ACK)).
Step 13: The gNB transfers the NAS message to the AMF.
Step 14: The AMF forwards the N1 SM container (PDU session modification command ACK) and user
location information received from the (R) AN to the SMF via the Nsmf_PDUSession_Update
SMContext service operation.
path/nsmf -pdusession /v1/sm-contexts/imsi- 123xxxx :1/modify
Step 15: The SMF acknowledges with 204 No Content.
Step 16: The SMF sends an HTTP POST request (/nchf -convergedcharging/v2/
chargingdata/acdsddsdd-988739-1466329180645-SBI/update) to the CHF. The
SMF sends ChargingDataUpdateReq by including Multi-Uni-Usage with Rating-
Group-ld, which is received as part of Charging_Description of Sm_Policy Control_
UpdateNotify_Request to install PCCRules.
Step 17: The CHF responds with 200 OK with triggers and PDU session charging information.
Step 18: The SMF updates the N4 session of the UPF(s) that are involved in the PDU session modification
by sending an N4 session modification request (N4 Session ID) message.
Step 19: The UPF acknowledges the request and responds with “cause” accepted.
This marks the end of the VoNR procedure.
The VoNR procedure is key to establishing voice calls with NR. The IMS PDU session establishment
along with a VoNR call flow completes the requirement needed to make a voice call or a video call
over NR.
One key thing to keep in mind, however, is that the IMS PDU session is established when the phone
is turned on, but the VoNR call flow is executed when we dial a number for voice or video calls.
In the next section, we will study the integration of Wi-Fi with 5G networks.
Wi-Fi attach
One of the prime features of the 5G core network is its capability to inter-work with different types
of access networks, both 3GPP-based and non-3GPP-based. One such network is Wi-Fi. The 5G
radio can coexist with Wi-Fi access to cover coverage gaps. Hence, denser access can be planned
with complementing radio access technologies. This is how Wi-Fi and New Radio (5G radio) can
complement each other and do not need to be treated as competing technologies.
Wi-Fi attach 169
Figure 7.29 – Wi-Fi attach – part 1
We will now go over the Wi-Fi attach procedure:

Step 1: The UE sends the IKE_SA_AUTH exchange message to ePDG (IWF-interworking function)
to create the IPSec tunnel.
Step 2: The UE sends the IKE_SA_AUTH exchange message to the SMF+PGW-C as a GTP Create
Session request by including the P-CSCF IPv4 or IPv6 request and DNS IPv4 or IPv6 container
identifier in APCO IE options. The ePDG checks the UE capability information to determine whether
it is supposed to anchor to a 5G SMF or a 4G PGW.
Step 3: The SMF+PGW-C extracts and saves the PDU session ID that the UE sent in the APCO IE option
and sends a UDM registration HTTP PUT request (/nudm-uecm/v1/imsi-123xxxxxxxx37/
registrations/smf-registrations/1) and sends the PDU session ID, DNN, and NSSAI info.
Step 4: For the successful transaction, UDM responds with 201 Created.
Step 5: The SMF fetches the session management subscription data for the corresponding SUPI,
DNN, and S-NSSAI with http GET/nudm-sdm/v2/imsi-123123111111111/
sm-data?dnn=imslab&plmn-id=%2%7 D&sing!e-nssai=%7%7D &supported-
features=O.
Step 6: For the successful transaction, UDM responds with 200 OK and sends the DNN configurations
– "5gQos profile: 5qi", "arp:SessAmbr" values, iwkEpsind, and so on.
Step 7: The SMF sends an HTTP POST subscription notification request to UDM for POST/nudm-
sdm/v2/imsi-123123xxxxxx/sdm-subs.
Step 8: For the successful transaction, UDM responds with 201 Created.
Step 9: The SMF sends an HTTP GET request (/nnrf-disc/v1/nf-instances?dnn=ims.

lab&requester-nf-type=SMF &target-nf-type=PCF) or PCF instances, and NRF
responds with 200 OK with the service instance ID, API versions, NF service status, and IPv4 addresses.
Step 10: The SMF initiates Npcf_SMPolicyControl_Create Request by including
SmPolicyContextData, which contains supi, gpsi, pduSessionld, ratType:WLAN,
servingNetwork, userLocationinfo , ueTimeZone, PEI, online/offline charging,
charging characteristics, PDU session type, allocated UE IP address/prefix(es), subsDefQos, and
other information.
Wi-Fi attach 171
Step 11: The PCF responds with 201 Created with policy creation with SessRules,
policyCtriReqTriggers, chargingInfo, pccRules, and revalidation time.
Step 12: The SMF initiates a POST request (/npcf-smpolicycontrol/v1/sm-policies/
ism.1.imsi-123xxxxxxxxxx/update to PCF Update) with access type,
ipv6addressPrefix, RAT type, reppolicyCtriretriggers, ServingNetwork,
ueTimezone, and user location info.
Step 13: PCF responds with 200 OK for the successful transaction.
Step 14: The SMF sends an HTTP GET request (//10.19.19.19:8080/nnrf-disc/v1/

nf-instances?preferred-locality=Belll&requester-nf-type=SMF&target-
nf-type=CHF) for CHF instances and NRF responds with 200 OK with the service instance ID,
API versions, NF service status, and IPv4 addresses.
Step 15: The SMF sends an HTTP POST request, /request/nchf-convergedcharging/

v2/chargingdata, to CHF initial with the invocation sequence number, timestamp, PDU session
charging information, subscriber identifier, and notify URI.
Step 16: The CHF responds with 201 Created with triggers and PDU session charging information.
Step 17: The SMF sends a PFCP session establishment/modification request to the UPF and provides
packet detection, enforcement, and reporting rules to be installed on the UPF for this PDU session
(PDR, QER, FAR, and URR).
Step 18: The UPF responds with UplinkTunnel information.
Step 19: The SMF+PGW-C sends a Create Session Response to the ePDG. This response includes
the bearer information and the FTE ID, bearer context, 5G QoS parameters in APCO options, PCSCF
IPv6 address, Session-AMBR, QoS rules, QoS flow description, and S-NSSAI.
Step 20: The ePDG sends an IKE_SA_AUTH response to the UE.
Figure 7.32 – Packet capture ePDG to SMF Create Session Request

Summary 173
The packet capture below shows the Create Session Response that is sent from SMF to ePDG. You
can have a glance at the message structure and information elements within it that is sent across to
the ePDG.
Figure 7.33 – Packet capture ePDG to SMF Create Session Response
In this section, we have delved into the details of establishing a Wi-Fi session. This explains the
interworking of WLAN technology with the 5G core network. This enables a 5G/4G network support
handover between 4G/5G and WLAN.
Summary
In this chapter, we have seen the various procedures in 5G and how they come together to service a
subscriber. We have gone over how a PDU session is established in 5G, and we have gone over how to
connect a 4G radio to work with a 5G interworking function. We have seen how to establish a voice
call over New Radio and finally, we have seen how Wi-Fi access integrates with a 5G system. By the
end of this chapter, we now understand the 5G call flows in detail and have developed a near-practical
understanding of the messages exchanged between the various network functions to bring about a
data or a voice call in 5G.
In the upcoming chapters, we will delve further into 5G-NSA and 5G-SA system architectures that
leverage these procedures. The next chapter introduces exclusive VoNR concepts.
8
Voice over New Radio (VoNR)
The combination of Voice over Long-Term Evolution (VoLTE) and Voice over NR (VoNR) will be
the long-term voice infrastructure for mobile service providers. In this chapter, we will discuss the
main concepts behind future VoNR networks. Furthermore, VoNR will be analyzed from end to end
with a focus on the architecture requirements, initial procedures, call establishment, and interworking.
VoNR has got some very close similarities to VoLTE. For example, both technologies require an IP
Multimedia Subsystem (IMS) for call signaling, and both technologies employ their Radio Access
Network (RAN), transport, and core networks to carry voice media in the form of IP packets.
We’ll go through the following topics in this chapter:
• VoNR concepts and drivers

• VoNR high-level architecture
• VoNR initial procedures
• VoNR call procedures
• Interworking and voice call continuity
VoNR concepts and drivers

In this section, the concepts and drivers associated with VoNR are analyzed in three main areas:
IMS network deployment growth, 5G system service requirements, and ultra-high-definition audio.
IMS network deployments growth

The number of subscribers associated with packet voice services over telephony such as VoLTE is
rising significantly. According to the 2018 Ericsson Mobility Report (https://www.ericsson.
com/491e17/assets/local/mobility-report/documents/2018/ericsson-
mobility-report-june-2018.pdf), VoLTE subscriptions are projected to reach 5.4 billion in
2023, which means that the service providers will be implementing more IMS deployments for VoLTE
176 Voice over New Radio (VoNR)
services. The same IMS architecture can also be employed for VoNR services when a service provider
deploys a 5G network. therefore, leveraging existing IMS deployments will be a key driver for VoNR.
5G system service requirements

The 3rd Generation Partnership Project (3GPP) technical specification (TS) 22.261 service
requirements for the 5G system brings different requirements to the efficient speech and video user
plane, media rate adaptations, augmented reality (AR), virtual reality (VR), extended reality (XR)
or mixed reality (MR) services, holographic communications, and telepresent robotics. These are
related to 5G system service requirements, and 5G networks need to be able to accommodate some of
these different services with VoNR deployments. Therefore, the need for VoNR deployments will grow.
Ultra-high-definition audio
VoNR employs ultra-high-definition audio through the Enhanced Voice Services (EVS) codec and
its extension of Immersive Voice and Audio Services (IVAS). This ultra-high-definition audio is
fundamentally used for voice calls. Furthermore, it will integrate with applications and contents, such
as announcements, music, conferencing, and real-time communications, leveraging VoNR.
VoNR high-level architecture

There are three main components associated with the VoNR architecture. These are the 5G New Radio
(NR) access network, 5G core network (5GC), and IP multimedia subsystem.
5G NR access and core networks

5G NR access and core networks transport call signaling and voice packets.
Call signaling is performed as a Session Initiation Protocol (SIP). SIP is the control signaling used
between the device and the IMS to initiate, maintain, and terminate real-time applications such as
voice, video, and messaging. From a Quality of Service (QoS) perspective, it is critical that signaling
cannot be delayed or dropped. In VoNR, SIP is transported through the 5G system, and the 5G system
is responsible for meeting the necessary QoS requirements.
Once the call is initiated, associated voice packets are carried by the 5G system in the form of a Real-
time Transport Protocol (RTP). It is possible to drop some voice packets without degrading the call
quality. However, minimizing the latency for the voice packets is crucial.
The different QoS types for signaling and voice packets require the employment of QoS flows with
different characteristics, hence different 5G QoS Identifier (5QI) values. VoNR uses the QoS flows
with 5QI value 5 for SIP signaling and 5QI value 1 for voice packets. The different characteristics of
those two 5QI values are shown in the following table (3GPP TS 23.501):
VoNR high-level architecture 177
SQL Resource Default Packet Packet Default Services

Type Priority Delay Budget Error Averaging
Loss Rate Window
1 GBR 20 100ms 0.01 200 ms Conversational voice
5 Non-GBR 10 100ms 0.0000001 Not applicable Ims signaling
Figure 8.1 – Characteristics of the 5QI values
The following diagram shows the established QoS flows of SIP signaling and voice packets required
for VoNR:
Figure 8.2 – 5G access and core networks
QoS flows are established in power distribution unit (PDU) sessions, and a PDU session creates
connectivity between the device, the gNodeB (gNB), and the User Plane Function (UPF). The UPF
provides connectivity to the IMS with an N6 reference point to allow subscribers to conduct calls.
IP multimedia subsystem
The IMS is the control infrastructure that provides call control services, and it consists of many
separate elements such as Call Session Control Functions (CSCFs) and some application servers,
and it utilizes some core network nodes.
CSCFs comprise Proxy CSCF (P-CSCF), Interrogating CSCF (I-CSFC), and Serving CSFC (S-CSCF).
P-CSCF is the first point of contact for home network subscribers in the IMS, and SIP signaling is
forwarded through P-CSCF. I-CSCF is responsible for selecting S-CSCF, and it communicates with the
Unified Data Management (UDM) for the selection procedure. S-CSCF is generally responsible for
processing, routing, and responding to SIP signaling messages. S-CSCF interacts with the Telephony
Application Server (TAS) in the call setup procedure.
The TAS is an IMS application server that supports supplementary service functionalities such as
calling line ID hiding and call diversion:
Figure 8.3 – IMS high-level architecture
Other elements included in the IMS are listed here:
• Media Resource Function (MRF)

• Interconnection Border Control Function/Transition Gateway (IBCF/TrGW)
• IMS Application Level Gateway/IMS Access Gateway (IMS-ALG/IMS-AGW)
• Media Gateway Control Function/IMS Media Gateway (MGCF/IMS-MGW)
• Breakout Gateway Control Function (BGCF)
VoNR initial procedures

Before the device can conduct VoNR calls, it must pass through a series of initial procedures. These
procedures are as follows:
• Subscriber provisioning
• IMS connectivity establishment
VoNR initial procedures 179
• IMS registration
• Third-party registration
Subscriber provisioning
Several network elements must be provisioned appropriately with subscriber information for VoNR
services. Some of these elements are the UDM, the Home Subscriber Server (HSS), the TAS and
Service Centralization and Continuity (SCC) application servers, the Policy Control Function
(PCF), and AAA servers in case of Wi-Fi calling.
The information indicating whether a subscriber is permitted access to the IMS for voice services is
contained within the subscriber profile in the UDM, which acts as a central repository of subscriber
information. The subscriber profile contains appropriate QoS profiles for the subscriber, and it
also contains whether roaming is supported. Likewise, the UDM within the IMS also keeps that
subscriber information.
Other elements, such as the TAS and the SCC application servers, must also be provisioned. The TAS,
for instance, contains subscriber information if supported with supplementary service functionalities
such as calling line ID hiding and call diversion. The TAS downloads these via Sh or other interfaces
such as Lightweight Directory Access Protocol (LDAP)/Diameter.
When the call is established, the PCF authorizes the appropriate QoS profiles for the subscribers.
Depending on the network deployment, some additional services, such as Wi-Fi calling, can be
supported. In this case, AAA servers are deployed. AAA servers also store the subscriber data, so they
need to be provisioned in the subscriber provisioning as well.
IMS connectivity establishment

Once the subscriber is correctly provisioned on the network it can establish the IMS connectivity. The
subscriber must first conduct the 5G registration procedure to register with the 5G network. After
the registration, the device/subscriber sends a PDU session establishment request to the network to
connect to a Data Network (DN).
Figure 8.4 – IMS PDU session establishment

For a regular data subscriber, the DN is usually the internet. However, for a VoNR subscriber, the
default DNs are both the internet and the IMS. Following the subsequent PDU session establishment
request, the PDU session providing connectivity to the IMS is established with a default QoS flow.
This default QoS flow has the 5QI value 5, and it carries SIP signaling. SIP signaling is required for
the next stage, which is the IMS registration procedure.
IMS registration
The IMS registration procedure includes many elements. However, P-CSCF, S-CSCF, and UDM are
the main elements taking place. P-CSCF serves as the ingress and the egress point to the IMS, provides
security, and manages SIP message routing. S-CSCF is the registrar in the registration procedure, while
the UDM has the security information together with the subscriber profile.
The IMS registration procedure is outlined in Figure 7.4. In step 1, the device sends an initial registration
request to the IMS. This request contains information such as the device capabilities and identification
information. Then in step 2, the P-CSCF obtains the security information from the UDM. That security
information allows the IMS network to send an authentication challenge down to the device. Finally,
in step 3, S-CSCF sends the authentication challenge to the device. Now, in step 4, the device attempts
to register again with the authentication response to the challenge in step 2 and 3. If the response is
correct, then in step 5, S-CSCF allows the device to access the IMS services:
Figure 8.5 – The IMS registration procedure
In terms of the IMS, the network is now set up to receive and process any mobile-originated or
terminated SIP signaling requests.
Third-party registration
Registration to the application servers such as the TAS is not part of the IMS registration procedure.
However, in the IMS registration procedure, S-CSCF interacts with the UDM and downloads the user
profile in the form of Initial Filter Criteria (IFC), which comprises a list of conditions upon which
the application servers can be registered on behalf of the subscriber:
Figure 8.6 – Third-party registration
Therefore, following the IMS registration procedure, S-CSCF sends a third-party registration to the
application servers listed in the IFC content.
VoNR call procedures

This section evaluates the activities that need to take place to ultimately set up a VoNR call.
High-level call procedure activities

Key procedures take place within the 5G system, IMS, and policy charging control elements such as
PCF to make a VoNR call. There is activity taking place with the SIP and the IMS. There is also activity
taking place with the Diameter protocol and PCF. Moreover, there is also activity taking place in the
5G access network itself. Hence, these three network domains work together to establish a VoNR call.
To go into this in more detail, the process starts with the concept of exchanging the Session Description
Protocol (SDP) messages: SDP Offer and SDP Answer. A flow of VoIP packets is required between two
parties in a VoIP call. Therefore, the IP address and ports between the two parties should be known.
Moreover, the voice codec and required bandwidth that need to be used should also be known. The
SIP doesn’t do this itself. It is the SDP, which is carried by the SIP. SDP message exchanges are used
between the calling and the called parties to agree on the codecs, the bandwidth, the IP address, and
port parameters.
Once done, P-CSCF uses the N5 reference point to interact with 1PCF, which in turn interacts with
the SMF by using the N7 reference point to determine QoS flow characteristics.
Once that policy and charging control interaction takes place, QoS flow is established. Therefore, the
call establishment is finalized by using SIP signaling. Remember that a bunch of policy and charging
control activities that take place as part of that SIP signaling exchange.
SIP signaling exchange

The diagram in Figure 7.6 shows the high-level SIP signaling flow. The signaling flow is passed through
the parties and their respective IMS. Signaling exchange starts with an INVITE message, which
carries the SDP Offer as a payload from the calling to the called party. The SDP is very significant
since it provides all the information regarding the media QoS flow. Remember, the SDP Offer carries
the following information:
• IP address and port information for the voice-packets flow

• The codecs for the voice encoding
• The required bandwidth to meet the Guaranteed Bit Rate (GBR) requirements of the QoS flow
In response to the SDP Offer, the called party sends an SDP Answer in 183 Session Progress provisional
message with the called party’s IP address, port, codec, and bandwidth information.
After exchanging the SDP Offer and the SDP Answer through INVITE and 183 Session Progress
messages, the PCF is triggered to start establishing the QoS flows in the 5G network for the media
flow. This is not shown in the following diagram and will be analyzed in the following section.
The next message that is sent is the Provisional Response Acknowledgement (PRACK), which is a
confirmation message to tell the called party that the calling party received the previous 183 Session
Progress message. In response to that, the called party sends a 200 OK message to confirm that it
received the PRACK.
As mentioned before, the 5G networks for the calling and called party will be busy setting up the
resources required for the media flow, and there is a technique used in VoLTE and VoNR called
preconditions. Fundamentally, a precondition is an agreement between the calling and called party
devices that before the called party is even alerted that somebody is ringing them, the calling and
called party start to establish their media bearers. That’s exactly what is happening in this flow. The
called party is not ringing at this point. The idea is to make sure that the correct QoS for the media
flow resources and additional media QoS flows are in place in the respective 5G networks for the
calling and the called party before the called party is alerted. So, UPDATE (SDP Offer) and 200 OK
(SDP Answer) in the signaling exchange are used to set up the preconditions and establish QoS flows.
Once the preconditions are met, it is now time to alert the subscriber. So, the called party device sends
back the 180 Ringing message to say that the called party device is now ringing. So, at this point, the
ringing tone will be heard by the calling party. When the called party answers the phone, a 200 OK
message is sent to the original INVITE message by the called party. Now, the call is in place, and the
last thing to do is just to acknowledge the called party with an ACK message.
Figure 8.7 – SIP signaling exchange
This is the high-level SIP signaling message exchange in a typical VoNR call establishment. It can be
more complicated, and several iterations of the UPDATE message can be transferred to manipulate
the codecs or other information.
QoS flow establishment

Remember that the default QoS flow, which has the 5QI value 5, carries the SIP signaling and it was in
place in the SIP signaling exchange for both calling and called parties. We also observed that during the
SDP Offer and SDP Answer messages in the SIP signaling exchange, additional QoS flows are created
to carry the actual voice packets. The following diagram outlines the steps for the establishment of
those additional QoS flows for both parties:
Figure 8.8 – QoS flow establishment
In step 1, the called party passes the SIP invite with SDP to the network and in response, it gets the
183 Session Progress message coming back from the called party. At this stage, P-CSCF in the IMS
analyzes the SPD Offer and SDP Answer, and it knows the full description of the media bearer, IP
address, ports, codecs, and bandwidth requirements.
In step 2, the information from the SDP is extracted and placed into Diameter to describe the media
bearer and be passed up to the PCF.
In step 3, the PCF generates a policy rule and sends it to the SMF. A policy rule describes the required
information, such as the following:
• Guaranteed Flow Bit Rate (GFBR) QoS flow at 40 kbps

• From 24.2.4.6:23554
• To 24.1.2.43:11224
In step 4, the SMF conducts a relevant message exchange with both the Access and Mobility Management
Function (AMF) and the UPF to modify the current PDU session with the PDU Session Modification
procedure. The result of the PDU Session Modification is the establishment of additional QoS flows
to carry voice packets. This procedure happens separately for both the calling and called parties.
QoS flow tear down

Whichever party ends the call, a BYE message will be generated. In this example, it is the calling
party that terminates the call. So, the calling party sends a BYE message through the IMS network,
and in response, a 200 OK message to that BYE message is sent from the called party. When the IMS
network sees this exchange of the BYE and the 200 OK messages, it knows that resources are no longer
required in the 5G access network on both legs of the call:
Interworking and voice call continuity 185
Figure 8.9 – SIP signaling exchange for call tear down
The following diagram shows the procedure for tearing down the call:
Figure 8.10 – Tearing down the call
In step 1, the P-CSCF analyzes the SIP BYE and 200 OK messages, and in step 2, it sends an indication
based on Diameter to the PCF that the VoNR session is ended. Therefore, in step 3, the PCF sends
an instruction to the SMF to remove the policy rule associated with the media flow. Consequently,
in step 4, the SMF will do another PDU Session Modification to tear down the QoS flow. Hence, the
QoS flow is removed for the voice packets, and all that remains is the QoS flow for SIP signaling.
Subsequently, the call is now torn down.
Interworking and voice call continuity

Interworking is required between VoNR-capable networks and the other legacy networks due to legacy
subscribers, coverage gaps, and utilization of other radio technologies.
The subscribers of 2G, 3G, and fixed-lined subscribers on Public Switched Telephone Networks
(PSTN) do not support SIP signaling. Therefore, the communication between legacy subscribers
and a VoNR subscriber requires appropriate SIP-based signaling and Real-Time Transport Protocol
(RTP)-based voice packet conversion.
In the rollout of each new technology, there exist some coverage gaps in RANs. So, in these coverage
gaps, the subscribers need to hand over to other technologies for connectivity continuity. This is also
valid for 5G rollouts. As the 5G networks roll out, there will be some coverage gaps that affect the
VoNR subscribers in terms of call continuity. Therefore, some handover techniques from 5G to legacy
networks, such as 4G or 3G, are required.
Finally, interworking might be required due to the utilization of other radio technologies such as
Wi-Fi calling.
Interworking with legacy voice networks

The communication between legacy subscribers of circuit switched (CS) networks (e.g., 2G, 3G, or the
PSTN) and a VoNR subscriber requires an appropriate SIP-based signaling conversion and RTP-based
voice packets conversion. This conversion is done with the Media Gateway Control Function (MGCF)
and an IP Multimedia Gateway (IM MGW), as outlined in the following diagram:
Figure 8.11 – IMS architecture break-out to other networks
The MGCF is responsible for the conversion of SIP signaling to Signaling System No 7 (SS7) or
Bearer-Independent Call Control (BICC) messages that are used by the CS domain networks. IM
MGW is responsible for converting RTP-based voice packets to Time-Division Multiplexing (TDM)
based delivery under the supervision of MGCF.
Packet switched handover from 5G to 4G

Even if the service providers have ubiquitous 5G coverage, there will still be some coverage gaps due to
high band frequency deployments, or there will be some point where the quality of service decreases.
In those cases, the VoNR call should be handed over to a different technology, such as 4G or 3G.
In this example, 5G to 4G handover will be evaluated. Here, the network needs to seamlessly hand
over a VoNR call to VoLTE. To achieve this, a Packet Switched (PS) handover must be coordinated
between the 5GC and 4G core network Evolved Package System (EPS), which requires interworking
between the AMF of 5G and the Mobility Management Entity (MME) of 4G. This interworking is
coordinated by the N26 interface between the AMF and the MME; hence, it needs to be provisioned
in the network.
Single radio voice call continuity

There might be scenarios where 5G network coverage is diminishing and where there is no 4G network
available. In this case, for voice call continuity, Single Radio Voice Call Continuity (SRVCC) can be
employed assuming the presence of 3G or 2G networks. SRVCC allows a PS-to-CS domain switch of
an ongoing IMS call. SRVCC has been in use for many years for 4G networks to switch the VoLTE call
to 3G or 2G networks where 4G coverage or quality diminishes. Note that 3GPP Release 15 doesn’t
cover SRVCC. SRVCC for 5G towards 3G is available in 3GPP Release 16.
The SRVCC procedure is coordinated through the AMF. The AMF uses the MME in the EPS as a
bridge to communicate with the Mobile Switching Center – Server (MSC-S) placed in the 3G core
network. The MSC-S is a core network node to control voice services.
When the handover decision is made by gNB, the AMF sends a handover request to the MSC-S via
the MME. When the MSC-S receives the handover request, it coordinates the 3G network to set up
radio resources for the voice call. After that, the MSC-S sends a redirect request to the SCC or to the
Access Transfer Control Function (ATCF) in the IMS, depending on the IMS deployment. So, this
redirect request basically takes the VoNR call away from the 5G packet switched network onto the
3G circuit switch core network:
Figure 8.12 – The SRVCC procedure

EPS fallback
Service providers may choose not to carry conversational voice with VoNR in the early 5G standalone
(SA) deployments, even if they have already deployed IMS for VoLTE services. One of the main
reasons for this is the patchy coverage of the 5G network in the initial phase of 5G SA deployments.
Therefore, they choose to continue to provide voice services with VoLTE even if the 5G device is
connected to 5GC. One way of achieving this requires IMS connectivity to both 5GC and the EPS.
IMS connectivity for 5GC is just required for SIP signaling between the 5G device and the IMS. The
following diagram depicts a sample network architecture for EPS fallback. EPS fallback allows fallback
to 4G and conducts a VoLTE call instead of a VoNR call.
Figure 8.13 – EPS fallback network architecture
In this architecture, the user equipment (UE) is connected to 5GC through 5G RAN, and it has the
default QoS flow for SIP signaling towards the IMS. When the UE initiates an IMS voice call, it will
be released to 4G RAN by gNB with RRC Release with Redirection or with Inter-System Handover.
When the UE attaches to the 4G network, the IMS voice call setup procedure for VoLTE continues.
Radio access technology fallback

Radio Access Technology (RAT) fallback is very similar to EPS fallback. In RAT fallback, Next-
Generation eNBs (ng-eNBs) are connected to the 5GC together with gNBs. Remember that ng-eNBs
provide 4G RAN coverage while it is connected to 5GC by supporting 5GC protocols. RAT fallback
allows fallback from 5G RAN to 4G RAN and to conduct a VoLTE call instead of a VoNR call in case
of patchy coverage in the 5G network. The following diagram shows a sample network architecture
for RAT fallback:
Figure 8.14– RAT fallback network architecture
In this architecture, a similar procedure to EPS fallback is in place. When the UE is connected to 5GC
through 5G RAN, it has the default QoS flow for SIP signaling towards the IMS. When the UE initiates
an IMS voice call, it will be released to 4G RAN by gNB with RRC Release with Redirection or with
Inter System Handover. When the UE attaches the 4G RAN, the IMS voice call setup procedure for
VoLTE continues. In this case, both RATs are utilizing the same 5GC.
Wi-Fi calling
In many VoLTE networks, Wi-Fi calling is already available. This is also called Voice over Wi-Fi
(VoWi-Fi). Therefore, there is no reason for the service providers to deploy Wi-Fi calling together
with their VoNR services by utilizing the common IMS.
All traffic is anchored in the UPF regardless of the RAN that the UE is using. This RAN can be 5G
NR or Wi-Fi. In the VoNR case, the UE utilizes the PDU session and the appropriate QoS flows for
the transmission of SIP signaling and RTP-based voice packets toward the UPF. However, the Wi-Fi
network, which includes the Access Point (AP), must connect to a Non-3GPP Interworking Function
(N3IWF) for security purposes. N3IWF provides direct connectivity to the UPF. Therefore, even
though the UE is on a Wi-Fi network, it can still set up VoWi-Fi call connectivity to the common IMS.
Similar to VoNR, bearers can carry out SIP signaling and voice packets as appropriate.
Figure 8.15 – VoNR and VoWi-Fi
In this section, we have analyzed the necessity of interworking between VoNR-capable networks and
other legacy networks. We’ve seen that the necessity of this interworking is due to legacy subscribers,
coverage gaps, and utilization of other radio technologies.
Summary
In summary, we have looked at some of the key concepts and drivers behind VoNR. Circuit-switched
networks are slowly being phased out and replaced with voice networks supported by IMS call control.
The voice requirements for the 5G system have been defined, so the standard bodies, specifically the
3GPP, have already been looking at what the 5G system needs to support with respect to voice. There
is already a great deal of interest in ultra-high-definition voice services.
We have also looked at VoNR’s high-level system architecture. It is comprised of three elements: the
5G access network, the IMS, and Policy and Charging Control (PCC). With respect to the 5G access
network, we have looked at some key elements such as the gNB, UPF, AMF, SMF, and UDM. Regarding
IMS, we have seen there are elements such as CSCFs, HSS, SCC, and TAS.
We have also analyzed VoNR’s initial procedures. Before making and receiving calls, the VoNR
subscribers must conduct these initial procedures, which include establishing resources in the 5G
network and registering with the IMS. The result of the overall procedure is the establishment of a
PDU session. In that PDU session, we have a QoS flow used to carry SIP signaling to the IMS.
We have seen that the 5G access network, the IMS, and PCC are required for the VoNR call procedures.
We have discussed voice packets being carried within the RTP, and the payload of that RTP being
the adaptive multi-rate codec or the enhanced voice services codec. Then we looked at the SIP
signaling exchange. We have seen that the INVITE and the 183 Session Progress messages need to
be exchanged so that we can swap the SDP Offer and SDP Answer. We have also analyzed INVITE,
Summary 191
PRACK, UPDATE, 180 Ringing, and 200 OK messages. Moreover, removing the QoS flows at each
leg of the call has been covered.
Finally, we have discovered the fact that interworking needs to occur with the PSTN or 2G-3G voice
networks and even for VoLTE. We have analyzed interworking with legacy voice networks, PS handover
from 5G to 4G, SRVCC, EPS, RAT fallbacks, and Wi-Fi calling.
In the next chapter, we are going to learn about different deployment scenarios of 5G networks. We
are going to discuss different architecture options for SA and NSA networks, which are mainly options
2, 3, 4, 5, and 7. We are also going to discuss different strategies for how Mobile Network Operators
(MNOs) can make the transition from Non-Standalone (NSA) to Standalone (SA) networks.
Part 2:
5G Network Design,
Deployment Models, and
Advanced Use Cases
This part of the book will cover the deployment options that are best suited for particular use cases, as
well as various applications of 5G technology. Next, it will glance at the operational and maintenance
aspects of these 5G networks and how they work with fixed wireline and satellite technologies. This
part of the book brings together the theoretical and practical aspects of 5G, enabling you to use it as
a handbook for deploying a 5G network with a range of enterprise applications.
This part of the book comprises the following chapters:
• Chapter 9, 5G Deployment Options

• Chapter 10, 5G Non-Standalone Networks
• Chapter 11, 5G Standalone Networks
• Chapter 12, 5G Infrastructure Design
• Chapter 13, 5G Network Slicing
• Chapter 14, 5G and Autonomous Vehicles
• Chapter 15, 5G Fixed Mobile Convergence
• Chapter 16, 5G and Satellite Communications
• Chapter 17, Automation, Orchestration, and Testing
9
5G Deployment Options
In this chapter, we are going to evaluate the two main architectures, namely Non-Standalone (NSA)
and Standalone (SA), that Mobile Network Operators (MNOs) and Communication Service
Providers (CSPs) can choose when transitioning from 4G to 5G technology. We will also examine
the migration paths and core network considerations in this transitional journey. Therefore, readers
will understand the deployment and migration strategies that can be applied by operators during
their own 5G journey.
• 5G network deployment architectures

• The different 5G deployment options defined by 3GPP
• 4G to 5G migration strategies
• The evolution of EPC to 5GC
5G network deployment architectures

In this section, we are going to analyze the details of NSA and SA deployment architectures that MNOs
and CSPs will choose for their 5G network deployments.
The first deployment approach is the NSA architecture. With this architecture, mobiles use two
generations of radio access technologies, 4G and 5G, simultaneously. Mobiles are connected to the 4G
network through the control and user planes, whereas they are connected to the 5G network through
the user plane only. In this architecture, mobiles only employ one core network, which is either the
4G Evolved Packet Core (EPC) or 5G Core (5GC) network, and are simultaneously connected to 4G
and 5G Radio Access Networks (RANs) in order to reach higher peak data rates, which are achieved
by combining the 4G and 5G bit rates.
196 5G Deployment Options
NSA deployments help MNOs provide an Enhanced Mobile Broadband (eMBB) service, which
delivers high data bandwidth and reliable connectivity. With the help of NSA architecture, 5G
networks can be quickly deployed with Next Generation NodeBs (gNBs) by utilizing the existing 4G
infrastructure. NSA basically allows MNOs to offer 5G speeds with the 4G EPC without the need for
the 5GC. Therefore, NSA deployments have been a popular choice within many 5G rollouts so far:
Figure 9.1 – NSA and SA architectures for 5G deployments
The second deployment approach is the SA architecture. The SA architecture consists of only one
generation of radio access technology used, with only one core network at the same time. The mobile
is either connected to the 4G RAN with the 4G EPC, which is the existing 4G deployment, or it is
connected to the 5G RAN with 5GC. In this architecture, there is only one generation of radio access
technology connected to a core network via both the control plane and the user plane. From hereon,
we will evaluate SA architecture in the context of the 5G deployments.
In 5G SA architecture, the mobile doesn’t depend on the 4G infrastructure as NSA does, where it
depends on 4G from the control plane. Moreover, with the employment of 5GC, SA architecture supports
all three use cases of IMT-2020, which are eMBB, Ultra-Reliable Low-Latency Communications
(URLLC), and Massive Machine Type Communications (mMTC). Therefore, 5G SA architecture
is the target architecture for MNOs in the long term.
5G network deployment architectures 197
The following is a general comparison of the 5G radio access and core networks (https://www.
gsma.com/futurenetworks/wp-content/uploads/2018/04/Road-to-5G-
Introduction-and-Migration_FINAL.pdf):
Figure 9.2 – Comparison of 5G radio access and core networks
Let’s talk more about those two architectures and focus on the main advantages and disadvantages
of each one in a bit more detail.
NSA network architecture

NSA architecture exploits 4G and 5G radio access technologies at the same time, so it combines the
existing 4G RAN and EPC with the New Radio (NR) technologies of 5G to provide faster and more
reliable service to its users. NSA architecture is the most common choice for existing MNOs who
want to deliver high-speed connectivity to consumers with 5G-enabled devices. Moreover, NSA
architecture helps MNOs leverage their existing 4G network to provide eMBB services with very low
Capital Expenditures (CAPEX).
In the NSA architecture, NR cells are combined with LTE cells to provide radio access with the dual
connectivity concept. The core network choice can be either the 4G EPC or even 5GC depending on
the investment and architecture choice of the operator. As a note, the architecture is still NSA even
if 5GC is utilized instead of a 4G EPC since two radio access technologies are used simultaneously
by the mobile user.
Figure 9.3 – NSA network architecture
Now, let’s talk a little bit more about this dual connectivity concept.
Dual connectivity for NSA architecture
Dual connectivity is also called Multi-Radio Access Technology Dual Connectivity (MR-DC). The
technical details of MR-DC can be seen in 3GPP’s TS 37.340. MR-DC is a functionality for which
multiple Receivers (Rx) or Transmitters (Tx) for mobile are configured to use radio resources from
two radio access technologies. With MR-DC, the radio resources are scheduled for the mobile by two
different schedulers, one from the eNB and the other from the gNB. In this architecture, the eNB is
the master node that provides access to the control and user planes between the mobile and the core
network, whereas the gNB is the secondary node and only provides access to the user plane. Both the
gNB and eNB should be connected by a network interface, which is usually X2 in an NSA configuration.
This interface carries the control plane between the gNB and eNB since in the NSA configuration 5G
mobiles are not connected to the gNB for control signaling. So, these are the conditions required to
make dual connectivity work properly in the NSA mode.
To sum up, mobiles get connectivity and access the user plane from two different network nodes,
getting LTE access from the eNB and NR access from the gNB. So far, we talked about the network
perspective. Note that dual connectivity must be supported by mobiles as well.
5G network deployment architectures 199
SA network architecture
So, what about the SA network architecture? SA refers to having an independent network and consists
of only one generation of radio access technology, so mobile users can either use the 4G RAN and the
EPC, or can use 5G NR and 5GC. In the case of 5G SA architecture, the connection to the 5G network
does not rely on the 4G network as is the case with NSA architecture. 5G SA architecture provides
both the control plane and the user plane for 5G mobiles.
The following figure depicts 4G and 5G SA structures. As can be seen on the left, the mobile is
connected to the EPC via the eNB with the control and user planes whereas, on the right, the mobile
is connected to 5GC via the gNB with the control and user planes:
Figure 9.4 – SA network architecture
In 5G, we have a new air interface, which is 5G NR, and we have a new cloud-native 5G core network,
so the 5G SA setup is a simplified RAN architecture. The SA architecture is the target solution for 5G
and it is a simple solution for MNOs to manage. 5G SA architecture, coupled with the cloud-native
5GC, will help MNOs support IMT-2020 use cases such as eMBB, URLCC, and mMTC while providing
a better end-to-end user experience. However, for this target, we need 5GC and we need to have good
5G coverage for an uninterrupted connection experience.
So far, we have examined the general structure of SA and NSA architectures. Within those two
architectures, there are different options defined by 3GPP that belong to either SA or NSA. Let’s have
a look at those options.
The different 5G deployment options defined by 3GPP

There are 10 different deployment options and sub-options defined by 3GPP in the late drop of Release
15. The main options are Option 2, 3, 4, 5, and 7, whereas the sub-options are 3a, 3x, 4a, 7a, and 7x.
Option 2 is SA architecture with a gNB and 5GC. Option 5 consists of 4G Next-Generation eNB
(ng-eNB) with 5GC. ng-eNBs are referred to as next-generation since they support 5GC network
protocols and are the updated versions of the existing eNBs. Option 3 involves NSA architecture and
includes the sub-options of 3a and 3x. The main difference between these sub-options is that some
new interfaces have been added in Option 3x – for instance, an S1-U interface between the EPC and
the gNB, which didn’t exist in Option 3. Also, the X2 interface between the eNB and the gNB doesn’t
exist in 3a but does in 3x.
Option 4 consists of the 5GC and the gNB with an ng-eNB as an NSA architecture and it also includes
sub-option 4a. Then, Option 7 has sub-options 7a and 7x, which use 5GC and an ng-eNB. So, the
main difference between Option 7 and Option 4 is that in Option 7, the ng-eNB is the master node
whereas, in Option 4, the gNB is the master node:
Figure 9.5 – Different 5G options defined by 3GPP
So these are the main differences – we will not go deep into the details of the other differences between
these architectures. Let’s now have a better view of the options from the SA and NSA perspectives.
SA options
There are three main variations of SA options within the 3GPP 5G deployment options. Firstly, Option
1, which wasn’t mentioned previously, uses an eNB and the EPC. This is the existing LTE network and
it is an SA architecture. Option 2 uses 5GC with a gNB:
The different 5G deployment options defined by 3GPP 201
Figure 9.6 – SA options
Note that this is the target architecture for 5G deployments as an SA option, considering there will
be enough 5G coverage. The last main SA architecture is Option 5, which uses 5GC together with
an ng-eNB.
NSA options
Option 3 (with 3a and 3x) is one of the most popular NSA options for 5G deployments, as we discussed
already. Option 3 utilizes the EPC as the core network, and it consists of the eNB as the master node and
the gNB as the secondary node. The importance of this option is that it helps MNOs to quickly deploy
and commercialize 5G with smaller CAPEX compared to an end-to-end 5G network deployment. The
drawback of this option is that it limits the IMT-2020 use cases to eMBB only. However, MNOs have
the opportunity to exploit a broad bandwidth range of 5G, some NR features, and massive Multiple
Input Multiple Output (MIMO) capabilities, which result in greater user throughput in total.
So, let’s move to the next option, which is Option 7 (with 7a and 7x). So, with this option, 5GC is
introduced and connected to both the ng-eNB and gNB. Note that here, we don’t use a regular eNB –
rather, we need to use an ng-eNB, which supports the 5GC protocols. With this option, the ng-eNB
is the master node and it provides access to the control plane and user plane. The secondary node is
the gNB, which is connected to 5GC for the user plane only.
The last NSA option is Option 4 (with 4a) and it is an evolution of Option 7. With this option, we
also have 5GC as we have in Option 7. The main difference between Option 7 and Option 4 is that
in Option 4, the gNB is the master node and the ng-eNB is the secondary node. Remember that the
master node provides access to the control and user plane while the secondary node only pertains
to the control plane:
Figure 9.7 – NSA options

The most important plane is the control plane because control plane signaling is a prerequisite for
mobiles to attach to the network. If the mobile does not achieve control plane signaling, then there
will be no user plane. Therefore, whether an MNO should opt for Option 7 or Option 4 depends
on the existing 5G coverage. Remember that the master node in Option 4 is the gNB, which means
gNBs are responsible for providing access to the control and user plane whereas, in Option 7, the
ng-eNB is the master node responsible for the control and user plane. Therefore, there should be wide
5G coverage for an MNO to opt for Option 4. If this is not the case and the MNO has a mature 4G
network, Option 7 would be a better choice.
A technical comparison of NSA versus SA

The following table is a technical comparison between some of the 5G NSA and SA options (https://
www.gsma.com/futurenetworks/wp-content/uploads/2018/04/Road-to-5G-
Figure 9.8 – Technical comparison between 5G NSA and SA options
As can be seen from the table, Option 3 and Option 7 are the choices for the transition to Option 2.
With Options 3 and 7, core network interworking is not required. However, forward compatibility
with SA architectures and with Release 16 onward is low or medium for Options 3 and 7, which also
makes these options temporary network architectures to pave the way to Option 2.
An economic comparison of NSA versus SA

The following table is an economic comparison between the 5G NSA and SA options (https://
www.gsma.com/futurenetworks/wp-content/uploads/2018/04/Road-to-5G-
4G to 5G migration strategies 203
Figure 9.9 – Economic comparison between 5G NSA and SA options
In this table, we can see that Option 3 is the low-cost deployment option for MNOs to quickly
commercialize 5G networks. With Option 7, the cost is high compared to Option 3 due to the
implementation of 5GC.
So far, we have examined SA and NSA network architectures. Let’s now move on to the possible
migration strategies for MNOs to move from 4G to 5G and from which options they should migrate
first to ensure to fully exploit the 5G capabilities and use cases.
4G to 5G migration strategies
The evolution from 4G to 5G can vary depending on an MNO’s existing network status and strategy.
First, remember that the control plane and UE signaling are managed by the master node, the eNB in
NSA architecture with Option 3, while it is managed by the gNB in SA mode with Option 2. Since 5G
coverage is very limited in the initial stage of 5G rollouts, the control plane is managed by eNBs with
nationwide 4G coverage, and as the 5G coverage expands, the control plane can then be managed by
gNBs. So, this is the essential consideration behind the 4G to 5G transition and migration strategy
from an MNO’s perspective:
Figure 9.10 – 4G to 5G migration strategies
Before introducing 5G, we assume that an MNO has an existing 4G network, covered by Option 1,
which comprises an eNB and EPC. As discussed previously, Option 3 can be quickly deployed by
upgrading the existing 4G nodes and deploying 5G gNBs, so the introduction of 5G with Option 3
helps MNOs quickly commercialize 5G with a quick time-to-market and low CAPEX. However, since
there is no utilization of 5GC, MNOs are limited to only providing eMBB services to their customers,
but they will still provide very high user throughput due to the wide range of bandwidth for 5G and
NR features.
The next step for an MNO can be to switch to Option 7 by utilizing 5GC. As we have discussed
previously, with Option 7, ng-eNBs are the master nodes providing access to the control and user
planes. That means if you do not manage the control plane with gNBs, then you cannot fully exploit
all the use cases even if you deploy 5GC. For instance, the URLCC use case has stringent network
delay requirements. That means that to meet this requirement, you need to carry the control plane on
gNBs and not on ng-eNBs because Option 7 requires the control plane carried by the ng-eNBs and
forwarded to gNBs, which causes additional delays.
So, the question is why would an MNO prefer Option 7 then? There are two reasons:
• The first one is there is still not enough 5G coverage nationwide and the MNO just wants to
boost the user throughput and experience in hot-spot areas with 5G.
• The second one is the device ecosystem. More 5G SA devices and mobiles will be released day
by day and MNOs should improve the customer experience with improved 5G services related
to a 5GC deployment.
4G to 5G migration strategies 205
The other option for an MNO is to deploy Option 2 only for local use cases with good 5G coverage and
with 5GC to fully exploit 5G use cases. For instance, the MNO can deploy 5G SA options in stadiums
to provide different 5G services, such as augmented and virtual reality. As another example, it could
be a smart factory where the URLLC use case is fully exploited.
The next migration exists by stepping into Option 4 when there is nationwide NR coverage. With
this option, gNBs will be the master nodes managing the control and user plane. Therefore, 5G use
cases and features such as URLLC, network slicing, or mMTC services would be fully exploited. The
advantage of Option 4 here is to support 4G mobiles and devices as well.
As a very long-term strategy, MNOs can switch to Option 2 solely nationwide and start releasing
the 4G network step by step. This very long-term strategy depends on the existing frequencies and
bandwidths that MNOs are working with. There are two things to consider here when releasing 4G
networks. First, how will nationwide coverage be provided? As we already know, 5G networks are
usually deployed on mid-bands and mmWave. To provide nationwide coverage, MNOs need to utilize
low 4G FDD frequencies for 5G or deploy numerous mmWave sites, which results in a high level of cell
densification and therefore a high level of energy consumption. The second thing to consider is there
will still be solely 4G-supported devices around many years from now, as we still have 2G phones in
use today. So, even if MNOs switch to Option 2 for 5G with nationwide coverage, they will still need
to have 4G networks to support their customers.
The following table is a high-level overview of the analysis of different migration steps – what we
have discussed so far with a few additions (https://www.gsma.com/futurenetworks/
wp-content/uploads/2018/04/Road-to-5G-Introduction-and-Migration_
FINAL.pdf):
Figure 9.11 – High-level overview of migration step analysis

Now, we have evaluated the different network deployment options. We either referred to the 4G core
as the EPC or 5GC for 5G. In the next section, we will cover some of the motivations for the evolution
of the EPC to 5GC at a high level and will compare the main differences between the EPC and 5GC.
The evolution of the EPC to 5GC

Let’s now talk about 5GC and understand how the evolution of 5GC happened. We will first look
at the main points that have driven the evolution of 5GC. After that, we will analyze the different
functions that are defined in 5GC.
So, at first glance, the 5GC architecture looks very different from that of the EPC, but this is not the
case. 5GC evolved from the EPC. The first step of this evolution involved Control and User Plane
Separation (CUPS) for the EPC. The EPC’s CUPS functions were reorganized into a Service-Based
Architecture (SBA).
You should also know that there are three principles behind the evolution of the 5GC network. The
first one is a smooth evolution, the second one involves maximizing the future value of 5G, and, finally,
the third one is maintaining service continuity.
CUPS and SBA have already been introduced throughout the book in relevant chapters. Now, we
will just summarize the main differences between the EPC and 5GC within the context of NSA and
SA deployments.
A comparison of the EPC and 5GC

The following table depicts the main differences between the EPC and 5GC from the perspective of 5G
deployments and use cases (https://www.gsma.com/futurenetworks/wp-content/
uploads/2018/04/Road-to-5G-Introduction-and-Migration_FINAL.pdf):
The evolution of the EPC to 5GC 207
Figure 9.12 – The main differences between the EPC and 5GC
In this comparison table, we can see that leveraging the EPC as a core network is just a temporary
solution for MNOs to quickly deploy a 5G network. However, in this case, the 5G services provided
will be limited to eMBB services. For instance, with EPC, there will be limited support for network
slicing, which is a crucial concept in 5G deployments.
Summary
In this chapter, we discussed two different 5G network deployment architectures, which are called NSA
and SA. We’ve also seen different deployment options that were determined by 3GPP by comparing
the architectures of the networks and the differences between the nodes utilized from the perspective
of the control plane and user plane.
With the knowledge we gained, we made some suggestions for MNOs on what the possible migration
strategies from 4G to 5G could be in the future.
We finalized the chapter by analyzing the evolution of the EPC to 5GC with the main comparison
between them made from the perspective of 5G deployments and IMT-2020 use cases.
In the following chapters, we will analyze the NSA and SA network architectures in more technical detail.
10
5G Non-Standalone Networks
The initial trials for 5G networks started as early as 2018, and by 2019, many tier-one operators already
had some presence of 5G in their networks. Therefore, the race among service providers to introduce
a 5G presence was substantial. The 3GPP standards body already anticipated this; hence specifications
were written to enable an architecture that would ensure faster rollouts of 5G. This provision was in
the form of 5G Non-Standalone (NSA) networks.
In this chapter, we will dig into the details of what an NSA network really means and ask, how is an
NSA network designed? What are the various technical aspects of this architecture and what are the
various types of NSA networks?
In this chapter, we’re going to cover the following main topics:
• Overview of NSA networks

• Types of NSA networks
• A deep dive into NSA networks
• 5G NSA – option 3 call flows
• Advantages and shortcomings
Introduction to NSA networks

An NSA network is one in which multiple radio technologies are combined to provide 5G coverage.
A master node controls the control plane, and the user plane can be split between a master and a
secondary node. As mentioned in the introduction, the main aim of introducing NSA networks was
to gain speed in deployment, and this was primarily achieved by building on the existing 4G network
and reusing its components, thus reducing the time to roll out drastically. Let us take an example of
a 5G NSA network, and later, we will go over the various other types of NSA networks.
The following figure illustrates 5G NSA option 3x:
210 5G Non-Standalone Networks
Figure 10.1 – 5G NSA option 3x
This diagram shows what a typical deployment of NSA looks like. There is an existing Long-Term
Evolution (LTE) evolved NodeB (eNB), which is connected to an existing 4G Evolved Packet Core
(EPC) core network. Now, this is augmented by 5G gNodeB (gNB) New Radio (NR) coverage.
Another way to look at this scenario is that in a service provider’s existing LTE coverage area, a new
5G NR is introduced to increase capacity. This 5G radio is controlled by a master 4G eNB, which in
turn is connected to the 4G core network EPC depicted by the dotted line. There is no 5G core network
involved here. All the control plane signaling from EPC to gNB NR is handled by the master eNB.
Hence the secondary gNB is completely managed by the master eNB, so it cannot stand alone, thus
the name NSA. Since there are two radios involved, the connectivity is also called dual connectivity
(E-UTRA NR-Dual Connectivity (EN-DC)).
Therefore NR is only a secondary node that is completely controlled by the master eNB. The data
plane, however, can be tunneled via S1-U directly from the Serving Gateway (SGW) in the EPC gNB.
When User Equipment (UE) is in the coverage area of this gNB, it is connected to a 5G radio, but at
the backend, the 4G core network is still leveraged.
Types of NSA networks

The NSA options include options 3, 3a, and 3x in addition to option 4 and option 7. In the introduction,
we took the example of a deployment option known as option 3x. Let us further discuss the main
features of this deployment option in detail:
• All control plane signaling is handled by the eNB.

• The eNB is connected to a 4G core for data and signaling.
• There is data plane connectivity between both the gNB and EPC and the eNB and EPC. In
this case, both the master nodeB and the EPC are capable of splitting the data traffic between
the eNB and gNB.
Types of NSA networks 211
The other two options of the same flavor are options 3 and 3a, as shown in the following diagrams:
Figure 10.2 – NSA network option 3
The features of option 3 are as follows:
• All control plane signaling is handled by the master eNB.

• The eNB is connected to the EPC for data and signaling. The signaling for gNB is sent from
the master eNB via the X2-C interface.
• The gNB is only connected to the eNB (master), and the Packet Data Convergence Protocol
(PDCP) sublayer of the eNB splits the traffic so that some traffic is sent to the gNB via the
X2-U interface.
Next, we will go over the aspects of option 3a:
Figure 10.3 – NSA option 3a
The features of option 3a are as follows:
• All control plane signaling is handled by the master eNB.

• The eNB is connected to the EPC for data and signaling. The signaling for gNB is sent from
the master eNB via the X2-C interface.
• The gNB is connected to the SGW via S1-U. In this option, the EPC splits the traffic.
The last item in the preceding list brings us to another new concept of split bearers, which answers
the question of how data is split to go to the gNB and eNB.
This brings us to the introduction of a few new terms:
Figure 10.4 – NSA DC bearers
Let’s define each of the terms from the diagram one by one:
• MCG bearer: The Master Cell Group (MCG) bearer in DC is a bearer whose radio protocol
stack is only located in master nodeB and only uses the master nodeB resources. The S1-U
connection to the SGW is terminated in the master node itself; the secondary node is not
involved in the direct transport of data to the EPC.
• SCG bearer: The Secondary Cell Group (SCG) bearer in DC is a bearer whose radio protocol
stack is only located in the secondary node to use secondary nodeB resources. In this case,
there is an S1-U connection from the secondary node to the SGW; hence there is a direct path
for data to pass to the EPC from the secondary nodeB.
• Split bearer: This is a combination of the previous two bearers, in which the bearer’s radio
protocol stack is located in both the master and the secondary nodeB.
This pictorial representation of these split bearers will help to further enhance our understanding:
A deep dive into NSA networks 213
Figure 10.5 – Split bearers
One practical use case of this scenario is the implementation of voice and data networks in a particular
coverage area. This can be implemented using option 3x because the lightweight voice (Voice over LTE
(VoLTE)) traffic can leverage 4G eNB and the heavy-weight data service is provided by the 5G NR.
In this section, we were introduced to the basic concept of NSA networks and the terms related to it.
In the next section, we will see the various options for NSA and Standalone (SA) networks.
A deep dive into NSA networks

In this section, we will dive deeper into the topic and also see the types of networks that can be deployed,
which translates to the various options that a service provider may have if they introduce 5G in their
network. This also highlights another aspect of the great flexibility in deployment that was ushered
in by 5G architecture. The following table provides a list of all the various options:
Network Type Connectivity Core Network Master RAT Secondary RAT 3GPP Term
Option
Standalone Option 1 EPC LTE - LTE
Standalone Option 2 5GC NR - NR
Non-Standalone Option 3 EPC LTE NR EN-DC
Non-Standalone Option 4 5GC NR eLTE NE-DC
Standalone Option 5 5GC eLTE - eLTE
Non-Standalone Option 7 5GC eLTE NR NGEN-DC
We can see that 5G can be rolled out in various combinations of cores and radios; some of them are
SA options (which we will explore in the next chapter), and some of them are NSA options:
• Option 1 is an SA option that denotes a 4G network, comprising 4G RAN and 4G packet core
with no secondary radio.
• Option 2 is an SA option comprising a 5G core and 5G radio. This is also a popular deployment
option across service providers. This also does not have a secondary radio, hence SA.
• Option 3 is an NSA option. This comprises a 4G packet core connected to a 4G radio as the master
node and a secondary 5G radio. This is a popular NSA deployment choice among operators.
• Option 4 is an NSA option with a 5G packet core connected to a 5G radio as master and a
secondary enhanced LTE eNB, which is an eNB that can connect to a 5G core; it is primarily
used to serve a 5G device over 4G radio.
• Option 5 is an SA option with a 5G core connected to an enhanced LTE radio.
• Option 7 is an NSA option with a 5G core connected to a master enhanced LTE radio and a
secondary NR node.
• Option 4, option 5, and option 7 benefit the service providers and their subscribers to continue
using legacy 4G equipment while connecting to 5GC.
Next, we will review one of the most popular NSA network architectures.
The architecture of the option 3 NSA network

The following diagram shows the high-level components of an option 3-based NSA network:
Figure 10.6 – 5G option 3 NSA network

When considering the requirements to implement an option 3-based NSA design, the following are
some key aspects to take into account:
• 5G option 3 capable UE
• An existing 4G packet core
• A 4G master eNB
• A 5G secondary NR
• X2-C denotes the signaling interface between the master and secondary radios
• X2-U denotes the data interface between the master and secondary radios
• S1-U is the data path between the radio and EPC
• S1-MME is the signaling path between the radio and EPC
One of the benefits of the preceding architecture is that it would be capable of servicing both 5G and
4G customers using the same infrastructure. As noted in the first bullet, to access a 5G network, an
appropriate 5G device is needed. Hence when an operator rolls out a 5G network, it would need to
wait for its subscribers to procure a 5G-capable device to be able to connect to the network.
Higher data rates of multiple Gbps per UE can be supported. Use cases such as fixed wireless and
mobile broadband can be implemented via this deployment option. Millimeter wave (24-52 Ghz)
frequencies can be supported, which would result in very high peak data rates.
Consider a scenario using the preceding diagram; the UE denoted here is a 5G UE, the blue area
shows 4G coverage by eNB, and the yellow area shows 5G coverage. When the UE is in the blue area
on the left, it detects a strong 4G signal and latches onto the 4G radio, and connects to the 4G packet
core in the backend. However, when the UE moves to the yellow area denoting 5G coverage, the UE
gets a strong 5G signal and latches onto the gNB, which is connected to the same EPC. Hence the UE
can use 5G radio using the same existing packet core. This substantially reduces the time to market
for operators to launch 5G.
It should be noted that the NSA network is capable of supporting only a subset of use cases. Mission-
critical use cases cannot be supported by this option.
It is important to consider another two aspects of network evolution as we move to 5G (not mandatory
for option 3 NSA, but good to have):
• Separation of control and user plane

• Virtualization
The tendency has been to move toward a Control and User Plane Separation (CUPS)-based network.
What that essentially means is the separation of control and data plane across the network in the
various nodes. The key nodes here are the SGW and Packet Network Data Gateway (PGW) in the
EPC, to be split into SGW-c, SGW-u, PGW-c, and PGW-u. Similarly, on the radio side, CUPS can be
achieved. The reason behind this design choice is to make more processing power available to support
faster data rates by decoupling control plane responsibilities, hence resulting in a faster speed.
Virtualization has been key in network function implementation since the beginning of the last decade.
It was successfully adopted in later deployments of 4G networks where the appliance-based network
elements were migrated to virtualized ones. This not only reduced the CAPEX but also increased
capacity in the network, as deployments were now commercially available off the shelf, as compared
to the earlier expensive custom appliance-based deployments, but it also reduced the time to market
as it adopted advanced orchestration and network automation techniques for deployment.
Now, considering the favorite choice of operators has been to start with option 3 for initial rollouts
of 5G, let us go over the various migration paths available to them, as shown in the following table:
Path Use Cases Support Key Aspects

EPS to SA option 2 Full set of 5G use cases • Small impact on existing
4G network
• Efficiencies of 5G core can
be leveraged
• The legacy 4G network
needs to be retained
• 4G-5G interworking will
be required to support
seamless mobility
• Voice can be supported
via IMS
EPS to NSA option 3 Limited support for 5G use cases • Leverage existing
LTE network
• Rapid time to market
• Features limited to 4G
core, hence advancements
of 5G core are absent
• Procedures are based
on EPC
• Voice can be
supported by existing
VoLTE infrastructure
NSA option 3 to NSA All 5G use cases can be supported • Migration of core network
option 4/SA option 5 should be accounted for
• 5G core benefits can
be leveraged
• EPC needs to be retained
• Wide area NR can
be supported
• IMS voice can
be supported
• No CS interworking
from 5GS
NSA option 3 to SA Full set of 5G use cases can • Packet core migration
option 2 be supported needs to be accounted for
• EPC needs to be retained
• Wide area NR can
be supported
• IMS voice can
be supported
from 5GS
NSA option 3 to NSA Full set of 5G use cases supported • Core migration needs to
option 4/SA option 2 be accounted for
• Initially limited use
cases until 5GC is
fully operational
• Impact on NR and LTE
during migration
• IMS voice supported
with 5GS
The following diagram shows 5G deployment options mapping into spectrum bands:
Figure 10.7 – Migration path from 4G to 5G across spectrum bands
The current 4G deployments leverage low bands of the spectrum, which are sub-1 GHz and 1–3 GHz, as
shown in the preceding figure. Then comes 5G NR, which is deployed in the mid bands of 3.5–8 GHz;
this greatly augments the capacity of the network and can support higher data rates and low-latency
use cases. NR in mmWave, along with existing wide area LTE RAN, ensures both good coverage and
high throughput and serves subscribers with both 4G and 5G UEs. High-band NR (mmWave) with
a 24–40 GHz downlink can be leveraged to further add capacity.
With the deployment of a 5G core, option 2 comes into play. This is initially the case, in the mmWave
spectrum and mid bands for fixed access, but later, when the LTE spectrum can be re-farmed, it can be
extended to cover wider areas. In this case, tight interworking with LTE can ensure seamless handover
between 4G and 5G during UE mobility.
5G NSA – option 3 call flows

In this section, we will dig into details of the call flow of 5G UE connected to an option 3x-based NSA
network. Let us go over the initial registration call flow step by step:
5G NSA – option 3 call flows 219
Figure 10.8 – Option 3x call flow part 1
1. Consider DC-capable UE that moves into the coverage area of a 5G NR radio; the UE sends an
Attach Request message to the master eNB, and the Packet Data Network (PDN) connectivity
request has a UE Network Capability field with a Dual-Connectivity with New Radio
(DCNR) flag on.
2. Since all signaling is handled by the master eNB, it sends the S1 initial UE message to the
Mobility Management Entity (MME), which contains the Attach Request and PDN Connectivity
Request with the DCNR bit on.
3. After a successful authentication procedure, a Diameter Update Location Answer message
is sent to the Home Subscriber Server (HSS) by the MME. This message contains the NR as
Secondary RAT field, which indicates the intention of the UE to leverage the 5G NR.
4. The HSS responds positively as the UE has the plan for 5G use and also sends the bitrates. Note
that for 5G use, additional fields called the extended max bit rate have been included, which
support Gbps bitrates.
5. The GTPv2 Create Session Request is sent from the MME to the SAEGW-C (a combination
of SGW and PGW control plane nodes). This request also includes the DCNR field.
6. The SAEGW-C then sends the Diameter Credit Control Request-Initial (CCR-I) message to
the Policy and Charging Resource Function (PCRF). This message contains the request for
Extended APN-AMBR values needed to support higher 5G speeds.
7. The PCRF responds with a Diameter Credit Control Answer-Initial (CCA-I) message with
the necessary policies in addition to the 5G AMBR values.
8. In this step, the SAEGW-C sends a PFCP Session Establishment Request to the SAEGW-U.
This message is relevant here as it depicts a CUPs-based architecture with control and user
plane functions separated in the SGW and PGW. The PFCP Session Establishment Request
message is used to inform the user plane about the parameters and packet handling rules of this
particular session for this UE so that the user plane is able to handle the packets accordingly.
The user plane function responds with a PFCP session establishment response; this message
contains a success code or an error code in case any of the rules have failed to apply.
9. The PFCP Session Modification Procedure is then carried out and the SAEGW-C sends a
PFCP: Session Modification Request with the SAEGW-U. Any earlier rule can be updated
or removed during this procedure.
10. The Create Session Response is then sent from the SAEGW-C to the MME, which contains an
acknowledgment of the successful or unsuccessful session setup with an appropriate response
code. This also contains the 5G-like APN-AMBR values.
11. The MME then sends an Initial Context Setup Request with the NAS container with Attach
Accept to the master eNB. This again contains the new 5G parameters of Extended UE Aggregate
Bit Rate Uplink and Downlink.
12. The Attach Accept is then sent to the UE from the master eNB.
13. The MME then sends an Initial Context Setup Response containing the F-TEID of master
node eNB.
14. The UE sends a NAS message with Attach Complete and Activate Default Bearer Accept to
the eNB, which is carried transparently to the MME.
15. The MME then sends a Modify Bearer Request; this message contains the F-TEID information
received from the eNB in the Initial Context Setup Response message:
16. The SAEGW-C then sends the PFCP: Session Modification Request message to the SAEGW-
U. This message contains the F-TEID information received from the eNB. The user plane then
sends the PFCP: Session Modification Response with the F-TEID of the user plane.
17. The SAEGW-C then sends the Modify Bearer Response to the MME with the F-TEID
information, which is sent to the radio.
18. Once the tunnel information is exchanged, the data path is set up and the UE can access it.
The following call flow indicates the addition of a 5G secondary node.
19. The master eNB sends an RRC Connection Reconfiguration message to the UE. This message
assigns radio resources to the UE:
Figure 10.11 – Option 3x call flow - part 4
20. The UE extracts NR information from the LTE RRC Connection Reconfiguration message.
The UE also extracts the NR RACH configuration information and C-RNTI for 5G access. It
then prepares the RRC Connection Reconfiguration Complete message and sends it to the
master eNB. This message also contains the NR RRC Reconfiguration Complete message
meant for the secondary gNB.
21. The master eNB then sends the NR RRC Reconfiguration message received from the UE to
the secondary gNB via the X2AP SgNB Reconfiguration Complete message. At this point,
the eNB starts copying data to the gNB.
22. The master eNB informs the gNB about the PDCP sequence number and the HFN for all the
bearers, which are transferred to the 5G NR gNB.
23. The SGW can now send data to the MN-eNB. The master eNB keeps forwarding the data to
the secondary NR gNB.
24. Since the UE has not yet established the data path, the gNB is buffering the data it receives
from the packet core.
25. The master eNB then sends an S1AP E-RAB Modification Indication request to the MME,
which notifies the MME that the data bearer is being switched from 4G-eNB to 5G-NR.
26. The MME updates this information with the SGW via a modify bearer request. The data path
is now switched from the eNB to the gNB.
Advantages and shortcomings 225
27. The response is then sent to the MME indicating a successful or an unsuccessful path switch.
28. The master eNB then sends an End Marker Packet to the eNB. This marks the end of the
transmission to the secondary 4G-eNB. All packets henceforth will be handled by the 5G-NR-gNB.
29. MME sends an E-RAB Modification Confirmation message to the master eNB.
30. Data now flows to the secondary 5G-gNB.
This concludes a typical option 3-based call flow. It is crucial to understand the details of these
procedures to be able to design and implement an NSA network.
Similarly, there are further details available in the specifications for specific call flows for the other
deployment options, which can be referenced for further reading.
Advantages and shortcomings

The main advantage of deploying an NSA-based network is the speed of deployment, which drastically
reduces the time to market. This architecture enables service providers to provide 5G services by
merely upgrading the RAN to NR while using the EPC from the legacy 4G infrastructure. This also
reduces the cost of deploying 5G. This is a good option for transitioning to a fully fledged 5G SA
network with a 5G core.
The main disadvantage is that it is limited in support of 5G use cases. This option can support
enhanced broadband-based use cases. However, the more advanced Ultra-Reliable Low-Latency
Communications (URLLC) use cases, live Vehicle-to-Vehicle (V2V) communications, and use cases
leveraging network slicing would need an SA network.
Summary
We have seen by now that the push for NSA networks comes from the strong desire of the industry
to accelerate the standardization of NR architecture so that the time to market can be cut down. The
greatest advantage is the ability to leverage existing legacy network infrastructure.
NSA access was standardized in 3GPP Release 15 in December 2017.
In this chapter, we have covered a typical NSA network in detail. We have discussed the different
bearers such as MCG, SCG, and split bearers. We have also explored the other available deployment
options and their key features.
We explored the various migration paths from the EPS network to 5G and finally, we delved into
a detailed 5G-NSA call flow. We concluded the chapter by briefly discussing the advantages and
disadvantages of the NSA network.
In the next chapter, we will learn about the design and implementation of a typical 5G SA network
and delve into the details of its procedures.
11
5G Standalone Networks
In this chapter, we will understand the essentials of a standard 5G Standalone (5G SA) network’s
design and deployment.
We will go through the specifics of designing a 5G SA network from scratch, as well as understand the
requirements for implementing a standalone network and the use cases that can be realized with it.
We will also go over the adoption of 5G SA options in private (non-public) networks and the design
considerations involved.
In a nutshell, we will cover the following topics:
• Benefits of a 5G SA network and use cases

• 5G SA network design fundamentals
• Network resilience and failure design
• Network performance analysis
Benefits and use cases of a 5G SA network

5G SA networks unleash the true power of this generation of wireless communication; they use 5G
New Radio (NR) and 5G core for both signaling and data transfer. This type of deployment allows all
5G use cases to be implemented, including Ultra Reliable Low Latency Communications (URLLC),
mission-critical services use cases, machine-type communications, IoT, enhanced broadband, and
fixed wireless access, to name a few. This generation of wireless telecommunications truly enhances
user experience and provides unparalleled speeds. It also supports network slicing, wherein the same
physical network can be logically separated into separate slices catering to different types of service.
Mobile network operators are exploring new avenues for generating revenue. The 5G SA network
architecture enables them to do just that by being able to have an enterprise focus as the enterprises
themselves are undergoing a digital transformation. Thus, in addition to the traditional end-subscriber
focus, mobile network operators are now able to offer services to enterprises and cater to use cases
such as smart cities, smart factories, vertical market solutions, autonomous vehicles, robotic vision,
228 5G Standalone Networks
and so on. The standalone architecture is completely free of the baggage of legacy telecom networks.
It is a fully virtualized service-based architecture, cloud-native, and built for scale, resilience, and
speed. This new microservice-based infrastructure ushers in the scope of automation in deployment,
operations, and maintenance. This, in turn, results in speedy deployment of the network and ease of
maintenance. Automation also comes in handy to onboard new use cases tailored to suit an enterprise’s
needs while at the same time driving down costs significantly.
As the 3GPP has standardized the cloud-native approach of 5G SA networks, this has provided room
for innovation and for open source communities to thrive, thus helping advance the unprecedented
pace of network enhancements.
The following illustration shows what a commercial 5G macro network would look like:
Figure 11.1 – Commercial 5G SA network components and their 3GPP references
This model of deployment also opened up possibilities for mobile network operators to choose between
a variety of options, ranging from an on-prem private cloud-based model to a public cloud or hybrid
model that meets both options halfway.
In this section, we have been introduced to the 5G SA network. In the upcoming sections, we will
delve into details of the fundamentals of designing such a network.
5G SA network design fundamentals

A standard 5G SA architecture uses only one radio technology called 5G NR, along with a 5G core. In
addition to enhancements in the wireless and core networks, to deliver low latency and high reliability,
the IP core network had to also undergo a major transformation. The data traffic from the radio network
is transferred to the 5G core network by a large network of switches and routers. There have been
5G SA network design fundamentals 229
enhancements in the routing domain that have reduced the latency of such carrier backhaul networks
immensely. Two such examples are the emergence of segment routing and the SD-WAN networks.
These highly intelligent and programmable networks can transport large volumes of data with minimum
delay and high accuracy.
Essential precursors
In this section, we will go over the most important considerations to keep in mind when designing
a network. As the 5G technology provides unprecedented levels of flexibility in design, it also brings
in the chance to overbuild or underbuild the network, or to build a network that is not suitable for
its intended purpose. For example, if a network does not need support for edge use cases, there is no
point in investing in an edge data center.
To begin with, the following are some of the fundamental questions that should be answered to build
a network that would be built-to-purpose, robust, and resilient. These questions are usually answered
in a requirements-gathering workshop between the mobile network operator architecture teams and
sometimes include the various vendors supplying the necessary components:
• What use cases are expected to be supported?

This is key to designing a network to purpose. 5G supports use cases spanning IoT, mission-
critical applications, and enhanced broadband scenarios, each of which has very different
requirements in terms of network design. Mission-critical applications need a highly resilient,
low-latency network, whereas enhanced broadband needs a higher capacity network and IoT
would need neither low latency nor high capacities.
Building a network that supports all of these at the same time at scale would be very expensive
and most likely a futile exercise as investing in a low-latency and high-capacity network are
both very significant. Hence, it is of utmost importance to know what should be supported in
the network that is being built.
• Who is it being built for?
Since 5G technology has been developed while keeping industrial automation and enterprises
in mind, it is very important to know who the network is being built for. A macro network
is most likely going to have enterprise, individual end subscribers, and IoT devices, all at the
same time. Hence, it is important to know the distribution of each of these types of consumers.
• What number of subscribers need to be supported?
This is key to understanding the scale of the network. The number of subscribers determines
the radio units to be deployed in an area, the number of data centers and their size, and the
type and quantity of servers, switches, and routers. In a nutshell, overbuilding a network would
lead to larger expansion and lower usage of the network, hence the ROI would plummet. At
the same time, underbuilding a network would lead to KPI drops and outages that would be
detrimental to user experience.
• What volume of data needs to be supported?

In addition to the number of subscribers that would connect to the network, it is also important
to know what max throughput is expected per user and what total throughput is expected
for a region. In addition to this, the traffic profile is also of great importance as it helps to
curate the network accordingly – for example, the percentage of UDP traffic versus TCP. The
throughput will determine the capacity of the IP backhaul needed to connect the 5G core and
radio components. It will also determine the number of servers allocated for a particular site for
the control and user plane functions. Greater throughput per user will mean a larger number
of computes dedicated to the user plane functions.
• What is the latency requirement?
There needs to be a maximum tolerable latency number for each network, beyond which there
would be packet timeouts and large amounts of retransmissions. In a 5G network, since all the
signaling protocols between network functions (NFs) are HTTP-based, it is important to meet
latency requirements as there would be retries for each timeout. This can cause a signal storm
in the network that will hog up bandwidth that can otherwise be used for processing calls.
• What is the right data center design?
There are many choices available as far as the data center design is concerned. This ranges
from hosting NFs completely in a public cloud to hosting them completely in the service
provider network:
Figure 11.2 – Options for hosting network functions

The preceding figure explains a few possible ways of laying out a data center. For example, in
a large macro 5G network, the mobile network operator may choose to host certain analytics
engines, automation engines, and more in a public cloud. Then, for a large geography, the
service provider network can be further subdivided into national data centers, regional data
centers, near-edge data centers, and far-edge data centers. The national data center can host
control plane functions centrally, especially the ones that are not sensitive to latency. Then,
regional data centers can have user planes that can cater to low-latency requirements. Near-
edge data centers can host centralized components of the distributed RAN and far-edge data
centers can host the radio heads. Though it is completely possible to co-locate most of these
data centers, it’s a best practice to segregate them. This will help in building the capabilities of
geo-redundancy as multiple data centers of each kind can serve as backup servers in case of
one data center failure.
• Does roaming need to be supported?
Roaming is a need for macro networks deployed by service providers as an end subscriber
coming in from another location may need access to the network. However, it is not necessary
to have a roaming design for enterprise networks such as an IoT network or a factory floor
as there won’t be a possibility of device mobility outside of the region. Hence, the investment
in SEPP that may be necessary for supporting a robust roaming architecture can be avoided.
• Does it need to support enterprise networks?
Most service providers have a requirement to support enterprise networks. The most important
concern for enterprises is their data security and isolation. Hence, while planning support for
enterprise networks in a macro environment, considerations should be made about how to
implement a VPN and how to separate the traffic of each enterprise not only in the routing
domain but also end-to-end in the data center.
• Does it need to interact with legacy networks?
Interworking is a key aspect of network design. If the network needs to support seamless
handover between 4G and 5G, considerations can be made about implementing an N26 interface
between MME and AMF, which would lead to faster handovers while increasing the complexity
of the network greatly in terms of configuration, call flows, debuggability, and maintenance.
• Does it need to interwork with Wi-Fi?
Wi-Fi is a great augmenting technology as it takes the load off a mobile network operator.
Voice and video calls over Wi-Fi have been supported widely since 4G networks. However, to
interwork seamlessly with Wi-Fi, an interworking function needs to be introduced that would
act as the gateway between Wi-Fi and mobile network traffic, also translating the control plane
signaling between the two for compatibility.
• Does it need to support network slicing?
Network slicing is a great feature introduced in 5G. It has caused a lot of excitement in enterprises,
many of which are requesting a separate slice for their traffic.
Now, supporting network slicing not only requires the necessary software in the NFs but also
a whole new level of investment in automating the slicing mechanism and implementing the
slicing architecture. Hence, the service provider would also need to invest in slicing software
(automation) in addition to the regular network function it needs to run a 5G network.
• What is the current capacity of the IP backhaul?
All the data that is sent from the gNBs to the user plane function and the internet would need
to go through some kind of IP backhaul. An increase in user traffic would need a larger capacity
of that backhaul network. Hence, the mobile network operators would need to invest greatly in
increasing the capacity of the network and also onboarding newer technologies such as segment
routing and SD-WAN for intelligent and faster convergence of the network.
• What is the nature of the geographic area that needs to be covered?
The geography and population distribution in a region determine the design of the data center.
A thickly populated region would need more compute muscle than a thinly populated region.
For example, if a country has north, south, east, and west zones and for some reason, the north
zone has only one-fourth the population of the east zone, there is no use building a similarly
sized data center in the north and east. A better design would be to concentrate the computer
power in the east and keep the north region a lightweight one.
• What is the projected data usage and type of network data consumed for the particular
geographic area?
The type of data consumed is also very important. Various data profiles such as video streaming,
voice/video, and file transfers have different requirements from the network. For example, while
packets per second are high for video calls, the data size of each packet is small. However, for a
file download, the size of each packet would be high and the packets per second would be low.
The higher packets per second will demand a higher tax on the CPU, so the number of CPUs
in a server should be scaled accordingly.
• What are the redundancy and failure requirements? What is the maximum tolerable limit for
a data outage in case of a network component failure?
For any network, one of the key aspects of it being usable is that it must be reliable. Most
networks guarantee five 9’s in terms of availability, which means a network targets to attain
99.999% availability. In addition to this, it is important to understand what the maximum
duration of an outage is tolerable in case of failure; in that case, a redundancy design can be
made. Geo-redundancies are slower but sometimes more cost-effective compared to building
local redundancy at each data center, which has many times faster convergence time.
• How is the network going to be monitored?
Once a network has been deployed, the major task is to monitor the network for failures. The
larger the network, the more complex it can be as there would be thousands of alarms every
second, ranging from minor to critical ones that can cause revenue loss. Hence, it is a good
idea to build intelligence to correlate alarms and flag only the ones that can cause a loss in
revenue; the others can be addressed in time. Many operators have built-in software that can
automatically check the contents of the alarm and automatically raise tickets with the concerned
vendor. Such systems enhance the manageability of the network greatly.
• How is the network going to be maintained and upgraded?
Once a large network has been deployed, the next concern is its maintainability. Upgrades on one
component can adversely affect the functioning of another and can cause service loss. Hence, it
is important to create a dependency chart and automate the feasibility analysis of an upgrade.
• How are faults going to be reported?
Reporting faults is critical to the performance of the network. If faults are reported promptly and
acted upon in time, it can save outages. A lot of third-party software is available that processes
logs and alarm data to prune out the potential issues that can cause an outage predictively.
• How is the network going to be scaled in or out?
Network scaling is largely an automated task nowadays. It is possible to automate a network
controller that can proactively determine the usage of each of the network applications and
hardware, and when the usage is above a certain threshold, it can spawn new nodes. At the
same time, if a certain application is underutilized, it can scale down to free up computes.
Hence, scaling in and out can be an on-the-fly operation with some added manual inputs from
operators in the final stages.
• How is the network going to be tested?
It is a valuable investment to onboard a network-testing framework right from the time of an
early proof of concept or lab testing. Such a testing framework can not only test the individual
network component but the entire network as a whole. Performance and regression tests can
be scheduled at predefined intervals so that defects can be caught well before they are found
in production.
The answers to these questions will certainly iron out most of the design requirements.
Next, we will go over the basic components needed to complete a call in a 5G SA network and how
they interact with each other to register a device and establish a Protocol Data Unit (PDU) 5G session.
5G SA network components and end-to-end call flow

The following diagram denotes the essential network functions that participate to establish a call
between two users – in this example, John and Jane:
Figure 11.3 – Essential 5G network functions
In the preceding figure, we have depicted two mobile phone users, John and Jane. Both have the
latest 5G handsets and are ready to make a call to each other. In Chapter 2, End-to-End Architecture
Components, Concepts, Security, and Transport, we learned about the functionality of each of these
NFs in detail. Now, let us go over the high-level steps that will take us through the procedure of a data
call after the UE has been powered on.
Phase 1 – UE registration process
The UE registration process is the way the UE gains access to the network. It is the way the UE and
the network mutually authenticate each other, and the network authorizes the UE to use the network
resources according to its subscription or mobile plan:
Figure 11.4 – UE registration – part 1
Let us go over each step one by one:
1. The UE sends the Random Access Preamble to the gNB. This preamble is referenced with the
help of a Random Access Preamble ID. This preamble is derived from a Zadoff-Chu sequence.
2. The gNB sends a Random Access Response to the UE with an assigned temporary C-RNTI value.
3. Then, the UE sends an RRC Connection Request Message to the gNB, which contains the UE
identity and the establishment cause.
4. The gNB responds with an RRC connection setup, which is sent to signaling radio bearer1 (SRB1).
The message contains the radio bearer configuration and master cell group information elements.
5. The UE sends an RRC Connection Setup Complete dedicated NAS message stating registration
request to the gNB, which is intended to be sent to the AMF.
Figure 11.5 – UE registration – part 2: authentication

6. The gNB then sends an initial UE message to the selected AMF (AMF selection is explained
in detail in the 3GPP specification 23.501 section 6.3.5). This message carries the Registration
Request message that was sent to the AMF from the UE via the gNB. This message also contains
the RAN UE NGAP ID and the RRC establishment cause.
7. The AMF sends the UE authentication request to the AUSF to receive the authentication vectors
and algorithm information.
8. The AUSF sends an Authentication Request to the UDM to get the vectors for authentication.
9. The UDM generates authentication vectors and sends them to the AUSF (SUPI, R, AUTN,
Kausf, and XRES*).
10. The AUSF sends the master key to the AMF, which is used by the AMF to derive the other
security-related keys (r, auth, and xhres*). The SUPI is also returned to the AMF.
11. The AMF sends a downlink NAS Transport Message to the gNB carrying the NAS
authentication request.
12. The NAS message is transported to the UE by the gNB. The UE checks the AUTN and generates
the RES* and Kausf.
13. The Uplink Information message is sent to the gnB from the UE, which carries the RES*
computed by the UE.
14. The AMF computes the HRES* and compares HRES* with HXRES*. The Uplink NAS transport
message carries the RES* to the AMF.
15. The AMF sends an authentication request to the AUSF and sends the RES* that was received
from the UE. The AUSF compares RES* with XRES* and verifies the identity.
16. The AUSF sends an authentication response with SUPI and Kseaf to the AMF. The AMF sends
Kamf from Kseaf.
17. The AUSF sends authentication confirmation to UDM on successful verification.
18. The UDM responds with an acknowledgment to the AUSF.
Figure 11.6 – UE registration – part 3: authentication and AMF registration

19. A DL NAS Transport message is then sent from the AMF to the gNB.
20. The NAS message carrying the selected security algorithm, UE security capability, and more
are sent to the UE.
21. A UL Information Transport Message is then sent to the gNB to be sent to the AMF; this
contains the Security mode command Accept message.
22. The UL NAS transport message is sent to the AMF and the DL Cipher starts. The AMF selects
the UDM.
23. The AMF sends the UE_CM registration request to the UDM. This contains the SUPI, AMF
3GPP Access, and AMF ID. The UDM checks the UE authentication.
24. The UDM sends the UE_CM registration response to the AMF.
25. The AMF sends a UE subscriber Data Management GET message to the UDM.
26. The UDM responds with Access and Mobility Subscription Data and SMF selection
Subscription Data.
27. The AMF sends a Subscribe to change notifications message to the UDM.
28. The UDM sends an acknowledgment for the subscribe to change notifications message.
29. The AMF sends a DL NAS transport message to the gNB.
30. The gNB sends the NAS message requesting the IMEI to the UE.
31. The UE sends the IMEI using the UL information Transport Message to the gNB.
32. The gNB sends the UL NAS transport message containing the IMEI to the AMF.
33. The AMF uses the IMEI for the equipment identity check procedure with the Equipment
Identity Repository (EIR).
34. The EIR acknowledges the request:
Figure 11.7 – UE registration – part 4: AM policy association
35. The AMF may then send AM Policy Association Request to the Policy Control Function (PCF).
36. The PCF sends a Data Repository query to the UDR using SUPI as the key to retrieve Access
and MM Policies.
37. The UDR sends an acknowledgment to the PCF and returns the requested Access and MM policies.
38. The AM PCF then sends a Data Repository Subscribe message to the UDR, requesting
notifications for any policy changes.
39. The UDR acknowledges this.
40. The PCF then acknowledges the completed AM policy association to the AMF and sends it to
the policies and triggers it has received from the UDR.
41. The AMF sends a NAS Registration Accept message to the gNB to be sent to the UE.
42. The gNB transfers the NAS message to the UE.
43. The UE responds with a UL Info Transport message carrying the NAS Registration
Complete message.
44. The NAS Registration Complete message is then transported to the AMF via the gNB:
Figure 11.8 – UE registration – part 5: UE policy delivery
45. The AMF then sends a UE Policy Association Create message to the AM PCF. This sequence
is very similar to the AM Policy association sequence noted previously.
46. The AM PCF then sends the Data Repository Query to the UDR.
47. The UDR responds with the UE policy data.

48. The AM PCF then sends a Data Repository Subscribe request to the UDR so that it can be
notified of any changes in policy in the UDR.
49. The UDR acknowledges the subscription request.
50. The AM PCF then sends the UE policy Association Acknowledgement message to the AMF
with the policy request triggers.
51. The PCF, in turn, sends an N1N2 message transfer subscribe message to the AMF to ensure
that it is notified of UE policy message delivery.
52. The AMF acknowledges this.
53. The PCF sends the N1N2 message transfer message to the PCF with the UE policy.
54. The AMF sends an acknowledgment.
55. The AMF then sends the DL NAS transport message to the gNB to transfer the NAS message
carrying the UE policy to the UE.
56. The NAS message is delivered to the UE with the UE policy.
57. The UE sends its response to the AMF in a NAS message, which is transported by the gNB.
58. The NAS message is delivered to the AMF.
59. The AMF sends a Notify message to PCF to convey the successful completion of the UE procedure.
60. The PCF acknowledges the notification.
61. The PCF sends a Data Repository Update to the UDR with the UE policy data.
62. The UDR acknowledges this.
This marks the end of the UE registration procedure. Here, we have seen that UE is authenticated
and authorized, the security procedures are completed, and the various UE policies for access and
mobility are obtained. The UE is now ready for the next step, which is to establish a PDU session.
Phase 2 – PDU session establishment
Following the PDU session establishment procedure, the UE can access the network. A PDU Session
establishment can be of the following types:
• When a UE initiates a PDU Session Establishment Procedure

• When a UE initiates a PDU Session handover between 3GPP and non-3GPP networks
• When a UE initiates PDU Session handover from EPS to 5GS
Once the PDU session has been established, the UE can access the data network (or VoNR network
as applicable).
Let us go over the various steps in a 5G PDU session establishment procedure. This procedure assumes
that the UE has already registered with the AMF:
Figure 11.9 – PDU Session Establishment – part 1

The steps are as follows:
1. The UE sends a PDU Session Establishment Request to the AMF; this is transported via the
gNB. The NAS message containing the PDU Session Establishment Request within the N1
SM container is sent to the AMF. This container includes information about the PDU session
ID, Requested PDU Session Type, Requested SSC mode, 5GSM Capability PCO, SM PDU
DN Request Container, and the number of packet filters. When the request type is “Initial
Request,” it is a request to establish a new PDU Session. If the request type is “Existing PDU
Session,” it means that it is referring to an existing PDU Session that is switching between
3GPP and non-3GPP access, or a handover from a 4G EPC network. The third type is that of
an “Emergency Request,” which is used to request a PDU Session to access emergency services.
In this example, we will assume the first type – that is, “Initial Request.”
2. The AMF selects an SMF. It may use the NRF to discover SMF instances unless SMF information
is available by local configuration.
3. The AMF receives the PDU Session Establishment Request and looks into the “Request Type.”
In this case, it indicates an “Initial Request” and determines that the PDU session ID is unique
and unused for any other. Next, it determines the DNN that the UE is attempting to connect
to with the help of the information in the request message; the AMF sends the Create SM
context Request message to the selected SMF. This Create SM context Request message contains
information such as the SUPI, DNN, nSSAI, PDU Session ID, Serving network, and request
type, among others.
4. If the SMF has not registered with a UDM for this PDU Session ID, it will now do so using
Nudm_UECM_Registration (SUPI, DNN, and PDU Session ID). The SMF sends a UDM
Registration Request. The UDM will store the information it has received from the SMF, such
as the SUPI, SMF identity, SMF address, and the associated DNN and PDU Session ID. The
UDM then responds with a UDM registration response if Session Management Subscription
data for the particular SUPI, DNN, and S-NSSAI combination is not available locally. SMF
then retrieves it using Nudm_SDM_Get (SUPI, Session Management Subscription data,
DNN, and S-NSSAI) and also subscribes to be notified whenever a modification is made to
this subscription. The subscription data contains information about the Allowed PDU Session
Type, Allowed SSC modes, default 5QI, ARP, and Session-AMBR, all of which can be used to
determine the characteristics of the session that has been initiated.
5. The SMF then sends a PDU Session Create SM Context Response to the AMF, which includes
a cause field and the context ID. The cause field will contain either an accept or a reject cause.
The accepted scenario will contain the aforementioned context ID. The cause also determines
the fate of the transaction so far as being successful or unsuccessful.
6. Optional: secondary authorization and authentication. If this step is needed, then an AAA
server is needed for the transaction to complete the authorization and authentication process.
7. PCF selection is undertaken by the SMF. This can happen with the PCF ID provided by the AMF,
or the PCF retrieved by querying the NRF or by local configuration. The SM Policy Association
Establishment procedure is then undertaken by the SMF to get the default PCC rules from the
PCF, which will be used by the PDU Session that is going to be established.
8. Since the request type is “Initial Request,” the SMF selects an SSC mode for the PDU session
and also selects UPFs accordingly. At this stage, the SMF also allocates an IP address to the UE.
9. The SMF performs the SM Policy Association Modification procedure, which can contain
information about the policy control trigger conditions that have been met. Most importantly,
it informs the PCF of the IP address prefix that it allocated to the UE in the previous step.
10. The SMF then initiates an N4 Session Establishment/Modification Request to the UPF. This
is the message that provides details about the packet detection, enforcement, and reporting
rules that the UPF will install for this particular PDU Session. The UPF acknowledges the
message sent by SMF and provides the installation status of each rule that was sent by SMF to
be installed on the UPF.
11. The SMF then sends a Namf_Communication_N1N2MessageTransfer message to AMF. This
message carries information for the consumption of the AMF and also some information that
will be sent further to the RAN(N2) and UE(N1).
Some of the information that SMF sends across to the AMF and GNB is as follows:
PDU Session ID
QFI(s)
QoS Profile(s)
CN Tunnel Info
S-NSSAI from the Allowed NSSAI
Session-AMBR
PDU Session Type
User Plane Security Enforcement information
UE Integrity Protection Maximum Data Rate
The following is some of the information to be carried to the UE:
PDU Session Establishment Accept
QoS Rule(s)
QoS flow level
Selected SSC mode
S-NSSAI(s)
DNN
Allocated IPv4 address

Interface identifier
Session-AMBR
Selected PDU Session Type
Reflective QoS Timer (if available)
P-CSCF addresses
12. The AMF sends the N2 PDU Session Request to RAN. This contains the information it received
from the SMF.
13. The gNB then sends the UE the important information the SMF has sent, such as its IP address
in the PDU Session Establishment Accept message and the other details mentioned in Step 11.
14. The gNB then sends an N2 PDU Session Response to the AMF. This message will also contain
the N3 tunnel information that will be used by the UPF to send data traffic.
15. The AMF sends a PDU Session Update SM Context Request to SMF. It sends the information
it received from the RAN previously.
16. The SMF will initiate an N4 Session Modification Procedure to the UPF, where the N3 tunnel
information is conveyed to the UPF. The UPF sends an N4 Session Modification Response to
the SMF as a response. At this time, the downlink path for data traffic to flow is established.
17. The SMF then sends a PDU Session Update SM Context Response to the AMF as an
acknowledgment of Step 15.
18. The SMF may send an optional PDU Session SM Context Status Notify (release). If any of the
steps after Step 5 have failed, the SMF informs the AMF and tells it that it has released any
resources that it had allocated to the UE PDU session.
19. The SMF sends an IPv6 Router Advertisement to the UE via the UPF in case the Session type
is IPv6 or IPv4v6. After this step, the uplink path of the traffic is established.
20. If the PDU Session establishment fails after Step 4, the SMF will unsubscribe from notifications
about modifications to the UDM and will also deregister the given PDU Session.
This concludes the PDU establishment procedure. After this procedure, the user device can access
the network resources, browse data, and surf the internet. We learned about the different types of
PDU Establishment procedures in detail in Chapter 6, which showed us not only how a UE attaches
for data calls but also voice calls and Wi-Fi. All these messages are transported over HTTP/S and
TCP. Hence, the underlying IP backbone network must be built robustly. If there is a delay or loss of
packets in the backbone, messages would be retransmitted and timeouts in the TCP window would
occur. This might lead to a signaling storm and high call failure rates.
Designing a macro network

Designing a macro (public) 5G network entails planning and architecting its subcomponents, as
listed here:
• Data center design: One of the most defining aspects of the usability and reliability of a network
is its data center design. There are many ways to design a data center. One of the popular high-
level design templates is shown here:
Figure 11.10 – Data center layout in a network
In the preceding diagram, the geographic area where the network is supposed to be laid out
is divided into five zones: north, south, east, west, and central. The central data center can
host the management, orchestration, testing, analytics framework, and some control plane
NFs. The regional data centers can host the user-plane functions and latency-sensitive control
plane functions. Each regional data center can have a co-located redundant data center, which
is most likely in an active-active configuration with 50% of traffic going to each one. If one of
the regional data centers fails, the other one in the same zone can take over.
Geo-redundancy can be planned across zones. For example, the north and west zones can be
geo-redundant. Geo-redundancy helps when both data centers in a zone fail – for example,
in the event of a natural disaster. In this case, the standby zone picks up the traffic. Also, note
that for a geo-redundant pair, traffic should be sized so that at any point in time there is, at
most, 50% usage so that in the event of a region failure, the standby zone can cater to not only
its local traffic but also the traffic coming from the failed zone.
The regional data centers feed in traffic from the edge data centers or the radio units.
• Radio access planning: Radio surveys and planning are an important aspect of laying out the
base stations in the network. There is a significant impact on the placement of radio heads and
the tilt of antennae. The terrain and obstacles are closely studied to select the most appropriate
position to place a radio unit that has maximum coverage and minimum interference.
• IP core – backhaul design: The IP core design is another prime aspect of network design.
With the advancement in radio and core technology and the explosion in data speeds, the total
carrying capacity of the backhaul network had to also be expanded greatly and built to tolerate
faults and outages. Note that a network will have a mix of legacy and new routers. This is why
planning an architecture to enhance capacity and performance using both legacy and new routers
and routing technologies is very challenging; security and isolation must also be kept in mind.
• Packet core design: The packet core design should be aligned to the use cases planned, the
transactions per second, the user throughput, latency, and the quality of service requirements.
Based on the data center design selected, the packet core can be distributed or centralized. It
is possible to have a centralized control plane and distributed user plane functions. It is also
possible to have distributed data and control plane functions that are collocated in regional
data centers. Since the control plane transactions are all HTTP-based and transported via TCP,
latency can cause retransmissions, which, in turn, causes a huge signaling overhead. Hence,
it is also important to tune the timers so that unnecessary retransmissions can be avoided.
• Scaling: After the network has been built initially, it is just a matter of time before it will need to
be scaled. Hence, it is important to bear in mind the future scope of expansion while planning a
network. This headroom for expansion should be accommodated in every stage and component
of the network, from the rack space and power requirements in the data center to the server’s
routers/switches and IP allocation.
Automation comes in handy for scaling applications in or out as 5G cloud-native design tasks
such as orchestrating and configuring servers and network functions can be done at the click
of a button.
• Test framework design: A robust test framework that can easily onboard test cases and scenarios
goes a long way when building a robust and resilient network. Tests should aim to verify the
functionality and test the performance of each network function, as well as test failure scenarios
such as reboot or server replacement scenarios, test other component failure scenarios, and
test geo-redundancy, latency, performance under load conditions, border scenarios, alarm
testing, upgrades, KPI dashboard verification, and so on. Hence, each aspect of the network,
including its functionality, performance, operations, and maintenance, should be tested. It is
also highly desirable to have a test suite that runs nightly to catch regression issues and perform
network health checks.
• Maintenance framework: The maintenance cycle of a network is undeniably the longest.

Even while 5G networks are being deployed the world over, the legacy 2G networks are still
being maintained to support older 2G devices. Hence, lots of expenses are incurred by mobile
network operators to maintain a network, and hence the need for tools that can help maintain
these large, complicated networks easily. Many third-party tools integrate seamlessly with the
network elements and schedule upgrades automatically and also perform health checks and
rollbacks if necessary. The induction of automated tools in the network maintenance cycle has
not only reduced the time to upgrade a network but also the chances of human errors.
• Monitoring framework: Dashboards for monitoring a network are the only windows into
the health of the network. Many third-party and open source tools do a great job of alarm
correlation and reporting. Patterns in logs and transactions can also be monitored and parsed
by such tools to predict future failure. Diagnostic tools can be run by an automation framework
to detect failure causes, which are then reported by the tool.
• Analytics engine: The mobile network is a crucible of invaluable information. The signaling
messages, transactions, and events all add up to data that can be mined for patterns and user
trends that can help in many ways, such as rolling out a new business plan or providing user
trends to applications and third-party applications, all while abiding by data privacy laws.
In this section, we delved into the details of designing a macro or a public network. In the next section,
we will delve into the details of designing a private (non-public) network, which is expected to be
extremely popular with enterprises.
Designing a non-public (private) network

Just like designing a public network, the first and foremost consideration while designing a private
network is to determine the use case to be applied. In most cases, the non-public network is for an
enterprise or campus. In either case, certain simplifications in design can be applied. For example, in
an enterprise network, there is hardly the need to charge subscribers, and roaming is seldom required.
Hence, the minimum number of network functions needed to design such a network is very small.
The most essential network functions needed are as follows:
• 5G NR for radio access

• AMF for access and mobility management
• SMF for session management
• UDM and UDR for subscription management
• UPF for the data plane
• PCF for the policy (optional – good to have)
In some cases, an unlicensed CBRS spectrum can be used; this is a more popular approach in the
USA. If an unlicensed spectrum is used, then the allotment of the same is done by a Spectrum Access
System (SAS) provider.
Several deployment options can be adopted by the enterprise. Firstly, the enterprise can choose to
deploy its private network on its own. In this case, the enterprise adopts the end-to-end responsibility
of deploying and maintaining a network. There is another common alternative that enterprises go for,
which is to have a mobile network operator provide the enterprise network. This way, the responsibility
of maintaining the network is largely on the network operator.
Next, let us go over the various types of private network options:
Enterprise Premises Service Public Cloud Description

Provider Premises
Radio, license None None Wholly private network.
management, Deployed, operated, and
control and user maintained entirely by
plane functions, the enterprise.
analytics,
Complete data
orchestration, and
ownership by
maintenance software
the enterprise.
Radio, license None Analytics, Analytics, orchestration,
management, and orchestration, and and maintenance
control and user maintenance software is maintained
plane functions software in the public cloud
while all the data and
signaling are done on
enterprise premises.
Partial network
information is shared
and visible to the
cloud provider.
Control and user Radio, license Analytics, Only control and
plane functions management, and orchestration, and user data are on the
subscription management maintenance enterprise premises.
software
and/or The service provider is
responsible for license
analytics,
management and
orchestration, and
subscription management.
User plane function Control plane or Only user data is on the

functions, radio, license enterprise premises.
analytics,
management, and
orchestration, and The service provider is
subscription management
maintenance responsible for radio,
and/or software license management,
subscription
analytics,
management,
orchestration, and
and control
plane functionality.
User plane function Radio, license Control plane, In this type of

management, and analytics, deployment, only the
subscription management orchestration, and user data resides in the
maintenance enterprise premises;
software the rest of the signaling
and management is
done in the service
provider network or the
public cloud.
Next, we will go over a list of industry use cases that leverage private networks:
Figure 11.11 – 5G use cases

In the preceding figure, we can see the enterprise-focused use cases for which private networks can be
implemented. One of the sectors is Industry 4.0, including tools and parts inventory control, remote
maintenance, and collaborative autonomous robots.
Private networks can be widely deployed in the transport and utilities sector and consumer-focused IoT.
With that, we have gone over the design considerations and use cases of a private network. Another
important part of the design is the stability and resilience of the network against failures. We will
examine this in the next section.
5G network resilience and failure design

5G networks are expected to cater to mission-critical applications, so there will be circumstances
where network failure can have a disastrous effect. Hence, tolerance to failure should be considered
at every step during the design. Let us go through each consideration one by one, from the highest
level to the finest granularity:
Figure 11.12 – Levels of redundancy built into a network

Network performance analysis 253
The idea behind failure design is to have an alternative path along which traffic can flow in case of a
single component failure. Most networks are expected to experience no impact from a single failure;
some highly resilient networks have tolerances for more than one failure. Let us go into the details of
the various redundancies built into the network shown in the preceding diagram:
• Data center redundancy: Every data center should have another data center in a geographically
separate site as a standby – this is known as geo-redundancy. In the preceding figure, Site 1 and
Site 2 are geo-redundant. Hence, if there is a complete failure of Site 1 for some reason, Site 2
will be fully equipped to carry the traffic seamlessly.
• Rack redundancy: Every cluster that comprises an application should span more than one
rack. If there is an issue and there is damage to the rack, the servers in the cluster from the
other rack would be able to service the traffic.
• Power source redundancy: There should be more than one power source for each rack and
server. If there is an issue with one power supply, the other one should take over.
• Server redundancy: Server issues are most common in the network as each server has multiple
components in it, such as memory, storage, CPUs, and network interface cards that can become
faulty over a certain period. Hence, it is always advisable to spread an application over a cluster
spanning multiple servers, preferably in separate racks.
• Router and switch redundancy: There should at least be two instances of each router/switch
so that, in case of a failure, there is an alternative path along which traffic can flow.
• NF redundancy: At each site, there should be two instances of the same NF, preferably in different
clusters so that a software or hardware issue on one does not cause a service interruption.
Similarly, a geo-redundant instance of an NF should be planned so that it has enough capacity
to deal with the failover traffic in addition to the local data center traffic.
It is best to avoid a single point of failure at every level of design. Keeping these points in mind, a
resilient network can be designed that can deal with single failures seamlessly.
Network failures are one of the key reasons for network performance and the network Key Performance
Indicators (KPIs) to dip. In the upcoming section, we will delve into network performance analysis.
Network performance analysis

Once a network has been deployed successfully, the next important step is to measure the performance
of the network. Network performance tests can be conducted at many points and in several ways in
the network. Let us go over some of the basic network performance tests:
• Single UE test: A single UE is attached in a cell with no other devices in that cell and tested
for maximum throughput. This test will give the maximum throughput that can be attained
in that particular 5G cell.
• Single UE test in busy conditions: A single UE test in busy conditions gives us an idea of how
the network performs in peak hours.
• Maximum aggregate throughput test: This test is conducted on a user plane function to
determine its capacity.
• Load tests: These can also be performed to test the capacity of the backbone IP network.
• Maximum number of subscribers: This test specifies the maximum number of subscribers
that can be processed by a site and can be tested.
• Maximum site-wise throughput.
• Single-component failure: This can be tested to check the impact and convergence in the
failure duration.
In addition to this, KPI dashboards are used to specify the health of the network. These dashboards
typically look like this:
Figure 11.13 – 5G KPIs
The following figure depicts a typical 5G KPI dashboard at the network operator. Here, you can see
various statistics, such as the 5G PDU session setup rate, the 5G PDU session release rate, handovers,
and more. Hence, this gives us a high-level idea of what rate devices are connecting to the network,
as well as their states:
Network performance analysis 255
Figure 11.14 – Extended 5G KPIs
The following dashboard is another example of how network operators might want to see their alarms.
Note that each alarm is assigned a category of critical, major, or minor, as per the degree of disruption
it will likely cause to the network. Here, five critical alarms must be addressed by the network operator:
Figure 11.15 – Alarm dashboard

In this section, we saw a variety of KPI dashboards that give us an idea about the current performance,
active alarms, and health of the network.
Summary
In this chapter, we learned about the main design principles of a 5G SA network. First, we understood
the requirements that need to be established before the start of the design phase. To do so, we looked
at how to design a 5G SA network, including a standard call flow. We also looked at the design aspects
and deployment options for private networks. Finally, we enlisted the design tenets of a failure-resilient
network and reviewed how to monitor and dashboard a network.
At this point, we know how to design a 5G SA network, both private and public. We also know how
to analyze requirements to build a high-performing robust network.
In the next chapter, we will learn about 5G and autonomous vehicles.
12
5G Infrastructure Design
In this chapter, we will focus on the infrastructure design required to successfully implement the
network foundation for 5G. We will look at the changes and evolution in the infrastructure as the
industry evolves from the prior generation to standalone 5G. In addition, we will look at the impact
of the maturity of cloud computing in Information Technology (IT) and its impact on the operators.
Here, we’ll cover the following main topics:
• Understanding NFV
• MEC-C-RAN (centralized/cloud RAN)
• O-RAN
• Using hybrid clouds
Understanding NFV
Network Functional Virtualization (NFV) borrows several concepts from enterprise IT to utilize
server virtualization. This alleviates the need for custom hardware systems and appliances for various
network functionalities. The goal of NFV is to decouple the hardware from the software stack for 5G.
This reduces the dependence on custom-built hardware. In Figure 12.1, we show the high-level 5G
core architecture to illustrate the relationship between the different concepts covered in this chapter.
NFV provides a great deal of flexibility to network operators to improve and enhance the capabilities
of their network. This includes the ability to adopt virtualization for software applications. This allows
independence from custom-built and expensive hardware in the form of specific physical appliances as
part of the main network architecture. Companies such as Ericsson are driving the thought leadership
around NFV: https://www.ericsson.com/en/nfv.
The adoption of NFV makes it easier to load-balance, scale up and down, and move functions across
distributed hardware resources. With continual updates, operators can keep things running on the
latest software without interruption to their customers. So, let us understand the role of the building
blocks of NFV.
258 5G Infrastructure Design
Virtual Network Functions (VNFs) are a software category that can provide essential network
services on commonly used computing hardware without the need for purpose-built appliances. See
Figure 12.1 for the high-level NFV architecture:
Figure 12.1 – NFV infrastructure architecture
Let us gain a basic understanding of the NFV architecture to appreciate why this is very popular in
the industry today and how it can promote agility and automation to rapidly deploy 5G network
infrastructure. The NFV architecture includes the following elements:
• VNFs: Application software

• NFV Infrastructure (NFVI): Virtualization layer
• NFV Management and Orchestration (MANO): Orchestration layer
NFV makes the architecture very modular. Some typical advantages of NFV include the following:
• Ease of upgrade of the network as it breaks free from monolithic architecture

• It reduces the network hardware space and energy needs, making it more sustainable
• The ability to replace the modules enhances the life of the network hardware
• Overall, it reduces the Total Cost of Ownership (TCO) for network operators
Next, let us look at the role of NVF and related concepts and their inter-relationships. Figure 12.2
shows the 5G architecture at a very high level and where NFV fits:
Understanding NFV 259
Figure 12.2 – 5G Architecture
The NVFI utilizes Intel x86 or generic computing hardware, which is easy to obtain and maintain as
organizations' IT departments are well versed in it. The software stack includes the following elements:
• Hypervisors
• Virtual Machines (VMs)
• Virtual Infrastructure Managers
This provides the physical and virtual network layers for 5G. Together it creates the layer of the
physical hardware stack for the compute, storage, and network. This is the software foundation for
the deployment and management of VNFs.
The NVFI facilitates the virtualization layer over the hardware layer. In other words, the NVFI provides
an abstraction layer of the x86 hardware servers. It allows logical partitioning and provisioning for
the VNFs to operate smoothly. In addition, the NFVI helps to expand the geographical span over the
prior-generation network architectures.
Next, let us look at Software-Defined Networking (SDN).
The role of SDN

In 5G networks, SDN and NFV provide software-based management and programmable control of
network resources. SDN and NFV also enable network slicing in 5G to allow multiple isolated logical
networks, catering to different services. These logical networks of different capacities and properties
fulfill the need for different requirements, such as smartphones, Internet of Things (IoT) devices,
and emerging needs of autonomous vehicles or drones.
Cisco defines SDN as the ability to program the network and drive automation. SDN can also be
considered as creating the physical separation of the network/user plane from the control plane. A
commonly used protocol for SDN is OpenFlow, which provides communication between the control
layer and the infrastructure layer. Other protocols often used are NETCONF, Border Gateway
Protocol Link-State (BGP-LS), Simple Network Management Protocol (SNMP), or Application
Policy Infrastructure Controller Enterprise Module (APIC-EM). VMware NSX can be considered
an overlay SDN implementation. Here, a network layer overlays a physical network. This adds agility
to the software systems to quickly bring up the network layer with much less dependence on the
hardware layer. SDN is also often interchangeably used with the term Software-Defined Wide Area
Network (SD-WAN). Figure 12.3 shows the high-level architecture of SDN:
Figure 12.3 – SDN architecture
Bare-metal switching, which allows the use of Linux in the switches, is also often discussed in the
context of SDN. Facebook (now part of Meta) also makes bare-metal switches running open OSs.
Switches running Linux as the OS are a good example of SDN. The actual definition of SDN depends
on the vendor you ask. However, at the core of SDN is easy network programmability and network
automation. The Open Networking Foundation is one of the relevant bodies in the context of SDN.
Understanding MEC C-RAN 261
As shown in Figure 12.3, in SDN architecture, the Northbound Interface (NBI) is used by business
applications for appropriate communications with the controller. The Southbound Interface (SBI)
facilitates communication with the devices that are part of the infrastructure layer or the data plane.
In the three-tier SDN architecture in the preceding figure, the business applications are written
by different vendors and third parties. Such applications are architected using the NBI to enable
communication with the controllers. This helps to promote interoperability in the SDN architecture.
In the prior section, we looked at the role of SDN in 5G and how it adds flexibility to the
infrastructure architecture.
Next, let us look at Multi-access Edge Computing (MEC) Cloud Radio Access Network (C-RAN).
Understanding MEC C-RAN

C-RAN is often used interchangeably with Centralized-RAN. C-RAN refers to cloud computing-
based architecture for RAN and implements Radio Access Technology (RAT). RAN also connects
the Core Network (CN) with User Equipment (UE). For 5G, one of the goals is to leverage public
cloud infrastructure for RAN, which is already used in the mainstream IT world, and future-proof it
for 5G. Where the cloud has too-high latency, an edge cloud is used.
C-RAN represents an architectural evolution over the following areas:
• An all-in-one macro base station for 1G and 2G networks

• A distributed base station for the 3G network
Historically, a RAN’s radio and baseband processing capability has resided in a base station. In
C-RAN, we decouple the base station capabilities and processing power into Remote Radio Heads
(RRHs), which exist in a distributed fashion at the cell site and the central Baseband Units (BBUs).
The connectivity between the BBU and the RRH is managed via the fronthaul network.
Over time, the Common Public Radio Interface (CPRI) standards have evolved. They are standards
for interfacing the Radio Equipment Control (REC) with radio equipment. A group of companies,
including Ericsson AB, Nokia, NEC Corporation, and Huawei Technologies, are working to refine
the CPRI standards. C-RAN takes advantage of the latest CPRI standards. In addition, C-RAN uses
the benefits of low-cost Coarse or Dense Wavelength Division Multiplexing (CWDM/DWDM)
technology. Finally, it uses millimeter Wave (mmWave) to enable the transmission of baseband
signals over long distances. This allows C-RAN to deploy centralized base stations on a massive scale.
Furthermore, C-RAN uses the data center network technology that is already well adopted in enterprise
IT. This brings the following benefits:
• Lower cost/TCO
• Improved reliability
• Lower latency
• A high-bandwidth interconnect network in BBU pooling
• Software virtualization in a vendor-agnostic manner
• Dynamic resource sharing
Let us also look at the gradual move from C-RAN to Virtual-RAN (vRAN) and the adoption of the
term C-RAN. Under vRAN, the baseband capabilities are handled using software functions, which
can be hosted on a general-purpose IT server, as opposed to custom hardware for this purpose. As a
result, vRAN improves the support for multi-vendor 5G ecosystems and avoids vendor lock-in. This
helps to reduce network costs and accelerates the rollout of innovative services.
Let us review the C-RAN architecture to understand its benefits. We must first understand two concepts,
BBU and RRH, and how they are part of the C-RAN architecture. BBU pooling or the Base Station
Hotels (BSHs) facilitate the creation of the master base stations. The RRH, on the other hand, permits
the 5G operator to have many network access points. In some ways, this is like the hub-and-spoke
paradigm, as shown in Figure 12.4:
Figure 12.4 – A simplified view of C-RAN
As we try to increase the density of devices in 5G, especially in places with a lot of users, such as an
airport or a large office complex, mall, or sports stadium, it stresses the Base Transceiver Station
(BTS) to its maximum extent. It is expensive to keep adding more BTSs, which increases the risk
of signal interference in the network. One solution is to separate the base station into two parts: the
BBU and the RRH. This enables the 5G network operators to support a larger number of network
access points and leverage the master base station to centralize the baseband functionality. With the
use of such a master or C-RAN base station, the overall management and infrastructure of the radio
resources are simplified in otherwise possibly complex 5G environments. (See: https://www.
artizanetworks.com/resources/tutorials/cran.html).
Let us look at how C-RAN helps with the cost efficiency of 5G network infrastructure. An average
5G base station can cost as much as three times the cost of 4G, with an even smaller coverage area.
Historically, the RAN costs contributed to 80% of CAPEX and about 60% of OPEX. With added
cost pressure where the revenues per telecom subscriber are going down, it is important to look for
innovations such as C-RAN for cost efficiencies. The TCO of BTS includes the equipment and the
site, power supply, battery backup, cooling, and security costs. These are the capital costs or one-time
investments. In addition, there are operating costs, including service and maintenance activities.
Understanding MEC C-RAN 263
However, BBU pooling creates economies of scale here. The cost of each BTS infrastructure can be
reduced by co-locating some of the baseband functionality at the C-RAN base station. This reduces
idle or extra capacity at the BTS that may not always be optimally utilized. This cost efficiency is often
referred to as the pooling gain. The wider adoption of cloud computing allows a shift to a pay-as-
you-go model, which is quite common in the public cloud computing space. The big providers of
public clouds include the following:
• Amazon Web Service (AWS)

• Microsoft Azure
• Google Cloud Platform (GCP)
• Oracle Cloud Infrastructure (OCI)
• Alibaba Cloud (Aliyun)
Many public cloud providers also have edge clouds to supplement the use cases where the cloud has too
high a latency for the specific scenario. We will see in the later Using hybrid cloud section how such edge
offerings from cloud providers play an important role in the hybrid cloud-based infrastructure of 5G.
NFV makes it possible for core network processing to be done in a virtualized computing environment,
achieving hardware independence to a great extent. Coupled with the mainstream use of public cloud
in enterprise computing, it sets the stage for the emergence of the RAN-as-a-Service (RANaaS) model.
Next, let us look at how C-RAN helps to reduce signal interference. Having a large number of BTSs
in a single geographical area can lead to signal interference. However, BBU pooling allows you to
centralize some of the baseband functionality in a single master base station. The centralization of the
baseband functionality allows better coordination of the transmission between the different types of
cells, as shown in Figure 12.5. This also lays the foundation of carrier aggregation:
Figure 12.5 – Advanced C-RAN architecture

Next, let us look at carrier aggregation.
Carrier aggregation
Carrier Aggregation (CA) allows the co-existence of the 4G and 5G networks. CA allows the
mixing of multiple frequency bands, leading to improved cell coverage. Ericsson is considered one
of the industry leaders when it comes to CA. To understand CA fully, let us look at the 5G spectrum,
consisting of the following elements:
• Low-band: This provides national-level coverage and can be used indoors below 7 GHz using
Frequency Division Duplex (FDD).
• Mid-band: This is a metro band in the range of 1 GHz to 6 GHz and can penetrate walls and
provide fast throughput speeds and enhanced capacity using Time Division Duplex (TDD).
• High-band: Also referred to as mmWave for higher-density localized services above 24 GHz.
It requires smaller antennas, provides dense coverage, and is more secure.
See Figure 12.6 for this concept of the three bands in 5G:
Figure 12.6 – The different bands in 5G
Ericsson developed Advanced RAN Coordination for low-latency coordination between the two
different RAN compute basebands. (See: https://www.ericsson.com/en/blog/2021/6/
what-why-how-5g-carrier-aggregation).
Figure 12.7 provides a comprehensive view of the C-RAN architecture, built upon the foundations we
covered here. Such a comprehensive C-RAN architecture lays the foundation of the RANaaS, which
aligns with the public cloud computing concept.
Figure 12.7 – Comprehensive C-RAN architecture
C-RAN facilitates rapid deployment of high-density RAN infrastructures. China Mobile first proposed
C-RAN architecture in 2009 to move from Distributed RAN (D-RAN) to C-RAN. Both China Mobile
and China Unicom were early adopters of C-RAN. On the global stage, C-RAN architecture-related
equipment crossed $5 billion in market share as early as 2015 (https://www.fiercewireless.
com/tech/ihs-china-fuels-5b-c-ran-market). AT&T adopted C-RAN at a later stage,
in preparation for mmWave and 5G (https://www.fiercewireless.com/wireless/
at-t-lays-c-ran-foundation-preparation-for-5g). In Europe, Nokia and Ericsson
drove the adoption of C-RAN starting in 2015. Globally speaking, Huawei and Samsung are the other
two large companies adopting C-RAN. As a result, global revenues related to C-RAN exceeded $12
billion by 2020.
In summary, the adoption of C-RAN can lead to a higher density of cell services under 5G, reduced
CAPEX and open costs by using BBU pooling, and reduced energy consumption, leading to improved
Environmental, Social, and Governance (ESG) outcomes for companies.
In the next section, we will look at O-RAN.
Understanding O-RAN
Open RAN or O-RAN is a vastly popular term in the 5G network world. It deals with the interoperability
of open hardware, software, and interfaces for cellular wireless networks. The goal is to allow the use of
Commercial Off-The-Shelf (COTS) servers and network equipment as opposed to customer hardware
similar to those used in the base stations. In other words, O-RAN is a movement to standardize and
allow for the interoperability of RAN’s building blocks (https://www.viavisolutions.com/
en-us/solutions/o-ran).
O-RAN provides flexibility for operators to mix and match vendor equipment and not get locked into
particular propriety hardware, software, and interfaces. See Figure 12.8:
Figure 12.8 – A simplified view of O-RAN
O-RAN promotes a more vibrant supply chain ecosystem for 5G compared to its predecessors due
to the use of open standards for communication. This adds agility to the innovation process for the
network and its applications.
Let us take an example of legacy RAN deployment and show how the O-RAN concept applies there.
See Figure 12.9:
Figure 12.9 – A legacy RAN deployment [image credit: Sanya]

From the bottom up, the layer consists of the RAN hardware and software. In legacy deployments, the
use of propriety hardware from a specific vendor dictated the use of the same hardware for the full
deployment over the life cycle. Likewise, this locked the operator into using corresponding proprietary
software, shown as SW Vendor 1. With the emergence of O-RAN, as new hardware appears on the
market with enhanced capabilities, mixing and matching is possible. Additionally, the loose coupling
between the RAN hardware and software provides more flexibility to adopt these solutions over the life
cycle of the RAN. This is absolutely critical in the era of massive supply chain disruptions during the
COVID-19 period, such as from 2020 to 2022. Furthermore, the global semiconductor crisis would
have aggravated the problem further if no concept such as O-RAN was applied to 5G infrastructure,
as the initial rollouts corresponded with this time period in several parts of the globe.
Figure 12.10 shows how O-RAN allows the adoption of hardware from different vendors when new
features are released in similar hardware from different vendors allowing mixing and matching at
the O-RAN hardware layer:
Figure 12.10 – A deployment based on O-RAN swapping hardware vendor [image credit: Sanya]
Figure 12.11 shows similar flexibility at the O-RAN software layer allowing swapping of the RAN
software stack in the RAN deployment life cycle:
Figure 12.11 – A deployment based on O-RAN swapping RAN software vendor [image credit: Sanya]
Figure 12.12 and Figure 12.13 further illustrate this concept, where O-RAN allows tremendous flexibility
due to the ability to swap out hardware and software vendors.
Figure 12.12 – A deployment based on O-RAN with central and distributed units [image credit: Sanya]
Figure 12.13 illustrates how the integrators manage the O-RAN infrastructure. This adds further
flexibility for managing O-RAN deployments:
Figure 12.13 – A deployment based on O-RAN integration models [image credit: Sanya]
This model can swap out elements as improved parts or replacements are needed due to the global
supply chain crisis during the pandemic. AT&T openly shared the impact of the semiconductor
industry delays and the resulting impact on RAN equipment, as can be read here: https://www.
sdxcentral.com/articles/news/att-ceo-a-little-skittish-about-5g-
ran-supply-chain/2021/04/.
Next, let us look at the O-RAN infrastructure management and operating cost models.
Managing O-RAN infrastructure

The O-RAN specification presents a standardized architecture to 5G service providers. It eases the
management of the O-RAN network infrastructure by virtue of minimal dependency on any proprietary
hardware, fostering innovation among the network application designers.
Figure 12.14 shows that O-RAN can reduce the network’s operating costs over legacy RAN deployments
by a sizeable extent, allowing the operators to focus on innovation and value delivery to their customers.
Figure 12.14 – Management paradigms of RAN infrastructure [image credit: Sanya]
Next, we look at the full view of the O-RAN architecture in Figure 12.15 (see https://www.o-
ran.org). The O-RAN architecture comprises the following elements:
• Service Management & Orchestrator (SMO): SMO governs the orchestration, management,
and automation of RAN elements and supports O1, A1, and O2 interfaces.
• Non-real-time RAN Intelligent Controller (Non-RT RIC): Non-RT RIC allows non-real-time
control and optimization of RAN elements and resources. It facilitates Artificial Intelligence
(AI) and Machine Learning (ML) capabilities for training and updating the models.
• Near-real-time RAN Intelligent Controller (Near-RT RIC): Near-RT RIC enables near-real-time
control and optimization of O-RAN elements and supports the E2 interface for the collection of
fine-grained data and actions. It helps to optimize and enrich the control function of the RAN.
• O-RAN Central Unit (O-CU): O-CU consists of O-RAN Central Unit – Control Plane
(O-CU-CP) and O-RAN Central Unit – User Plane (O-CU-UP). O-CU also hosts the Radio
Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and Packet Data
Convergence Protocol (PDCP) protocols.
• O-RAN Distributed Unit (O-DU): O-DU hosts Radio Link Control (RLC)/Medium Access
Control (MAC)/high-PHY layers, where PHY is the physical and electrical characteristics of
the network.
• O-RAN Radio Unit (O-RU): O-RU hosts the low-PHY layer and Radio Frequency (RF)
processing layers.
Together these components provide the full range of network functionality of O-RAN:
Figure 12.15 – The O-RAN architecture
The O-RAN architecture is based on the following core principles:
• Open interfaces for RAN virtualization, and AI-capable

• Composable model for RAN to allow multi-vendor components and solutions
• Use of off-the-shelf silicon and hardware to minimize the need for any proprietary hardware
• Specification for open APIs to foster the use of open source components and adopt standards
wherever possible
In the previous section, we looked at O-RAN and how its core principles help to optimize 5G networks
from the service provider’s perspective.
In the next section, we will look at the emergence of hybrid cloud and its role for 5G operators.
Using hybrid cloud

In Chapter 3, Building Blocks – Cloud Native Infrastructure, we covered the topic of cloud-native
infrastructure for 5G to drive the move from proprietary hardware to increased use of mainstream
COTS products. This creates composable architecture with the ability to mix and match building
blocks. These building blocks can be COTS hardware or microservices for the software stack. Figure 3.2
in Chapter 3, illustrates some of these components prevalent today. This also enhances the ability to
port 5G infrastructure across different types of infrastructure building blocks. The focus on the public
cloud landscape to support hybrid cloud comes in handy here.
The 5G industry landscape is gradually maturing and going through Non-Standalone (NSA) and
Standalone (SA) evolutionary phases. (See the document located here: https://www.t-mobile.
com/content/dam/tfb/pdf/TFB_TechTarget-whitepaper_SA-NSA-5G.pdf). This
is given further context by the following descriptions:
• The NSA 5G phase is the first phase, where a 5G New Radio (5G NR) access network is used
with the existing 4G Long-Term Evolution (LTE) network core to deliver the service.
• The SA 5G phase involves the use of a 5G NR access network with the newly introduced 5G
network core. This is important for delivering innovation use cases and the full promise of 5G
to the user community.
For operators, though, the maturity curve of 5G deployments calls for flexibility in infrastructure
models. This is where hybrid cloud provides several opportunities to grow and tailor 5G infrastructure
deployments. This is the concept of composable networks, where 5G is treated like a wireless fabric.
(See: https://www.sdxcentral.com/articles/news/composable-5g-networks-
its-a-thing-liqid-ceo-says/2019/09/)
The functional split of RAN, as shown in Figure 12.15, opens up the opportunity to use the public
cloud and, when appropriate, leverage the hybrid cloud features for 5G infrastructure:
Figure 12.16 – Splitting functionality in 5G to break up monolithic architecture
The communication between the Distributed Unit (DU) and Radio Unit (RU) requires low latency.
The enhanced Common Public Radio Interface (eCPRI) is the emerging standard for interfaces to
Using hybrid cloud 273
connect the RU with the DU, often referred to as fronthaul, to ensure the stringent low-latency needs
(sub 100 microseconds). The DU serving the RU is a one-to-many relationship, and RUs can often
be far away. (See: https://www.rcrwireless.com/20200708/open_ran/open-ran-
101-ru-du-cu-reader-forum).
Next, we will look at how the telecom cloud plays a role here in adding flexibility to the 5G infrastructure.
The emergence of the telecom cloud

Recent years have seen an emergence of telecom clouds providing options for 5G operators to consider
for adoption. The role of edge/far edge for operational technology workloads, such as a robotic arm
in a factory assembly line, will never be in the cloud due to latency needs. This makes the edge very
important in this case. Hence, 5G operators are exploring managing the control plane in the public
cloud but keeping the data at the edge. 5G operators can use cloud-managed services at operator
locations. Figure 12.16 shows how Oracle, with its public cloud called Oracle Cloud Infrastructure
(OCI), provides a flexible hybrid cloud for 5G operators:
Figure 12.17 – Splitting functionality in 5G to break the monolith [image credit: Sanya]
Sometimes multiple cloud providers work with partners to provide support for multi-cloud solutions.
Figure 12.18 shows one such example where OCI and AWS come together with their partner Equinix
to help eliminate the complexities for operators in building the NFV deployment architecture while
leveraging the OPEX models of the public cloud:
Figure 12.18 – Enablers for NFV architecture
In the preceding section, we looked at the emergence of the public and hybrid clouds in the context
of 5G infrastructure design. This has provided opportunities for the public cloud providers such as
AWS, Microsoft Azure, GCP, and OCI to become part of the 5G ecosystem. Google announced that it
joined the O-RAN alliance in June 2021 (See: https://cloud.google.com/blog/topics/
telecommunications/google-cloud-joins-o-ran-alliance).
Now, Communication Service Providers (CSPs) can embrace the public cloud for both IT and network
transformation. Based on the latency and data residency issues, the hybrid cloud offerings provide
great flexibility while taking advantage of the OPEX model from a financial perspective. Given that
5G NSA infrastructure can cost in the range of $1 million for 50,000 subscribers, the flexibility of the
financing model is key here (see: https://www.lightreading.com/open-ran/heres-
how-much-5g-wireless-network-really-costs/d/d-id/769114):
Feature / RAN C-RAN vRAN O-RAN

Deployment Type Centralized Deployed on Flexible deployment
and often uses commercial
propriety hardware off-the-shelf servers
Vendor A single vendor Uses VMs or Multi-vendor or
provides hardware containers, and mix-and-match
and software single-vendor software vendors for RAN
Cost High Medium Low
The preceding table summarizes the comparison between C-RAN, vRAN, and O-RAN, using
deployment type, vendor, and cost.
Summary 275
Summary
In this chapter, we learned about the infrastructure required to support 5G networks. We looked at
NFV, C-RAN, vRAN, and O-RAN, as well as the use of hybrid clouds for 5G networks. A thorough
understanding of the infrastructure allows the development of a composable network over the life
cycle of 5G.
In the next chapter, we will introduce the concept and architecture of network slicing for 5G. We will
understand how network slicing acts as a differentiator for 5G. We will look at several use cases for
slicing to better understand its applications.
13
5G Network Slicing
This chapter will focus on the purpose and architecture of 5G network slicing. Traditional methods of
mobile network management cannot unleash the full potential of 5G. Network slicing helps to make
an infrastructure intelligent and reduces the dependence on applications for efficiency and latency.
Network slicing allows the connectivity to be fine-tuned to end-customer devices and use cases, both
for enterprise and retail customers. Overall, network slicing is a key differentiator between 5G and
prior generations of mobile technologies.
• Understanding network slicing

• Network slicing architecture and design
• Use cases of network slicing
Understanding network slicing

Network slicing is the ability to dynamically create a logical end-to-end 5G network. In network slicing,
specific User Equipment (UE) can use multiple slices over the same access network or radio interface. A
network slice can be formally defined as “a set of network functions and corresponding resources necessary
to provide the required telecommunication services and network capabilities” (see www.3GPP.org).
Network slicing allows mobile operators to develop new commercial models to help dominate the
enterprise market. With network slicing, the operators can expose 5G capabilities to enterprise
customers to meet their needs for latency, throughput, security, and compliance. This allows a greater
degree of self-service capabilities for these customers.
Next, let us understand the basic concept of network slicing.
278 5G Network Slicing
Network slicing simplified

Network slicing in 5G allows you to create several virtual networks over a shared public network. It
adds flexibility and efficiency to the utilization of the network resources. The logical networks created
on top of a single physical infrastructure give each slice its own characteristics. These slices help to
meet the specific needs of application users.
One network slice could cater to a virtual reality application with a need for high bandwidth and low
latency. Another network slice can support a remote-control system that needs low bandwidth but
high reliability. Overall, network slicing gives flexibility to service providers to enable a large variety of
5G applications and diversity of use cases, without the need to over-invest in a network infrastructure.
Figure 13.1 shows how network slicing allows us to serve different types of needs, such as the following:
• Mobile and wireless devices, including tablets and smartphones

• Internet of Things (IoT) devices with sensors and imaging data
• Connected automobiles such as cars, ambulances, and fleets
• Remote manufacturing facilities
• Physical infrastructure, including buildings and campuses
Figure 13.1 – Network slicing explained
In network slicing, each slice can be configured for its own performance and throughput. Let us look
at the importance of Control and User Plane Separation (CUPS). This helps to improve the efficiency
Understanding network slicing 279
and performance of the 5G network. As a result, the control plane and user plane serve as two different
network components used to handle different kinds of network traffic.
The control plane manages the network and maintains the communication between devices. The
control plane sets up and tears down connections, routes traffic, and manages resource allocation.
The user plane carries the user data, including payloads such as voice and video. Independent scaling
of the control plane and user plane can be done using CUPS.
CUPS, along with Software-Defined Networking (SDN), facilitates network slicing in 5G. SDN
manages and controls the allocation of resources to different network slices. This allows sufficient
allocation of capacity and features required by each slice to serve the supported application. The use
of SDN allows network operators to respond quickly to customer demands and usage of network
slicing. Overall, SDN makes the management and operation of the 5G network easier, allowing
flexibility in offering network slicing (for more details, visit https://5ghub.us/5g-end-to-
end-network-slicing/).
End-to-end network slicing is the ability to create and manage multiple logical networks, or slices, that
span an entire network. This goes from a user’s device all the way to the core of a 5G network. Each
network slice acts like a fully independent network. It is tailored to meet the specific requirements of
different types of users and applications.
SDN and Network Function Virtualization (NFV) technologies are used to create and manage the
different end-to-end network slices. An operator will define the characteristics and capabilities of each
slice, such as the bandwidth, latency, and reliability requirements, and use SDN and NFV to allocate
resources and configure the network accordingly.
When end users connect to a network, they are automatically connected to the appropriate network
slice. This selection depends on the requirements of their device and applications in use. The network
is then able to route the user’s traffic through the appropriate network slice. In this process, the desired
performance and Quality of Service (QoS) are met.
Let us look at a simple analogy to network slicing. Let us say there are two large cities – City A and
City B. The operator is responsible for creating roads between the two cities. The traffic between these
two cities consists mainly of cars, motorbikes, and trucks. Historically, all three have shared the same
road and have not been happy with their experience on the road, due to accidents and delays. The
operator now has two choices:
• Build three different highways and assign one for trucks, one for cars, and one for motorbikes.
In this approach, it needs three times the investment to build three separate roads between
City A and City B.
• Build several lanes on a single multi-lane highway and segment them into three groups of lanes
in either direction, in such a way that traffic cannot switch from one group of lanes to another
except at designated exits. Different speed limits and toll levels can be set up for each set of
lanes, independent of the others.
The second approach here is like the network slicing approach, where the same physical network or
general-purpose multi-lane highway caters to different specific needs and provides sufficient isolation
for each set of users.
Network slicing essentially helps to extend the concept of virtualization, which is quite prevalent in
enterprise IT, to customer premises and devices, through the connectivity layer. In 4G, virtualization
was possible in the core of the mobile platform. Network slicing in 5G extends this capability to
the radio access part of the network. With network slicing, it is easy to cater to applications that
have low-latency and high-bandwidth needs, such as Augmented Reality (AR), for optimal user
experience. On the other hand, a network slice for a low-power sensor network can be created for
IoT asset-tracking purposes.
Figure 13.2 provides a simplified view of the concept of network slicing in 5G. On one hand, we have
public and shared capabilities from previous generations, which come with lower costs and higher
flexibility. On the other hand are the private and isolated networks, often adopted by large enterprises,
such as for port operations with poor coverage of a public network.
Figure 13.2 – A simplified concept of network slicing
Network slicing helps to bridge the gap between the two extremes, as shown in Figure 13.2, by
providing the following:
• Convenience and coverage

• Use case-based speed and flexibility
• QoS and security
In 2021, Deloitte conducted a global study that surveyed over 400 executives about 5G. The study
indicated that 76% of those surveyed believed that over the next 3 years, 5G would be essential for
their business. The low-latency and near-fiber speeds unleashed by 5G would be the key enablers for
business outcomes.
As enterprises are exploring their paths to profitability, they are looking to adopt 5G to drive new
channels of productivity and revenue, in the following ways:
• Building their own 5G private wireless networks to address their specific needs for bandwidth,
latency, and Service-Level Agreements (SLAs) with their users
• Evaluating the network slicing provided by their Communications Service Provider (CSP)
as a slice provider to slice the enterprise tenants, under rigid SLAs
The expected share of the 5G private network is about three times the network slicing market, as per
the recent forecasts from ABI Research. However, the sheer size of the predicted total market growth
by 2030 creates a large stake in network-slicing services. Small and medium businesses are likely to
adopt network slicing services more than large enterprises, gradually (https://www.nokia.com/
blog/enabling-advanced-use-cases-with-5g-network-slicing/). However,
making network slicing commercially viable for CSPs will require careful planning and prioritization
of investments in a network infrastructure.
Some CSPs will adopt a hybrid model in the near future. The hybrid model of network operations
combines elements of both SDN and traditional networks. Some parts of a network use traditional
networking protocols and hardware, while other parts use software and virtualization for management
and control.
Network slicing will not apply in every scenario. Let us look at a case study covering the decision-making
process – in this case, a smart warehouse solution for a large manufacturing company (https://
www2.deloitte.com/us/en/pages/consulting/articles/private-5g-network-
support-smart-warehouse-applications.html).
In this case, Deloitte and a large manufacturing company designed a smart warehousing solution for a
45,000-square-feet facility, leveraging 5G. The solution included a precision location tracking system,
autonomous robots and forklifts, a computer vision and sensing system, and AR/VR capabilities. In
this case, the best option was a private 5G network rather than network slicing for the QoS required.
The private network also allowed the use of Zero Trust Architecture (ZTA), increasing the security
and compliance of the network in the warehouse. This example goes on to prove that both private
networks and network slices have their own advantages and disadvantages and have to be carefully
selected for the specific scenario.
Ericsson and Far EasTone Telecommunications (FET) from Taiwan demonstrated a solution where
smartphone applications interact with different network slices, based on the QoS requirements. Here,
dynamic network slice selection provides an added level of flexibility in the mobile application design
and architecture, as shown in Figure 13.3.
Figure 13.3 – A selection of a network slice
This type of solution allows policy-based selection of a network slice that is most optimal for an
application. For instance, a smartphone user may use the generic broadband slice for regular mobile
services and a different slice for gaming applications. However, the same smartphone device could
be used for enterprise applications. In this case, a highly secure network slice is used for enterprise
applications such as secure video conferences with a field technician. In this case, the user experience
and reliability of the enterprise applications on a smartphone are improved via network slicing. Such
a use case is becoming increasingly important, due to the increasing use of Bring Your Own Device
(BYOD) policies in the corporate world as well as remote work, as a result of the COVID-19 pandemic.
Network slicing provides a capability bridge between public network flexibility and the benefits of
standalone networks.
In order to capitalize on the opportunities provided by 5G network slicing, CSPs have to look at their
priorities for investments. These priorities will be dictated by the type of demand they see in their
customer base. Figure 13.4 shows how the adoption of 5G and its use cases will grow. CSPs have to
look at the opportunities in the near future for monetization while keeping long-term growth in mind.
Initially, a few slices may suffice for meeting the near-term requirements of its enterprise customers.
However, planning has to be done to allow the introduction of other slices when the remaining use
cases mature in the industry or their specific customer base.
Figure 13.4 – Usage of network slices
In the next section, let us look at the practical challenges that network slicing may pose to CSPs.
Network slicing challenges

CSPs have to invest heavily in network-slicing capabilities before enterprise customers can adopt
them. This is similar to cloud computing, where hyper-scalers such as Amazon Web Services (AWS),
Microsoft Azure, Google Cloud Platform (GCP), and Oracle Cloud Infrastructure (OCI) had to
make upfront investments. They had to prioritize which cloud services to build first by intelligently
guessing the enterprise uptake in the foreseeable future. In a similar fashion, CSPs have to prioritize
the plausible use cases of 5G and cater the network slicing services to them. If they do not make good
decisions here, the Return on Investment (ROI) on their capital-heavy investments will suffer. The
use cases can vary by geography and fluctuate with macroeconomic cycles. Figure 13.4 captures this
visually. An operator has to adapt to future trends and be able to act quickly.
Next, let us look at the ways CSPs can potentially overcome these network-slicing challenges.
Overcoming the network-slicing challenges

With strategy planning and selective investments, CSPs can try to overcome challenges associated
with network slicing to their businesses. As shown in Figure 13.5, this strategy could comprise the
following steps:
1. Select the target industry, in their customer base today, or industries to be targeted in the near
future. This is key to a focused approach to investments.
2. Identify network capability gaps to address in the early slices planned for deployment.
3. Create a business plan based on prioritized near-term opportunities by use case.
4. Rinse and repeat – this is an iterative process, in the initial years, until there is widespread
adoption of 5G in the industry.
Figure 13.5 – A selection of network slices
With a phased approach based on prioritization of the industry, segments, and use cases, CSPs can
try to overcome the network slicing challenges and reduce their risk exposure. See Figure 13.6 for the
suggested phased approach. The investments increase with the phases, but the initial phase helps to
get started with network slicing-based services.
Figure 13.6 – A phased approach for network slicing rollout by CSPs
As the CSPs mature with the slicing Lifecycle Management (LCM), they will need to ensure they
have Network Functions Virtualization Infrastructure (NFVI) and capacity in a physical network.
This requirement includes adequate radio coverage as well. Hence, to support automated network
slicing LCM functionality, CSPs must overall be sufficiently competent with the network capabilities.
The CSPs also must invest in the ecosystem, as 5G devices will continue to evolve in the first few years.
Network slicing’s ability to invoke reliability, redundancy, and ultra-low latency in an end-to-end
fashion is key. Such capabilities allow network slicing to facilitate a plethora of use cases, such as drone
streaming videos, live sports coverage, AR/VR, and emerging use cases, as conversations about the
metaverse increase. In a blog post, Ericsson has tried to explain the relationship between the metaverse
and 5G (https://www.ericsson.com/en/blog/2022/4/why-metaverse-needs-5g).
Access to the virtual world of the metaverse is enabled by 3D eXtended Reality (XR) devices.
According to Ericsson, XR refers to technology that lets human users experience and interact beyond
their immediate physical space and reality by sight, touch, or sound. Today, XR is loosely used as the
umbrella term for AR, VR, mixed reality, and merged reality. Some of the applications of XR can include
remote working with co-workers from different locations, remote learning, shopping, or even hanging
out with a friend in a cafe in a very immersive manner. The largest aircraft manufacturer Boeing has
discussed its intentions to design its next aircraft in the metaverse (https://www.reuters.com/
technology/boeing-wants-build-its-next-airplane-metaverse-2021-12-17/).
Metaverse
Gartner defines a metaverse as a collective virtual shared space, created by the convergence of
virtually enhanced physical and digital reality. It is persistent, providing enhanced immersive
experiences as well as device independence and accessibility through any type of device, from
tablets to head-mounted displays (https://www.gartner.com/en/articles/
what-is-a-metaverse).
For an acceptable user experience, large amounts of data have to be transmitted between the AR/
VR devices, such as Microsoft HoloLens, and the edge cloud within milliseconds, with tight latency
requirements. Today, 5G is the most suitable wireless technology to facilitate connectivity for XR
applications. Network slicing makes 5G commercially feasible in such Metaverse scenarios.
Security considerations for network slicing

Let us look at the security implications of network slicing. The following security challenges should
not be overlooked:
• Hackers can gain access to one slice and exploit it to access sensitive data from other slices.
They could also disrupt the services provided by the other slices.
• If the underlying physical infrastructure is compromised, then potentially all the slices can be
disrupted. To prevent this, the infrastructure has to be hardened and limited to administrators.
• Hackers could initiate a Denial of Service (DOS) attack from a slice, which can then paralyze
an entire network infrastructure.
“Improper network slice management may allow malicious actors to access data from different network
slices or deny access to prioritized users.” This is according to a paper published by the National
Security Agency (NSA), the Cybersecurity and Infrastructure Security Agency (CISA), and the
Office of the Director of National Intelligence (ODNI). (For more information, visit https://
www.bleepingcomputer.com/news/security/nsa-shares-tips-on-mitigating-
5g-network-slicing-threats/.)
To safeguard from security challenges, it is important to ensure Confidentiality, Integrity, and
Availability (CIA) for 5G network slicing protection. Advanced migration strategies can include
the following:
• Zero Trust Architecture (ZTA) requirements

• Multi-Layer Security (MLS)
• Cross-Domain Solutions (CDS)
• Post-Quantum Cryptography (PQC)
• Isolation
A detailed description of these security techniques is beyond this chapter and book.
In this section, we looked at a description of 5G network slicing as well as its challenges. Let us next
look at the architecture and design of network slicing.
Network slicing architecture and design

When we discuss the architecture of new technology, we often look at the industry standards bodies,
such as the 3rd Generation Partnership Project (3GPP) (https://www.3gpp.org/about-
3gpp), which is considered one of the main standards bodies and influencers for 5G. 3GPP has
recognized that network slicing is key to the widespread adoption of 5G. 3GPP’s working groups who
are developing the 5G core architecture have included it in Technical Specification (TS) 23.501 and
TS 22.261. The latter covers how to provision network slices and achieve slice and device association. It
further includes specifications about performance isolation during the various modes of slice operations.
According to TS 22.261, a network slice provides the functionality of a complete network. This includes
Radio Access Network (RAN) functions, core network functions, and IP Multimedia Subsystem
(IMS) functions. The core network functions may come from different vendors and interoperability
is key here. IMS facilitates interactive calling in 5G. The home and roaming users are provided
connectivity in the same network slice. This architecture specification allows one network to support
several network slices. TS 22.261 also specifies that a 5G network provides appropriate Application
Programming Interfaces (APIs) to allow a trusted third party to configure, monitor, create, modify,
and delete network slices, as well as assign UE that is required by the third party.
Network slicing architecture and design 287
5G network slicing at work

Let us see how the differential handling of traffic is managed for network slicing. We’ll define a few
terms first (http://anisimoff.org/eng/5g/5g_uc_requirements.html):
• Enhanced Mobile Broadband (eMBB): eMBB is a 5G service category that assures a minimum
data transfer rate level. It is geared toward high data rates and high traffic volumes.
• Ultra-Reliable and Low-Latency Communications (URLLC): URLLC caters to the need for
ultra-low latency (such as below 1 ms each way) as well as very high reliability. It serves well
in factory automation scenarios and the control of robots, remote surgery, and Vehicle to
Everything (V2X) communication.
• Massive Machine-Type Communication (mMTC): This is best suited for IoT devices and
sensors that are often low-power but have a high density (defined by the number of devices
per square area). These devices are often low-cost, transmit small packets infrequently, and
are often delay-tolerant.
The preceding information is summarized in Figure 13.7.
Figure 13.7 – 5G classes of use cases
Next, let us look at how the 5G network slices use the preceding paradigm to enable the different
services according to their requirements. Figure 13.8 shows the network layer, network slice layer,
and services layer. Further, it shows how network slicing facilitates different types of services, all over
the same physical 5G network.
Figure 13.8 – 5G network slicing at work
Let us look at the high-level architecture view shown in Figure 13.9. Here, we show three network
slices with one user each. In the top slice for voice and mobility, where a user could be watching a
video on a smartphone in a restaurant, the mobility management is done in the core cloud. This will
suffice for a relatively static user while streaming video on the phone. However, on the connected
automobile, the middle slice, the mobility management is moved to the edge cloud, along with the
session management. This accounts for automobiles that are often on the move. In the bottom slice,
geared toward IoT devices, mMTC allows for very high connection densities. Usually, the data rate
may be low from such IoT devices. Mobility management is not needed for this slice.
Figure 13.9 – Network slicing architecture view

Let us next look at the 3GPP architecture for 5G network slicing. We will list out the relevant
acronyms here:
• Network Slice Selection Function (NSSF)

• Access and Mobility Management Function (AMF)
• Network Repository Function (NRF)
• Session Management Function (SMF)
• User Plane Function (UPF)
• Policy Control Function (PCF)
• Data Network (DN)
Figure 13.10 shows how the common network functions, and those unique to each of the two slices,
are invoked to create two DNs with unique network characteristics.
Figure 13.10 – 3GPP architecture for 5G network slicing
Figure 13.10 shows the power of network slicing and its ability to work with DNs best suited for the
use case.
Architecture and flow diagram

The key tenet of the 5G network slicing architecture is the complete logical isolation from other slices
in an end-to-end (E2E) network. Traditional software design concepts such as virtualization and
recursion play a key role in network slicing. The concept of recursion is utilized through SDN, which
enables the control plane to support the specific slice composition by creating several sub-controllers.
NFV facilitates the network functionality on Virtual Machines (VMs) to easily decouple the slice
building blocks from propriety hardware components, adding to the agility of the network slice design.
This speeds up the provisioning of the network slices (for more information, visit https://www.
viavisolutions.com/en-us/5g-network-slicing).
Figure 13.11 shows the architecture as swim lanes for eMBB, URLLC, and mMTC. Each network lane
here is architected for latency, throughput, and security. This eventually helps us to manage the budget
and commercial viability of the architecture, both for the network operator and users – enterprise
or consumer. The diagram shows that each slice traverses unique and common network elements.
Figure 13.11 – Lane-based architecture of network slicing
The task of the operators is somewhat challenging, since the 3GPP standards for 5G are still in the early
stages of evolution. Automobile companies such as Telsa and Zoox are working toward autonomous
cars. Cellular Vehicle-to-Everything (C-V2X) technology will rely on network slicing and will likely
be deployed on a URLLC slice to provide ultra-low latency. As 3GPP standards mature over time,
operators will add more capabilities, leading to more commercially viable enterprise use cases in both
B2B and B2B2C scenarios.
Let us next look at Figure 13.12, which shows 3PGG 5G network architecture for a non-roaming
scenario. Note NSSF as part of this architecture.
Figure 13.12 – 5G network architecture (non-roaming)
NSSF is a network function that is responsible for selecting the appropriate network slice for a
particular device or application. It is based on the requirements and the capabilities of the available
slices. NSSF plays a key role in enabling network slicing. When a device connects to a 5G network,
NSSF is responsible for evaluating the device’s requirements and the capabilities of the available slices,
and for selecting the most appropriate slice for the device. NSSF can also be responsible for negotiating
the terms of service for the slice, such as the bandwidth and latency requirements, and for managing
the allocation of resources to the slice.
In the context of 5G networks, AMF and SMF are responsible for managing and controlling the
different slices that have been created on top of the shared physical infrastructure. AMF is responsible
for managing access to the network and enabling devices to move between different slices and coverage
areas. SMF is responsible for managing the establishment, maintenance, and teardown of sessions
between devices and the network.
Both AMF and SMF use information from NSSF to determine the appropriate slice for a particular
device or application, based on its requirements and the capabilities of the available slices. AMF
and SMF also work with other network functions, such as the UPF and the PCF, to ensure that the
appropriate resources are allocated to the slices and that they are able to meet the performance and
QoS requirements for the devices and applications they are serving.
The gNodeB (gNB), which is a type of base station, is responsible for managing and controlling the
RAN. It manages the connection between devices and a network, and enables devices to communicate
with each other and other network elements. For network slicing, gNB is responsible for routing
traffic to and from the appropriate slice, based on the requirements of the devices and applications
it is serving. It also works with other network functions, such as AMF and SMF, to ensure that the
appropriate resources are allocated to the slices and that they are able to meet the performance and
QoS requirements of the devices and applications they are serving.
Network Slice Instance (NSI) is defined as a collection of network function instances and the necessary
compute, storage, and networking resources to create a deployed network slice. The life cycle management
of NSI is governed by the 3GPP Technical Report (TR) 28.801. Figure 13.13 shows the LCM of NSI.
Figure 13.13 – NSI LCM
In this section, we looked at the architecture of network slicing in depth. We also looked at how
standards bodies such as 3GPP influence the evolution of the technical specifications and standards
of 5G and network slicing.
Let us next do a deep dive into the various use cases of network slicing.
Use cases of network slicing

Let us look at the use cases of 5G and how network slicing will play a role in the widespread adoption
of several of these.
Here are some of the common use cases for 5G:
• Collaborative robots in Industry 4.0

• V2X communications for vehicles, including autonomous cars
• Truck platooning in transportation
• Connected ambulances in healthcare
• Remote learning in education
• IoT
• Remote surgery
• Coverage of sports events, such as the Super Bowl
• AR/VR and the metaverse
• Gaming
• Fixed wireless access for enterprise connectivity
All the preceding are good candidates for network slicing. Let us take remote surgery. The need for this
use case has two main drivers. Expert surgeons may not be locally available in many remote locations or
certain countries and cities. Furthermore, since the COVID-19 pandemic, the movement of healthcare
Use cases of network slicing 293
professionals has been restricted. Robotic arms can often perform surgery with the surgeon being in
a different location. In February 2019, the first known 5G-enabled remote surgery was performed by
Dr Antonio de Lacy in Spain. The 5G network had a 0.01-second lag. If 4G was used, this would be
0.27 seconds. Network slicing is a key enabler for this level of superior network performance to be
entrusted for remote surgeries (see https://www.openet.com/wp-content/uploads/
Openet_WP_5G_3GPP_Release_16__5G_monetisation-1.pdf).
A TM Forum report looked into the monetization of 5G. It found that network slicing-enabled B2B
services would have a significant positive impact on enterprises (see https://inform.tmforum.
org/research-and-analysis/reports/5g-future-business-models-for-
monetization/). Some of the high-value business use cases are shown in Figure 13.14.
Figure 13.14 – 5G business use cases
The business use cases shown in Figure 13.14 are the key enterprise drivers for network slicing revenues
for CSPs. Next, let us try to quantify some of these revenue potentials for CSPs to justify their initial
investment in network-slicing technology.
Figure 13.15 shows that a revenue opportunity of around $200 billion is available for CSPs, based on
global digitalization efforts (see https://www.5gnetworkarchitecture.com/network-
slicing-in-5g/). This figure shows the four-step calculation of how this number is arrived at.
The numbers are in billions of USD.
Figure 13.15 – The potential revenues for CSPs from network slicing
A further industry sector-wise distribution of the CSP’s revenue is shown in Figure 13.16. Healthcare
shows the largest share, followed by Government or the public sector.
Figure 13.16 – Industry-wise potential revenue distribution from network slicing

Use cases of network slicing 295
The source for Figure 13.15 and Figure 13.16 is Network slicing: A go-to-market guide to capture the
high revenue potential by Ericsson and Arthur D. Little.
Next, we will look at plotting these use cases using a network slicing triangle. Figure 13.17 shows the
network requirements versus the enablers for network slicing. This provides a simple view for CSPs
as they plan their phased investment approach to the buildout of the network slicing capabilities.
Figure 13.17 – Plotting the network slicing use cases
In this section, we looked at 5G use cases where network slicing will facilitate widespread adoption in
the industry. We looked at how these use cases create large revenue potential for CSPs and how they
can align their strategy to industry-wise use cases, trying to capture these revenue streams over time.
Summary
In this chapter, we learned about 5G network slicing. We provided a simplified definition of network
slicing. Then, we looked at the architecture of network slicing. Finally, we looked at the use cases that
are enabled by it. Overall, 5G network slicing creates multiple revenue opportunities for its operators.
It can serve multiple industry use cases without large upfront and speculative investments.
In the next chapter, we will look at connected and autonomous vehicles and the role of 5G. We will cover
the concepts and the background of autonomous vehicles and the different levels of autonomy. Finally,
we will cover different applications related to driver assistance, leading to enhanced safety in driving.
14
5G and Autonomous Vehicles
This chapter will focus on the use of 5G technologies for Autonomous Vehicles (AVs). We will cover
general concepts of Connected and Autonomous Vehicles (CAVs), as well as the 5G Vehicle-to-
Everything (V2X) technology. We will look at the high-level architecture for it. We will look at the
underlying concepts and network procedures that enable AVs to communicate with other vehicles
and the infrastructure.
The introduction of V2X will improve road safety, traffic efficiency, and the conservation of energy.
The US National Highway Traffic Safety Administration (NHTSA) has estimated that Vehicle-to-
Vehicle (V2V) systems will help to eliminate about 13% of traffic accidents. This will prevent about
439,000 auto crashes and save up to 1,000 lives in the US each year (see https://www.nhtsa.
gov/sites/nhtsa.gov/files/documents/v2v_pria_12-12-16_clean.pdf).
The maximum benefit will be seen when almost all vehicles can communicate with each other, and
the system eliminates human errors. To get to that state, government bodies such as the NHTSA, the
automobile industry, and the technology and telecommunication industry will have to work together,
along with consumers. Eventually, even cyclists and pedestrians may be able to use and benefit from
similar technology.
• A background on AVs and their concepts

• The high-level architecture of AVs
• AV intercommunication
• 5G V2X
A background on CAVs and their concepts

Let us begin with the concept of CAVs. Technology allows vehicles to talk to each other, as well
as the infrastructure surrounding them. A connected car can enhance the driver’s experience.
298 5G and Autonomous Vehicles
The connectivity can be through 5G or prior generations. General Motors (GM) and AT&T are working
together to provide 5G-equipped automobiles by 2024 (see https://www.fiercewireless.
com/5g/at-t-marks-first-5g-connected-car-deal-gm).
There were an estimated 236 million connected cars on the road as of 2021 (source: https://www.
statista.com/statistics/1155517/global-connected-car-fleet-by-market/).
A CAV can enhance safety, reliability, and security, as well as offering improved infotainment options.
In a CAV, the driver has ultimate control over the vehicle. The 5G network provides much-needed
low-latency connectivity to CAVs. 5G will facilitate the use of network slices to this end. 5G will also
allow the deployment of appropriate private mobile networks in industrial and commercial complexes.
Let us look at the details of V2V communication. It can provide the driver with awareness of 360
degrees around the vehicle and warn them about a potential crash before it happens, thereby preventing
it. V2V allows an automobile to communicate within about 300 meters, or almost 1,000 feet, with
similarly enabled vehicles.
Personal privacy is considered in V2V technology, so only required information is shared. At
intersections, it can provide a driver with assistance and guidance for safely entering an intersection.
It can provide the emergency application of brakes and warnings when it is not safe to pass a slow-
moving vehicle. V2V can adequately cover vehicles’ traditional blind spots. V2V uses a wireless protocol
called Dedicated Short-Range Communication (DSRC). DSRC, along with GPS, is what enables
V2V communications. Vehicles may broadcast their speed, acceleration, direction, GPS location, path,
and other information related to the steering wheel and transmission system.
In Figure 14.1, we can see how forward obstacle detection and avoidance and approaching emergency
vehicle warnings work with DSRC (see https://cecas.clemson.edu/cvel/auto/
systems/DSRC.html):
Figure 14.1 – DSRC

A background on CAVs and their concepts 299
The DSRC protocol can be potentially used for any applications, such as collision avoidance at an
intersection, automatic vehicle safety inspection, electronic toll collection, parking payments, and
rail intersection warnings. As shown in Figure 14.2, DSRC can be used for Cooperative Adaptive
Cruise Control (CACC). This capability is useful when the other car may not be in the line of sight
and regular ACC is not sufficient.
Figure 14.2 – CACC with DSRC
Next, we will look at bike collision avoidance with DSRC, as shown in Figure 14.3. Through the use
of a DSRC-enabled smartphone, the position of a pedestrian or cyclist can be determined, and timely
alerts can be provided to prevent potential collisions.
Figure 14.3 – Bike collision avoidance with DSRC

We have looked at a couple of scenarios that can use DSRC to improve traffic safety. Next, we will
investigate the details of the DSRC protocol, as shown in Figure 14.4:
Figure 14.4 – DSRC protocol
This DSRC protocol diagram in Figure 14.4 caters to both safety and non-safety (or general) applications.
It depicts the related IEEE protocols such as the following:
• IEEE 1609.2
• IEEE 1609.3
• IEEE 1609.4
• IEEE 802.11p
The proper use of the DSRC protocol is likely to significantly drop the number of collisions and
casualties on the road by promoting the use of data transmission for V2V scenarios. There is a new
proposal by the US NHSTA for cars to broadcast a Basic Safety Message (BSM) every tenth of a
second. The BSM will include a vehicle’s position, speed, direction, acceleration, path history, and so
on. While critics of this proposal are worried about the privacy aspects of this, if approved, this will
reduce automobile robberies through its increased ability to track them (https://freedom-
to-tinker.com/2017/06/21/killing-car-privacy-by-federal-mandate/).
In the next section, we will look at the levels of driving automation and the standardization around it.
Levels of automation
Next, let us look into the details of AVs. An AV uses a combination of technologies to achieve various
degrees of autonomy and respond to external road, traffic, and weather conditions, similar to what a
human driver would do when driving a car. Figure 14.5 shows the different levels of automation for
an AV:
• LEVEL 0: No driving automation and the human driver is fully responsible for driving
• LEVEL 1: Driving assistance is provided to the human driver – e.g., ACC
• LEVEL 2: Partial automation to help the human driver – e.g., highway driving assistance
• LEVEL 3: Conditional automation in which the system can drive in some situations but
may occasionally need the human driver to step in when the system cannot handle it – e.g.,
moving off-ramp
• LEVEL 4: A high level of automation in which the system can do all the driving under certain
conditions without any human attention
• LEVEL 5: Full automation, where the system can drive the car in all situations that a human can
Figure 14.5 – Levels of automation in vehicles
Audi A8 planned Level 3 (L3) automation, but it was later canceled due to the lack of industry
regulations around it. However, Mercedes-Benz Drive Pilot is considered the world’s first L3 autonomous
driving system and was first made available in Germany in May 2022. It is available as an option for
Mercedes-Benz S-Class and EQS models. The Drive Pilot feature adds about $5-10K to the cost of
the car (https://www.motortrend.com/news/mercedes-benz-drive-pilot-eqs-

autonomous-driverless-first-drive-review/). It uses a combination of technologies
such as radar, Light Detection and Ranging (LIDAR), and stereo cameras to enable the sensing
required for safe L3 automation in driving. Tesla Full Self-Driving (FSD) Beta Version 10.69.x costs
around $15K and was released in September 2022. Tesla FSD Beta is not considered L3 automation.
Tesla drivers have shared a video of their FSD Beta experience here: https://www.youtube.
com/watch?v=qfKNMD8cm9o. About 100,000 Tesla cars in North America use FSD software.
It is interesting that software upgrades and new features can often be delivered Over the Air (OTA)
and benefit from the 5G network.
Mercedes-Benz uses 5G in a manufacturing facility for its automobiles, Factory 56 (https://group.
mercedes-benz.com/innovation/production/5g-network-production.html).
They have equipped Factory 56 with many 5G small-cell indoor antennas and a central 5G hub.
In March 2022, BMW launched its first 5G-equipped car, which is the 2022 model of BMW iX xDrive50.
This 5G capability utilizes the Magenta Drive service from T-Mobile. This service, which costs about
$20 per month, provides both the calls and data high-speed connectivity services for the car.
The 5G network will help to enable Level 5 (L5) or the full automation of vehicles over time by
providing low-latency communication between vehicles, as well as with infrastructure elements
such as traffic lights, road devices, and signage. This will reduce various risks in the transportation
industry, including traffic accidents. An autonomous cargo truck does not have to stop for a coffee
break, thereby reducing commute times and fuel costs. There are different pilots or autonomous cars
and taxis in flight such as the following:
• Waymo – Formerly owned by Google, it has operated an autonomous ride-hailing service in

the US since October 2020
• Cruise – A subsidiary of General Motors (GM) that is working on self-driving taxis and recently
got approval in California for the first Phase I Driverless AV Passenger Service Deployment
permit, allowing the company to serve passengers in its AVs without a driver present in the
vehicle (https://www.cpuc.ca.gov/news-and-updates/all-news/cpuc-
issues-first-driverless-autonomous-vehicle-passenger-service-
deployment-permit)
• Halo Car – A remotely operated car service in Las Vegas, US
• TuSimple – An autonomous trucking company in the southwest of the US (https://www.
tusimple.com/)
• Nuro – Nuro, started in Houston, TX, is focused on driverless cars for goods delivery rather than
transporting passengers, with heating and cooling capability for perishables (see https://
www.nuro.ai/vehicle and https://www.youtube.com/watch?v=L68ZzwtCon8
for more information)
We will continue to see the maturity of these pilots and limited production launches for AVs in the
near future. 5G will play a key role in these autonomous solutions due to its ability to support very
low latency, in the order of one millisecond. This enables the use of 5G in mission-critical applications
and end devices, such as ambulances leveraging smart car technology. The use of 5G, in convergence
with autonomous driving, will also facilitate the delivery of rich content to the passengers in the
car. The aviation industry is working with the automotive industry to explore flying cars. These are
commonly known as Electric, Vertical, Takeoff, and Landing (eVTOL) aircraft. eVTOL aircraft will
also use 5G for 3D navigation (https://www.frontiersin.org/articles/10.3389/
frcmn.2021.689881/full). Uber and AT&T are collaborating in this area. 5G uses the
massive Three-Dimensional Multiple-Input and Multiple-Output (3D MIMO) technology. This
5G technology will be very useful to provide the required eVTOL aerial coverage. Aerial ride-sharing
experiments are expected to begin in 2023 (https://gizmodo.com/uber-claims-aerial-
ridesharing-on-track-to-be-more-e-1835435983).
Next, let us look at the role of 5G-related associations and organizations.
The 5G Automotive Association (5GAA)

Let us learn about the 5GAA in this context. The 5GAA is a global cross-industry body
that consists of companies that span across industries such as automotive, technology, and
telecommunications (https://5gaa.org/about-5gaa/about-us/).
These companies include the eight founding members of the 5GAA from 2016: AUDI AG, BMW
Group, Daimler AG, Ericsson, Huawei, Intel, Nokia, and Qualcomm Incorporated. The 5GAA has over
10 members now. Their collective goal is to develop end-to-end solutions for advancing the future of
mobility and transportation:
Figure 14.6 – The 5GAA: the union of the automotive and telecommunications industries
Let us next look at the high-level architecture of AVs.

The high-level architecture of AVs

In the following sections, we will look at the high-level architecture that enables V2X. The automotive
industry is getting ready for the deployment of Cellular V2X (C-V2X) technologies. C-V2X is a 3GPP
standard. It describes how to meet the V2X requirements. C-V2X is an alternative to IEEE 802.11p,
which is a specified standard for V2V and other forms of V2X communications. C-V2X includes
LTE-V2X and NR-V2X technologies. 5G NR-V2X adds certain advanced capabilities on top of the
5G NR air interface. This adds stringent requirements to support CAV use cases.
C-V2X will use the 5.9 GHz band for direct communications using the PC5 interface. According
to the PC5 standard, the User Equipment (UE) directly communicates with other UE over a direct
channel, without the need for communication with the base station. The UE can be a mobile handset
or a vehicle, in this case (see Figure 14.7):
Figure 14.7 – PC5 interface
In Figure 14.8, we show a full view of V2X communication and how the PC5 interface is part of
that architecture.
The high-level architecture of AVs 305
Figure 14.8 – PC5 interface
Bodies such as the 5GAA are working to drive the necessary consensus between different stakeholders
to ensure homogeneity and interoperability across the ecosystem surrounding the autonomous
automobile industry. The 5GAA advocates for a deployment band configuration for the C-V2X industry.
The 5GAA believes that a formal agreement is required for the use of specific channels to deploy
C-V2X in the 5.9 GHz band.
Next, let us look at the CAV architecture.
Architecture for cooperative and intelligent transportation

The US Department of Transportation (DOT) created the Architecture Reference for Cooperative
and Intelligent Transportation (ARC-IT), which facilitates intelligent systems (https://www.
arc-it.net/). Figure 14.9 shows the ARC-IT in terms of the following:
• An enterprise view
• A functional view
• The physical view
• The communications view
This architectural approach facilitates the design and life cycle management of Intelligent Transportation
Systems (ITSs) such as AVs. It provides a common terminology for architects, design engineers, and
planners. Further details of the architectural view can be seen at https://www.arc-it.net/

html/architecture/architecture.html:
Figure 14.9 – ARC-IT view
The ARC-IT, in its prior form, was first developed in 1996. It provides guidelines for transportation
professionals as they devise new systems, including AVs powered by 5G. The ARC-IT provides four
views, as well as service packages, which are used to provide different service applications around
connected vehicles. Traffic Signal Control (TSC) is an example of a service package. The service
packages are grouped into 12 categories:
• Commercial Vehicle Operations

• Data Management
• Maintenance and Construction
• Parking Management
• Public Safety
• Public Transportation
• Support
The high-level architecture of AVs 307
• Sustainable Travel
• Traffic Management
• Traveler Information
• Vehicle Safety
• Weather
In summary, the ARC-IT helps to provide a common framework and set of standards for connected
systems and ITSs.
Next, let us look at the role of public cloud providers.
The role of cloud providers

To get the 5G network ready for various applications, including AVs, different telecommunication
providers are working with public cloud providers. AT&T is working with Microsoft to enhance its 5G
capabilities, using Azure for Operators (https://azure.microsoft.com/en-us/blog/
microsoft-partners-with-the-telecommunications-industry-to-roll-
out-5g-and-more/). Figure 14.10 shows how public cloud providers such as Microsoft Azure
are creating the computing infrastructure for 5G operators:
Figure 14.10 – Azure for Operators solution overview

5G operators are under pressure to quickly deliver the new network capabilities to both consumer
and enterprise customers. The integration of a 5G service-based architecture with hyper-scale cloud
providers such as Microsoft Azure and similar services unleashes the availability of a pool of cloud
application development talent. In other words, a massive software development pool is potentially
available to help accelerate the 5G mobile network development as well in some capacity, and the
cloud platform helps to bridge the gap.
The global developer population is 24.5 million in 2020, according to Statistica (see https://
www.statista.com/statistics/627312/worldwide-developer-population/).
SlashData estimates the global developer population to exceed 45 million by 2030 (https://
slash.co/articles/people-behind-your-tech-how-many-developers-are-
there-in-the-world/). The majority of these developers focus on public cloud technologies
these days. In summary, the convergence of 5G networks and the public cloud opens up the talent
pool for network software development.
AT&T is working on the following as part of its collaboration with Microsoft Azure:
• Testing Azure Operator Distributed Services, which will bring hybrid network support to
hosted network functions
• The development of a private 5G edge service for areas such as robotics in manufacturing, sales
support in car dealerships, and video health sensors in hospitals or clinics
• Trials of Azure public Multi-Access Edge Computing (MEC)
(See https://news.microsoft.com/2021/06/30/att-to-run-its-mobility-
network-on-microsofts-azure-for-operators-cloud-delivering-cost-
efficient-5g-services-at-scale/.)
AT&T’s private 5G edge service will be able to provide support for applications such as the use of
robotics in factories for manufacturing or latency-sensitive hospital applications. Telecommunication
companies such as AT&T and Singtel are piloting this service.
(See https://azure.microsoft.com/en-us/blog/new-azure-for-operators-
solutions-and-services-built-for-the-future-of-telecommunications/.)
Next, we will look at AV intercommunication.
AV intercommunication
The ability of a vehicle to communicate using technology such as 5G is the key enabler for AVs. Let
us look at different types of vehicle intercommunication.
AV intercommunication 309
Figure 14.11 shows the different types of V2X communications:
• V2V
• Vehicle-to-Pedestrian (V2P)
• Vehicle-to-Network (V2N)
• Vehicle-to-Infrastructure (V2I)
Figure 14.11 – Vehicle communications
An AV can generate as much as 4 terabytes of data per day. The 5G network comes in handy to move
such large volumes of data and use it to make timely decisions. Apart from the ability to act as a huge
data pipe, 5G acts as the vital glue between the vehicle, the driver, the Advanced Driver-Assistance
Systems (ADAS), other vehicles – both autonomous and others – cyclists, pedestrians, law enforcement,
and other infrastructure fixtures such as traffic lights or toll machines.
Let us look at how ADAS works.
ADAS
Next, we will look at the working of ADAS. Since many traffic accidents are caused by human
error, ADAS can help to prevent traffic accidents and their serious impacts on us. ADAS enables
applications such as blind spot detection, lane departure warnings, automatic emergency braking,
and pedestrian detection. Additional ADAS capabilities include automatic parking, ACC, and night
vision. Figure 14.12 shows how ADAS works (https://www.synopsys.com/automotive/
what-is-adas.html):
Figure 14.12 – ADAS at work
Figure 14.12 explains how each of the major ADAS capabilities comes into play for a stationary
vehicle or one moving on the road. These ADAS capabilities are enabled by a combination of sensing
technologies based on radar, LIDAR, cameras, and ultrasound. Purpose-built semiconductor chips,
SOCs, and electronics hardware are being developed to support these activities.
Next, let us look at the role of 5G here.
V2X and 5G
The ability of 5G to communicate with low latency is vital for these vehicle technologies. 5G networks
benefit from features such as Software-Defined Networks (SDNs) and network slicing. This allows
5G to provide latency about five times lower than 4G networks.
Bodies such as the 5GAA are driving the cross-sector consensus to enhance traffic safety and
efficiency in the transportation system for AVs. The 5GAA is fostering the convergence of autonomous
driving and mobile networks to help drive standardization. 5G acts as the vital glue between
vehicles, pedestrians, cyclists, ADAS, and AVs. The image and sound data collected by sensing the
environment and communicated between vehicles goes through machine learning tasks (see https://
embeddedcomputing.com/application/networking-5g/5g-is-paving-the-
way-for-autonomous-cars for more details).
The use of low bands such as 600 MHz for 5G can help connect vehicles as they move to remote areas
away from city centers. This is a big advantage for SOS-type calls over 5G requests for assistance in
emergencies made by drivers. On the other hand, high bands, using the millimeter wave frequencies
(24 GHz to 100 GHz), can provide high bandwidth and a higher level of user experience for both
drivers and passengers in these areas of coverage. High bands can support as much as a 10 Gbps data
rate over 5G.
AV intercommunication 311
Panasonic Connect Co. is also working with the city of Yokohama, Japan, to build out the preceding concept.
In the next section, we will investigate the role of network slicing in V2X.
Network slicing and V2X

As discussed in the prior chapter, network slicing helps to create virtual networks or “slices” within a 5G
network. Each network slice can have its own properties and serve specific application requirements.
In the case of AVs, network slicing with 5G can be useful for the following:
• Low-latency applications: AVs can utilize 5G network slicing with low latency for real-time
and near real-time communication with the network to make critical decisions.
• High-reliability applications: To ensure the safety and prevention of auto accidents, AVs
need access to a very high degree of reliability in communications. A network slice with high
reliability and redundancy can meet this need.
• High-bandwidth applications: Applications such as infotainment in AVs are examples of a
need for high bandwidth. A network slice with high bandwidth can fulfill this need.
Thus, we can see that by properly utilizing 5G network slicing, we can serve the diverse requirements
of AVs, such as low latency, high reliability, and high bandwidth.
Let us look at a high-level architecture for network slicing in the context of V2X. According to the
European Telecommunications Standards Institute (ETSI), the end-to-end latency for V2X is about
100 milliseconds for about 1,600 bytes of messaging, with the desired reliability of 99.999%. This is
used for vehicle safety messages, such as location, kinematics, cooperative cruise control, and collision
warnings (see https://ieeexplore.ieee.org/abstract/document/8385521).
Some of the seminal ideas for the use cases for network slicing in V2X communication are included
in the Mobile and wireless communications Enablers for the Twenty-twenty Information Society
(METIS) deliverable D 7.3, published in June 2017 (to download this publication, see https://
metis-ii.5g-ppp.eu/wp-content/uploads/deliverables/METIS-II_D7.3_
V1.0.pdf).
Figure 14.13 shows the high-level architecture for network slicing for V2X applications, such as
autonomous driving slicing and infotainment slicing over the same physical network. This in principle
is not very different from the separation of critical messaging, such as the Aircraft Communications
Addressing and Reporting System (ACARS) for aircraft when they are in flight, and infotainment,
which may include movies on demand, television, or internet browsing:
Figure 14.13 – High-level network slicing for V2X
In Figure 14.13, the autonomous driving slice is responsible for the reliable exchange of safety messages
in V2X, and the infotainment slice provides video and other non-critical services to the driver or
passengers. Other slices could be created for vehicle remote diagnostics and management. Likewise,
a network slice can support teleoperated driving and ensure ultra-low latency and high reliability
between the vehicle being controlled by a remote operator. For teleoperated driving, an end-to-end
latency of 20 ms is desired, with 99.999% reliability for V2N. For remote diagnostics that use V2I and
V2N, latency, data rate, and reliability are not a concern. However, for infotainment that uses V2N,
a bandwidth of a few Mbps may be needed for high-quality video streaming.
In prior generations, such as the legacy LTE-A network for connected vehicles, the Road Side Unit
(RSU) was responsible for providing different vehicle services. With the new approach, the RSU only
provides infotainment services. The virtual RSUs or access points provide reliable communication on
V2X now. This approach prevents the RSU as the single chokepoint for V2X communication.
Let us look at the network slicing of the RAN in V2X. It includes the following:
• Radio Access Technology (RAT) selection – This can be pure 5G or a mashup of other 3GPP
or non-3GPP access services. Often, multiple RATs may be configured to improve the V2I
capacity of the vehicle for different applications, such as infotainment or teleoperated driving.
• Radio Access Network (RAN) selection – Through the use of Cloud-RAN (C-RAN), often,
V2X network slicing can support the on-demand deployment of RAN functions. In this scenario,
the radio and baseband processing functionalities are split and the Baseband Unit (BBU) pool
runs in the cloud. These resources can be dynamically allocated to Evolved NodeBs (eNBs)
to meet the vehicles’ demands.
• Communication mode and primitive selection – The V2X slice configuration is mapped
to a communication mode such as sidelink or cellular communication. Likewise, a primitive
5G V2X 313
such as unicast, multicast, or broadcast can be used. A network slice for autonomous driving
may mostly use sidelink communications for localized interactions. Applications such as the
platooning of trucks may use unicast for V2I and V2N. However, multicast may be used for
accident or traffic jam warnings.
• Radio resource allocation – The 3GPP-recommended dynamic scheduling scheme adaptively
allocates radio resources based on the buffer status of UE and works well for vehicular infotainment
slices. An autonomous driving network slice may rely on semi-persistent scheduling.
• Numerology – Using different time/frequency numerology, 5G can support V2X communications.
This takes care of Doppler effects due to the high-speed movement of vehicles.
We have reviewed network slicing in the RAN. Next, we will look at network slicing of the Core
Network (CN) for V2X. This involves the following:
• Mobility Management Entity (MME) – The MME’s role in the CN is to manage the mobility,
session, and auth (authentication and authorization) procedures. A good and flexible design
principle is to enable multiple MME instances as Virtualized Network Functions (VNFs).
These interconnected MMEs can then meet the different V2X requirements.
• Evolved Multimedia Broadcast and Multicast Services (eMBMS) – This helps with the
quick dissemination of vehicle safety data in case of an accident or another emergency. The
autonomous driving network slice can be activated on the fly for multicast flows for these
safety-critical messages.
• Application servers – Traditionally, application servers run in the cloud or data centers. With
MEC, the V2X application servers can run at the eNodeB location. This allows for a reduction
in latency for V2X-related services.
After looking at the network slicing of the RAN, let us look at the slicing of the UE. On vehicular
devices, network slicing may impact certain configurations. In some cases, vehicular UE may even host
a V2X application server as a container. In these cases, a slice should be able to support the vehicular
UE to act as a storage unit for other UE nearby – for example, a pedestrian using a smartphone.
Now that we have looked at the network slicing considerations for V2X, in the next section, we will
deep-dive into V2X.
5G V2X
As we learned in the preceding sections, V2X refers to highly reliable communication between the
major components of intelligent transportation and traffic systems and their sensors. V2X requires
low-latency and high-bandwidth capabilities such as those provided by 5G.
Let us explore V2X further.
V2X technology
V2X is often used as the umbrella term for connected vehicles and the communications around
them. Figure 14.14 shows V2X communications (see https://www.autoweek.com/news/
technology/a36190311/v2x-technology/ for more details):
Figure 14.14 – V2X communications
In Figure 14.14, we can see the interplay of V2X with V2V, V2P, V2I, and V2N. In order to foster
interoperability, there are multiple standards around V2X. 5G communications allow fast-moving
vehicles to act like a smart cluster rather than individual cars (https://www.ericsson.com/
en/news/2019/9/5g-and-v2x).
Let us look at the V2X standards next.
The V2X standards

We will look at the standards that are evolving around AVs. IEEE 1609 is a collection of such standards
for Wireless Access in Vehicular Environments (WAVE):
Here is a list of WAVE standards:
• IEEE 1609.1: Resource Manager

• IEEE 1609.2: Security service and processing of secure message
• IEEE 1609.3: Networking Services
• IEEE 1609.4: Multi-Channel Operation
5G V2X 315
• IEEE 1609.11: Over-the-Air Electronic Payment Data Exchange Protocol for Intelligent
Transport Systems (ITS)
• IEEE 1609.12: Identifiers
These WAVE standards enable secure and reliable V2X communications (see https://www.
standards.its.dot.gov/Factsheets/Factsheet/80), and are meant for use by the
automotive industry, namely their engineers, as well as by transportation and traffic engineers. In
addition, the telecommunication industry must be aware of these standards to maximize the use of
5G for intelligent driving applications. The WAVE standard also applies to onboard vehicle systems
and any roadside devices, including traffic systems.
IEEE 802.11p is another important standard and it is the amendment to the 802.11 standards to
facilitate WAVE (see https://standards.ieee.org/ieee/802.11/10548/).
The IEEE 802.11 task group developed this amendment to improve upon Vehicular Ad Hoc Networks
(VANETs), which are mainly for broadcasting warning messages to nearby vehicles, such as in
emergencies or traffic congestion.
IEEE 802.11p defines how the V2X data interchange between high-speed automobiles, as well as
between automobiles and roadside infrastructure, should happen. It uses the licensed ITS band of 5.9
GHz (5.85–5.925 GHz) for communication. IEEE 802.11p deals with and improves upon the Medium
Access Control (MAC) and Physical (PHY) layers of the VANET.
In Figure 14.15, we look at the various V2X communication use cases:
Figure 14.15 – V2X communication use cases

As we can see in Figure 14.15, as automobiles become electric, Electric Vehicles (EVs) will require
Vehicle-to-Grid (V2G) communication. For the full potential of the V2X application, High-Definition
(HD) mapping is required, which needs 5G due to the data rate requirements.
Let us look at other applications of V2X, such as platooning trucks.
Platooning
Platooning is the collective and synchronized movement of a group of vehicles, such as a number of
trucks on the highway traveling between two cities. Figure 14.16 shows how V2V and V2I allow the
platooning of the trucks on a highway. Platooning requires semi-AVs or AVs to share a lane, with goals
such as reduced fuel use and the reduced need for braking, thereby reducing the carbon footprint and
improving overall safety in transportation. When the front truck – the Platoon Leader (PL) – brakes
or accelerates, all the remaining ones – Platoon Members (PMs) – do the same in a synchronized
fashion. With platooning, only the front truck may need an experienced driver or autonomous system
and the rest of the trucks can couple with it in a train-like fashion (https://www.ncbi.nlm.
nih.gov/pmc/articles/PMC5981612/):
Figure 14.16 – Platooning of trucks explained
Here, we saw a good application of 5G C-V2X communication. This utilizes the 3GPP specification
for communications over the sidelink by leveraging eNodeBs. Furthermore, platooning uses ACC and
its enhancement, CACC, to facilitate sensing across the whole platoon and not just the single truck
ahead. Figure 14.17 shows how C-V2X facilitates the control of the different trucks in the platoon:
5G V2X 317
Figure 14.17 – Platoon control strategy
In this section, we looked at the intersection of cellular technologies such as 5G and V2X communication
to drive the latest advances toward AVs. We looked at specific examples such as platooning.
We saw how in the context of V2X communication, 5G network slicing can be used to create dedicated
and optimized slices for V2X communication to meet the specific requirements of connected vehicles.
Network slicing can support different slices for different types of V2X communication, such as V2V,
V2I, and V2P.
Next, let us see how cloud computing enables V2X.
Cloud computing for V2X

Next, let us look at how cloud computing is becoming a key technological enabler. Figure 14.18
demonstrates the emerging role of CSPs in the C-V2X space:
Figure 14.18 – V2V and V2I enabled by CSP
CSPs are building a vehicular cloud to support C-V2X applications. Besides traffic-related applications,
the adoption of in-vehicle mobile commerce, powered by 5G, will create new sources of revenue
for different stakeholders in the C-V2X ecosystem (https://www.forbes.com/sites/
googlecloud/2021/11/01/car-talk-how-5g-mobile-and-cloud-are-
transforming-the-automobile/). Infotainment system in the cars will get a facelift with
5G; electric cars such as Tesla support 5G today (https://www.tesla.com/support/
infotainment).
Summary
In this chapter, we learned about the convergence of 5G and AVs. We looked at the different levels of
AVs. We then looked at how V2X communication is key for AVs. We looked at C-V2X and how 5G
is an integral part of it. We looked at intelligent applications such as the platooning of trucks, which
utilizes C-V2X.
Overall, this chapter covered the foundations of AVs and their detailed architecture. We looked at
the intercommunications of AVs. Finally, we looked at the emerging applications built on top of
V2V capabilities.
In Chapter 15, we will cover 5G fixed-mobile convergence. This capability allows for the seamless use
of 5G communication wirelessly or over wire.
15
5G Fixed Mobile Convergence
This chapter will focus on 5G Fixed Mobile Convergence (FMC), which enables 5G for broadband
networks. We will look at the drivers of and challenges for 5G FMC and the architecture that facilitates
the convergence. We will discuss the initial procedures that Residential Gateways (RGs) perform to
gain access to 5G services. We will explore how 5G FMC can be made secure.
Gartner describes FMC as a “Device and infrastructure technology trend that enables the transparent
use of voice and data applications across the fixed and mobile access points” (see https://www.
gartner.com/en/information-technology/glossary/fmc-fixed-mobile-
convergence).
This chapter will discuss the considerations for the convergence technology for 5G. It will go
into the system architecture used to facilitate FMC. We will discuss structural and functional
convergence. Furthermore, we will explore the details of FMC, such as the role of Protocol Data
Unit (PDU) sessions (see https://datatracker.ietf.org/doc/draft-allan-5g-
fmc-encapsulation/08/).
• Introduction to FMC in 5G
• FMC architecture
• FMC security considerations
Introduction to FMC in 5G
FMC blurs the line between fixed and wireless mobile networks. Its goal is to create a seamless consumer
experience by leveraging the best of fixed broadband and wireless networks. With FMC, a voice call
can be transferred between a mobile or cellular network and fixed or broadband network without
any interruption for the end user. Such services are also referred to as network-agnostic services. The
biggest benefit of FMC to the consumer is convenience. It allows reaching a person by using a single
phone number, irrespective of where that person is. For businesses, it helps to improve customer
320 5G Fixed Mobile Convergence
experience. Businesses can bring their point of presence closer to the target market. Wireless 5G
provides agility, and FMC offers enterprise-grade capabilities that are traditionally limited to wired
access. Some of the common FMC use cases are listed here:
• Initiating a phone call from a home phone and then continuing the call on your smartphone
as you walk to the grocery store
• Starting a streamed movie on your home TV and then viewing it on your smartphone at a
nearby park
• Searching for a new restaurant on your home computer and then sending directions to it to
your car’s navigation system
• Having a basketball finals game watch party with your friends, who can watch the same game
at the same time and discuss it on the phone while at different locations
• Bank Automated Teller Machines (ATMs)
• Temporary offices, such as at a construction site
• A small business kiosk bringing its own network access in a large mall
• A taco truck that operates at different locations close to its customers
• Vaccination centers (mainly during the COVID-19 pandemic)
• Internet of Things (IoT) devices in a large warehouse complex
The US retail chain Dollar General used LTE-based Fixed Wireless Access (FWA) to connect 2,000 of
its 13,000 stores to the internet. This connectivity simplified technology management for these stores.
To cater to such always-on experiences and use cases, FMC requires session redirection without any
explicit intervention by the end user. While FMC focuses on the convergence of fixed and mobile
networks, we have seen similar convergence between voice and data through VoIP services, and
between home entertainment systems and audio/video content via Internet Protocol Television
(IPTV). Hence, convergence is inevitable. One oversimplified way to look at FMC from the consumer’s
perspective is that it entails one phone service, one phone number, and one phone bill every month,
for postpaid service.
FMC also has its challenges, though, and not all of them are resolved yet. Many countries allow
number portability, with separate options for mobile number portability and fixed number portability.
However, portability between fixed and mobile networks is not easily workable. Likewise, seamless
phone directory services have limitations too. Other commonly used terms for FMC are FWA and
Global Wireless Access (GWA). Verizon started 5G FWA services in four US metros, namely Los
Angeles, Sacramento, Houston, and Indianapolis, in October 2018 (see https://www.verizon.
com/business/resources/events/fixed-wireless-access-webinars/).
According to Verizon, the demand for FWC is expected to grow at an annualized rate of 73% till 2026,
globally. Often, wireless routers have cellular modems built into them. That’s handy for implementing
FMC. Many companies are working together to make the hardware requirements for FMC easier
Introduction to FMC in 5G 321
to manage for their end customers. One such example is Verizon working with Cradlepoint on the
wireband adapter (see https://cradlepoint.com/press-release/verizon-boosts-
5g-fixed-wireless-access-strategy-with-new-cradlepoint-wideband-
adapter/).
Some of the technology enablers for FMC lie in services and protocols (https://vdocument.
in/fixed-mobile-convergence-fmc.html?page=7):
• Session Initiation Protocol (SIP)

• Real-Time Transport Protocol (RTP)
• IP Multimedia Subsystem (IMS)
• Unlicensed Mobile Access (UMA) and 3GPP’s Generic Access Network (GAN)
Let us investigate the details of each of these services and protocols.
Session Initiation Protocol

Let us look at the standards and protocols that enable the transportation of seamless network traffic
for FMC. The Internet Engineering Task Force (IETF) developed SIP, which is an application-level
protocol. The IETF is a large global body, established in 1986, that focuses on the evolution, architecture,
and seamless operation of the internet. It consists of network researchers, vendors, network architects,
operators, and other similar stakeholders. The IETF works closely with 3GPP for 5G standardization.
SIP is governed by IETF documents Requests for Comments (RFCs), namely RFC3261 and RFC3265.
SIP is a signaling protocol. It allows us to initiate, maintain, and terminate calls, such as for a real-
time multimedia communication session. SIP is used for both voice and video calls in the internet
telephony space. The open source implementation of SIP is available here: https://www.pjsip.
org/links.htm. A simplified architecture of SIP is shown in Figure 15.1:
Figure 15.1 – Simplified architecture of SIP

SIP helps to control the communications for services such as voice calls. The user agent in Figure 15.1
might be a smartphone or a softphone. SIP can run over Transmission Control Protocol (TCP),
User Datagram Protocol (UDP), and Stream Control Transmission Protocol (SCTP), which are
common protocols for the transport layer. A SIP INVITE request method can be used to invite
another party to a call session. More details about SIP functions can be found here: https://www.
extrahop.com/company/blog/2016/sip-protocol/.
Real-Time Transport Protocol

RTP endows the real-time characteristics of audio and video communication to end-to-end data
delivery services. RTP-based applications often utilize UDP services. RTP and RTCP are real-time
control protocols, and they work closely together. An audio or video conference application may use
RTP and RTCP Figure 15.2 shows a simplified view of RTP and RTCP
Figure 15.2 – Simplified view of RTP and RTCP
Figure 15.2 shows how RTP facilitates data transfer while control signals can leverage RTCP between
the senders and receivers.
IP Multimedia Subsystem
IMS plays a key role in the unification of broadband and fixed/wireless networks. IMS is also the glue
between FMC and traditional voice services. A simplified view of IMS is shown in Figure 15.3. In
summary, IMS is an open standard for facilitating voice and multimedia communications over packet-
based IP networks. Therefore, it plays a key role in network convergence. IMS is maintained by 3GPP.
Figure 15.3 – A simplified view of IMS
IMS often uses the IETF SIP protocol. According to 3GPP, IMS is key for FMC. Voice over LTE (VoLTE)
is based on IMS. IMS also supports roaming and internetworking with existing network services,
such as Public Switched Telephone Network (PSTN). Service-level convergence is provided by IMS.
Unlicensed Mobile Access

GAN originated in 2004 and is associated with Voice over Wi-Fi (VoWiFi) calling. The use of the term
GAN was replaced with UMA over time, but UMA is still associated with VoWiFi. This technology
allows sending cell phone packets to network access points over the internet instead of only over the
air or wirelessly. A UMA-compatible mobile phone can use Wi-Fi if it cannot reach a cellular network.
iPhone 5c and later are VoWiFi capable.
UMA is air interface-agnostic technology and can use Bluetooth in place of Wi-Fi if needed. The way
UMA works is that when the handset is on a local unlicensed LAN, the LAN is available along with
the licensed WAN. This enables a smooth transition between the use of LAN and WAN for the voice
call. As the user moves around and leaves the LAN coverage area, the call continues as it is roamed to
the WAN connection. No user intervention is required. Mobile network operators can set up Wi-Fi
hotspots to extend the coverage, say, inside a mall, where WAN coverage is weaker. The user handset
must be UMA-compatible for this.
Figure 15.4 – A simplified view of UMA
In this section, we looked at the enabler technologies for FMC. Let us look at a simplified view of FMC
in Figure 15.5. It shows the logical convergence of the network, device, and services.
Figure 15.5 – A simplified view of FMC
In Figure 15.5, the bottom left refers to wireless mobile networks and the right-hand side refers to
fixed broadband access. Together, these network infrastructures facilitate services such as voice, data,
audio, and video streaming, as well as home entertainment services such as IPTV.
Let us next look at the regulatory bodies and organizations that have played an active role in the
FMC space.
The Fixed-Mobile Convergence Alliance

We will look at the role of bodies such as the Fixed-Mobile Convergence Alliance (FMCA) now.
The FMCA strived for the seamless integration of cellular and fixed phone services. The founding
members of FMCA in 2004 were the following:
• British Telecom
• NTT
• Rogers Wireless
• Brasil Telecom
• Korea Telecom
• Swisscom
The purpose of this alliance was to encourage the seamless integration of mobile and fixed telephone
services (technological convergence). To this end, the FMCA started working closely with Standards
Development Organizations (SDOs) and other similar organizations, such as these:
• The Wi-Fi Alliance

• The Wireless Broadband Alliance
• The Home Gateway Initiative
• 3GPP
The FMCA did not focus on standards development for FMC; rather, they focused on advocating for
the adoption of convergence and related technologies. However, the demand for its services declined
and the FMCA stopped functioning in 2010.
Let us next look at the Broadband Forum.
The Broadband Forum

The Broadband Forum is a leading non-profit organization that works on standards, innovations, and
ecosystem development. Its projects span connected homes, 5G, and broadband access (https://
www.broadband-forum.org/about-bbf).
The Broadband Forum started in 2016 but is a merging of prior forums that are over 25 years old. It
has a Wireline-Wireless Convergence (WWC) Work Area. The role of the WWC Work Area is to
assist mobile operators with combined FMC-based offerings for their subscribers. This requires multi
or hybrid access as well as catering for work-from-home scenarios, which have been accelerated by the
pandemic. The convergence of voice communication with 5G is part of this. The Broadband Forum
works closely with 3GPP to facilitate functional network convergence.
To drive WWC, the Broadband Forum works with 3GPP on how fixed access can integrate 5G core
(see https://www.nokia.com/networks/core/5g-core/#WhatIsSA5GC).
5G Core includes functionalities such as the following:
• Broadband Network Gateway for convergence with wireline networks

• 5G policy control
• 5G core signaling
• The network data analytics function
• Slice management
Let us look at Broadband Network Gateway in more detail.
Broadband Network Gateway
Broadband Network Gateway (BNG) allows an operator to converge wireline and fixed-wireless
access. BNG acts as an access point for network subscribers and allows them to connect and consume
broadband services. BNG permits an operator to deliver a better subscriber experience, adding reliability,
affordability, and seamless customer experience. Figure 15.6 shows how multi-access BNG works.
Figure 15.6 – Multi-access BNG
Single-access technology often falls short of providing the right connectivity to users. FMC helps to
overcome this problem. Control and User Plane Separation (CUPS) is a good standard to follow
for multi-access. It allows the integration of wireless broadband and wireline services with 5G Core.
Residential services have evolved over time from dial-up internet to Digital Subscriber Lines (DSLs).
Solutions such as Nokia’s BNG help operators provide a range of services, including gigabit internet,
High-Definition (HD) video streaming, IPTV online gaming, and social media.
Fixed wireless convergence using multi-access edge helps to overcome the last-mile problem. The
last-mile problem refers to the gulf between the network provider’s infrastructure and the consumer
or business infrastructure, such as the home or office where the service is consumed. Often the last
mile is a greater challenge outside of major metropolitan areas. It is not feasible or cost effective to
lay fiber to every home or office where the service is required. Figure 15.7 illustrates the last-mile
problem, including the Optical Network Termination (ONT). The backbone of the internet is often
a fiber network.
Figure 15.7 – The last-mile problem
Often, it is not cost effective to lay fiber to every building and replace the older copper or similar cables.
A Fixed-Wireless Access Gateway (FWAG) often becomes an alternative in such cases.
Today, telecommunications providers want to offer their subscribers services that can leverage both
the fixed network, whether it is DSL or cable internet, and mobile or cellular networks. Today, an
average US household uses more than 10x the amount of data over their fixed network than over their
mobile network. The consumption of broadband data has increased during the COVID pandemic, due
to the work from home phenomenon. Conservative estimates describe a 30% increase in broadband
use per average US household over the pandemic (https://www.consumeraffairs.com/
news/americans-increased-broadband-use-by-30-percent-during-the-
pandemic-040821.html). The use of web conferencing services such as Zoom and associated
data increased 300% in some cases.
We envision that 5G Core will become integral to the convergence of fixed network and cellular services
over time (https://techblog.comsoc.org/2021/12/04/mobile-experts-on-
the-state-of-fixed-mobile-convergence-in-the-u-s-telecommunications-
market/). In the US market, the three major mobile wireless providers are Verizon, AT&T, and
T-Mobile, each with an estimate of over 100 million subscribers. The top fixed broadband providers are
Comcast and Charter Communications (which includes Spectrum Cable). However, AT&T, Verizon,
and T-Mobile also have sizable fixed broadband market shares. Hence, the convergence of services is
imminent. Some of the advantages of convergence are these:
• Standard interfaces
• Unified authentication
• Unified resource management
FMC will allow the 5G Core network to function independently and be decoupled from access
modes. FMC will enable users to be authenticated by a single operator. Overall, it will simplify
resource management (see https://www.zte.com.cn/global/about/magazine/
zte-technologies/2018/5-en/Special-Topic/1.html).
FMC is not limited to 5G; rather, it is available with LTE. However, with 5G, the convergence of cloud
networks, Virtual Network Functions (VNFs), and service functions allows FMC to provide diverse
applications to the consumer. Figure 15.8 provides a broader view of FMC.
Figure 15.8 – FMC: a high-level view

FMC’s architecture 329
In this section, we looked at why FMC is needed and how it helps to bridge the last-mile gap in network
services. Let us look at FMC’s architecture next.
FMC’s architecture
Figure 15.9 shows FMC’s architecture. This figure highlights the separation of CPs and UPs, or the
concept of CUPS. This helps to improve manageability for providers.
Figure 15.9 – FMC's architecture
The architecture shown in Figure 15.9 supports the centralization of the Control Plane (CP) and the
use of cloud infrastructure for scaling. This architecture allows a distributed User Plane (UP). Overall,
CUPS enables the use of both virtualized and physical infrastructure for CP and UP functionality.
It also gives us the flexibility to independently deploy and maintain the CP and UP functions, often
referred to as CPFs and UPFs, respectively. This composability allows flexibility in the upgrading of
the hardware and software infrastructure and loosely couples the CP and UP.
The Broadband Forum’s specification TR-459 provides details on how to separate the UPFs and CPFs. It
describes three interfaces for this purpose (https://onestore.nokia.com/asset/210510):
• The Management Interface, or Mi

• The State Control Interface, or Sci
• The Control Packet Redirect Interface, or CPRi
Next, we will look at how the separation of the CPFs and UPFs works, along with the disaggregation
of the UP (as in the use of physical and virtualized infrastructure). For more details, see Figure 15.10:
Figure 15.10 – The Broadband Forum’s TR-459
Figure 15.10 supports off-loading broadband internet and video traffic from 5G Core. This will facilitate
infrastructure scalability for fixed-wireless and mobile gateway network functionality.
Let us next look at the need for the 5G Residential Gateway (5G-RG). The 5G-RG is needed to
realize the full range of benefits of 5G for wireline. It can help to implement Quality of Service
(QoS) and improve overall reliability. The 5G-RG can be used to steer network traffic among access
technologies based on Key Performance Indicators (KPIs). These KPIs can be latency or throughput.
During the COVID-19 pandemic, the demand for home broadband increased. As a result, residential
customers' expectations of network operators have increased, and they now have to provide increased
reliability (https://www.broadband-forum.org/why-residential-gateways-are-
essential-for-wireless-wireline-convergence?cn-reloaded=1).
The use of the 5G-RG allows network operators to deliver an enhanced user experience to residential
customers, as shown in Figure 15.11.
FMC’s architecture 331
Figure 15.11 – 5G-RG
The 5G-RG can also enhance the security of a system. In combination with 5G Core, it can facilitate
a secure and separate session for device management. However, depending on the industry sector,
enterprise customers may have to look at the regulatory compliance that applies to them. Two examples
of such industry compliance are Payment Card Industry (PCI), which applies to the handling of
credit card information, and Health Insurance Portability and Accountability Act (HIPAA), which
applies to medical and health records. Enterprise users of FMC may need an additional end-to-end
security model to ensure their industry-specific regulatory compliance.
Since 5G enables the availability of an access-neutral service, it can be seamlessly made available over
5G New Radio (3GPP access) or Wi-Fi and other wireline access networks (non-3GPP access). This
non-3GPP access can take the following forms:
• Untrusted non-3GPP access networks: This uses Non-3GPP InterWorking Function (N3IWF)
• Trusted Non-3GPP Access Networks (TNANs): This uses Trusted Non-3GPP Gateway
Function (TNGF)
• Wireline access networks: This uses the RG and the Wireline Access Gateway Function (W-AGF)
In this section, we looked at the architectural considerations for FMC. In the next section, let us look
at the security considerations for FMC.
FMC security considerations

Let us look at the security considerations for FMC. Potential adopters of FMC, especially enterprise
users, often ask whether having their data travel wirelessly over long distances makes it more vulnerable
to cybersecurity breaches. Once the data leaves the enterprise wired network and enters the 4G or 5G
wireless network, it relies on the encryption of the wireless network.
Let us look at the potential security risks of FMC. Overall, cybersecurity risks for mobile operators
are on the rise. In July 2022, the French mobile operator La Poste Mobile experienced a ransomware
attack. La Poste Mobile was a victim of the LockBit ransomware operation (see https://
cybersecurityworldconference.com/2022/07/10/french-telephone-operator-
la-poste-mobile-suffered-a-ransomware-attack for more details).
Since FMC depends on many protocols and technologies, such as SIP and UMA, it is dependent on
the underlying security of those technologies.
SIP security
SIP is vulnerable to cybersecurity attacks if not properly secured. SIP security is based on the following:
• Authentication
• Confidentiality
• Other security functions
Securing SIP requires a defense-in-depth strategy.
Defense-in-depth
This is a cybersecurity concept where several independent layers are used to strengthen overall
security. National Institute of Standards and Technology (NIST) defines it as an “Information
security strategy integrating people, technology, and operation capabilities to establish variable
barriers across multiple layers and missions of the organization.”
Source: https://csrc.nist.gov/glossary/term/defense_in_depth
Secure SIP is one way of securing SIP communication and was first described in SIP RFC 3261
(https://www.ietf.org/rfc/rfc3261.txt). This helps to secure the sending of SIP
messages through a Transport Layer Security (TLS) encrypted channel. TLS is commonly used for
the security of HTTP sessions. TLS can be used to protect SIP session communications. It can prevent
eavesdropping or tampering with SIP messages. Hence, one way to secure SIP communication is to
limit the use of SIP devices that support secure SIP. This will improve the overall security of VoIP
networks and FMC.
FMC security considerations 333
One way to enhance secure SIP communication is to mandate the use of Message Digest (MD5)
authentication by all UAs and SIP proxy servers. This hardens the handshake between the SIP proxy
server and the SIP UA by adding an authentication challenge.
Figure 15.12 – Proxy-based SIP security
Figure 15.12 shows authentication and proxy-based security. A single security certificate can be used
to encrypt and sign a message for a related group of clients, for example, members of an organization,
to make it more efficient. The SIP proxy takes the role of signing and encrypting SIP messages. The
private key for security will reside centrally on the proxy server. This works well for a call center
relying on FMC.
In addition, the use of Secure Multipurpose Internet Mail Extensions (S/MIME) to encrypt information
with an SIP message is another effective way to secure it. See https://learn.microsoft.
com/en-us/exchange/security-and-compliance/smime-exo/smime-exo for
more information on S/MIME and how Microsoft uses it for email security.
Figure 15.13 shows the S/MIME-based security paradigm.
Figure 15.13 – S/MIME-based SIP security

The sending UA (Alice) creates multipart/signed S/MIME SIP messages. The UA uses the private
key to sign the body of the MIME message. The receiving UA (Bob) decomposes the message to
get the public key and validate the authenticity of the message. If there are signs of tampering in the
message, then remedial actions can be taken and a cybersecurity breach can be prevented. More
details about securing SIP can be found in this research paper: https://www.researchgate.
net/publication/41392312_Towards_Public_Key_Infrastructure_less_
authentication_in_Session_Initiation_Protocol.
By using a combination of SIP security mechanisms, we can implement defense-in-depth.
Next, we will look at UMA security.
UMA security
The security concerns of UMA are broadly as follows:
• Authentication
• Encryption
UMA authentication has to rely on Subscriber Identity Module (SIM) or Universal SIM (USIM).
SIM uses the A3/A5/A8 algorithms for security. USIM supports the F8/F9 (KASUMI) and MILENAGE
algorithms as well. For encryption, UMA relies on Wi-Fi security and IPSec (https://www.3gpp.
org/specifications/60-confidentiality-algorithms).
A security gateway helps to overcome some of the security challenges of UMA. A security gateway
provides the required confidentiality and data security for subscribers of FMA. The security gateway
does this by using IPSec tunnels to encapsulate the call and its signaling data. When the user’s handset
roams between wireless and 5G, the security gateway assists in the authentication and registration of
the user and their privileges.
Next, we will look at some UMA-security-related work done by Cisco several years ago along these
lines. See https://www.cisco.com/cdc_content_elements/flash/mobile_sols/
partners_site/pdfs/partners/kineto/CTIA_Tear_Sheet.pdf.
Figure 15.14 shows how Cisco secured their UMA architecture using a security gateway.
FMC security considerations 335
Figure 15.14 – Securing UMA
Cisco provides an enhanced UMA security gateway to offer a layered defense-in-depth approach that
protects VoIP communication.
Fixed Mobile Convergence (FMC) security

The overall topic of FMC security is quite complex, and risks are still emerging. The network security
landscape is rapidly changing. Today, network security revolves primarily around TLS. FMC will
expand this to the security of the control and signaling layers as well as the service and application
layers. The need for an Authentication, Authorization, and Accounting (AAA) service exists in this
context. The absence of such robust security mechanisms will create cybersecurity risks for operators
using FMC. (For more details, see https://technews.tmcnet.com/ipcommunications/
hot-topics/ims/articles/9675-fixed-mobile-convergence-fmc-security.
htm.)
Let us review the multi-layered security approach for FMC. It includes the following:
• IP TLS
• The policy and control layers
• The application/service layer
FMC relies on the multi-layer security paradigm. Threats could be external, such as SQL injections,
viruses, worms, Trojans, and zero-day vulnerabilities, or they could be internal to the organization.
Let us look at the security of the different layers.
IP TLS
Here we will mainly look at the security of the data plane and network protocols. Securing the data
plane prevents spoofing, and the use of Access Control Lists (ACLs) allows the dropping of all traffic
from a suspicious IP address range. In addition, IP fragment filtering can help to block fragmented
IP packets. This helps to prevent Denial of Service (DoS) attacks.
Network protocol security covers Border Gateway Protocol (BGP), Secure File Transfer Protocol
(SFTP), Secure Shell (SSH), and more.
The policy and control layers
Using stateless firewalls, an FWA provider can ensure that packet header inspection can take place
and decide whether a packet is allowed into the network. Stateful firewalls can be deployed to monitor
and control traffic. Packets that are not permitted can be dropped according to stateful firewall rules.
Firewalls should be SIP-protocol-aware to provide additional security in FWA. The use of VPNs with
IPSec can further enhance security. SIP firewalls can prevent man-in-the-middle attacks and prevent
authorized users from accessing voice mailboxes, call logs, directory services, and so on. Billing fraud
attacks have to be prevented as well.
The application/service layer
The use of Intrusion Detection Systems/Intrusion Prevention Systems (IDSs/IPSs) helps to

strengthen security at this layer. IDSs/IPSs extend firewall security and help to prevent intrusive
activity from malicious users. Such systems look for known patterns or signatures in permitted traffic.
These signatures can be updated to stay current. The biggest challenge is zero-day attacks. The use of
machine learning in IDSs/IPSs may prove an enhancement in this regard.
In this section, we looked at various ways to enhance overall security for FMC solutions. The provider
has the responsibility to provide sufficient security as well as sufficient QoS to their subscribers.
On one hand, FMC makes the delivery and consumption of a variety of services such as voice, data,
and video easier through the convergence of fixed and mobile networks. On the other hand, the
mechanisms for securing FMC are still in their infancy. As a result, the providers of FMC need to
carefully review the security implications of their network infrastructure. Some new security providers
are entering this space. One such provider, Benu Networks, uses BNG with support for 5G Access
Gateway Functions (AGFs). This allows operators to manage fixed-line subscribers using 5G Core.
Benu Networks helps to provide Secure Access Service Edge (SASE). They provide the integration
of SASE and 5G AGFs with virtual Broadband Network Gateway (vBNG). This helps in the faster
deployment of FMC.
Summary 337
(See https://benunetworks.com/cloud-native-bng-integrates-sase-and-
5g-agf/.)
In this section, we looked at the security considerations for FMC. We looked at how to create robust
security for FMC.
Summary
In this chapter, we looked at the factors driving the need for FMC. We looked at how FMC works and
the industry standards around it. Then, we looked at the architectural details for FMC. Finally, we
looked at the security concerns of FMC and how to overcome some of those concerns.
In the next chapter, we will learn about 5G and satellite communications. We will learn about recent
developments in non-terrestrial networks that can be used to improve the overall capabilities of
5G networks.
16
5G and Satellite
Communications
This chapter will focus on 5G and Satellite Communications (SATCOM). The rapid growth of 5G
services over the next few years will lead to advances in many complementary services. Terrestrial
mobile networks include 5G wireless services as well as fixed mobile convergence, which we studied
in Chapter 15. We are now seeing the capabilities of Non-Terrestrial Networks (NTNs), which can
extend and augment 5G cellular networks. This is enabled by SATCOM.
The coverage of satellite communications has increased in recent years and the cost has gone down.
This allows unique capabilities through the integration of satellite communications with Terrestrial
Networks (TNs) such as 5G cellular technology. Some recent developments include announcements by
Apple such as the emergency service for iPhone 14, internet service in Ukraine using Starlink systems,
as well as major 5G service providers announcing or already providing satellite-based coverage to
their subscribers. About 5 billion people have internet access today (https://datareportal.
com/global-digital-overview), which implies over another 3 billion could be connected.
For this purpose, the extension of 5G by using satellite communication on smartphones will be key.
• Introduction to satellite communications

• Why do we need satellite communication with 5G?
• The architecture of 5G and satellite communications
• Use cases of 5G and satellite communications
Introduction to satellite communications

With a global population of around 8 billion, the intersection of 5G and satellite communication has
huge potential to extend the reach of the internet for all. See Figure 16.1 for related statistics. As many
as 1 million new smartphones per day get introduced to users globally.
340 5G and Satellite Communications
Figure 16.1 – Global mobile phone and internet use
The increasing connectivity of consumers also leads to the greater use of social media as well as mobile
commerce. About 60% of users in the age group 16 to 64 with internet access make online purchases
weekly. The amount of mobile purchases is increasing. In 2021, online purchases of consumer goods
exceeded $3.8 trillion in the US.
The United Nations (UN) has a goal of connecting 90% of the global population to the internet by
2050 (https://transhumanica.com/asts). Such efforts could be accelerated by making all
or the majority of smartphones satellite phones. This could help to overcome the growing cost of cell
towers as well as issues with geo-political boundaries and hard-to-access terrains. The Iridium and
Starlink systems are pioneering efforts in this direction. However, the cost of these systems has to
come down to allow mass adoption. If regular smartphones can be easily adapted to utilize a satellite
communication system, it will be a breakthrough on this front.
AST SpaceMobile is working on the BlueBird satellite program, toward this goal (https://
spacenews.com/operational-ast-spacemobile-satellites-could-proceed-
without-prototype/). Their proposed approach uses large satellites with a modular design that
can allow smartphones to directly communicate with a satellite-based cellular system. The Federal
Communications Commission (FCC) granted AST a license for their experiment, in May 2022, to
test out BlueWalker 3 services in Texas and Hawaii.
Lynk (https://lynk.world) and Société Européenne des Satellites (SES) are working toward
similar goals of connecting smartphones with satellite communication. SES had about 50 Geostationary
Equatorial Orbit (GEO) and 20 Medium Earth Orbit (MEO) satellites in 2022. Figure 16.2 shows
the O03 MEO satellite system.
Introduction to satellite communications 341
Figure 16.2 – Architecture of MEO satellite system
Lynk started working on this idea after they saw the need to connect front-line health workers in
Africa during the Ebola outbreak. They started working on the universal mobile broadband initiative
in 2014. They realized that only 25% of the earth’s landmass had cell coverage. Besides, oceans had no
cell tower coverage. The use of dedicated satellite phones, which have bulky antennas and a large power
supply but no LTE or 5G coverage, has proved that consumer-grade satellite communication is feasible.
However, the next landmark is the convergence of smartphones and satellite phones. See Figure 16.3.
Figure 16.3 – Convergence of smartphones and satellite phones
On December 1, 2022, Apple iPhone Emergency SOS via satellite was put to use, helping to rescue
a person stranded in snow in Alaska. The Apple emergency response center alerted the proper local
authorities, the Alaska State Troopers, in a timely fashion, when the person in a snowmobile was lost
in an isolated area. The “accuracy and the completeness” of the satellite-driven alert from the iPhone
was impressive and shows that the convergence of 5G and satellite communication is already working.
This service was launched by Apple on November 15, 2022. This is clear evidence that we are ready
to put NTN systems to work with smartphones and make such services available to consumers (see
https://9to5mac.com/2022/12/02/use-of-emergency-sos/ for more details).
The Apple website provides details of how this service works on iPhone (see https://support.
apple.com/en-us/HT213426). Figure 16.4 shows the screenshots of the SOS (which is derived
from the phrase Save Our Ship) steps.
Figure 16.4 – Satellite-based emergency service on iPhone
Let us see, in Figure 16.5, the high-level architecture of the satellite-based SOS system. The Apple
iPhone 14 model includes the hardware component and required antenna to communicate with 48
Low Earth Orbit (LEO) satellites from a company called Globalstar. The first 2 years of this service
are free to consumers.
Figure 16.5 shows the high-level approach.
Figure 16.5 – How satellite-based Emergency SOS works
In Figure 16.6, we look at the next level of architectural details for this solution. We can see that the
Gateway (GW) to the Globalstar LEO satellite uses C-band, while the satellite-to-device connection
uses S-band and L-band for communication.
Figure 16.6 – Globalstar network architecture for SOS
T-Mobile and SpaceX are working toward a similar service (https://www.t-mobile.com/

news/un-carrier/t-mobile-takes-coverage-above-and-beyond-with-spacex).
This was announced in August 2022 and will be launched in 2023. In the United States, an area of
around 500,000 square miles does not have wireless coverage, including national parks, deserts, and
mountainous regions. In addition, oceans and large lakes also have dead zones. T-Mobile’s approach
will allow current smartphones on its network to be able to use the satellite service when it is launched
in 2023. Initially, under the Coverage Beyond offering (https://www.t-mobile.com/news/

un-carrier/coveragebeyond), consumers will have text message/SMS coverage and, later,
voice and data will be rolled out. In-flight coverage for text and SMS is part of this initiative as well.
Earlier-generation solutions for satellite phones were quite expensive. See Verizon offerings based on
Immarsat and Iridium here: https://www.vzwsatellite.com/. These used to cost about
$6-$9 per minute.
AT&T is working with a company called OneWeb on LEO-based SATCOM technology to extend the
reach of its TNs. AT&T has an extensive fiber network in the US with 2.5 million business customer
locations and another 9 million within 1,000 feet of its fiber network. However, what about all the
remaining business customers that are not within this reach? That is where the OneWeb relationship
enters the picture, with over 500 LEO satellites today (https://about.att.com/story/2021/
att_oneweb.html).
OneWeb is also working with British Telecom (BT). Likewise, Eutelsat is working with Deutsche
Telekom and Gruppo TIM on similar lines.
The holy grail of satellite broadband would be the backward compatibility of satellite communication
to work with existing smartphones. Imagine, with one call to the customer services department of
your cellular provider, you could enable satellite connectivity on your current smartphone without
exorbitant additional costs!
Let us next look at the Global Positioning System (GPS).
The Global Positioning System

We are familiar with GPS. GPS projects were initiated by the US Department of Defense in 1973. GPS
uses satellite signals to help find a location on earth (https://aerospace.org/article/
brief-history-gps).
At a high level, the GPS system has three main components, as shown in Figure 16.7, namely the following:
• Control segment
• Space segment
• User segment
Figure 16.7 – Architecture of satellite systems
The control segment is the earth-based system that manages the satellite communication system. The
space segment is a Geosynchronous Equatorial Orbiting (GEO) satellite that goes around the earth.
The user segment is the GPS device in the car or, going forward, the smartphone.
The GEO satellite orbits about 35.8 kilometers above the earth and the propagation delay for the round
trip is about half a second. While for location services, a 0.5-second delay may be acceptable, it may be
too much latency for other services typically supported by a smartphone. LEO satellites significantly
reduce the latency to below 50 milliseconds.
In the context of the positioning system, we often reference the Global Navigation Satellite System
(GNSS). GNSS consists of a constellation of satellites, around the earth. This collection of satellites
transmits a signal with positioning and timing data to GNSS receivers. This information is used to
determine the precise location on the earth (https://www.euspa.europa.eu/european-
space/eu-space-programme/what-gnss).
A nice video explaining GNSS can be found here: https://www.youtube.com/
watch?v=gffG5sTegT4&t=157s
Next, we’ll look at considerations for satellite communication in 5G.
Satellite communication in 5G
Satellite communication adds the satellite network to the network infrastructure of 5G. Since satellites
have a global reach, they can be used for the following:
• Data distribution to many regions

• TV broadcasts
• Broadband access
• Emergency communication
• IoT device connectivity
The backhaul segment of the 5G network can utilize satellite services. Smartphones such as Apple
iPhone 14 having the ability to directly communicate as a user terminal opens many other possibilities.
Figure 16.8 provides a high-level vision for the future of communication systems leveraging satellites
over urban, rural, and remote areas of the earth.
Figure 16.8 – 5G and satellite communication
Next, let us look at the organizations that influence 5G and satellite communication.
The role of regulatory bodies

There are several regulatory bodies and consortiums that influence the adoption of 5G and satellite
communication. We will look at some of these organizations and their contributions.
The 3GPP – NTN
The 3rd Generation Partnership Project (3GPP), which is the umbrella term for Standards
Development Organizations (SDOs) related to mobile telecommunications, refers to NTNs and
satellite communications in its Release 17 (Rel-17) and Release 18 (Rel-18) (https://www.3gpp.
org/news-events/partner-news/ntn-rel17).
The Rel-17 NTN topics are of general interest to both mobile- and space-related companies as well as
chipset and hardware system manufacturers. The 3GPP specifications target satellites in GEO, MEO,
and LEO, as shown in Figure 16.9.
Figure 16.9 – Different satellite orbits
The 3GPP Rel-17 specification targets use cases such as the following:
• Narrowband Internet of Things (NB-IoT) support

• Enhanced Machine Type Communication (eMTC)-based Massive Internet of Things (MIoT)
use case support for connecting a very large number of devices
NB-IoT is for lower data rates and infrequent IoT device communication. eMTC allows higher data rates
and more overall throughput, including MIoT use cases in industry domains such as transportation,
supply chain and logistics, and even smart agriculture. There were some competing features in NB-IoT
and eMTC. In June 2017, 3GPP Rel-15 reached a consensus and resolved those issues.
The initial work for NTN started with Release-15 in 3GPP RAN Working Group 1 (WG1) in June
2017. It stated that NTNs will be integral to 5G service deployment by doing the following:
• Enabling ubiquitous connectivity to public safety and IoT devices where the 5G terrestrial
network is lacking
• Adding resistance to natural disaster impact to cell services and towers, such as during
earthquakes, fires, hurricanes, flooding, and tsunamis
• Enabling 5G-RAN connectivity
• Enabling 5G services in aircraft, hot air balloons, and drones, as well as mid-ocean ships
• Enabling scenarios that involve terrestrial and in-flight objects
These things together help to add a) service ubiquity, b) service continuity, and c) service scalability
to 5G networks.
Next, let us look at the contributions of 5G Americas.
5G Americas
5G Americas, formerly called 3G Americas and 4G Americas, is an industry association involved in the
development of 5G and related standards for the Americas (https://www.5gamericas.org/).
In its white paper on the future of mobile communications, 5G Americas states that satellites and
NTNs will extend interconnections to a three-dimensional space (https://www.5gamericas.
org/mobile-communications-toward-2030/). This will support very dense device
connections. Apart from GEO, MEO, and LEO satellites, balloons, drones, and aircraft may also help
to extend NTNs’ connectivity, in the long run. Likewise, future quantum communications may also
be facilitated by NTNs.
In its publication titled 5G and Non-Terrestrial Networks, 5G Americas discusses how 5G services will
help to bridge the digital divide by leveraging satellite-based communication in conjunction with the
communication infrastructure in place (https://www.5gamericas.org/5g-and-non-
terrestrial-networks/).
Next, let us look at the ITU and its role.
The ITU
The International Telecommunication Union (ITU) works toward the enablement of the digital
economy and has over 900 members (https://www.itu.int/en/about/Pages/default.
aspx).
The ITU is a UN-specialized agency with a focus on IT and communications strategies. The ITU was
founded in 1865, with the goal of facilitating connectivity in communication networks globally. The
ITU’s goal is to connect everyone around the world to the internet. The ITU Academy also offers
advanced training in the area of 5G (https://academy.itu.int/training-courses/
full-catalogue/5g-advanced-mobile-broadband-internet-and-new-services).
The ITU has championed the affordability of smartphones globally. According to its publication, a 10%
increase in access to mobile broadband would lead to a 1.5% increase in the Gross Domestic Product
(GDP) (https://www.broadbandcommission.org/working-groups/smartphone-
access/). Satellite communication will be key in the additional reach of mobile broadband. The
Broadband Commission for Sustainable Development is working to reduce the price of entry-level
smartphones to make them more affordable.
The availability of 5G services opens up opportunities for Mission-Critical Services (MCSs). The
types of applications supported by 5G and their availability in remote areas can include the following:
• Remote patient monitoring where skilled healthcare workers are scarce

• Drones and autonomous vehicles
• Industrial automation/smart factories
• Smart grid and energy management
These are some examples of how the intersection of 5G and satellite communication will contribute
to economic growth in many parts of the world through the adoption and availability of superior
technology. This will generate better employment opportunities as well. This ties into the UN’s
Sustainable Development Goal 9 well, which relates to building resilient infrastructure and promoting
inclusive and sustainable industrialization, as well as fostering innovation (https://sdgs.
un.org/2030agenda). The 5G and satellite communication network would fall under the resilient
infrastructure that would promote industrialization.
The article by the ITU titled Space for change: satellites in the service of digital transformation paints
a picture of a satellite-enabled future and their role in connecting smartphones to drive digital
transformation (https://digital-world.itu.int/space-for-change-satellites-
in-the-service-of-digital-transformation/).
Next, we’ll look at TM Forum.
TM Forum
TeleManagement Forum (TM Forum) is an alliance of over 850 companies promoting technology
services and breaking down technological and cultural barriers. TM Forum helps communication
service providers by connecting them to the broader ecosystem, enabling them to capitalize on new
opportunities such as 5G and satellite communications (https://www.tmforum.org/about-
tm-forum/).
TM Forum provides a 5G monetization and Return on Investment (ROI) toolkit for its members.
TM Forum published an article about Ericsson, Qualcomm, and Thales testing satellite technology for
different aspects of 5G NTNs in France (https://inform.tmforum.org/features-and-
opinion/will-5g-trial-be-a-game-changer-for-satellite-connectivity/).
One of the goals of the previously mentioned experimentation is to ensure that not only can 5G NTNs
provide a backup to disruption to regular 5G networks but they can also be regularly used for specific
purposes such as for national security and critical public services. In addition, support for global
roaming services for IoT devices is being investigated. The cost of satellites and Customer-Premise
Equipment (CPE) remains a concern today.
Let us next look at ATIS.
ATIS
The Alliance for Telecommunications Industry Solutions (ATIS) has over 150 member companies
that work together to advance 5G-related standards, robocall mitigation, IoT, smart cities, cybersecurity,
and so on. ATIS is one of the seven SDOs affiliated with 3GPP (https://www.atis.org/
wp-content/uploads/2022/03/2022-Overview.pdf).
ATIS focuses on open programmable 5G, as well as research on Artificial Intelligence (AI) and
Machine Learning (ML) in 5G. ATIS has a group called 5GORR, or the 5G Operational and
Regulatory Requirements group. 5GORR is looking into non-public or private 5G networks that
can operate in factories, wind turbine farms, oil rigs, university campuses, and other public facilities.
Often, these non-public locations may need to use satellite communication to connect between
different locations. ATIS also facilitates 5G-related interoperability testing. ATIS is recognized by
the American National Standards Institute (ANSI). ATIS is also a member of ITU and the Inter-
American Telecommunication Commission (CITEL).
ATIS often publishes thought leadership papers on futuristic use cases of 5G. One such publication is
titled 5G Supply Chain Standard: Creating the Foundation for Assured 5G Networks. It discusses a phased
approach, 1) Awareness, 2) Insight, and 3) Assurance, to help build a global, robust 5G supply chain
system (https://www.atis.org/resources/atis-5g-supply-chain-standard/).
Next, let us look at any possible challenges to satellite communication, especially due to 5G.
Challenges to satellite communication

Satellite communication devices usually operate in frequency bands such as C-band. They normally
receive signals in the 3.4 to 4.2 GHz range. They transmit in the 5.85 to 6.425 GHz range. 5G cellular
technology uses part of the C-band, causing potential interference in cellular communication. Countries
in Africa as well as China and Russia use 5G networks below 3.6 GHz. In Europe, many countries use
the 3.4 to 3.8 GHz range. A possible way to overcome interference is the use of a Low-Noise Block
Downconverter (LNB) or a waveguide filter. More details on how these methods work can be found
here: http://www.satmagazine.com/story.php?number=2132459167.
On a related note, 5G C-band signals may interfere with aircraft equipment too.
Let us next look at why we need satellite communication with 5G.
Why do we need satellite communication with 5G? 351
Why do we need satellite communication with 5G?

Let us investigate the role of satellite communication with 5G and why it is needed. Satellite communication
can provide cellular coverage in hard-to-reach places with terrestrial networks, such as in the middle
of the ocean, on a ship, or on a small island. 5G networks can use satellite communication to increase
their capacity. Satellite communication can act as a backup for 5G networks.
The European Union’s (EU’s) Horizon 2020 program and the European Space Agency (ESA) have
been researching satellite convergence with 5G. They have the common goal of developing the satellite
and TN for 5G by leveraging GEO, MEO, and LEO satellite systems.
The main reasons for the use of satellite communication systems for 5G are the following:
• Satellite backhaul: When a suitable terrestrial network is lacking, we can use fixed satellite
backhaul to single small cells and base stations. This can support eMBB and provide 5G
connectivity in regions lacking cellular infrastructure. Some degree of IoT application support
can be provided via mMTC.
• Connecting homes and premises: Homes and offices can be provided broadband services as
an alternative to installing fiber optic cables in rural and semi-rural areas. The use of distributed
small cells can provide this connectivity. Overall, fixed wireless access will promote connectivity
for underserved areas as well.
• Mobile assets and platforms: Mobile infrastructure assets such as ships, trains, airplanes, postal
delivery trucks, taxis, and cars require roaming capabilities as they may traverse localized 5G
cellular networks. Such mobile assets are good candidates for a 5G satellite network.
• On-demand services: A 5G satellite network can be used for content on-demand downloads
in low-density areas. Imagine a government university providing online courses or degrees to
students living in the desert or mountainous areas. They could download the content in regular
intervals leveraging satellite multicasting.
More information can be found at https://www.microwavejournal.com/articles/33942-

the-role-of-satellites-in-5g-networks. Figure 16.10 shows how the 5G network
integrates with the satellite network.
Figure 16.10 – Satellite integration with the 5G network

We looked at the need for SATCOM in the context of 5G in this section. Next, we will look at the
architectural needs to support that.
The architecture of 5G and satellite communications

Let us look at the architecture of satellite communication in the context of 5G networks. We have
already learned about three types of satellites:
• Geostationary Earth Orbit (GSO): Some examples include the PanAmSat, Intelsat, and
Inmarsat satellite systems
• Medium Earth Orbit (MEO): The Galileo satellite and GPS are some examples.
• Low Earth Orbit (LEO): Starlink, Viasat, Iridium, and Globalsat are some examples.
Figure 16.11 is a diagram of the different types of satellite orbits around the earth. Many of these
satellites co-exist with the terrestrial networks to create a 5G satellite-based network.
Figure 16.11 – Satellite orbits
Figure 16.11 shows that GEO satellites cause a latency of 600-800 milliseconds (ms) for the roundtrip.
This roundtrip latency drops down to 125-325 ms for MEO, and for LEO, to 30-50 ms. The power
needed by end user devices is greater when using GEO or MEO. LEO allows direct connectivity with
a smartphone as User Equipment (UE) due to low power requirements as well as low latency.
The architecture of 5G and satellite communications 353
Figure 16.12 – Features of satellite orbit platform
Figure 16.12 shows the characteristics of the GSO, which stands for geostationary orbit, and
Non-Geostationary Orbit (NGSO) platforms (MEO and LEO) for satellites.
Figure 16.13 – 3GPP specifications and satellite communication
Figure 16.13 shows that NTN-related specifications started with R-17 and R-18 adds enhancements to
it. 3GPP R-17 started support for NTN and that has led to greater adoption of satellite communication
with 5G by service providers. R-18 will add support for cellular drones.
R-17 supports bent-pipe and transparent architecture for satellite communication. This implies the
information transmitted from earth to the satellite is sent right back. Pictorially, i creates a shape like a
bent pipe, as shown in Figure 16.14. This is the simplest form of satellite communication. The satellite
may amplify the signal received from earth. The satellite does not do any other complex processing to
the signal, keeping its systems simple. The satellite acts like a passive repeater in this case.
Figure 16.14 – Satellite bent-pipe architecture
The LEO Globalstar satellites use bent-pipe technology (https://globalcomsatphone.

com/learn-about-globalstar-bent-pipe-and-path-diversity-satellite-
technology-globalcom).
Figure 16.15 – Satellite transmission technology

Let us look at the impact of a voice call using bent-pipe versus crosslink technology, as shown in
Figure 16.15. The latency between the satellite phone and the landline would be lower due to a single
satellite hop. Globalstar and Inmarsat use such bent-pipe technology. On the other hand, Viasat and
Iridium use crosslink technology, which can reduce the quality of voice communication and add
latency for certain scenarios as the signal transmission time may increase. It requires a mini modem
and router in each LEO satellite (https://www.satellitephonereview.com/networks/).
There are a few other alternatives to bent-pipe architecture, such as regenerative architecture and
onboard processing architecture. In the regenerative architecture, the satellite processes the signal
before retransmitting it.
Figure 16.16 – Satellite regenerative architecture
We can see in Figure 16.16 that the Core Network (CN) is terrestrial, and the Radio Access Network
(RAN) is in the satellite. In the case of bent-pipe architecture, both the CN and RAN are terrestrial,
keeping the satellite’s system simple. In this scenario, the satellite systems may also do error correction
and signal quality improvement before retransmitting it. In the onboard processing architecture,
the satellite may perform tasks such as error correction, encryption, and modulation. This makes
the onboard processing more complex. However, it can make the satellite system more reliable and
efficient. It drives up the cost of satellite systems.
Knowledge of 3GPP specifications such as R-17 and R-18 and their coverage of NTN helps to decide
which satellite system to utilize when architecting a satellite-based 5G solution. While LEO provides
lower latency (30 to 50 ms), it will have lower geographical coverage when compared to MEO/GEO.
In turn, MEO and GEO have a lower deployment cost per unit of geographical coverage. For an LEO
system, there will be different satellites in view of the UE, leading to handoffs. That can make the
design of the 5G system more complex.
Next, let us look at the different spectrum frequencies allocated by 3GPP for NTN. There are two main
Frequency Range (FR) groups, namely FR1 and FR2, as shown in Table 16.1:
Name Frequency Range Bands

FR1 450 MHz to 6 GHz S-band and L-band
FR2 24.25 GHz to 52.6 GHz Not applicable
For NTN, 3GPP has ratified the following S-band and L-band for FR1:
• S-band: It ranges from 1,980-2,010 MHz and 2,170-2,200 MHz. As per the ITU, S-band is
for use in satellite and terrestrial components of International Mobile Telecommunications
(IMT) frameworks.
• L-band: Certain parts of this band are used for Maximum Segment Size (MSS). It depends on
the GSO or NGO composition. Note that 3GPP cannot dictate the use of such bands for NTNs
universally. Some countries may have different local use of this band for terrestrial use. The
ITU helps to co-ordinate between the countries in such cases for satellite and mobile network
operators (https://www.itu.int/en/ITU-R/terrestrial/broadcast/
Pages/Bands.aspx).
In Figure 16.17, we see the high-level NTN architecture spanning urban, rural, and remote area
coverage. For urban coverage, we see the use of Unmanned Aerial Vehicles (UAVs) or drones. AT&T
has tested cell on wings to provide 5G coverage for about 10 square miles using a drone.
Figure 16.17 – NTN network architecture

Let us look at the two common types of satellite-based NTN communications. In Figure 16.18, we see
the first scenario, where only one satellite is involved in the communication and both the sender and
receiver are communicating with the same satellite. In this context, UAS refers to unmanned aerial
systems and ISL stands for inter-satellite link.
Figure 16.18 – Scenario 1 of NTN architecture
In scenario 2, as shown in Figure 16.19, we see there is more than one satellite involved in the NTN
communication. The satellites communicate with each other via the ISL. In this case, the sender and
the receiver are communicating with different satellites. In a general case, there can be more than two
satellites involved for the ISL part.
According to 3GPP TR 38.82117, the two typical scenarios of a satellite-based NTNs providing access
to UE are depicted as follows:
Figure 16.19 – Scenario 2 of NTN architecture

Finally, in Figure 16.20, we look at the TN and NTN communication scenario based on the interoperability
of GEO and LEO satellites, to provide global coverage.
Figure 16.20 – NTN network architecture between different types of satellites
With support for the three different scenarios of NTN-based communication, 5G can truly provide a
global reach and overcome the lack of terrestrial cell towers in every part of the earth – the land and
the oceans (https://www.5gamericas.org/wp-content/uploads/2022/01/5G-
Non-Terrestrial-Networks-2022-WP-Id.pdf).
Let us evaluate security implications next. Under the NTN architecture, the current 5G security
considerations will apply to NTN and 5G communication. The key considerations will remain as follows:
• Authentication and authorization

• Integrity and replay protection
• Confidentiality protection
Privacy may emerge as the next consideration for this area. With mobile UE, the location and movement
of people or assets can be subject to privacy requirements. We may see future evolutions of security
implementations at the interface of the satellite GW and current 5G systems.
Let us discuss the security measures for 3GPP (untrusted and trusted) for New Radio (NR)-based
access. Figure 16.21 shows an untrusted scenario per the 3GPP TS 23.501 specification. It uses the
Non-3GPP Interworking Function (N3IWF).
Figure 16.21 – Untrusted non-3GPP access via satellite
Figure 16.22 shows a trusted scenario, which relies on the Trusted Network Gateway Function (TNGF).
Figure 16.22 – Trusted non-3GPP access via satellite
Finally, we’ll look at the security considerations for NTN- and TN-integrated communication. This
scenario is shown in Figure 16.23.
Figure 16.23 – Securing NTN integrated with TN
In Figure 16.23, a single satellite-based mobile network includes one 5G CN using different types of
access networks. Satellite connectivity provides one access network. Conventional TNs are the other
access networks in this case. The 5G UE or the NTN UE has satellite communication capabilities.
On the ground station for the satellite network, the satellite GW or the hub provides the 5G gNB
functionality. The satellite network supports the NR. When the satellite network acts as a non-3GPP
access network, the GW or the hub will act as the N3IWF for untrusted non-3GPP. It will act as
the TNGF in the case of trusted non-3GPP. For more details, see https://www.wipro.com/
network-edge-providers/untrusted-non-3gpp-access-network-interworking-
with-5g-core/.
In this section, we have looked at the architectural considerations for the convergence of 5G and NTN.
Next, we will look at the use cases for 5G and satellite communication.
Use cases of 5G and satellite communication

In this section, we will discuss the different 5G use cases for satellite communication. Earlier in the
chapter, we looked at the use of Apple iPhone 14 with Globalstar connectivity for emergency purposes.
Cellular providers are catching up, with similar solutions that are agnostic to the make of the smartphone.
On one hand, 5G allows cellular networks to provide high speed and lower latency, as compared to
the previous generation of mobile technology. On the other hand, satellite communication helps
to connect areas that are out of coverage of terrestrial communication networks. Together, the two
technologies help to bring the best of both to users. It is very useful for connecting remote areas or
applications with a high degree of mobility, often seen in the aviation industry, the maritime industry,
Use cases of 5G and satellite communication 361
transportation, and public services in the case of large-scale disasters such as earthquakes or tsunamis.
The convergence of 5G and satellite communication also enables large-scale IoT use cases. Autonomous
vehicles, as well as military communication, are other beneficiaries here.
Today, metro areas and communication between the major cities of a country have good coverage
through TNs powered by fiber and Wi-Fi networks. However, the new avenues for 5G and satellite
convergence are the following:
• Coverage for moving devices such as cruise ships, cargo vehicles, trucks, and goods trains
traveling cross-country with precious cargo
• IoT connections and asset-tracking scenarios where coverage is needed both within cities
and remote areas such as power-generation grids with wind turbines, solar farms, and
hydro-generation facilities
• Edge computing scenarios where the processing and caching of data is moving progressively
closer to the field location and further away from the cloud core or central data centers
See https://www.wilsoncenter.org/article/role-satellites-5g-networks
for more details.
While TNs can extend connectivity for devices close to the periphery of large cities, such as the suburbs,
SATCOM along with 5G is the only way to provide continuous connectivity between metro areas
with a high degree of reliability, network bandwidth, and Quality of Service (QoS). Lockheed Martin
is working with a satellite company called Omnispace (https://news.lockheedmartin.
com/5g-omnispace-agreement).
The Lockheed Martin initiative for 5G NTN will make use of Omnispace’s 2 GHz S-band spectrum
rights. These will be used to deploy the 3GPP standards to enable direct-to-device connectivity and
interoperability. This hybrid SATCOM and 5G network can then facilitate the necessary coverage and
capacity for applications that need global, seamless communications with high reliability. This may
include support for defense, government, and military use as well.
According to the SAT5G project from Europe (https://5g-ppp.eu/sat5g/), the four use
cases are summarized as follows:
• Fixed backhaul for inaccessible or hard-to-reach areas

• Complementary services for areas underserved by TNs
• Complementary broadband connectivity for edge computing
• Moving platforms such as ships, trucks, and trains
Let us next look at Figure 16.24, which presents the high-level 5G vision of NTN use cases visually.
It covers, on one hand, dense urban areas and on the other, isolated and remote scenarios such as
connectivity to a ship in the middle of the ocean.
Figure 16.24 – High-level vision of 5G and NTN
In the next section, in Table 16.2, we tabulate use cases in more detail and provide the corresponding
5G service enabler (https://www.5gamericas.org/5g-and-non-terrestrial-
networks).
Use Case 5G Service Satellite Description

Enabler Service
Multi-Connectivity eMBB Broadband Users in underserved
connectivity for areas (home or site offices,
cells/relay nodes in construction sites, events, and
underserved areas. conferences) are connected to
Can be combined a 5G network, using different
with TN or network technologies. Latency-
wire-line access. sensitive traffic can be sent over
priority networks, as compared
to other traffic, for example, voice
compared to data.
Fixed-Cell Connectivity eMBB Broadband 5G services with high data rates,
connectivity for users in remote settlements or
between CN and industry locations such as oil rigs
cells in isolated and and mines.
underserved areas.
Mobile-Cell Connectivity eMBB Broadband Passengers onboard aircraft,

connectivity ships, or other vessels, with access
between CN and to high-data-rate 5G services.
cells onboard a ship
or aircraft.
Trunking eMBB Broadband Allows network operators to

connectivity between interconnect different 5G local
a mobile network access networks.
anchor point and
Allows network operators to
the public data
deploy a 5G service as disaster
network or between
recovery in an isolated area not
two mobile network
connected by public data or a
anchor points.
fibre network.
Edge Network Delivery eMBB Broadcast channel Allows offloading content

to support multicast from a mobile network
delivery to 5G infrastructure at the backhaul
network edges. level. Video and media content
including live broadcasts, group
communications, and multi-
access edge computing’s virtual
network function updates
transmitted in multicast mode to
RAN equipment at the network
edge stored in a local cache or
distributed to UE.
Mobile-Cell eMBB Broadband Allow reliable 5G connectivity
Hybrid Connectivity connectivity between for mobile passengers on public
the CN and cells in transport such as buses, trains,
isolated areas. cruise ships, and boats. A base
station connected by a hybrid
cellular/satellite connection
serves such mobile users.
Direct-to-Node Broadcast eMBB Broadcast/ TV or multimedia service
multicast service delivery to a home or onboard a
to access points in moving platform.
homes or onboard
moving platforms.
Local-Area IoT Service mMTC Connectivity A group of IoT sensors that

between a mobile collect data, connect to each
CN and base station other in a peer-to-peer fashion,
serving IoT devices or to the IoT core or aggregator.
in a cell or a group The IoT core may also be
of cells. sending actuator signals to the
edge. The IoT sensing devices
may be served by a LAN as part
of a smart grid or onboard a
moving vessel.
Wide-Area IoT Service mMTC Connectivity Global continuity of service for
between IoT devices telematic applications based on
and spaceborne a group of sensors/actuators
platforms and such as IoT devices, scattered
terrestrial base over or moving around a wide
stations is needed. area, and communication to the
IoT core. These scenarios may
involve telematics applications
for the automotive industry with
applications such as platooning,
traffic flow optimization, OTA
updates, and so on. Other
scenarios are asset tracking and
fleet management or critical
infrastructure monitoring.
Finally, also smart agriculture
and livestock management.
Direct-to-Mobile eMBB Broadcast/multicast Allows public safety authorities
Broadcast service directly to UE to alert/warn the masses in
whether handheld or case of catastrophic events and
mounted in a vehicle. provide them with guidance
during disaster relief while the
TN is down. Automotive industry
use for firmware and software
updates in the case of auto recalls,
via OTA. Also, map updates
and early warning broadcasts
for tornados, earthquakes,
flash flooding, or terrorism and
amber alerts.
Wide-Area eMBB Access to Emergency responders including

Public Safety handheld or law enforcement, the fire service,
vehicle-mounted UE. paramedics, and medical
professionals can use voice
calls or messaging in outdoor
conditions to provide continuity
in mobile scenarios such as
those involving ambulances,
air ambulances, fire trucks, and
police vehicles.
Local-Area eMBB Broadband Emergency responders
Public Safety connectivity between including law enforcement, the
the CN and the fire service, paramedics, and
tactical cells. medical professionals can set up
a tactical cell where needed for
their operations. This cell can
be connected to a 5G system via
SATCOM, to exchange voice,
data, and video-based services
between public safety users
within a tactical cell or with the
remote coordination center.
The NB-IoT/eMTC support in an NTN is critical for operating IoT services in remote and otherwise
inaccessible areas (https://www.gsma.com/iot/narrow-band-internet-of-things-
nb-iot/).
Some of the industries and operational areas in need of proper NB-IoT coverage include the following:
• Transportation (maritime, trucking, railways, and aviation), distribution, and logistics

• Solar, oil, and gas exploration and production
• Energy and utilities
• Farming and agri-tech
• Environment monitoring, including monitoring of pollution in oceans
• Mining and natural resources
SATCOM networks complement TNs to connect the dots between IoT services today present in dense
urban areas only. The 3GPP work item for NTNs is contained in R-17 on an NTN for NB-IoT and
eMTC. 3GPP’s goal is to reuse as much knowledge as possible from the TN for the NB-IoT/eMTC
design. 5G core connectivity may be considered as part of R-18 or later specifications.
In this section, we have looked at the various use cases that the intersection of SATCOM and 5G
enables for enterprises, government and the military, as well as consumers.
Summary
In this chapter, we have learned about 5G and satellite communication. We looked at use cases that
are enabled by network slicing. After an introduction to satellite communication, we learned why
it is needed in the context of 5G networks. Finally, we learned about its architecture and use cases.
In the upcoming chapter, we will introduce automation, orchestration, and testing in the context of 5G
networks. We will learn that automation and orchestration often go together. We will also learn how
to manage large-scale 5G networks using automatic scale-in and scale-out, when applicable. Finally,
we will learn about automating failure recovery.
17
Automation, Orchestration,
and Testing
Automation and orchestration have been tightly integrated into the development, deployment, and
operations life cycle of modern networks. A 5G network is no exception. 5G network specifications
emphasize a cloud-native framework on which the various network functions are built, which goes hand
in hand with massive-scale network automation. In this chapter, we will delve into details of network
automation, understand how these critical networks are orchestrated, and discover how advanced use
cases such as automatic scale-in and scale-out can be achieved. Automatic failure recovery is another
topic that we will discuss in detail, and we will explore why it is needed.
The integration of various network components in a highly complex network such as a standard 5G
network is a massive time consumer for Mobile Network Operators (MNOs) and Communication
Service Providers (CSPs). We will discuss in detail how various network components can be integrated
and tested.
Operating a massive network is a critical task with no scope for error. Faulty network configuration
updates have been the reason for network downtimes around the world. Such errors can be prevented to
a large extent with accurate network operation automation. Finally, we will talk about the opportunity
to monetize 5G networks and enhance performance with the help of Artificial Intelligence (AI) and
Machine Learning (ML).
We will understand how we can deploy, manage, and operate a 5G network efficiently and smoothly.
In this chapter, we’re going to cover the following main topics:
• Automation infrastructure in 5G
• Introduction to network orchestration
• Auto scale-in and scale-out
• Automatic failure recovery
368 Automation, Orchestration, and Testing
• Integration planning in a multivendor environment

• Testing of integration via automation
• Automating operations and CI/CD
• Monetization via AI and ML
Automation infrastructure in 5G
Network automation is the heart of a stable, well-performing 5G network. With every generation of
mobile networks, their complexity is increasing. 5G networks are built block by block by combining
the network functions with a lot of network gear running a wide variety of heterogeneous technologies.
Figure 17.1 – A typical 5G production network
A typical mid-sized mobile network, as shown in the preceding figure, would comprise thousands of
radio units and thousands of servers and network equipment items that would have been procured from
multiple vendors running different hardware and operating systems. Hence, to be able to build, test,
maintain, observe, and troubleshoot a large network, it is imperative to invest in network automation.
Automation infrastructure in 5G 369
The network automation areas at a high level can be as follows:
• Deployment: A network is composed of various types of network elements; some can be

appliance-based and run software on proprietary hardware. Classic examples of this are network
switches and routers and some 3G/4G telecom equipment. These make up a large percentage
of a network operator’s infrastructure. Also, these are candidates for constant configuration
updates, such as adding or removing VLANs, access control lists, BGP neighbors, and so on,
in the case of switches and routers.
Then, there are virtual functions, which are basically virtualized pieces of network software
that run on commercial off-the-shelf hardware. Virtualization hit like a tidal wave right from
the time of 4G networks. A lot of network elements in 4G networks have been virtualized and
deployed by operators across the world. Virtualization ushered in a lot of savings in terms of
hardware costs that resulted in CapEx savings by decoupling the operating system from the
hardware, but it brought with it software complexity. Now, operators had to keep in mind
additional hypervisors that were used to onboard and manage these virtual functions.
Most operators avoid vendor lock-ins, which would mean different network elements can be
procured from different vendors. This, in turn, means that these different vendors may have
varied preferences for hypervisors, and guest and host operating systems. Hence, the network
becomes diverse and complicated to manage manually. Therefore, there arises the need for a
robust automation framework to manage the life cycle of these virtualized functions.
Cloud-native network functions were designed keeping automation in mind; hence, 5G
networks are the best candidates for automation for life cycle management and deployment.
Most of the network equipment vendors bring forth automated orchestration tools to deploy
and orchestrate the network. There are also some generic orchestrators sold by many vendors,
which solely manage on-premises and cloud deployments. There are also sophisticated tools
for observability, wherein the entire network health is visible in a single pane of glass; this
completely abstracts the complexity of the underlying technology. Hence, automation in 5G
can be thought of as a beautiful veil that hides all the complexity behind it and makes the network
appealing and manageable.
All these network elements, whether physical, virtual, or cloud-native, are candidates for major
and minor software upgrades, which can be a huge exercise given the sheer number of such
network equipment that an operator might have. Hence, finishing such configuration updates
quickly (by fitting them into a small maintenance window) and accurately (by not affecting
any existing setting) is key. Upgrading a mid-sized network (with physical functions varying
from hundreds to thousands) within a maintenance window of a few hours is a mammoth task.
Hence, automation saves the day. Configuration updates and health checks after the application
of changes via automation are getting extremely popular; also, the rollback option is scripted.
Hence, if anything was to go wrong, the script would automatically roll back with minimal or
no human intervention. Similarly, for upgrades, pre- and post-checks can be automated, and
similar rollback options can be added in case the upgrade hits a roadblock.
The following figure depicts broad areas of network automation:
Figure 17.2 – Network automation areas
• Testing: Testing is one of the most essential aspects of network design. This includes the
functional testing of the individual network elements, which could be physical, virtual, or
cloud-native. Testing areas also include the integration validation of all the network elements
(whether they can communicate with each other and are tuned in terms of latency, timers,
and other inter-dependent configurations), and then testing end-to-end call flows of various
types, which would test the overall functioning of the various network functions making the
network. For a network, all the expected use cases that it is designed to support must be tested
in detail. This should also include border and edge cases and failure testing. This would help to
understand the limits of the network and its performance during a network component failure.
Another important aspect of the test is to evaluate load conditions. This would involve testing
with the maximum possible throughput, active subscribers, and call events per second, such
as handovers, connections, disconnects of subscribers, and so on. This would give an idea of
the maximum number of transactions per second that the network can handle.
• Operations: Operating a network is one of the most critical aspects of an MNO. This directly
impacts revenue. A smoothly operating network will give the best customer experience, which
will most certainly drive revenue for the operator in terms of customer retention and new
customer wins. Similarly, an efficiently operating network will save a lot of money allocated to
Operational Expenses (OPEX). If the network operations are fully automated, it will result
in faster maintenance cycles and quicker fault detection, and would, in turn, result in better
customer experience and less cost to the operator in terms of needing a large workforce for
maintenance activities.
Network automation drives OPEX down, and at the same time, reduces the time to market for the
MNO to launch a solution. Older generations of mobile technology did use some initial scripts to
automate parts of their processes but the push toward a one-touch automated network only came
in with 5G networks. It would be excruciating to build a 5G network without automation. Let us
understand, one by one, the reasons why we must build a robust automation framework and the
purposes it should attempt to solve:
• Heterogeneous technologies: 5G networks are built using a mix of cloud-native functions that
have a microservices-based architecture and multiple virtual network functions that are neither
appliance-based nor cloud-native. They may be virtualized using different hypervisors; there
will also be some physical network functions and legacy routers or switches that serve to build
the IP network connectivity backbone. In addition to this, there will be various operations and
maintenance tools, both proprietary and open source. There will be network log-capturing tools
and packet-capture tools, alarming dashboards, troubleshooting tools, reporting tools, and
so on that comprise the network. To add to this, some of these tools and applications can be
hosted on a public cloud and some on a private cloud on-premises. Multiple public or private
cloud providers can also host these varied tools.
Thus, we see that the network can get extremely complex, and therefore, building, operating,
and maintaining a network of such monstrous complexity would need a team of geniuses at
the MNO’s Network Operations Center (NOC) who would be champions in each of these
hundreds of technologies and would work 24/7 to operate the network. However cool such
folks may sound, they are impossible to find. The easier solution is to build a sophisticated
framework for network automation so that the entire build and maintain cycle can be automated
from end to end.
Network automation should cover the stages of planning, building, deploying, operations, and
maintenance, as well as network failure prediction. A network automation engine should be
able to connect to all the network components regardless of the type of the component and be
able to manage its life cycle.
It can be a very taxing task to set up such an infrastructure initially from scratch, but once it is
in place, it pays dividends for a very long time. Thus, to operate such highly complex networks,
a robust automation framework should be built from the very beginning of the build cycle.
• Reduces operational downtime: It is very common for humans to make errors. At the same
time, it is unacceptable for a 5G network running mission-critical services to go down. That
could not only cause heavy revenue and reputation impact for the CSP but also lead to loss of
human life in the case of mission-critical applications. According to a survey by Uptime Institute
(https://journal.uptimeinstitute.com/outages-understanding-the-
human-factor/), 70% of data center outages are due to human error. Hence, automation
can eradicate this almost entirely. You may state that automation frameworks also fail and can
have bugs, which is a fair point, but by having proper checks and failure handling, a lot of these
road bumps can be evened out.
• Reduces network failure downtime: This is a direct consequence of network automation.
Automation of configuration updates and software or firmware upgrades can not only reduce
the chances of human error resulting in network failures but also complete the job much faster
than when done manually. The automated procedures can also have a provision of a dry run that
not only checks the script and commands/actions to be completed beforehand but also helps in
checking the sanity of the environment and collecting statistics to capture the snapshot of the
environment before applying changes. This way, the pre- and post-change KPIs can be compared
to check the health before and after the network update. The automated infrastructure monitors
the KPIs continuously after the update and can also perform a rollback in case of performance
degradation. The following table shows some of the KPIs needed for different use cases in 5G.
5G performance Minimum KPI requirement Category

requirement type
Peak Data Rate Downlink: 20 Gbps eMBB
Uplink: 10 Gbps
Peak Spectral Efficiency Downlink: 30 bits/sec/Hz eMBB
Uplink: 15 bits/sec/Hz
Data Rate Experienced by User Downlink: 100 Mbps eMBB
Uplink: 50 Mbps
Area Traffic Capacity D own lin k: 10 Mbits/s e c/ eMBB
m2 in indoor hotspot (eMBB
test environment)
Latency (User Plane) • 4 ms for eMBB eMBB, URLLC
• 1 ms for URLLC
Latency (User Plane) • 20 ms eMBB, URLLC
(10 ms encouraged)
Connection Density 1 x 106 devices/Km2 mMTC
Average Spectral Efficiency (All the following figures are in eMBB

units of bits/sec/Hz/TRxP)
Indoor hotspot: DL: 9/UL: 6.75
Dense urban: DL: 7.8/UL: 5.4
Rural: DL: 3.3/UL: 1.6
Energy Efficiency • Efficient data transmission eMBB
(loaded case): To be
demonstrated by “average
spectral efficiency”
• Low energy consumption (no
data case): This test case should
support a high sleep ratio/long
sleep duration
Reliability 1 x 10-5 probability of URLLC
transmitting layer-2 PDU of
32 bytes in size within 1 ms
(in channel quality of coverage
edge for urban Macro-URLLC
test environment)
Mobility • Dense urban: Up to 30 km/h eMBB
• Rural: Up to 500 km/h
Mobility Interruption Time 0 ms eMBB, URLLC
Bandwidth (Maximum • At least 100 MHz IMT-2020
Aggregated System)
• Up to 1 GHz for operation in
high-frequency bands (i.e., above
6 GHz)
The preceding KPIs must be met at all times by the mobile operator to be able to cater to the
quality of experience demands of a 5G network.
• Reduces training time and niche skillset dependency: Automation comes to the rescue,
especially in times when there is a new technology or software every year or so. A CSP deploys
numerous types of software and hardware equipment. Having a workforce that has the expertise
to operate all these various types of equipment would not only be hard to find but also very
expensive. Hence, automation comes to the rescue. This helps the MNO to save on intensive
training costs for their operations personnel. Basic training would suffice as most of the heavy
lifting would be done by automated scripts; in many cases, even a service ticket is raised by the
automation environment for a particular software with their respective vendor. The automation
engine also provides all the logs and details for the issue to the service ticket. Hence, it reduces
a lot of boring manual work that an engineer would do to open a service ticket. As every issue is
monitored and logged by an automation framework, it is hard to miss scenarios that are tough
to reproduce. Hence, in a nutshell, the level of expertise needed to operate a diverse network
is reduced with the widespread adoption of automation.
• Reduces operational expenses: This is one of the greatest savings that is incurred as a direct
consequence of a sophisticated network automation framework. Almost every operator in the
world has to invest a significant number of hours in maintaining their network. A network
consisting of hundreds of pieces of network equipment is bound to have some wear and tear
on its gear. Many malfunctioning or broken network equipment parts need to be identified and
replaced at any point in time. This can vary from the entire equipment or server to small parts
of the equipment. This part replacement needs to follow a meticulous procedure, as most of the
equipment would be in a production environment. Hence, careful procedures to divert traffic
and complete the task within a small window of time are important. This method can also be
automated to a large extent. All the steps, from identifying faulty equipment to ordering the
replacement part, can be automated. Scheduling the maintenance work and diverting traffic can
also be automated. Then comes the time of actual part removal, which can be either robotic or
manual. Finally, the last step of checking and traffic convergence can also be automated. Hence,
if most of the steps in the process are automated, it would save precious time and cost in terms
of keeping large teams for this work. As most of these tasks are recurring, it would make a lot
of sense to automate this process. This would help the maintenance team in focusing on more
specialized tasks rather than being engaged in such mundane activities.
Similarly, software upgrades and configuration changes can be automated completely. A cloud-
native approach also provides a provision for canary-based upgrades, where a small portion of
traffic is first diverted to the newly upgraded software. Its stability can be monitored and then, if
found to be acceptable, the entire volume of traffic can be moved to the newly updated software.
Hence, we can see that operations tasks that are repetitive can be completely automated. This
saves not only operational expenses but also time and reduces the chances of mistakes.
• Enhances tracking and SLA conformity: An important aspect of operations teams at a CSP
is to track the open tickets for faulty equipment and software. Over a period of time, this can
aggregate to thousands for even a small-sized network. It becomes next to impossible to manage
the tickets and follow up on each of these manually. Here too, automated tools come to the
rescue. These tools can check the status of each of the tickets in a multivendor environment
and can generate reports highlighting issues and their criticality and the status of each of the
issues. It can also flag when the SLA is not met on any of these issues and send reminders to
the concerned parties. Hence, automation enables the operations team to better track tickets
and follow up on critical ones. Also, sophisticated reports can be generated for the SLA times
for each vendor for their equipment, and these can be used to follow up with each one for
conformity. Thus, automation brings operational efficiency and excellence when it comes to
tracking and SLA conformance.
Introduction to network orchestration 375
• Achieves operational excellence: As we have already discussed in various parts of the book,
an efficient and innovative operations team is one of the key contributors to an MNO’s success.
This particular vertical has tremendous scope for innovation and automation. The better an
operator knows its network, the smoother it will be able to operate it, hence comes the need
for observability. There are many software products available in the marketplace that promise
to provide visibility in a single pane of glass. What this really means is that all the complicated
technology in a network is abstracted and a simple intuitive dashboard is made available. Let’s
understand what this complexity is really about.
There would be thousands of pieces of equipment in the network running a whole range of
software and operating systems. Getting a bird’s-eye view of the network is instrumental for
smooth operation. For example, a dashboard should be able to provide views of the various
personas that the MNO might have, starting from a network engineer up to top management.
All these personas would need different levels of detail. A network engineer may be interested
in a specific critical alarm for a certain type of equipment that they may be assigned to operate,
whereas a higher operations manager might want an aggregated view of all the critical alarms,
regardless of the technology type. Some teams may be more interested in the correlation of
a physical hardware-related alarm to a software KPI-dip alarm. The management team may
be interested in getting an overall view of the network performance, throughput, congestion,
number of subscribers, and network failures (if any). Hence, the point here is that a good
dashboarding practice will enable the MNO to have better visibility of the network so that they
can manage it smoothly and prevent delays in fault detection and correction.
We now see the significance of introducing automation in a network: it is not only essential but
also critical for running a highly available, resilient, mobile network that is maintainable and has an
affordable operating model, which, in turn, would directly reflect customer satisfaction and profitability.
Introduction to network orchestration

This is the aspect that brings out the flexibility provided by a 5G network. The importance of
orchestration cannot be stressed enough. In a network that is trending toward rapid virtualization
and cloudification, a network orchestrator becomes all the more necessary. Network orchestration
from a high level may look like the following figure:
Figure 17.3 – Network orchestration tools

It contains an orchestration engine, which acts as the brain of this system. Orchestration is most
popularly used for the deployment of services, cloud-native functions, and network functions, which
can also be virtualized network functions.
But it is not limited to the deployment operation. A network orchestrator participates in every aspect
of life cycle management. Most network function vendors have their own life cycle management tools.
An orchestrator works to integrate all of them to provide a one-stop shop for all life cycle management
activities. As the network functions can be deployed on any cloud or on-premises solution, it becomes
all the more important to have a simple integrated solution for life cycle management. Imagine a
scenario where an MNO has network functions from multiple independent software vendors deployed
on multiple clouds. Operating, maintaining, and monitoring such a network would be a gruesome
task. Hence, an automated solution such as an orchestrator can manage all the deployments from a
single point of operation.
Similar to monitoring the various clouds and performance of the network function, its logging and
collection of KPIs can be done by one pervasive orchestrator and this can, in turn, be consumed by
AI/ML algorithms to provide cohesive and correlated trend analysis, which can be treated like a closed
loop mechanism to improve network and business intelligence. We will discuss a few unique use cases
of network orchestration and the value it can bring to the operator.
Auto scale-in and scale-out

A 5G network typically has its component network functions deployed over hundreds of servers.
Most of this network is built considering a certain capacity in terms of transactions per second and
throughput, which correlate to the usage of the server resources such as memory, CPU, and storage.
Now, we would need to understand that not all network functions may use all the resources dedicated
to them. For example, on a game night, there would be heavy streaming, and hence, high throughput
demand. This would mean the user plane nodes would be stressed out; however, it is possible that
some control plane network functions are sparingly utilized. Therefore, it is worthwhile to consider
the creation of an entity that could monitor the usage of all the resources and manage it efficiently and
dynamically such that, on load conditions, resources could be freed up from minimally used network
functions and dedicated to resource-intensive network functions. This would help not only save costs
by better utilization of the hardware resources and minimizing hardware oversubscription but also
result in an improvement in KPIs. An orchestrator is one of the best places to seat such intelligence
in the network, as it already has access to life cycle management of all the network functions and can
manage to implement this use case with minimal investment.
Auto scale-in and scale-out have been implemented widely in the IT industry but they have not yet
picked up their pace in the telecom field. There is still some reluctance among operators to put in
live traffic on a freshly orchestrated network function. As there is an elaborate acceptance procedure
that is followed at the MNO’s side before launching any element in production, this is their standard
operating procedure. However, if enough confidence can be built in an automated test framework
that would run these acceptance tests as soon as a new network function has been spawned, then
Introduction to network orchestration 377
this hesitation could be mitigated. Like most things, trust in such elevated-level automation may take
some time, but it is inevitable, and just a matter of some trials to be successful.
We can see a higher rate of adoption in the coming years, where networks will grow and shrink in
terms of usage. Many cloud players already have a pay-per-use model. Cloud providers are strongly
growing their presence in the telecom space and this will further push this case.
Automatic failure recovery

Another classic use case of an intelligent orchestrator is to be able to recover from failure. The failure
can be of various types; it could be a faulty piece of hardware or software, for instance. The orchestrator
should be able to detect the type of issue and then take appropriate corrective action. For example, if
there is an issue with the software, then moving the network function to a different server will be of
no use. Similarly, if the hardware is faulty, then rolling back a software version wouldn’t help.
As an orchestrator has a view of the whole network, it can correlate a fault across the network and
root cause the failure to a large extent and then take appropriate action. As an example, if there is
a sudden KPI dip in a region and, at the same time, there is a critical hardware alarm in the same
region, it could be easily correlated to the timestamp of the issue, and appropriate action (such as
moving the particular element out of rotation from production and diverting the traffic to a healthy
node) can be taken.
There is enough room for flexibility as to what action needs to be taken in each scenario, and the
MNO can customize each action at its own discretion.
Congestion control by configuration management

This is another feature that can be best adopted by an orchestrator with the overall network view.
Congestion is a frequently occurring condition in a mobile network. It is a sudden rush of traffic or
number of connections that causes general delays in the network and dips the KPIs drastically. One
way to address this issue is, as we discussed earlier, by auto-scaling, but it is not always feasible to
find resources in extreme load conditions. Hence, the best way to deal with a situation like that is to
optimize the usage of the existing allocated resources.
In a mobile network, there are a lot of value-added services that run on network functions. While this
might improve some aspects of business, these are not mandatory to run for a network to perform
well. Such services can be identified by the network orchestrator in congested nodes and stopped
temporarily so that their resources can be freed up to alleviate the congestion situation. When the
congestion is removed from the network and it comes back to a normal operating volume, then the
orchestrator starts the services again.
Hence, this is a method to provide temporary relief in a highly congested network.
Implementation of network slicing

This is one of the most important use cases for automation. It entirely depends on the availability
of an orchestrator. As you will have read about and understood the various network slices and their
uses, you will also know that network slicing is nothing but segmenting the network such that certain
resources are made available for certain purposes. The slicing is horizontal across all the components
of the network for a given use case (for example, IoT). A reservation of the resources is made and the
network functions are deployed via an orchestrator. This orchestrator is not only responsible for the
life cycle management of a slice but also for its configuration.
We have gone through a few examples showing where network orchestration is key to building relevant
capabilities; can you think of more examples?
Integration planning in a multivendor environment

By now, we are well aware of the complexity and the sheer number of components that constitute a 5G
network. Integrating these would not be a trivial task. Each network component is a part of the puzzle
that needs to fit in an airtight way for the network to function. Hence, there are multiple aspects to
consider when we go about laying the foundations of the network and planning its integration. The
following points should come in handy while doing so, and it should be noted that all of these steps
should be automated for faster test cycles and integration:
• Unit testing: This is the most basic part of testing and, possibly, the starting point for any
network engineer before they can start the integration of the components. It is important to
check the sanity of each network component before it is ready for integration. This is usually
done with the help of an independent test framework that simulates the external interfaces.
The focus of this testing is to check for the workability of the software.
• Platform testing: This is more relevant in a 5G backdrop, as almost all of the components in 5G
are cloud-based or virtualized. Hence, the cloud platform needs to be vetted for suitability with
the network function software installed to be able to check its compatibility. This also provides
scope for finetuning the configuration of the platform according to the needs of the software
being hosted on it. Also, platform failure scenarios can be tested to observe the outcome and
build a design to minimize its impact.
• Network testing: This is to test the design and stability of the transport network and the
networking used within the platform. Each of the VLANs associated should be tested for
its reachability. Also, external peering, such as a Border Gateway Protocol (BGP) neighbor
relationship, should be checked for correctness. Each of the routers and switches that would
be in the traffic path should be tested for reachability and stability. Additional care should be
taken to address security, and meaningful access control lists and firewalls should be tested.
• Testing end-to-end latency: It is important to understand the latency in any given network
so that further steps can be taken accordingly. For example, if there is an edge user plane and
Integration planning in a multivendor environment 379
a centralized control plane, and the latency between the two should be such that the round-
trip time for a packet is greater than the timer set at the sending and receiving side, then there
would be retransmissions. As the control signaling is based on TCP, it is all the more important
to ensure the network is stable and has acceptable latency. Otherwise, there can be a situation
of a storm of TCP retransmissions clogging up the network.
• Planning of timers’ consistency: Timers are critical during the setting up of the call. Timers
of some kind are present in most network functions, but the ones that are most important
for call setup are present in the Next-Generation NodeB (gNB) and Access and Mobility
Management Function (AMF). These timers determine the time needed for the completion
of procedures such as PDU setup and so on. The expiry of these timers can cause a retry or
complete process failure. It is, therefore, a good idea to plan the timer duration so that all the
timers in the network are consistent with each other. A rule of thumb, although not written in
stone, is to plan the timers such that the value increases as we move from the RAN to the core,
component by component. The timers that are related to the setup of the entire call should
consider the end-to-end latency and round-trip time.
• Functional testing: This is done when the software is already checked for sanity and is ready
for prime time. The individual network function software is installed and integrated with
one or two interfacing network functions, and the rest of the components are simulated. The
reason for integrating a few network functions at a time is to eliminate the chances of too many
unknowns. If you choose to integrate all the network components in one go, then it could be
very hard to debug as the call would touch too many network functions, and a failure reason
or faulty configuration could be hard and time-consuming to detect. Hence, it is a good idea
to start small and grow to cover the whole network. This will result in better debuggability
and a faster testing cycle.
• Identifying use cases: It is a good idea to identify the scenarios and use cases that the network
will need to support once the functional testing is complete and all the network functions have
been integrated. This is the time to test the end-to-end use cases. Some examples are voice calls
and video calls, traffic streaming, and sending MMS messages.
• Running continuous calls to test performance and longevity: Once the network is tested
functionally and integrated, it is time to check its performance and stability. Performance
tests are run with a large call volume to test the sizing and capacity of the network. These tests
are generally run on simulators so that any failure does not impact production traffic. Both
the throughput and maximum transaction per second are tested. Similarly, longevity tests are
run, which involve having a large number of active subscribers and constant data downloads.
The performance of these subscribers is monitored over a long duration ranging from days to
weeks. This is to monitor the degradation of the KPIs over a period of time.
• Integrating CI/CD pipelines: Continuous integration/continuous delivery (CI/CD) pipelines
can be set up after the initial integration. This is slowly becoming the norm in the industry.
Software updates are tested for sanity via automation and also deployed automatically on the
nodes, mostly in a staging environment. This reduces manual intervention and quickens the
development and operations cycle. Once the network is integrated, it is a great idea to start the CI/
CD pipeline to ensure all the various components have the latest code for the best performance.
In this section, we have understood various aspects of network integration, the role automation has
in it, and how to go about doing it in a simple manner. In the next section, we will discuss the areas
of monetization of the network and how AI and ML can help in enhancing revenue.
Monetization via AI and ML

AI and ML are no longer buzzwords. They have very much become a reality in modern networks.
A telecom network is a treasure trove of important information that can be mined and analyzed to
further improve business opportunities and the network itself.
Patterns in user behavior can be mined and analyzed to suggest better mobile usage plans for them.
They can be used to provide meaningful insights to the user. For example, if the user is in a mall, there
could be a recommendation of ongoing discounts or the latest offers in the food courts and restaurants
that the user can benefit from. Such recommendations would improve the quality of experience of
the user and thus also improve their loyalty to the service provider.
Similarly, if a user regularly downloads a large amount of data every day, then there could be a
recommendation for a plan that would allow a large data download at discounted rates. This would
again result in savings on the side of the customer, which would help in keeping their trust and loyalty.
Another example of AI/ML is understanding the network better. The network components generate
a large number of logs and KPIs, and those contain a lot of information. This data can be analyzed to
observe trends. For example, a certain region may see a peak in network traffic at some hours of the
day; this could be analyzed by the AI engine and there could be a suggestion to divert some of this
traffic to another region to share the load and ensure better performance.
Another example of AI-enabled operations is an engine analyzing the data and latency of the whole
network and automatically suggesting what the points of congestion are and what equipment is
specifically causing it. It would be a more accurate suggestion as the engine would crunch data from
hundreds of days to arrive at a conclusion, besides the fact that an automated procedure would not
have an inherent technology bias or reluctance that a human might have when suggesting bad news.
Thus we see that a mobile network, if truly monetized, would add to numerous pathways of generating
revenue for a service provider, rather than the traditional data plan lead revenue. We have already
started seeing the use of secure APIs to expose relevant information to third-party applications that
consume mobile network-generated events and information to translate to business intelligence. In
the upcoming years, as businesses modernize, this will be a very common practice.
Summary 381
Summary
In this chapter, we have seen that automation plays a key role in the smooth operation of a 5G network.
MNOs are adopting this practice widely. We have learned about network orchestration and how it is
helpful in various scenarios, such as dynamically scaling in and out of a network, automatic failure
recovery, congestion control, and implementation of network slicing.
We have also covered aspects of planning integration in a multivendor environment and how to go
about testing the same. Finally, we concluded with the importance of AI/ML in the telecom business
and how it can be used to expand horizons.
This book has walked you through the concepts needed to build, design, operate, and monetize a 5G
network. We have gone over use cases that highlight the capabilities that a 5G infrastructure unleashes
for various applications to consume.
I would like to take this opportunity to congratulate you for completing the book and also thank you
for being persistent till the end. The book aimed at creating a basic foundation that will now help
you develop deeper knowledge independently by referring to specifications mentioned in the Further
reading section.
Further reading
To continue your learning of the topics covered in this book, you can now delve into the low-level
details provided by www.3gpp.org. The specifications dig into the depths of each feature, right up
to the level of implementation.
The specifications provide some insights shared by industry experts that will highlight some of the
exciting opportunities and the future they envision for this technology.
Appendix
Interview on 5G with Rob Tiffany, founder and CEO of

Sustainable Logix
Rob Tiffany is the founder and CEO of Sustainable Logix and the inventor of the Greenhouse
Sustainability Platform, with a mission to help rescue the environment using connected intelligence.
He’s been featured in Wired, Forbes, Fierce Wireless, Inc. Magazine, Dataconomy, Thinkers360, Mobile
World Live, and Techonomy.
Prior to founding Sustainable Logix, Rob served as vice president and head of IoT strategy at Ericsson,
driving 5G connection management for IoT devices globally. As chief technology officer at Hitachi, he
received the Presidential “Product of the Year” award for designing the Lumada Industrial IoT platform,
which landed in Gartner’s “Leaders” Magic Quadrant. Spending most of his career at Microsoft, Rob
was global technology lead for the Azure IoT cloud platform and co-authored its reference architecture.
Prior to Microsoft, he co-founded NetPerceptor, developing one of the industry’s earliest Enterprise
Mobility Management (EMM) platforms for smartphones.
A bestselling author and frequent keynote speaker, Rob serves on multiple boards and is routinely
ranked as one of the top IoT and digital twin experts and influencers in the world by Inc. Magazine,
Onalytica, and others.
Please share one aspect of you that your biography does not cover.
I used to drive Special Ops and Trident submarines in the US Navy, and I still consult with the military
on emerging technologies.
What was the major focus of your company in the last 1–2 years and which companies have you
worked for/interacted with on 5G-related topics?
I spent the last several years as an executive at Ericsson in Sweden, which is one of the handful of
companies that actually makes 5G gear. It’s fair to say I was completely immersed in this next generation
of cellular technology, and I interacted with our mobile network operator customers all over the world
as we rolled 5G out globally.
What’s your perspective on 5G as opposed to the common views on this technology?
I look at 5G from the perspective of having dramatically more capacity in the network than LTE. You can
now have 1 million concurrently connected IoT devices sending and receiving data within a one-kilometer
radius of a cell tower. This will be a game changer for device-dense use cases such as smart cities.
384 Appendix
How is your company contributing to the adoption of 5G in the industry?

My start-up, Sustainable Logix, is already using 5G on farms with appropriate coverage to send telemetry
data from devices and sensors deployed in orchards and fields. I’ve noticed better wireless penetration
through foliage and tree canopies than with other LPWAN options.
Do you think 5G is ready for mainstream or it is a bleeding-edge concept? Why do you think so?
Depending on the mobile network operator you’re using, 5G is mainstream and here today. In the US,
T-Mobile has a substantial lead over the other MNOs with great mid-band speeds, due to their acquisition
of Sprint. Fixed Wireless Access (FWA) is looking to be a monetizable use case for MNOs looking to recoup
the money they spent on spectrum auctions.
Any word of advice or caution for those looking to adopt 5G for their business?
The 5G rollout has been uneven around the world due to the high costs incurred by mobile network
operators to buy new spectrum and the required equipment. This means you can’t count on uniform
availability across the globe or even within a country. It’s important to use cellular modules that support
both LTE and 5G over the next decade.
Interview on 5G with Sunil Dadlani, global CIO and CISO of Atlantic Health System 385
Interview on 5G with Sunil Dadlani, global CIO and CISO

of Atlantic Health System
Sunil Dadlani is a globally recognized technology executive with over 20+ years of extensive experience
in digital transformations and innovation in the public sector, private sector, and not-for-profit
organizations. He has a track record of consistent success in finding white spaces and translating
them into new sources of value.
Sunil Dadlani’s career spans multiple industry verticals across Asia, North America/US, Africa, South
America, and Europe. Serving as a chief information and transformation officer, he is responsible for
driving innovation and digital transformation agenda for global organizations; leveraging technology
innovations to drive organization performance in terms of driving organic growth; entering into new
markets and creating revenue diversification, enterprise cost optimization, and product and service
innovations, driving differential competitive advantage; and building state-of-the-art cybersecurity
functions, application portfolio rationalization, and secure, reliable and scalable enterprise infrastructure.
Sunil leads technology and digital transformation for Atlantic Health System (https://www.
atlantichealth.org/about-us.html) to deliver a real-time, data-driven, patient-centric
integrated healthcare system. Prior to that, Sunil served as cluster chief information officer at the New
York Department of Health, where he was responsible for the largest public sector digital transformation.
Sunil has earned advanced education and executive certifications from Harvard, Wharton, Cornell,
and the University of Phoenix in the fields of global management, information systems, and public
health and healthcare leadership. Sunil was named one of the top 100 digital and technology leaders
and influencers in the United States by various recognized organizations. Sunil has also been a global
technology thought leader and speaker at global forums.
Sunil has been involved with Sankara Eye Foundation, St. Jude Hospital, and the American Society
for the Prevention of Cruelty to Animals (ASPCA).
I like to travel and try street food in every city.
What was the major focus of your company and the healthcare industry in the last 1–2 years?
Telehealth has been the primary way health systems have been leveraging 5G for the past couple of years.
As the COVID-19 pandemic forced health systems to be increasingly remote, mobile networks, particularly
fast and reliable mobile networks, were the backbone of delivering care and keeping patients safe.
As 5G becomes more mainstream along with new cutting-edge technologies such as the metaverse, AR, VR,
block chain, and digital twins, healthcare use cases such as genomics and DNA sequencing, 3D modeling
in education and research, precision and personalized care, and on-demand, high-quality video consults
are becoming more viable, as 5G will serve as a backbone to support these initiatives.
386 Appendix
We have been studying and exploring technology maturity in the following spaces:
• Telecommunications companies such as AT&T and Verizon

• Chipmakers such as Qualcomm, Intel, and Nvidia
• Smartphone companies such as Apple and Samsung
• AR/VR companies such as Microsoft and Meta

5G innovation is about increased speed, throughput, higher compute, data transfers, and the scaling
of what we’re doing today with mobile networks. It’s thinking about how it can open new doors to how
technology can be utilized. For example, with the ultra-low latency speeds that 5G brings, the possibilities
of a tactile internet open up. That could mean a surgeon could remotely perform a procedure and still feel
like they are operating on a patient, or you could have millions of concurrently connected IoT medical
devices, sensors, and wearables sending and receiving data within a one-mile radius of a cell tower. This
is a game changer for remote patient monitoring, care-at-home, or hospital-at-home care delivery models.
New disruptive technologies such as the metaverse, AR, VR, digital twins, edge computing, connected
IoT devices, block chain, and cryptocurrencies will require 5G as a backbone.
5G is generally viewed as the next generation of mobile networks, enabling faster download and upload
speeds, lower latency, and the ability to connect more devices than ever before. Telecommunications
companies such as AT&T and Verizon actively invest in building out 5G networks and work to bring
5G-enabled devices to market.
How are your company and hospital chain contributing to the adoption of 5G in the industry?
We’re keeping our pulse on the evolution of 5G and exploring its application in areas such as virtual care
and remote patient monitoring for patient care; real-time location systems, IoT, and edge computing,
with telemetry data from devices and sensors to track objects and people; and AR for enhanced treatment
information and medical education for clinicians over high-speed, low-latency 5G networks.
5G-enabled devices help us to monitor variables such as bed occupancy level, the movement of physicians,
nurses, and patients around hospitals, and integrated with Electronic Health Record (EHR) systems
monitored by 24*7 hospital command centers.
Not yet, but not because it’s not possible – it just requires a lot of different industry players to come together
and focus on a single opportunity. Mobile network providers, hardware vendors, device manufacturers,
and healthcare systems need to find the right use case that creates enough value for all of them to make
the substantial investment to move forward. It’ll happen eventually, but it will more likely become
mainstream in other industries first before healthcare jumps on the bandwagon.
Interview on 5G with Sunil Dadlani, global CIO and CISO of Atlantic Health System 387
Any word of advice or caution for those looking to adopt 5G for their business, especially
in healthcare?
Some key challenges are as follows:
• Uneven 5G rollout and coverage across different geographies

• High cost for network operators to build telecom infrastructures
• Connection congestions and interferences as 5G operates in a cluster of small cells with low coverage
Increased interconnectivity brought on by 5G networks can be a challenge for organizations currently

struggling with their cybersecurity, on millions of IoT, sensors, wearables, and medical devices.
Understand your use case and the unique business problem that 5G solves, while ensuring that you have
the necessary breadth of technology required to take advantage of it.
388 Appendix
Interview on 5G with Aayush Bhatnagar, senior vice

president of Reliance Jio
Aayush Bhatnagar leads the 5G and 6G technology organization at Jio. As part of this role, he leads
the product initiatives for Jio 5G radios, 5G core, 4G core, automation platforms, as well as early 6G
designs. He is a technology enthusiast and likes designing and developing software hands-on.
There is one fun fact that I would like to share. The idea of building Jio Platforms’ 5G stack was decided
in a car, during a traffic jam.
It’s amazing how decisions taken from the heart can be so intuitively right, as now we are using this
technology in India to power one of the largest 5G SA networks globally.
What was the major focus of your company in the last 1–2 years?
The focus of our company has been to offer the latest 5G technological developments to Indian consumers.
We adopted 5G standalone from day 0, and as we speak, we are using network slicing in production. We
want to be the early adopters of new 5G capabilities and create a unique benchmark.
5G should not be considered a Swiss army knife – a solution to all problems under the sun. My perspective
on 5G is more pragmatic. The core technology offers agility in terms of being cloud-native, hence enabling
faster deployment and change management. However, the business value is delivered through an over-
arching layer that enables new use cases through APIs. The 3GPP standards call this the Common API
Framework (CAPIF) layer. How efficiently we leverage this layer will be the key to 5G monetization
beyond voice and data services. The numerous 5G use cases will also leverage the CAPIF layer for deeper
integration with network capabilities.
Jio is at the forefront of 5G adoption and the massive scaling of 5G services.
As of early 2023, Jio True 5G standalone services have been launched in more than 200 Indian cities.
This number keeps growing every week.
This is beneficial not only to the consumers but also to the industry in general.
5G SA being deployed at this massive scale comes with important operational learning, which Jio 5G
products inculcates.
This learning will help the industry transition much faster to standalone 5G services, by ironing out the
teething troubles elegantly with Jio’s help.
Interview on 5G with Aayush Bhatnagar, senior vice president of Reliance Jio 389
Do you think 5G is ready for the mainstream or it is a bleeding-edge concept? Why do you think so?
At Jio, 5G is no longer bleeding edge. It is mainstream, and soon it will be “business as usual.” The biggest
testament to this is the Jio True 5G network, which is supporting millions of 5G SA users today, using
Jio’s own technology.
Do not let 5G’s expectations eclipse business goals. We need to use 5G as one of the tools to achieve the end
goal. Other sister technologies, such as AR/VR, AI/ML, the cloud, and blockchain, will act as ingredients
for an ultimate solution, which will vary from one industry to another.
390 Appendix
Interview on 5G with ChatGPT

About ChatGPT: (https://chat.openai.com/chat)
I am a language model developed by OpenAI. My purpose is to generate text based on the input provided
to me. I have been trained on a massive corpus of text data and can respond to questions, write stories,
translate languages, summarize articles, and much more. I am not a person or a conscious entity, I am
just AI software that runs on computer servers.
As an AI language model, I do not have personal experiences, emotions, beliefs, or opinions. I can
generate text based on patterns learned from the data I was trained on, but I do not have consciousness
or subjective experiences. Everything I say or write is based purely on my programming and the data I
have been trained on.
How is ChatGPT involved with 5G?
OpenAI’s GPT-3, which is the model that I am based on, has no direct involvement with 5G technology.
5G is a cellular network technology that provides faster internet speeds and more reliable communication
for mobile devices. It is primarily used for wireless communication and does not directly impact the
functioning of language models like me.
However, the increased speed and reliability of 5G networks may lead to greater use of AI-powered
applications and services, including language models like me, which can be used for tasks such as customer
service, language translation, and information retrieval. The improved performance of 5G networks can
make these applications more accessible and responsive, providing a better user experience.
As an AI language model, I don’t have personal opinions, emotions, or beliefs. I can provide neutral and
factual information about 5G technology and its perspectives.
5G technology has generated a lot of discussion and debate in recent years, with a range of perspectives
on its benefits and drawbacks. On one hand, 5G is seen as a major technological advancement that
has the potential to greatly improve connectivity, increase internet speeds, and enable new applications
and services. On the other hand, 5G has also generated concerns about privacy, security, and potential
health effects.
In summary, 5G technology is a complex and multi-faceted issue with both positive and negative
perspectives, and it is important to consider all of the potential benefits and drawbacks when making
decisions about its deployment and use.
Interview on 5G with ChatGPT 391

OpenAI’s work in AI and machine learning could potentially contribute to the adoption of 5G in several
ways. For example, AI-powered applications that run on 5G networks could provide improved performance,
faster response times, and more sophisticated functionality. Additionally, the development of new AI
models and algorithms could help to optimize the use of 5G networks, improving their efficiency and
enabling new use cases.
So, while OpenAI is not directly involved in 5G deployment or adoption, the company’s work in AI and
machine learning could play a role in helping to drive the wider adoption of this technology in the industry.
Who are the major contributors to the adoption of 5G in the industry?
The adoption of 5G technology is a complex and multi-faceted process that involves a range of players
from different industries. Here are some of the major contributors to the adoption of 5G in the industry:
• Telecom companies: Major telecommunications companies, such as AT&T, Verizon, T-Mobile,

and others, are investing heavily in the deployment of 5G networks, building out infrastructure
and providing 5G services to consumers and businesses.
• Network equipment vendors: Companies such as Ericsson, Nokia, and Huawei are supplying the
network equipment and infrastructure that is required to build out 5G networks.
• Mobile device manufacturers: Major smartphone manufacturers, such as Samsung, Apple, and
others, are producing 5G-enabled devices that allow consumers to access 5G networks.
• Government and regulatory agencies: Governments and regulatory agencies play a crucial role
in the deployment of 5G by establishing regulations, standards, and policies that govern the use
and deployment of the technology.
• Industry organizations: Industry organizations, such as the 5G Americas and the 5G Infrastructure
Association, are working to promote the deployment and adoption of 5G technology and to develop
industry standards and best practices.
These are just a few of the major contributors to the adoption of 5G in the industry. The process of deploying
and adopting 5G involves many other players, from technology providers and research organizations to
businesses and end users, who are all working together to help drive the wider adoption of this exciting
new technology.
As an AI language model, I don’t have personal opinions or emotions. I can provide neutral and factual
information about the readiness of 5G technology for the mainstream.
5G is a relatively new technology that is still in the process of being deployed and adopted on a widespread
basis. Currently, 5G networks are available in many major cities around the world and are being rolled
out in additional areas. Some early adopters have already begun to use 5G services, but the technology
is not yet available to all consumers and businesses.
392 Appendix
In terms of its readiness for the mainstream, it can be argued that 5G technology is still in a transition
phase, with many challenges to be addressed before it becomes a fully-matured, mainstream technology.
These challenges include the need for more extensive infrastructure and network coverage, the availability
of 5G-enabled devices, and the development of new applications and services that take advantage of the
capabilities of 5G networks.
That being said, 5G is widely regarded as a promising and exciting new technology that has the potential
to transform many aspects of our lives, from communication and entertainment to healthcare and
transportation. And as more 5G networks are deployed, more devices become available, and new applications
are developed, it is likely that 5G will become increasingly prevalent and widely used in the coming years.
Sure! Here are some things to consider when adopting 5G for your business:
• Availability: Ensure that 5G network coverage is available in the areas where you operate.
• Cost: 5G infrastructure and devices can be more expensive than previous generations of cellular
technology, so plan accordingly.
• Network Capacity: Consider the capacity of your 5G network provider, as 5G networks can become
congested with a large number of users.
• Compatibility: Make sure that your current devices and systems are compatible with 5G technology,
or plan for necessary upgrades.
• Security: 5G technology brings new security concerns, such as potential for network attacks and
privacy violations. Ensure that your network and devices are secure.
• Regulation: Be aware of any local regulations regarding 5G technology and its deployment, as
there may be restrictions in certain regions.
These are some things to keep in mind as you plan for 5G adoption in your business.
Index
Symbols NSA and SA option, economic
comparison 202, 203
2G 6 NSA and SA option, technical
3D MIMO technology 303 comparison 202
3G 3, 6 NSA option 201
3rd Generation Partnership Project SA option 200
(3GPP) 4, 6, 52, 108, 286, 347 5G identifiers 45-48
technical specification (TS) 176 5G (IMT-2020)
4G 3, 6 performance synopsis 5, 6
4G core network Evolved Package 5G New Radio (NR) 3, 189, 228
System (EPS) 186 access and core networks 176, 177
4G (E-UTRAN) initial attach 147-151 architecture 7
4G Evolved Packet Core (EPC) 140 5G NSA
4G Next-Generation eNB (ng-eNB) 200 option 3 call flows 218-225
4G to 5G migration strategy 203-206 5G Operational and Regulatory
5G 3, 6, 24 Requirements group (5GORR) 350
deployment architectures 195, 196 5G QoS 40-42
functions 233 5G QoS Identifier (5QI) values 176
resilience and failure design 252, 253 5G Radio Access Network
5G Americas 348 deployment options 9, 10
URL 348 5G Residential Gateway (5G-RG) 330
5G Automotive Association (5GAA) 303 5G SA network
reference link 303 benefits 228
5G Core (5GC) Network 4, 195, 228 use cases 227, 228
5G deployment options, by 3GPP 5G standardization 6, 7
defining 200 5G to 4G
Packet Switched (PS) handover 186
394 Index
5G Uu 7 American National Standards

5G V2X 313 Institute (ANSI) 350
cloud computing 317, 318 analytics engine 249
platooning 316, 317 antennas
V2X standards 314-316 CSI-RS, mapping to 121
V2X technology 314 Application Functions (AFs) 20, 32, 33
256 Quadrature Amplitude services 71
Modulation (256QAM) 14 Application Policy Infrastructure Controller
Enterprise Module (APIC-EM) 260
A Application Programming
Interfaces (APIs) 286
Absolute Radio-Frequency Channel Architecture Reference for Cooperative
Number (ARFCN) 104 and Intelligent Transportation
Access and Mobility Management Function (ARC-IT) 305-307
(AMF) 9, 184, 289, 291, 379 URL 305
Access Control Lists (ACLs) 336 Artificial Intelligence (AI) 270, 350, 367
Access Gateway Functions (AGFs) 336 for monetization 380
Access Management Function AST SpaceMobile 340
(AMF) 22, 25, 26 Augmented Reality (AR) 4, 176, 280
services 59-61 Authentication, Authorization, and
access network (AN) 19-21, 59 Accounting (AAA) service 335
Access Point (AP) 189 Authentication Server Function
Access Point Name (APN) 47 (AUSF) 26, 32
Access Transfer Control services 67
Function (ATCF) 187 Automated Teller Machines (ATMs) 320
Address Resolution Protocol automation infrastructure 368
(ARP) requests 27 autonomous cars
advanced C-RAN architecture 263 Cruise 302
Advanced Driver-Assistance Halo Car 302
Systems (ADAS) 309, 310 Nuro 302
reference link 309 TuSimple 302
Advanced RAN Coordination 264 Waymo 302
Aircraft Communications Addressing and autonomous vehicles (AVs) 297
Reporting System (ACARS) 311 automation levels 301-303
Alliance for Telecommunications cloud providers role 307, 308
Industry Solutions (ATIS) 350 high-level architecture 304, 305
reference link 350 AV intercommunication 308, 309
Amazon Web Services (AWS) 283 5G 310
Index 395
Advanced Driver-Assistance
Systems (ADAS) 309, 310
C
network slicing, for V2X 311-313 call
tearing down 185
B Call Session Control Functions (CSCFs) 177

Capital Expenditure (CAPEX) 50, 197
bands, 5G spectrum Carrier Aggregation (CA) 103, 264
high-band 264 CAV architecture 305
low-band 264 Cell Specific Reference Signal (CRS) 79, 121
mid-band 264 cellular-Internet of Things (IoT) 5
Bandwidth Parts (BWPs) 102, 115, 131 Cellular Vehicle-to-Everything
defining 132 (C-V2X) technology 290, 304
operations 132, 133 Centralized Unit (CU) 15, 21
parameters 132 channel coding schemes 128
use cases 134-136 data retransmissions 130
Baseband Units (BBUs) 261, 312 transport channel coding chains 128-130
Base Station Hotels (BSHs) 262 Channel Quality Information (CQI) 79
Base Transceiver Station (BTS) 262 Channel State Information Reference
Basic Safety Message (BSM) 300 Signal (CSI-RS) 77, 101, 115
beam determination 100 mapping, to antennas 121
beam forming 14, 15 channel structure 75
with Massive MIMO 14 Charging Function (CHF) 22
beam management 100 circuit switched (CS) 186
beam measurement 100 cloud computing, for V2X 317, 318
beam reporting 100 cloud-native applications 51, 52
beam steering 15 cloud-native infrastructure 51, 52
beam sweeping 96-101 Cloud-RAN (C-RAN) 15, 312
Bearer-Independent Call high-level architecture 15, 16
Control (BICC) 186 Coarse or Dense Wavelength Division
Binary Phase Shift Keying (pi/2-BPSK) 123 Multiplexing (CWDM/DWDM) 261
BlueBird satellite program 340 Code Block Group (CBG)-based
Border Gateway Protocol (BGP) 336, 378 retransmissions 130
Border Gateway Protocol Link- Commercial Mobile Alert
State (BGP-LS) 260 Service (CMAS) 78
Bring Your Own Device Commercial Off-The-Shelf (COTS)
(BYOD) policies 282 hardware 24, 50, 265
British Telecom (BT) 344 Common Public Radio Interface (CPRI) 261
Broadband Network Gateway (BNG) 326 Common Resource Block (CRB) 104
396 Index
Communication Service Providers

(CSPs) 195, 274, 281, 367
D
Component Carriers (CCs) 103 data center design 23, 24, 247
comprehensive C-RAN architecture 264, 265 data center redundancy 253
confidentiality, integrity, and Data Network (DN) 179, 289
availability (CIA) 286 Data Network Name (DNN) 32, 48
Connected and Autonomous data retransmissions 130
Vehicles (CAVs) 297 Code Block Group (CBG)-based
Dedicated Short Range retransmissions 130
Communication (DSRC) 298 HARQ principle 130, 131
V2V technology 298 Dedicated Resource Bearer (DRB) 40
containers 51 Dedicated Short Range Communication
continuous integration/continuous (DSRC) 298, 299
delivery (CI/CD) pipelines 379 bike collision avoidance 300
Control and User Plane Separation CACC 299
(CUPS) 206, 215, 278, 279, 326 protocol diagram 300
Control Channel Elements (CCEs) 116 reference link 298
Control Packet Redirect default QoS flow 180
Interface (CPRi) 330 DELETE method 58
Control Plane (CP) 279, 329 Demodulation Reference Signal
Control Resource Set (CORESET) 99, 116 (DMRS) 98, 117
Cooperative Adaptive Cruise for PDCCH 77
Control (CACC) 299 for PDSCH 77
with DSRC 299 for PUCCH 77
Coordinated Universal Time (UTC) 78 for PUSCH 77
Core Network (CN) 261, 313, 355 Denial of Service (DoS) attacks 285, 336
Create Read Update and Delete (CRUD) 54 Diameter Credit Control Request-
Cross-Domain Solutions (CDS) 286 Initial (CCR-I) message 220
CSI reports 120 Diameter protocol 181
CSI-RS 120 Digital Subscriber Lines (DSL) 326
customer-premise equipment (CPE) 350 directional transmissions 96
Cybersecurity and Infrastructure Discrete Fourier Transform-spread-
Security Agency (CISA) 285 Orthogonal Frequency
Cyclic Prefix (CP) 74, 111 Division Multiplexing
Cyclic Prefix Orthogonal Frequency (DFT-s-OFDM) 74, 81, 123
Division Multiplexing Distributed RAN (D-RAN) 265
(CP-OFDM) 13, 74, 81, 123 Distributed Unit (DU) 21, 272
Cyclic Redundancy Check (CRC) 116 Downlink Control Information
(DCI) 92, 116
Index 397
downlink physical channels, and signals Equipment Identity Repository (EIR) 239
CSI reports 120 ETSI MANO NFV architecture 50
CSI-RS 120 European Space Agency (ESA) 351
PDCCH 116 European Telecommunications
PDSCH 117 Standards Institute (ETSI) 50
PDSCH eMBB 119 European Union’s (EU’s) Horizon
PTRS 122 2020 program 351
TRS 121, 122 E-UTRA-NR Dual Connectivity
URLLC multiplexing 119 (EN-DC) 210
downlink PIs 119 Evolved NodeBs (eNBs) 10, 312
dual connectivity 210 Evolved Packet Core (EPC) 7, 195, 210
Dual-Connectivity with New Evolved Packet System (EPS) 61
Radio (DCNR) flag 219 eVTOLs 303
duplexing scheme 90, 91 extended reality (XR) 176, 285
E F
Earthquake and Tsunami Warning Far EasTone Telecommunications (FET) 281
System (ETWS) 78 far-edge 23
Electric Vehicles (EVs) 316 Fast Fourier Transform (FFT) 81
Element Manager (EM) 50 Federal Communications
end-to-end (E2E) network 289 Commission (FCC) 340
end-to-end network slicing 279 Fixed-Mobile Convergence
enhanced Common Public Radio Alliance (FMCA) 325
Interface (eCPRI) 272 Fixed Mobile Convergence (FMC) 319
Enhanced Machine Type architecture 329-331
Communication (eMTC) 347 Broadband Forum 325, 326
Enhanced Mobile Broadband Broadband Network Gateway
(eMBB) 4, 115, 196, 287 (BNG) 326-329
Enhanced Voice Services (EVS) 176 challenges 320
Environmental, Social, and Fixed-Mobile Convergence
Governance (ESG) 265 Alliance (FMCA) 325
ePCO (extended Protocol IP Multimedia Subsystem (IMS) 322
Configuration Options) 152 Real-Time Transport Protocol (RTP) 322
EPC to 5CG evolution 206 Session Initiation Protocol (SIP) 321
comparison 206, 207 Unlicensed Mobile Access (UMA) 323, 324
EPS fallback 188 use cases 320
Equipment Identity Register (EIR) 26 Fixed Wireless Access (FWA) 320
398 Index
Fixed-Wireless Access Gateway (FWAG) 327 Global Wireless Access (GWA) 320
flexible configuration 91 gNodeB (gNB) 7, 8, 20, 177, 291
FMC security 335 Google Cloud Platform (GCP) 283
application/service layer 336 gross domestic product (GDP) 348
considerations 332 Group-Common PDCCH 117
IP transport layer security 336 Guaranteed Bit Rate (GBR) 182
policy and control layers 336 Guaranteed Flow Bit Rate (GFBR) 184
SIP security 332-334
UMA security 334, 335
four-step random access approach 99, 100
H
Frequency Division Duplex (FDD) 90, 264 Health Insurance Portability and
Frequency Range 1 (FR1) 96 Accountability Act (HIPPA) 331
Frequency Range 2 (FR2) 95 High Definition (HD) mapping 316
frequency range (FR) groups 356 Home Subscriber Server (HSS) 179, 219
fronthaul network 261 Hybrid Automatic Repeat Request
Full Self-Driving (FSD) 302 (HARQ) 120, 130, 131
functional testing 379 hybrid cloud
using 272
G
General Motors (GM) 298
I
Generic Public Subscription Immersive Voice and Audio
Identifier (GPSI) 66 Services (IVAS) 176
Geostationary Earth Orbit initial access procedure 96, 97
(GEO) satellites 352 integration planning
Geostationary Equatorial Orbit in multivendor environment 378, 379
(GEO) satellites 340 Intelligent Transportation
Geosynchronous Equatorial Orbiting Systems (ITS) 305
(GEO) satellite 345 Inter-American Telecommunication
characteristics 353 Commission (CITEL) 350
GET method 58 International Mobile Subscriber
Globally Unique AMF ID (GUAMI) 47 Identity (IMSI) 45
Globally Unique Temporary International Mobile Telecommunications
Identifiers (GUTIs) 46 (IMT) 3, 356
Global Navigation Satellite International Mobile Telecommunications
System (GNSS) 345 (IMT) 2020 81
reference link 345 International Telecommunication
Global Positioning System (GPS) 344, 345 Union (ITU) 348, 349
reference link 348
Index 399
International Telecommunication Union Lightweight Directory Access

- Radiocommunication (ITU-R) 3 Protocol (LDAP) 179
Internet Engineering Task Force (IETF) 321 Link Adaptation (LA) 77
Internet of Things (IoT) 320 logical channels 75
Internet Protocol Television (IPTV) 320 long PUCCH 127, 128
Inter Radio Access Technology (IRAT) 78 Long-Term Evolution (LTE) 95, 115
Interrogating CSCF (I-CSFC) 178 versus NR 79, 80
inter-satellite link (ISL) 357 Long-Term Evolution (LTE) evolved
Inter Symbol Interference (ISI) 81 NodeB (eNB) 210
Inter-System Handover 188 Low-Density Parity Check (LDPC) code 128
interworking 185, 186, 231 Low Earth Orbit (LEO)
with legacy voice networks 186 satellites 342, 345, 352
Intrusion Detection Systems/Intrusion Low-Noise Block Downconverter (LNB) 350
Prevention Systems (IDSs/IPSs) 336 Lynk
IP backhaul 232 URL 340
IP core design 248
IP Multimedia Gateway (IM MGW) 186
IP Multimedia Subsystem
M
(IMS) 151, 175, 177, 178, 286, 322 Machine Learning (ML) 270, 350, 367
5G PDU session establishment 151-163 for monetization 380
elements 178 macro network 229
designing 247-249
K maintenance framework 249

Management and Orchestration
Key Performance Indicators (MANO) framework 50
(KPIs) 253, 330, 372 Management Interface (Mi) 329
massive Internet of Things (MIoT) 347
L massive Machine Type Communications

(mMTC) 4, 5, 128, 196, 287
L-Band 356 Massive MIMO 14
legacy RAN deployment Master Cell Group (MCG) 212
example 266, 267 Master Information Block
legacy voice networks (MIB) 78, 104, 108
interworking with 186 master RAN node 11
licensed Radio Frequency (RF) spectrum 13 Maximum Segment Size (MSS) 356
life cycle management (LCM) 284 Medium Access Control (MAC) 21, 75, 270
Light Detection and Ranging (LIDAR) 302 Medium Earth Orbit (MEO)
satellites 340, 352
400 Index
Message Digest (MD5) 333

metaverse 285
N
Microsoft Azure 283 N3-Interworking Function (N3-IWF) 26, 32
millimeter Wave (mmWave) 82, 95, 261 Narrow Band - Internet of Things
mini-slot 87 (NB-IoT) 347, 365
mission-critical services (MCS) 349 National Security Agency (NSA) 285
mixed reality (MR) 176 near-real-time RAN Intelligent
Mobile Country Code (MCC) 47 Controller (Near-RT RIC) 270
Mobile Network Code (MNC) 47 Network Access Identifier (NAI) 47
Mobile Network Operators (MNOs) 195, 367 network automation 368
Mobile Subscriber Identification deployment automation 369
Number (MSIN) 47 operations automation 371
Mobile Switching Center - testing operation 370
Server (MSC-S) 187 Network Data Analytics Function
Mobility Management Entity (NWDAF) 30, 35
(MME) 50, 187, 219 supported use cases 36
Modulation and Coding Scheme (MCS) 122 network, designing
monitoring framework 249 considerations 229-233
Multi-Access Edge Computing (MEC) 308 Network Exposure Function (NEF) 29, 30
Multi-access Edge Computing services 69, 70
(MEC) Cloud Radio Access Network Functional Virtualization
Network (C-RAN) 261-263 (NFV) 257-259
multi-beaming scenario 101 advantages 258
Multi-Layer Security (MLS) 286 Network Function Repository
Multimedia Broadcast Single Frequency Function (NRF) 289
Network (MBSFN) 88 Network Functions (NFs) 19, 53, 230
Multiple-Input Multiple-Output Network Functions Virtualization
(MIMO) 74, 201 Infrastructure (NFVI) 284
antennas 74 Network Function Virtualization (NFV) 279
multiplexing numerologies network operations center (NOC) 371
use cases 85 network orchestration 375
Multi-Radio Access Technology Dual automatic failure recovery 377
Connectivity (MR-DC) 198 auto scale-in and scale-out 376, 377
Multi-User Multiple Input Multiple congestion control by configuration
Output (MU-MIMO) 124 management 377
multivendor environment tools 375, 376
integration planning 378, 379 network performance analysis 253-255
Network Registration Function (NRF) 138
Index 401
Network Repository Function (NRF) 30, 31 network testing 378

network slice 277 New Radio (NR) 20, 95, 115, 197
Network Slice Instance (NSI) 291 cell definition 78
Network Slice Selection Assistance cell measurement signals 79
Information (NSSAI) 34 channel structure 75
Network Slice Selection Function downlink reference and
(NSSF) 26, 34, 35, 289, 291 synchronization signals 76, 77
services 71, 72 physical layer 74
Network Slice Specific Authentication and resource grid 88, 89
Authorization Function (NSSAAF) 37 spectral efficiency 75
network slicing 34, 231, 277-282 ultra-lean design 79
3GPP architecture 289 uplink reference and
architecture and design 286 synchronization signals 77
architecture and flow diagram 289-291 versus LTE 79, 80
benefits 278 Next-Generation eNBs (ng-eNBs) 10, 188
challenges 283 Next Generation NodeBs (gNBs) 196, 379
challenges, overcoming 283-285 Next-Generation Radio Access
high-level architecture view 288 Network (NG-RAN) 3, 26
implementing 378 architecture 7, 8
security considerations 285 tracking areas 8, 9
use cases 292-295 NF redundancy 253
working 287 NFV Infrastructure (NFVI) 258
network slicing, for V2X 311 NFV Management and Orchestration
high-bandwidth applications 311 (MANO) 258
high-reliability applications 311 non-3GPP access 331
low-latency applications 311 Non-3GPP Interworking
network slicing of Core Network Function (N3IWF) 189
(CN), for V2X Non Access Stratum (NAS) 59
application servers 313 Non-Geostationary Orbit (NGSO)
eMBMS 313 characteristics 353
Mobility Management Entity (MME) 313 non-public (private) network
network slicing of RAN, in V2X designing 249-252
communication mode and non-real-time RAN Intelligent
primitive selection 312 Controller (Non-RT RIC) 270
numerology 313 Non-Standalone (NSA) networks
Radio Access Network (RAN) selection 312 195, 209, 210, 213
Radio Access Technology architecture 197, 198
(RAT) selection 312 advantages 225
radio resource allocation 313
402 Index
dual connectivity 198 Open RAN (O-RAN) 265, 266

option 3a aspects 211 architecture, core principles 271
option 3a, features 211 architecture, elements 270
option 3, features 211 examples 267-269
options 213, 214 infrastructure, managing 269
shortcomings 225 network functionality 271
types 210-213 operational expenses (OPEX) 151, 371
Non-Standalone (NSA) operation 6 Optical Network Termination (ONT) 327
Non-Terrestrial Network (NTN) Option 3 NSA network
systems 341, 347 architecture 214-216
Northbound Interface (NBI) 261 Oracle Cloud Infrastructure (OCI) 273, 283
NR and NG-RAN, features O-RAN Central Unit – Control
beam forming 14, 15 Plane (O-CU-CP) 270
beam steering 15 O-RAN Central Unit (O-CU) 270
Cloud RAN 15, 16 O-RAN Central Unit – User
dual connectivity 11, 12 Plane (O-CU-UP) 270
increased spectrum 13 O-RAN Distributed Unit (O-DU) 270
radio enhancements 13, 14 O-RAN Radio Unit (O-RU) 270
small cells 12 Orthogonal Frequency-Division
NR frame structure 86-88 Multiple Access (OFDMA) 74
mini-slot, use cases 88 Orthogonal Frequency Division
NRF services 70 Multiplexing (OFDM) 74, 81, 116
NR numerology 81, 82 Over the Air (OTA) 302
cell size 83
examples 85, 86
illustration 82, 83
P
latency 84 packet core design 248
multiplexing numerologies 85 packet core network 20, 22
NR waveforms 80, 81 Packet Data Convergence Protocol
NTN- and TN-integrated communication (PDCP) 21, 211, 270
security considerations 359, 360 Packet Flow Descriptors (PFDs) 28
NTN network architecture 356-358 Packet Network Data Gateway (PGW) 215
numerology 81 Packet Switched (PS) handover
5G to 4G 186
O PATCH method 58
Payment Card Industry (PCI) 331
O03 MEO satellite system 340 PDN Gateway Control (PGW-c) 62
OFDM waveform 81 PDN Gateway (PGW) 50
Index 403
PDSCH eMBB 119 platooning 316, 317

PDU session establishment 242-246 Platoon Leader (PL) 316
PDU Session Modification procedure 184 Platoon Members (PMs) 316
PDU sessions 38, 39 Policy and Charging Resource
Peak to Average Power Ratio (PAPR) 81, 123 Function (PCRF) 220
PGW-C+SMF 146 Policy Control Function
Phase Tracking Reference Signal (PCF) 22, 28, 29, 53, 179, 240, 289, 291
(PTRS) 76, 77, 115, 122 services 67-69
Physical Broadcast Channel policy rule 184
(PBCH) 78, 97, 108, 115 POST method 58
resource element mapping 109, 110 Post-Quantum Cryptography (PQC) 286
Physical Cell ID (PCI) 104 Power Amplifier (PA) 79
physical channels 75 power distribution unit (PDU) 177
Physical Downlink Control Channel power source redundancy 253
(PDCCH) 115, 116 Precoding Matrix Indicators (PMIs) 120
Control Resource Set (CORESET) 116 Preemption Indicator (PI) 117
Group-Common PDCCH 117 Primary Synchronization Signal
Physical Downlink Shared Channel (PSS) 76, 101, 107, 108, 115
(PDSCH) 99, 115, 117 producer-consumer model 52
Demodulation Reference Signal Protocol Data Unit (PDU) session 137
(DMRS) 117, 118 establishment, in 5G 138-146
processing chain 118 establishment, with 4G/N26/IWF 146, 147
Physical (PHY) layer 21 Protocol Data Units (PDUs) 27
Physical Random Access Channel Provisional Response Acknowledgement
(PRACH) 77, 98, 110, 115 (PRACK) 182
and SCS 112, 113 Proxy CSCF (P-CSCF) 178
long sequence PRACH formats 110 public clouds providers 263
long sequence PRACH structure 111 Public Switched Telephone
short sequence PRACH formats 111 Networks (PSTN) 185
short sequence PRACH structure 112 PUSCH Demodulation Reference
Physical Resource Block (PRB) 88, 102, 116 Signal (DMRS) 123
Physical Uplink Control Channel PUSCH processing chain 124
(PUCCH) 123-126 PUT method 58
long PUCCH 127, 128
short PUCCH 126, 127
Physical Uplink Shared Channel
Q
(PUSCH) 77, 123 Quadrature Amplitude
platform testing 378 Modulation (QAM) 117
404 Index
Quadrature Phase Shift Keying (QPSK) 116 Resource Elements (REs) 88, 118
Quality of Service RESTful interfaces, 5G system 58
(QoS) 20, 138, 176, 279, 330, 336, 361 AF services 71
flows, establishing 183, 184 AMF services 59-61
Quasi-Colocation (QCL) 121 AUSF services 67
NEF services 69, 70
R NRF services 70
NSSF services 71, 72
rack redundancy 253 PCF services 68, 69
Radio Access Network SMF services 61-63
(RAN) 175, 195, 286, 291, 355 UDM services 63-66
radio access planning 248 UDR services 66, 67
Radio Access Technology (RAT) 261 REST, in 5G NFs
Radio Access Technology (RAT) fallback 188 cacheable 55, 56
network architecture 189 layered system 56
Radio Equipment Control (REC) 261 stateless 56
Radio Frequency (RF) 270 uniform interface 57
Radio Link Control (RLC) 21, 75, 270 Return On Investment (ROI) 283, 349
Radio Network Temporary Road Side Unit (RSU) 312
Identifier (RNTI) 116 roaming 231
Radio Resource Control robust automation framework
(RRC) 21, 93, 116, 270 benefits 371-375
Radio Unit (RU) 21, 22, 272 router and switch redundancy 253
RAN-as-a-Service (RANaaS) model 263 RRC Release with Redirection 188
random access preamble 110, 111
Real-time Transport Protocol
(RTP) 176, 185
S
Receivers (Rx) 198 SA network architecture 199
Remaining Minimum System satellite backhaul 351
Information (RMSI) 99, 118 satellite bent pipe architecture 354
Remote Radio Heads (RRHs) 22, 261 satellite communications
Remote Units (RUs) 21 (SATCOM) 339-344
Representational State Transfer (REST) 54 5G use cases 360-365
benefits 54 challenges 350
Representational State Transfer considerations 346
(REST) model 52 with 5G 351
Requests for Comments (RFCs) 321 satellite gateway (GW) 360
Resource Element Groups (REGs) 116 satellite regenerative architecture 355
Index 405
satellite transmission technology 355 Session Management (SM) messages 26

S-Band 356 Short Messaging Service Function
scaling 248 (SMSF) 26, 34
Scheduling Request (SR) 123 short PUCCH 126, 127
SCP 36, 37 SIB messages 78
SDP Answer 181 Signaling System No 7 (SS7) 186
Secondary Cell Group (SCG) 212 Signal to Interference and Noise
secondary RAN node 11 Ratio (SINR) 130
Secondary Synchronization Signal Simple Network Management
(SSS) 76, 101, 107, 108, 115 Protocol (SNMP) 260
Secure Access Service Edge (SASE) 336 Single Radio Voice Call Continuity
Secure File Transfer Protocol (SFTP) 336 (SRVCC) 187
Secure Multipurpose Internet Mail SIP signaling exchange 181-183
Extensions (S/MIME) 333 for call tear down 184
Secure Shell (SSH) 336 Slot Format Indication (SFI) 91-93
Security Edge Protection Proxy (SEPP) 35 Slot Format Indicator (SFI) 117
server redundancy 253 Société Européenne des Satellites (SES) 340
Service-Based Architecture (SBA) 52, 206 Software-Defined Networking
Service Centralization and (SDN) 259, 260, 279
Continuity (SCC) 179 high-level architecture 260
Service Communication Proxy (SCP) 30 Software-Defined Networks (SDNs) 310
service consumer 55 Software-Defined Wide Area
Service Data Adaptation Network (SD-WAN) 260
Protocol (SDAP) 270 Sounding Reference Signal
Service Delivery Adaptation (SRS) 77, 101, 123
Protocol (SDAP) 21 Southbound Interface (SBI) 261
Service-Level Agreements (SLAs) 281 Spectrum Access System (SAS) provider 250
Service Management & split bearer 212
Orchestrator (SMO) 270 SS block 101
service producer 55 composition 103, 104
Serving CSFC (S-CSCF) 178 for LTE-NR coexistence 105
Serving Gateway (SGW) 50, 210 mapping locations 104, 105
Session and Service Continuity (SSC) 44 set composition 106
modes 45 time index indication 106
Session Description Protocol (SDP) 181 SS burst set definition 102, 103
Session Initiation Protocol (SIP) 176 Standalone (SA) networks 195, 213
Session Management Function Standards Development Organizations
(SMF) 22, 27, 53, 62, 289, 291 (SDOs) 325, 347
services 61-63
406 Index
State Control Interface (Sci) 329 transport channel coding chains 128-130
Steering of Roaming information 141 transport channels 75
Stream Control Transmission Transport Layer Security (TLS) 332
Protocol (SCTP) 322 transport network 20, 22
Subcarrier Spacings (SCs) 74, 100 Trusted Network Gateway
Subscriber Identity Module (SIM) 334 Function (TNGF) 359
Subscription Concealed Identifier (SUCI) 32 trusted non-3GPP access
Subscription Identifier De-concealing via satellite 359
Function (SIDF) 47 typical 5G network 19
Subscription Permanent typical 5G production network 368
Identifier (SUPI) 32
Synchronization Signal block
(SSB - SS block) 78, 97, 117
U
Synchronization Signal (SS) 76 UE registration process 234-242
System Frame Number (SFN) 109 Ultra Reliable Low Latency Communications
System Information Block 1 (SIB1) 78 (URLLC) 4, 5, 23, 128,
System Information Blocks (SIB) 99 197, 225, 227, 287
System Information (SI) 78, 122 Unified Data Management (UDM) 32, 178
services 63-66
T Unified Data Manager (UDM) 22

Unified Data Repository (UDR) 28, 33, 34
telecom cloud services 66, 67
emergence 273, 274 United Nations (UN) 340
telecom infrastructure unit testing 378
evolution 49-51 Universal Resource Identifier (URI) 58
Telephony Application Server (TAS) 178 Universal SIM (USIM) 334
Terrestrial Network (TN) 358 Unmanned Aerial Systems (UAS) 357
test framework design 248 Unmanned Aerial Vehicles (UAVs) 356
Time Division Duplex (TDD) 90, 97, 264 Uplink Control Information (UCI) 123
Time-Division Multiplexing (TDM) 186 uplink physical channels, and signals 123
TM Forum (TeleManagement Forum) 349 PUCCH 125, 126
reference link 349 PUSCH 123
Total Cost of Ownership (TCO) 258 URLLC multiplexing 119
Tracking Reference Signal User Datagram Protocol (UDP) 322
(TRS) 77, 115, 121, 122 User Equipment (UE) 7, 20, 137, 188,
Transmission Control Protocol (TCP) 322 210, 261, 277, 286, 304, 352
Transmission Time Interval (TTI) 86 User Plane Function (UPF) 9, 20,
Transmitters (Tx) 198 27, 28, 177, 289, 291
User Plane (UP) 279, 329
Index 407
V VoNR initial procedures 178

3rd party registration 180, 181
Vehicle to Everything (V2X) IMS connectivity establishment 179, 180
communication 287, 297 IMS registration 180
types 309 subscriber provisioning 179
use cases 316
Vehicle-to-Grid (V2G) 316
Vehicle-to-Vehicle (V2V) system 225, 297
W
Vehicular Ad Hoc Networks (VANETs) 315 Wi-Fi 231
virtual Broadband Network Wi-Fi attach 168-173
Gateway (vBNG) 336 Wi-Fi calling 179, 189, 190
Virtual Infrastructure Manager (VIM) 50 Wireless Access in Vehicular
Virtualized Network Function (VNF) 313 Environments (WAVE) 314
virtual machines (VMs) 289 standards 314
Virtual Network Functions Wireline-Wireless Convergence (WWC) 325
(VNFs) 50, 258, 328
Virtual-RAN (vRAN) 262
virtual reality (VR) 176
Z
voice call continuity 185, 186 Zero Trust Architecture (ZTA) 281, 286
Voice Over Long-Term Evolution
(VoLTE) 175, 323
Voice Over NR (VoNR) 175
5G system service requirements 176
call flow 163-168
concepts 175
drivers 175
IMS network deployments growth 175
ultra-high-definition audio 176
Voice over Wi-Fi (VoWi-Fi) 189
VoNR call procedures
high-level call procedure activities 181
QoS flow establishment 183, 184
QoS flow tear down 184, 185
SIP signaling exchange 181-183
VoNR high-level architecture 176
5G NR access and core networks 176, 177
IP multimedia subsystem 177, 178
Packtpub.com
Subscribe to our online digital library for full access to over 7,000 books and videos, as well as
industry leading tools to help you plan your personal development and advance your career. For more
information, please visit our website.
Why subscribe?
• Spend less time learning and more time coding with practical eBooks and Videos from over
4,000 industry professionals
• Improve your learning with Skill Plans built especially for you
• Get a free eBook or video every month
• Fully searchable for easy access to vital information
• Copy and paste, print, and bookmark content
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files
available? You can upgrade to the eBook version at Packtpub.com and as a print book customer, you
are entitled to a discount on the eBook copy. Get in touch with us at customercare@packtpub.
com for more details.
At www.Packtpub.com, you can also read a collection of free technical articles, sign up for a range
of free newsletters, and receive exclusive discounts and offers on Packt books and eBooks.
Other Books You May Enjoy
If you enjoyed this book, you may be interested in these other books by Packt:
Learn Wireshark - Second Edition

Lisa Bock
ISBN: 9781803231679
• Master network analysis and troubleshoot anomalies with Wireshark

• Discover the importance of baselining network traffic
• Correlate the OSI model with frame formation in Wireshark
• Narrow in on specific traffic by using display and capture filters
• Conduct deep packet analysis of common protocols: IP, TCP, and ARP
• Understand the role and purpose of ICMP, DNS, HTTP, and DHCP
• Create a custom configuration profile and personalize the interface
• Create I/O and stream graphs to better visualize traffic
Other Books You May Enjoy 411
Building Industrial Digital Twins

Shyam Varan Nath, Pieter van Schalkwyk
ISBN: 9781839219078
• Identify key criteria for the applicability of digital twins in your organization
• Explore the RACI matrix and rapid experimentation for choosing the right tech stack for your
digital twin system
• Evaluate public cloud, industrial IoT, and enterprise platforms to set up your prototype
• Develop a digital twin prototype and validate it using a unit test, integration test, and functional test
• Perform an RoI analysis of your digital twin to determine its economic viability for the business
• Discover techniques to improve your digital twin for future enhancements
412
Packt is searching for authors like you

If you’re interested in becoming an author for Packt, please visit authors.packtpub.com and
apply today. We have worked with thousands of developers and tech professionals, just like you, to
help them share their insight with the global tech community. You can make a general application,
apply for a specific hot topic that we are recruiting an author for, or submit your own idea.
Share Your Thoughts

Now you’ve finished Mastering 5G Network Design, Implementation, and Operation, we’d love to
hear your thoughts! If you purchased the book from Amazon, please click here to go straight to the
Amazon review page for this book and share your feedback or leave a review on the site that you
purchased it from.
Your review is important to us and the tech community and will help us make sure we’re delivering
excellent quality content.
413
Download a free PDF copy of this book

Thanks for purchasing this book!
Do you like to read on the go but are unable to carry your print books everywhere? Is your eBook
purchase not compatible with the device of your choice?
Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.
Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical
books directly into your application.
The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free content
in your inbox daily
Follow these simple steps to get the benefits:
1. Scan the QR code or visit the link below
https://packt.link/free-ebook/9781838980108
2. Submit your proof of purchase

3. That’s it! We’ll send your free PDF and other benefits to your email directly

Mastering 5G Network Design, Implementation, and Operations

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Mastering 5G Network Design, Implementation, and Operations

Uploaded by

Copyright:

Available Formats

Mastering 5G Network Design,

Implementation, and Operations

A comprehensive guide to understanding, designing,

Shyam Varan Nath

Associate Group Product Manager: Rahul Nair

First published: June 2023

Production reference: 1260523

Published by Packt Publishing Ltd.

Shyam Varan Nath

About the authors

Founder and CEO of Sustainable Logix, @RobTiffany

- Sunil Dadlani, CIO and CISO,

Atlantic Health System

- Prakash Sangam, founder and principal,

Tantra Analyst, @MyTechMusings

- Dez Blanchfield CEO,

Sociaall Inc., @dez_blanchfield

- Mark Szewczul, MSEE, CISSP, product/cybersecurity strategist,

The NWDAF 35 5G QoS 40

VoNR high-level architecture 176 Interworking and voice call continuity185

VoNR call procedures 181

Part 2: 5G Network Design, Deployment Models,

Network slicing architecture and Use cases of network slicing 292

AV intercommunication 308 Summary318

Why do we need satellite Use cases of 5G and satellite

Other Books You May Enjoy 410

Who this book is for

What this book covers

Download the color images

Tips or important notes

Share Your Thoughts

1. Scan the QR code or visit the link below

2. Submit your proof of purchase

• 5G concepts and drivers

5G concepts and drivers

Figure 1.1 – ITU-R and the IMT technologies

Enhanced mobile broadband

Figure 1.2 – Evolution to ultra broadband

Ultra-reliable and low-latency communications

Figure 1.3 – URLLC

Massive machine-type communications

5G (IMT-2020) performance synopsis

Requirement Unit IMT Advanced IMT-2020

Figure 1.4 – 5G system high-level architecture

5G systems largely comprise the 5G NR, NG-RAN, and, finally, 5GC.

Figure 1.5 – NG-RAN architecture

Figure 1.6 – Tracking areas

5G RAN deployment options

Figure 1.7 – 5G Radio Access Network deployment options

NR and NG-RAN features

Figure 1.8 – Dual connectivity

Figure 1.9 – Macro coverage with small cells

Figure 1.10 – Radio enhancements

Figure 1.11 – Beam forming with Massive MIMO

Figure 1.12 – Beam steering with Massive MIMO

Figure 1.13 – Cloud RAN high-level architecture

Figure 2.1 – 5G network overview

Let’s understand some of these components:

The access network

The packet core network

The transport network

Data center design

The NWDAF 35 5G QoS 40

VoNR high-level architecture 176 Interworking and voice call continuity185

VoNR call procedures 181

Network slicing architecture and Use cases of network slicing 292

AV intercommunication 308 Summary318

Other Books You May Enjoy 410