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
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html >
<head><title>Anatomy of contemporary GSM cellphone hardware</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="generator" content="TeX4ht (http://www.cse.ohio-state.edu/~gurari/TeX4ht/)">
<meta name="originator" content="TeX4ht (http://www.cse.ohio-state.edu/~gurari/TeX4ht/)">
<!-- html -->
<meta name="src" content="gsm_phone-anatomy-v0.2.tex">
<meta name="date" content="2010-04-14 12:26:00">
<link rel="stylesheet" type="text/css" href="gsm_phone-anatomy-v0.2.css">
</head><body
>
<div class="maketitle">
<h2 class="titleHead">Anatomy of contemporary GSM cellphone hardware</h2>
<div class="author" ><span
class="cmr-12">Harald Welte </span><span
class="cmmi-12"><</span><span
class="cmr-12">laforge@gnumonks.org</span><span
class="cmmi-12">></span></div>
<br />
<div class="date" ><span
class="cmr-12">April 14, 2010</span></div>
</div>
<div
class="abstract"
>
<div class="center"
>
<!--l. 25--><p class="noindent" >
<!--l. 25--><p class="noindent" ><span
class="cmbx-9">Abstract</span></div>
<!--l. 27--><p class="indent" > <span
class="cmr-9">Billions of cell phones are being used every day by an almost equally large number of users. The</span>
<span
class="cmr-9">majority of those phones are built according to the GSM protocol and interoperate with GSM networks</span>
<span
class="cmr-9">of hundreds of carriers.</span>
<!--l. 32--><p class="indent" > <span
class="cmr-9">Despite being an openly published international standard, the architecture of the GSM network and</span>
<span
class="cmr-9">its associated protocols are only known to a relatively small group of R&D engineers.</span>
<!--l. 36--><p class="indent" > <span
class="cmr-9">Even less public information exists about the hardware architecture of the actual mobile phones</span>
<span
class="cmr-9">themselves, at least as far as it relates to that part of the phone implementing the GSM protocols and</span>
<span
class="cmr-9">facilitating access to the public GSM networks.</span>
<!--l. 41--><p class="indent" > <span
class="cmr-9">This paper is an attempt to serve as an introductory text into the hardware architecture of</span>
<span
class="cmr-9">contemporary GSM mobile phone hardware anatomy. It is intended to widen the technical background</span>
<span
class="cmr-9">on mobile phones within the IT community.</span>
</div>
<h3 class="sectionHead"><span class="titlemark">1 </span> <a
id="x1-10001"></a>Foreword</h3>
<!--l. 50--><p class="noindent" >This document is the result of my personal research on mobile phone hardware and system-level software
throughout the last 6+ years.
<!--l. 53--><p class="indent" > Despite my past work for Openmoko Inc., I have never been professionally involved in any aspect of the actual
GSM related hardware of any phone. Nevertheless I have the feeling that in the wider information technology
industry, I am part of a very, very small group of people who actually understand mobile phones down to the lowest
layer.
<!--l. 59--><p class="indent" > I hope it is useful for any systems level engineer with an interest in understanding more about how mobile phone
hardware actually works.
<!--l. 62--><p class="indent" > There are no guarantees for accuracy or correctness of any part of the document. I happily receive your feedback
and corrections.
<!--l. 65--><p class="noindent" >
<h3 class="sectionHead"><span class="titlemark">2 </span> <a
id="x1-20002"></a>Is your phone smart or does it have features?</h3>
<!--l. 67--><p class="noindent" >Initially, for the first couple of years, GSM cell phones were actual phones with very little additional functionality.
They provided everything that was required for voice calls, as well as SIM phone book editing features.
The only additional non-features were simple improvements like the ability to use them as an alarm
clock.
<!--l. 73--><p class="indent" > In the mid-1990s, a certain new type of devices became popular: The PDA (personal digital assistant). They
pioneered handheld computing by introducing touch screen user interfaces and a wide range of application
programs, ranging from calendar/scheduling applications, dictionaries, exchange rate and tip calculators, scientific
calculators, accounting / finance software, etc.
<!--l. 79--><p class="indent" > While in mobile phones the actual cellphone aspect was becoming more and more commoditized, at some point
the PDA features and functionalities were added to phones, coining the term <span
class="cmti-10">smartphone</span>. At that point there was a
need to differentiate from those phones that were not-so-smart. Those phones were then called <span
class="cmti-10">feature</span>
<span
class="cmti-10">phones</span>.
<!--l. 85--><p class="indent" > There has never been an industry-wide accepted definition of those terms, and especially in the late
2000s, feature phones started to inherit a lot of the functionality that was formerly only present in
smartphones.
<!--l. 89--><p class="indent" > This document will define the terms (only for the purpose of this document) along a very clear border in
hardware architecture, as will be described in the following sections:
<!--l. 93--><p class="noindent" >
<h4 class="subsectionHead"><span class="titlemark">2.1 </span> <a
id="x1-30002.1"></a>Feature Phone</h4>
<!--l. 95--><p class="noindent" >A feature phone is a phone that runs the GSM protocol stack (the software implementing the GSM protocol) as well
as the user interface and all applications on a single processor. For historic reasons, this processor is known as the
so-called <span
class="cmti-10">baseband processor </span>(BP).
<!--l. 100--><p class="indent" > The baseband processor often exposes a serial port (or today USB) over which the phone can be
used as a terminal adapter, similar to old wireline modems. The industry standard protocol for this
interface is an AT command set - extended and modified from how computers interfaced old wireline
modems. The AT-command interface can be connected to a computer. The computer can then use the
phone to establish data calls, send/receive short messages via SMS, and generally remote-control the
phone.
<!--l. 108--><p class="noindent" >
<h4 class="subsectionHead"><span class="titlemark">2.2 </span> <a
id="x1-40002.2"></a>Smartphone</h4>
<!--l. 110--><p class="noindent" >A smartphone is a phone that has a dedicated processor for the GSM protocol stack, and another (potentially
multi-core) general purpose processor for the user interface and applications. This processor is known as the
<span
class="cmti-10">application processor </span>(AP).
<!--l. 115--><p class="indent" > The first hardware generations of smartphones did nothing else but to put the feature phone and a PDA into one
case. The keypad and display of the baseband processor is removed. What remains of the feature phone is a <span
class="cmti-10">GSM</span>
<span
class="cmti-10">modem</span>, controlled by AT commands sent from the AP.
<!--l. 120--><p class="indent" > Each processor has its own memory (RAM and Flash), peripherals, clocking, etc. So this setup
is not to be confused with the symmetric multi-processor setups like seen in the personal computer
industry.
<!--l. 124--><p class="indent" > Later generations of smartphones have exchanged the AT command interface by various proprietary protocols.
Also, the serial line was replaced by a higher-bandwidth hardware connection such as USB, SPI or a shared memory
interface.
<!--l. 129--><p class="indent" > Due to market pressure for ever smaller phones with ever more functions, the industry has produced highly
integrated products, uniting the AP and BP inside one physical package. Further pressure on reducing cost and
PCB footprint has led to products where there is no need to have independent RAM and Flash chips for AP and
BP. Rather, a single RAM and Flash chip is divided by assigning portions of the RAM and Flash to each of the two
processors.
<!--l. 137--><p class="indent" > However, the fundamental separation between the AP and BP, each with their own memory address space and
software, remains present in all smartphones until today.
<!--l. 141--><p class="noindent" >
<h3 class="sectionHead"><span class="titlemark">3 </span> <a
id="x1-50003"></a>GSM modem architecture</h3>
<!--l. 143--><p class="noindent" >Every GSM phone, feature phone and smartphone alike, has a GSM modem interfacing with the GSM
network.
<!--l. 146--><p class="indent" > This GSM modem consists of several parts:
<ul class="itemize1">
<li class="itemize">RF Frontend, responsible for receiving and transmitting at GSM frequency
</li>
<li class="itemize">Analog Baseband, responsible for modulation and demodulation
</li>
<li class="itemize">Digital Baseband, responsible for digital signal processing and the GSM protocol stack</li></ul>
<!--l. 153--><p class="indent" > <hr class="figure"><div class="figure"
>
<a
id="x1-50011"></a>
<!--l. 155--><p class="noindent" ><img
src="gsm_phone-anatomy-v0.20x.png" alt="PIC" class="graphics"><!--tex4ht:graphics
name="gsm_phone-anatomy-v0.20x.png" src="calypso-block.pdf"
-->
<br /> <div class="caption"
><span class="id">Figure 1: </span><span
class="content">Block schematics of a TI Calypso/Iota/Rita GSM modem</span></div><!--tex4ht:label?: x1-50011 -->
<!--l. 158--><p class="indent" > </div><hr class="endfigure">
<h4 class="subsectionHead"><span class="titlemark">3.1 </span> <a
id="x1-60003.1"></a>The RF Frontend</h4>
<!--l. 162--><p class="noindent" >The RF Frontend is tasked with the physical receive and transmit interface with the GSM air interface (sometimes
called Um interface).
<!--l. 165--><p class="indent" > It minimally consists of an antenna switch, GSM band filters, low-noise amplifier (LNA) for the receive path,
power amplifier for the transmit path, a local oscillator (LO) and a mixer.
<!--l. 169--><p class="indent" > By mixing the LO frequency with the received RF signal, it generates an analog baseband signal that is passed
to the Analog Baseband (ABB) part of the modem. By mixing the output of the ABB with the LO frequency, it
generates a RF signal that is to be transmitted in the GSM frequency band.
<!--l. 175--><p class="indent" > As the receive and transmit framing has an offset of 3 TDMA frames, there is no need for a frequency duplexer.
Instead, an antenna switch is used. The switch typically is implemented using a MEMS or diode switch. For a
quad-band phone, typically a SP
<!--l. 180--><p class="noindent" >
<h5 class="subsubsectionHead"><span class="titlemark">3.1.1 </span> <a
id="x1-70003.1.1"></a>RF Frontend receive path</h5>
<!--l. 182--><p class="noindent" >The antenna picks up the GSM radio signal as it is sent from a GSM cell (called Base Transceiver Station, BTS).
The antenna signal first hits the antenna switch, which connects the antenna with the Rx path for the GSM band of
the to-be-received radio frequency. It is then filtered by a bandpass to block out-of-band signals before entering a
low-noise amplifier for increasing signal amplitude.
<!--l. 189--><p class="indent" > After passing the LNA, the RF signal is mixed with a frequency generated by the LO. Depending on the
LO signal, either an intermediate frequency (IF) or a direct baseband signal is produced. In modern
GSM modems, zero-IF designs with immediate down-conversion to analog baseband signals are most
common.
<!--l. 195--><p class="indent" > The baseband signal is then filtered to remove unwanted images and sent as analog I/Q signals (representing
amplitude and phase) to the ABB.
<!--l. 198--><p class="noindent" >
<h5 class="subsubsectionHead"><span class="titlemark">3.1.2 </span> <a
id="x1-80003.1.2"></a>RF Frontend transmit path</h5>
<!--l. 200--><p class="noindent" >The ABB generates analog I/Q signals, which are filtered and passed into the mixer, where they are mixed with the
LO frequency and thus up-converted to the GSM RF band. From there, they are sent to the transmit amplifier (RF
PA) for amplification. After amplification, they traverse the antenna switch and are transmitted by the
antenna.
<!--l. 206--><p class="noindent" >
<h5 class="subsubsectionHead"><span class="titlemark">3.1.3 </span> <a
id="x1-90003.1.3"></a>Local Oscillator</h5>
<!--l. 208--><p class="noindent" >The LO of a GSM modem has to be synchronized very closely to that of the cell (BTS). To achieve the
required precision, a Voltage-Controlled, Temperature-Compensated Crystal Oscillator (VCTCXO) is
used.
<!--l. 212--><p class="indent" > Common frequencies for this VCTCXO are 26MHz or 13MHz, as the GSM bit clock (270,833 Hz) is an integral
division (/96 or /48, respectively) of those frequencies. The tuning range of the VCTCXO is several kHz to
compensate for temperature drift.
<!--l. 217--><p class="noindent" >
<h4 class="subsectionHead"><span class="titlemark">3.2 </span> <a
id="x1-100003.2"></a>The Analog Baseband (ABB)</h4>
<!--l. 219--><p class="noindent" >The ABB part of a GSM modem is responsible to interface between the digital domain and the analog domain of
the GSM modem.
<!--l. 222--><p class="noindent" >
<h5 class="subsubsectionHead"><span class="titlemark">3.2.1 </span> <a
id="x1-110003.2.1"></a>ABB Receive path</h5>
<!--l. 224--><p class="noindent" >The analog baseband I/Q signals are potentially filtered again and digitized by and Analog-Digital converter
(ADC). The sample clocks used are typically integral multiples of the GSM bit-clock. The sample clock itself is
derived by dividing the VCTCXO of the RF frontend.
<!--l. 229--><p class="indent" > The digital I/Q samples are passed to the Digital Signal Processor (DSP) in the Digital Baseband (DBB). To
reduce the number of traces to be routed on the PCB, the samples are typically sent over some kind of synchronous
serial link.
<!--l. 234--><p class="noindent" >
<h5 class="subsubsectionHead"><span class="titlemark">3.2.2 </span> <a
id="x1-120003.2.2"></a>ABB Transmit path</h5>
<!--l. 236--><p class="noindent" >There are multiple architectures found in the ABB transmit path.
<!--l. 238--><p class="indent" > The obvious architecture is to do the inverse of the receive operation: Transmit digital I/Q samples from the
DSP to the ABB and convert them into an analog signal that is then to be sent to the mixer of the RF
Frontend.
<!--l. 243--><p class="indent" > However, sending a GSM signal with its GMSK modulation is much simpler than receiving. So in order to reduce
computational complexity (and thus cost as well as power consumption) inside the DSP, the modulation of the bits
is often performed in hardware inside the ABB.
<!--l. 248--><p class="indent" > In this design, the unmodulated GSM burst bits are sent from the DBB to a burst buffer inside the ABB. From
there, based on ROM tables and a Digital-to-Analog converter (DAC), an analog GMSK modulated signal is
generated.
<!--l. 253--><p class="noindent" >
<h4 class="subsectionHead"><span class="titlemark">3.3 </span> <a
id="x1-130003.3"></a>The Digital Baseband (DBB)</h4>
<!--l. 255--><p class="noindent" >The digital baseband implements the actual GSM protocols from Layer1 up to Layer3 as well as higher layers such
as a user interface in the case of the feature phone. In a smartphone, the DBB only implements a machine interface
to be used by the AP.
<!--l. 260--><p class="indent" > A typical DBB design includes a Digital Signal Processor (DSP) for the lower half of Layer1, and a
general-purpose processor (MCU) for the upper part of Layer1, as well as anything above.
<!--l. 264--><p class="noindent" >
<h5 class="subsubsectionHead"><span class="titlemark">3.3.1 </span> <a
id="x1-140003.3.1"></a>Digital Signal Processor</h5>
<!--l. 266--><p class="noindent" >The choice of DSP architecture largely depends on the DBB chipset vendor. Often they already have a line of DSP
cores in-house and will of course want to reuse that in their DBB chip designs. Every major DSP architecture can be
found (TI, Analog Devices, ...).
<!--l. 271--><p class="indent" > The DSP performs the primary tasks such as Viterbi equalization, demodulation, decoding, forward error
correction, error detection, burst (de)interleaving.
<!--l. 275--><p class="indent" > Of course, if actual speech data is to be communicated over the GSM network, the DSP will also
have the auxiliary task to perform the computation of the lossy speech codec used to compress the
speech.
<!--l. 279--><p class="indent" > Communication between the DSP and MCU happens most commonly by a shared memory interface. The shared
memory contains both actual data that is to be processed, as well as control information and parameters describing
what to be done with the respective data.
<!--l. 284--><p class="indent" > For the receive side, the MCU will instruct the DSP to perform decoding for a particular GSM burst type, after
which the DSP will receive I/Q samples from the ABB, perform detection/demodulation/decoding and report the
result of the operation (including any decoded data) back to the MCU.
<!--l. 290--><p class="indent" > For the transmit path, the MCU will present the to-be-transmitted data and auxiliary information to the DSP,
which then takes care of encoding and sends the corresponding burst bits to the ABB (remember, most ABB take
care of the modulation to reduce DSP load).
<!--l. 295--><p class="indent" > The detailed programming information (API) of the DSP shared memory interface is a closely-guarded secret of
the baseband chip maker and is not commonly disclosed even to their customers (the actual phone making
companies).
<!--l. 300--><p class="indent" > In doing so, the baseband chip makers create a close dependency between the GSM Layer1 software (running on
the MCU) driving/implementing this API and the actual baseband chip. Whoever buys their chip will also have to
license their GSM protocol stack software.
<!--l. 305--><p class="indent" > It is thus almost impossible for an independent software vendor to get access to the DSP API documentation,
which the author of this paper finds extremely anti-competitive.
<!--l. 309--><p class="noindent" >
<h5 class="subsubsectionHead"><span class="titlemark">3.3.2 </span> <a
id="x1-150003.3.2"></a>DSP Peripherals</h5>
<!--l. 311--><p class="noindent" >The specifications of the GSM proprietary On-air encryption A5/1 and A5/2 are only made available to GSM
baseband chip makers who declare their confidentiality. Implementing the algorithm in software is apparently
considered as breach of that confidentiality. Thus, the encryption algorithms are only implemented in
hardware - despite them being reverse-engineered and publicly disclosed by cryptographers as early as
1996.
<!--l. 319--><p class="indent" > Thus, the DSP in a DBB commonly has a integrated peripheral implementing the A5 encryption.
<!--l. 322--><p class="indent" > Further integrated DSP peripherals may include a viterbi hardware accelerator, a DMA capable serial interface
to the ABB and others.
<!--l. 325--><p class="noindent" >
<h4 class="subsectionHead"><span class="titlemark">3.4 </span> <a
id="x1-160003.4"></a>Baseband Processor (MCU)</h4>
<!--l. 327--><p class="noindent" >The MCU of almost all modern GSM DBBs is a System-on-a-Chip (SoC) utilizing a 32bit ARM7TDMI core. The
only notable exception are low-cost Infineon chips like PM7870, who still use a version of their 16bit C166
core.
<!--l. 331--><p class="indent" > Baseband chips that support 3G cellular networks often use a more powerful ARM926 or ARM975 core as
MCU.
<!--l. 334--><p class="noindent" >
<h4 class="subsectionHead"><span class="titlemark">3.5 </span> <a
id="x1-170003.5"></a>MCU peripherals</h4>
<!--l. 336--><p class="noindent" >The MCU cores have the typical set of peripherals of any ARM7 based microcontroller, such as RTC,
UARTs for RS232 and IRDA, SPI, I2C, SD/MMC card controller, keypad scan controller, USB device,
...
<!--l. 340--><p class="indent" > However, there are some additional peripherals that are very GSM specific:
<ul class="itemize1">
<li class="itemize">A GPRS crypto unit for the proprietary GEA family of ciphers
</li>
<li class="itemize">Extended power management facilities, including a timer that can calibrate the RTC clock based on
the synchronized VCTCXO in order to wake-up the MCU ahead of pre-programmed events in the GSM
time multiplex
</li>
<li class="itemize">GSM TDMA timers that can synchronize to the on-air time frames and generate interrupts to MCU
and DSP
</li>
<li class="itemize">Software-programmable hardware state machines for sequencing GSM burst Rx or Tx in ABB and RF
Frontend
</li>
<li class="itemize">An ISO7816 compatible smart card reader interface for the SIM card</li></ul>
<!--l. 349--><p class="indent" > The programming of those peripherals is highly device-specific and there are no industry standards. Every DBB
architecture of every supplier has its own custom register set and programming interface.
<!--l. 353--><p class="indent" > The register-level documentation for those proprietary peripherals is (like all documentation on DBB chipsets)
closely guarded by NDAs, effectively preventing the development of Free Software / Open Source drivers for them,
unless such documents are leaked by third parties.
<!--l. 358--><p class="indent" > However, as opposed to the DSP API documentation, the register-level documentation to the MCU peripherals
is normally provided to the cellphone manufacturers.
<!--l. 362--><p class="noindent" >
<h3 class="sectionHead"><span class="titlemark">4 </span> <a
id="x1-180004"></a>Digital Baseband Software Architecture</h3>
<!--l. 364--><p class="noindent" >This section provides an introductory reading in the typical software architecture as it is found on contemporary
GSM digital baseband designs.
<!--l. 367--><p class="noindent" >
<h4 class="subsectionHead"><span class="titlemark">4.1 </span> <a
id="x1-190004.1"></a>GSM Layer 1</h4>
<!--l. 369--><p class="noindent" >The Layer1 (L1) software is highly device-specific, as it closely interacts with the DSP using the shared memory
DSP API, as well as the proprietary integrated peripherals controlling the ABB and RF Frontend.
<!--l. 373--><p class="indent" > However, there are some general observations that can be made about the L1:
<!--l. 375--><p class="noindent" >
<h5 class="subsubsectionHead"><span class="titlemark">4.1.1 </span> <a
id="x1-200004.1.1"></a>L1 Synchronous part</h5>
<!--l. 377--><p class="noindent" >The synchronous part is executed synchronously to the GSM TDMA frame clock. Both CPU and DSP are
interrupted by some hardware GSM timer every TDMA frame.
<!--l. 380--><p class="indent" > The L1 synchronous part typically runs inside IRQ or FIQ context of the MCU, taking care of retrieving data
from and providing data to the DSP API.
<!--l. 383--><p class="noindent" >
<h5 class="subsubsectionHead"><span class="titlemark">4.1.2 </span> <a
id="x1-210004.1.2"></a>L1 Asynchronous part</h5>
<!--l. 385--><p class="noindent" >The asynchronous part is scheduled as a normal task, potentially with high or even real-time priority. It picks up the
information provided by the L1 Sync and schedules its next actions.
<!--l. 389--><p class="indent" > The L1 async typically communicates via a message queue with the Layer2 above. Common primitives for L1
control are described (as non-normative parts) of the GSM specifications.
<!--l. 393--><p class="noindent" >
<h4 class="subsectionHead"><span class="titlemark">4.2 </span> <a
id="x1-220004.2"></a>GSM Layer 2</h4>
<!--l. 395--><p class="noindent" >As opposed to L1, the GSM Layer 2 (L2) is already fully hardware independent. It implements the LAPDm protocol
as specified in GSM TS 04.06. LAPDm is a derivative of the ISDN Layer 2 called LAPD, which in turn is a
descendent of the HDLC family of protocols.
<!--l. 400--><p class="indent" > LAPDm takes care of providing communication channels for Layer3. Those channels are protected from frame
loss by the use of sequence numbers and retransmissions.
<!--l. 404--><p class="indent" > The interface to Layer3 is typically implemented by means of a message queue.
<!--l. 406--><p class="indent" > Primitives (but no detailed protocol) for use of the Layer2 / Layer3 interface are provided in the GSM
specifications.
<!--l. 409--><p class="noindent" >
<h4 class="subsectionHead"><span class="titlemark">4.3 </span> <a
id="x1-230004.3"></a>GSM Layer 3</h4>
<!--l. 411--><p class="noindent" >GSM Layer 3 (L3) consist of sublayers for Radio Resource (RR), Mobility Management (MM) and Call Control
(CC).
<!--l. 414--><p class="indent" > There is sufficient treatment of the GSM L3 and its sublayers in existing texts, so there is no point in making a
futile attempt repeating that here.
<!--l. 418--><p class="noindent" >
<h3 class="sectionHead"><span class="titlemark">5 </span> <a
id="x1-240005"></a>Synchronization and Clocking</h3>
<!--l. 420--><p class="noindent" >The author of this paper has been quoted saying <span
class="cmti-10">GSM is a synchronous TDMA nightmare</span>. This is by no means
intended as an insult to the technology itself or to its inventors. It merely serves as evidence how hard it is to get
into the synchronous TDMA mindset, especially for engineers who have spent most of their career in the world of
packet switched networks.
<!--l. 427--><p class="indent" > GSM is synchronous in multiple ways between cell (BTS) and phone (MS):
<ul class="itemize1">
<li class="itemize">Synchronization of the carrier clock to tune the receiver and transmitter to the correct frequency
</li>
<li class="itemize">Synchronization of the bit clock in order to perform sampling at the most optimal sample intervals
</li>
<li class="itemize">Synchronization of the frame clock (and thus timeslots) to know when a TDMA frame and its 8
timeslots start
</li>
<li class="itemize">Synchronization of the TDMA multiplex to correctly (de)multiplex the logical channels that are sent
over each timeslots</li></ul>
<!--l. 435--><p class="indent" > As all those clocks are related to each other, they can (and should) all be derived from the same master clock:
The VCTCXO in our phone.
<!--l. 438--><p class="noindent" >
<h4 class="subsectionHead"><span class="titlemark">5.1 </span> <a
id="x1-250005.1"></a>How to synchronize the VCTCXO</h4>
<!--l. 440--><p class="noindent" >Every cell sends frequency correction bursts as part of the Frequency Correction CHannel (FCCH), which is itself
part of the BCCH, which in turn is constantly transmitted by the BTS.
<!--l. 444--><p class="indent" > To acquire initial synchronization ot the GSM network, the LO is tuned to the desired GSM RF channel
(ARFCN) frequency. However, at this point, the LO frequency is a multiple of the VCTCXO frequency which in
turn still has an undetermined error. This initial frequency error is as large as that of a regular crystal oscillator,
potentially already with temperature compensation.
<!--l. 450--><p class="indent" > The resulting baseband signal thus can be shifted by a fairly large amount in our baseband spectrum. A specific
DSP code is now using correlation and other techniques to identify the frequency correction burst. The DSP can
then further calculate the actual frequency error of the LO by comparing the received FCCH burst with the FCCH
burst as specified.
<!--l. 456--><p class="indent" > This computed frequency error can be fed into a (software) frequency control loop filter. The loop filter output is
applied to an auxiliary DAC, which generates the control voltage for the VCTCXO.
<!--l. 460--><p class="indent" > After a number of FCCH bursts and corresponding frequency control loop iterations, the VCTCXO generated
clock has only a residual error. Whenever the phone is receiving, the frequency control loop is continuously exercised
in order to maintain synchronization.
<!--l. 465--><p class="noindent" >
<h4 class="subsectionHead"><span class="titlemark">5.2 </span> <a
id="x1-260005.2"></a>How to synchronize the frame clock</h4>
<!--l. 467--><p class="noindent" >When the DSP performs FCCH burst detection as described above, it identifies the exact position in the incoming
sample stream when the FCCH burst was happening. By knowing from the specification that the FCCH burst is
part of the BCCH, and that the BCCH is sent on timeslot 0, the Layer1 software can then synchronize the phone to
the TDMA frame start.
<!--l. 473--><p class="indent" > Commonly, a hardware timer unit is clocked by a (divided) VCTCXO clock and thus counts in multiples of the
GSM bit clock, wrapping/resetting at the TDMA duration of 1250 bits.
<!--l. 477--><p class="indent" > By scheduling events synchronously to this GSM bit-clock timer, the L1 can now trigger events (such
as asking the DSP to demodulate incoming data) or instructing the LO to retune synchronously to
every TDMA frame. From this timer the DBB typically also generates interrupts to the DSP and
MCU.
<!--l. 482--><p class="noindent" >
<h4 class="subsectionHead"><span class="titlemark">5.3 </span> <a
id="x1-270005.3"></a>How to synchronize the GSM TDMA multiplex</h4>
<!--l. 484--><p class="noindent" >As part of the BCCH, the BTS not only sends the FCCH but also the Synchronization CHannel (SCH). The
Synchronization channel indicates the current GSM time / frame number (skipping the 3 least significant bits). By
using this received GSM time and incrementing it every time the GSM bit-clock timer wraps at the beginning of a
new TDMA frame, the GSM time is synchronized.
<!--l. 490--><p class="indent" > Understanding the multiple layers of time multiplex such as the 26/51 multiframe, superframe and hyperframe,
the L1 can multiplex and demultiplex all the logical channels of GSM.
<!--l. 494--><p class="noindent" >
<h3 class="sectionHead"><span class="titlemark">6 </span> <a
id="x1-280006"></a>Miscellaneous Topics</h3>
<!--l. 495--><p class="noindent" >
<h4 class="subsectionHead"><span class="titlemark">6.1 </span> <a
id="x1-290006.1"></a>GPRS</h4>
<!--l. 497--><p class="noindent" >GPRS was the first packet switched extension to GSM. In fact, it is much more its entirely own mobile network,
independent of GSM. The only parts shared are the GSM modulation scheme (GMSK) and time multiplex, in order
to ensure peaceful coexistence between them.
<!--l. 502--><p class="indent" > The L1 and L2 protocols are very different (and much more complex) than GSM.
<!--l. 504--><p class="indent" > So while the phone baseband hardware did not need any modifications for a basic GPRS enabled phone, the
software needed to be extended quite a lot.
<!--l. 507--><p class="noindent" >
<h4 class="subsectionHead"><span class="titlemark">6.2 </span> <a
id="x1-300006.2"></a>EDGE</h4>
<!--l. 509--><p class="noindent" >EDGE is a very small incremental step to GPRS. It reuses all of the time multiplex and protocol stack, but
introduces a new modulation: Offset 8-PSK instead of GMSK to increase the bandwidth that can be
transmitted. Offset 8-PSK is used (as opposed to simple 8-PSK) to avoid zero-crossings in the modulator
output.
<!--l. 515--><p class="indent" > So while the software modifications from GPRS to EDGE are minimal, the 8PSK modulation scheme has a
significant impact on the DSP, ABB and even RF PA design.
<!--l. 519--><p class="noindent" >
<h4 class="subsectionHead"><span class="titlemark">6.3 </span> <a
id="x1-310006.3"></a>UMTS</h4>
<!--l. 521--><p class="noindent" >UMTS (sometimes called WCDMA) is an entirely separate cellular network technology. Its physical
layer, modulation schemes, encoding, frequency bands, channel spacing are entirely different, as is the
Layer1.
<!--l. 525--><p class="indent" > UMTS Layer2 has some resemblance to the GPRS Layer2.
<!--l. 527--><p class="indent" > UMTS Layer3 for Mobility Management and Call Control are very similar to GSM.
<!--l. 529--><p class="indent" > Given the vast physical layer and L1 differences, a UMTS phone hardware design significantly differs from what
has been described in this document.
<!--l. 532--><p class="indent" > Notwithstanding, all known commercial UMTS phone chipsets as of today still include a full GSM modem in
hardware and software to remain backwards-compatible.
<!--l. 536--><p class="noindent" >
<h4 class="subsectionHead"><span class="titlemark">6.4 </span> <a
id="x1-320006.4"></a>Dual-SIM and Triple-SIM phones</h4>
<!--l. 538--><p class="noindent" >In recent years, a large number of so-called <span
class="cmti-10">Dual-SIM </span>or even <span
class="cmti-10">Triple-SIM </span>phones have entered the market,
particularly in China and other parts of East Asia.
<!--l. 542--><p class="indent" > Those phones come in various flavours. Some of them simply have a multiplexer that allows electrical switching
between multiple SIM card slots. This is similar to replacing the SIM card in a phone, just without the manual
process of mechanically removing/inserting the card. As a result, you can only use one of the two SIMs at any
time.
<!--l. 548--><p class="indent" > The more sophisticated Dual-SIM phones have two complete phones in one case. Yes, that’s right! They contain
two full GSM phone chipsets, i.e. 2 antennas, 2 rf frontends, 2 analog basebands, 2 digital basebands,
...
<!--l. 552--><p class="indent" > However, they use the same trick as smartphones: One of the two basebands does not have keypad or display and
is simply a GSM modem connected via serial line to the other baseband processor.
<!--l. 556--><p class="indent" > So if a smartphone (as defined in this document) is a GSM modem connected to a PDA in one case, a Dual-SIM
phone is a GSM modem connected to a feature phone in one case.
<!--l. 560--><p class="indent" > Triple-SIM phones often combine the two approaches, i.e. they contain two complete GSM baseband chips, but
three SIM slots that can be switched among the base bands. Only two SIMs can be active at the same
time.
<!--l. 564--><p class="noindent" >
<h4 class="subsectionHead"><span class="titlemark">6.5 </span> <a
id="x1-330006.5"></a>Powerful feature phones</h4>
<!--l. 566--><p class="noindent" >Feature phones are becoming more and more powerful. However, their comparatively lower market price cannot
afford a full-blown smartphone design with its two independent processors and the associated design
complexity.
<!--l. 570--><p class="indent" > Thus, more and more hardware peripherals are added to the only processor left in the phone: The
baseband processor. Such peripherals include sophisticated camera interfaces, high-resolution color display
controllers, TV output, touchscreen controllers, audio and video codecs and even interfaces for mobile TV
reception.
<!--l. 576--><p class="indent" > However, all of those features are still implemented on a fairly weak ARM7 or ARM9 CPU core (compared to
ARM11 and Cortex-A8 in the smartphone market). They also lack a real operating system and still run on top of a
real-time microkernel intended for much less complex systems. They almost always lack any form of memory
protection or multiple address spaces. This makes them more prone to security issues as there is no
privilege separation between the GSM protocol stack and the applications, or between the applications
themselves.
<!--l. 585--><p class="noindent" >
<h3 class="sectionHead"><span class="titlemark">7 </span> <a
id="x1-340007"></a>Personal rant on the closedness of the GSM industry</h3>
<!--l. 587--><p class="noindent" >The GSM industry is one of the most closed areas of computing that I’ve encountered so far. It is very hard to get
any hard technical information out of them. All they like to spread is high-level marketing information, but they’re
very reluctant when it comes down to hard technical facts on their products.
<!--l. 593--><p class="indent" > If you want to build a phone, you need to buy a GSM chipset for your product. There are only very few
companies that offer such chipsets. The classic suppliers are Infineon, Texas Instruments, ST/Ericsson, ADI (now
MediaTek) and Freescale.
<!--l. 598--><p class="indent" > The GSM handset products they sell are not generally available and distributed like other electronic component
they manufacture. If you need a Microcontroller/SoC, a power management IC, a Wifi or Bluetooth chip, RFID
reader ASIC, you simply approach the respective distributors and order them. You get your samples directly from
Digikey.
<!--l. 604--><p class="indent" > This is impossible for GSM (or other cellphone) chipsets. For some reason those chips are sold only to
hand-picked manufacturers. If you want to qualify, you have to subscribe to at least six-digit annual purchasing
quantities. And in order for them to believe you, you have to cough up a significant NRE (non-refundable
engineering fee). This has been reported as high as a seven-digit US$ amount and is to make sure that even if you
end up buying less chips than you indicate, the chipset maker will still have your upfront NRE money and keep
it.
<!--l. 613--><p class="indent" > And if you buy your way into that select club of cellphone makers, what you get from the chipset maker is
typically not all too impressive either. The documentation you get is incomplete, i.e. it alone would not enable you
as a cellphone maker to make any use of the hardware, unless you license the software (drivers, GSM protocol stack,
...) from the chipset maker, too.
<!--l. 620--><p class="indent" > On the software side, most of the technologically interesting bits (like the protocol stack) are provided as
binary-only libraries, you only get source code to some parts of the systems, i.e. some hardware drivers that might
need modification for your particular phone electrical design.
<!--l. 626--><p class="indent" > That GSM protocol stack was not written by the chipset maker either. They simply license a stack from
one of the estimated 4 or 5 organizations who have ever implemented a commercial GSM protocol
stack.
<!--l. 630--><p class="indent" > It is not like the GSM protocols were some kind of military secret. They are a published international standard,
freely accessible for anyone. So why does everybody in that industry think that there is a need to be so
secretive?
<!--l. 635--><p class="indent" > Having spent a significant part of the last 6 years with reverse engineering of various aspects of mobile phones in
order to understand them better and do write software tools for security analysis, I still don’t understand this
secrecy.
<!--l. 640--><p class="indent" > All the various vendors do more or less the same. The fundamental architecture of a GSM baseband chip is the
same, whether you buy it from TI, Infineon or from MediaTek. <span
class="cmti-10">They all cook with water</span>, like we Germans tend
to say. The details like the particular DSP vendor or whether you use a traditional IF, zero-IF or
low-IF analog baseband differ. But from whom do they want to hide it? If people like myself with a
personal interest in the technical aspects of mobile phones can figure it out in a relatively short time,
then I’m sure the competiton of those chipset makers can, too. In much less time, if they actually
care.
<!--l. 651--><p class="indent" > This closedness of the cellular industry is one of the reasons why there has been very little innovation in the
baseband firmware throughout the last decades. Innovation can only happen by very few players. Source code bugs
can only be found and fixed by very few developers at even fewer large corporations. No chance for a small start-up
to innovate, like they can in the sphere of the internet.
<!--l. 658--><p class="indent" > It is fundamentally also the reason why the traditional phone makers have been losing market share to
newcomers to the mobile sphere like Apple with its iPhone or Google with its Android platform.
<!--l. 662--><p class="indent" > Those innovations really only happened on the application processor on high-end smartphones. The closed GSM
baseband processor had to be accompanied by an independent application processor running a real operating
system, with real processes, memory management, shared libraries, memory protection, virtual memory spaces,
user-installable applications, etc.
<!--l. 669--><p class="indent" > They still don’t happen on the baseband processor, which is as closed as it was 15 years ago.
</body></html>
|
