import of old now defunct presentation slides svn repo

3 files changed, 672 insertions, 0 deletions

diff --git a/2010/gsm_phone-anatomy/html/gsm_phone-anatomy-v0.2.css b/2010/gsm_phone-anatomy/html/gsm_phone-anatomy-v0.2.css
new file mode 100644
index 0000000..ee2c1e3
--- /dev/null
+++ b/2010/gsm_phone-anatomy/html/gsm_phone-anatomy-v0.2.css
@@ -0,0 +1,120 @@
+ 
+/* start css.sty */
+.cmr-17{font-size:170%;}
+.cmr-12{font-size:120%;}
+.cmmi-12{font-size:120%;font-style: italic;}
+.cmr-9{font-size:90%;}
+.cmbx-9{font-size:90%; font-weight: bold;}
+.cmti-10{ font-style: italic;}
+p.noindent { text-indent: 0em }
+td p.noindent { text-indent: 0em; margin-top:0em; }
+p.nopar { text-indent: 0em; }
+p.indent{ text-indent: 1.5em }
+@media print {div.crosslinks {visibility:hidden;}}
+a img { border-top: 0; border-left: 0; border-right: 0; }
+center { margin-top:1em; margin-bottom:1em; }
+td center { margin-top:0em; margin-bottom:0em; }
+.Canvas { position:relative; }
+img.math{vertical-align:middle;}
+li p.indent { text-indent: 0em }
+li p:first-child{ margin-top:0em; }
+li p:last-child, li div:last-child { margin-bottom:0.5em; }
+li p~ul:last-child, li p~ol:last-child{ margin-bottom:0.5em; }
+.enumerate1 {list-style-type:decimal;}
+.enumerate2 {list-style-type:lower-alpha;}
+.enumerate3 {list-style-type:lower-roman;}
+.enumerate4 {list-style-type:upper-alpha;}
+div.newtheorem { margin-bottom: 2em; margin-top: 2em;}
+.obeylines-h,.obeylines-v {white-space: nowrap; }
+div.obeylines-v p { margin-top:0; margin-bottom:0; }
+.overline{ text-decoration:overline; }
+.overline img{ border-top: 1px solid black; }
+td.displaylines {text-align:center; white-space:nowrap;}
+.centerline {text-align:center;}
+.rightline {text-align:right;}
+div.verbatim {font-family: monospace; white-space: nowrap; text-align:left; clear:both; }
+.fbox {padding-left:3.0pt; padding-right:3.0pt; text-indent:0pt; border:solid black 0.4pt; }
+div.fbox {display:table}
+div.center div.fbox {text-align:center; clear:both; padding-left:3.0pt; padding-right:3.0pt; text-indent:0pt; border:solid black 0.4pt; }
+div.minipage{width:100%;}
+div.center, div.center div.center {text-align: center; margin-left:1em; margin-right:1em;}
+div.center div {text-align: left;}
+div.flushright, div.flushright div.flushright {text-align: right;}
+div.flushright div {text-align: left;}
+div.flushleft {text-align: left;}
+.underline{ text-decoration:underline; }
+.underline img{ border-bottom: 1px solid black; margin-bottom:1pt; }
+.framebox-c, .framebox-l, .framebox-r { padding-left:3.0pt; padding-right:3.0pt; text-indent:0pt; border:solid black 0.4pt; }
+.framebox-c {text-align:center;}
+.framebox-l {text-align:left;}
+.framebox-r {text-align:right;}
+span.thank-mark{ vertical-align: super }
+span.footnote-mark sup.textsuperscript, span.footnote-mark a sup.textsuperscript{ font-size:80%; }
+div.tabular, div.center div.tabular {text-align: center; margin-top:0.5em; margin-bottom:0.5em; }
+table.tabular td p{margin-top:0em;}
+table.tabular {margin-left: auto; margin-right: auto;}
+td p:first-child{ margin-top:0em; }
+td p:last-child{ margin-bottom:0em; }
+div.td00{ margin-left:0pt; margin-right:0pt; }
+div.td01{ margin-left:0pt; margin-right:5pt; }
+div.td10{ margin-left:5pt; margin-right:0pt; }
+div.td11{ margin-left:5pt; margin-right:5pt; }
+table[rules] {border-left:solid black 0.4pt; border-right:solid black 0.4pt; }
+td.td00{ padding-left:0pt; padding-right:0pt; }
+td.td01{ padding-left:0pt; padding-right:5pt; }
+td.td10{ padding-left:5pt; padding-right:0pt; }
+td.td11{ padding-left:5pt; padding-right:5pt; }
+table[rules] {border-left:solid black 0.4pt; border-right:solid black 0.4pt; }
+.hline hr, .cline hr{ height : 1px; margin:0px; }
+.tabbing-right {text-align:right;}
+span.TEX {letter-spacing: -0.125em; }
+span.TEX span.E{ position:relative;top:0.5ex;left:-0.0417em;}
+a span.TEX span.E {text-decoration: none; }
+span.LATEX span.A{ position:relative; top:-0.5ex; left:-0.4em; font-size:85%;}
+span.LATEX span.TEX{ position:relative; left: -0.4em; }
+div.float, div.figure {margin-left: auto; margin-right: auto;}
+div.float img {text-align:center;}
+div.figure img {text-align:center;}
+.marginpar {width:20%; float:right; text-align:left; margin-left:auto; margin-top:0.5em; font-size:85%; text-decoration:underline;}
+.marginpar p{margin-top:0.4em; margin-bottom:0.4em;}
+table.equation {width:100%;}
+.equation td{text-align:center; }
+td.equation { margin-top:1em; margin-bottom:1em; } 
+td.equation-label { width:5%; text-align:center; }
+td.eqnarray4 { width:5%; white-space: normal; }
+td.eqnarray2 { width:5%; }
+table.eqnarray-star, table.eqnarray {width:100%;}
+div.eqnarray{text-align:center;}
+div.array {text-align:center;}
+div.pmatrix {text-align:center;}
+table.pmatrix {width:100%;}
+span.pmatrix img{vertical-align:middle;}
+div.pmatrix {text-align:center;}
+table.pmatrix {width:100%;}
+span.bar-css {text-decoration:overline;}
+img.cdots{vertical-align:middle;}
+.partToc a, .partToc, .likepartToc a, .likepartToc {line-height: 200%; font-weight:bold; font-size:110%;}
+.index-item, .index-subitem, .index-subsubitem {display:block}
+div.caption {text-indent:-2em; margin-left:3em; margin-right:1em; text-align:left;}
+div.caption span.id{font-weight: bold; white-space: nowrap; }
+h1.partHead{text-align: center}
+p.bibitem { text-indent: -2em; margin-left: 2em; margin-top:0.6em; margin-bottom:0.6em; }
+p.bibitem-p { text-indent: 0em; margin-left: 2em; margin-top:0.6em; margin-bottom:0.6em; }
+.paragraphHead, .likeparagraphHead { margin-top:2em; font-weight: bold;}
+.subparagraphHead, .likesubparagraphHead { font-weight: bold;}
+.quote {margin-bottom:0.25em; margin-top:0.25em; margin-left:1em; margin-right:1em; text-align:justify;}
+.verse{white-space:nowrap; margin-left:2em}
+div.maketitle {text-align:center;}
+h2.titleHead{text-align:center;}
+div.maketitle{ margin-bottom: 2em; }
+div.author, div.date {text-align:center;}
+div.thanks{text-align:left; margin-left:10%; font-size:85%; font-style:italic; }
+div.author{white-space: nowrap;}
+.quotation {margin-bottom:0.25em; margin-top:0.25em; margin-left:1em; }
+.abstract p {margin-left:5%; margin-right:5%;}
+div.abstract {width:100%;}
+.figure img.graphics {margin-left:10%;}
+.subfigcaption {margin-top:1em; margin-left:1em; text-align:center;}
+div.subfigure {text-align:center;}
+/* end css.sty */
+
diff --git a/2010/gsm_phone-anatomy/html/gsm_phone-anatomy-v0.2.html b/2010/gsm_phone-anatomy/html/gsm_phone-anatomy-v0.2.html
new file mode 100644
index 0000000..d688f57
--- /dev/null
+++ b/2010/gsm_phone-anatomy/html/gsm_phone-anatomy-v0.2.html
@@ -0,0 +1,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">&#x003C;</span><span 
+class="cmr-12">laforge@gnumonks.org</span><span 
+class="cmmi-12">&#x003E;</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&amp;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&#x00A0;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&#8217;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&#8217;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&#8217;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&#8217;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&#8217;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&#8217;t happen on the baseband processor, which is as closed as it was 15 years ago.
+    
+</body></html> 
+
+
+
diff --git a/2010/gsm_phone-anatomy/html/gsm_phone-anatomy-v0.20x.png b/2010/gsm_phone-anatomy/html/gsm_phone-anatomy-v0.20x.png
new file mode 100644
index 0000000..489c5b4
--- /dev/null
+++ b/2010/gsm_phone-anatomy/html/gsm_phone-anatomy-v0.20x.png