summaryrefslogtreecommitdiff
path: root/2010/gsm_phone-anatomy
diff options
context:
space:
mode:
authorHarald Welte <laforge@gnumonks.org>2015-10-25 21:00:20 +0100
committerHarald Welte <laforge@gnumonks.org>2015-10-25 21:00:20 +0100
commitfca59bea770346cf1c1f9b0e00cb48a61b44a8f3 (patch)
treea2011270df48d3501892ac1a56015c8be57e8a7d /2010/gsm_phone-anatomy
import of old now defunct presentation slides svn repo
Diffstat (limited to '2010/gsm_phone-anatomy')
-rw-r--r--2010/gsm_phone-anatomy/calypso-block.eps832
-rw-r--r--2010/gsm_phone-anatomy/calypso-block.pdfbin0 -> 14118 bytes
-rw-r--r--2010/gsm_phone-anatomy/calypso-block.svg778
-rw-r--r--2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.1.pdfbin0 -> 184103 bytes
-rw-r--r--2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.2.pdfbin0 -> 184322 bytes
-rw-r--r--2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.2.tex674
-rw-r--r--2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.3.pdfbin0 -> 191293 bytes
-rw-r--r--2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.3.tex770
-rw-r--r--2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.4.pdfbin0 -> 206865 bytes
-rw-r--r--2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.4.tex984
-rw-r--r--2010/gsm_phone-anatomy/html/gsm_phone-anatomy-v0.2.css120
-rw-r--r--2010/gsm_phone-anatomy/html/gsm_phone-anatomy-v0.2.html552
-rw-r--r--2010/gsm_phone-anatomy/html/gsm_phone-anatomy-v0.20x.pngbin0 -> 60416 bytes
-rw-r--r--2010/gsm_phone-anatomy/phones.txt14
-rw-r--r--2010/gsm_phone-anatomy/topics48
15 files changed, 4772 insertions, 0 deletions
diff --git a/2010/gsm_phone-anatomy/calypso-block.eps b/2010/gsm_phone-anatomy/calypso-block.eps
new file mode 100644
index 0000000..01ed57a
--- /dev/null
+++ b/2010/gsm_phone-anatomy/calypso-block.eps
@@ -0,0 +1,832 @@
+%!PS-Adobe-3.0 EPSF-3.0
+%%Creator: cairo 1.8.10 (http://cairographics.org)
+%%CreationDate: Wed Apr 14 00:28:53 2010
+%%Pages: 1
+%%BoundingBox: 0 0 787 276
+%%DocumentData: Clean7Bit
+%%LanguageLevel: 2
+%%EndComments
+%%BeginProlog
+/cairo_eps_state save def
+/dict_count countdictstack def
+/op_count count 1 sub def
+userdict begin
+/q { gsave } bind def
+/Q { grestore } bind def
+/cm { 6 array astore concat } bind def
+/w { setlinewidth } bind def
+/J { setlinecap } bind def
+/j { setlinejoin } bind def
+/M { setmiterlimit } bind def
+/d { setdash } bind def
+/m { moveto } bind def
+/l { lineto } bind def
+/c { curveto } bind def
+/h { closepath } bind def
+/re { exch dup neg 3 1 roll 5 3 roll moveto 0 rlineto
+ 0 exch rlineto 0 rlineto closepath } bind def
+/S { stroke } bind def
+/f { fill } bind def
+/f* { eofill } bind def
+/B { fill stroke } bind def
+/B* { eofill stroke } bind def
+/n { newpath } bind def
+/W { clip } bind def
+/W* { eoclip } bind def
+/BT { } bind def
+/ET { } bind def
+/pdfmark where { pop globaldict /?pdfmark /exec load put }
+ { globaldict begin /?pdfmark /pop load def /pdfmark
+ /cleartomark load def end } ifelse
+/BDC { mark 3 1 roll /BDC pdfmark } bind def
+/EMC { mark /EMC pdfmark } bind def
+/cairo_store_point { /cairo_point_y exch def /cairo_point_x exch def } def
+/Tj { show currentpoint cairo_store_point } bind def
+/TJ {
+ {
+ dup
+ type /stringtype eq
+ { show } { -0.001 mul 0 cairo_font_matrix dtransform rmoveto } ifelse
+ } forall
+ currentpoint cairo_store_point
+} bind def
+/cairo_selectfont { cairo_font_matrix aload pop pop pop 0 0 6 array astore
+ cairo_font exch selectfont cairo_point_x cairo_point_y moveto } bind def
+/Tf { pop /cairo_font exch def /cairo_font_matrix where
+ { pop cairo_selectfont } if } bind def
+/Td { matrix translate cairo_font_matrix matrix concatmatrix dup
+ /cairo_font_matrix exch def dup 4 get exch 5 get cairo_store_point
+ /cairo_font where { pop cairo_selectfont } if } bind def
+/Tm { 2 copy 8 2 roll 6 array astore /cairo_font_matrix exch def
+ cairo_store_point /cairo_font where { pop cairo_selectfont } if } bind def
+/g { setgray } bind def
+/rg { setrgbcolor } bind def
+/d1 { setcachedevice } bind def
+%%EndProlog
+11 dict begin
+/FontType 42 def
+/FontName /f-0-0 def
+/PaintType 0 def
+/FontMatrix [ 1 0 0 1 0 0 ] def
+/FontBBox [ 0 0 0 0 ] def
+/Encoding 256 array def
+0 1 255 { Encoding exch /.notdef put } for
+Encoding 1 /uni0043 put
+Encoding 2 /uni0041 put
+Encoding 3 /uni004C put
+Encoding 4 /uni0059 put
+Encoding 5 /uni0050 put
+Encoding 6 /uni0053 put
+Encoding 7 /uni004F put
+Encoding 8 /uni0054 put
+Encoding 9 /uni0057 put
+Encoding 10 /uni0033 put
+Encoding 11 /uni0030 put
+Encoding 12 /uni0032 put
+Encoding 13 /uni0035 put
+Encoding 14 /uni0042 put
+Encoding 15 /uni0055 put
+Encoding 16 /uni0044 put
+Encoding 17 /uni006E put
+Encoding 18 /uni0074 put
+Encoding 19 /uni0065 put
+Encoding 20 /uni0061 put
+Encoding 21 /uni0077 put
+Encoding 22 /uni0069 put
+Encoding 23 /uni0063 put
+Encoding 24 /uni0068 put
+Encoding 25 /uni004D put
+Encoding 26 /uni0034 put
+Encoding 27 /uni0052 put
+Encoding 28 /uni0046 put
+Encoding 29 /uni0036 put
+Encoding 30 /uni0031 put
+Encoding 31 /uni0072 put
+Encoding 32 /uni0073 put
+Encoding 33 /uni0076 put
+Encoding 34 /uni0078 put
+Encoding 35 /uni0056 put
+Encoding 36 /uni0020 put
+Encoding 37 /uni0047 put
+Encoding 38 /uni002F put
+Encoding 39 /uni004B put
+Encoding 40 /uni0049 put
+Encoding 41 /uni0051 put
+Encoding 42 /uni006C put
+Encoding 43 /uni006F put
+Encoding 44 /uni0067 put
+/CharStrings 45 dict dup begin
+/.notdef 0 def
+/uni0043 1 def
+/uni0041 2 def
+/uni004C 3 def
+/uni0059 4 def
+/uni0050 5 def
+/uni0053 6 def
+/uni004F 7 def
+/uni0054 8 def
+/uni0057 9 def
+/uni0033 10 def
+/uni0030 11 def
+/uni0032 12 def
+/uni0035 13 def
+/uni0042 14 def
+/uni0055 15 def
+/uni0044 16 def
+/uni006E 17 def
+/uni0074 18 def
+/uni0065 19 def
+/uni0061 20 def
+/uni0077 21 def
+/uni0069 22 def
+/uni0063 23 def
+/uni0068 24 def
+/uni004D 25 def
+/uni0034 26 def
+/uni0052 27 def
+/uni0046 28 def
+/uni0036 29 def
+/uni0031 30 def
+/uni0072 31 def
+/uni0073 32 def
+/uni0076 33 def
+/uni0078 34 def
+/uni0056 35 def
+/uni0020 36 def
+/uni0047 37 def
+/uni002F 38 def
+/uni004B 39 def
+/uni0049 40 def
+/uni0051 41 def
+/uni006C 42 def
+/uni006F 43 def
+/uni0067 44 def
+end readonly def
+/sfnts [
+<00010000000a008000030020636d61700223f2f9000021a8000000986376742000691d390000
+2240000001fe6670676d7134766a00002440000000ab676c79668236ed47000000ac000020fc
+68656164f30fc2be000024ec00000036686865610cb8067e0000252400000024686d7478dc9a
+166400002548000000b46c6f63610002f714000025fc000000b86d617870049a0671000026b4
+00000020707265703b07f100000026d40000056800020066fe96046605a400030007001a400c
+04fb0006fb0108057f0204002fc4d4ec310010d4ecd4ec301311211125211121660400fc7303
+1bfce5fe96070ef8f272062900010073ffe3052705f000190036401a0da10eae0a951101a100
+ae04951791118c1a07190d003014101a10fcec32ec310010e4f4ecf4ec10eef6ee30b40f1b1f
+1b02015d01152e0123200011100021323637150e01232000111000213216052766e782ff00fe
+f00110010082e7666aed84feadfe7a0186015386ed0562d55f5efec7fed8fed9fec75e5fd348
+48019f01670168019f470000000200100000056805d50002000a00c240410011010004050402
+1105050401110a030a0011020003030a0711050406110505040911030a08110a030a42000307
+95010381090509080706040302010009050a0b10d4c4173931002f3ce4d4ec1239304b535807
+1005ed0705ed071005ed0705ed071008ed071005ed071005ed071008ed5922b2200c01015d40
+420f010f020f070f080f005800760070008c000907010802060309041601190256015802500c
+67016802780176027c0372047707780887018802800c980299039604175d005d090121013301
+230321032302bcfeee0225fe7be50239d288fd5f88d5050efd1903aefa2b017ffe8100000001
+00c90000046a05d500050025400c0295008104011c033a00040610fcecec31002fe4ec304009
+300750078003800404015d133311211521c9ca02d7fc5f05d5fad5aa0001fffc000004e705d5
+00080094402803110405040211010205050402110302080008011100000842020300af060207
+0440051c0040070910d4e4fce4123931002fec3239304b5358071005ed071008ed071008ed07
+1005ed5922b2000a01015d403c05021402350230023005300846024002400540085102510551
+086502840293021016011a031f0a2601290337013803400a670168037803700a9f0a0d5d005d
+03330901330111231104d9019e019bd9fdf0cb05d5fd9a0266fcf2fd3902c7000000000200c9
+0000048d05d500080013003a40180195100095098112100a0802040005190d3f11001c090414
+10fcec32fcec11173931002ff4ecd4ec30400b0f151f153f155f15af1505015d011133323635
+342623252132041514042b0111230193fe8d9a9a8dfe3801c8fb0101fefffbfeca052ffdcf92
+878692a6e3dbdde2fda800010087ffe304a205f00027007e403c0d0c020e0b021e1f1e080902
+070a021f1f1e420a0b1e1f0415010015a11494189511049500942591118c281e0a0b1f1b0700
+221b190e2d071914222810dcc4ecfcece4111239393939310010e4f4e4ec10eef6ee10c61117
+39304b535807100eed11173907100eed1117395922b20f2901015db61f292f294f29035d0115
+2e012322061514161f011e0115140421222627351e013332363534262f012e01353424333216
+044873cc5fa5b377a67ae2d7feddfee76aef807bec72adbc879a7be2ca0117f569da05a4c537
+36807663651f192bd9b6d9e0302fd04546887e6e7c1f182dc0abc6e4260000020073ffe305d9
+05f0000b00170023401306951200950c91128c1809190f33031915101810fcecfcec310010e4
+f4ec10ee300122001110003332001110002720001110002120001110000327dcfefd0103dcdc
+0101feffdc013a0178fe88fec6fec5fe870179054cfeb8fee5fee6feb80148011a011b0148a4
+fe5bfe9efe9ffe5b01a40162016201a500000001fffa000004e905d50007004a400e06029500
+81040140031c0040050810d4e4fce431002ff4ec3230014bb00a5458bd000800400001000800
+08ffc03811373859401300091f00100110021f071009400970099f09095d0321152111231121
+0604effdeecbfdee05d5aafad5052b0000010044000007a605d5000c017b4049051a0605090a
+09041a0a09031a0a0b0a021a01020b0b0a061107080705110405080807021103020c000c0111
+00000c420a050203060300af0b080c0b0a09080605040302010b07000d10d4cc173931002f3c
+ec32321739304b5358071005ed071008ed071008ed071005ed071008ed071005ed0705ed0710
+08ed5922b2000e01015d40f206020605020a000a000a120a2805240a200a3e023e05340a300a
+4c024d05420a400a59026a026b05670a600a7b027f027c057f05800a960295051d0700090208
+03000406050005000601070408000807090009040a0a0c000e1a0315041508190c100e200421
+052006200720082309240a250b200e200e3c023a033504330530083609390b3f0c300e460046
+014a0240044505400542064207420840084009440a4d0c400e400e58025608590c500e660267
+03610462056006600760086409640a640b770076017b02780377047405790679077708700878
+0c7f0c7f0e860287038804890585098a0b8f0e97049f0eaf0e5b5d005d133309013309013301
+2309012344cc013a0139e3013a0139cdfe89fefec5fec2fe05d5fb1204eefb1204eefa2b0510
+faf000000001009cffe3047305f000280070402e0015130a86091f862013a0150da00993061c
+a020932391068c15a329161c13000314191c2620101c03141f09062910fc4bb016544bb01454
+5b58b90009ffc03859c4c4d4ecf4ec11173939310010ece4f4e4ec10e6ee10ee10ee10ee1112
+3930014009641e611f6120642104005d011e0115140421222627351e013332363534262b0135
+33323635342623220607353e01333204151406033f91a3fed0fee85ec76a54c86dbec7b9a5ae
+b6959ea39853be7273c959e6010c8e03251fc490ddf22525c33132968f8495a67770737b2426
+b42020d1b27cab0000020087ffe3048f05f0000b00170023401306a01200a00c91128c18091c
+0f1e031c151b1810fcecf4ec310010e4f4ec10ee300122021110123332121110022732001110
+00232200111000028b9c9d9d9c9d9d9d9dfb0109fef7fbfbfef701090550fecdfeccfecdfecd
+0133013301340133a0fe73fe86fe87fe73018d0179017a018d00000100960000044a05f0001c
+009a4027191a1b03181c11050400110505044210a111940da014910400a00200100a02010a1c
+171003061d10fc4bb015544bb016545b4bb014545b58b90003ffc03859c4d4ecc0c011123931
+002fec32f4ecf4ec304b5358071005ed0705ed11173959220140325504560556077a047a0576
+1b87190704000419041a041b051c74007606751a731b741c82008619821a821b821ca800a81b
+115d005d25211521353600373e0135342623220607353e01333204151406070600018902c1fc
+4c73018d33614da7865fd3787ad458e80114455b19fef4aaaaaa7701913a6d974977964243cc
+3132e8c25ca5701dfeeb00000001009effe3046405d5001d005e4023041a071186101d1aa007
+14a010890d02a000810d8c07a41e171c010a031c000a10061e10fc014bb016544bb014545b58
+b90010ffc038594bb00f5458b9001000403859c4d4ec10c4ee310010e4e4f4ec10e6ee10fec4
+10ee1112393013211521113e0133320015140021222627351e0133323635342623220607dd03
+19fda02c582cfa0124fed4feef5ec3685ac06badcacaad51a15405d5aafe920f0ffeeeeaf1fe
+f52020cb3130b69c9cb624260000000300c9000004ec05d5000800110020004340231900950a
+0995128101950aad1f110b080213191f05000e1c1605191c2e09001c12042110fcec32fcecd4
+ec111739393931002fececf4ec10ee3930b20f2201015d011121323635342623011121323635
+34262325213216151406071e01151404232101930144a39d9da3febc012b94919194fe0b0204
+e7fa807c95a5fef0fbfde802c9fddd878b8c850266fe3e6f727170a6c0b189a21420cb98c8da
+000100b2ffe3052905d50011004040160802110b0005950e8c09008112081c0a38011c004112
+10fc4bb0105458b90000ffc03859ecfcec310010e432f4ec11393939393001b61f138f139f13
+035d133311141633323635113311100021200011b2cbaec3c2aecbfedffee6fee5fedf05d5fc
+75f0d3d3f0038bfc5cfedcfed6012a012400000200c9000005b005d500080011002e40150095
+09810195100802100a0005190d32001c09041210fcecf4ec113939393931002fecf4ec30b260
+1301015d0111332000111000212521200011100029010193f40135011ffee1fecbfe42019f01
+b20196fe68fe50fe61052ffb770118012e012c0117a6fe97fe80fe7efe960000000100ba0000
+0464047b001300364019030900030e0106870e11b80cbc0a010208004e0d09080b461410fcec
+32f4ec31002f3ce4f4c4ec1112173930b46015cf1502015d0111231134262322061511231133
+153e013332160464b87c7c95acb9b942b375c1c602a4fd5c029e9f9ebea4fd870460ae6564ef
+00010037000002f2059e0013003840190e05080f03a9001101bc08870a0b0809020400081012
+0e461410fc3cc4fc3cc432393931002fecf43cc4ec3211393930b2af1501015d011121152111
+14163b01152322263511233533110177017bfe854b73bdbdd5a28787059efec28ffda0894e9a
+9fd202608f013e00000000020071ffe3047f047b0014001b00704024001501098608880515a9
+0105b90c01bb18b912b80c8c1c1b1502081508004b02120f451c10fcecf4ecc4111239310010
+e4f4ece410ee10ee10f4ee1112393040293f1d701da01dd01df01d053f003f013f023f153f1b
+052c072f082f092c0a6f006f016f026f156f1b095d71015d0115211e0133323637150e012320
+00111000333200072e0123220607047ffcb20ccdb76ac76263d06bfef4fec70129fce20107b8
+02a5889ab90e025e5abec73434ae2a2c0138010a01130143feddc497b4ae9e000002007bffe3
+042d047b000a002500bc4027191f0b17090e00a91706b90e1120861fba1cb923b8118c170c00
+1703180d09080b1f030814452610fcecccd4ec323211393931002fc4e4f4fcf4ec10c6ee10ee
+11391139123930406e301d301e301f3020302130223f27401d401e401f402040214022501d50
+1e501f50205021502250277027851d871e871f8720872185229027a027f0271e301e301f3020
+3021401e401f40204021501e501f50205021601e601f60206021701e701f70207021801e801f
+80208021185d015d0122061514163332363d01371123350e0123222635343633213534262322
+0607353e0133321602bedfac816f99b9b8b83fbc88accbfdfb0102a79760b65465be5af3f002
+33667b6273d9b4294cfd81aa6661c1a2bdc0127f8b2e2eaa2727fc0000010056000006350460
+000c01eb404905550605090a0904550a0903550a0b0a025501020b0b0a061107080705110405
+080807021103020c000c011100000c420a050203060300bf0b080c0b0a09080605040302010b
+07000d10d44bb00a544bb011545b4bb012545b4bb013545b4bb00b545b58b900000040385901
+4bb00c544bb00d545b4bb010545b58b90000ffc03859cc173931002f3cec32321739304b5358
+071005ed071008ed071008ed071005ed071008ed071005ed0705ed071008ed59220140ff0502
+16021605220a350a49024905460a400a5b025b05550a500a6e026e05660a79027f0279057f05
+870299029805940abc02bc05ce02c703cf051d0502090306040b050a080b09040b050c150219
+0316041a051b081b09140b150c2500250123022703210425052206220725082709240a210b23
+0c390336043608390c300e460248034604400442054006400740084409440a440b400e400e56
+0056015602500451055206520750085309540a550b6300640165026a0365046a056a066a076e
+09610b670c6f0e7500750179027d0378047d057a067f067a077f07780879097f097b0a760b7d
+0c870288058f0e97009701940293039c049b05980698079908402f960c9f0ea600a601a402a4
+03ab04ab05a906a907ab08a40caf0eb502b103bd04bb05b809bf0ec402c303cc04ca05795d00
+5d13331b01331b013301230b012356b8e6e5d9e6e5b8fedbd9f1f2d90460fc96036afc96036a
+fba00396fc6a000200c100000179061400030007002b400e06be04b100bc0205010804004608
+10fc3cec3231002fe4fcec30400b1009400950096009700905015d1333112311331523c1b8b8
+b8b80460fba00614e90000010071ffe303e7047b0019003f401b00860188040e860d880ab911
+04b917b8118c1a07120d004814451a10fce432ec310010e4f4ec10fef4ee10f5ee30400b0f1b
+101b801b901ba01b05015d01152e0123220615141633323637150e0123220011100021321603
+e74e9d50b3c6c6b3509d4e4da55dfdfed6012d010655a20435ac2b2be3cdcde32b2baa242401
+3e010e0112013a230000000100ba000004640614001300344019030900030e0106870e11b80c
+970a010208004e0d09080b461410fcec32f4ec31002f3cecf4c4ec1112173930b2601501015d
+0111231134262322061511231133113e013332160464b87c7c95acb9b942b375c1c602a4fd5c
+029e9f9ebea4fd870614fd9e6564ef00000100c90000061f05d5000c00bf4034031107080702
+11010208080702110302090a0901110a0a09420a070203080300af080b050908030201050a06
+1c043e0a1c00040d10fcecfcec11173931002f3cc4ec32111739304b5358071005ed071008ed
+071008ed071005ed5922b2700e01015d405603070f080f09020a15021407130a260226072007
+260a200a3407350a69027c027b07790a80028207820a90021604010b0313011b0323012c0327
+08280934013c035608590965086a097608790981018d0395019b03145d005d13210901211123
+110123011123c9012d017d017f012dc5fe7fcbfe7fc405d5fc0803f8fa2b051ffc000400fae1
+000000020064000004a405d50002000d0081401d010d030d0003030d4200030b07a005010381
+09010c0a001c0608040c0e10dc4bb00b544bb00d545b58b9000cffc03859d43cc4ec32113931
+002fe4d43cec321239304b5358071004c9071005c9592201402a0b002a004800590069007700
+8a000716012b0026012b0336014e014f0c4f0d5601660175017a0385010d5d005d0901210333
+1133152311231121350306fe0201fe35fed5d5c9fd5e0525fce303cdfc33a8fea00160c30000
+000200c90000055405d50013001c00b14035090807030a061103040305110404034206040015
+030415950914950d810b040506031109001c160e050a191904113f140a1c0c041d10fcec32fc
+c4ec1117391139393931002f3cf4ecd4ec123912391239304b5358071005ed071005ed111739
+5922b2401e01015d40427a130105000501050206030704150015011402160317042500250125
+0226032706260726082609201e3601360246014602680575047505771388068807980698071f
+5d005d011e01171323032e012b01112311212016151406011133323635342623038d417b3ecd
+d9bf4a8b78dcca01c80100fc83fd89fe9295959202bc16907efe68017f9662fd8905d5d6d88d
+ba024ffdee8783838500000100c90000042305d50009002940120695040295008104ad080501
+07031c00040a10fcec32d4c431002fecf4ec10ee30b20f0b01015d13211521112115211123c9
+035afd700250fdb0ca05d5aafe48aafd37000002008fffe3049605f0000b0024005840241306
+000d860c00a01606a01c16a510a00c8922911c8c250c22091c191e131c03211f1b2510fcecec
+f4ece4310010e4f4e4fce410ee10ee10ee111239304014cb00cb01cd02cd03cd04cb05cb0607
+a41eb21e025d015d01220615141633323635342601152e01232202033e013332001514002320
+0011100021321602a4889f9f88889f9f01094c9b4cc8d30f3bb26be10105fef0e2fefdfeee01
+50011b4c9b033bbaa2a1bbbba1a2ba0279b82426fef2feef575dfeefebe6feea018d01790162
+01a51e000000000100e10000045a05d5000a004040154203a00402a005810700a009081f061c
+03001f010b10d44bb00f5458b9000100403859ecc4fcec31002fec32f4ecd4ec304b53585922
+01b40f030f04025d3721110535253311211521fe014afe990165ca014afca4aa047348b848fa
+d5aa0000000100ba0000034a047b001100304014060b0700110b03870eb809bc070a06080008
+461210fcc4ec3231002fe4f4ecc4d4cc11123930b450139f1302015d012e0123220615112311
+33153e0133321617034a1f492c9ca7b9b93aba85132e1c03b41211cbbefdb20460ae66630505
+00000001006fffe303c7047b002700e7403c0d0c020e0b531f1e080902070a531f1f1e420a0b
+1e1f041500860189041486158918b91104b925b8118c281e0a0b1f1b0700521b080e07081422
+452810fcc4ecd4ece4111239393939310010e4f4ec10fef5ee10f5ee121739304b535807100e
+ed111739070eed1117395922b2002701015d406d1c0a1c0b1c0c2e092c0a2c0b2c0c3b093b0a
+3b0b3b0c0b200020012402280a280b2a132f142f152a16281e281f292029212427860a860b86
+0c860d12000000010202060a060b030c030d030e030f03100319031a031b031c041d09272f29
+3f295f297f2980299029a029f029185d005d7101152e012322061514161f011e011514062322
+2627351e013332363534262f012e01353436333216038b4ea85a898962943fc4a5f7d85ac36c
+66c661828c65ab40ab98e0ce66b4043fae282854544049210e2a99899cb62323be353559514b
+50250f2495829eac1e0000000001003d0000047f0460000600fb402703110405040211010205
+050402110302060006011100000642020300bf0506050302010504000710d44bb00a5458b900
+00004038594bb014544bb015545b58b90000ffc03859c4173931002fec3239304b5358071005
+ed071008ed071008ed071005ed592201408e48026a027b027f02860280029102a40208060006
+0109030904150015011a031a0426002601290329042008350035013a033a0430084600460149
+034904460548064008560056015903590450086600660169036904670568066008750074017b
+037b0475057a068500850189038904890586069600960197029a03980498059706a805a706b0
+08c008df08ff083e5d005d133309013301233dc3015e015ec3fe5cfa0460fc5403acfba00000
+0001003b000004790460000b0143404605110607060411030407070604110504010201031102
+02010b110001000a11090a0101000a110b0a0708070911080807420a070401040800bf05020a
+0704010408000208060c10d44bb00a544bb00f545b4bb010545b4bb011545b58b90006004038
+594bb0145458b90006ffc03859c4d4c411173931002f3cec321739304b5358071005ed071008
+ed071008ed071005ed071005ed071008ed071008ed071005ed59220140980a04040a1a04150a
+260a3d04310a55045707580a660a76017a047607740a8d04820a99049f049707920a900aa601
+a904af04a507a30aa00a1c0a03040505090a0b1a03150515091a0b2903260525092a0b200d3a
+013903370534073609390b300d4903460545094a0b400d590056015902590357055606590756
+085609590b500d6f0d78017f0d9b019407ab01a407b00dcf0ddf0dff0d2f5d005d0902230901
+2309013309010464fe6b01aad9febafebad901b3fe72d9012901290460fddffdc101b8fe4802
+4a0216fe71018f00000100100000056805d5000600b740270411050605031102030606050311
+0403000100021101010042030401af0006040302000505010710d4c4173931002fec3239304b
+5358071005ed071008ed071008ed071005ed5922b2500801015d406200032a03470447055a03
+7d038303070600070208040906150114021a041a052a00260126022904290525062008380033
+0133023c043c053706480045014502490449054706590056066602690469057a007601760279
+0479057506800898009706295d005d21013309013301024afdc6d301d901dad2fdc705d5fb17
+04e9fa2b00010073ffe3058b05f0001d0039402000051b0195031b950812a111ae15950e9108
+8c1e02001c1134043318190b101e10fcecfce4fcc4310010e4f4ecf4ec10fed4ee1139393025
+1121352111060423200011100021320417152e0123200011100021323604c3feb6021275fee6
+a0fea2fe75018b015e9201076f70fc8bfeeefeed011301126ba8d50191a6fd7f53550199016d
+016e01994846d75f60fecefed1fed2fece25000000010000ff4202b205d50003002d4014001a
+010201021a03000342029f008104020001032fc43939310010f4ec304b5358071005ed071005
+ed5922013301230208aafdf8aa05d5f96d000000000100c90000056a05d5000a00ef40280811
+05060507110606050311040504021105050442080502030300af09060501040608011c00040b
+10fcec32d4c4113931002f3cec321739304b5358071004ed071005ed071005ed071004ed5922
+b2080301015d4092140201040209081602280528083702360534084702460543085502670276
+027705830288058f0894029b08e702150603090509061b031907050a030a07180328052b062a
+073604360536063507300c41034004450540064007400c62036004680567077705700c8b038b
+058e068f078f0c9a039d069d07b603b507c503c507d703d607e803e904e805ea06f703f805f9
+062c5d71005d711333110121090121011123c9ca029e0104fd1b031afef6fd33ca05d5fd8902
+77fd48fce302cffd31000000000100c90000019305d50003002eb700af02011c00040410fc4b
+b0105458b9000000403859ec31002fec3001400d30054005500560058f059f05065d13331123
+c9caca05d5fa2b0000020073fef805d905f0000b001d0052402a1110020f010c0d0c0e010d0d
+0c420f1e0c06951200951891128c0d1e0d1b0f0c0309191b33031915101e10fcecfcec113939
+1139310010c4e4f4ec10ee391239304b5358071005ed071005ed173959220122001110003332
+00111000130123270e012320001110002120001110020327dcfefd0103dcdc0101feff3f010a
+f4dd212310fec5fe870179013b013a0178d1054cfeb8fee5fee6feb80148011a011b0148facf
+feddef020201a50161016201a5fe5bfe9efefcfe8e00000100c100000179061400030022b700
+9702010800460410fcec31002fec30400d10054005500560057005f00506015d13331123c1b8
+b80614f9ec0000020071ffe30475047b000b0017004a401306b91200b90cb8128c1809120f51
+031215451810fcecf4ec310010e4f4ec10ee3040233f197b007b067f077f087f097f0a7f0b7b
+0c7f0d7f0e7f0f7f107f117b12a019f01911015d012206151416333236353426273200111000
+232200111000027394acab9593acac93f00112feeef0f1feef011103dfe7c9c9e7e8c8c7e99c
+fec8feecfeedfec70139011301140138000000020071fe56045a047b000b0028004a4023190c
+1d0912861316b90f03b92623b827bc09b90fbd1a1d261900080c4706121220452910fcc4ecf4
+ec323231002fc4e4ece4f4c4ec10fed5ee1112393930b6602a802aa02a03015d013426232206
+15141633323617100221222627351e013332363d010e0123220211101233321617353303a2a5
+9594a5a59495a5b8fefefa61ac51519e52b5b439b27ccefcfcce7cb239b8023dc8dcdcc8c7dc
+dcebfee2fee91d1eb32c2abdbf5b6362013a01030104013a6263aa0000000002000300000000
+001400010000000000340004002000000004000400010000f02cffff0000f000ffff10000001
+000000000006006400000000002d0000000100020003000400050006000700080009000a000b
+000c000d000e000f0010001100120013001400150016001700180019001a001b001c001d001e
+001f0020002100220023002400250026002700280029002a002b002c013500b800cb00cb00c1
+00aa009c01a600b800660000007100cb00a002b20085007500b800c301cb0189022d00cb00a6
+00f000d300aa008700cb03aa0400014a003300cb000000d9050200f4015400b4009c01390114
+013907060400044e04b4045204b804e704cd0037047304cd04600473013303a2055605a60556
+053903c5021200c9001f00b801df007300ba03e9033303bc0444040e00df03cd03aa00e503aa
+0404000000cb008f00a4007b00b80014016f007f027b0252008f00c705cd009a009a006f00cb
+00cd019e01d300f000ba018300d5009803040248009e01d500c100cb00f600830354027f0000
+0333026600d300c700a400cd008f009a0073040005d5010a00fe022b00a400b4009c00000062
+009c0000001d032d05d505d505d505f0007f007b005400a406b80614072301d300b800cb00a6
+01c301ec069300a000d3035c037103db0185042304a80448008f0139011401390360008f05d5
+019a0614072306660179046004600460047b009c00000277046001aa00e904600762007b00c5
+007f027b000000b4025205cd006600bc00660077061000cd013b01850389008f007b0000001d
+00cd074a042f009c009c0000077d006f0000006f0335006a006f007b00ae00b2002d0396008f
+027b00f600830354063705f6008f009c04e10266008f018d02f600cd03440029006604ee0073
+0000140000960000b707060504030201002c2010b002254964b040515820c859212d2cb00225
+4964b040515820c859212d2c20100720b00050b00d7920b8ffff5058041b0559b0051cb00325
+08b0042523e120b00050b00d7920b8ffff5058041b0559b0051cb0032508e12d2c4b505820b0
+fd454459212d2cb002254560442d2c4b5358b00225b0022545445921212d2c45442d2cb00225
+b0022549b00525b005254960b0206368208a108a233a8a10653a2d000001000000024ccc7563
+80ee5f0f3cf5001f080000000000c74a953600000000c74a9536f7d6fd330d72095500000008
+000000010000000000010000076dfe1d00000de2f7d6fa510d72000100000000000000000000
+00000000002d04cd00660596007305790010047500c904e3fffc04d300c905140087064c0073
+04e3fffa07e900440517009c05170087051700960517009e057d00c905db00b2062900c90512
+00ba0323003704ec007104e7007b068b0056023900c104660071051200ba06e700c905170064
+058f00c9049a00c90517008f051700e1034a00ba042b006f04bc003d04bc003b05790010028b
+00000633007302b20000053f00c9025c00c9064c0073023900c104e500710514007100000000
+00000044000000dc000001d80000021c000002e00000036000000458000004e4000005540000
+0710000007f80000087c0000097800000a3800000ae800000b6c00000bec00000c6400000ce0
+00000db400000ee00000110400001154000011ec00001264000013600000141c000015300000
+15840000165c000016cc0000173c0000189c000019c000001b4400001c2400001c2400001ccc
+00001d1800001e4000001e8800001f5400001f9000002034000020fc00010000002d0354002b
+0068000c000200100099000800000415021600080004b8028040fffbfe03fa1403f92503f832
+03f79603f60e03f5fe03f4fe03f32503f20e03f19603f02503ef8a4105effe03ee9603ed9603
+ecfa03ebfa03eafe03e93a03e84203e7fe03e63203e5e45305e59603e48a4105e45303e3e22f
+05e3fa03e22f03e1fe03e0fe03df3203de1403dd9603dcfe03db1203da7d03d9bb03d8fe03d6
+8a4105d67d03d5d44705d57d03d44703d3d21b05d3fe03d21b03d1fe03d0fe03cffe03cefe03
+cd9603cccb1e05ccfe03cb1e03ca3203c9fe03c6851105c61c03c51603c4fe03c3fe03c2fe03
+c1fe03c0fe03bffe03befe03bdfe03bcfe03bbfe03ba1103b9862505b9fe03b8b7bb05b8fe03
+b7b65d05b7bb03b78004b6b52505b65d40ff03b64004b52503b4fe03b39603b2fe03b1fe03b0
+fe03affe03ae6403ad0e03acab2505ac6403abaa1205ab2503aa1203a98a4105a9fa03a8fe03
+a7fe03a6fe03a51203a4fe03a3a20e05a33203a20e03a16403a08a4105a096039ffe039e9d0c
+059efe039d0c039c9b19059c64039b9a10059b19039a1003990a0398fe0397960d0597fe0396
+0d03958a410595960394930e05942803930e0392fa039190bb0591fe03908f5d0590bb039080
+048f8e25058f5d038f40048e25038dfe038c8b2e058cfe038b2e038a8625058a410389880b05
+891403880b03878625058764038685110586250385110384fe038382110583fe0382110381fe
+0380fe037ffe0340ff7e7d7d057efe037d7d037c64037b5415057b25037afe0379fe03780e03
+770c03760a0375fe0374fa0373fa0372fa0371fa0370fe036ffe036efe036c21036bfe036a11
+42056a530369fe03687d036711420566fe0365fe0364fe0363fe0362fe03613a0360fa035e0c
+035dfe035bfe035afe0359580a0559fa03580a035716190557320356fe035554150555420354
+150353011005531803521403514a130551fe03500b034ffe034e4d10054efe034d10034cfe03
+4b4a13054bfe034a4910054a1303491d0d05491003480d0347fe0346960345960344fe034302
+2d0543fa0342bb03414b0340fe033ffe033e3d12053e14033d3c0f053d12033c3b0d053c40ff
+0f033b0d033afe0339fe033837140538fa033736100537140336350b05361003350b03341e03
+330d0332310b0532fe03310b03302f0b05300d032f0b032e2d09052e10032d09032c32032b2a
+25052b64032a2912052a25032912032827250528410327250326250b05260f03250b0324fe03
+23fe03220f03210110052112032064031ffa031e1d0d051e64031d0d031c1142051cfe031bfa
+031a42031911420519fe031864031716190517fe031601100516190315fe0314fe0313fe0312
+11420512fe0311022d05114203107d030f64030efe030d0c16050dfe030c0110050c16030bfe
+030a100309fe0308022d0508fe030714030664030401100504fe03401503022d0503fe030201
+1005022d0301100300fe0301b80164858d012b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b
+2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b
+2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b
+2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b
+2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b002b2b2b2b2b2b
+2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b
+2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b
+2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b
+2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b1d00>
+] def
+FontName currentdict end definefont pop
+%%Page: 1 1
+%%BeginPageSetup
+%%PageBoundingBox: 0 0 787 276
+%%EndPageSetup
+q
+0 g
+2.267717 w
+0 J
+0 j
+[] 0.0 d
+4 M q 1 0 0 -1 0 275.102356 cm
+737.715 156.613 m 780.234 156.613 l 780.234 99.922 l 780.234 99.922 l S Q
+1.700787 w
+q 1 0 0 -1 0 275.102356 cm
+786.531 93.055 m 782.773 93.055 779.727 96.105 779.727 99.859 c 779.727
+103.613 782.773 106.664 786.531 106.664 c S Q
+1 g
+0.707 274.395 m 142.441 274.395 l 142.441 61.794 l 0.707 61.794 l 0.707
+274.395 l h
+0.707 274.395 m f
+0 g
+1.417323 w
+q 1 0 0 -1 0 275.102356 cm
+0.707 0.707 m 142.441 0.707 l 142.441 213.309 l 0.707 213.309 l 0.707
+0.707 l h
+0.707 0.707 m S Q
+BT
+16 0 0 16 2.308661 260.220464 Tm
+/f-0-0 1 Tf
+[<01>-1<02>1<03>133<04>-1<050607>]TJ
+ET
+1 g
+255.723 246.122 m 340.973 246.122 l 340.973 61.927 l 255.723 61.927 l
+255.723 246.122 l h
+255.723 246.122 m f
+0 g
+1.205805 w
+q 1 0 0 -1 0 275.102356 cm
+255.723 28.98 m 340.973 28.98 l 340.973 213.176 l 255.723 213.176 l
+255.723 28.98 l h
+255.723 28.98 m S Q
+BT
+17.54446 0 0 16.791247 255.826791 230.241386 Tm
+/f-0-0 1 Tf
+<0809030a0b0c0d>Tj
+9.6 0 0 9.6 259.749073 129.812069 Tm
+[<0e>18<0605>]TJ
+0.0416667 -3.069444 Td
+<0f0605>Tj
+0.0833333 -2.7862 Td
+<080605>Tj
+5.705271 10.248252 Td
+<0e0f03>Tj
+-0.0774485 1.373258 Td
+<0e1003>Tj
+ET
+1 g
+652.68 161.005 m 737.715 161.005 l 737.715 89.895 l 652.68 89.895 l
+652.68 161.005 l h
+652.68 161.005 m f
+0 g
+1.419749 w
+q 1 0 0 -1 0 275.102356 cm
+652.68 114.098 m 737.715 114.098 l 737.715 185.207 l 652.68 185.207 l
+652.68 114.098 l h
+652.68 114.098 m S Q
+BT
+9.6 0 0 9.6 666.850416 118.488179 Tm
+/f-0-0 1 Tf
+[<021112>-1<1311>-1<11>-1<14>]TJ
+0 -1 Td
+[<0615161217>-1<18>]TJ
+16 0 0 16 654.277173 146.834639 Tm
+[<0206191a0d>-1<0a0c>]TJ
+ET
+1 g
+652.613 274.458 m 766.348 274.458 l 766.348 203.997 l 652.613 203.997 l
+652.613 274.458 l h
+652.613 274.458 m f
+0 g
+1.292092 w
+q 1 0 0 -1 0 275.102356 cm
+652.613 0.645 m 766.348 0.645 l 766.348 71.105 l 652.613 71.105 l
+652.613 0.645 l h
+652.613 0.645 m S Q
+0.333333 0 0 rg
+2.267717 w
+q 1 0 0 -1 0 275.102356 cm
+340.867 199.133 m 624.332 199.133 l 624.332 57.402 l 652.676 57.402 l S Q
+0 g
+640.812 223.188 m 655.68 217.723 l 640.812 212.255 l 643.188 215.485
+643.176 219.899 640.812 223.188 c h
+640.812 223.188 m f*
+1 0 0 rg
+142.441 132.661 m 255.828 132.661 l 255.828 132.661 l f*
+2.834646 w
+q 1 0 0 -1 0 275.102356 cm
+142.441 142.441 m 255.828 142.441 l 255.828 142.441 l S Q
+0 g
+157.27 125.802 m 138.688 132.634 l 157.27 139.466 l 154.301 135.434
+154.316 129.915 157.27 125.802 c h
+157.27 125.802 m f*
+241 139.52 m 259.582 132.688 l 241 125.856 l 243.969 129.891 243.949
+135.411 241 139.52 c h
+241 139.52 m f*
+0 0 1 rg
+q 1 0 0 -1 0 275.102356 cm
+142.441 199.133 m 255.828 199.133 l S Q
+0 g
+241 82.829 m 259.582 75.997 l 241 69.161 l 243.969 73.196 243.949
+78.716 241 82.829 c h
+241 82.829 m f*
+1 0 0 rg
+142.441 104.313 m 255.828 104.313 l 255.828 104.313 l f*
+q 1 0 0 -1 0 275.102356 cm
+142.441 170.789 m 255.828 170.789 l 255.828 170.789 l S Q
+0 g
+157.27 97.454 m 138.688 104.286 l 157.27 111.122 l 154.301 107.087
+154.316 101.567 157.27 97.454 c h
+157.27 97.454 m f*
+241 111.177 m 259.582 104.341 l 241 97.509 l 243.969 101.544 243.949
+107.063 241 111.177 c h
+241 111.177 m f*
+1 g
+454.254 274.395 m 567.637 274.395 l 567.637 104.313 l 454.254 104.313 l
+454.254 274.395 l h
+454.254 274.395 m f
+0 g
+1.417323 w
+q 1 0 0 -1 0 275.102356 cm
+454.254 0.707 m 567.637 0.707 l 567.637 170.789 l 454.254 170.789 l
+454.254 0.707 l h
+454.254 0.707 m S Q
+BT
+16 0 0 16 454.251978 260.220464 Tm
+/f-0-0 1 Tf
+[<081b>-1<1c>-1<1d1e>-1<0d1e>]TJ
+12.8 0 0 12.8 468.42522 231.874007 Tm
+[<08>146<1f>-1<1411>-1<20>-1<17>-1<1316>1<21131f>]TJ
+0 -1 Td
+[<191622>31<131f>-1<20>]TJ
+0 -1 Td
+<230107>Tj
+0 -1 Td
+<050303>Tj
+16 0 0 16 652.677173 260.220464 Tm
+[<1b1c>-1<0a>-1<1e1d>-1<1d>]TJ
+12.8 0 0 12.8 666.850416 231.874007 Tm
+[<1b1c>-1<24>-1<05>64<02>]TJ
+9.6 0 0 9.6 118.894483 72.768489 Tm
+<080605>Tj
+ET
+1 0 1 rg
+2.267717 w
+q 1 0 0 -1 0 275.102356 cm
+567.637 14.883 m 652.676 14.883 l 652.676 14.883 l S Q
+0 g
+640.812 265.708 m 655.68 260.243 l 640.812 254.774 l 643.188 258.005
+643.176 262.419 640.812 265.708 c h
+640.812 265.708 m f*
+BT
+9.6 0 0 9.6 595.984253 261.820464 Tm
+/f-0-0 1 Tf
+<250619>Tj
+ET
+1 0 1 rg
+q 1 0 0 -1 0 275.102356 cm
+567.637 29.055 m 652.676 29.055 l 652.676 29.055 l S Q
+0 g
+640.812 251.536 m 655.68 246.067 l 640.812 240.602 l 643.188 243.829
+643.176 248.247 640.812 251.536 c h
+640.812 251.536 m f*
+BT
+9.6 0 0 9.6 595.984253 247.647237 Tm
+/f-0-0 1 Tf
+[<10010626>-1<05>-1<01>-1<06>]TJ
+ET
+1 0 1 rg
+q 1 0 0 -1 0 275.102356 cm
+652.676 128.27 m 567.637 128.27 l 567.637 128.27 l S Q
+0 g
+555.773 152.325 m 570.641 146.856 l 555.773 141.391 l 558.148 144.618
+558.137 149.032 555.773 152.325 c h
+555.773 152.325 m f*
+BT
+9.6 0 0 9.6 595.984253 148.434639 Tm
+/f-0-0 1 Tf
+<250619>Tj
+ET
+1 0 1 rg
+q 1 0 0 -1 0 275.102356 cm
+652.676 142.441 m 567.637 142.441 l 567.637 142.441 l S Q
+0 g
+555.773 138.149 m 570.641 132.684 l 555.773 127.216 l 558.148 130.442
+558.137 134.86 555.773 138.149 c h
+555.773 138.149 m f*
+BT
+9.6 0 0 9.6 595.984253 134.261409 Tm
+/f-0-0 1 Tf
+<100106>Tj
+ET
+1 0 1 rg
+q 1 0 0 -1 0 275.102356 cm
+652.676 156.613 m 567.637 156.613 l 567.637 156.613 l S Q
+0 g
+555.773 123.977 m 570.641 118.509 l 555.773 113.044 l 558.148 116.27
+558.137 120.688 555.773 123.977 c h
+555.773 123.977 m f*
+BT
+9.6 0 0 9.6 595.984253 120.088179 Tm
+/f-0-0 1 Tf
+[<0501>-1<06>]TJ
+-32.479004 14.930446 Td
+[<1b1c>-1<01>-1<0327>]TJ
+ET
+1 1 0 rg
+q 1 0 0 -1 0 275.102356 cm
+454.254 14.883 m 142.441 14.883 l 142.441 14.883 l S Q
+0 g
+130.578 265.708 m 145.445 260.243 l 130.578 254.774 l 132.953 258.005
+132.941 262.419 130.578 265.708 c h
+130.578 265.708 m f*
+0 1 0 rg
+340.867 189.356 m 454.254 189.356 l 454.254 189.356 l 454.254 189.356 l f*
+q 1 0 0 -1 0 275.102356 cm
+340.867 85.746 m 454.254 85.746 l 454.254 85.746 l 454.254 85.746 l S Q
+0 g
+352.73 183.864 m 337.863 189.333 l 352.73 194.798 l 350.355 191.571
+350.367 187.157 352.73 183.864 c h
+352.73 183.864 m f*
+442.391 194.845 m 457.254 189.376 l 442.391 183.911 l 444.766 187.138
+444.75 191.552 442.391 194.845 c h
+442.391 194.845 m f*
+BT
+9.6 0 0 9.6 375.385816 192.554317 Tm
+/f-0-0 1 Tf
+[<2826>-1<29240211>-1<142a2b>1<2c>]TJ
+ET
+0 1 0 rg
+q 1 0 0 -1 0 275.102356 cm
+369.211 85.746 m 369.211 99.922 l 340.867 99.922 l 340.867 99.922 l S Q
+0 g
+363.723 177.493 m 369.191 192.356 l 374.656 177.493 l 371.43 179.868
+367.016 179.852 363.723 177.493 c h
+363.723 177.493 m f*
+1 1 0 rg
+q 1 0 0 -1 0 275.102356 cm
+142.441 43.227 m 255.828 43.227 l S Q
+0 g
+243.965 237.364 m 258.828 231.895 l 243.965 226.43 l 246.34 229.657
+246.324 234.071 243.965 237.364 c h
+243.965 237.364 m f*
+BT
+9.6 0 0 9.6 180.160621 235.074007 Tm
+/f-0-0 1 Tf
+[<01>-1<03>1<27>-1<1e0a>-1<19>]TJ
+ET
+0.333333 0 0 rg
+q 1 0 0 -1 0 275.102356 cm
+340.867 128.27 m 454.254 128.27 l S Q
+0 g
+442.391 152.325 m 457.254 146.856 l 442.391 141.391 l 444.766 144.618
+444.75 149.032 442.391 152.325 c h
+442.391 152.325 m f*
+BT
+9.6 0 0 9.6 374.012574 151.634639 Tm
+/f-0-0 1 Tf
+[<021c01>-1<24>-1<02>1<11>-1<14>-1<2a>1<2b2c>]TJ
+ET
+0 0 1 rg
+q 1 0 0 -1 0 275.102356 cm
+114.094 213.309 m 114.094 270 l 681.023 270 l 681.023 184.961 l S Q
+0 g
+675.535 78.278 m 681 93.145 l 686.469 78.278 l 683.242 80.653 678.824
+80.641 675.535 78.278 c h
+675.535 78.278 m f*
+BT
+9.6 0 0 9.6 227.480323 8.302352 Tm
+/f-0-0 1 Tf
+[<080605>-1<2405>44<14>-1<1f14>-1<2a>1<2a132a>]TJ
+0.166667 3.0958 Td
+[<080605>-1<2406131f>-1<16142a>]TJ
+ET
+1 1 0 rg
+q 1 0 0 -1 0 275.102356 cm
+142.441 57.402 m 255.828 57.402 l S Q
+0 g
+243.965 223.188 m 258.828 217.723 l 243.965 212.255 l 246.34 215.485
+246.324 219.899 243.965 223.188 c h
+243.965 223.188 m f*
+BT
+9.6 0 0 9.6 180.16062 220.90078 Tm
+/f-0-0 1 Tf
+[<01>-1<03>1<27>-1<0a0c>-1<27>]TJ
+ET
+1 0 1 rg
+q 1 0 0 -1 0 275.102356 cm
+709.371 71.574 m 709.371 114.094 l S Q
+0 g
+714.859 172.872 m 709.391 158.005 l 703.926 172.872 l 707.152 170.497
+711.57 170.509 714.859 172.872 c h
+714.859 172.872 m f*
+BT
+0 9.6 -9.6 0 706.170093 175.181099 Tm
+/f-0-0 1 Tf
+<250619>Tj
+ET
+1 0 1 rg
+q 1 0 0 -1 0 275.102356 cm
+681.023 71.574 m 681.023 114.094 l S Q
+0 g
+686.512 172.872 m 681.047 158.005 l 675.578 172.872 l 678.805 170.497
+683.223 170.509 686.512 172.872 c h
+686.512 172.872 m f*
+BT
+0 8.615542 -9.6 0 676.223589 162.768256 Tm
+/f-0-0 1 Tf
+[<10010626>-1<05>-1<01>-1<06>]TJ
+ET
+0 0 1 rg
+q 1 0 0 -1 0 275.102356 cm
+681.023 270 m 751.891 270 l 751.891 71.574 l 751.891 71.574 l S Q
+0 g
+685.469 5.102 m 685.469 2.598 683.438 0.567 680.934 0.567 c 678.43
+0.567 676.398 2.598 676.398 5.102 c 676.398 7.606 678.43 9.638 680.934
+9.638 c 683.438 9.638 685.469 7.606 685.469 5.102 c h
+685.469 5.102 m f*
+1.133858 w
+q 1 0 0 -1 0 275.102356 cm
+685.469 270 m 685.469 272.504 683.438 274.535 680.934 274.535 c 678.43
+274.535 676.398 272.504 676.398 270 c 676.398 267.496 678.43 265.465
+680.934 265.465 c 683.438 265.465 685.469 267.496 685.469 270 c h
+685.469 270 m S Q
+740.027 209.016 m 754.895 203.548 l 740.027 198.083 l 742.402 201.309
+742.387 205.727 740.027 209.016 c h
+740.027 209.016 m f*
+BT
+9.6 0 0 9.6 375.385816 79.168489 Tm
+/f-0-0 1 Tf
+[<020501>-1<240211>-1<142a2b>1<2c>]TJ
+ET
+0 0 1 rg
+2.267717 w
+q 1 0 0 -1 0 275.102356 cm
+199.133 199.133 m 199.133 241.652 l 482.598 241.652 l 482.598 170.789 l S Q
+0 g
+199.133 71.524 m 196.629 71.524 194.598 73.555 194.598 76.059 c 194.598
+78.563 196.629 80.595 199.133 80.595 c 201.637 80.595 203.668 78.563
+203.668 76.059 c 203.668 73.555 201.637 71.524 199.133 71.524 c h
+199.133 71.524 m f*
+1.133858 w
+q 0.000000000000000061 -1 -1 -0.000000000000000061 0 275.102356 cm
+203.578 -199.133 m 203.578 -196.629 201.547 -194.598 199.043 -194.598 c
+196.539 -194.598 194.508 -196.629 194.508 -199.133 c 194.508 -201.637
+196.539 -203.668 199.043 -203.668 c 201.547 -203.668 203.578 -201.637
+203.578 -199.133 c h
+203.578 -199.133 m S Q
+477.109 92.454 m 482.578 107.317 l 488.043 92.454 l 484.816 94.829
+480.398 94.813 477.109 92.454 c h
+477.109 92.454 m f*
+Q
+showpage
+%%Trailer
+count op_count sub {pop} repeat
+countdictstack dict_count sub {end} repeat
+cairo_eps_state restore
+%%EOF
diff --git a/2010/gsm_phone-anatomy/calypso-block.pdf b/2010/gsm_phone-anatomy/calypso-block.pdf
new file mode 100644
index 0000000..27f8be8
--- /dev/null
+++ b/2010/gsm_phone-anatomy/calypso-block.pdf
Binary files differ
diff --git a/2010/gsm_phone-anatomy/calypso-block.svg b/2010/gsm_phone-anatomy/calypso-block.svg
new file mode 100644
index 0000000..cf7d07a
--- /dev/null
+++ b/2010/gsm_phone-anatomy/calypso-block.svg
@@ -0,0 +1,778 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://creativecommons.org/ns#"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="297mm"
+ height="210mm"
+ id="svg2383"
+ sodipodi:version="0.32"
+ inkscape:version="0.47 r22583"
+ sodipodi:docname="calypso-block.pdf"
+ inkscape:output_extension="org.inkscape.output.svg.inkscape"
+ inkscape:export-filename="/home/laforge/calypso-block.png"
+ inkscape:export-xdpi="90"
+ inkscape:export-ydpi="90"
+ version="1.1">
+ <defs
+ id="defs2385">
+ <marker
+ inkscape:stockid="CurveIn"
+ orient="auto"
+ refY="0.0"
+ refX="0.0"
+ id="CurveIn"
+ style="overflow:visible">
+ <path
+ id="path3349"
+ d="M 4.6254930,-5.0456926 C 1.8654930,-5.0456926 -0.37450702,-2.8056926 -0.37450702,-0.045692580 C -0.37450702,2.7143074 1.8654930,4.9543074 4.6254930,4.9543074"
+ style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt;marker-start:none;marker-end:none;fill:none"
+ transform="scale(0.6)" />
+ </marker>
+ <marker
+ inkscape:stockid="DotM"
+ orient="auto"
+ refY="0.0"
+ refX="0.0"
+ id="DotM"
+ style="overflow:visible">
+ <path
+ id="path3229"
+ d="M -2.5,-1.0 C -2.5,1.7600000 -4.7400000,4.0 -7.5,4.0 C -10.260000,4.0 -12.5,1.7600000 -12.5,-1.0 C -12.5,-3.7600000 -10.260000,-6.0 -7.5,-6.0 C -4.7400000,-6.0 -2.5,-3.7600000 -2.5,-1.0 z "
+ style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt;marker-start:none;marker-end:none"
+ transform="scale(0.4) translate(7.4, 1)" />
+ </marker>
+ <marker
+ inkscape:stockid="Arrow2Mstart"
+ orient="auto"
+ refY="0.0"
+ refX="0.0"
+ id="Arrow2Mstart"
+ style="overflow:visible">
+ <path
+ id="path7719"
+ style="font-size:12.0;fill-rule:evenodd;stroke-width:0.62500000;stroke-linejoin:round"
+ d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.9730900,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
+ transform="scale(0.6) translate(0,0)" />
+ </marker>
+ <marker
+ inkscape:stockid="Arrow2Mend"
+ orient="auto"
+ refY="0.0"
+ refX="0.0"
+ id="Arrow2Mend"
+ style="overflow:visible;">
+ <path
+ id="path3191"
+ style="font-size:12.0;fill-rule:evenodd;stroke-width:0.62500000;stroke-linejoin:round;"
+ d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.9730900,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
+ transform="scale(0.6) rotate(180) translate(0,0)" />
+ </marker>
+ <marker
+ inkscape:stockid="Arrow1Send"
+ orient="auto"
+ refY="0.0"
+ refX="0.0"
+ id="Arrow1Send"
+ style="overflow:visible;">
+ <path
+ id="path3179"
+ d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z "
+ style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt;marker-start:none;"
+ transform="scale(0.2) rotate(180) translate(6,0)" />
+ </marker>
+ <marker
+ inkscape:stockid="Arrow1Mend"
+ orient="auto"
+ refY="0.0"
+ refX="0.0"
+ id="Arrow1Mend"
+ style="overflow:visible;">
+ <path
+ id="path3173"
+ d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z "
+ style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt;marker-start:none;"
+ transform="scale(0.4) rotate(180) translate(10,0)" />
+ </marker>
+ <marker
+ inkscape:stockid="TriangleOutL"
+ orient="auto"
+ refY="0.0"
+ refX="0.0"
+ id="TriangleOutL"
+ style="overflow:visible">
+ <path
+ id="path3307"
+ d="M 5.77,0.0 L -2.88,5.0 L -2.88,-5.0 L 5.77,0.0 z "
+ style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt;marker-start:none"
+ transform="scale(0.8)" />
+ </marker>
+ <marker
+ inkscape:stockid="Arrow2Lend"
+ orient="auto"
+ refY="0.0"
+ refX="0.0"
+ id="Arrow2Lend"
+ style="overflow:visible;">
+ <path
+ id="path3185"
+ style="font-size:12.0;fill-rule:evenodd;stroke-width:0.62500000;stroke-linejoin:round;"
+ d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.9730900,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
+ transform="scale(1.1) rotate(180) translate(1,0)" />
+ </marker>
+ <marker
+ inkscape:stockid="Arrow1Lend"
+ orient="auto"
+ refY="0.0"
+ refX="0.0"
+ id="Arrow1Lend"
+ style="overflow:visible;">
+ <path
+ id="path3188"
+ d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z "
+ style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt;marker-start:none;"
+ transform="scale(0.8) rotate(180) translate(12.5,0)" />
+ </marker>
+ <inkscape:perspective
+ sodipodi:type="inkscape:persp3d"
+ inkscape:vp_x="0 : 372.04724 : 1"
+ inkscape:vp_y="0 : 1000 : 0"
+ inkscape:vp_z="1052.3622 : 372.04724 : 1"
+ inkscape:persp3d-origin="526.18109 : 248.03149 : 1"
+ id="perspective2392" />
+ </defs>
+ <sodipodi:namedview
+ inkscape:document-units="mm"
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1.0"
+ inkscape:pageopacity="0.0"
+ inkscape:pageshadow="2"
+ inkscape:zoom="0.96166971"
+ inkscape:cx="267.27075"
+ inkscape:cy="495.79724"
+ inkscape:current-layer="layer1"
+ id="namedview2387"
+ showgrid="true"
+ inkscape:snap-global="true"
+ inkscape:window-width="599"
+ inkscape:window-height="987"
+ inkscape:window-x="0"
+ inkscape:window-y="0"
+ inkscape:snap-guide="true"
+ inkscape:object-paths="false"
+ inkscape:object-nodes="false"
+ objecttolerance="3"
+ gridtolerance="10000"
+ inkscape:window-maximized="0">
+ <inkscape:grid
+ type="xygrid"
+ id="grid2400"
+ visible="true"
+ enabled="true"
+ units="mm"
+ spacingx="5mm"
+ spacingy="5mm"
+ empspacing="2" />
+ </sodipodi:namedview>
+ <metadata
+ id="metadata2389">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ <dc:title></dc:title>
+ </cc:Work>
+ </rdf:RDF>
+ </metadata>
+ <g
+ inkscape:label="Layer 1"
+ inkscape:groupmode="layer"
+ id="layer1">
+ <path
+ style="fill:none;stroke:#000000;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#CurveIn)"
+ d="m 956.69293,230.31495 53.14957,0 0,-70.86614 0,0"
+ id="path22123" />
+ <g
+ id="g12239"
+ transform="translate(-35.433051,2.2643947e-6)">
+ <rect
+ y="35.433064"
+ x="70.866142"
+ height="265.74802"
+ width="177.16536"
+ id="rect7161"
+ style="fill:#ffffff;stroke:#000000;stroke-width:1.77165353;stroke-miterlimit:4;stroke-dasharray:none" />
+ <text
+ sodipodi:linespacing="100%"
+ id="text7163"
+ y="53.149601"
+ x="72.866142"
+ style="font-size:20px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="53.149601"
+ x="72.866142"
+ id="tspan7165"
+ sodipodi:role="line">CALYPSO</tspan><tspan
+ y="73.149597"
+ x="72.866142"
+ sodipodi:role="line"
+ id="tspan3020">Digital Baseband</tspan><tspan
+ y="93.149597"
+ x="72.866142"
+ sodipodi:role="line"
+ id="tspan3024"></tspan><tspan
+ y="93.149597"
+ x="72.866142"
+ sodipodi:role="line"
+ id="tspan3036">DSP</tspan><tspan
+ y="113.1496"
+ x="72.866142"
+ sodipodi:role="line"
+ id="tspan3026">MCU</tspan><tspan
+ y="133.1496"
+ x="72.866142"
+ sodipodi:role="line"
+ id="tspan3028">SRAM</tspan><tspan
+ y="153.1496"
+ x="72.866142"
+ sodipodi:role="line"
+ id="tspan3030">Mask ROM</tspan><tspan
+ y="173.1496"
+ x="72.866142"
+ sodipodi:role="line"
+ id="tspan3032">UART, SPI, I2C</tspan></text>
+ </g>
+ <g
+ id="g20347"
+ transform="translate(-35.433051,2.2643947e-6)">
+ <rect
+ y="70.77356"
+ x="389.63159"
+ height="230.24446"
+ width="106.56361"
+ id="rect2406"
+ style="fill:#ffffff;stroke:#000000;stroke-width:1.50725651;stroke-miterlimit:4;stroke-dasharray:none" />
+ <text
+ transform="scale(1.0221827,0.9782987)"
+ sodipodi:linespacing="100%"
+ id="text7157"
+ y="92.63372"
+ x="381.30542"
+ style="font-size:21.45465279px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="92.63372"
+ x="381.30542"
+ id="tspan7159"
+ sodipodi:role="line">TWL3025</tspan><tspan
+ y="114.08837"
+ x="381.30542"
+ sodipodi:role="line"
+ id="tspan3038">ABB</tspan></text>
+ <text
+ sodipodi:linespacing="100%"
+ id="text12244"
+ y="216.1601"
+ x="394.66666"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="216.1601"
+ x="394.66666"
+ id="tspan12246"
+ sodipodi:role="line">BSP</tspan></text>
+ <text
+ sodipodi:linespacing="100%"
+ id="text12248"
+ y="252.99342"
+ x="395.16666"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="252.99342"
+ x="395.16666"
+ id="tspan12250"
+ sodipodi:role="line">USP</tspan></text>
+ <text
+ sodipodi:linespacing="100%"
+ id="text12252"
+ y="286.42783"
+ x="396.16666"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="286.42783"
+ x="396.16666"
+ id="tspan12254"
+ sodipodi:role="line">TSP</tspan></text>
+ <text
+ sodipodi:linespacing="100%"
+ id="text20330"
+ y="163.44881"
+ x="464.62991"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="163.44881"
+ x="464.62991"
+ id="tspan20332"
+ sodipodi:role="line">BUL</tspan></text>
+ <text
+ sodipodi:linespacing="100%"
+ id="text20334"
+ y="146.96971"
+ x="463.70053"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="146.96971"
+ x="463.70053"
+ id="tspan20336"
+ sodipodi:role="line">BDL</tspan></text>
+ </g>
+ <g
+ id="g13450"
+ transform="translate(-35.433051,2.2643947e-6)">
+ <rect
+ y="177.16687"
+ x="885.82831"
+ height="88.888702"
+ width="106.29617"
+ id="rect12310"
+ style="fill:#ffffff;stroke:#000000;stroke-width:1.77468574;stroke-miterlimit:4;stroke-dasharray:none" />
+ <text
+ sodipodi:linespacing="100%"
+ id="text13440"
+ y="230.31496"
+ x="903.54333"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="230.31496"
+ x="903.54333"
+ id="tspan13442"
+ sodipodi:role="line">Antenna</tspan><tspan
+ id="tspan13444"
+ y="242.31496"
+ x="903.54333"
+ sodipodi:role="line">Switch</tspan></text>
+ <text
+ sodipodi:linespacing="100%"
+ id="text13446"
+ y="194.88188"
+ x="887.82678"
+ style="font-size:20px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="194.88188"
+ x="887.82678"
+ id="tspan13448"
+ sodipodi:role="line">ASM4532</tspan></text>
+ </g>
+ <rect
+ style="fill:#ffffff;stroke:#000000;stroke-width:1.61511528;stroke-miterlimit:4;stroke-dasharray:none"
+ id="rect11596"
+ width="142.16623"
+ height="88.074844"
+ x="850.31543"
+ y="35.354797" />
+ <path
+ style="fill:none;stroke:#550000;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)"
+ d="m 460.62994,283.46456 354.33071,0 0,-177.16535 35.43307,0"
+ id="path21554" />
+ <path
+ style="fill:#ff0000;fill-rule:evenodd;stroke:#ff0000;stroke-width:3.54330707;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-start:url(#Arrow2Mstart);marker-end:url(#Arrow2Mend)"
+ d="m 212.59845,212.59842 141.73228,0 0,0"
+ id="path7167" />
+ <path
+ style="fill:none;stroke:#0000ff;stroke-width:3.54330707;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)"
+ d="m 212.59845,283.46456 141.73228,0"
+ id="path7171" />
+ <path
+ style="fill:#ff0000;fill-rule:evenodd;stroke:#ff0000;stroke-width:3.54330707;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-start:url(#Arrow2Mstart);marker-end:url(#Arrow2Mend)"
+ d="m 212.59844,248.03149 141.73229,0 0,0"
+ id="path9925" />
+ <g
+ id="g12217"
+ transform="translate(-35.433051,2.2643947e-6)">
+ <rect
+ y="35.433064"
+ x="637.79529"
+ height="212.59842"
+ width="141.73228"
+ id="rect2408"
+ style="fill:#ffffff;stroke:#000000;stroke-width:1.77165353;stroke-miterlimit:4;stroke-dasharray:none" />
+ <text
+ sodipodi:linespacing="125%"
+ id="text7153"
+ y="53.149601"
+ x="637.79529"
+ style="font-size:20px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ id="tspan11602"
+ y="53.149601"
+ x="637.79529"
+ sodipodi:role="line">TRF6151</tspan></text>
+ <text
+ sodipodi:linespacing="100%"
+ id="text12175"
+ y="88.582672"
+ x="655.51184"
+ style="font-size:16px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="88.582672"
+ x="655.51184"
+ id="tspan12177"
+ sodipodi:role="line">Transceiver</tspan><tspan
+ id="tspan12179"
+ y="104.58267"
+ x="655.51184"
+ sodipodi:role="line">Mixers</tspan><tspan
+ id="tspan12183"
+ y="120.58267"
+ x="655.51184"
+ sodipodi:role="line">VCO</tspan><tspan
+ id="tspan12181"
+ y="136.58267"
+ x="655.51184"
+ sodipodi:role="line">PLL</tspan></text>
+ </g>
+ <text
+ xml:space="preserve"
+ style="font-size:20px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+ x="850.39374"
+ y="53.149605"
+ id="text11598"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan11600"
+ x="850.39374"
+ y="53.149605">RF3166</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:16px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+ x="868.11029"
+ y="88.582672"
+ id="text12185"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ x="868.11029"
+ y="88.582672"
+ id="tspan12193">RF PA</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+ x="183.16537"
+ y="287.46457"
+ id="text12256"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan12258"
+ x="183.16537"
+ y="287.46457">TSP</tspan></text>
+ <g
+ id="g12268"
+ transform="translate(-35.433051,2.2643947e-6)">
+ <path
+ id="path11606"
+ d="m 779.52756,53.149601 106.29921,0 0,0"
+ style="fill:none;stroke:#ff00ff;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" />
+ <text
+ sodipodi:linespacing="100%"
+ id="text12260"
+ y="51.149601"
+ x="814.96063"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="51.149601"
+ x="814.96063"
+ id="tspan12262"
+ sodipodi:role="line">GSM</tspan></text>
+ </g>
+ <g
+ id="g12273"
+ transform="translate(-35.433051,2.2643947e-6)">
+ <path
+ id="path12195"
+ d="m 779.52756,70.866136 106.29921,0 0,0"
+ style="fill:none;stroke:#ff00ff;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" />
+ <text
+ sodipodi:linespacing="100%"
+ id="text12264"
+ y="68.866135"
+ x="814.96063"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="68.866135"
+ x="814.96063"
+ id="tspan12266"
+ sodipodi:role="line">DCS/PCS</tspan></text>
+ </g>
+ <g
+ id="g12290"
+ transform="translate(-35.433051,2.2643947e-6)">
+ <path
+ id="path12197"
+ d="m 885.82677,194.88188 -106.29921,0 0,0"
+ style="fill:none;stroke:#ff00ff;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" />
+ <text
+ sodipodi:linespacing="100%"
+ id="text12278"
+ y="192.88188"
+ x="814.96063"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="192.88188"
+ x="814.96063"
+ id="tspan12280"
+ sodipodi:role="line">GSM</tspan></text>
+ </g>
+ <g
+ id="g12295"
+ transform="translate(-35.433051,2.2643947e-6)">
+ <path
+ id="path12165"
+ d="m 885.82677,212.59841 -106.29921,0 0,0"
+ style="fill:none;stroke:#ff00ff;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" />
+ <text
+ sodipodi:linespacing="100%"
+ id="text12282"
+ y="210.59842"
+ x="814.96063"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="210.59842"
+ x="814.96063"
+ id="tspan12284"
+ sodipodi:role="line">DCS</tspan></text>
+ </g>
+ <g
+ id="g12300"
+ transform="translate(-35.433051,2.2643947e-6)">
+ <path
+ id="path12199"
+ d="m 885.82677,230.31495 -106.29921,0 0,0"
+ style="fill:none;stroke:#ff00ff;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" />
+ <text
+ sodipodi:linespacing="100%"
+ id="text12286"
+ y="228.31496"
+ x="814.96063"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="228.31496"
+ x="814.96063"
+ id="tspan12288"
+ sodipodi:role="line">PCS</tspan></text>
+ </g>
+ <g
+ id="g18005"
+ transform="translate(-35.433051,2.2643947e-6)">
+ <text
+ sodipodi:linespacing="100%"
+ id="text14594"
+ y="49.149601"
+ x="425.21259"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ id="tspan14598"
+ y="49.149601"
+ x="425.21259"
+ sodipodi:role="line">RFCLK</tspan></text>
+ <path
+ id="path14605"
+ d="m 637.79528,53.149601 -389.76378,0 0,0"
+ style="fill:none;stroke:#ffff00;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" />
+ </g>
+ <g
+ id="g18583"
+ transform="translate(-35.433051,2.2643947e-6)">
+ <path
+ inkscape:label="#path2410"
+ id="path241011111"
+ d="m 496.06299,141.73228 141.73229,0 0,0 0,0"
+ style="fill:#00ff00;fill-rule:evenodd;stroke:#00ff00;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-start:url(#Arrow2Mstart);marker-end:url(#Arrow2Mend)" />
+ <text
+ sodipodi:linespacing="100%"
+ id="text12167"
+ y="137.73228"
+ x="539.21259"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="137.73228"
+ x="539.21259"
+ id="tspan12169"
+ sodipodi:role="line">I/Q Analog</tspan></text>
+ <path
+ id="path15170"
+ d="m 531.49606,141.73228 0,17.71653 -35.43307,0 0,0"
+ style="fill:none;stroke:#00ff00;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-start:url(#Arrow2Mstart)" />
+ </g>
+ <g
+ id="g18000"
+ transform="translate(-35.433051,2.2643947e-6)">
+ <path
+ id="path17431"
+ d="m 248.0315,88.582671 141.73228,0"
+ style="fill:none;stroke:#ffff00;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" />
+ <text
+ sodipodi:linespacing="100%"
+ id="text17996"
+ y="84.582672"
+ x="295.18109"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="84.582672"
+ x="295.18109"
+ id="tspan17998"
+ sodipodi:role="line">CLK13M</tspan></text>
+ </g>
+ <g
+ id="g18593"
+ transform="translate(-35.433051,2.2643947e-6)">
+ <path
+ id="path18010"
+ d="m 496.06299,194.88188 141.73229,0"
+ style="fill:none;stroke:#550000;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" />
+ <text
+ sodipodi:linespacing="100%"
+ id="text18589"
+ y="188.88188"
+ x="537.49603"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="188.88188"
+ x="537.49603"
+ id="tspan18591"
+ sodipodi:role="line">AFC Analog</tspan></text>
+ </g>
+ <path
+ style="fill:none;stroke:#0000ff;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)"
+ d="m 177.16538,301.1811 0,70.86614 708.66141,0 0,-106.29921"
+ id="path19726" />
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+ x="318.89767"
+ y="368.04724"
+ id="text20291"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan20293"
+ x="318.89767"
+ y="368.04724">TSP Parallel</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+ x="320.89767"
+ y="330.89764"
+ id="text20295"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan20297"
+ x="320.89767"
+ y="330.89764">TSP Serial</tspan></text>
+ <g
+ id="g20314"
+ transform="translate(-35.433052,-17.716531)">
+ <path
+ id="path20301"
+ d="m 248.0315,124.01574 141.73228,0"
+ style="fill:none;stroke:#ffff00;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" />
+ <text
+ sodipodi:linespacing="100%"
+ id="text20303"
+ y="120.01574"
+ x="295.18109"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ id="tspan20310"
+ y="120.01574"
+ x="295.18109"
+ sodipodi:role="line">CLK32K</tspan></text>
+ </g>
+ <g
+ id="g20421"
+ transform="translate(-35.433051,2.2643947e-6)">
+ <path
+ id="path12871"
+ d="m 956.69291,124.01574 0,53.14961"
+ style="fill:none;stroke:#ff00ff;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)" />
+ <text
+ transform="matrix(0,-1,1,0,0,0)"
+ sodipodi:linespacing="100%"
+ id="text20402"
+ y="952.69293"
+ x="-159.44881"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="952.69293"
+ x="-159.44881"
+ id="tspan20404"
+ sodipodi:role="line">GSM</tspan></text>
+ </g>
+ <g
+ id="g20415"
+ transform="translate(-35.433051,2.2643947e-6)">
+ <g
+ id="g20410">
+ <path
+ style="fill:none;stroke:#ff00ff;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)"
+ d="m 921.25984,124.01574 0,53.14961"
+ id="path12312" />
+ <text
+ xml:space="preserve"
+ style="font-size:11.36807537px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+ x="-184.69075"
+ y="867.06183"
+ id="text20406"
+ sodipodi:linespacing="100%"
+ transform="matrix(0,-0.9473396,1.0555877,0,0,0)"><tspan
+ sodipodi:role="line"
+ id="tspan20408"
+ x="-184.69075"
+ y="867.06183">DCS/PCS</tspan></text>
+ </g>
+ </g>
+ <path
+ style="fill:none;stroke:#0000ff;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-start:url(#DotM);marker-end:url(#Arrow2Mend)"
+ d="m 885.82679,372.04724 88.58266,0 0,-248.0315 0,0"
+ id="path20426" />
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+ x="503.77954"
+ y="279.46457"
+ id="text22119"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan22121"
+ x="503.77954"
+ y="279.46457">APC Analog</tspan></text>
+ <path
+ style="fill:none;stroke:#0000ff;stroke-width:2.83464575;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-start:url(#DotM);marker-end:url(#Arrow2Mend)"
+ d="m 283.46459,283.46456 0,53.14961 354.33071,0 0,-88.58268"
+ id="path18598" />
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
+ x="258.43008"
+ y="206.35927"
+ id="text3040"><tspan
+ sodipodi:role="line"
+ id="tspan3042"
+ x="258.43008"
+ y="206.35927">I/Q Digital</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
+ x="259.96451"
+ y="237.68361"
+ id="text3044"><tspan
+ sodipodi:role="line"
+ id="tspan3046"
+ x="259.96451"
+ y="237.68361">SPI</tspan></text>
+ </g>
+</svg>
diff --git a/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.1.pdf b/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.1.pdf
new file mode 100644
index 0000000..b91c574
--- /dev/null
+++ b/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.1.pdf
Binary files differ
diff --git a/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.2.pdf b/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.2.pdf
new file mode 100644
index 0000000..d90ca5a
--- /dev/null
+++ b/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.2.pdf
Binary files differ
diff --git a/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.2.tex b/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.2.tex
new file mode 100644
index 0000000..72e707c
--- /dev/null
+++ b/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.2.tex
@@ -0,0 +1,674 @@
+\documentclass[a4paper]{article}
+\usepackage[english]{babel}
+\usepackage{graphicx}
+\usepackage{subfigure}
+\pagestyle{plain}
+
+%\usepackage{url}
+
+\setlength{\oddsidemargin}{0in}
+\setlength{\evensidemargin}{0in}
+\setlength{\topmargin}{0in}
+\setlength{\headheight}{0in}
+\setlength{\headsep}{0in}
+\setlength{\textwidth}{6.5in}
+\setlength{\textheight}{9.5in}
+%\setlength{\parindent}{0in}
+\setlength{\parskip}{0.05in}
+
+\begin{document}
+
+\title{Anatomy of contemporary GSM cellphone hardware}
+\author{Harald Welte $<$laforge@gnumonks.org$>$}
+\maketitle
+
+\begin{abstract}
+%% add citation for the nubmer of gsm users and phones / carriers.
+Billions of cell phones are being used every day by an almost equally large
+number of users. The majority of those phones are built according to
+the GSM protocol and interoperate with GSM networks of hundreds of
+carriers.
+
+Despite being an openly published international standard, the architecture of
+the GSM network and its associated protocols are only known to a relatively
+small group of R\&D engineers.
+
+Even less public information exists about the hardware architecture of the
+actual mobile phones themselves, at least as far as it relates to that part
+of the phone implementing the GSM protocols and facilitating access to the
+public GSM networks.
+
+This paper is an attempt to serve as an introductory text into the hardware
+architecture of contemporary GSM mobile phone hardware anatomy. It is intended
+to widen the technical background on mobile phones within the IT community.
+\end{abstract}
+
+%\tableofcontents
+
+\section{Foreword}
+
+This document is the result of my personal research on mobile phone
+hardware and system-level software throughout the last 6+ years.
+
+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.
+
+I hope it is useful for any systems level engineer with an interest in
+understanding more about how mobile phone hardware actually works.
+
+There are no guarantees for accuracy or correctness of any part of the
+document. I happily receive your feedback and corrections.
+
+\section{Is your phone smart or does it have features?}
+
+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.
+
+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.
+
+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 {\em smartphone}. At that point there was a
+need to differentiate from those phones that were not-so-smart. Those
+phones were then called {\em feature phones}.
+
+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.
+
+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:
+
+\subsection{Feature Phone}
+
+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 {\em baseband processor} (BP).
+
+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.
+
+\subsection{Smartphone}
+
+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
+{\em application processor} (AP).
+
+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 {\em GSM modem},
+controlled by AT commands sent from the AP.
+
+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.
+
+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.
+
+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.
+
+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.
+
+\section{GSM modem architecture}
+
+Every GSM phone, feature phone and smartphone alike, has a GSM modem interfacing
+with the GSM network.
+
+This GSM modem consists of several parts:
+\begin{itemize}
+\item RF Frontend, responsible for receiving and transmitting at GSM frequency
+\item Analog Baseband, responsible for modulation and demodulation
+\item Digital Baseband, responsible for digital signal processing and the GSM protocol stack
+\end{itemize}
+
+\begin{figure}[h]
+\centering
+\includegraphics[width=160mm]{calypso-block.pdf}
+\caption{Block schematics of a TI Calypso/Iota/Rita GSM modem}
+\label{reg-form}
+\end{figure}
+
+\subsection{The RF Frontend}
+
+The RF Frontend is tasked with the physical receive and transmit
+interface with the GSM air interface (sometimes called Um interface).
+
+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.
+
+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.
+
+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 single-pole 6-throw (SP6T)
+switch is used: 4 for the four Rx bands (one for each band), and 2 for
+Tx (where 850+900 and 1800+1900 each share one PA output, respectively).
+
+\subsubsection{RF Frontend receive path}
+
+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.
+
+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.
+
+The baseband signal is then filtered to remove unwanted images and sent
+as analog I/Q signals (representing amplitude and phase) to the ABB.
+
+\subsubsection{RF Frontend transmit path}
+
+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.
+
+\subsubsection{Local Oscillator}
+
+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.
+
+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.
+
+\subsection{The Analog Baseband (ABB)}
+
+The ABB part of a GSM modem is responsible to interface between the
+digital domain and the analog domain of the GSM modem.
+
+\subsubsection{ABB Receive path}
+
+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.
+
+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.
+
+\subsubsection{ABB Transmit path}
+
+There are multiple architectures found in the ABB transmit path.
+
+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.
+
+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.
+
+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.
+
+\subsection{The Digital Baseband (DBB)}
+
+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.
+
+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.
+
+\subsubsection{Digital Signal Processor}
+
+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, ...).
+
+The DSP performs the primary tasks such as Viterbi equalization,
+demodulation, decoding, forward error correction, error detection, burst
+(de)interleaving.
+
+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.
+
+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.
+
+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.
+
+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).
+
+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).
+
+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.
+
+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.
+
+\subsubsection{DSP Peripherals}
+
+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. %% cite
+
+Thus, the DSP in a DBB commonly has a integrated peripheral implementing the A5
+encryption.
+
+Further integrated DSP peripherals may include a viterbi hardware accelerator,
+a DMA capable serial interface to the ABB and others.
+
+\subsection{Baseband Processor (MCU)}
+
+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.
+
+Baseband chips that support 3G cellular networks often use a more powerful
+ARM926 or ARM975 core as MCU.
+
+\subsection{MCU peripherals}
+
+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, ...
+
+However, there are some additional peripherals that are very GSM specific:
+\begin{itemize}
+\item A GPRS crypto unit for the proprietary GEA family of ciphers
+\item 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
+\item GSM TDMA timers that can synchronize to the on-air time frames and generate interrupts to MCU and DSP
+\item Software-programmable hardware state machines for sequencing GSM burst Rx or Tx in ABB and RF Frontend
+\item An ISO7816 compatible smart card reader interface for the SIM card
+\end{itemize}
+
+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.
+
+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.
+
+However, as opposed to the DSP API documentation, the register-level
+documentation to the MCU peripherals is normally provided to the cellphone
+manufacturers.
+
+\section{Digital Baseband Software Architecture}
+
+This section provides an introductory reading in the typical software
+architecture as it is found on contemporary GSM digital baseband designs.
+
+\subsection{GSM Layer 1}
+
+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.
+
+However, there are some general observations that can be made about the L1:
+
+\subsubsection{L1 Synchronous part}
+
+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.
+
+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.
+
+\subsubsection{L1 Asynchronous part}
+
+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.
+
+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.
+
+\subsection{GSM Layer 2}
+
+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.
+
+LAPDm takes care of providing communication channels for Layer3. Those
+channels are protected from frame loss by the use of sequence numbers and
+retransmissions.
+
+The interface to Layer3 is typically implemented by means of a message queue.
+
+Primitives (but no detailed protocol) for use of the Layer2 / Layer3 interface
+are provided in the GSM specifications.
+
+\subsection{GSM Layer 3}
+
+GSM Layer 3 (L3) consist of sublayers for Radio Resource (RR), Mobility
+Management (MM) and Call Control (CC).
+
+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.
+
+\section{Synchronization and Clocking}
+
+The author of this paper has been quoted saying {\em GSM is a synchronous
+TDMA nightmare}. 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.
+
+GSM is synchronous in multiple ways between cell (BTS) and phone (MS):
+\begin{itemize}
+\item Synchronization of the carrier clock to tune the receiver and transmitter to the correct frequency
+\item Synchronization of the bit clock in order to perform sampling at the most optimal sample intervals
+\item Synchronization of the frame clock (and thus timeslots) to know when a TDMA frame and its 8 timeslots start
+\item Synchronization of the TDMA multiplex to correctly (de)multiplex the logical channels that are sent over each timeslots
+\end{itemize}
+
+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.
+
+\subsection{How to synchronize the VCTCXO}
+
+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.
+
+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.
+
+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.
+
+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.
+
+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.
+
+\subsection{How to synchronize the frame clock}
+
+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.
+
+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.
+
+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.
+
+\subsection{How to synchronize the GSM TDMA multiplex}
+
+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.
+
+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.
+
+\section{Miscellaneous Topics}
+\subsection{GPRS}
+
+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.
+
+The L1 and L2 protocols are very different (and much more complex) than GSM.
+
+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.
+
+\subsection{EDGE}
+
+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.
+
+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.
+
+\subsection{UMTS}
+
+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.
+
+UMTS Layer2 has some resemblance to the GPRS Layer2.
+
+UMTS Layer3 for Mobility Management and Call Control are very similar to GSM.
+
+Given the vast physical layer and L1 differences, a UMTS phone hardware design
+significantly differs from what has been described in this document.
+
+Notwithstanding, all known commercial UMTS phone chipsets as of today still
+include a full GSM modem in hardware and software to remain
+backwards-compatible.
+
+\subsection{Dual-SIM and Triple-SIM phones}
+
+In recent years, a large number of so-called {\em Dual-SIM} or even {\em
+Triple-SIM} phones have entered the market, particularly in China and other
+parts of East Asia.
+
+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.
+
+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, ...
+
+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.
+
+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.
+
+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.
+
+\subsection{Powerful feature phones}
+
+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.
+
+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.
+
+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.
+
+\section{Personal rant on the closedness of the GSM industry}
+
+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.
+
+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.
+
+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.
+
+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.
+
+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.
+
+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.
+
+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.
+
+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?
+
+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.
+
+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. {\em They all cook with water}, 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.
+
+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.
+
+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.
+
+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.
+
+They still don't happen on the baseband processor, which is as closed as
+it was 15 years ago.
+
+\end{document}
diff --git a/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.3.pdf b/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.3.pdf
new file mode 100644
index 0000000..e666c7a
--- /dev/null
+++ b/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.3.pdf
Binary files differ
diff --git a/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.3.tex b/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.3.tex
new file mode 100644
index 0000000..fe1e73d
--- /dev/null
+++ b/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.3.tex
@@ -0,0 +1,770 @@
+\documentclass[a4paper]{article}
+\usepackage[english]{babel}
+\usepackage{graphicx}
+\usepackage{subfigure}
+\pagestyle{plain}
+
+%\usepackage{url}
+
+\setlength{\oddsidemargin}{0in}
+\setlength{\evensidemargin}{0in}
+\setlength{\topmargin}{0in}
+\setlength{\headheight}{0in}
+\setlength{\headsep}{0in}
+\setlength{\textwidth}{6.5in}
+\setlength{\textheight}{9.5in}
+%\setlength{\parindent}{0in}
+\setlength{\parskip}{0.05in}
+
+\begin{document}
+
+\title{Anatomy of contemporary GSM cellphone hardware}
+\author{Harald Welte $<$laforge@gnumonks.org$>$}
+\maketitle
+
+\begin{abstract}
+%% add citation for the nubmer of gsm users and phones / carriers.
+Billions of cell phones are being used every day by an almost equally large
+number of users. The majority of those phones are built according to
+the GSM protocol specifications and interoperate with GSM networks of hundreds
+of carriers.
+
+Despite being an openly published international standard, the architecture of
+GSM networks and its associated protocols are only known to a relatively
+small group of R\&D engineers.
+
+Even less public information exists about the hardware architecture of the
+actual mobile phones themselves, at least as far as it relates to that part
+of the phone implementing the GSM protocols and facilitating access to the
+public GSM networks.
+
+This paper is an attempt to serve as an introductory text into the hardware
+architecture of contemporary GSM mobile phone hardware anatomy. It is intended
+to widen the technical background on mobile phones within the IT community.
+\end{abstract}
+
+%\tableofcontents
+
+\section{Foreword}
+
+This document is the result of my personal research on mobile phone
+hardware and system-level software throughout the last six years.
+
+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.
+
+I hope it is useful for any systems level engineer with an interest in
+understanding more about how mobile phone hardware actually works.
+
+There are no guarantees for accuracy or correctness of any part of the
+document. I happily receive your feedback and corrections.
+
+\section{Is your phone smart or does it have features?}
+
+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.
+
+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.
+
+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 {\em smartphone}. At that point there was a
+need to differentiate from those phones that were not-so-smart. Those
+phones were then called {\em feature phones}.
+
+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.
+
+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:
+
+\subsection{Feature Phone}
+
+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 {\em baseband processor} (BP).
+
+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.
+
+\subsection{Smartphone}
+
+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
+{\em application processor} (AP).
+
+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 {\em GSM modem},
+controlled by AT commands sent from the AP.
+
+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 those seen in the personal computer industry.
+
+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.
+
+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.
+
+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.
+
+\section{GSM modem architecture}
+
+Every GSM phone, feature phone and smartphone alike, has a GSM modem interfacing
+with the GSM network.
+
+This GSM modem consists of several parts:
+\begin{itemize}
+\item RF Frontend, responsible for receiving and transmitting on GSM frequencies
+\item Analog Baseband, responsible for modulation and demodulation
+\item Digital Baseband, responsible for digital signal processing and the GSM protocol stack
+\end{itemize}
+
+\begin{figure}[h]
+\centering
+\includegraphics[width=160mm]{calypso-block.pdf}
+\caption{Block schematics of a TI Calypso/Iota/Rita GSM modem}
+\label{reg-form}
+\end{figure}
+
+\subsection{The RF Frontend}
+
+The RF Frontend is tasked with the physical receive and transmit
+interface with the GSM air interface (sometimes called Um interface).
+
+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.
+
+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.
+
+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 single-pole 6-throw (SP6T)
+switch is used: 4 for the four Rx bands (one for each band), and 2 for
+Tx (where 850+900 and 1800+1900 each share one PA output, respectively).
+
+\subsubsection{RF Frontend receive path}
+
+The antenna picks up the GSM radio signal as it is sent from a GSM cell tower
+(properly called a Base Transceiver Station, or abbreviated as 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.
+
+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.
+
+The baseband signal is then filtered to remove unwanted images and sent
+as analog I/Q signals (representing amplitude and phase) to the ABB.
+
+\subsubsection{RF Frontend transmit path}
+
+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.
+
+\subsubsection{Local Oscillator}
+
+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.
+
+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.
+
+\subsection{The Analog Baseband (ABB)}
+
+The ABB part of a GSM modem is responsible to interface between the
+digital domain and the analog domain of the GSM modem.
+
+\subsubsection{ABB Receive path}
+
+The analog baseband I/Q signals are potentially filtered again and
+digitized by an 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.
+
+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.
+
+\subsubsection{ABB Transmit path}
+
+There are multiple architectures found in the ABB transmit path.
+
+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.
+
+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.
+
+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.
+
+\subsection{The Digital Baseband (DBB)}
+
+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.
+
+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.
+
+\subsubsection{Digital Signal Processor}
+
+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, ...).
+
+The DSP performs the primary tasks such as Viterbi equalization,
+demodulation, decoding, forward error correction, error detection, burst
+(de)interleaving.
+
+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.
+
+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.
+
+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.
+
+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
+devices take care of the modulation to reduce DSP load).
+
+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).
+
+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.
+
+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.
+
+\subsubsection{DSP Peripherals}
+
+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. %% cite
+
+Thus, the DSP in a DBB commonly has a integrated peripheral implementing the A5
+encryption.
+
+Further integrated DSP peripherals may include a viterbi hardware accelerator,
+a DMA capable serial interface to the ABB and others.
+
+\subsection{Baseband Processor (MCU)}
+
+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.
+
+Baseband chips that support 3G cellular networks often use a more powerful
+ARM926 or ARM975 core as MCU.
+
+\subsection{MCU peripherals}
+
+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, ...
+
+However, there are some additional peripherals that are very GSM specific:
+\begin{itemize}
+\item A GPRS crypto unit for the proprietary GEA family of ciphers
+\item 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
+\item GSM TDMA timers that can synchronize to the on-air time frames and generate interrupts to MCU and DSP
+\item Software-programmable hardware state machines for sequencing GSM burst Rx or Tx in ABB and RF Frontend
+\item An ISO7816 compatible smart card reader interface for the SIM card
+\item Audio routing, i.e. selecting how audio is routed in the phone,
+considering integrated earpiece, ringtone speaker and microphone, as
+well as external analog headset, handsfree or even bluetooth-attached
+audio devices.
+\end{itemize}
+
+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.
+
+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.
+
+However, as opposed to the DSP API documentation, the register-level
+documentation to the MCU peripherals is normally provided to the cellphone
+manufacturers.
+
+\section{Digital Baseband Software Architecture}
+
+This section provides an introductory reading in the typical software
+architecture as it is found on contemporary GSM digital baseband designs.
+
+The MCU usually runs a very small realtime operating system (RTOS) such
+as Nucleus, VxWorks or the L4 microkernel. In some cases, no operating
+system is used at all, in order to save royalties or licensing fees that
+would occurr for proprietary RTOS.
+
+\subsection{GSM Layer 1}
+
+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.
+
+However, there are some general observations that can be made about the L1:
+
+\subsubsection{L1 Synchronous part}
+
+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.
+
+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.
+
+\subsubsection{L1 Asynchronous part}
+
+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.
+
+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.
+
+\subsection{GSM Layer 2}
+
+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.
+
+LAPDm takes care of providing communication channels for Layer3. Those
+channels are protected from frame loss by the use of sequence numbers and
+retransmissions.
+
+The interface to Layer3 is typically implemented by means of a message queue.
+
+Primitives (but no detailed protocol) for use of the Layer2 / Layer3 interface
+are provided in the GSM specifications.
+
+\subsection{GSM Layer 3}
+
+GSM Layer 3 (L3) consist of sublayers for Radio Resource (RR), Mobility
+Management (MM) and Call Control (CC).
+
+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.
+
+\section{Synchronization and Clocking}
+
+The author of this paper has been quoted saying {\em GSM is a synchronous
+TDMA nightmare}. 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.
+
+GSM is synchronous in multiple ways between cell (BTS) and phone (MS):
+\begin{itemize}
+\item Synchronization of the carrier clock to tune the receiver and transmitter to the correct frequency
+\item Synchronization of the bit clock in order to perform sampling at the most optimal sample intervals
+\item Synchronization of the frame clock (and thus timeslots) to know when a TDMA frame and its 8 timeslots start
+\item Synchronization of the TDMA multiplex to correctly (de)multiplex the logical channels that are sent over each timeslots
+\end{itemize}
+
+As all those clocks are related to each other, they can (and should) all be
+derived from the same master clock: The VCTCXO present in each GSM
+phone.
+
+\subsection{How to synchronize the VCTCXO}
+
+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.
+
+To acquire initial synchronization to 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.
+
+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.
+
+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.
+
+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.
+
+\subsection{How to synchronize the frame clock}
+
+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.
+
+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.
+
+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.
+
+\subsection{How to synchronize the GSM TDMA multiplex}
+
+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.
+
+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.
+%% this is awkwardly worded
+
+\section{Miscellaneous Topics}
+
+\subsection{GPRS}
+
+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.
+
+The L1 and L2 protocols are very different (and much more complex) than GSM.
+
+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.
+
+\subsection{EDGE}
+
+EDGE is a very small incremental set of changes from 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.
+
+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.
+
+\subsection{UMTS}
+
+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.
+
+UMTS Layer2 has some resemblance to the GPRS Layer2.
+
+UMTS Layer3 for Mobility Management and Call Control are very similar to GSM.
+
+Given the vast physical layer and L1 differences, a UMTS phone hardware design
+significantly differs from what has been described in this document.
+
+Notwithstanding, all known commercial UMTS phone chipsets as of today still
+include a full GSM modem in hardware and software to remain
+backwards-compatible.
+
+\subsection{Dual-SIM and Triple-SIM phones}
+
+In recent years, a large number of so-called {\em Dual-SIM} or even {\em
+Triple-SIM} phones have entered the market, particularly in China and other
+parts of East Asia.
+
+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.
+
+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, ...
+
+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.
+
+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.
+
+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.
+
+\subsection{Powerful feature phones}
+
+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.
+
+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.
+
+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.
+
+\subsection{GSM baseband security features}
+
+There are several (sometimes conflicting) security requirements that
+apply to mobile phones. Interestingly, the security features are
+typically used to protect some industry interest against the interest of
+the customer. There are very few security features in a phone that are
+meant to protect the users or their interests.
+
+\subsubsection{IMEI - The hardware serial number}
+
+The International Mobile Equipment Identifier (IMEI) uniquely identifies
+a GSM phone. It is a globally unique serial number which is programmed
+into the phone non-volatile memory (Flash or EEPROM) during the
+production process. There are no particular security features used to
+store the IMEI. Once you are able to write to flash and have found it,
+it can be changed.
+
+\subsubsection{The SIM Card}
+
+The SIM card is a cryptographic smart card that stores the secret key
+used for authenticating the user to the GSM network (Ki). The Ki is
+never released by the card, and as such copying (cloning) of the SIM
+is prevented. Some early implementations of the SIM card had
+cryptographic weaknesses that inadvertently permitted cloning until the
+late 1990s.
+
+Furthermore, the SIM stores the International Mobile Subscriber Identity
+(IMSI). The IMSI is not encrypted or protected in any way.
+
+There is no security channel on the connection between the SIM card and
+the baseband MCU. Furthermore, there is no way how the MCU can securely
+identify/authenticate the SIM itself. Physical access to the SIM card
+slot allows sniffing and/or modification of the communications between
+the MCU and the SIM.
+
+\subsubsection{SIM or Operator Locking}
+
+GSM is an international standard. This ensures interoperability, i.e.
+any phone can be used on any network.
+
+However, in some cases, the vendors of a GSM phone want to restrict this
+interoperability and lock a phone to one specific network, or even lock
+it to a particular SIM.
+
+Those locks are implemented by software only, i.e. the MCU software will
+instruct the GSM protocol stack not to register with a network unless
+its network operator code is a certain factory-programmed network number.
+
+As such, techniques for circumventing those locks have become
+commonplace. It's somewhat of an ongoing race between the phone makers
+and the phone-unlockers. The industry invents ever more complex methods
+of obfuscating their locks in the software, while the phone-unlockers
+reverse engineer those bits for each and every phone model after some
+time.
+
+\subsubsection{DBB firmware signatures}
+
+In order to protect the operator and phone manufacturers peculiar
+business models based on SIM or operator locking, some vendors
+extended their baseband software with cryptographic signatures. Only
+if the correct signature is present in a software update, the bootloader
+program will accept the new software.
+
+However, there are more or less invasive hardware-related approaches in
+circumventing those signature checks, such as hardware debugging
+interfaces like JTAG, or replacing the external flash memory components.
+
+More recently, GSM chipset vendors introduced features such as
+hardware-assisted software signature checks. In this case a master key
+hash might be present in DBB-internal fuses, together with a
+signature-verifying boot loader in DBB-internal mask ROM. As the root
+of the chain of trust is moving deeper into the hardware, it becomes
+more difficult for anyone to make software modifications to the DBB.
+
+Especially with tighter integration, where RAM and FLASH are no longer
+present as discrete components but part of a multi-chip-package, the
+number of options are becoming more limited.
+
+On the other hand, an ever more complex baseband software stack is
+opening up many more options for exploiting software vulnerabilities.
+Given the lack of a proper/modern operating system with privilege
+separation and virtual memory, such exploits immediately give away
+full access to all aspects of the respective DBB.
+
+\section{Personal rant on the closedness of the GSM industry}
+
+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.
+
+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.
+
+The GSM handset products they sell are not generally available and
+distributed like other electronic components 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.
+
+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.
+
+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.
+
+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.
+
+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.
+
+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?
+
+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 to write software tools for security analysis, I still
+don't understand this secrecy.
+
+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. {\em They all cook with water}, 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 competition
+of those chipset makers can, too. In much less time, if they actually
+care.
+
+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. There is little to no chance for a small start-up to
+innovate, like they can in the sphere of the internet.
+
+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.
+
+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.
+
+They still don't happen on the baseband processor, which is as closed as
+it was 15 years ago.
+
+\end{document}
diff --git a/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.4.pdf b/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.4.pdf
new file mode 100644
index 0000000..fe1adbe
--- /dev/null
+++ b/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.4.pdf
Binary files differ
diff --git a/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.4.tex b/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.4.tex
new file mode 100644
index 0000000..88927b0
--- /dev/null
+++ b/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.4.tex
@@ -0,0 +1,984 @@
+\documentclass[a4paper]{article}
+\usepackage[english]{babel}
+\usepackage{graphicx}
+\usepackage{subfigure}
+\pagestyle{plain}
+
+%\usepackage{url}
+
+\setlength{\oddsidemargin}{0in}
+\setlength{\evensidemargin}{0in}
+\setlength{\topmargin}{0in}
+\setlength{\headheight}{0in}
+\setlength{\headsep}{0in}
+\setlength{\textwidth}{6.5in}
+\setlength{\textheight}{9.5in}
+%\setlength{\parindent}{0in}
+\setlength{\parskip}{0.05in}
+
+\begin{document}
+
+\title{Anatomy of contemporary GSM cellphone hardware}
+\author{Harald Welte $<$laforge@gnumonks.org$>$}
+\maketitle
+
+\begin{abstract}
+%% add citation for the nubmer of gsm users and phones / carriers.
+Billions of cell phones are being used every day by an almost equally large
+number of users. The majority of those phones are built according to
+the GSM protocol specifications and interoperate with GSM networks of hundreds
+of carriers.
+
+Despite being an openly published international standard, the architecture of
+GSM networks and its associated protocols are only known to a relatively
+small group of R\&D engineers.
+
+Even less public information exists about the hardware architecture of the
+actual mobile phones themselves, at least as far as it relates to that part
+of the phone implementing the GSM protocols and facilitating access to the
+public GSM networks.
+
+This paper is an attempt to serve as an introductory text into the hardware
+architecture of contemporary GSM mobile phone hardware anatomy. It is intended
+to widen the technical background on mobile phones within the IT community.
+\end{abstract}
+
+\tableofcontents
+
+\section{Foreword}
+
+This document is the result of my personal research on mobile phone
+hardware and system-level software throughout the last six years.
+
+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.
+
+I hope it is useful for any systems level engineer with an interest in
+understanding more about how mobile phone hardware actually works.
+
+There are no guarantees for accuracy or correctness of any part of the
+document. I happily receive your feedback and corrections.
+
+\section{Is your phone smart or does it have features?}
+
+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.
+
+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.
+
+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 {\em smartphone}. At that point there was a
+need to differentiate from those phones that were not-so-smart. Those
+phones were then called {\em feature phones}.
+
+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.
+
+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:
+
+\subsection{Feature Phone}
+
+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 {\em baseband processor} (BP).
+Some manufacturers also call it Cellular Processor (CP) or CMT.
+
+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.
+
+\subsection{Smartphone}
+
+There is no clear, industry-wide definition on the term "smartphone".
+
+Originally, and for the scope of this paper, a smartphone is a phone that has
+one 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 {\em application processor} (AP).
+
+The baseband processor (BP) part in a smartphone is typically the same as
+in a feature phone. But instead of connecting it to a personal computer,
+a small PDA (personal digital assistant) is built into the same case.
+
+We will later discuss smartphone hardware architecture in more detail, but
+let's first look at the GSM modem side of things.
+
+\section{GSM modem architecture}
+
+Every GSM phone, feature phone and smartphone alike, has a GSM modem interfacing
+with the GSM network.
+
+This GSM modem consists of several parts:
+\begin{itemize}
+\item RF Frontend, responsible for receiving and transmitting on GSM frequencies
+\item Analog Baseband, responsible for modulation and demodulation
+\item Digital Baseband, responsible for digital signal processing and the GSM protocol stack
+\end{itemize}
+
+\begin{figure}[h]
+\centering
+\includegraphics[width=160mm]{calypso-block.pdf}
+\caption{Block schematics of a TI Calypso/Iota/Rita GSM modem}
+\label{reg-form}
+\end{figure}
+
+\subsection{The RF Frontend}
+
+The RF Frontend is tasked with the physical receive and transmit
+interface with the GSM air interface (sometimes called Um interface).
+
+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.
+
+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.
+
+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 single-pole 6-throw (SP6T)
+switch is used: 4 for the four Rx bands (one for each band), and 2 for
+Tx (where 850+900 and 1800+1900 each share one PA output, respectively).
+
+\subsubsection{RF Frontend receive path}
+
+The antenna picks up the GSM radio signal as it is sent from a GSM cell tower
+(properly called a Base Transceiver Station, or abbreviated as 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.
+
+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.
+
+The baseband signal is then filtered to remove unwanted images and sent
+as analog I/Q signals (representing amplitude and phase) to the ABB.
+
+\subsubsection{RF Frontend transmit path}
+
+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.
+
+\subsubsection{Local Oscillator}
+
+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.
+
+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.
+
+\subsection{The Analog Baseband (ABB)}
+
+The ABB part of a GSM modem is responsible to interface between the
+digital domain and the analog domain of the GSM modem.
+
+\subsubsection{ABB Receive path}
+
+The analog baseband I/Q signals are potentially filtered again and
+digitized by an 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.
+
+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.
+
+\subsubsection{ABB Transmit path}
+
+There are multiple architectures found in the ABB transmit path.
+
+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.
+
+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.
+
+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.
+
+\subsection{The Digital Baseband (DBB)}
+
+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.
+
+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.
+
+\subsubsection{Digital Signal Processor}
+
+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, ...).
+
+The DSP performs the primary tasks such as Viterbi equalization,
+demodulation, decoding, forward error correction, error detection, burst
+(de)interleaving.
+
+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.
+
+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.
+
+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.
+
+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
+devices take care of the modulation to reduce DSP load).
+
+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).
+
+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.
+
+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.
+
+\subsubsection{DSP Peripherals}
+
+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. %% cite
+
+Thus, the DSP in a DBB commonly has a integrated peripheral implementing the A5
+encryption.
+
+Further integrated DSP peripherals may include a viterbi hardware accelerator,
+a DMA capable serial interface to the ABB and others.
+
+\subsection{Baseband Processor (MCU)}
+
+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.
+
+Baseband chips that support 3G cellular networks often use a more powerful
+ARM926 or ARM975 core as MCU.
+
+\subsection{MCU peripherals}
+
+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, ...
+
+However, there are some additional peripherals that are very GSM specific:
+\begin{itemize}
+\item A GPRS crypto unit for the proprietary GEA family of ciphers
+\item 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
+\item GSM TDMA timers that can synchronize to the on-air time frames and generate interrupts to MCU and DSP
+\item Software-programmable hardware state machines for sequencing GSM burst Rx or Tx in ABB and RF Frontend
+\item An ISO7816 compatible smart card reader interface for the SIM card
+\item Audio routing, i.e. selecting how audio is routed in the phone,
+considering integrated earpiece, ringtone speaker and microphone, as
+well as external analog headset, handsfree or even bluetooth-attached
+audio devices.
+\end{itemize}
+
+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.
+
+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.
+
+However, as opposed to the DSP API documentation, the register-level
+documentation to the MCU peripherals is normally provided to the cellphone
+manufacturers.
+
+\section{Digital Baseband Software Architecture}
+
+This section provides an introductory reading in the typical software
+architecture as it is found on contemporary GSM digital baseband designs.
+
+The MCU usually runs a very small realtime operating system (RTOS) such
+as Nucleus, VxWorks or the L4 microkernel. In some cases, no operating
+system is used at all, in order to save royalties or licensing fees that
+would occurr for proprietary RTOS.
+
+\subsection{GSM Layer 1}
+
+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.
+
+However, there are some general observations that can be made about the L1:
+
+\subsubsection{L1 Synchronous part}
+
+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.
+
+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.
+
+\subsubsection{L1 Asynchronous part}
+
+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.
+
+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.
+
+\subsection{GSM Layer 2}
+
+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.
+
+LAPDm takes care of providing communication channels for Layer3. Those
+channels are protected from frame loss by the use of sequence numbers and
+retransmissions.
+
+The interface to Layer3 is typically implemented by means of a message queue.
+
+Primitives (but no detailed protocol) for use of the Layer2 / Layer3 interface
+are provided in the GSM specifications.
+
+\subsection{GSM Layer 3}
+
+GSM Layer 3 (L3) consist of sublayers for Radio Resource (RR), Mobility
+Management (MM) and Call Control (CC).
+
+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.
+
+\section{Synchronization and Clocking}
+
+The author of this paper has been quoted saying {\em GSM is a synchronous
+TDMA nightmare}. 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.
+
+GSM is synchronous in multiple ways between cell (BTS) and phone (MS):
+\begin{itemize}
+\item Synchronization of the carrier clock to tune the receiver and transmitter to the correct frequency
+\item Synchronization of the bit clock in order to perform sampling at the most optimal sample intervals
+\item Synchronization of the frame clock (and thus timeslots) to know when a TDMA frame and its 8 timeslots start
+\item Synchronization of the TDMA multiplex to correctly (de)multiplex the logical channels that are sent over each timeslots
+\end{itemize}
+
+As all those clocks are related to each other, they can (and should) all be
+derived from the same master clock: The VCTCXO present in each GSM
+phone.
+
+\subsection{How to synchronize the VCTCXO}
+
+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.
+
+To acquire initial synchronization to 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.
+
+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.
+
+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.
+
+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.
+
+\subsection{How to synchronize the frame clock}
+
+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.
+
+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.
+
+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.
+
+\subsection{How to synchronize the GSM TDMA multiplex}
+
+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.
+
+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.
+%% this is awkwardly worded
+
+\section{Miscellaneous Topics}
+
+\subsection{GPRS}
+
+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.
+
+The L1 and L2 protocols are very different (and much more complex) than GSM.
+
+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.
+
+\subsection{EDGE}
+
+EDGE is a very small incremental set of changes from 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.
+
+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.
+
+\subsection{UMTS}
+
+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.
+
+UMTS Layer2 has some resemblance to the GPRS Layer2.
+
+UMTS Layer3 for Mobility Management and Call Control are very similar to GSM.
+
+Given the vast physical layer and L1 differences, a UMTS phone hardware design
+significantly differs from what has been described in this document.
+
+Notwithstanding, all known commercial UMTS phone chipsets as of today still
+include a full GSM modem in hardware and software to remain
+backwards-compatible.
+
+\subsection{Dual-SIM and Triple-SIM phones}
+
+In recent years, a large number of so-called {\em Dual-SIM} or even {\em
+Triple-SIM} phones have entered the market, particularly in China and other
+parts of East Asia.
+
+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.
+
+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, ...
+
+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.
+
+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.
+
+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.
+
+\subsection{GSM baseband security features}
+
+There are several (sometimes conflicting) security requirements that
+apply to mobile phones. Interestingly, the security features are
+typically used to protect some industry interest against the interest of
+the customer. There are very few security features in a phone that are
+meant to protect the users or their interests.
+
+\subsubsection{IMEI - The hardware serial number}
+
+The International Mobile Equipment Identifier (IMEI) uniquely identifies
+a GSM phone. It is a globally unique serial number which is programmed
+into the phone non-volatile memory (Flash or EEPROM) during the
+production process. There are no particular security features used to
+store the IMEI. Once you are able to write to flash and have found it,
+it can be changed.
+
+\subsubsection{The SIM Card}
+
+The SIM card is a cryptographic smart card that stores the secret key
+used for authenticating the user to the GSM network (Ki). The Ki is
+never released by the card, and as such copying (cloning) of the SIM
+is prevented. Some early implementations of the SIM card had
+cryptographic weaknesses that inadvertently permitted cloning until the
+late 1990s.
+
+Furthermore, the SIM stores the International Mobile Subscriber Identity
+(IMSI). The IMSI is not encrypted or protected in any way.
+
+There is no security channel on the connection between the SIM card and
+the baseband MCU. Furthermore, there is no way how the MCU can securely
+identify/authenticate the SIM itself. Physical access to the SIM card
+slot allows sniffing and/or modification of the communications between
+the MCU and the SIM.
+
+\subsubsection{SIM or Operator Locking}
+
+GSM is an international standard. This ensures interoperability, i.e.
+any phone can be used on any network.
+
+However, in some cases, the vendors of a GSM phone want to restrict this
+interoperability and lock a phone to one specific network, or even lock
+it to a particular SIM.
+
+Those locks are implemented by software only, i.e. the MCU software will
+instruct the GSM protocol stack not to register with a network unless
+its network operator code is a certain factory-programmed network number.
+
+As such, techniques for circumventing those locks have become
+commonplace. It's somewhat of an ongoing race between the phone makers
+and the phone-unlockers. The industry invents ever more complex methods
+of obfuscating their locks in the software, while the phone-unlockers
+reverse engineer those bits for each and every phone model after some
+time.
+
+\subsubsection{DBB firmware signatures}
+
+In order to protect the operator and phone manufacturers peculiar
+business models based on SIM or operator locking, some vendors
+extended their baseband software with cryptographic signatures. Only
+if the correct signature is present in a software update, the bootloader
+program will accept the new software.
+
+However, there are more or less invasive hardware-related approaches in
+circumventing those signature checks, such as hardware debugging
+interfaces like JTAG, or replacing the external flash memory components.
+
+More recently, GSM chipset vendors introduced features such as
+hardware-assisted software signature checks. In this case a master key
+hash might be present in DBB-internal fuses, together with a
+signature-verifying boot loader in DBB-internal mask ROM. As the root
+of the chain of trust is moving deeper into the hardware, it becomes
+more difficult for anyone to make software modifications to the DBB.
+
+Especially with tighter integration, where RAM and FLASH are no longer
+present as discrete components but part of a multi-chip-package, the
+number of options are becoming more limited.
+
+On the other hand, an ever more complex baseband software stack is
+opening up many more options for exploiting software vulnerabilities.
+Given the lack of a proper/modern operating system with privilege
+separation and virtual memory, such exploits immediately give away
+full access to all aspects of the respective DBB.
+
+
+\section{Smartphone hardware archtiecture}
+
+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
+{\em application processor} (AP).
+
+The purpose of the application processor is to run a general-purpose
+operating system (OS) driving a rich user interface (UI) software stack, which
+provides a platform for running application programs. Such applications
+migh be developed by the original phone vendor or by third parties.
+
+There is no specific technical reason for splitting the functionality among
+two independent processors. It is more likely that business and political
+issues played a role in this. The baseband processor vendors are typically
+very reluctant to give up any amount of control over "their" processor. They
+also don't usually provide sufficient informtaion or a general-purpose enough
+operating system on it.
+
+So the logical choice is to keep the "phone part" (aka GSM modem) just like
+it was (and is) in feature phones, but add an entirely separate PDA-like
+embedded system with an application processor into the same device.
+
+It is common to use existing feature phone GSM modem designs in smartphones.
+The same BP chipset and peripherals are used.
+
+\subsection{Fully separate AP and BP}
+
+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 connection to the
+BP is removed. What remains of the feature phone is a {\em GSM modem},
+controlled by AT commands sent from the AP.
+
+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 those seen in the personal computer industry.
+
+The interface between AP and BP originally was a simple serial (UART) line,
+but ever since there has been a growing variety of electrical-level interfaces.
+For more information, see the section below on the Interface between AP and BP
+
+\subsection{Integrated Smartphone-on-a-chip Solutions}
+
+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. The first popular example was the Qualcomm MSM7200
+as used in the first generation of Android and many Windows Mobile phones.
+
+More recently, other manufacturers such as ST-Ericsson (a merger of the
+cellular chipset business of NXP, ST Micro and Ericsson Mobile Platforms)
+have been shipping similar products.
+
+Such integrated chips typically combine the
+\begin{itemize}
+\item Application processor (typically ARM11, Cortex-A8 or A9)
+\item AP peripherals such as RAM-controller, display controller, I2C, SPI, SDIO, etc.
+\item Digital Baseband (DBB), typically including an ARM9 core and a DSP
+\item Integrated peripherals of a the BP, including ADC and DAC
+\item A GPU (Graphics Processing Unit) for 3D and/or video codec acceleration
+\end{itemize}
+
+Sometimes, even a second DSP is added for signal processing tasks of the AP side.
+
+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.
+
+In such systems, some integrated peripheral logic is separating the physical
+RAM and flash into portions that are accessible from the AP and portions
+accesible from the BP. The division ratio as well as the access levels
+might be configurable by software, eFuses or bootstrap pins of the package.
+
+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.
+
+\subsection{Control + Data Interface between AP and BP}
+
+\subsubsection{Serial Line}
+
+The interface between AP and BP originally was a simple serial line (UART),
+over which AT commands compliant with GSM TS 07.05 / 07.07 are spoken. A
+serial line with a standard speed of 115200bps is sufficient for the control of
+GSM voice calls, SMS, circuit switched data (CSD), as well as most GPRS data
+speeds. However, for concurrent data and voice services, a serial multiplexor
+protocol according to GSM TS 07.10 was used. It provides multiple virtual
+channels with each their own instance of an AT command parser on the BP.
+
+As the data speeds of the cellular networks were increased with EDGE (both ECSD
+and EGPRS), an asynchronouse serial connection at standard speeds became
+to narrow as a communications channel.
+
+\subsubsection{Universal Serial Bus (USB)}
+
+The EDGE capable GSM modems that were once again coming from the feature phone
+designs typically included a USB device mode controller for attaching those
+feature phones to personal computers.
+
+While many of the USB-device-capable BPs use the standardized CDC-ACM protocol
+to emulate one or multiple serial ports over USB, there never was any standard
+or even any recommendation in the GSM/3GPP specifications.
+
+So a number of smartphone designs such as the Motorola EZX platform (A780,
+A1200, ROKR E6, etc.) simply used that existing USB device-mode controller and
+connected it to a USB host controller inside the AP. However, USB is far from
+being a good protocol for this application, mostly due to power management
+issues. If the phone is idle, the AP switches in some kind of deep-sleep
+state. To do this, it has to disable the USB host controller, whcih in turn
+means that the BP has no way how to actually issue a wake-up to the AP in case
+of an incoming call. The solution to the problem was connecting some general
+purpose output signal of the BP to a wakeup-capable general-purpose input
+of the AP. However, this means that the system is no longer fully USB
+compatible, and that the BP software has to be specifically modified.
+
+\subsubsection{Serial Peripheral Interface}
+
+Some smartphone designs, most notably those of E-TEN corporation (now Acer)
+have started to use SPI-class electrical interfaces between the AP and BP.
+
+However, as SPI normally is a master/slave type of protocol, additional
+handshaking was needed to allow the slave to request an outgoing data transfer
+from the master.
+
+Modern application processors support SPI with speeds of up to 25 or sometimes
+50 MHz, providing more than sufficient bandwidth for even the fastest available
+cellular transfer speeds over the air interface.
+
+The second-layer protocol on top of this SPI link is vendor-specific and
+proprietaty. One of them is known as CAIF by Ericsson Mobile Products (EMP).
+
+\subsubsection{Shared Memory / Dual Ported RAM}
+
+Another method for interfacing wth AP with the BP is by using some form
+of shared memory. The clear advantage is speed, as access to parallel RAM
+is typically several orders of magnitude faster than any serial link.
+Furthermore, there is no need for serializer/deserializer, the use of DMA
+controllers and the like. The data is available without any copying
+(zero-copy).
+
+Management of shared memory is a complex problem though, and there has
+to be some kind of mutual exclusion mechanism to prevent coherency/concurrency
+problems like race conditions.
+
+Depending on the chipset architecture, this is either an actual external
+dual-ported RAM (DPRAM) that provides separate address and data busses for AP
+and BP. Sometimes that DPRAM is built into the BP - or simulated by the BP
+using some internal arbitration logic.
+
+In the latest Smarphone-on-a-Chip systems, the shared memory is simply one
+portion of the phyiscal RAM which is mapped into the address space of both AP
+and BP parts - while the remaining RAM is mapped exclusively to either the
+AP or the BP.
+
+\subsection{Audio Interface between AP and BP}
+
+In feature phones, the audio architecture is quite simple: Microphone and
+earpiece speaker are all connected to an audio codec which is co-located with
+the analog baseband (ABB) chip. A digital serial audio interface connects this
+codec with the DSP inside the BP. As the DSP does both the
+demodulation/decoding of the baseband signal as well as the actual voice codec
+processing, speech data never needs to leave the DSP. The MCU is purely
+handling control, but no voice data.
+
+With a bluetooth headset things get slightly more complex, but not much.
+Bluetooth chipsets for mobile phones have a control interface (typically UART),
+as well as a synchronous serial PCM interface. That PCM interface then needs
+to be hooked up either to the ABB or the DSP.
+
+In a smartphone however, things are getting more complicated. The Application
+Processor wants to play-back music, both via the ringtone speaker as well as
+the headset. Ringtones are no longer played back by the BP, but are typically
+mp3 files on the AP. Voice recording / memo features require the microphone
+to be routed to the AP. Some advanced phones allow you to record an actual
+voice call. While that call is handled by the BP, recording is done by the AP,
+which is storing it to mass storage memory such as a (micro)SD card.
+
+There are different audio architectures on smartphones, all of them are complex.
+
+\subsubsection{Analog audio interface}
+
+This is the most "logical" interface, looking at the idea of a smartphone being
+a feature phone and a PDA in one box: The AP gets an audio codec chip not
+different to what a "sound card" used to be for the PC.
+
+Using proper analog impedance matching networks, you connect the analogue
+output of the ABB to a line input of the codec chip. One of the codec
+outputs is connected to the microphone input of the codec chip.
+
+The actual micrphone is connected to the microphone input of the codec chip,
+while the headphone jack and ringtone speakers are connected to corresponding
+outputs of the codec.
+
+The digital (PCM/IIS) interface of the codce is driven by the AP.
+
+So all connections between ABB and codec are analog, while the AP-codec
+connection is digital.
+
+If you add a bluetooth interface for wireless headsets, the codec chip will
+need a second IIS/PCM interface which is then connected to that bluetooth chip.
+
+Analog audio signals on an otherwise completely digital device can be
+cumbersome. They will likely catch noise from power supply or digital signals.
+
+\subsubsection{Digital audio interface}
+
+The solution to this problem is to use digital audio interfaces. This will
+require some cooperation/integration with either the ABB or the DBB of the
+baseband processor and was not possible with re-purposed BP chipsets that
+were not built with smartphones in mind.
+
+One possible architecture is to have an ABB that offers a secondary PCM/IIS
+interface for the AP. Another solution is to use the PM/IIS as a multi-master
+bus, which is either driven by the AP or the BP, depending on the current
+use case.
+
+The third option is to no longer use any voice band DAC/ADC that might be
+present in the ABB and use a codec chip that has at least two (three with
+bluetooth) PCM/IIS interfaces, and a DBB that has a compatible digital
+PCM interface.
+
+\section{Powerful feature phones}
+
+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.
+
+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.
+
+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.
+
+The chipset vendor most associated with this strategy is Mediatek (MTK) in
+Taiwan, who bough the cellular chipset business from Analog Devices (ADI).
+
+In MTK chipsets , you can find unusual combinations of an ARM7 core with
+Jazelle (ARM7EJS), which has H.264 hardware codecs attached to it. Most
+of the competition doesn't have Jazelle or advanced video codecs in anything
+smaller than an ARM9.
+
+\section{Personal rant on the closedness of the GSM industry}
+
+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.
+
+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.
+
+The GSM handset products they sell are not generally available and
+distributed like other electronic components 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.
+
+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.
+
+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.
+
+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.
+
+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.
+
+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?
+
+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 to write software tools for security analysis, I still
+don't understand this secrecy.
+
+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. {\em They all cook with water}, 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 competition
+of those chipset makers can, too. In much less time, if they actually
+care.
+
+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. There is little to no chance for a small start-up to
+innovate, like they can in the sphere of the internet.
+
+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.
+
+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.
+
+They still don't happen on the baseband processor, which is as closed as
+it was 15 years ago.
+
+\end{document}
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
Binary files differ
diff --git a/2010/gsm_phone-anatomy/phones.txt b/2010/gsm_phone-anatomy/phones.txt
new file mode 100644
index 0000000..16b8879
--- /dev/null
+++ b/2010/gsm_phone-anatomy/phones.txt
@@ -0,0 +1,14 @@
+
+Phone AP BP Intf Audio
+
+EZX Marvell PXA270 Freescale Neptune LTE USB+ SSI
+MAGX Freescale Freescale Neptune LTE USB+
+iPhone Samsung Infineon ?
+Palm Pre TI OMAP3 Qualcomm MSM62xx ?
+Galaxy S S5PC1100 Qualcomm
+Google G1 Qualcoom Integrated MSM7200
+Nexus One
+Freerunner S3C2442 TI Calypso UART analog
+glofiish M900 S3C2442 Ericsson EMP SPI
+glofiish M900 S3C6410 Ericsson EMP SPI
+Nokia N900 OMAP3430 Rapu Yama ? SSI
diff --git a/2010/gsm_phone-anatomy/topics b/2010/gsm_phone-anatomy/topics
new file mode 100644
index 0000000..9786151
--- /dev/null
+++ b/2010/gsm_phone-anatomy/topics
@@ -0,0 +1,48 @@
+* gsm protocol intro as far as needed
+* distinction smartphone / featurephone
+ * feature phones
+ * single processor (BP) for gsm stack + UI
+ * smartphones
+ * dual processor (AP / BP)
+ * baseband processor like in feature phone
+ * additional application processor for OS/UI
+ * PDA + phone in a box
+ * different interconnects
+
+* closer look at baseband chipset architecture
+ * DBB (MCU+DSP)
+ * integrated peripherals
+ * GSM TDMA timer / interrupt
+ * A5 ciphering unit
+ * GEA ciphering unit
+ * low power timers / RTC crystal calibration for power saving
+ * synchronous clock architecture
+ * AFC / VCTCXO
+ * ABB
+ * RF Frontend
+ * VCO + PLL + mixer
+ * RF PA
+ * Antenna switch (MEMS or diode)
+ * integrated frontend modules
+
+* introduction to GSM software architecture
+ * layer 1
+ * synchronous part
+ * asynchronous part
+ * layer 2
+ * layer 3
+ * telephony API
+ * actual UI
+ * AT command parser or related
+
+* misc
+ * gprs
+ * edge
+ * 3g
+ * multi-sim
+ * more powerful feature phones
+
+
+* glossary
+* references
+
personal git repositories of Harald Welte. Your mileage may vary