-
Notifications
You must be signed in to change notification settings - Fork 0
/
primer.html
481 lines (368 loc) · 23.5 KB
/
primer.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
<!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 2: Radio Transmission — 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 3: Basic Architecture" href="arch.html" />
<link rel="prev" title="Chapter 1: Introduction" href="intro.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 current"><a class="current reference internal" href="#">Chapter 2: Radio Transmission</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#coding-and-modulation">2.1 Coding and Modulation</a></li>
<li class="toctree-l2"><a class="reference internal" href="#scheduling-4g">2.2 Scheduling: 4G</a></li>
<li class="toctree-l2"><a class="reference internal" href="#scheduling-5g">2.3 Scheduling: 5G</a></li>
</ul>
</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"><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 2: Radio Transmission</li>
<li class="wy-breadcrumbs-aside">
<a href="_sources/primer.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-2-radio-transmission">
<h1>Chapter 2: Radio Transmission<a class="headerlink" href="#chapter-2-radio-transmission" title="Permalink to this headline">¶</a></h1>
<p>For anyone familiar with wireless access technologies like Wi-Fi, the
cellular network is most unique due to its approach to sharing the
available radio spectrum among its many users, all the while allowing
those users to remain connected while moving. This has resulted in a
highly dynamic and adaptive approach, in which coding, modulation and
scheduling play a central role.</p>
<p>As we will see later in this chapter, cellular networks use a
reservation-based strategy, whereas Wi-Fi is contention-based. This
difference is rooted in each system’s fundamental assumption about
utilization: Wi-Fi assumes a lightly loaded network (and hence
optimistically transmits when the wireless link is idle and backs off if
contention is detected), while 4G and 5G cellular networks assume (and
strive for) high utilization (and hence explicitly assign different
users to different “shares” of the available radio spectrum).</p>
<p>We start by giving a short primer on radio transmission as a way of
laying a foundation for understanding the rest of the 5G architecture.
The following is not a substitute for a theoretical treatment of the topic,
but is instead intended as a way of grounding the systems-oriented
description of 5G that follows in the reality of wireless communication.</p>
<div class="section" id="coding-and-modulation">
<h2>2.1 Coding and Modulation<a class="headerlink" href="#coding-and-modulation" title="Permalink to this headline">¶</a></h2>
<p>The mobile channel over which digital data needs to be reliably
transmitted brings a number of impairments, including noise,
attenuation, distortion, fading, and interference. This challenge is
addressed by a combination of coding and modulation, as depicted in
<a class="reference internal" href="#fig-modulation"><span class="std std-ref">Figure 2.1</span></a>.</p>
<div class="figure align-center" id="id1">
<span id="fig-modulation"></span><a class="reference internal image-reference" href="_images/Slide09.png"><img alt="_images/Slide09.png" src="_images/Slide09.png" style="width: 500px;" /></a>
<p class="caption"><span class="caption-text">Figure 2.1: The role of coding and modulation in mobile communication.</span></p>
</div>
<p>At its core, coding inserts extra bits into the data to help recover
from all the environmental factors that interfere with signal
propagation. This typically implies some form of <em>Forward Error
Correction</em> (e.g., turbo codes, polar codes). Modulation then
generates signals that represent the encoded data stream, and it does
so in a way that matches the channel characteristics: It first uses a
digital modulation signal format that maximizes the number of reliably
transmitted bits every second based on the specifics of the observed
channel impairments; it next matches the transmission
bandwidth to channel bandwidth using pulse shaping; and finally, it
uses RF modulation to transmit the signal as an electromagnetic wave
over an assigned <em>carrier frequency.</em></p>
<p>For a deeper appreciation of the challenges of reliably transmitting
data by propagating radio signals through the air, consider the
scenario depicted in <a class="reference internal" href="#fig-multipath"><span class="std std-ref">Figure 2.2</span></a>, where
the signal bounces off various stationary and moving objects,
following multiple paths from the transmitter to the receiver, who may
also be moving.</p>
<div class="figure align-center" id="id2">
<span id="fig-multipath"></span><a class="reference internal image-reference" href="_images/Slide10.png"><img alt="_images/Slide10.png" src="_images/Slide10.png" style="width: 600px;" /></a>
<p class="caption"><span class="caption-text">Figure 2.2: Signals propagate along multiple paths from
transmitter to receiver.</span></p>
</div>
<p>As a consequence of these multiple paths, the original signal arrives at
the receiver spread over time, as illustrated in
<a class="reference internal" href="#fig-coherence"><span class="std std-ref">Figure 2.3</span></a>. Empirical evidence shows that the
Multipath Spread—the time between the first and last signals of one
transmission arriving at the receiver—is 1 to 10μs in urban
environments and 10 to 30μs in suburban environments. Theoretical
bounds for the time duration for which the channel may be assumed to
be time invariant, known as the <em>Coherence Time</em> and denoted
<span class="math notranslate nohighlight">\(T_c\)</span>, is given by</p>
<div class="math notranslate nohighlight">
\[T_c =c/v \times 1/f\]</div>
<p>where <span class="math notranslate nohighlight">\(c\)</span> is the velocity of the signal, <span class="math notranslate nohighlight">\(v\)</span> is the
velocity of the receiver (e.g., moving car or train), and <span class="math notranslate nohighlight">\(f\)</span> is
the frequency of the carrier signal that is being modulated. This
says the coherence time is inversely proportional to the frequency of
the signal and the speed of movement, which makes intuitive sense: The
higher the frequency (narrower the wave) the shorter the coherence time,
and likewise, the faster the receiver is moving the longer the coherence
time. Based on the target parameters to this model (selected according
to the target physical environment), it is possible to calculate
<span class="math notranslate nohighlight">\(T_c\)</span>, which in turn bounds the rate at which symbols can be
transmitted without undue risk of interference.</p>
<div class="figure align-center" id="id3">
<span id="fig-coherence"></span><a class="reference internal image-reference" href="_images/Slide11.png"><img alt="_images/Slide11.png" src="_images/Slide11.png" style="width: 500px;" /></a>
<p class="caption"><span class="caption-text">Figure 2.3: Received data spread over time due to multipath
variation.</span></p>
</div>
<p>To complicate matters further,
<a class="reference internal" href="#fig-multipath"><span class="std std-ref">Figure 2.2</span></a> and <a class="reference internal" href="#fig-coherence"><span class="std std-ref">2.3</span></a> imply
the transmission originates from a single
antenna, but cell towers are equipped with an array of antennas, each
transmitting in a different (but overlapping) direction. This
technology, called <em>Multiple-Input-Multiple-Output (MIMO)</em>, opens the
door to purposely transmitting data from multiple antennas in an effort
to reach the receiver, adding even more paths to the environment-imposed
multipath propagation.</p>
<p>One of the most important consequences of these factors is that the
transmitter must receive feedback from every receiver to judge how to
best utilize the wireless medium on their behalf. 3GPP specifies a
<em>Channel Quality Indicator (CQI)</em> for this purpose, where in practice
the receiver sends a CQI status report to the base station periodically
(e.g., every millisecond in LTE). These CQI messages report the observed
signal-to-noise ratio, which impacts the receiver’s ability to recover
the data bits. The base station then uses this information to adapt how
it allocates the available radio spectrum to the subscribers it is
serving, as well as which coding and modulation scheme to employ.
All of these decisions are made by the scheduler.</p>
<p>How the scheduler does its job is one of the most important properties
of each generation of the cellular network, which in turn depends on the
multiplexing mechanism. For example, 2G used <em>Time Division Multiple
Access (TDMA)</em> and 3G used <em>Code Division Multiple Access (CDMA)</em>. It is
also a major differentiator for 4G and 5G, completing the transition
from the cellular network being fundamentally circuit-switched to
fundamentally packet-switched. The following two sections describe each,
in turn.</p>
</div>
<div class="section" id="scheduling-4g">
<h2>2.2 Scheduling: 4G<a class="headerlink" href="#scheduling-4g" title="Permalink to this headline">¶</a></h2>
<p>The state-of-the-art in multiplexing 4G cellular networks is called
<em>Orthogonal Frequency-Division Multiple Access (OFDMA)</em>. The idea is to
multiplex data over a set of 12 orthogonal subcarrier frequencies, each
of which is modulated independently. The “Multiple Access” in OFDMA
implies that data can simultaneously be sent on behalf of multiple
users, each on a different subcarrier frequency and for a different
duration of time. The subbands are narrow (e.g., 15kHz), but the coding
of user data into OFDMA symbols is designed to minimize the risk of data
loss due to interference between adjacent bands.</p>
<p>The use of OFDMA naturally leads to conceptualizing the radio spectrum
as a two-dimensional resource, as shown in <a class="reference internal" href="#fig-sched-grid"><span class="std std-ref">Figure 2.4</span></a>.
The minimal schedulable unit, called a <em>Resource Element (RE)</em>,
corresponds to a 15kHz-wide band around one subcarrier frequency and the
time it takes to transmit one OFDMA symbol. The number of bits that can
be encoded in each symbol depends on the modulation rate, so for example
using <em>Quadrature Amplitude Modulation (QAM)</em>, 16-QAM yields 4 bits per
symbol and 64-QAM yields 16 bits per symbol</p>
<div class="figure align-center" id="id4">
<span id="fig-sched-grid"></span><a class="reference internal image-reference" href="_images/Slide12.png"><img alt="_images/Slide12.png" src="_images/Slide12.png" style="width: 600px;" /></a>
<p class="caption"><span class="caption-text">Figure 2.4: Spectrum abstractly represented by a 2-D grid of
schedulable Resource Elements.</span></p>
</div>
<p>A scheduler allocates some number of REs to each user that has data to
transmit during each 1ms <em>Transmission Time Interval (TTI</em>, where users
are depicted by different colored blocks in <a class="reference internal" href="#fig-sched-grid"><span class="std std-ref">Figure 2.4</span></a>.
The only constraint on the scheduler is that it must make its allocation
decisions on blocks of 7x12=84 resource elements, called a <em>Physical
Resource Block (PRB)</em>. <a class="reference internal" href="#fig-sched-grid"><span class="std std-ref">Figure 2.4</span></a> shows two
back-to-back PRBs. Of course time continues to flow along one axis, and
depending on the size of the available frequency band (e.g., it might be
100MHz wide), there may be many more subcarrier slots (and hence PRBs)
available along the other axis, so the scheduler is essentially
preparing and transmitting a sequence of PRBs.</p>
<p>Note that OFDMA is not a coding/modulation algorithm, but instead
provides a framework for selecting a specific coding and modulator for
each subcarrier frequency. QAM is one common example modulator. It is
the scheduler’s responsibility to select the modulation to use for each
PRB, based on the CQI feedback it has received. The scheduler also
selects the coding on a per-PRB basis, for example, by how it sets the
parameters to the turbo code algorithm.</p>
<p>The 1ms TTI corresponds to the time frame in which the scheduler
receives feedback from users about the quality of the signal they are
experiencing. This is the CQI mentioned earlier, where once every
millisecond, each user sends a set of metrics, which the scheduler uses
to make its decision as to how to allocate PRBs during the subsequent
TTI.</p>
<p>Another input to the scheduling decision is the <em>QoS Class Identifier
(QCI)</em>, which indicates the quality-of-service each class of traffic is
to receive. In 4G, the QCI value assigned to each class (there are nine
such classes, in total) indicates whether the traffic has a <em>Guaranteed
Bit Rate (GBR)</em> or not <em>(non-GBR)</em>, plus the class’s relative priority
within those two categories.</p>
<p>Finally, keep in mind that <a class="reference internal" href="#fig-sched-grid"><span class="std std-ref">Figure 2.4</span></a> focuses on
scheduling transmissions from a single antenna, but the MIMO technology
described above means the scheduler also has to determine which antenna
(or more generally, what subset of antennas) will most effectively reach
each receiver. But again, in the abstract, the scheduler is charged with
allocating a sequence of Resource Elements.</p>
<p>This all begs the question: How does the scheduler decide which set of
users to service during a given time interval, how many resource
elements to allocate to each such user, how to select the coding and
modulation levels, and which antenna to transmit their data on? This is
an optimization problem that, fortunately, we are not trying to solve
here. Our goal is to describe an architecture that allows someone else
to design and plug in an effective scheduler. Keeping the cellular
architecture open to innovations like this is one of our goals, and as
we will see in the next section, becomes even more important in 5G where
the scheduler operates with even more degrees of freedom.</p>
</div>
<div class="section" id="scheduling-5g">
<h2>2.3 Scheduling: 5G<a class="headerlink" href="#scheduling-5g" title="Permalink to this headline">¶</a></h2>
<p>The transition from 4G to 5G introduces additional degrees-of-freedom in
how the radio spectrum is scheduled, making it possible to adapt the
cellular network to a more diverse set of devices and applications
domains.</p>
<p>Fundamentally, 5G defines a family of waveforms—unlike LTE, which
specified only one waveform—each optimized for a different band in the
radio spectrum. The bands with carrier frequencies below 1GHz are
designed to deliver mobile broadband and massive IoT services with a
primary focus on range. Carrier frequencies between 1GHz-6GHz are
designed to offer wider bandwidths, focusing on mobile broadband and
mission-critical applications. Carrier frequencies above 24GHz
(mmWaves) are designed to provide super wide bandwidths over short,
line-of-sight coverage.</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">A waveform is the frequency, amplitude, and phase-shift independent
property (shape) of a signal. A sine wave is an example waveform.</p>
</div>
<p>These different waveforms affect the scheduling and subcarrier intervals
(i.e., the “size” of the resource elements described in the previous
section).</p>
<ul class="simple">
<li>For sub-1GHz bands, 5G allows maximum 50MHz bandwidths. In this case,
there are two waveforms: one with subcarrier spacing of 15kHz and
another of 30kHz. (We used 15kHz in the example shown in
<a class="reference internal" href="#fig-sched-grid"><span class="std std-ref">Figure 2.4</span></a>.)
The corresponding scheduling intervals are
0.5ms and 0.25ms, respectively. (We used 0.5ms in the example shown
in <a class="reference internal" href="#fig-sched-grid"><span class="std std-ref">Figure 2.4</span></a>.)</li>
<li>For 1GHz-6GHz bands, maximum bandwidths go up to 100MHz.
Correspondingly, there are three waveforms with subcarrier spacings
of 15kHz, 30kHz and 60kHz, corresponding to scheduling intervals of
0.5ms, 0.25ms and 0.125ms, respectively.</li>
<li>For millimeter bands, bandwidths may go up to 400MHz. There are two
waveforms, with subcarrier spacings of 60kHz and 120kHz. Both have
scheduling intervals of 0.125ms.</li>
</ul>
<p>This range of options is important because it adds another degree of
freedom to the scheduler. In addition to allocating radio resources to
users, it has the ability to dynamically adjust the size of the resource
by changing the wave form being used. With this additional freedom,
fixed-sized REs are no longer the primary unit of resource allocation.
We instead use more abstract terminology, and talk about allocating
<em>Resource Blocks</em> to subscribers, where the 5G scheduler determines both
the size and number of Resource Blocks allocated during each time
interval.</p>
<p><a class="reference internal" href="#fig-scheduler"><span class="std std-ref">Figure 2.5</span></a> depicts the role of the scheduler
from this more abstract perspective, where just as with 4G, CQI
feedback from the receivers and the QCI quality-of-service class
selected by the subscriber are the two key pieces of input to the
scheduler. Note that the set of QCI values changes between 4G and 5G,
reflecting the increasing differentiation being supported. For 5G,
each class includes the following attributes:</p>
<ul class="simple">
<li>Resource Type: Guaranteed Bit Rate (GBR), Delay-Critical GBR, Non-GBR</li>
<li>Priority Level</li>
<li>Packet Delay Budget</li>
<li>Packet Error Rate</li>
<li>Averaging Window</li>
<li>Maximum Data Burst</li>
</ul>
<p>Note that while the preceding discussion could be interpreted to imply a
one-to-one relationship between subscribers and a QCI, it is more
accurate to say that each QCI is associated with a class of traffic
(often corresponding to some type of application), where a given
subscriber might be sending and receiving traffic that belongs to
multiple classes at any given time. We explore this idea in much more
depth in a later chapter.</p>
<div class="figure align-center" id="id5">
<span id="fig-scheduler"></span><a class="reference internal image-reference" href="_images/Slide13.png"><img alt="_images/Slide13.png" src="_images/Slide13.png" style="width: 600px;" /></a>
<p class="caption"><span class="caption-text">Figure 2.5: Scheduler allocates Resource Elements to user data
streams based on CQI feedback from receivers and the QCI
parameters associated with each class of service.</span></p>
</div>
</div>
</div>
</div>
</div>
<footer>
<div class="rst-footer-buttons" role="navigation" aria-label="footer navigation">
<a href="arch.html" class="btn btn-neutral float-right" title="Chapter 3: Basic Architecture" accesskey="n" rel="next">Next <span class="fa fa-arrow-circle-right"></span></a>
<a href="intro.html" class="btn btn-neutral float-left" title="Chapter 1: Introduction" 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>