diff options
Diffstat (limited to '2010/gsm_phone-anatomy/html/gsm_phone-anatomy-v0.2.html')
| -rw-r--r-- | 2010/gsm_phone-anatomy/html/gsm_phone-anatomy-v0.2.html | 552 |
1 files changed, 552 insertions, 0 deletions
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"><</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> + + + |