-
Notifications
You must be signed in to change notification settings - Fork 0
/
disaggregate.html
501 lines (388 loc) · 25.6 KB
/
disaggregate.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
<!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 5: Advanced Capabilities — 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 6: Exemplar Implementation" href="impl.html" />
<link rel="prev" title="Chapter 4: RAN Internals" href="ran.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"><a class="reference internal" href="arch.html">Chapter 3: Basic Architecture</a></li>
<li class="toctree-l1"><a class="reference internal" href="ran.html">Chapter 4: RAN Internals</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">Chapter 5: Advanced Capabilities</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#optimized-data-plane">5.1 Optimized Data Plane</a></li>
<li class="toctree-l2"><a class="reference internal" href="#multi-cloud">5.2 Multi-Cloud</a></li>
<li class="toctree-l2"><a class="reference internal" href="#network-slicing">5.3 Network Slicing</a><ul>
<li class="toctree-l3"><a class="reference internal" href="#ran-slicing">RAN Slicing</a></li>
<li class="toctree-l3"><a class="reference internal" href="#core-slicing">Core Slicing</a></li>
</ul>
</li>
</ul>
</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 5: Advanced Capabilities</li>
<li class="wy-breadcrumbs-aside">
<a href="_sources/disaggregate.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-5-advanced-capabilities">
<h1>Chapter 5: Advanced Capabilities<a class="headerlink" href="#chapter-5-advanced-capabilities" title="Permalink to this headline">¶</a></h1>
<p>Disaggregating the cellular network pays dividends. This chapter
explores three examples. Stepping back to look at the big picture,
Chapter 3 (Architecture) described “what is” (the basics of 3GPP) and
the Chapter 4 (RAN Internals) described “what will be” (where the
industry, led by the O-RAN Alliance, is clearly headed), whereas this
chapter describes “what could be” (our best judgement on cutting-edge
capabilities that will eventually be realized).</p>
<div class="section" id="optimized-data-plane">
<h2>5.1 Optimized Data Plane<a class="headerlink" href="#optimized-data-plane" title="Permalink to this headline">¶</a></h2>
<p>There are many reasons to disaggregate functionality, but one of the
most compelling is that by decoupling control and data code paths, it is
possible to optimize the data path. This can be done, for example, by
programming it into specialized hardware. Modern white-box switches with
programmable packet forwarding pipelines are a perfect example of
specialized hardware we can exploit in the cellular network.
<a class="reference internal" href="#fig-e2e"><span class="std std-ref">Figure 5.1</span></a> shows the first step in the process
of doing this. The figure also pulls together all the elements we’ve
been describing up to this point. There are several things to note
about this diagram.</p>
<div class="figure align-center" id="id1">
<span id="fig-e2e"></span><a class="reference internal image-reference" href="_images/Slide21.png"><img alt="_images/Slide21.png" src="_images/Slide21.png" style="width: 600px;" /></a>
<p class="caption"><span class="caption-text">Figure 5.1: End-to-end disaggregated system, including Mobile Core
and Split-RAN.</span></p>
</div>
<p>First, the figure combines both the Mobile Core and RAN elements,
organized according to the major subsystems: Mobile Core, Central Unit
(CU), Distributed Unit (DU), and Radio Unit (RU). The figure also shows
one possible mapping of these subsystems onto physical locations, with
the first two co-located in a Central Office and the latter two
co-located in a cell tower. As discussed earlier, other configurations
are also possible.</p>
<p>Second, the figure shows the Mobile Core’s two user plane elements (PGW,
SGW) and the Central Unit’s single user plane element (PDCP) further
disaggregated into control/user plane pairs, denoted PGW-C / PGW-U,
SGW-C / SGW-U, and PDCP-C / PDCP-U, respectively. Exactly how this
decoupling is realized is a design choice (i.e., not specified by 3GPP),
but the idea is to reduce User Plane component to the minimal
Receive-Packet / Process-Packet / Send-Packet processing core, and
elevate all control-related aspects into the Control Plane component.</p>
<p>Third, the PHY (Physical) element of the RAN pipeline is split between
the DU and RU partition. Although beyond the scope of this book, the
3GPP spec specifies the PHY element as a collection of functional
blocks, some of which can be effectively implemented by software running
on a general-purpose processor and some of which are best implemented in
specialized hardware (e.g., a Digital Signal Processor). These two
subsets of functional blocks map to the PHY Upper (part of the DU) and
the PHY Lower (part of the RU), respectively.</p>
<p>Fourth, and somewhat confusingly, <a class="reference internal" href="#fig-e2e"><span class="std std-ref">Figure 5.1</span></a>
shows the PCDP-C
element and the Control Plane (Forwarding) element combined into a
single functional block, with a data path (blue line) connecting that
block to both the RLC and the MME. Exactly how this pair is realized is
an implementation choice (e.g., they could map onto two or more
microservices), but the end result is that they are part of an
end-to-end path over which the MME can send control packets to the UE.
Note that this means responsibility for demultiplexing incoming packets
between the control plane and user plane falls to the RLC.</p>
<div class="figure align-center" id="id2">
<span id="fig-e2e-p4"></span><a class="reference internal image-reference" href="_images/Slide22.png"><img alt="_images/Slide22.png" src="_images/Slide22.png" style="width: 600px;" /></a>
<p class="caption"><span class="caption-text">Figure 5.2: Implementing data plane elements of the User Plane in
programmable switches.</span></p>
</div>
<p><a class="reference internal" href="#fig-e2e-p4"><span class="std std-ref">Figure 5.2</span></a> shows why we disaggregated these
components: it allows us to realize the three user plane elements
(PGW-U, SGW-U, PDCP-U) in switching hardware. This can be done using a
combination of a language that is tailored for programming forwarding
pipelines (e.g., P4), and a protocol-independent switching
architecture (e.g., Tofino). For now, the important takeaway is that
the RAN and Mobile Core user plane can be mapped directly onto an
SDN-enabled data plane.</p>
<p>Pushing RAN and Mobile Core forwarding functionality into the switching
hardware results in overlapping terminology that can sometimes be
confusing. 5G separates the functional blocks into control and user
planes, while SDN disaggregates a given functional block into control
and data plane halves. The overlap comes from our choosing to implement
the 5G user plane by splitting it into its SDN-based control and data
plane parts. As one simplification, we refer to the Control Plane
(Forwarding) and PDCP-C combination as the CU-C (Central Unit - Control)
going forward.</p>
<p>Finally, the SDN-prescribed control/data plane disaggregation comes with
an implied implementation strategy, namely, the use of a scalable and
highly available <em>Network Operating System (NOS)</em>. Like a traditional
OS, a NOS sits between application programs (control apps) and the
underlying hardware devices (whitebox switches), providing higher levels
abstractions (e.g., network graph) to those applications, while hiding
the low-level details of the underlying hardware. To make the discussion
more concrete, we use ONOS (Open Network Operating System) as an example
NOS, where PGW-C, SGW-C, and PDCP-C are all realized as control
applications running on top of ONOS.</p>
<div class="figure align-center" id="id3">
<span id="fig-onos"></span><a class="reference internal image-reference" href="_images/Slide23.png"><img alt="_images/Slide23.png" src="_images/Slide23.png" style="width: 400px;" /></a>
<p class="caption"><span class="caption-text">Figure 5.3: Control Plane elements of the User Plane implemented
as Control Applications running on an SDN Controller (e.g., ONOS).</span></p>
</div>
<p><a class="reference internal" href="#fig-onos"><span class="std std-ref">Figure 5.3</span></a> shows one possible configuration, in which the
underlying switches are interconnected to form a leaf-spine fabric. Keep
in mind that the linear sequence of switches implied by <a class="reference internal" href="#fig-e2e-p4"><span class="std std-ref">Figure
5.2</span></a> is logical, but that in no way restricts the actual
hardware to the same topology. The reason we use a leaf-spine topology
is related to our ultimate goal of building an edge cloud, and
leaf-spine is the proto-typical structure for such cloud-based clusters.
This means the three control applications must work in concert to
implement an end-to-end path through the fabric, which in practice
happens with the aid of other, fabric aware, control applications (as
implied by the “…” in the Figure). We describe the complete picture in
more detail in the next chapter, but for now, the big takeaway is that
the control plane components of the 5G overlay can be realized as
control applications for an SDN-based underlay.</p>
</div>
<div class="section" id="multi-cloud">
<h2>5.2 Multi-Cloud<a class="headerlink" href="#multi-cloud" title="Permalink to this headline">¶</a></h2>
<p>Another consequence of disaggregating functionality is that once
decoupled, different functions can be placed in different physical
locations. We have already seen this when we split the RAN, placing some
functions (e.g., the PCDP and RRC) in the Central Unit and others (e.g.,
RLC and MAC) in Distributed Units. This allows for simpler (less
expensive) hardware in remote locations, where there are often space,
power, and cooling constraints.</p>
<p>This process can be repeated by distributing the more centralized
elements across multiple clouds, including large datacenters that
already benefit from elasticity and economies of scale. <a class="reference internal" href="#fig-multicloud"><span class="std std-ref">Figure
5.4</span></a> shows the resulting multi-cloud realization of
the Mobile Core. We leave the user plane at the edge of the network (e.g.,
in the Central Office) and move control plane to a centralized cloud. It
could even be a public cloud like Google or Amazon. This includes not
only the MME, PCRF and HSS, but also the PGW-C and SGW-C we decoupled
in the previous section. (Note that <a class="reference internal" href="#fig-multicloud"><span class="std std-ref">Figure 5.4</span></a>
renames the PDCP-U from earlier diagrams as the CU-U; either label is
valid.)</p>
<div class="figure align-center" id="id4">
<span id="fig-multicloud"></span><a class="reference internal image-reference" href="_images/Slide24.png"><img alt="_images/Slide24.png" src="_images/Slide24.png" style="width: 600px;" /></a>
<p class="caption"><span class="caption-text">Figure 5.4: Multi-Cloud implementation, with MME, HSS, PCRF and
Control Plane elements of the PGW and SGW running in a centralized
cloud.</span></p>
</div>
<p>What is the value in doing this? Just like the DU and RU, the Edge Cloud
likely has limited resources. If we want room to run new edge services
there, it helps to move any components that need not be local to a
larger facility with more abundant resources. Centralization also
facilitates collecting and analyzing data across multiple edge
locations, which is harder to do if that information is distributed over
multiple sites. (Analytics performed on this data also benefits from
having abundant compute resources available.)</p>
<p>But there’s another reason worth calling out: It lowers the barrier for
anyone (not just the companies that own and operate the RAN
infrastructure) to offer mobile services to customers. These entities
are called <em>MVNOs (Mobile Virtual Network Operators)</em> and one clean way
to engineer an MVNO is to run your own Mobile Core on a cloud of your
choosing.</p>
</div>
<div class="section" id="network-slicing">
<h2>5.3 Network Slicing<a class="headerlink" href="#network-slicing" title="Permalink to this headline">¶</a></h2>
<p>One of the most compelling value propositions of 5G is the ability to
differentiate the level of service offered to different applications and
customers. Differentiation, of course, is key to being able to charge
some customers more than others, but the monetization case aside, it is
also necessary if you are going to support such widely varying
applications as streaming video (which requires high bandwidth but can
tolerate larger latencies) and Internet-of-Things (which has minimal
bandwidth needs but requires extremely low and predictable latencies).</p>
<p>The mechanism that supports this sort of differentiation is called
network slicing, and it fundamentally comes down to scheduling, both in
the RAN (deciding which segments to transmit) and in the Mobile Core
(scaling microservice instances and placing those instances on the
available servers). The following introduces the basic idea, starting
with the RAN.</p>
<p>But before getting into the details, we note that a network slice is a
generalization of the QoS Class Index (QCI) discussed earlier. 3GPP
specifies a standard set of network slices, called <em>Standardized Slice
Type (SST)</em> values. For example, SST 1 corresponds to mobile broadband,
SST 2 corresponds to Ultra-Reliable Low Latency Communications, SST 3
corresponds to Massive IoT, and so on. It is also possible to extend
this standard set with additional slice behaviors, as well as define
multiple slices for each SST (e.g., to further differentiate subscribers
based on priority).</p>
<div class="section" id="ran-slicing">
<h3>RAN Slicing<a class="headerlink" href="#ran-slicing" title="Permalink to this headline">¶</a></h3>
<p>We start by reviewing the basic scheduling challenge previewed in
Chapter 2. As depicted in <a class="reference internal" href="#fig-slice-sched"><span class="std std-ref">Figure 5.5</span></a>,
the radio spectrum can be conceptualized as a two-dimensional grid of
<em>Resource Blocks (RB)</em>, where the scheduler’s job is to decide how to fill the
grid with the available segments from each user’s transmission queue
based on CQI feedback from the UEs. To restate, the power of OFDMA is
the flexibility it provides in how this mapping is performed.</p>
<div class="figure align-center" id="id5">
<span id="fig-slice-sched"></span><a class="reference internal image-reference" href="_images/Slide27.png"><img alt="_images/Slide27.png" src="_images/Slide27.png" style="width: 450px;" /></a>
<p class="caption"><span class="caption-text">Figure 5.5: Scheduler allocating resource blocks to UEs.</span></p>
</div>
<p>While in principle one could define an uber scheduler that takes dozens
of different factors into account, the key to network slicing is to add
a layer of indirection, such that (as shown in <a class="reference internal" href="#fig-hypervisor"><span class="std std-ref">Figure 5.6</span></a>, we perform a second mapping of Virtual RBs to
Physical RBs. This sort of virtualization is common in resource
allocators throughout computing systems because we want to separate how
many resources are allocated to each user from the decision as to which
physical resources are actually assigned. This virtual-to-physical
mapping is performed by a layer typically known as a <em>Hypervisor</em>, and
the important thing to keep in mind is that it is totally agnostic about
which user’s segment is affected by each translation.</p>
<div class="figure align-center" id="id6">
<span id="fig-hypervisor"></span><a class="reference internal image-reference" href="_images/Slide28.png"><img alt="_images/Slide28.png" src="_images/Slide28.png" style="width: 600px;" /></a>
<p class="caption"><span class="caption-text">Figure 5.6: Wireless Hypervisor mapping virtual resource blocks to
physical resource blocks.</span></p>
</div>
<p>Having decoupled the Virtual RBs from Physical RBs, it is now possible
to define multiple Virtual RB sets (of varying sizes), each with its own
scheduler. <a class="reference internal" href="#fig-multi-sched"><span class="std std-ref">Figure 5.7</span></a> gives an example with two
equal-sized RB sets, where the important consequence is that having made
the macro-decision that the Physical RBs are divided into two equal
partitions, the scheduler associated with each partition is free to
allocate Virtual RBs completely independent from each other. For
example, one scheduler might be designed to deal with high-bandwidth
video traffic and another scheduler might be optimized for low-latency
IoT traffic. Alternatively, a certain fraction of the available capacity
could be reserved for premium customers or other high-priority traffic
(e.g., public safety), with the rest shared among everyone else.</p>
<div class="figure align-center" id="id7">
<span id="fig-multi-sched"></span><a class="reference internal image-reference" href="_images/Slide29.png"><img alt="_images/Slide29.png" src="_images/Slide29.png" style="width: 600px;" /></a>
<p class="caption"><span class="caption-text">Figure 5.7: Multiple schedulers running on top of wireless
hypervisor.</span></p>
</div>
<p>Going one level deeper in the implementation details, the real-time
scheduler running in each DU receives high-level directives from the
near real-time scheduler running in the CU, and as depicted in
<a class="reference internal" href="#fig-slicing-control"><span class="std std-ref">Figure 5.8</span></a>, these directives make dual
transmission, handoff, and interference decisions on a per-slice
basis. A single RAN Slicing control application is responsible for the
macro-scheduling decision by allocating resources among a set of
slices. Understanding this implementation detail is important because
all of these control decisions are implemented by software modules,
and hence, easily changed or customized. They are not “locked” into
the underlying system, as they have historically been in 4G’s eNodeBs.</p>
<div class="figure align-center" id="id8">
<span id="fig-slicing-control"></span><a class="reference internal image-reference" href="_images/Slide30.png"><img alt="_images/Slide30.png" src="_images/Slide30.png" style="width: 350px;" /></a>
<p class="caption"><span class="caption-text">Figure 5.8: Centralized near-realtime control applications
cooperating with distribute real-time RAN schedulers.</span></p>
</div>
</div>
<div class="section" id="core-slicing">
<h3>Core Slicing<a class="headerlink" href="#core-slicing" title="Permalink to this headline">¶</a></h3>
<p>In addition to slicing the RAN, we also need to slice the Mobile Core.
In many ways, this is a well-understood problem, involving QoS
mechanisms in the network switches (i.e., making sure packets flow
through the switching fabric according to the bandwidth allocated to
each slice) and the cluster processors (i.e., making sure the containers
that implement each microservice are allocated sufficient CPU cores to
sustain the packet forwarding rate of the corresponding slice).</p>
<p>But packet scheduling and CPU scheduling are low-level mechanisms. What
makes slicing work is to also virtualize and replicate the entire
service mesh that implements the Mobile Core. If you think of a slice as
a system abstraction, then that abstraction needs to keep track of the
set of interconnected microservices that implement each slice,
and then instruct the underlying packet schedulers to allocate
sufficient network bandwidth to the slice’s flows and the underlying CPU
schedulers to allocate sufficient compute cycles to the slice’s
containers.</p>
<p>For example, if there are two network slices (analogous to the two RAN
schedulers shown in <a class="reference internal" href="#fig-multi-sched"><span class="std std-ref">Figure 5.7</span></a> and
<a class="reference internal" href="#fig-slicing-control"><span class="std std-ref">5.8</span></a>), then there would also need to be two Mobile
Core service meshes: One set of AMF, SMF, UPF,… microservices running on
behalf of the first slice and a second set of AMF, SMF, UPF,…
microservices running on behalf of the second slice. These two meshes
would scale independently (i.e., include a different number of container
instances), depending on their respective workloads and QoS guarantees.
The two slices would also be free to make different implementation
choices, for example, with one optimized for massive IoT applications
and the other optimized for high-bandwidth AR/VR applications.</p>
<p>The one remaining mechanism we need is a demultiplexing function that
maps a given packet flow (e.g., between UE and some Internet
application) onto the appropriate instance of the service mesh. This is
the job of the NSSF described in an Chapter 3: it is responsible
for selecting the mesh instance a given slice’s traffic is to traverse.</p>
</div>
</div>
</div>
</div>
</div>
<footer>
<div class="rst-footer-buttons" role="navigation" aria-label="footer navigation">
<a href="impl.html" class="btn btn-neutral float-right" title="Chapter 6: Exemplar Implementation" accesskey="n" rel="next">Next <span class="fa fa-arrow-circle-right"></span></a>
<a href="ran.html" class="btn btn-neutral float-left" title="Chapter 4: RAN Internals" 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>