From fca59bea770346cf1c1f9b0e00cb48a61b44a8f3 Mon Sep 17 00:00:00 2001 From: Harald Welte Date: Sun, 25 Oct 2015 21:00:20 +0100 Subject: import of old now defunct presentation slides svn repo --- 2010/gsm_phone-anatomy/calypso-block.eps | 832 +++++++++++++++++ 2010/gsm_phone-anatomy/calypso-block.pdf | Bin 0 -> 14118 bytes 2010/gsm_phone-anatomy/calypso-block.svg | 778 ++++++++++++++++ 2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.1.pdf | Bin 0 -> 184103 bytes 2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.2.pdf | Bin 0 -> 184322 bytes 2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.2.tex | 674 ++++++++++++++ 2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.3.pdf | Bin 0 -> 191293 bytes 2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.3.tex | 770 ++++++++++++++++ 2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.4.pdf | Bin 0 -> 206865 bytes 2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.4.tex | 984 +++++++++++++++++++++ .../html/gsm_phone-anatomy-v0.2.css | 120 +++ .../html/gsm_phone-anatomy-v0.2.html | 552 ++++++++++++ .../html/gsm_phone-anatomy-v0.20x.png | Bin 0 -> 60416 bytes 2010/gsm_phone-anatomy/phones.txt | 14 + 2010/gsm_phone-anatomy/topics | 48 + 15 files changed, 4772 insertions(+) create mode 100644 2010/gsm_phone-anatomy/calypso-block.eps create mode 100644 2010/gsm_phone-anatomy/calypso-block.pdf create mode 100644 2010/gsm_phone-anatomy/calypso-block.svg create mode 100644 2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.1.pdf create mode 100644 2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.2.pdf create mode 100644 2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.2.tex create mode 100644 2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.3.pdf create mode 100644 2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.3.tex create mode 100644 2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.4.pdf create mode 100644 2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.4.tex create mode 100644 2010/gsm_phone-anatomy/html/gsm_phone-anatomy-v0.2.css create mode 100644 2010/gsm_phone-anatomy/html/gsm_phone-anatomy-v0.2.html create mode 100644 2010/gsm_phone-anatomy/html/gsm_phone-anatomy-v0.20x.png create mode 100644 2010/gsm_phone-anatomy/phones.txt create mode 100644 2010/gsm_phone-anatomy/topics (limited to '2010/gsm_phone-anatomy') 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 Binary files /dev/null and b/2010/gsm_phone-anatomy/calypso-block.pdf 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 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + CALYPSODigital BasebandDSPMCUSRAMMask ROMUART, SPI, I2C + + + + TWL3025ABB + BSP + USP + TSP + BUL + BDL + + + + AntennaSwitch + ASM4532 + + + + + + + + + TRF6151 + TransceiverMixersVCOPLL + + RF3166 + RF PA + TSP + + + GSM + + + + DCS/PCS + + + + GSM + + + + DCS + + + + PCS + + + RFCLK + + + + + I/Q Analog + + + + + CLK13M + + + + AFC Analog + + + TSP Parallel + TSP Serial + + + CLK32K + + + + GSM + + + + + DCS/PCS + + + + APC Analog + + I/Q Digital + SPI + + 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 Binary files /dev/null and b/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.1.pdf 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 Binary files /dev/null and b/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.2.pdf 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 Binary files /dev/null and b/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.3.pdf 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 Binary files /dev/null and b/2010/gsm_phone-anatomy/gsm_phone-anatomy-v0.4.pdf 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 @@ + + +Anatomy of contemporary GSM cellphone hardware + + + + + + + + +
+ + + +

Anatomy of contemporary GSM cellphone hardware

+
Harald Welte <laforge@gnumonks.org>
+
+
April 14, 2010
+
+
+
+

+

Abstract

+

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. +

+

1 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. + +

+

2 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 smartphone. At that point there was a +need to differentiate from those phones that were not-so-smart. Those phones were then called 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: +

+

2.1 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 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. +

+

2.2 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 +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 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. +

+

3 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: +

+

+ + + +

PIC +

Figure 1: Block schematics of a TI Calypso/Iota/Rita GSM modem
+ +

+

3.1 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 SP +

+

3.1.1 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. +

+

3.1.2 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. +

+

3.1.3 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. +

+ +

3.2 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. +

+

3.2.1 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. +

+

3.2.2 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. +

+

3.3 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. +

+

3.3.1 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. +

+

3.3.2 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. +

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. +

+

3.4 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. +

+

3.5 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: +

+

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. +

+

4 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. +

+

4.1 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: +

+

4.1.1 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. +

+

4.1.2 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. + +

+

4.2 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. +

+

4.3 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. +

+

5 Synchronization and Clocking

+

The author of this paper has been quoted saying 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): +

+

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. +

+

5.1 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. +

+

5.2 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. +

+

5.3 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. +

+

6 Miscellaneous Topics

+

+

6.1 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. +

+

6.2 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. +

+

6.3 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. +

+

6.4 Dual-SIM and Triple-SIM phones

+

In recent years, a large number of so-called Dual-SIM or even 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. + +

+

6.5 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. +

+

7 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. 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. + + + + + 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 Binary files /dev/null and b/2010/gsm_phone-anatomy/html/gsm_phone-anatomy-v0.20x.png 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 + -- cgit v1.2.3