-
Notifications
You must be signed in to change notification settings - Fork 0
/
arch.html
604 lines (491 loc) · 30.4 KB
/
arch.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
<!DOCTYPE html>
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Chapter 3: Basic Architecture — 5G Mobile Networks: A Systems Approach Version 0.1 documentation</title>
<link rel="shortcut icon" href="static/bridge.ico"/>
<script type="text/javascript" src="static/js/modernizr.min.js"></script>
<script type="text/javascript" id="documentation_options" data-url_root="./" src="static/documentation_options.js"></script>
<script type="text/javascript" src="static/jquery.js"></script>
<script type="text/javascript" src="static/underscore.js"></script>
<script type="text/javascript" src="static/doctools.js"></script>
<script type="text/javascript" src="static/language_data.js"></script>
<script async="async" type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.5/latest.js?config=TeX-AMS-MML_HTMLorMML"></script>
<script type="text/javascript" src="static/js/theme.js"></script>
<link rel="stylesheet" href="static/css/theme.css" type="text/css" />
<link rel="stylesheet" href="static/pygments.css" type="text/css" />
<link rel="stylesheet" href="static/css/rtd_theme_mods.css" type="text/css" />
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="Chapter 4: RAN Internals" href="ran.html" />
<link rel="prev" title="Chapter 2: Radio Transmission" href="primer.html" />
</head>
<body class="wy-body-for-nav">
<div class="wy-grid-for-nav">
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
<div class="wy-side-scroll">
<div class="wy-side-nav-search" >
<a href="index.html" class="icon icon-home"> 5G Mobile Networks: A Systems Approach
</a>
<div class="version">
Version 0.1
</div>
<div role="search">
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
<input type="text" name="q" placeholder="Search docs" />
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
</div>
</div>
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
<p class="caption"><span class="caption-text">Table of Contents</span></p>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="preface.html">Preface</a></li>
<li class="toctree-l1"><a class="reference internal" href="intro.html">Chapter 1: Introduction</a></li>
<li class="toctree-l1"><a class="reference internal" href="primer.html">Chapter 2: Radio Transmission</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">Chapter 3: Basic Architecture</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#main-components">3.1 Main Components</a></li>
<li class="toctree-l2"><a class="reference internal" href="#radio-access-network">3.2 Radio Access Network</a></li>
<li class="toctree-l2"><a class="reference internal" href="#mobile-core">3.3 Mobile Core</a><ul>
<li class="toctree-l3"><a class="reference internal" href="#g-mobile-core">4G Mobile Core</a></li>
<li class="toctree-l3"><a class="reference internal" href="#id1">5G Mobile Core</a></li>
</ul>
</li>
<li class="toctree-l2"><a class="reference internal" href="#deployment-options">3.4 Deployment Options</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="ran.html">Chapter 4: RAN Internals</a></li>
<li class="toctree-l1"><a class="reference internal" href="disaggregate.html">Chapter 5: Advanced Capabilities</a></li>
<li class="toctree-l1"><a class="reference internal" href="impl.html">Chapter 6: Exemplar Implementation</a></li>
<li class="toctree-l1"><a class="reference internal" href="cloud.html">Chapter 7: Cloudification of Access</a></li>
<li class="toctree-l1"><a class="reference internal" href="README.html">About This Book</a></li>
</ul>
</div>
</div>
</nav>
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
<nav class="wy-nav-top" aria-label="top navigation">
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
<a href="index.html">5G Mobile Networks: A Systems Approach</a>
</nav>
<div class="wy-nav-content">
<div class="rst-content">
<div role="navigation" aria-label="breadcrumbs navigation">
<ul class="wy-breadcrumbs">
<li><a href="index.html">Docs</a> »</li>
<li>Chapter 3: Basic Architecture</li>
<li class="wy-breadcrumbs-aside">
<a href="_sources/arch.rst.txt" rel="nofollow"> View page source</a>
</li>
</ul>
<hr/>
</div>
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
<div itemprop="articleBody">
<div class="section" id="chapter-3-basic-architecture">
<h1>Chapter 3: Basic Architecture<a class="headerlink" href="#chapter-3-basic-architecture" title="Permalink to this headline">¶</a></h1>
<p>This chapter identifies the main architectural components of cellular
access networks. It focuses on the components that are common to both 4G
and 5G, and as such, establishes a foundation for understanding the
advanced features of 5G presented in later chapters.</p>
<p>This overview is partly an exercise in introducing 3GPP terminology. For
someone that is familiar with the Internet, this terminology can seem
arbitrary (e.g., “eNB” is a “base station”), but it is important to keep
in mind that this terminology came out of the 3GPP standardization
process, which has historically been concerned about telephony and
almost completely disconnected from the IETF and other Internet-related
efforts. To further confuse matters, the 3GPP terminology often changes
with each generation (e.g., a base station is called eNB in 4G and gNB
in 5G). We address situations like this by using generic terminology
(e.g., base station), and referencing the 3GPP-specific counterpart only
when the distinction is helpful.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">This example is only the tip of the terminology iceberg. For a
slightly broader perspective on the complexity of terminology in 5G,
see Marcin Dryjanski’s <a class="reference external" href="https://www.grandmetric.com/blog/2018/07/14/lte-and-5g-differences-system-complexity/">blog
post</a>.</p>
</div>
<div class="section" id="main-components">
<h2>3.1 Main Components<a class="headerlink" href="#main-components" title="Permalink to this headline">¶</a></h2>
<p>The cellular network provides wireless connectivity to devices that are
on the move. These devices, which are known as <em>User Equipment (UE)</em>,
have until recently corresponded to smartphones and tablets, but will
increasingly include cars, drones, industrial and agricultural machines,
robots, home appliances, medical devices, and so on.</p>
<div class="figure align-center" id="id2">
<span id="fig-cellular"></span><a class="reference internal image-reference" href="_images/Slide01.png"><img alt="_images/Slide01.png" src="_images/Slide01.png" style="width: 600px;" /></a>
<p class="caption"><span class="caption-text">Figure 3.1: Cellular networks consists of a Radio Access Network
(RAN) and a Mobile Core.</span></p>
</div>
<p>As shown in <a class="reference internal" href="#fig-cellular"><span class="std std-ref">Figure 3.1</span></a>,
the cellular network consists of
two main subsystems: the <em>Radio Access Network (RAN)</em> and the <em>Mobile
Core</em>. The RAN manages the radio spectrum, making sure it is both used
efficiently and meets the quality-of-service requirements of every user.
The main component in the RAN is the crypticly named <em>eNodeB</em> (or
<em>eNB</em>), which is short for the equally cryptic <em>evolved Node B</em>. The
Mobile Core is a bundle of functionality (as opposed to a device) that
serves several purposes:</p>
<ul class="simple">
<li>Provides Internet (IP) connectivity for both data and voice services.</li>
<li>Ensures this connectivity fulfills the promised QoS requirements.</li>
<li>Tracks user mobility to ensure uninterrupted service.</li>
<li>Tracks subscriber usage for billing and charging.</li>
</ul>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">Mobile Core is another example of a generic term. In 4G this is
called the Evolved Packet Core (EPC) and in 5G it is called the Next
Generation Core (NG-Core).</p>
</div>
<p>Even though the word “Core” is in its name, from an Internet
perspective, the Mobile Core is still part of the access network,
effectively providing a bridge between the RAN and the IP-world.</p>
<p>Taking a closer look at <a class="reference internal" href="#fig-cellular"><span class="std std-ref">Figure 3.1</span></a>, we see that a
<em>Backhaul Network</em> interconnects the eNBs that implement the RAN with
the Mobile Core. This network is typically wired, may or may not have
the ring topology shown in the Figure, and is often constructed from
commodity components found elsewhere in the Internet. For example, the
Passive Optical Network (PON) that implements Fiber-to-the-Home is a
prime candidate for implementing the RAN backhaul. The backhaul network
is obviously a necessary part of the RAN, but it is an implementation
choice and not prescribed by the 3GPP standard.</p>
<p>Although 3GPP specifies all the elements that implement the RAN and
Mobile Core in an open standard—including sub-layers we have not yet
introduced—network operators have historically bought proprietary
implementations of each subsystem from a single vendor. This lack of an
open source implementation contributes to the perceived “opaqueness” of
the cellular network in general, and the RAN in particular. And while it
is true that an eNodeB implementation does contain sophisticated
algorithms for scheduling transmission on the radio spectrum—algorithms
that are considered valuable Intellectual Property of the equipment
vendors—there is significant opportunity to open and disaggregate both
the RAN and the Mobile Core. The following two sections describe each,
in turn.</p>
<p>Before getting to those details, <a class="reference internal" href="#fig-cups"><span class="std std-ref">Figure 3.2</span></a>
redraws components from <a class="reference internal" href="#fig-cellular"><span class="std std-ref">Figure 3.1</span></a>
to highlight two important
distinctions. The first is that the eNB (which we will refer to as the
Base Station from here on) has an analog component (depicted by an
antenna) and a digital component (depicted by a processor). The second
is that the Mobile Core is partitioned into a <em>Control Plane</em> and <em>User
Plane</em>, which is similar to the control/data plane split that someone
familiar with the Internet would recognize. (3GPP also recently
introduced a corresponding acronym—<em>CUPS, Control and User Plane
Separation</em>—to denote this idea). The importance of these two
distinctions will become clear in the following discussion.</p>
<div class="figure align-center" id="id3">
<span id="fig-cups"></span><a class="reference internal image-reference" href="_images/Slide02.png"><img alt="_images/Slide02.png" src="_images/Slide02.png" style="width: 400px;" /></a>
<p class="caption"><span class="caption-text">Figure 3.2: Mobile Core divided into a Control Plan and a User
Plane, an architectural feature known as CUPS: Control and User
Plane Separation</span></p>
</div>
</div>
<div class="section" id="radio-access-network">
<h2>3.2 Radio Access Network<a class="headerlink" href="#radio-access-network" title="Permalink to this headline">¶</a></h2>
<p>We now describe the RAN by sketching the role each base station plays.
Keep in mind this is kind of like describing the Internet by explaining
how a router works—a not unreasonable place to start, but it doesn’t
fully do justice to the end-to-end story.</p>
<p>First, each base station establishes the wireless channel for a
subscriber’s UE upon power-up or upon handover when the UE is active.
This channel is released when the UE remains idle for a predetermined
period of time. Using 3GPP terminology, this wireless channel is said to
provide a bearer service.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">The term “bearer” has historically been used in telecommunications
(including early wireline technologies like ISDN) to denote “data,”
as opposed to a channel that carries “signalling” information.</p>
</div>
<div class="figure align-center" id="id4">
<span id="fig-active-ue"></span><a class="reference internal image-reference" href="_images/Slide03.png"><img alt="_images/Slide03.png" src="_images/Slide03.png" style="width: 500px;" /></a>
<p class="caption"><span class="caption-text">Figure 3.3: Base Station detects (and connects to) active UEs.</span></p>
</div>
<p>Second, each base station establishes ”3GPP Control Plane” connectivity
between the UE and the corresponding Mobile Core Control Plane
component, and forwards signaling traffic between the two. This
signaling traffic enables UE authentication, registration, mobility
tracking.</p>
<div class="figure align-center" id="id5">
<span id="fig-control-plane"></span><a class="reference internal image-reference" href="_images/Slide04.png"><img alt="_images/Slide04.png" src="_images/Slide04.png" style="width: 500px;" /></a>
<p class="caption"><span class="caption-text">Figure 3.4: Base Station establishes control plane connectivity
between each UE and the Mobile Core.</span></p>
</div>
<p>Third, for each active UE, the base station establishes one or more
tunnels between the corresponding Mobile Core User Plane component.</p>
<div class="figure align-center" id="id6">
<span id="fig-user-plane"></span><a class="reference internal image-reference" href="_images/Slide05.png"><img alt="_images/Slide05.png" src="_images/Slide05.png" style="width: 500px;" /></a>
<p class="caption"><span class="caption-text">Figure 3.5: Base station establishes one or more tunnels between
each UE and the Mobile Core’s User Plane.</span></p>
</div>
<p>Fourth, the base station forwards both control and user plane packets
between the Mobile Core and the UE. These packets are tunnelled over
SCTP/IP and GTP/UDP/IP, respectively. SCTP (Stream Control Transport
Protocol) is 3GPP-defined alternative to TCP, tailored to carry
signalling (control) information for telephony services. GTP (a nested
acronym corresponding to (General Packet Radio Service) Tunneling
Protocol) is a 3GPP-specific tunneling protocol designed to run over
UDP.</p>
<p>As an aside, it is noteworthy that connectivity between the RAN and the
Mobile Core is IP-based. This was introduced as one of the main changes
between 3G and 4G. Prior to 4G, the internals of the cellular network
were circuit-based, which is not surprising given its origins as a voice
network.</p>
<div class="figure align-center" id="id7">
<span id="fig-tunnels"></span><a class="reference internal image-reference" href="_images/Slide06.png"><img alt="_images/Slide06.png" src="_images/Slide06.png" style="width: 500px;" /></a>
<p class="caption"><span class="caption-text">Figure 3.6: Base Station to Mobile Core (and Base Station to Base
Station) control plane tunneled over SCTP/IP and user plane
tunneled over GTP/UDP/IP.</span></p>
</div>
<p>Fifth, the base station coordinates UE handovers between neighboring
base stations, using direct station-to-station links. Exactly like the
station-to-core connectivity shown in the previous figure, these links
are used to transfer both control plane (SCTP over IP) and user plane
(GTP over UDP/IP) packets.</p>
<div class="figure align-center" id="id8">
<span id="fig-handover"></span><a class="reference internal image-reference" href="_images/Slide07.png"><img alt="_images/Slide07.png" src="_images/Slide07.png" style="width: 500px;" /></a>
<p class="caption"><span class="caption-text">Figure 3.7: Base Stations cooperate to implement UE hand over.</span></p>
</div>
<p>Sixth, the base station coordinates wireless multi-point transmission to
a UE from multiple base stations, which may or may not be part of a UE
handover from one base station to another.</p>
<div class="figure align-center" id="id9">
<span id="fig-link-aggregation"></span><a class="reference internal image-reference" href="_images/Slide08.png"><img alt="_images/Slide08.png" src="_images/Slide08.png" style="width: 500px;" /></a>
<p class="caption"><span class="caption-text">Figure 3.8: Base Stations cooperate to implement multipath
transmission (link aggregation) to UEs.</span></p>
</div>
<p>For our purposes, the main takeaway is that the base station can be
viewed as a specialized forwarder. In the Internet-to-UE direction, it
fragments outgoing IP packets into physical layer segments and schedules
them for transmission over the available radio spectrum, and in the
UE-to-Internet direction it assembles physical layer segments into IP
packets and forwards them (over a GTP/UDP/IP tunnel) to the upstream
user plane of the Mobile Core. Also, based on observations of the
wireless channel quality and per-subscriber policies, it decides whether
to (a) forward outgoing packets directly to the UE, (b) indirectly
forward packets to the UE via a neighboring base station, or (c) utilize
multiple paths to reach the UE. The third case has the option of either
spreading the physical payloads across multiple base stations or across
multiple carrier frequencies of a single base station (including Wi-Fi).</p>
<p>Note that as outlined in the previous chapter, scheduling is complex and
multi-faceted, even when viewed as a localized decision at a single base
station. What we now see is that there is also a global element, whereby
it’s possible to forward traffic to a different base station (or to
multiple base stations) in an effort to make efficient use of the radio
spectrum over a larger geographic area.</p>
<p>In other words, the RAN as a whole (i.e., not just a single base
station) not only supports handovers (an obvious requirement for
mobility), but also <em>link aggregation</em> and <em>load balancing</em>, mechanisms
that are familiar to anyone that understands the Internet. We will
revisit how such RAN-wide (global) decisions can be made using SDN
techniques in a later chapter.</p>
</div>
<div class="section" id="mobile-core">
<h2>3.3 Mobile Core<a class="headerlink" href="#mobile-core" title="Permalink to this headline">¶</a></h2>
<p>The main function of the Mobile Core is to provide external packet data
network (e.g., Internet) connectivity to mobile subscribers, while
ensuring that they are authenticated and their observed service
qualities satisfy their subscription SLAs. An important aspect of the
Mobile Core is that it needs to manage all subscribers’ mobility by
keeping track of their last whereabouts at the granularity of the
serving base station.</p>
<p>While the aggregate functionality remains largely the same as we migrate
from 4G to 5G, how that functionality is virtualized and factored into
individual components changes, with the 5G Mobile Core heavily
influenced by the cloud’s march towards a microservice-based (cloud
native) architecture. This shift to cloud native is deeper than it might
first appear, in part because it opens the door to customization and
specialization. Instead of supporting just voice and broadband
connectivity, the 5G Mobile Core can evolve to also support, for
example, massive IoT, which has a fundamentally different latency
requirement and usage pattern (e.g., many more devices connecting
intermittently). This stresses—if not breaks—a one-size-fits-all
approach to session management.</p>
<div class="section" id="g-mobile-core">
<h3>4G Mobile Core<a class="headerlink" href="#g-mobile-core" title="Permalink to this headline">¶</a></h3>
<p>The 4G Mobile Core, which 3GPP officially refers to as the <em>Evolved
Packet Core (EPC)</em>, consists of five main components, the first three of
which run in the Control Plane (CP) and the second two of which run in
the User Plane (UP):</p>
<ul class="simple">
<li>MME (Mobility Management Entity): Tracks and manages the movement of
UEs throughout the RAN. This includes recording when the UE is not
active.</li>
<li>HSS (Home Subscriber Server): A database that contains all
subscriber-related information.</li>
<li>PCRF (Policy & Charging Rules Function): Tracks and manages policy
rules and records billing data on subscriber traffic.</li>
<li>SGW (Serving Gateway): Forwards IP packets to and from the RAN.
Anchors the Mobile Core end of the bearer service to a (potentially
mobile) UE, and so is involved in handovers from one base station to
another.</li>
<li>PGW (Packet Gateway): Essentially an IP router, connecting the Mobile
Core to the external Internet. Supports additional access-related
functions, including policy enforcement, traffic shaping, and
charging.</li>
</ul>
<p>Although specified as distinct components, in practice the SGW
(RAN-facing) and PGW (Internet-facing) are often combined in a single
device, commonly referred to as an S/PGW. The end result is illustrated
in <a class="reference internal" href="#fig-4g-core"><span class="std std-ref">Figure 3.9</span></a>.</p>
<div class="figure align-center" id="id10">
<span id="fig-4g-core"></span><a class="reference internal image-reference" href="_images/Slide20.png"><img alt="_images/Slide20.png" src="_images/Slide20.png" style="width: 700px;" /></a>
<p class="caption"><span class="caption-text">Figure 3.9: 4G Mobile Core (Evolved Packet Core).</span></p>
</div>
<p>Note that 3GPP is flexible in how the Mobile Core components are
deployed to serve a geographic area. For example, a single MME/PGW pair
might serve a metropolitan area, with SGWs deployed across ~10 edge
sites spread throughout the city, each of which serves ~100 base
stations. But alternative deployment configurations are allowed by the
spec.</p>
</div>
<div class="section" id="id1">
<h3>5G Mobile Core<a class="headerlink" href="#id1" title="Permalink to this headline">¶</a></h3>
<p>The 5G Mobile Core, which 3GPP calls the <em>NG-Core</em>, adopts a
microservice-like architecture, where we say “microservice-like” because
while the 3GPP specification spells out this level of disaggregation, it
is really just prescribing a set of functional blocks and not an
implementation. Keeping in mind a set of functional blocks is very
different from the collection of engineering decisions that go into
designing a microservice-based system, viewing the collection of
components shown in <a class="reference internal" href="#fig-5g-core"><span class="std std-ref">Figure 3.10</span></a>
as a set of microservices is a good working model.</p>
<p>The following organizes the set of functional blocks into three groups.
The first group runs in the Control Plane (CP) and has a counterpart in
the EPC:</p>
<ul class="simple">
<li>AMF (Core Access and Mobility Management Function): Manages the
mobility-related aspects of the EPC’s MME. Responsible for connection
and reachability management, mobility management, access
authentication and authorization, and location services.</li>
<li>SMF (Session Management Function): Manages each UE session, including
IP address allocation, selection of associated UP function, control
aspects of QoS, and control aspects of UP routing. Roughly
corresponds to part of the EPC’s MME and the control-related aspects
of the EPC’s PGW.</li>
<li>PCF (Policy Control Function): Manages the policy rules that other CP
functions then enforce. Roughly corresponds to the EPC’s PCRF.</li>
<li>UDM (Unified Data Management): Manages user identity, including the
generation of authentication credentials. Includes part of the
functionality in the EPC’s HSS.</li>
<li>AUSF (Authentication Server Function): Essentially an authentication
server. Includes part of the functionality in the EPC’s HSS.</li>
</ul>
<p>The second group also runs in the Control Plane (CP) but does not have a
counterpart in the EPC:</p>
<ul class="simple">
<li>SDSF (Structured Data Storage Network Function): A “helper” service
used to store structured data. Might be implemented by an “SQL
Database” in a microservices-based system.</li>
<li>UDSF (Unstructured Data Storage Network Function): A “helper” service
used to store unstructured data. Might be implemented by a “Key/Value
Store” in a microservices-based system.</li>
<li>NEF (Network Exposure Function): A means to expose select
capabilities to third-party services, including translation between
internal and external representations for data. Might be implemented
by an “API Server” in a microservices-based system.</li>
<li>NFR (NF Repository Function): A means to discover available services.
Might be implemented by a “Discovery Service” in a
microservices-based system.</li>
<li>NSSF (Network Slicing Selector Function): A means to select a Network
Slice to serve a given UE. Network slices are essentially a way to
differentiate service given to different users. It is a key feature
of 5G that we discuss in depth later in this tutorial.</li>
</ul>
<p>The third group includes the one component that runs in the User Plane
(UP):</p>
<ul class="simple">
<li>UPF (User Plane Function): Forwards traffic between RAN and the
Internet, corresponding to the S/PGW combination in EPC. In addition
to packet forwarding, responsible for policy enforcement, lawful
intercept, traffic usage reporting, and QoS policing.</li>
</ul>
<p>Of these, the first and third groups are best viewed as a
straightforward refactoring of 4G’s EPC, while the second group—despite
the gratuitous introduction of new terminology—is 3GPP’s way of pointing
to a cloud native solution as the desired end-state for the Mobile Core.
Of particular note, introducing distinct storage services means that all
the other services can be stateless, and hence, more readily scalable.
Also note that <a class="reference internal" href="#fig-5g-core"><span class="std std-ref">Figure 3.10</span></a> adopts an idea that’s
common in microservice-based systems, namely, to show a “message bus”
interconnecting all the components rather than including a full set of
pairwise connections. This also suggests a well-understood
implementation strategy.</p>
<div class="figure align-center" id="id11">
<span id="fig-5g-core"></span><a class="reference internal image-reference" href="_images/Slide33.png"><img alt="_images/Slide33.png" src="_images/Slide33.png" style="width: 700px;" /></a>
<p class="caption"><span class="caption-text">Figure 3.10: 5G Mobile Core (NG-Core).</span></p>
</div>
<p>Stepping back from these details, and with the caveat that we are
presuming an implementation, the main takeaway is that we can
conceptualize the Mobile Core as a <em>Service Mesh</em>. We adopt this
terminology for “an interconnected set of microservices” since it is
widely used in cloud native systems. Other terms you will sometimes hear
are <em>Service Graph</em> and <em>Service Chain</em>, the latter being more prevalent
in NFV-oriented documents. 3GPP is silent on the specific terminology
since it is considered an implementation choice rather than part of the
specification.</p>
</div>
</div>
<div class="section" id="deployment-options">
<h2>3.4 Deployment Options<a class="headerlink" href="#deployment-options" title="Permalink to this headline">¶</a></h2>
<p>With an already deployed 4G RAN/EPC in the field and a new 5G
RAN/NG-Core deployment underway, we can’t ignore the issue of
transitioning from 4G to 5G (an issue the IP-world has been grappling
with for 20 years). 3GPP officially spells out multiple deployment
options, which can be summarized as follows:</p>
<ul class="simple">
<li>Stand-Alone 4G / Stand-Alone 5G</li>
<li>Non-Stand-Alone (4G+5G RAN) over 4G’s EPC</li>
<li>Non-Stand-Alone (4G+5G RAN) over 5G’s NG-Core</li>
</ul>
<p>Focusing on the second pair, which imply incremental phasing, we see two
general strategies. The first is to connect new 5G base stations to
existing 4G-based EPCs, and then incrementally evolve the Mobile Core by
refactoring the components and adding NG-Core capabilities over time.
The second is to implement a backward-compatible NG-Core that can
support both 4G and 5G base stations, where the new NG-Core could be
implemented from scratch, but would likely start with the existing EPC
code base.</p>
<p>One reason we call attention to the phasing issue is that we face a
similar challenge in the chapters that follow. The closer the following
discussion gets to implementation details, the more specific we have to
be about whether we are using 4G components or 5G components. As a
general rule, we use 4G components—particularly with respect to the
Mobile Core, since that’s the available open source software—and trust
the reader can make the appropriate substitution without loss of
generality. Like the broader industry, the open source community is in
the process of incrementally evolving its 4G code base into its
5G-compliant counterpart.</p>
</div>
</div>
</div>
</div>
<footer>
<div class="rst-footer-buttons" role="navigation" aria-label="footer navigation">
<a href="ran.html" class="btn btn-neutral float-right" title="Chapter 4: RAN Internals" accesskey="n" rel="next">Next <span class="fa fa-arrow-circle-right"></span></a>
<a href="primer.html" class="btn btn-neutral float-left" title="Chapter 2: Radio Transmission" accesskey="p" rel="prev"><span class="fa fa-arrow-circle-left"></span> Previous</a>
</div>
<hr/>
<div role="contentinfo">
<p>
© Copyright 2019
</p>
</div>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/rtfd/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
</footer>
</div>
</div>
</section>
</div>
<script type="text/javascript">
jQuery(function () {
SphinxRtdTheme.Navigation.enable(true);
});
</script>
</body>
</html>